测试过程规范

1目的

侧重测试工作流程及规范的J控制，明确产品研发口勺各阶段测试组应完毕的工作。测试技术和方略等问

题不在本文档描述范围内。

本规范作为所有测试组组员工作前必须掌握的I工作规范，乜供应其他部门其他组查阅参照，以便于组

间的协调沟通，更好的合作完毕产品的研发工作。

2概念与术语

在整个产品的研发过程中，测试类型按照先后次序重要分为：单元测试、集成测试、系统测试及产品

确认，整个过程如下面的w模型所示：

图I

有关口勺测试类型的概念如下：

1）单元测试：验证产品中的模块，测试根据重要为模块详细设计或模块H勺需求规格。能使问题及早

暴露，也便于问题的定位处理，的元测试属于初期测试，因而错误发现后能明确懂得是某一单元产生的，

单元测试容许多种被测单元的测试工作同步开展。根据企业研发流程的实际状况，此测试也可由设计研发

人员执行。

2）集成测试是验证模块间接口及匹配关系，测试根据重要为概要设计。一般采用自底向上或自顶向

下H勺模块集成措施，逐渐集成。在此环节中测试组还负责验收研发人员提供的转测试H勺材料，假如材料不

完备，测试组可以拒绝接受。

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

求规格。目的是确认产品与设计规格、需求、行业原则及企业原则的符合性，同步还要确认性能和系统的

稳定性，与之前的集成测试应遵照“相似U勺被测对象不要做两遍相似的测试”的基本原则。

4）除单元测试、集成测试和系统测试之外，还应有“产品确认”环节，即在客户环境中或模拟客户

环境测试与验证产品，在有限的试用客户中或模拟客户环境中发现产品问题并加以妥善处理，保证产品质

量，提高客户满意度。确认与试验室内部测试的区别在于：试验室内部测试要尽量多做，多发现问题；确

认要在到达质量目日勺H勺状况下尽量少做：两者要在质量和成本之间权衡、综合考虑。

5）TD：全称MercuryTeslDirector,一种测试管理工具。

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

把程序看作一种不能打开口勺黑盒子，在完全不考虑程序内部构造和内部特性口勺状况下，在程序接口进行

测试，它只检杳程序功能与否按照需求规定正常使用，程序与否能合适地接受输入数据而产生对口勺的输

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

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

3职责

角色名称有关重要责任

测试主管•组建测试小组

・协调测试小组内外部的沟通

•组织编制测试大纲（含测试用例）和计划

•组织测试准入检查

•测试过程中的进度控制、风险管理

•测试过程汇报

•编写测试汇报

•召集测试评审

测试人员•识别测试需求

•参与编制测试人纲（含测试用例）和计划

•协助测试准入检查

•执行测试用例，测试成果记录

•测试缺陷记录与跟踪

•协助测试评审

支持人员•为测试工作提供技术支持，例如环境安装、版本布署、测试工具支持等

备注：该角色可选，可根据项目实际状况设置，一般状况下由研发人员担任。

【注】：当某个项目仅有一种测试人员时，该测试人员同步也为该项目内的测试主管，需要肩负起测试主

管H勺职责。

4测试类型和测试措施

4.1测试类型

测试工作一般分为4个类型，功能测试、联合测试、性能测试及稳定性测试。

测试类型测试意义

功能测试•保证功能符合需求定义

•保证所有功能可以正常完毕工作

联合测试•一种新产品或一种产品的）新版本公布时，要保证与之相配合的产品可以正常配合

使用

性能测试•在产品有性能规定口勺部分，进行性能测试和调优，保证产品性能符合需求

稳定性测试・模拟顾客真正日勺使用状况，设计对应的测试用例，保证产品可以稳定可靠的长时

间运行

4.2测试措施

提交

项目组自

测试需求测试需求分析汇报否无特殊需求，可省略

定义

项目组自

测试大纲是各项目组根据测试任务H勺规模可自定义模板

定义

项目组自假如测拭大纲或设计开发计划中已包括了测试计

测试计划否

定义划的内容，则本文档可省略

测试计划

测试大纲计划评审记

否企业模板各项目酌情选用

录

测试用例是企业模板采用企业统一测试用例模板

