日包项目测试规范1122.docx

日包项目测试规范1122.docx

《日包项目测试规范1122.docx》由会员分享，可在线阅读，更多相关《日包项目测试规范1122.docx（16页珍藏版）》请在冰豆网上搜索。

日包项目测试规范1122

目录

1简介1

1.1目的1

1.2适用范围1

2过程使用规范1

2.1测试准备1

2.1.1输入1

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

2.1.3测试准备过程2

2.1.4输出5

2.1.5结束准则5

2.2测试执行6

2.2.1输入6

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

2.2.3测试执行过程6

2.2.4输出10

2.2.5结束准则10

2.3测试发布10

2.3.1输入10

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

2.3.3测试发布过程11

2.3.4输出12

2.3.5结束准则12

3附录12

3.1附表1测试环境12

1简介

1.1目的

本文的目的是规范日本外包开发项目测试工作，为测试组与开发组提供详细的过程指引。

以统一规范标准的测试过程为目的，提高苏州工程中心软件测试的管理水平，确保开发项目的交付质量。

1.2适用范围

本文档的适用范围为苏州工程中心的所有日本外包开发项目。

所有日本外包项目都将遵照此规范执行。

2过程使用规范

2.1测试准备

2.1.1输入

《式样书》

《项目计划》

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

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

相关人员职责见下表：

阶段任务

参与人员

提供式样书;

提供项目计划;

参与测试计划评审;

PM/项目组长

式样书分析;

制定测试计划;

测试计划更新;

编写测试方案;

测试分析式样书;

测试场景式样书;

测试执行式样书;

整理式样书检查点;

测试组长/测试人员

2.1.3测试准备过程

2.1.3.1建立测试配置库

Ø在项目配置库中建立测试区域。

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

Ø设置访问权限。

根据项目的需要设置项目组成员的访问权限，开发人员（读取权限）；PM/项目组长/测试组长/测试人员：

（读写权限）。

Ø测试人员提供测试文档。

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

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

测试区域目录结构图

注：

测试配置库的目录结构见：

https:

//61.132.122.76:

8443/svn/TestingGroup/TestingStructure

测试配置库分布表：

文件路径

存放内容

负责人

测试区域

/测试计划

《项目测试计划》

测试组长

/测试方案

《测试方案》

测试组长

/测试式样书

《测试分析式样书》

《测试场景式样书》

《测试式样书》

测试组员

/式样书检查点

《式样书检查点》

测试组长

/测试版本发布

《数据库文件》

《式样书代码》

测试组长

/BUG提交

《版本BUG列表》

测试组员

/测试报告

《月度测试分析报告》

《项目测试总结》

测试组长

2.1.3.2式样书分析

Ø提供式样书。

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

Ø分析式样书。

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

Ø式样书检查点。

PM/项目组长向测试组长向测试组长提供式样书检查点。

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

Ø检查点更新。

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

注：

式样书检查点一般是由发包方提供，如果发包方不提供式样书检查点，则由项目经理制定。

2.1.3.3制定测试计划

Ø提交项目计划。

PM/项目组长向测试组长提交项目计划。

可采用开放配置库的方式。

Ø制定测试计划。

测试组长获取到项目计划后，制定测试计划。

测试计划采用MicrosoftOfficeProject制定。

Ø评审测试计划。

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

测试计划文档发到配置库的测试计划目录下。

Ø变更测试计划。

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

2.1.3.4制定测试方案

Ø制定测试方案。

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

测试方案包括，产品的质量目标，测试的质量目标，角色分配，测试资源分配，测试策略等内容。

Ø评审测试方案。

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

测试方案文档发到配置库的测试方案目录下。

Ø变更测试方案。

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

2.1.3.5编写测试式样书

Ø编写测试分析式样书。

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

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

Ø编写场景测试式样书。

测试组员将测试分析式样书中分析出的测试场景，添加到场景测试式样书中。

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

Ø编写测试式样书。

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

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

Ø编写验收式样书。

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

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

Ø评审测试式样书。

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

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

2.1.3.6测试环境搭建

Ø明确项目测试环境：

PM/项目组长根据项目需求和项目实际情况确定该项目测试所需的必要环境。

Ø搭建项目测试环境：

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

见：

附表1测试环境

