《软件质量保证过程(SQA).doc》由会员分享,可在线阅读,更多相关《软件质量保证过程(SQA).doc(26页珍藏版)》请在三一办公上搜索。
1、软件质量保证过程软件质量保证过程作为一种独立的审查活动贯穿于整个软件开发过程.质量控制人员类似于软件开发过程中的过程警察,其主要职责是:检查开发和管理活动是否与制定的过程策略、标准和流程一致;检查工作产品是否遵循模板规定的内容和格式。此文档从软件开发过程的各个阶段来描述软件质量保证过程。1. 计划阶段目的和范围:项目计划过程的目的是计划并执行一系列必要的活动,以便在不超出项目预算和日程安排的前提下,将优质的产品交付给客户。项目计划过程适用于公司的所有项目,但每个项目可以根据各自的不同情况对该过程进行裁剪。进入标准:n 项目启动会议已经结束;n 在项目的生命周期中,根据项目的跟踪结果,需要对项目
2、计划进行修改和完善。输入:n 项目启动报告;n 项目提案书;n 项目相关文档;n 组织财富库中以往类似的经验文档。退出标准:项目计划已通过评审、批准并确立。输出:评审后的项目计划文档包括:n 软件开发质量计划;n 软件配置管理计划。过程描述:项目计划包含3个需要在项目中执行和管理的主要计划,如下:n 软件项目管理计划;n 软件项目质量管理计划;n 软件配置管理计划。软件项目管理计划涉及项目中所有与项目管理相关的问题(从项目开始到结束)。软件项目质量管理计划涉及与质量相关的需求,这些需要在产品中实现,并保证用于构筑产品的项目过程。由于质量是产品创建的一部分,所以将软件项目管理计划和软件项目质量管
3、理计划合成一个计划文档,称为软件开发质量计划。软件配置管理计划用于管理与配置管理相关的需求,这些需求与工作产品和可交付产品有关。该计划的目的在于:为执行软件工程相关活动提供依据,并在整个开发和维护过程中对软件项目进行管理。可以使用不同的检查表来制定软件开发质量计划和软件配置管理计划。如下每个计划都将包含以下3点:n 目标;n 执行方法;n 当前状态。前两点不会经常变更,但第三点则被认为会在执行跟踪时被修改。因此,前两点通常被直接放到计划中,而第三点则以链接的方法放到计划中。(1)制订软件开发质量计划软件开发质量计划包括软件项目管理计划、软件项目质量管理计划。制订软件项目管理计划软件项目管理计划
4、的主要内容包括基础设施计划,进度计划(包括各种类型的估算)、风险管理计划、项目培训计划、执行计划、客户管理计划。n 基础设施计划基础设施计划包括项目开始执行前必须到位的所有需求,它需要解决以下问题:软件工程需求、基础设施需求、角色和职责、内外部接口、过程需求、知识和技能需求。n 进度计划进度计划涉及制定合理可用的项目进度。在制定项目进度时,需要进行下面的估算:规模(Size)、工作量(effort)。项目进度需要描述以下内容:执行的活动、估算的人时、投入的人员、责任人和时间线、里程碑事件的标识。n 风险管理计划风险管理包括:标识风险事件(与管理相关的风险、与执行相关的风险,与客户相关的风险等)
5、、评估风险并设定风险优先级、制订风险缓解和应急计划并跟踪该计划。n 项目培训计划根据项目及人员结构制订项目培训计划,包括业务领域知识、技术、工具等方面的培训计划。n 执行计划项目执行计划包含了与执行当前项目关系最大的生命周期模型。该计划对组织级执行模型进行了裁剪。项目生命周期模型通常包括:项目执行的阶段、各阶段的输入和输出、可交付的产品、需要迭代(反复)的阶段。制订软件项目质量管理计划制订软件项目质量管理计划包含如下主要内容:n 项目设定的质量标准;n 同级评审计划:同级评审计划中描述了在不同的软件生命周期开发阶段,对不同的工作产品所采用的同级评审类型;n 测试计划:测试计划包括对可执行文件/
6、模块或整个系统将要进行的各种测试。根据项目测试过程来制定测试计划;n 度量管理计划:通过裁剪组织级的度量过程来制定项目度量管理计划。n 缺陷预防计划:管理、开发和测试人员互相配合制订缺陷预防计划,防止已识别的缺陷再次发生;n 过程改进计划:项目级过程改进的机会要记录到过程改进计划中。这些机会主要来源于度量分析、缺陷预防分析和标识出的好的或可避免的实践。(2)制订软件配置管理计划软件配置管理计划主要包括以下内容:n 软件配置管理计划组织;n 角色和职责;n 开发/维护配置管理计划,包括可配置项的标识、命名约定、目录结构、访问控制、变更管理、基线库创建、放入/提取(Checkin/Checkout
7、)机制、版本控制;n 产品配置管理,包括产品中部件的可跟踪性,产品的版本设定和发布、交付的配置管理(标识出要交付的产品构成)、需求配置管理(需求基线的确定、产品版本与划定基线的需求版本之间的关系)、配置审计。验证:同级评审人员和软件质量保证人员必须对项目计划进行评审,批准后项目才能付诸实施。配置控制:项目经理保管所有项目计划文档。对所有项目计划文档都要进行配置管理。项目结束后,所有的项目计划文档都要保存到组织财富库中,仍受配置控制。QA检查清单:QA检查清单包括:n 软件开发质量计划;n 软件配置管理计划。该阶段要确保制定了软件开发质量计划和软件配置管理计划。2. 需求分析阶段目的和范围:需求
8、说明和需求管理过程的目的是为了保证开发组在开发期间对项目目标和生产出最后产品的目的有一个清晰的理解。软件需求规格说明书将作为产品测试和验证是否适合需要的基础。对于需求的变更,它可能在开发项目期间的任何时间点发生,需求的变更将要影响日程和承诺的变化,这些变化需要和客户所提出的要求相一致。进入标准:n 计划已经被批准,并且项目整体的基础设施是可用的;n 软件的需求已经被需求收集小组捕获;n 对已经形成了基线的软件需求规格说明书有变更的请求时。输入:n 软件的需求说明书;n 变更需求的请求。退出标准:n 软件需求规格说明书已经经过评审并形成了基线;n 对已经形成基线的软件需求的变更进行了处理;n 形
9、成基线的软件说明书已经经过客户批准;n 验收标准已经完成;n 所有评审的问题都已经解决。输出:n 经过批准并形成基线的软件需求规格说明书;n 对受影响组件的重新估算文档;n 验收测试标准和测试计划。过程描述:这个过程主要处理以下两种活动:需求说明和需求管理。需求说明指的是需求过程中形成基线的主体,它是以后进一步的设计和测试的基础。另外,在软件开发过程中,会经常遇到由于客户又有新需求或开发组自身对项目有了更清楚的理解或认识,要对需求进行变更。在对最初的需求说明书进行变更时,要用到需求管理过程。(1)需求说明需求说明过程主要包括以下任务:n 执行需求分析n 定义需求规格说明书n 定义验收标准n 评
10、审说明书和验收标准。执行需求分析分析收集到的需求和在提案中可用的需求。这个任务要求需求说明书应该在完整性、一致性、清晰性和可测试性上达到比较合理的程序。定义需求说明书基于对需求的分析编写软件需求规格说明书。这个文档应清晰记录以下内容:n 目标和范围;n 功能需求;n 用户接口;n 输入输出;n 模块之间的接口;n 性能需求;n 特殊用户需求。如果需求不清晰或模糊,就需要准备原型,通过评估原型来产生需求说明书。定义验收标准基于对以前步骤收集的需求规格说明书,建立测试标准,验证的解决方案。所有的需求应该可制定测试标准。这个测试标准将成为客户批准最终产品的依据,因此要求在制定客户标准时要经常紧密的与
11、客户进行交流沟通。评审需求分析说明书和测试标准因为是开发项目的基础,所以需求规格说明书和验收标准需要由项目组的同级人员进行评审。(2)需求管理需求管理过程包括以下6个任务:n 记录变更请求;n 分析受到影响的组件;n 估算需求变更成本;n 重新估算所有产品的交付日期和时间;n 评审受影响组件;n 获得客户的批准。记录变更请求;形成基线的需求说明书的变更可能是由客户提出的,也可能是由于设计或编码阶段开发人员根据一些限制或优化而提出的。所有需求变更必须经过客户的批准,并且必须是可行的。任务需求变更可以由组织自己定义开始时间,并且所有需求变更需要记录到变更登记表中。分析受到影响的组件;任何经过批准的
12、变更需要在整个项目组范围内进行受影响组件分析。估算需求变更成本;项目成本与需求变更有关。任何规模的变更对于成本来讲都是一种损耗。如果一个受影响组件是非常重要的,那么可行性需要重新进行成本估算。重新估算所有产品的交付日期和时间;如果没有考虑有效的缓冲,成本的变化可能会影响整个项目的交付时间。在交付时间内的任何实质的变更都需要再同用户商议决定。评审受影响组件;在这个步骤中所有相关的受影响组件需要进行评审,项目负责人根执行此项任务。获得客户的批准。这个过程的最后一项任务是获得客户的签字。客户应该同意已经形成基线的软件需求说明书、验收标准和已记录的受影响组件的变更。验证:n 项目经理要定期的检查需求规
13、格说明书和项目需求管理的各个方面;n 软件质量保证人员要定期的对需求分析过程执行独立的评估。配置控制:n 软件需求规格说明书需要严格的配置控制;n 所有的变更请求需要被管理和控制;n 用于跟踪的度量文档需要管理和控制。QA检查清单:质量保证检查清单包括:n 软件需求规格说明书;n 变更需求跟踪记录;n 验收测试标准与测试计划。该阶段要确保客户提出的需求是可行的,确保客户了解自己提出的需求的含义,并且这个需求能够真正达到他们的目标,确保开发人员和客户对于需求没有误解或误会,确保按照需求实现的软件系统能够满足客户提出的需求。3. 设计阶段目的和范围:本过程所关注的是把需求(用户需求说明书和软件需求
14、规格说明书)转变成为如何实现这些需求的描述。主要包括以下两个阶段:n 概要设计;n 详细设计。软件设计过程主要包括以下活动:n 体系结构设计;n 运算方法设计;n 类/函数/数据结构设计;n 建立测试标准。进入标准:n 产品需求已经形成了基线;n 需要设计解决方案;n 新的或修改的需求需要改变当前的设计。输入:n 形成基线的需求(用户需求说明书和软件需求规格说明书)。退出标准:n 设计文档已经评审并形成基线;n 测试标准、测试计划可行。输出:n 概要设计文档;n 详细设计文档;n 测试计划;n 项目标准;n 选择的工具。过程描述:设计过程包括概要设计和详细设计两个阶段。(1)概要设计这个阶段包
15、括以下的任务:结构设计、逻辑设计、项目标准定义、系统/集成测试计划的创建,并要进行同级评审。概要设计模板、系统/集成测试计划模板在本阶段将被使用。结构设计在这个步骤中,完成软件解决方案的基础布局设计。继软件布局设计之后,应用程序被分解成基础模块/组件,目的是为了实现在模块内的高聚合和模块之间的松耦合。通常情况下,模块的划分是基于概要设计中的功能需求而定的。运算方法设计在这个步骤中,完成软件系统解决方案与应用程序的转换逻辑设计。设计模块接口和应用需求的主要逻辑。在决定通用算法之前,通常需要一些模型。定义项目标准在这个步骤中,所有的项目开发标准被定义。详细设计/编码标准要同实际执行的一致。制定标准
16、时还要考虑标准将来的扩展性、灵活性和方便性。创建系统/集成测试计划基于对概要设计的理解,系统和集成测试计划被制定出来。验证最后生产的产品达到了设计要求,通常采用基于黑盒的功能或性能检查。评审设计作为所有开发阶段基础的概要设计是非常重要的,因此需要进行同级评审,由能力强的高级软件工程师组成的同级评审小组,以确保完成了合适的软件解决方案设计。(2)详细设计这个阶段包括以下任务:详细设计和准备单元测试计划。在这个阶段,需要使用详细设计模板和单元测试计划模板。类/函数/数据结构设计根据项目所采用的设计方法(软件结构化设计方法/面向对象设计方法)进行类、函数及数据结构的设计。所有的用户界面、状态转换和相
17、关的数据库详细描述在本阶段被建立。创建单元测试计划测试计划应该包括要被测试的每一个模块的每一个元素,例如:n 与需求的完整一致性;n 与其它元素的一致性;n 在性能上的要求。单元/功能测试采用完全透明的白盒/玻璃盒测试方法,对于测试者来讲,实际运行的代码是可见的。评审详细设计详细设计阶段的输出是代码编写工作的基础,是非常重要的,因此需要在项目组中很好的进行评审。评审小组负责评审和清除那些在详细设计中与采用的方法不一致的问题。(3)选择有用工具在详细设计完成之后,系统在解决方案已经非常清晰。这时,项目组需要选择用来提高软件质量的工具。这些工具要产生以下作用:n 提高质量;n 提高生产力;n 缩短
18、开发周期。验证:n 项目管理者分析概要设计满足需求的程序;n 项目管理者不定时的监督详细设计说明书的创建工作;n 项目管理者通过定期的分析在设计阶段收集的数据来验证设计过程执行的有效性;n 质量保证(QA)人员通过验证产生的工作产品和做独立的抽样检查来验证产品的有效性;n 质量保证(QA)人员通过分析项目的度量数据和对过程的走查来验证设计过程的效性。配置控制:n 所有的概要设计文档、详细设计文档和系统/集成测试计划需要进行严格的配置控制;n 跟踪的度量数据需要进行管理和控制。质量保证(QA)检查清单:质量保证(QA)检查清单包括:n 概要设计文档;n 详细设计文档;n 测试计划(系统/集成/单
19、元);n 项目标准。在概要设计阶段,要确保规格定义能够完全符合、支持和覆盖前面描述的系统需求;可以采用建立需求跟踪文档和需求实现矩阵的方式,确保规格定义满足系统需求的性能、可维护性、灵活性的要求;确保规格定义是可以测试的,并且建立了测试策略;确保建立了可行的、包含评审活动的开发进度表;确保建立了正式的变更控制流程。在详细设计阶段,要确保建立了设计标准,并且按照该标准进行设计;确保设计变更被正确跟踪、控制、文档化;确保按照计划进行设计评审;确保设计按照评审准则评审通过并被正式批准之前,没有开始正式编码。4. 编码阶段目的和范围:编码过程的目的是为了实现详细设计中各个模块的功能,能够使用户要求的实
20、际业务流程通过代码的方式被计算机识别并转化为计算机程序。编码过程就是用具体的数据结构来定义对象的属性,用具体的语言来实现业务流程所表示的算法。在对象设计阶段形成的对象类和关系最后被转换成特定的程序设计语言、数据库或者硬件的实现。进入标准:n 设计文档已经形成基线;n 详细设计变更编写完毕并通过评审,并且代码需要变更时;n 对于维护项目,维护需求分析已经形成基线,可进行代码的变更;n 用于编码的测试标准已经制定。输入:n 详细设计文档;n 特定项目的编码规范;n 相关的软、硬件环境;n 维护分析文档;n 测试计划。退出标准:详细设计中所有模块的功能全部被实现,并通过自我代码审查,编译通过。输出:
21、n 已完成的、需要进行测试的代码;n 代码编写规范的更改建议。过程描述:编码过程是把详细设计中的各个模块功能转化为计算机可识别代码的过程,因此程序员在进行编码时,一定要仔细认真,切勿有半点疏忽。编码过程通常情况下占整个项目开发时间的20%左右,为了代码达到高质量、高标准,代码编写过程一定要合理规范。编码过程主要包括以下几项活动:n 制定编码计划;n 认真阅读开发规范;n 编码准备;n 专家指导,并填写疑问或问题表;n 理解详细设计书;n 编写代码;n 自我审查;n 提交代码;n 更改代码。编码过程流程如下图所示。(1)制定编码计划在编码之前一周,项目经理要根据详细设计中的模块划分情况制定编码计
22、划。编码计划的主要内容如下。本次编码的目的在制定编码计划时,必须要明确编码目的。编码人员组成在编码之前,要确定本次编码的人员组成:选择编码人员时要考虑以下几点:责任心、技术能力、服从意识、努力程序、编码效率、编码质量。编码任务分配在编码之前,一定要为每个编码人员划分好自己所负责的模块,并且要规定各个模块的编码开始,结束日期。(2)认真阅读开发规范为了实现编码的规范统一,需要制定编码规范。有的项目,客户也会提供一些开发规范用来对本次编码进行约束。编码人员在编写代码之前一定要理解并掌握相关编码规范的所有内容。这样有助于以后编码工作的规范统一。如果本次编码采用的是公司自己的开发规范,编码人员在阅读的
23、过程中,如果发现编码规范有不足或不合理之处,可以编写开发规范建议书提交给项目经理,项目经理再和软件质量保证人员取得联系以决定是否要对目前的编码规范进行更改。(3)编码准备在进行编码之前还要进行一些相关的准备。软硬件环境配置:包括编码工具、配置管理工具、数据库和一些必要的辅助工具。了解程序设计语言的特性,选择良好的程序设计风格:程序设计风格是程序设计质量的一个重要方面,具有好的设计风格的程序更容易阅读和理解。(4)理解详细设计书由于项目模块功能的复杂性,即使再详细的设计也会有表达不够准确之处,因此在编写代码之前,一定要把每个模块的详细设计思路弄清楚。如果编码人员在理解详细设计时有疑惑,一定要询问
24、详细设计人员。为了保证编码人员对详细设计的理解的正确性,采用以下方法:详细设计同级评审时,让编码人员参加;让编码人员对详细设计进行讲解;让编码人员根据自己的理解画出流程图,由详细设计者确认。如果编码人员在理解详细设计书的过程中存在疑问,应填写详细设计疑问列表提交给项目经理或详细设计人员。(5)专家指导在编码之前或编码过程中,为了保证编码工作的顺利进行以及代码质量,项目经理要根据目前编码人员的技术能力或开发进度情况邀请本项目组内部或外部专家对编码人员进行指导。指导的内容主要包括以下两方面的内容。对于本次编码有关的业务进行指导:对编码人员进行业务上的指导,有助于编码人员对详细设计的理解。对技术进行
25、指导:通过对编码人员的技术指导,可以解答编码人员在技术上的一些疑问。(6)编写代码在很多的软件开发中,客户为了便于程序的可维护性,往往会对程序代码编写过程做出一些规定,如变量的命名规则、书写规范和公共处理等,所以这就要求编码人员要熟悉这些要求和规范,并严格的遵守这些规范,如果客户没有规定,就要按照公司的规定执行。画出程序的流程图程序的流程图又称程序框图,用来描述软件设计,是历史最长、使用最广泛的方法。在编码之前,一定要先画好程序的流程图,这对一个复杂的程序来说是非常必要的,这样做了以后,可以使你在编码阶段达到事半功倍的效果,而且对于代码的正确性和质量都是一个很好的保证。代码的模块化模块化是把系
26、统分割成能完成独立功能的模块代码,明确规定各个模块代码及其输入输出规格,使模块代码的接口不会产生混乱。程序的注解程序的注解对于程序的阅读与理解起着重要的作用。注解主要分两部分。程序块头的注解,主要是模块功能的说明、输入输出变量的说明、算法的说明、程序员姓名和程序完成以及变更的日期列表。这些主要是满足管理者的需要,管理者易于掌握哪些程序是由哪个编码人员负责的。程序内部的注解,对程序中的一些难以理解的语句以上注释,以使阅读者容易理解设计者的意图,易于理解程序。这样的程序具有很强的可读性和可维护性。数据类型/变量说明n 数据说明的次序应标准化,如按数据类型或者数据结构来确定数据说明的次序,次序的规则
27、在数据字典中加以说明,以便在测试调试阶段和维护阶段可以方便的查找数据说明的情况;n 当对在同一个语句中的多个变量加以说明时,应按英文字母的顺序排列;n 在使用一个复杂的数据结构时,最好加注释语句;n 变量说明不要遗漏,变量的类型、长度、存储及其初始化要正确。语句构造n 不要为了节省空间把多个语句写在同一行;n 尽量避免复杂的条件;n 对于多分支语句,应该把出现可能性大的情况放在前面,把较少出现的分支放在后面,这样可以加快运算时间;n 避免大量使用循环嵌套语句和条件嵌套语句;n 利用括号使逻辑表达式或算术表达式的运算次序清晰直观;n 每个循环要有终止条件,不要出现死循环,也要避免不可能被执行的循
28、环。程序效率程序效率主要指处理工作时间和内存容量这两方面的利用率,在程序满足了正确性、可理解性、可测试性和可维护性的基础上,提高程序的效率也是非常必要的。在编码过程中,一定要严格按照规定的开发规范进行编码,如果没有按照编码规范进行编码,再好的程序代码也不能被接受。另外,在编写代码时,如果认为开发规范有不合理或有待补充之处,应该填写开发规范建议书提交给项目经理;如果发现详细设计中有问题或对详细设计产生疑问,应该填写详细设计疑问列表并提交给项目经理。(7)代码审查在编码过程中,每个模块或程序的自我审查的关键环节是绝对不能缺少的。无论多么好的编码人员编写的代码,都会或多或少的存在缺陷,从而影响程序的
29、运行。有的缺陷可以在很短的时间内暴露出来;有的缺陷需要很长的时间才能显现出来。因此在代码审查过程中,一定要仔细认真,不要遗漏某个条件。编码人员切勿对自己编写的代码过于自信而不去自我审查。在进行代码审查过程中,并不是盲目地进行审查。而是要按照代码审查列表中的内容进行审查。审查之后还要把自己审查的内容以及发现的问题记录到代码审查记录中。代码审查记录不作为考核个人的依据。通过代码审查记录,管理人员可以掌握每个编码人员的代码审查工作情况以及自我审查的质量效率。如果是比较重要的代码(如重要的算法、复杂的SQL程序段、要求性能比较高的模块等),可以让经验丰富的设计人员或编码人员来复查或进行同级评审。(8)
30、代码测试为了进一步保证代码的正确性和合理性,编码人员还要对自己编写的代码进行测试。代码测试的依据是详细设计过程中的单元测试计划书。编码人员按照测试计划书中所提供的每个测试项目的测试用例进行测试。本次测试只是编码人员对自己所编写的代码进行自我测试,测试主要采用白盒与黑盒结合的方法。在代码测试过程中,应该填写代码测试记录。(9)提交测试编码人员对自己编写的代码审查完毕,并认为代码不会有任何问题,就可以把代码提交给相应的测试人员。在提交代码时一定要注意自己所提交的代码是最新的版本。(10)更改代码更改代码的情况可以分为两种:在测试中发现代码有误或者逻辑不合理。出现这种情况的主要原因可能有两种:一是编
31、码人员本身的错误而造成的缺陷;二是在需求、设计阶段的错误没有被查出,被带到编码阶段而造成的缺陷。由于需求和设计的变更引起的代码变更。在变更代码的过程中一定要注意对代码的版本管理。验证:n 验证编码的规范性;n 验证是否进行了自我审查;n 验证代码的一致性和可跟踪性;n 通过测试验证代码的正确、合理性;n 验证每个编码人员的工作能力。配置控制:n 通过相应的配置管理工具对不同版本的代码进行管理;n 对编码规范进行管理;n 对项目开发质量计划进行管理。QA检查清单:n 编码计划;n 开发规范建议书;n 详细设计疑问列表;n 代码审查检查列表;n 代码审查记录;n 代码测试记录。该阶段要确保建立了编
32、码规范、文档格式标准,并且按照该标准进行编码;确保代码被正确地测试和集成,代码的修改符合变更控制和版本控制流程;确保按照进度计划编写代码;确保按照进度计划进行代码评审。5. 测试阶段目的和范围:软件测试过程的目的是为了保证软件产品的正确性、完整性和一致性,保证提供实现用户需求的高质量、高性能的软件产品,从而提高用户对软件产品的满意程序。在软件投入运行前,要对软件需求分析、设计和编码各阶段的产品进行最终检查和检测,软件测试是对软件产品内容和程序执行状况的检测以及调整、修正的一个过程。这种以检查软件产品内容和功能特性为核心的测试,是软件质量保证的关键步骤,也是成功实现软件开发目标的重要保障。软件测
33、试包括:单元测试、集成测试、系统测试、确认/验收测试。进入标准:n 经过自我检查过的程序代码需要进行测试;n 测试环境搭建完成;n 测试计划完成。输入:n 需要测试的程序代码;n 测试工具;n 测试环境;n 测试计划;n 测试用例;n 测试数据;n 测试检查列表;n 以往的经验与教训。退出标准:n 按照测试计划,所有的测试用例都成功地被执行了;n 测试过的代码形成基线。输出:n 测试记录;n 缺陷统计表;n 已经测试过的代码。过程描述:软件测试是软件质量保证的关键元素,代表了规约、设计和编码的最终检查。软件测试针对不同的测试阶段和测试内容,可以分为单元测试、集成测试、系统测试以及确认/验收测试
34、,在编码阶段进行单元测试,单元测试的目的是测试单一的功能模块能否正常运行;集成测试主要是根据设计阶段制定的测试计划进行,集成测试是测试模块与模块之间的连接是否正确;系统测试主要是对系统的整体质量进行测试;确认/验收测试根据需求分析阶段制定的测试计划进行测试,是测试整个软件产品是否满足了用户的需求。不同阶段所使用的测试用例也是不同的。根据软件开发过程的特点。通常情况下单元测试和集成测试使用白盒测试方法;系统测试和确认/验收测试采用黑盒测试方法。软件测试的目的主要是为了验证(Verification)和确认(Validation)软件的正确性。验证是以开发者的角度来考虑的,是为了验证软件是否满足用
35、户的需求;而确认是以用户的角度考虑的,验证软件的方便性、友好性、容错性等。随着软件测试各个阶段的不断进行,验证的成分越来越少,白盒测试方法所占的比例就会越来越小;确认的成分越来越多,黑盒测试的比例就会越来越大。(1)单元测试单元测试集中在检查软件设计的最小单位模块上,通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况,以及编码的缺陷。由于模块规模小、功能单一、逻辑简单,测试人员有可能通过模块说明书和源程序,清楚地了解该模块的I/O条件和模块的逻辑结构,采用结构测试(白盒法)的用例,尽可能达到彻底测试,然后辅之以功能测试(黑盒法)的用例,使之对任何合理和不合理的输入都能鉴别和响应
36、。高可靠性的模块是组成可靠系统的坚实基础。(2)集成测试将已测试的模块进行组装并进行检测,对照软件设计测试和排除子系统或系统结构上的缺陷。集成测试一般采用黑盒测试法,重点是检测模块接口之间的连接,发现访问公共数据结构可能引起的模块间的干扰,以及全局数据结构的不一致,测试软件系统或子系统输入输出处理、故障处理和容错等方面的能力。(3)系统测试检测软件系统运行时与其他相关要素(硬件、数据库及操作人员等)的协调工作情况是否满足要求,包括性能测试、恢复测试和安全测试等内容。n 性能测试:程序的响应时间、处理速度、精确范围、存储要求以及负荷等性能的满足情况。n 恢复测试:系统在软硬件发生故障后,控制并保
37、存数据以及进行自动恢复的能力。n 安全测试:检查系统对用户使用权限进行管理、控制和监督以防非法进入、篡改、窃取和破坏等行为的能力。系统测试通常是由系统工程组负责进行的,如果小的项目没有系统工程组,那么建议系统测试合并到确认/验收测试中。(4)确认/验收测试确认/验收测试是指按规定需求,逐项进行有效性测试。以检验软件的功能和性能及其他特性是否与用户的要求相一致,一般采用黑盒测试法。确认测试的基本事项如下:n 功能确认:以用户需求规格说明书为依据,检测系统满足需求所规定功能的实现情况。n 配置确认:检查系统资源和设备的协调情况,确保开发软件的所有文档资料编写齐全,能够支持软件运行后的维护工作。文档
38、资料包括:设计文档、源程序、测试文档、用户文档。确认/验收测试包括以下两方面:n 仿真用户确认测试:测试人员假冒用户的身份进行测试。n 用户确认测试。验证:n 验证测试人员是否按测试计划执行测试;n 验证测试人员的测试能力;n 验证各个阶段缺陷的严重程序。配置控制:n 对各种测试记录进行管理条例;n 对测试后的代码进行管理。QA检查清单:n 软件测试计划n 测试记录n 缺陷统计表。该阶段要确保建立了测试计划,并按照测试计划进行了测试;确保测试计划覆盖了所有的系统规格定义和系统需求;确保经过测试和调试,软件仍旧符合系统规格和需求定义。6. 系统交付和安装阶段目的和范围:在系统交付阶段,要将开发并
39、且通过测试的软件应用系统和相关文档交付给用户。本过程的目的是确保正确的元素/组件被交付给用户,并对每个交付产品做适当的记录。进入标准:n 软件已经经过了系统测试,达到了用户所提的要求;n 各种手册已经书写完毕,准备交付。输入:n 测试通过的、需要被安装的应用系统;n 软件用户使用手册;n 软件维护技术手册。退出标准:n 用户接受了被交付的系统。输出:n 被批准的软件交付及培训计划;n 安装后的软件n 用户签字后的用户验收确认单。过程描述:n 制订软件交付及培训计划;n 制订软件维护计划;n 交付给用户所有的文档;n 交付、安装软件系统;n 评审批准软件维护计划;n 用户验收确认。验证:n 项目经理定期或事件驱动地评审交付产品的配置管理活动;n 质量保证组评审和审计交付产品的配置管理过程。配置控制:n 产品或系统组件的交付信息包被项目组配置。QA检查清单:n 说明书检查;n 程序检查。该阶段要确保按照软件交付计划交付、安装软件系统,并按照培训计划对用户进行培训;确保交付给用户所有的文档;制订并评审、批准了软件维护计划;用户进行了验收确认。