测试用例评审记录否企业模板各项目酌情选用

测试准入检查表否企业模板各项目酌情选用

测试实行项目组自

测试记录是各项n组根据测试任务u勺规模可自定义模板

定义

测试汇报是企业模板采用企业统一测试汇报模板

测试汇报评审记录否企业模板各项目酌情选用

测试收尾

项目组自

测试工作改善汇报否各项目的情选用

定义

项目组自

测试成果提交否各项目酌情选用

定义

5.2评审点

评审点定义参照《设计开发控制程序》。

5.3敏捷测试模式

5.3.1敏捷测试概念

敏捷测试即是不停修正质量指标，对的建立测试方略，确认客户日勺有效需求得以圆满实现和保证整

个生产的I过程安全日勺、及时的J公布最终产品。

5.3.2敏捷增量测试措施

测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。整个产品的敏捷开发生命周期可以

分为4个阶段，即初始阶段，项目的建设阶段，产品公布阶段和产品的维护阶段，在关键的项目建设阶

段中，测试被提成两个部分，验证测试和系统测试。

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

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

5.3.3敏捷测试流程

敏捷测试流程根据业务场景制定测试方略。在每次敏捷测试的过程中包括验证测试和联合测试。并

且不停的J进行迭代测试。在系统内所有业务场景都通过敏捷测试过后，进入系统测试阶段。达行所有业务

场景的功能测试、联合测试、性能测试、稳定性测试。

根据业务场景制定测试方略流程图

敏捷测试流程图

根据缺陷性质来判断更新提交测试的根据：

1）严重级别为Urgent和HighH勺修改后立即更新，要保证更新后不能影响其他功能测试。

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

5.4老式瀑布模式

5.4.1测试需求分析

过程要点详细阐明

启动条件需求阶段的工作启动

工作内容由测试主管根据项目仃•务复杂程度组织或指定测试人员进行测试需求分析，从客户角度考虑软

件测试需要到达的验证状态，并确定与否要形成测试需求分析汇报

结束条件需求分析完毕

例外对于简朴设计更改、衍生产品等只需例行测试的，可不进行测试需求分析

负责人项目经理

参与人测试主管

5.4.2成立测试小组或确认测试人员

过程要点详细阐明

启动条件测试任务明确，前期工作启动

工作内容•确认项目的测试人员，若整个项目的测试需要若干个测试人员，则需要成立一种测试小组；

•为测试小组任命一名测试主管，若只有一种测试人员，则该测试人员同步也为该测试组的

测试主管，同步确定测试小组的其他构成人选；

•小组内进行必要的培训。

结束条件测试小构成立

例外•若此前的测试任务已成立过测试小组，则可以复用此前的组织人员和形式

负责人项目经理

参与人测试主管

5.4.3编制测试计划

过程要点详细阐明

项目阶段性计划确定

启动条件

需求规格阐明书、详细设计阐明书等已评审

测试大纲至少包括如下关键内容：

•测试目的一一对本次测试1向规定和要到达的目的

•测试范围一一需要测试小组测试日勺范围，和各个测试需求的J测试优先级

•工作分工一一明确测试小组内部及外部配合方的有关责任和工作关系

・测试方略一一整体测试的总体测试方略、环境、措施和工具等

•完毕原则一一到达何种条件可以认为测试完毕

工作内容

•交付文献一一测试完毕时应提交H勺文献，例如则试大纲（含测试用例）、测试汇报等等

测试计划至少应包括如下关键内容：

•重要任务一一每项任务的时间计划、前置条件及资源

•重要里程碑一一关键任务及完毕时间点

•在项目研发过程中，要适时的对测试计划进行跟踪，以评估此计划口勺完整性、可行性，在

项目结束时还要鼓终评估一下测试计划的质量

结束原则测试计划评审通过或得到有关各方日勺审批

输出文献测试计划、测试计划评审记录

•灼于多种系统参与的1同一种测试任务，可由主项目组或牵头方统一编制测试大纲和计划，

例外不用每个系统单独编制和出具

・测试计划可以在测试大纲中直接详细列明，而不用单独编制

负责人测试主管

参与人研发总监、项目经理、测试人员

5.4.4编制测试大纲、设计测试用例

