日包项目测试规范1122.docx

1、日包项目测试规范1122目录1 简介 11.1 目的 11.2 适用范围 12 过程使用规范 12.1 测试准备 12.1.1 输入 12.1.2 阶段描述和人员职责描述 12.1.3 测试准备过程 22.1.4 输出 52.1.5 结束准则 52.2 测试执行 62.2.1 输入 62.2.2 阶段描述和人员职责描述 62.2.3 测试执行过程 62.2.4 输出 102.2.5 结束准则 102.3 测试发布 102.3.1 输入 102.3.2 阶段描述和人员职责描述 112.3.3 测试发布过程 112.3.4 输出 122.3.5 结束准则 123 附录 123.1 附表1测试环境

2、121 简介1.1 目的本文的目的是规范日本外包开发项目测试工作，为测试组与开发组提供详细的过程指引。以统一规范标准的测试过程为目的，提高苏州工程中心软件测试的管理水平，确保开发项目的交付质量。1.2 适用范围本文档的适用范围为苏州工程中心的所有日本外包开发项目。所有日本外包项目都将遵照此规范执行。2 过程使用规范2.1 测试准备2.1.1 输入式样书项目计划2.1.2 阶段描述和人员职责描述测试准备阶段是测试人员进行式样书分析、制定测试计划、配置测试配置库，编写测试式样书，建立缺陷管理配置等活动，能有效的定义测试过程，制定出合理的测试策略和测试的进度安排，明确细化责任和分工，便于交流软件测试

3、小组的意图，为执行测试阶段做准备，以保证整个项目的测试工作能顺利进行。相关人员职责见下表：阶段任务参与人员提供式样书;提供项目计划;参与测试计划评审;PM/项目组长式样书分析;制定测试计划;测试计划更新;编写测试方案;测试分析式样书;测试场景式样书;测试执行式样书;整理式样书检查点;测试组长/测试人员2.1.3 测试准备过程2.1.3.1 建立测试配置库 在项目配置库中建立测试区域。由PM/项目组长/测试组长在配置库中的测试区域中建立如下目录，Bug提交，测试版本发布，测试计划，测试总结和式样书检查点，分别用于存储测试文档。 设置访问权限。根据项目的需要设置项目组成员的访问权限，开发人员（读取

4、权限）；PM/项目组长/测试组长/测试人员：(读写权限)。 测试人员提供测试文档。测试人员或测试组长分别将测试文档提交到对应的文件夹目录下。下图是项目配置库关于测试区域的目录结构图：测试区域目录结构图 注：测试配置库的目录结构见： https:/61.132.122.76:8443/svn/TestingGroup/TestingStructure测试配置库分布表：文件路径存放内容负责人测试区域/测试计划项目测试计划测试组长/测试方案测试方案测试组长/测试式样书测试分析式样书测试场景式样书测试式样书测试组员/式样书检查点式样书检查点测试组长/测试版本发布数据库文件式样书代码测试组长/BUG提交

5、版本BUG列表测试组员/测试报告月度测试分析报告项目测试总结测试组长2.1.3.2 式样书分析 提供式样书。PM/项目组长向测试组长提供式样书，可以采用向测试组开放配置库的方式。 分析式样书。测试组长/组员拿到该设计式样书后，分析该式样书，对式样书中不理解或疑惑的地方整理成文档，并确定好开会时间，请相关的项目经理，项目组长和开发人员进行讲解。 式样书检查点。PM/项目组长向测试组长向测试组长提供式样书检查点。测试组长将式样书检查点添加到测试配置库中并通知相关测试人员获取检查点。 检查点更新。在项目开发过程中，式样书检查点有所变更，PM/项目组长需及时以邮件方式告知测试组长更新式样书检查点。注：

6、式样书检查点一般是由发包方提供，如果发包方不提供式样书检查点，则由项目经理制定。2.1.3.3 制定测试计划 提交项目计划。PM/项目组长向测试组长提交项目计划。可采用开放配置库的方式。 制定测试计划。测试组长获取到项目计划后，制定测试计划。测试计划采用Microsoft Office Project制定。 评审测试计划。PM/项目组长评审会议讨论测试计划，并提出评审意见，测试组长根据评审意见修改测试计划。测试计划文档发到配置库的测试计划目录下。 变更测试计划。在项目开发过程中，如果项目计划有变动，需及时通知测试组长，修改测试计划。2.1.3.4 制定测试方案 制定测试方案。测试组长拿到式样书

