1 目的

确保软件产品的质量，使系统能够达到规定的功能要求、性能要求等，确保系统在要求的硬件和软件平台上工作正常，保证软件产品能够顺利通过验收、符合用户要求。

2 适用范围

本文件适用于项目开发过程中的单元测试、集成测试、系统测试、客户验收测试及其它一些专项测试等。

3职责

测试负责人:参与项目实施各阶段工作产品的评审，编写《测试计划》、各类《测试方案》和组织编写《测试用例》，组织执行测试，收集、汇总测试记录和缺陷记录。组织评审《测试用例》测试方案》。编写各类《测试总结报告》，与测试管理员共同字，确认各阶段的测试结果，对产品质量负责;

测试管理员:来自公司测试部(组)，协助项目组制定适合项目实际情况的测试方法和过程，参与项目的测试计划、测试方案、用例的编写和评审，测试实施，测试总结，负责测试过程中数据的收集统计和分析，积累测试过程的经验和方法，与测试负责人共同签字，确认各阶段的测试结果，对测试过程负责:

测试人员:按《测试方案》的各项要求编写《测试用例》、执行测试，同步填写《测试过程记录》和《测试缺陷记录》，帮助构建人员定位缺陷，验证缺陷的修复;

集成负责人:组织集成人员编写集成测试阶段的《测试方案》和《测试用例》，进行集成测试，编写《测试总结报告》:

集成人员:参与编写集成测试阶段的《测试方案》和《测试用例》，与项目技术负责人、SCM配合将系统各模块集成为系统(子系统)，在此基础上进行集成测试:

技术专家:参与《测试方案》和《测试用例》的评审:

SCCB:对测试中发现的问题所引起的基线库中配置项的更改进行审批;

项目负责人:协助组织、参与对《测试方案》和《测试用例》的评审

4 各阶段测试活动

5 流程

各阶段测试流程如下:

6 流程描述

6.1制定测试计划

测试负责人在计划(初定)阶段开始与项目负责人协商制定《测试计划》的草案。测试计划的内容应包括测试前提、测试目标、测试优先级和重点、测试范围和限制等内容。

在计划(确定)阶段应完成《测试计划》，随《项目总体计划》一同评审，具体评审过程参见《评审过程指导》:

6.2测试设计

6.2.1 编制《测试方案》

测试负责人根据《测试计划》的要求，编写完成《测试方案》。

6.2.2 评审《测试方案》

为了保证《测试方案》的正确性、完整性和清晰性，测试管理员在测试工作开始前首先组织项目组内部对《测试方案》进行讨论确认，然后组织相关人员对《测试方案》进行评审。

《测试方案》需通过需求、设计、构建、集成、测试各小组负责人共同评审、评审通过后方可进行测试工作。具体评审过程参见《评审过程指导》。

6.2.3 编制《测试用例》

每个阶段完成测试用例的同时需维护《测试用例汇总表》，还要对前一阶段的测试用例进行补充和维护，以达到测试用例在多个阶段复用的目的。测试用例编写参见《测试用例编写说明》:

6.2.4 评审《测试用例》

《测试用例》需通过需求、设计、构建、集成、测试各小组负责人共同评审、评审通过后方可进行测试工作。具体评审过程参见《评审过程指导》。

6.3建立测试环境并进行测试环境的确认

测试负责人组织测试小组成员按照《测试方案》的要求建立起测试环境准备进行测试;

确认测试环境并填写《测试环境确认表》:

6.4进行测试

测试根据测试目的和阶段可分为单元测试、集成测试、系统测试和客户验收测试，同时在这些测试过程中，因为测试重点不同还会包括相应的专项测试(功能测试、压力测试、界面测试、边界测试、兼容性测试等)。对于不同的项目而言，项目所经历的测试阶段或形式不同，在项目计划阶段时根据具体情况明确。

6.4.1 单元测试

单元测试也叫模块测试，针对软件设计的最小单位一程序模块进行正确性检验的测试工作。目的在于发现各模块内部可能存在的各种差错，多个模块可以平行的独立进行单元测试。单元测试时测试者需要依据详细设计说明书和源程序清单，了解模块的I/0条件和逻辑结构，一般采用白盒测试法，要求对所有的局部和全局的数据结构、外部接口和程序代码关键部分都要进行测试。

单元测试需在五个方面对所测模块进行检查:

1、模块接口测试:首先应对通过所测模块的数据流进行测试。对模块接口可能需要如下的测试项目:调用所测模块时的输入参数与形式参数在个数、属性、顺序上是否匹配:全局量的定义在各模块中是否一致:块通过外部设备的输入/输出操作。

2、局部数据结构测试:不正确和不一致的数据类型说明:使用尚未赋值或尚未初始化的变量;错误的初始值或错误的缺省值:变量名拼写错或书写错;不一致的数据类型等。

3、路径测试:对模块中重要的执行路径进行测试，查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。

4、错误处理测试:测试模块的错误处理部分，包括:出错的描述难以故障转移和恢复测试、配置测试、安装测试和系统的其它特性的测试。对以上特性的基本测试策略参见《测试参考文件》。

系统测试一般采用黑盒测试方法;

6.4.4 客户验收测试

客户验收测试的目的是为了确认在规定的使用环境下整个产品的运行情况是否满足规定的要求。

6.5客户验收测试一般由客户完成，通过测试后，需由客户签署《客户验收测试总结报告》。测试过程记录与缺陷处理

6.5.1 测试记录与总结

每阶段测试工作要保留测试记录，跟踪测试过程:测试人员在测试过程中同步填写《测试过程记录表》，对发现的缺陷填写《测试缺陷处理记录表》，提交测试负责人，填写《测试缺陷跟踪表》;在每一阶段测试结束后,测试负责人需要对测试过程进行总结，完成《测试总结报告》，提交项目负责人和项目控制主管:

6.5.2 测试缺陷分类描述

测试缺陷分为以下级别:

严重错误，可能导致本模块以及其它相关模块异常，死机等问题，如:由于程序所引起的死机,非法退出

死循环

数据库发生死锁

与数据库连接错误

重要错误，问题局限在本模块，导致模块功能失效或异常退出，如:数据库设计未达到第三范式的要求或需求规格说明的格式水平

功能错误

数据通讯错误

程序错误

因错误操作迫使程序中断

程序接口错误

数据库的表、业务规则、缺省值未加完整性等约束条件次要错误，模块部分功能失效，如:

操作界面错误(包括数据窗口内列名定义、含义是否一致)

打印内容、格式错误

简单的输入限制未放在前台进行控制

删除操作未给出提示

数据库表中有过多的空字段轻微问题，由问题提出人对测试对象的改进意见:

界面不规范

辅助说明描述不清楚

输入输出不规范

长操作未给用户提示

提示窗口文字未采用行业术语

可输入区域和只读区域没有明显的区分标志

6.5.3 测试缺陷处理流程

6.5.4 缺陷处理

测试人员填写《测试缺陷处理记录表》提交给测试负责人进行整理、汇总(过滤掉描述不清和重复的缺陷记录)，统一提交项目组。测试负责人对缺陷进行跟踪直至测试结束:

由技术负责人对提交的缺陷进行确认、分析、评估，指定缺陷处理人。如果缺陷引起已纳入基线的配置项变更，则转入变更流程，参见《变更过程指导》;

缺陷处理人对缺陷进行处理、修正，并自行验证，填写《测试缺陷处理记录表》。如果缺陷无法重现，则要在《测试缺陷处理记录表》中给出

相关说明:缺陷进行修正后，由测试人员做回归测试，以确认修改的正确性;缺陷发现、处理、验证等过程相关人员必须完整记录于《测试缺陷处理记录表》中;

对不确定原因，或是暂时不能修改的缺陷，应指出避免用户使用时发生此种错误的限制性条件:

如果缺陷影响测试工作的进展，需更新程序版本，立即对缺陷修复进行验证。如果缺陷不影响测试工作的进展，可以累积，提交下一轮测试进行验证。进入下一轮测试时，首先进行前一版本的回归测试，验证缺陷修复是否正确;复未能得到验证，则该缺陷报告将重新执行上述流程直至关闭;

6.5.5 回归测试

各阶段测试过程中都需要进行回归测试。在测试过程中，缺陷解决之后，应当对被修改的部分根据情况进行回归测试，以检查对该部分的修改是否正确，是否在其他部分引出新的问题。

每当被测试的软件和其环境改变时在每个合适的测试层次上进行回归测试;

• 上一篇：【软件工程】【CMMI】测试管理指南
• 下一篇：CMMI体系概述