在技术规格书评审通过后来，测试小组需要针对项目的测试范围编制测试大纲、设计测试用例。在实

际测试过程中，测试用例可根据实际需要进行更新和调整。在测试用例的设计过程中，详细的任务和负责

人如下:

过程要点详细阐明

启动条件本次测试范围、业务需求已经明确

需求规格阐明是、详细设计阐明书已通过评审

工作内容•准备本次测试H勺测试用例

•测试用例在该产品的测试用例库中进行选择，如有需要，可以进行增长；

•每个测试用例须包括用例编号、测试概述、测试数据、操作环节阐明、预期成果等要素；

•测试用例须覆盖所有的测试需求和功能点；

•采用统一欧1模板进行用例设计。

结束原则测试用例覆盖所有的待测试需求或功能点，并且评审通过

输出文献测试大纲、测试用例、测试大纲评审记录

负责人测试人员

参与人研发总监、研发人员、项目经理、测试主管

5.5测试实行阶段

5.5.1测试准入检查

过程要点详细描述

启动条件测试实行准备工作完毕

•测试主管根据本项目的特点，事先确定测试准入原则中哪些条目可以进行裁剪，并与项目

经理及研发人员商讨确认

•准入原则中“计划准入原则”是指编制测试计划、测试大纲、测试用例设计时就需要具有

口勺前提条件，应提前进行检查；”执行准入原则”是指在执行测试之前需要进行的检查。

工作内容

以上两类检查应分两次进行

•测试主管和测试人员根据测试准入原则，逐项进行检查，并填写测试准入检杳表

•对于不满足条件11勺检查项，规定有关方面进行处理.，处理后重新进行检查

•必须要通过R勺检查项，而没检查通过的1,视为准入检查不通过，不能进入下一•阶段工作

结束条件测试准入检查通过

输出文献测试准入检查表

负责人测试主管

参与人测试人员、项目经理、研发人员

5.5.2执行测试用例

过程要点详细描述

启动条件测试执行阶段准入检查通过

•测试人员根据计划，执行对应的测试用例，并做好测试记录

•测试人员进行缺陷登记，并跟踪处理状况，及时复测，关闭缺陷

工作内容•测试主管跟踪测试用例执行状况，理解影响测试用例执行的原因，及时跟进有关的协调、

汇报测试状态

•测试主管根据项目日勺状况，选择有关口勺汇报形式，将测试进展状况及时通报给有关各方

结束条件测试用例执行完毕

负责人测试人员、测试主管

参与人研发人员、项目经理

5.5.3回归测试

在每轮测试结束之后，当研发人员处理完有关问题，重新提交，进行回归测试。

过程要点详细描述

启动条件在每轮测试中，按既有的测试用例没有新的缺陷被发现，测试汇报中所有H勺活动缺陷都被处理

测试组将按照测试计划中对于回归测试的方略对产品进行回归测试，回归测试的用例属:测试

工作内容

用例的一部分或者是所有测试用例，但不能超过原先预定口勺测试用例的范围

结束条件回归测试所运行的用例所有通过

负责人测试人员

参与人研发人员、项目经理

5.5.4缺陷管理

过程要点详细描述

启动条件测试用例开始执行

工作内容•测试人员在测试过程中，记录被测产品缺陷，跟踪缺陷的分析、处理过程

•研发人员及时分析处理缺陷，并按规定记录缺陷的分析处理信息，更新缺陷状态，填制缺

陷来源；对需要其他人员参与分析处理的时候，需及时将缺陷分派给下一环节人员

•测试人员看待验证的缺陷需及时进行复测，测试通过后关闭缺陷

结束条件测试用例执行完毕，并且缺陷跟踪完毕

负责人测试人员、研发人员、测试主管

参与人项目经埋

5.6测试收尾阶段

测试实行阶段结束或即将结束时，测试小组可以开始着手准备进行总结汇报及收尾工作。

5.6.1编制测试汇报

在测试实行完毕之后，测试主管或测试人员需根据实行测试状况，编制测试汇报。

过程要点详细描述

启动条件测试小组完毕了所有的测试实行工作或测试时间已结束

工作内容测试主管或测试人员根据测试的成果，按照测试汇报的文档模板编写测试汇报，测试汇报必须

