XX项目测试规范

目录

1 简介 (2)

1.1 目的 (2)

1.2 适用范围 (2)

2 过程使用规范 (2)

2.1 测试准备 (2)

2.1.1 输入 (2)

2.1.2 阶段描述和人员职责描述 (2)

2.1.3 测试准备过程 (3)

2.1.4 输出 (6)

2.1.5 结束准则 (6)

2.2 测试执行 (6)

2.2.1 输入 (6)

2.2.2 阶段描述和人员职责描述 (7)

2.2.3 测试执行过程 (7)

2.2.4 输出 (11)

2.2.5 结束准则 (11)

2.3 测试发布 (11)

2.3.1 输入 (11)

2.3.2 阶段描述和人员职责描述 (11)

2.3.3 测试发布过程 (12)

2.3.4 输出 (12)

2.3.5 结束准则 (12)

3 附录 (13)

3.1 附表1测试环境 (13)

1简介

1.1目的

本文的目的是规范日本外包开发项目测试工作，为测试组与开发组提供详细的过程指引。以统一规范标准的测试过程为目的，提高苏州工程中心软件测试的管理水平，确保开发项目的交付质量。

1.2适用范围

本文档的适用范围为苏州工程中心的所有日本外包开发项目。所有日本外包项目都将遵照此规范执行。

2过程使用规范

2.1测试准备

2.1.1输入

《式样书》

《项目计划》

2.1.2阶段描述和人员职责描述

测试准备阶段是测试人员进行式样书分析、制定测试计划、配置测试配置库，编写测试式样书，建立缺陷管理配置等活动，能有效的定义测试过程，制定出合理的测试策略和测试的进度安排，明确细化责任和分工，便于交流软件测试小组的意图，为执行测试阶段做准备，以保证整个项目的测试工作能顺利进行。相关人员职责见下表：

2.1.3测试准备过程

2.1.

3.1建立测试配置库

在项目配置库中建立测试区域。由PM/项目组长/测试组长在配置库中的测试区域中建立如下目录，Bug提交，测试版本发布，测试计划，测试总结和式样书检查点，

分别用于存储测试文档。

设置访问权限。根据项目的需要设置项目组成员的访问权限，开发人员（读取权限）；

PM/项目组长/测试组长/测试人员：(读写权限)。

测试人员提供测试文档。测试人员或测试组长分别将测试文档提交到对应的文件夹目录下。

下图是项目配置库关于测试区域的目录结构图：

测试区域目录结构图

测试配置库分布表：

2.1.

3.2式样书分析

提供式样书。PM/项目组长向测试组长提供式样书，可以采用向测试组开放配置库的方式。

分析式样书。测试组长/组员拿到该设计式样书后，分析该式样书，对式样书中不理解或疑惑的地方整理成文档，并确定好开会时间，请相关的项目经理，项目组长

和开发人员进行讲解。

式样书检查点。PM/项目组长向测试组长向测试组长提供式样书检查点。测试组长将式样书检查点添加到测试配置库中并通知相关测试人员获取检查点。

检查点更新。在项目开发过程中，式样书检查点有所变更，PM/项目组长需及时以邮件方式告知测试组长更新式样书检查点。

注：式样书检查点一般是由发包方提供，如果发包方不提供式样书检查

点，则由项目经理制定。

2.1.

3.3制定测试计划

提交项目计划。PM/项目组长向测试组长提交项目计划。可采用开放配置库的方式。

制定测试计划。测试组长获取到项目计划后，制定测试计划。测试计划采用Microsoft Office Project制定。

评审测试计划。PM/项目组长评审会议讨论测试计划，并提出评审意见，测试组长

根据评审意见修改测试计划。测试计划文档发到配置库的测试计划目录下。

变更测试计划。在项目开发过程中，如果项目计划有变动，需及时通知测试组长，修改测试计划。

2.1.

3.4制定测试方案

制定测试方案。测试组长拿到式样书和制定好测试计划后，就需要准备测试方案了。

测试方案包括，产品的质量目标，测试的质量目标，角色分配，测试资源分配，测

试策略等内容。

评审测试方案。测试方案编写完毕后，可邀请PM/项目组长评审会议讨论测试方案，并提出评审意见，测试组长根据评审意见修改测试方案。测试方案文档发到配置库

的测试方案目录下。

变更测试方案。在项目开发过程中，如果项目计划和资源有变动，需及时通知测试组长，修改测试方案。

