测试流程及规范.doc

1目的
侧重测试工作流程及规范的控制，明确产品研发的各阶段测试组应完成的工作。

测试技术和策略等问题不在本文档描述范围内。

本规范作为所有测试组成员工作前必须掌握的工作规范，也供给其它部门其它组查阅参考，以便于组间的协调沟通，更好的合作完成产品的研发工作。

2概念与术语
在整个产品的研发过程中，测试类型按照先后顺序主要分为：单元测试、集成测试、系统测试及产品确认，整个过程如下面的W模型所示：
图1
有关的测试类型的概念如下：
1）单元测试：验证产品中的模块，测试依据主要为模块详细设计或模块的需求规格。

能使问题及早暴露，也便于问题的定位解决，单元测试属于早期测试，因而错误发现后能明确知道是某一单元产生的，单元测试允许多个被测单元的测试工作同时开展。

根据公司研发流程的实际情况，此测试也可由设计研发人员执行。

2）集成测试是验证模块间接口及匹配关系，测试依据主要为概要设计。

一般采用自底向上或自顶向下的模块集成方法，逐步集成。

在此环节中测试组还负责验收研发人员提供的转测试的材料，如果材料不完备，测试组可以拒绝接收。

3）系统测试是对系统的一系列的整体、有效性、可靠性的测试，测试依据主要为设计规格及产品需求规格。

目的是确认产品与设计规格、需求、行业标准及公司标准的符合性，同时还要确认性能和系统的
稳定性，与之前的集成测试应遵循“相同的被测对象不要做两遍相同的测试”的基本原则。

4）除单元测试、集成测试和系统测试之外，还应有“产品确认”环节，即在客户环境中或模拟客户环境测试与验证产品，在有限的试用客户中或模拟客户环境中发现产品问题并加以妥善处理，保证产品质量，提高客户满意度。

确认与实验室内部测试的区别在于：实验室内部测试要尽可能多做，多发现问题；确认要在达到质量目标的情况下尽可能少做；两者要在质量和成本之间权衡、综合考虑。

5）TD：全称Mercury TestDirector，一种测试管理工具。

6）黑盒测试：黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。

在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。

黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。

3职责
【注】：当某个项目仅有一个测试人员时，该测试人员同时也为该项目内的测试主管，需要担负起测试主管的职责。

4测试类型和测试方法
4.1测试类型
测试工作通常分为4个类型，功能测试、联合测试、性能测试及稳定性测试。

4.2测试方法
【注】：黑盒测试过程的参考准则：
（1）必须采用边界值分析法；
（2）必要时采用等价类划分法补充测试用例；
（3）采用错误判断法，追加测试用例；
（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。

如果没有达到要求的覆盖标准，应当补充更多的测试用例；
（5）测试数据应准备充分，应采用有效数据、无效数据、边界数据分别测试验证；
5工作流程、模式及规范
5.1测试提交文件及裁剪说明
5.2评审点
评审点定义参照《设计开发控制程序》。

5.3敏捷测试模式
5.3.1敏捷测试概念
敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。

5.3.2敏捷增量测试方法
测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。

整个产品的敏捷开发生命周期可以分为 4 个阶段，即初始阶段，项目的建设阶段，产品发布阶段和产品的维护阶段，在关键的项目建设阶段中，测试被分成两个部分，验证测试和系统测试。

验证测试：静态测试和关键的功能测试。

系统测试：功能测试、联合测试、性能测试、稳定性测试。

5.3.3敏捷测试流程
敏捷测试流程依据业务场景制定测试策略。

在每次敏捷测试的过程中包括验证测试和联合测试。

并且不断的进行迭代测试。

在系统的所有业务场景都经过敏捷测试过后，进入系统测试阶段。

进行所有业务场景的功能测试、联合测试、性能测试、稳定性测试。

根据业务场景制定测试策略流程图
产品
业务场景一 业务场景二 。

业务场景N
模块一 模块二 模块三 。

模块N
模块四 业务场景一
缺陷管理 业务场景三 业务场景二 业务场景N 业务场景四
敏捷测试流程图
根据缺陷性质来判断更新提交测试的依据：
1）严重级别为Urgent和High的修改后立即更新，要保证更新后不能影响其他功能测试。

2）功能级别为Medium以下的可以等待下一次提交敏捷测试的时候更新。

5.4传统瀑布模式
5.4.1测试需求分析
5.4.2成立测试小组或确认测试人员
5.4.3编制测试计划
5.4.4编制测试大纲、设计测试用例
在技术规格书评审通过以后，测试小组需要针对项目的测试范围编制测试大纲、设计测试用例。

在实际测试过程中，测试用例可根据实际需要进行更新和调整。

在测试用例的设计过程中，具体的任务和责任人如下：
5.5测试实施阶段
5.5.1测试准入检查
5.5.2执行测试用例
5.5.3回归测试
在每轮测试结束之后，当研发人员解决完相关问题，重新提交，进行回归测试。

5.5.4缺陷管理
5.6测试收尾阶段
测试实施阶段结束或即将结束时，测试小组可以开始着手准备进行总结报告及收尾工作。

5.6.1编制测试报告
在测试实施完成之后，测试主管或测试人员需根据实施测试情况，编制测试报告。

5.6.2测试工作过程改进
测试过程改进在测试实施阶段工作全部结束以后进行。

它的目的是评估本次测试工作，总结经验，使下一次的工作做得更好。

本项工作不是一个必须的过程，各项目可根据情况采用。

5.6.3测试成果提交
测试资产提交在测试实施阶段工作结束以后进行，对测试过程中涉及到各种标准文档进行归类，存档。

5.7软件测试执行模式
目前采用3+1模式。

即三轮系统测试加一轮回归测试。

6缺陷管理机制
缺陷通过测试管理工具TD进行管理
测试团队
研发团队
缺陷的严重级别以及如何分类
7新产品测试流程
7.1新产品测试输入输出
7.2新产品测试流程图
8生产缺陷测试流程
8.1生产缺陷测试输入和输出
8.2生产缺陷测试流程图
9新增和修改需求测试流程
9.1新增和修改需求测试输入和输出
9.2新增和修改需求测试流程图
10发布评估标准
检验合格依据:
➢遗留问题中不能有Urgent、High级别的问题；
➢遗留问题中Medium级别的问题数要小于等于8，并且经过研发、测试及产品经理讨论一致同意。

➢软件达到设计的性能指标。

➢软件稳定性测试通过，没有不稳定现象。

➢联合测试通过，无Bug。

满足以上五点，视为产品检验合格。

如果产品不满足上述五点，但还需要发布，则应当征得软件总监的同意。

11问题处理
如研发团队对测试结论有争议，应通过评审解决。

12相关文件
《设计开发控制程序》
《设计更改控制程序》
《研发评审规定》
《研发测试规定》
13相关记录
《测试计划》
《测试大纲》
《测试用例》
《测试记录》
《测试报告》
《缺陷跟踪报告》
《评审记录》
《评审报告》
文件修订信息页。