功能测试工作规程文档格式.docx

1、4.3.2 编制测试方案计划 64.3.3 设计测试案例 74.4 测试实施阶段 84.4.1 测试准入检查 84.4.2 执行测试案例 94.4.3 缺陷管理 104.5 测试收尾阶段 104.5.1 编制测试报告 104.5.2 测试工作过程改进 114.5.3 测试资产提交 125 问题处理 121 编写目的本文档是我行信息技术项目中功能测试小组（以下简称测试小组）的日常工作规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试小组应完成的工作。测试技术和策略等问题不在本文档描述范围内。2 测试类型的划分项目的开发工作完成时，一般应由开发小组在完成内部测试（含单元测试和系统内部集成测

2、试）后，再将完成件提交给测试小组进行后续测试。按照测试的时间先后顺序，测试小组负责的测试可以分为连接测试（Link Test，简称LT）、系统集成测试（System Integration Test，简称SIT）,用户接受测试（User Acceptance Test，简称UAT）和版本检验测试（Verification Test，简称VT）等四种类型。有关的测试类型的概念如下： 1）单元测试是验证本系统的软件构件或模块的正确性，并由开发人员组织实施的测试。因为一个构件或模块本身不是一个独立的程序，通常需要开发相应的驱动程序和桩模块。 2）系统内部集成测试是验证本系统应用处理的正确性由开发人员

3、组织实施的内部测试。一般采用自底向上或自顶向下的模块集成方法，逐步集成。为消除其它周边相关系统的影响，可以采用请求方或应答方模拟器来模拟周边系统，比如网银模拟器或CCBS模拟器等。3）连接测试是在跨系统的测试环境中，为消除跨系统间环境和报文接口的一般性技术缺陷而进行的短期测试，可以视为SIT阶段开始前的绿灯测试，实际工作中可根据项目实际情况将其内容纳入SIT测试阶段。4）系统集成测试是为验证需求规格说明所定义的所有系统功能和业务功能，并且与关联系统能够正确的集成交互所进行的测试，是对整体系统功能进行全面测试和验证的过程。系统集成测试也被称为“跨系统集成测试”。5）用户接受测试是为验证软件实现的

4、业务功能是否满足业务需求、是否满足业务人员的实际使用需求而由业务部门组织的测试。用户接受测试通常由业务部门组织进行测试，此过程中本规程及相关规范只作为建议，不作为强制约束要求。6）版本检验测试按照类似投产的版本管理要求，将待投产的版本在类似的生产环境中安装，并作回归测试，以检验投产版本质量的过程。实际测试中可以将此阶段纳入UAT测试的最后一轮。3 测试小组构成职责功能测试是软件过程中的重要组成部分，肩负着如下责任： 尽可能早地参与项目的需求工作和必要的应用设计工作，参与需求、设计、单元测试、系统内部集成测试等阶段的审核工作，跟踪业务需求的变更，全面理解和熟悉系统的功能需求和应用设计，从用户体验

5、和测试的角度提出自己的看法。 编写合理的测试方案和计划，并与项目整体计划有机地结合在一起。 编写合理有效测试案例，保证对被测应用的覆盖。 针对测试需要选择相应测试技术及策略。 认真仔细地实施测试工作，进行缺陷登记与跟踪，做好复测工作，并提交测试报告。角色划分下面是一般情况下测试小组的角色构成，在人力资源有限的情况下，一人可以同时承担多个角色。角色名称相关主要责任测试经理 组建测试小组 协调测试小组内外部的沟通 编制测试方案和计划 组织测试准入检查 测试过程中的进度控制、风险管理 测试过程报告 编写测试报告 召集测试评审测试人员 识别测试需求 设计测试案例 协助编制测试方案和计划 协助测试准入检

6、查 执行测试案例，测试结果记录 测试缺陷登记与跟踪 协助测试评审技术支持人员 为测试工作提供技术支持，比如环境安装、版本布署、测试工具支持等备注：该角色可选，可根据项目实际情况设置4 工作流程及规范工作流程每项功能测试（SIT、UAT等）任务都可划分为三个阶段，每个阶段由不同的活动组成。测试提交件及裁剪说明下面是对各测试阶段主要工作提交件要求及裁剪说明的一览表。部分提交件是必须的，部分提交件允许在一定条件下省略。部分模板要求必须采用全行统一的模板（即本规范所要求的），部分模板允许各开发中心结合自身情况进行定制，部分模板允许各项目组根据情况自由决定。阶段提交件必须提交模板定义裁剪条件说明测试计划