2.1.

3.5编写测试式样书

编写测试分析式样书。根据测试组长的分配，测试组员拿到式样书后开始分析系统，确定各个模块的基本流和备选流和需要测试的测试场景，形成测试分析式样书。测

试分析式样书文档发到配置库的测试式样书目录下

编写场景测试式样书。测试组员将测试分析式样书中分析出的测试场景，添加到场景测试式样书中。测试场景式样书文档发到配置库的测试式样书目录下。

编写测试式样书。测试组员针对系统的功能和非功能性需求，参考测试方案中的测试策略，编写系统功能和非功能性的测试式样书。测试式样书文档发到配置库的测

试式样书目录下。

编写验收式样书。测试组长可与客户共同讨论编写出验收式样书，作为验收的依据。

验收式样书文档发到配置库的测试式样书目录下。

评审测试式样书。测试式样书编写完成后，可邀请项目组长，开发和其它测试人员，评审会议讨论测试式样书，并提出评审意见，测试组员根据评审意见修改测试式样

书。测试式样书文档发到配置库的测试式样书目录下。

2.1.

3.6测试环境搭建

明确项目测试环境：PM/项目组长根据项目需求和项目实际情况确定该项目测试所

需的必要环境。

搭建项目测试环境：测试组长/测试人员根据PM/项目组长确定的测试环境搭建项目测试环境，包括测试服务器环境和测试机环境。

见：附表1 测试环境

2.1.

3.7缺陷管理系统配置

在缺陷管理系统Mantis或Quality Center中，建立项目名称和模块，配置项目相关人员，并为项目相关人员分配角色权限等等。

2.1.4输出

《项目测试计划》

《测试方案》

《测试分析式样书》

《测试场景式样书》

《测试式样书》

《式样书检查点》

2.1.5结束准则

所有文档都已经准备完成并且评审通过

2.2测试执行

2.2.1输入

《项目测试计划》

《测试方案》

《测试分析式样书》

《测试场景式样书》

《测试式样书》

2.2.2阶段描述和人员职责描述

该阶段为测试执行阶段，主要是测试人员对软件进行测试和验证的阶段，以测试准备阶段的工作成品为入口，开发人员测试人员按照各自的职责分工合作以达到该阶段的出口准则。具体职责见下表：

2.2.3测试执行过程

2.2.

3.1制定测试周计划

制定测试周计划。在Sprint开发的周期内，测试组长以本周一至本周五为单位制定测试周计划，确定本周应测试式样书，拆分测试任务。测试周计划存放于测试区域的测试计划区。

维护测试周计划。测试组长根据项目变更维护测试周计划。测试组长修改本周应测试式样书，维护式样书版本，重新拆分测试任务。

查看周计划。测试人员从测试区域的测试计划中得到测试周计划，明确自己在本周的测试任务，如有不明确或无法理解之处，需提出疑问。

周计划跟踪。测试组长在每天下班前确定本周当天测试任务完成情况（当天应测试式样书，当天未完成测试式样书，当天已完成测试式样书，是否需要加班），以便于评估本周测试任务是否能够按计划完成.

详见下图：

2.2.

3.2测试每日构建版本

上传代码。项目PM/组长督促开发人员下班前将每天完成的代码本地编译通过后上传到SVN，并邮件发送BuildNotes通知项目组相关人员。

版本构建和部署。测试组长收到BuildNotes后，在构建服务器上获取到最新的SVN代码，编译通过后部署系统到测试站点，并通知相关测试人员测试。

建立每日构建版本。部署系统完毕后，测试组长需要到缺陷管理系统中，建立新的测试版本，供项目相关人员提交和修复bug。

构建版本测试。测试组员于第二天，根据项目PM/组长发布的BuildNotes测试测试站点上的系统。对于构建版本的测试，只需要执行相关模块的测试用例即可，对于发现的缺陷需提交到Mantis或者QC中。

构建版本测试结果反馈。测试人员测试构建版本完成后，对于构建版本的测试结果需要以流式的DailyTestResults，邮件通知项目组所有相关人员。

注：此版本仅供项目组内部使用。

2.2.

3.3测试里程碑版本

对日外包中，只需要参考项目计划按期给客户发版本即可，不需要每天都给客户发送新的版本，对于这些计划中的版本则称之为里程碑版本。对于里程碑的版本发布，需要经过以下借个过程.