2.1.3.7缺陷管理系统配置

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

2.1.4输出

《项目测试计划》

《测试方案》

《测试分析式样书》

《测试场景式样书》

《测试式样书》

《式样书检查点》

2.1.5结束准则

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

2.2测试执行

2.2.1输入

《项目测试计划》

《测试方案》

《测试分析式样书》

《测试场景式样书》

《测试式样书》

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

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

具体职责见下表：

参与人员职责

角色

提交测试版本以及数据库脚本；提交BuildNotes

PM/项目组长

制定计划；周总结；协调沟通；发布版本报告等

测试组长

提交BUG；回归BUG;项目系统数据收集

测试人员

2.2.3测试执行过程

2.2.3.1制定测试周计划

Ø制定测试周计划。

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

测试周计划存放于测试区域的测试计划区。

Ø维护测试周计划。

测试组长根据项目变更维护测试周计划。

测试组长修改本周应测试式样书，维护式样书版本，重新拆分测试任务。

Ø查看周计划。

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

Ø周计划跟踪。

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

详见下图：

过程描述

角色

实施前提

周期

备注

制定周计划

测试组长

开发

Sprint计划完成

每周一下班前制定完成

邮件通知PM/项目组长/测试人员到测试计划区查看周计划

修改维护周计划（项目变更）

测试组长

式样书变更

PM告知项目变更

项目计划变更后第二天下班前制定完成

邮件通知PM/项目组长/测试人员

查看周计划

测试人员

收到邮件通知

收到邮件通知后获取

获取周计划后确认本周任务安排，测试人员如认为安排过少或过多可口头告知测试组长确认后重新安排

周计划跟踪

测试组长

周计划开始实施

确定本周当天测试任务完成情况

测试组长通过日报收集当天任务完成情况

2.2.3.2测试每日构建版本

Ø上传代码。

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

Ø版本构建和部署。

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

Ø建立每日构建版本。

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

Ø构建版本测试。

测试组员于第二天，根据项目PM/组长发布的BuildNotes测试测试站点上的系统。

对于构建版本的测试，只需要执行相关模块的测试用例即可，对于发现的缺陷需提交到Mantis或者QC中。

Ø构建版本测试结果反馈。

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

详见下图：

过程描述

角色

实施前提

周期

备注

上传代码

项目组长

Sprint开发中

每天

测试人员对BuildNotes中有疑问的地方，可以在QQ讨论组中咨询开发人员，对应功能的开发人员需及时作出解答

版本构建和部署

测试组长

PM/项目组长告之测试组长代码已经上传

每天

构建过程中出现问题时，项目组长需要及时解决问题

建立每日构建版本

测试组长

构建完成

每天

测试组长构建通过后，需要在Mantis/QC中建立新版本

构建版本测试

测试组员

构建完成

每天

对于构建版本发现的缺陷，开发在下一个构建版本中需要优先处理

构建版本测试结果反馈

测试组员

构建版本测试完成

每天

构建测试反馈中主要反馈针对BuildNotes中测试结果即可

注：

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

2.2.3.3测试里程碑版本

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

对于里程碑的版本发布，需要经过以下借个过程.

Ø上传代码。

在里程碑版本发布给用户日期前的3~5天，项目组长需要督促项目开发人员将代码本地编译通过后上传代码到SVN。

并邮件告知项目组成员，该版本为里程碑版本和该版本完成的所有功能。

Ø编译部署。

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

对于里程碑版本，测试组长需要生成代码和数据库到测试版本目录下，并写明log日志。

Ø建立里程碑版本。

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

Ø里程碑版本测试。

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

Ø里程碑版本报告。

测试人员测试完毕后，需要对里程碑版本，做一个里程碑版本测试报告，反应当前版本的质量状况和剩余未解决的严重的bug。

版本报告需在里程碑版本发布之前的前一天之前完成。

项目里程碑版本报告存放在测试区域的测试报告区中，测试组成员和开发组成员可查看该项目里程碑版本报告。

Ø里程碑版本发布。

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

会议中得出结论，该版本是否允许发布，以及对所有Medium或以上的问题的解决方案

详见下图：

过程描述

角色

实施前提

周期

备注

上传代码

项目组长