7、QC项目创建申清单否全行统一在不引起混淆的情况下，可与QC原有项目进行复用，不用再提交QC项目创建清单测试方案是开发中心1各开发中心根据测试任务的规模可自定义模板项目组如果测试方案中已包括了测试计划的内容，则本文档可省略测试方案计划评审检查表测试案例执行周期在3工作日以内的测试任务可省略测试案例数据线有关测试任务可采用其它自定义模板测试数据需求各项目酌情选用测试案例评审检查表测试实施功能测试准入检查表QC中的测试案例执行记录按QC的规范进行管理QC中的测试缺陷记录测试日报测试收尾测试报告可以采用各开发中心统一规定的模板代替测试报告评审检查表测试工作改进报告测试资产清单测试计划阶段成立测试小组过

8、程要点详细说明启动条件测试任务明确，前期工作启动工作内容 为测试小组任命一名测试经理，同时确定测试小组的其它构成人选 小组内进行必要的培训 对于跨系统的测试，测试人员往往来自于多个项目或部门，工作地点可能不在一起，更需要明确小组的人员组成、职责及配合方式 测试经理按照有关流程申请创建QC的项目和用户，并通知各方 QC项目的创建应按照项目群的方式，把相关项目组和人员都纳入，这样才能便于测试过程中的协同和统一管理结束条件测试小组成立输出产物QC项目创建申请单相关模板QC项目创建申请单（含在测试管理工具（QC）使用手册中）相关指南测试管理工具（QC）使用手册例外 若以前的测试任务已成立过测试小组，则

9、可以复用以前的组织人员和形式 在不引起混淆的情况下，可与QC原有项目进行复用，不用再提交QC项目创建清单责任人项目经理参与人编制测试方案计划项目计划确定测试目标、范围等已确定对于有多次投产版本的项目，须按照每次不同的待测版本编写相应的测试方案和计划。测试方案至少包括以下关键内容： 测试目标对本次测试的要求和要达到的目标 测试范围需要测试小组测试的范围，和各个测试需求的测试优先级 工作分工明确测试小组内部及外部配合方的相关责任和工作关系 测试环境使用什么样的测试环境进行本次测试 测试策略整体测试的总体测试策略、方法和工具等 版本管理测试过程中版本如何管理、不同系统间的版本更新协同方式 完成标准达

10、到何种条件可以认为测试完成 交付物测试完成时应提交的工作产物，比如测试方案、测试案例、测试报告等等 风险管理分析测试过程中可能出现的风险及对策测试计划至少应包括以下关键内容： 主要任务每项任务的时间计划、前置条件及资源 主要里程碑关键任务及完成时间点测试计划可以采用project或excel等形式来编制结束标准测试方案计划评审通过或得到相关各方的书面认可测试方案、测试计划、测试方案计划评审检查表测试方案、测试方案计划评审检查表相关规范功能测试评审管理规范 对于多个系统参与的同一个测试任务，可由主项目组或牵头方统一编制测试方案和计划，不用每个系统单独编制和出具 测试计划可以在测试方案中直接详细列

11、明，而不用单独编制项目经理、测试人员设计测试案例在需求分析说明书确立基线以后，测试小组需要针对项目的测试范围编写测试案例。在实际测试过程中，测试案例可根据实际需要进行更新和调整。在案例的编写过程中，具体的任务和责任人如下：本次测试范围、业务需求已经明确需求分析说明书已通过评审 准备本次测试的测试案例 测试案例可以新编或复用以前积累的案例 每个测试案例须包括案例编号、测试概述、测试数据、必要的操作步骤、预期结果等要素 测试案例全部编制完成后，根据测试数据描述梳理出本次全部案例所需的测试数据需求 案例须覆盖所有的测试需求和功能点 采用统一的模板进行案例设计 根据测试案例，整理提出完整清晰的测试数据