7、和制定好测试计划后，就需要准备测试方案了。测试方案包括，产品的质量目标，测试的质量目标，角色分配，测试资源分配，测试策略等内容。 评审测试方案。测试方案编写完毕后，可邀请PM/项目组长评审会议讨论测试方案，并提出评审意见，测试组长根据评审意见修改测试方案。测试方案文档发到配置库的测试方案目录下。 变更测试方案。在项目开发过程中，如果项目计划和资源有变动，需及时通知测试组长，修改测试方案。2.1.3.5 编写测试式样书 编写测试分析式样书。根据测试组长的分配，测试组员拿到式样书后开始分析系统，确定各个模块的基本流和备选流和需要测试的测试场景，形成测试分析式样书。测试分析式样书文档发到配置库的测试

8、式样书目录下 编写场景测试式样书。测试组员将测试分析式样书中分析出的测试场景，添加到场景测试式样书中。测试场景式样书文档发到配置库的测试式样书目录下。 编写测试式样书。测试组员针对系统的功能和非功能性需求，参考测试方案中的测试策略，编写系统功能和非功能性的测试式样书。测试式样书文档发到配置库的测试式样书目录下。 编写验收式样书。测试组长可与客户共同讨论编写出验收式样书，作为验收的依据。验收式样书文档发到配置库的测试式样书目录下。 评审测试式样书。测试式样书编写完成后，可邀请项目组长，开发和其它测试人员，评审会议讨论测试式样书，并提出评审意见，测试组员根据评审意见修改测试式样书。测试式样书文档发

9、到配置库的测试式样书目录下。2.1.3.6 测试环境搭建 明确项目测试环境：PM/项目组长根据项目需求和项目实际情况确定该项目测试所需的必要环境。 搭建项目测试环境：测试组长/测试人员根据PM/项目组长确定的测试环境搭建项目测试环境，包括测试服务器环境和测试机环境。见：附表1 测试环境2.1.3.7 缺陷管理系统配置 在缺陷管理系统Mantis或Quality Center中，建立项目名称和模块，配置项目相关人员，并为项目相关人员分配角色权限等等。2.1.4 输出项目测试计划测试方案测试分析式样书测试场景式样书测试式样书式样书检查点2.1.5 结束准则所有文档都已经准备完成并且评审通过2.2

10、测试执行2.2.1 输入项目测试计划测试方案测试分析式样书测试场景式样书测试式样书2.2.2 阶段描述和人员职责描述该阶段为测试执行阶段，主要是测试人员对软件进行测试和验证的阶段，以测试准备阶段的工作成品为入口，开发人员测试人员按照各自的职责分工合作以达到该阶段的出口准则。具体职责见下表：参与人员职责角色提交测试版本以及数据库脚本；提交BuildNotesPM/项目组长制定计划；周总结；协调沟通；发布版本报告等测试组长提交BUG；回归BUG;项目系统数据收集测试人员2.2.3 测试执行过程2.2.3.1 制定测试周计划 制定测试周计划。在Sprint开发的周期内，测试组长以本周一至本周五为单位

11、制定测试周计划，确定本周应测试式样书，拆分测试任务。测试周计划存放于测试区域的测试计划区。 维护测试周计划。测试组长根据项目变更维护测试周计划。测试组长修改本周应测试式样书，维护式样书版本，重新拆分测试任务。 查看周计划。测试人员从测试区域的测试计划中得到测试周计划，明确自己在本周的测试任务，如有不明确或无法理解之处，需提出疑问。 周计划跟踪。测试组长在每天下班前确定本周当天测试任务完成情况（当天应测试式样书，当天未完成测试式样书，当天已完成测试式样书，是否需要加班），以便于评估本周测试任务是否能够按计划完成.详见下图：过程描述角色实施前提周期备注制定周计划测试组长开发Sprint计划完成每周

12、一下班前制定完成邮件通知PM/项目组长/测试人员到测试计划区查看周计划修改维护周计划（项目变更）测试组长式样书变更PM告知项目变更项目计划变更后第二天下班前制定完成邮件通知PM/项目组长/测试人员查看周计划测试人员收到邮件通知收到邮件通知后获取获取周计划后确认本周任务安排，测试人员如认为安排过少或过多可口头告知测试组长确认后重新安排周计划跟踪测试组长周计划开始实施确定本周当天测试任务完成情况测试组长通过日报收集当天任务完成情况2.2.3.2 测试每日构建版本 上传代码。项目PM/组长督促开发人员下班前将每天完成的代码本地编译通过后上传到SVN，并邮件发送BuildNotes通知项目组相关人员。