里程碑版本计划中功能已经完成，一般在发布给用户日期前的2~3天

里程碑版本周期

项目组长需要即时在ProductBacklog中，修改已完成功能状态

编译和部署

测试组长

PM/项目组长告之测试组长代码已经上传

里程碑版本周期

构建过程中出现问题时，项目组长需要及时解决问题

建立里程碑版本

测试组长

部署完成

里程碑版本周期

测试组长构建通过后，需要在Mantis/QC中建立新版本

里程碑版本测试

测试组员

部署完成

里程碑版本周期

对于里程碑版本发现的缺陷，开发需要尽量在版本发布给用户前处理完成

里程碑版本报告

测试组员

里程碑版本测试完成

里程碑版本周期

报告需要对用例执行情况，系统已完成功能的质量状况等进行说明

里程碑版本发布

项目组长

评审会议上确定同意发布给客户

里程碑版本周期

发布系统给用户时，需要附带已完成和未完成功能列表，可以ProductBacklog呈现，测试报告

2.2.3.4测试风暴

测试风暴是由测试组长/组员发起，公司领导支持的，全公司的项目测试行为。

分为以下几个过程：

Ø测试风暴发起。

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

Ø测试问题收集。

测试完成后，由测试组员收集和筛选出所有反馈的bug,并提交到Mantis/QC中。

并对所有测试风暴中所有的缺陷进行统计。

并督促开发人员处理测试风暴中所发现的bug.

Ø测试结果公布。

对测试风暴结果以邮件形式通报全公司，并对测试优胜者进行奖励。

注：

此过程非项目研发必须过程，可根据实际情况进行裁剪

2.2.4输出

《测试周计划》

《DailyTestResults》

《里程碑版本测试报告》

《场景用例执行记录》

《功能用例执行记录》

《测试风暴计划邮件》

《测试风暴结果统计》

2.2.5结束准则

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

2.3测试发布

2.3.1输入

《场景用例执行记录》

《功能用例执行记录》

《测试风暴结果统计》

缺陷统计

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

该阶段是测试发布阶段主要是测试人员准备测试报告，产品评审的阶段。

开发人员和测试人员依据各自的分工达到输出准则。

具体人员职责见下表：

参与人员职责

角色

制定测试报告（项目测试总结）；

收集测试数据（BUG总数，修改BUG数，BUG率等）

测试组长

收集测试数据（BUG总数，修改BUG数，BUG率等）

测试人员

2.3.3测试发布过程

2.3.3.1测试报告编写

Ø收集测试数据。

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

Ø分析测试数据。

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

Ø编写项目测试报告。

测试组长根据项目测试过程和测试结果，编写测试报告。

测试报告存放在测试区域的测试报告区中，测试组成员和开发组成员可查看该项目测试报告。

2.3.3.2发布评审

Ø发起评审会议。

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

Ø项目评审会议。

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

Ø评审结论。

评审通过后，由测试组长发出讨论结果，并跟踪问题的处理情况，直到项目发布。

评审若通不过，则需要讨论出项目延期的时间，原因等等，为项目经理跟用户沟通提供依据。

2.3.4输出

《项目测试报告》

评审结论

2.3.5结束准则

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

3附录

3.1附表1测试环境

测试环境

环境配置

配置项

测试服务器硬件配置

双核CPU2.4GHz以上，内存1G，硬盘80G

双核CPU1.6GHz以上，内存2G，硬盘120G

测试服务器操作系统

WindowsServer2003

WindowsXPsp3

Windows7Ultimate

数据库

Oracle

SQLServer

MySQL

中间件

Tomcat（一个轻量级应用服务器）

Jboss（个基于J2EE的开放源代码的应用服务器）

Apache（排名第一的Web服务器软件）

IIS（互联网信息服务）

测试机硬件配置

双核CPU2.4GHz以上，内存1G，硬盘80G

双核CPU1.6GHz以上，内存2G，硬盘120G

测试机操作系统

WindowsServer2003

WindowsXPsp3

UNNIX

Linux

测试机所用浏览器

IE6.0

IE7.0

IE8.0

Firefox

网络协议

TCP/IP（传输控制协议）

IPX/SPX（以太网协议）（顺序数据分组交换协议）

网络带宽

不兼容的软件

其他环境要求