12、需求，并及时着手准备测试数据 案例全部导入QC中进行管理，便于统计、分析及跟踪测试案例需要覆盖所有的待测试需求或功能点，并且评审通过测试案例、测试数据需求、测试案例评审检查表功能测试案例设计、测试案例评审检查表、测试数据需求功能测试案例设计指南、功能异常测试案例设计参考、测试管理工具（QC）使用手册对于数据线的测试任务，可另外制定其测试案例模板测试经理、开发人员、项目经理测试实施阶段测试准入检查详细描述测试实施准备工作完成 测试经理根据本项目的特点，事先确定测试准入标准中哪些条目可以进行裁剪，并与项目经理或开发人员事先沟通 准入标准中“计划准入标准”是指编制测试计划和案例设计时就需要具备的前提

13、条件，应提前进行检查；“执行准入标准”是指在执行案例之前需要进行的检查。以上两类检查应分两次进行 测试经理和测试人员根据测试准入标准，逐项进行检查，并填制功能测试准入检查表 对于不满足条件的检查项，要求相关方面进行解决，解决后重新进行检查 对于必须要通过的检查项，而没检查通过的，视为准入检查不通过，不能进入下一阶段工作测试准入检查通过测试人员、项目经理、开发人员、技术支持人员执行测试案例测试执行阶段准入检查通过 测试人员根据计划，执行相应的测试案例，并及时在QC中更新案例的“运行结果”状态 测试人员进行缺陷登记，并跟踪解决情况，及时复测，关闭缺陷 测试经理跟踪案例执行情况，了解影响案例执行的因

14、素，及时跟进有关的协调、报告测试状态 测试经理根据项目的情况，选择有关的报告形式，将测试进展情况及时通报给有关各方测试案例执行完成QC中的测试案例执行记录、测试日报测试人员、测试经理开发人员、项目经理缺陷管理测试案例开始执行 测试人员在测试过程中，登记被测系统缺陷，跟踪缺陷的分析、解决过程 开发人员及时分析处理缺陷，并按要求记录缺陷的分析处理信息，更新缺陷状态，填制缺陷起源；对需要其它人员参与分析处理的时候，需及时将缺陷分配给下一环节人员 测试人员对待验证的缺陷需及时进行复测，测试通过后关闭缺陷测试案例执行完成，并且缺陷跟踪完成功能测试缺陷管理规范测试人员、开发人员、测试经理测试收尾阶段测试实

15、施阶段结束或即将结束时，测试小组可以开始着手准备进行总结报告及收尾工作。编制测试报告在测试实施完成之后，测试经理需根据实施测试情况，编制测试报告。测试小组完成了所有的测试实施工作或测试时间已结束测试经理根据测试的结果，按照测试报告的文档模板编写测试报告，测试报告必须包含以下重要内容： 案例执行情况分析 测试阶段案例执行的数量、轮次、通过率等 测试过程中已发现缺陷分析分析缺陷的数量、分布、起源等 未执行案例的风险分析分析未执行的案例对系统形成的风险 未关闭缺陷的风险分析分析未关闭的缺陷对系统形成的风险 测试结论 评价测试方案中定义的测试完成标准是否达到，被测系统的质量评价，存在的风险，以及有关建

16、议功能测试报告评审通过，发送给相关人员测试报告、测试报告评审检查表功能测试报告模板（或用户测试报告模板）、测试报告评审检查表 用户测试报告模板仅供有关用户测试时参考测试人员、开发人员、项目经理测试工作过程改进测试过程改进在测试实施阶段工作全部结束以后进行。它的目的是评估本次测试工作，总结经验，使下一次的工作做得更好。本项工作不是一个必须的过程，各项目可根据情况采用。测试实施阶段结束 测试经理召集测试参与人员，讨论本次测试过程得与失，总结经验，提出改进方法和意见 编写测试工作过程改进报告测试工作过程改进报告编制完成可根据项目情况，裁剪本过程测试资产提交 测试资产提交在测试实施阶段工作结束以后进行，对测试过程中涉及到各种标准文档进行归类，存档。提交本次测试过程产生的，能为其它项目或本项目后续测试提供借鉴的，与投产版本配套的测试案例、测试脚本等全部资产归档完毕如果资产内容不多，结构清楚，则可以省略测试资产清单5 问题处理对于测试过程中出现的争议或问题，分别提请项目经理、牵头项目组项目经理、开发中心及信息技术管理部相关条线帮助协调解决。