13、 版本构建和部署。测试组长收到BuildNotes后，在构建服务器上获取到最新的SVN代码，编译通过后部署系统到测试站点，并通知相关测试人员测试。 建立每日构建版本。部署系统完毕后，测试组长需要到缺陷管理系统中，建立新的测试版本，供项目相关人员提交和修复bug。 构建版本测试。测试组员于第二天，根据项目PM/组长发布的BuildNotes测试测试站点上的系统。对于构建版本的测试，只需要执行相关模块的测试用例即可，对于发现的缺陷需提交到Mantis或者QC中。 构建版本测试结果反馈。测试人员测试构建版本完成后，对于构建版本的测试结果需要以流式的DailyTestResults，邮件通知项目组所有

14、相关人员。详见下图：过程描述角色实施前提周期备注上传代码项目组长Sprint开发中每天测试人员对BuildNotes中有疑问的地方，可以在QQ讨论组中咨询开发人员，对应功能的开发人员需及时作出解答版本构建和部署测试组长PM/项目组长告之测试组长代码已经上传每天构建过程中出现问题时，项目组长需要及时解决问题建立每日构建版本测试组长构建完成每天测试组长构建通过后，需要在Mantis/QC中建立新版本构建版本测试测试组员构建完成每天对于构建版本发现的缺陷，开发在下一个构建版本中需要优先处理构建版本测试结果反馈测试组员构建版本测试完成每天构建测试反馈中主要反馈针对BuildNotes中测试结果即可注：

15、此版本仅供项目组内部使用。2.2.3.3 测试里程碑版本对日外包中，只需要参考项目计划按期给客户发版本即可，不需要每天都给客户发送新的版本，对于这些计划中的版本则称之为里程碑版本。对于里程碑的版本发布，需要经过以下借个过程. 上传代码。在里程碑版本发布给用户日期前的35天，项目组长需要督促项目开发人员将代码本地编译通过后上传代码到SVN。并邮件告知项目组成员，该版本为里程碑版本和该版本完成的所有功能。 编译部署。测试组长收到邮件通知后，在构建服务器上获取到最新的SVN代码，编译通过后部署系统到测试站点，并通知相关测试人员测试。对于里程碑版本，测试组长需要生成代码和数据库到测试版本目录下，并写明

16、log日志。 建立里程碑版本。部署系统完毕后，测试组长需要到缺陷管理系统中，建立新的测试版本，供项目相关人员提交和修复bug。 里程碑版本测试。测试人员收到测试组长的通知以后，需要对里程碑版本进行比较详细的测试，所有的已完成模块的场景测试用例和功能测试用例，都需要执行一遍，对于系统中已经修改的严重状态为High及以上的bug都需要进行回归测试。 里程碑版本报告。测试人员测试完毕后，需要对里程碑版本，做一个里程碑版本测试报告，反应当前版本的质量状况和剩余未解决的严重的bug。版本报告需在里程碑版本发布之前的前一天之前完成。项目里程碑版本报告存放在测试区域的测试报告区中，测试组成员和开发组成员可查

17、看该项目里程碑版本报告。 里程碑版本发布。里程碑版本测试报告完成以后，由测试组长邮件通知项目PM/组长及项目组其它所有相关人员，对该里程版本的评审会议。会议中得出结论，该版本是否允许发布，以及对所有Medium或以上的问题的解决方案详见下图：过程描述角色实施前提周期备注上传代码项目组长里程碑版本计划中功能已经完成，一般在发布给用户日期前的23天里程碑版本周期项目组长需要即时在ProductBacklog中，修改已完成功能状态编译和部署测试组长PM/项目组长告之测试组长代码已经上传里程碑版本周期构建过程中出现问题时，项目组长需要及时解决问题建立里程碑版本测试组长部署完成里程碑版本周期测试组长构建