包括如下重要内容：

•测试用例执行状况分析一一测试阶段用例执行日勺数量、轮次、通过率等

•测试过程中已发现缺陷分析一一分析缺陷的数量、分布、来源等

•未执行用例的）风险分析一一分析未执行的J用例对系统形成的风险

•未关闭缺陷的风险分析一一分析未关闭的缺陷对系统形成的风险

•测试结论一一评价测试大纲中定义的测试完毕原则与否到达，被测系统的质量评价，存在

的风险，以及有关提议

结束条件测试汇报评审通过，发送给有关人员

输出文献测试汇报、测试汇报评审记录

负责人测试主管、测试人员

参与人研发总监、研发人员、项目经理

5.6.2测试工作过程改善

测试过程改善在测试实行阶段工作所有结束后来进行。它的目日勺是评估本次测试工作，总结经验，使

下一次的工作做得更好。本项工作不是一种必须的过程，各项目可根据状况采用。

过程要点详细描述

启动条件测试实行阶段结束

工作内容•测试主管召集测试参与人员，讨论本次测试过程得与失，总结经验，提出改善措施和意见

•编写测试工作过程改善汇报

结束条件测试工作过程改善汇报编制完毕

输出文献测试工作改善汇报

负责人测试主管

参与人测试人员

5.6.3测试成果提交

测试资产提交在测试实行阶段工作结束后来进行，对测试过程中波及到多种原则文档进行归类，存档。

过程要点详细描述

启动条件测试实行阶段结束

工作内容提交本次测试过程产生的，能为其他项目或本项目后续测试提供借鉴的，测试用例等

结束条件所有成果归档完毕

输出文献测试成果清单

例外假如成果内容不多，构造清晰，则可以省略测试成果清单

负责人测试主管

参与人测试人员

5.7软件测试执行模式

目前采用3+1模式。即三轮系统测试加一轮I可归测试。

6缺陷管理机制

缺陷通过测试管理工具TD进行管理

测试团体研发团体

缺陷的严重级别以及怎样分类

严重级别描述

5-Urgen(阻碍流程、系统瓦解导致重大任务不能正常进行H勺缺陷，例如：

1、由于程序所引起的死机,非法退出。

2、死循环

4-High1、数据库发生死锁

2、错误操作导致H勺程序中断

3、严重的计算错误

4、与数据库连接错误

5、数据通讯错误等

3-Medium缺陷导致失去系统重要功能，基本功能不能完整使用。例如：

1、功能不符

2、程序接口错误

3、数据流错误

4、轻微数据计算错误等

2-Low操作性错误、错误成果、遗漏功能等影响系统规定或基本功能日勺实现。例如：

1、界面错误

2、打印内容、格式错误

3、简朴的输入限制未放在前台进行控制

4、删除操作未给出提醒

5、数据输入没有边界值限定或不合理

6、错别字等

1-suggest提议，不影响使用的瑕疵或更好的实现等。

7新产品测试流程

7.1新产品测试输入输出

测试环节输入输出

测

试需求分析阶段产品需求分析文档评审成果

准

备软件开发设计阶段概要设计阶段评审成果

详细设计阶段测试方案和测试计划

软件测试设计阶段《概要设计》测试案例

《详细设计》

《测试方案和测试计划》

测试环境准备《概要设计》测试环境清单

《详细设计》测试环境准备完毕

《测试方案和测试计划》

测试冒烟测试《测试项传递汇报》冒烟测试成果

执行系统测试和回归阶段《测试方案和测试计划》《测试日志》

测试案例《轮次总结测试汇报》

《测试项传递汇报》

测试软件测试总结《系统测试总结汇报》

分析软件评估《系统测试总结汇报》评估成果

和维软件测试维护测试案例的J修改

护

7.2新产品测试流程图

石曰-IX、mrvfrrA.en

需求规格阐明书

训心才匕丕；由；升

8生产缺陷测试流程

8.1生产缺陷测试输入和输出

测试阶段输入输出

测试准备阶段生产缺陷描述和处理措施《测试方案和测试计划简报》

测试执行阶段《测试项传递汇报》《测试总结简报》

软件评估《测试总结简报》评估成果

测试案例维护