测试组工作流程v10Word文档格式.docx
《测试组工作流程v10Word文档格式.docx》由会员分享，可在线阅读，更多相关《测试组工作流程v10Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。
要求注明变更内容和变更范围
目录
1编写目的4
2测试团队构成4
2.1职责4
2.2角色划分4
3工作流程及规范5
3.1计划与设计阶段5
3.1.1成立测试团队5
3.1.2熟悉需求文档5
3.1.3编写测试计划文档6
3.1.4设计测试用例6
3.2实施测试阶段7
3.2.1实施测试用例，并提交缺陷报告7
3.2.2回归测试8
3.2.3结束测试8
3.3总结阶段9
3.3.1编写测试报告9
3.3.2测试工作总结10
3.4缺陷跟踪10
4争议处理11
5标准文档11
1编写目的
本文档是测试团队的日常工作规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试团队应完成的工作。
测试技术和策略等问题不在本文档描述范围内。
2测试团队构成
2.1职责
测试是软件开发过程中的重要组成部分，担负着如下责任：
Ø
在项目的前期，需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。
编写合理的测试计划，并与项目整体计划有机地整合在一起。
编写覆盖率高的测试用例。
针对测试需求进行相关测试技术的研究。
认真仔细地实施测试工作，并及时提交bugreport。
提交测试报告供项目组参考。
进行缺陷跟踪与分析。
2.2角色划分
在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。
角色名称
相关主要责任
测试负责人
●协调测试组内部的沟通
●保持与项目经理的有效沟通，了解项目的进展
●监控测试的进度与质量
●编写总体测试计划
●编写测试报告
●评审测试用例和缺陷报告并对组员提供指导
●后台配置
测试工程师
●在组长指导下编写分系统的测试计划
●编写测试用例
●实施测试用例，执行测试
●编写缺陷报告并进行缺陷跟踪
●编写测试脚本
●执行测试脚本，分析执行结果
3工作流程及规范
3.1计划与设计阶段
3.1.1成立测试团队
在项目组成立的同时，测试组也将同时成立。
团队成立的工作与责任如下：
过程要点
详细说明
输入条件
项目组成立
工作内容
确定测试组的构成人选。
退出标准
测试组成立
责任人
测试主管
图表1
3.1.2熟悉需求文档
用户需求文档和产品需求文档编写完成后，测试人员要充分熟悉和理解需求文档，对于用户需求和产品需求不一致的地方或者任何对用户需求和产品需求有疑问的地方都要记录下来，方式是对每一篇需求文档以批注方式添加到原文件中，待需求评审时提出来。
需要各个系统组对评审问题给予回应。
项目进入需求阶段
充分理解需求，就需求中的不确定性问题与项目经理、软件负责人及各个系统组达成一致意见
产品需求评审通过，评审所提问题都以明确
测试负责人，测试工程师
图表2
3.1.3编写测试计划文档
需求分析文档确立后，测试组需要编写测试计划文档，为后续的测试工作提供直接的指导
项目需求文档建立
根据项目的需求文档，按照测试计划文档模板编写测试计划。
测试计划中应该至少包括以下关键内容：
●测试需求——需要测试组测试的范围，估算出测试所花费的人力资源和各个测试需求的测试优先级
●测试方案——整体测试的测试方法和每个测试需求的测试方法
●测试资源——本次测试所需要用到的人力、硬件、软件、技术的资源
●测试组角色——明确测试组内各个成员的角色和相关责任
●里程碑——明确标准项目过程中测试组应该关注的里程碑
●可交付工件——在测试组的工作中必须向项目组提交的产物，包括测试计划、测试报告等等
●风险管理——列举出测试工作所可能出现的风险
测试计划编写完毕后，必须提交给项目组全体成员，并由项目经理、软件负责人组织评审。
●测试计划由项目组评审通过
●在项目开发过程中，根据项目计划要适时的对测试计划进行跟踪，以评估此计划的完整性、可行性
图表4
3.1.4设计测试用例
在需求分析文档确立基线以后，测试组需要针对项目的测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准。
在用例的编写过程中，具体的任务和责任人如下：
测试需求明确，测试计划明确，数据库设计图（设计组）
●测试工程师根据测试计划编写全部的测试用例
●测试主管抽查部分功能模块的测试用例复审对测试人员提供指导
●测试组内审测试用例
●项目组评审测试用例
●用例编写过程中发现的任何需求问题都记录下来，形成文档，与需求组长沟通，使得需求得以确定
测试用例需要覆盖所有的测试需求并通过项目组评审（测试用例需要不断完善，当需求变更时需调整相应的用例）
图表5
3.2实施测试阶段
3.2.1实施测试用例，并提交缺陷报告
实施测试用例将花费测试组绝大部分时间，这些工作都是建立在前期很多计划工作的基础上。
详细描述
测试用例通过项目组评审。
功能实现时间列表，功能重要程度列表（设计组）。
●测试工程师根据测试计划中分配给自己的测试任务和提供的测试用例，实施相应的测试用例，并对失败状态的用例填写缺陷报告
●在测试过程中若发现有未覆盖到的用例，需及时补充到用例库中，并做出标记，测试结束后需分析遗漏用例的原因
●用例编写及执行过程中发现的任何设计变更都记录下来，并建立《设计变更表》以追踪此功能点，与项目经理、软件负责人、需求组长沟通，使得设计变更得以确定
●参加对变更的讨论以评估此变更对测试工作带来的影响及风险（需求组，设计组）
●配置组需要配合维护测试环境，安装测试版本
●测试主管抽查部分缺陷报告进行审查并对测试人员提供指导
测试用例中的所有任务被执行，结果被记录。
3.2.2回归测试
在开发人员修改上一轮的缺陷后，由测试组重新取修改后的最新版本，进行回归测试。
此回归测试与实施测试用例并行进行。
●在上轮测试中，按照现有的测试用例没有新的缺陷被发现
●对于上一轮发现的缺陷，只允许存在FIXED、INVALID、WONTFIX、LATER四种状态
测试组将按照测试计划中对于回归测试的策略对产品进行回归测试，回归测试的用例属于测试用例的一部分或者是全部测试用例（在测试过程中若发现有未覆盖到的用例，需及时补充到用例库中）。
●回归测试所运行的用例全部通过
●对于上一轮发现的FIXED状态的缺陷报告，本轮回归结束后，BUGZILLA中只允许存在Reopen、Closed两种状态
测试工程师
3.2.3结束测试
●项目到了发布日期
●上一轮回归测试结束后，BUGZILLA中只存在VERIFIED-FIXED、VERIFIED-INVALID、VERIFIED-WONTFIX、VERIFIED-LATER四种状态的缺陷报告
●测试组将按照测试计划中对于回归测试的策略对产品进行回归测试，回归测试的用例属于测试用例的一部分或者是全部测试用例
●在测试过程中若发现有未覆盖到的用例，需及时补充到用例库中
●主要工作流程和主要功能没有问题（时间不充分的情况）
●所有测试用例全部回归通过（时间充分的情况）
●结束测试时BUGZILLA中只允许存在CLOSED-FIXED、CLOSED-INVALID、CLOSED-WONTFIX、CLOSED-LATER四种状态的缺陷报告
3.3总结阶段
测试工作结束或即将结束时，测试组就要开始着手准备进行总结的工作。
3.3.1编写测试报告
在回归测试结束之后，测试主管将要编写测试报告，对测试进行总结，并且提交给项目组，为产品的后续工作和项目组以后的工作改进提供重要的信息支持。
测试组完成了所有的测试实施工作
测试主管根据测试的结果，按照测试报告的文档模板编写测试报告，测试报告必须包含以下重要内容：
●测试资源概述——多少人、多长时间
●测试结果摘要——分别描述各个测试需求的测试结果，产品实现了哪些功能点，哪些还没有实现
●缺陷分析——按照缺陷的属性分类进行分析
●测试需求覆盖率——原先列举的测试需求的测试覆盖率，可能一部分测试需求因为资源和优先级的因素没有进行测试，那么在这里要进行说明
●测试评估——从总体对项目质量进行评估
●测试组建议——从测试组的角度为项目组提出工作建议
测试主管完成了符合标准的测试报告，发送给项目经理，软件负责人
3.3.2测试工作总结
测试总结工作是在以上的工作全部结束以后，它的目的是评估本次测试工作，总结经验，使下一次的工作做得更好。
测试主管完成了符合标准的测试报告，发送给项目组
●测试工程师总结测试中发现的问题，将常见的问题记录下来，作为下次测试的参考及重点测试项
●测试工程师提出功能/界面改进建议
●测试工程师汇总本项目发现的需求问题
●测试组分析遗漏的测试用例原因，避免下次遗漏
●测试主管汇总测试工程师的总结，结合项目过程中自己发现的问题和不足，编写测试总结文档
测试主管完成了测试总结，发送给测试组
测试主管、测试工程师
3.4缺陷跟踪
测试验收结束后，跟踪产品在试运行阶段暴露出来的新缺陷，以及已提交的缺陷是否再次发生。
测试组完成了所有的测试实施工作，测试验收通过，产品试运行、运行。
●已发现缺陷是否再次发生
●是否有新发现的在测试中未发现的缺陷
●是否有新发现的在测试中已发现但未修改的缺陷
定义：
A类：
新发现的缺陷
B类：
已发现的缺陷再次发生
C类：
已发现未修改的缺陷
缺陷跟踪报告
项目经理、测试主管
4争议处理
如开发团队对测试结论有争议，由项目经理、软件负责人、测试主管协调解决，项目经理具有最终决定权。
5标准文档
1.《测试计划》
2.《测试用例》
3.《测试报告》
4.《设计变更表》
5.《测试工作总结》
升级会员 