18、通过后，需要在Mantis/QC中建立新版本里程碑版本测试测试组员部署完成里程碑版本周期对于里程碑版本发现的缺陷，开发需要尽量在版本发布给用户前处理完成里程碑版本报告测试组员里程碑版本测试完成里程碑版本周期报告需要对用例执行情况，系统已完成功能的质量状况等进行说明里程碑版本发布项目组长评审会议上确定同意发布给客户里程碑版本周期发布系统给用户时，需要附带已完成和未完成功能列表，可以Product Backlog呈现，测试报告2.2.3.4 测试风暴测试风暴是由测试组长/组员发起，公司领导支持的，全公司的项目测试行为。分为以下几个过程： 测试风暴发起。系统功能和界面全部实现完成后，由测试组长/组员

19、发起，公司领导支持，以邮件形式通知公司所有员工测试系统，邮件中告知系统的访问地址，账号密码，注意事项，奖励方式，结束时间等等。 测试问题收集。测试完成后，由测试组员收集和筛选出所有反馈的bug,并提交到Mantis/QC中。并对所有测试风暴中所有的缺陷进行统计。并督促开发人员处理测试风暴中所发现的bug. 测试结果公布。对测试风暴结果以邮件形式通报全公司，并对测试优胜者进行奖励。注：此过程非项目研发必须过程，可根据实际情况进行裁剪2.2.4 输出测试周计划DailyTestResults里程碑版本测试报告场景用例执行记录功能用例执行记录测试风暴计划邮件测试风暴结果统计2.2.5 结束准则所有不

20、能裁剪工作中的测试文档都已经整理完成。2.3 测试发布2.3.1 输入场景用例执行记录功能用例执行记录测试风暴结果统计缺陷统计2.3.2 阶段描述和人员职责描述该阶段是测试发布阶段主要是测试人员准备测试报告，产品评审的阶段。开发人员和测试人员依据各自的分工达到输出准则。具体人员职责见下表：参与人员职责角色制定测试报告（项目测试总结）；收集测试数据（BUG总数，修改BUG数，BUG率等）测试组长收集测试数据（BUG总数，修改BUG数，BUG率等）测试人员2.3.3 测试发布过程2.3.3.1 测试报告编写 收集测试数据。测试组员依据项目测试报告模板收集项目相关数据，包括bug Open和Fixe

21、d,pending的bug数量，各模块产生的bug数量，产生原因等等。 分析测试数据。测试组长/组员分析测试数据找出数据异常和正常的原因，得出测试结论等等。 编写项目测试报告。测试组长根据项目测试过程和测试结果，编写测试报告。测试报告存放在测试区域的测试报告区中，测试组成员和开发组成员可查看该项目测试报告。2.3.3.2 发布评审 发起评审会议。项目测试报告发布编写完成后，原则上在项目交付给用户前的35天左右，由测试组长邮件通知所有项目成员参加项目评审会议，告知会议时间和地点，并提前做好准备。 项目评审会议。评审会议中，由测试组长先对照测试报告讲解项目的质量状况，然后参照未解决问题列表，讨论出

22、项目发布前的需要解决的问题和保留的问题。 评审结论。评审通过后，由测试组长发出讨论结果，并跟踪问题的处理情况，直到项目发布。评审若通不过，则需要讨论出项目延期的时间，原因等等，为项目经理跟用户沟通提供依据。2.3.4 输出项目测试报告评审结论2.3.5 结束准则评审会议中，对项目的正常发布有了结论定义。3 附录3.1 附表1测试环境测试环境环境配置配置项测试服务器硬件配置双核CPU 2.4GHz以上，内存1G，硬盘80G双核CPU 1.6GHz以上，内存2G，硬盘120G测试服务器操作系统Windows Server 2003Windows XP sp3Windows 7 Ultimate数据

23、库OracleSQL ServerMySQL中间件Tomcat（一个轻量级应用服务器）Jboss（个基于J2EE的开放源代码的应用服务器）Apache（排名第一的Web服务器软件）IIS（互联网信息服务）测试机硬件配置双核CPU 2.4GHz以上，内存1G，硬盘80G双核CPU 1.6GHz以上，内存2G，硬盘120G测试机操作系统Windows Server 2003Windows XP sp3UNNIXLinux测试机所用浏览器IE6.0IE7.0IE8.0Firefox网络协议TCP/IP（传输控制协议）IPX/SPX（以太网协议）（顺序数据分组交换协议）网络带宽不兼容的软件其他环境要求