上传代码。在里程碑版本发布给用户日期前的3~5天，项目组长需要督促项目开发人员将代码本地编译通过后上传代码到SVN。并邮件告知项目组成员，该版本为里程碑版本和该版本完成的所有功能。

编译部署。测试组长收到邮件通知后，在构建服务器上获取到最新的SVN代码，编译通过后部署系统到测试站点，并通知相关测试人员测试。对于里程碑版本，测试组长需要生成代码和数据库到测试版本目录下，并写明log日志。

建立里程碑版本。部署系统完毕后，测试组长需要到缺陷管理系统中，建立新的测试版本，供项目相关人员提交和修复bug。

里程碑版本测试。测试人员收到测试组长的通知以后，需要对里程碑版本进行比较详细的测试，所有的已完成模块的场景测试用例和功能测试用例，都需要执行一遍，对于系统中已经修改的严重状态为High及以上的bug都需要进行回归测试。

里程碑版本报告。测试人员测试完毕后，需要对里程碑版本，做一个里程碑版本测试报告，反应当前版本的质量状况和剩余未解决的严重的bug。版本报告需在里程碑版本发布之前的前一天之前完成。项目里程碑版本报告存放在测试区域的测试报告区中，测试组成员和开发组成员可查看该项目里程碑版本报告。

里程碑版本发布。里程碑版本测试报告完成以后，由测试组长邮件通知项目PM/组长及项目组其它所有相关人员，对该里程版本的评审会议。会议中得出结论，该版本是否允

许发布，以及对所有Medium或以上的问题的解决方案

2.2.

3.4测试风暴

测试风暴是由测试组长/组员发起，公司领导支持的，全公司的项目测试行为。分为以下几个过程：

测试风暴发起。系统功能和界面全部实现完成后，由测试组长/组员发起，公司领导支持，以邮件形式通知公司所有员工测试系统，邮件中告知系统的访问地址，账号密码，注意事项，奖励方式，结束时间等等。

测试问题收集。测试完成后，由测试组员收集和筛选出所有反馈的bug,并提交到Mantis/QC中。并对所有测试风暴中所有的缺陷进行统计。并督促开发人员处理测试风暴中所发现的bug.

测试结果公布。对测试风暴结果以邮件形式通报全公司，并对测试优胜者进行奖励。注：此过程非项目研发必须过程，可根据实际情况进行裁剪

2.2.4输出

《测试周计划》

《测试周报》

《里程碑版本测试报告》

《场景用例执行记录》

《功能用例执行记录》

《测试风暴计划邮件》

《测试风暴结果统计》

2.2.5结束准则

所有不能裁剪工作中的测试文档都已经整理完成。

2.3测试发布

2.3.1输入

《场景用例执行记录》

《功能用例执行记录》

《测试风暴结果统计》

缺陷统计

2.3.2阶段描述和人员职责描述

该阶段是测试发布阶段主要是测试人员准备测试报告，产品评审的阶段。开发人员和测试人员依据各自的分工达到输出准则。具体人员职责见下表：

2.3.3测试发布过程

2.3.3.1测试报告编写

收集测试数据。测试组员依据项目测试报告模板收集项目相关数据，包括bug Open和Fixed,pending的bug数量，各模块产生的bug数量，产生原因等等。

分析测试数据。测试组长/组员分析测试数据找出数据异常和正常的原因，得出测试结论等等。

编写项目测试报告。测试组长根据项目测试过程和测试结果，编写测试报告。测试报告存放在测试区域的测试报告区中，测试组成员和开发组成员可查看该项目测试报告。

2.3.3.2发布评审

发起评审会议。项目测试报告发布编写完成后，原则上在项目交付给用户前的3~5天左右，由测试组长邮件通知所有项目成员参加项目评审会议，告知会议时间和地点，并提前做好准备。

项目评审会议。评审会议中，由测试组长先对照测试报告讲解项目的质量状况，然后参照未解决问题列表，讨论出项目发布前的需要解决的问题和保留的问题。

评审结论。评审通过后，由测试组长发出讨论结果，并跟踪问题的处理情况，直到项目发布。评审若通不过，则需要讨论出项目延期的时间，原因等等，为项目经理跟用户沟通提供依据。

2.3.4输出

《项目测试报告》

评审结论

2.3.5结束准则

评审会议中，对项目的正常发布有了结论定义。

3附录

3.1附表1测试环境