1 编写目的
制定完整且具体的测试流程和规范指引，为快速、高效和高质量的软件测试提出基础流程框架，最终目标是实现软件测试规范化、标准化。
明确测试团队各个角色的工作内容，并具体指引工作细则；优化岗位设置，明确岗位职责，合理配置人员；加强沟通协调，提高工作效率。规范工作标准，提升产出质量与工作成果。
本规范内容根据实际工作变化情况，与提出的优化修改建议，不定期更新并发布，目前要求每半年更新一次。

2 测试组职能与岗位职责划分
2.1 测试组职能
软件测试是软件开发过程中的重要组成部分，测试团队主要肩负着如下责任：

2.2 岗位职责
在人力资源有限的情况下：

一个团队成员可能会同时担任同一项目里面的多个角色（岗位）；
或者一个团队成员可能会担任多个项目里面的同一角色（岗位）。

3 软件测试流程及规范
3.1 测试流程

3.2 过程规范
测试相关人员把测试工作前置到项目的开始阶段，提早介入测试，尽最大可能提高工作效率。测试规范根据项目&测试组目前实际情况（包括资源，成本等）制定，根据内部业务与规模的发展不定期做相应的调整。

3.2.1 需求分析
在项目的需求评审阶段，测试人员需要参与需求评审，把测试工作前置，让产品、技术、与测试人员对需求文档的理解达成共识。

3.2.2 设计评审
在项目的设计阶段，测试编写可行的测试计划与方案，测试用例。

3.2.3 SIT 测试
测试工程师根据测试计划和测试用例执行测试，当日提交当天的测试记录到缺陷管理系统中，测试主管根据项目的具体进度，适当调整测试计划。

3.2.4 UAT 测试

3.2.5 上线与验收
测试人员与产品负责人进行上线验收测试。验收通过后，才能正式对外公布功能上线。

3.2.6 注意事项
原则上，上线版本需经完整的测试流程方可更新到正式环境。只有紧急情况下才可先更新正式环境然后再提交给测试人员进行补测。补测过程与正式提测过程一致；
原则上，测试人员不得直接修改测试环境数据库的数值、服务器系统时间等，去检验回归的问题；
原则上，不允许本次提测的版本中又再加插其他测试内容，除非是紧急需求变更或者是修复正式环境的某个严重的缺陷。
报障后，第一时间做好测试跟进，并把问题填写到缺陷管理系统上（Tapd）或指定 confluence 的 QAC 文件夹中，要添加报障日期、问题状态等关键字段。
测试组内部不定时针对生产环境问题做好总结分析，做测试改进。
3.2.7 生产环境问题处理
3.3 处理机制
3.3.1 退回机制
若在测试过程中发生如下情况，将系统退回到申请部门：
通常是指 1 级用例测试不通过，但具体要根据实际情况做判断。
经过测试后，发现与需求说明书中定义的功能项存在较大的差异；
单一模块，测试过程中发现缺陷较多或者无法继续进行系统其它功能模块的测试，继续测试无意义；
测试过程中频繁死机或者系统崩溃；
主业务流程不完整。

3.3.2 异常情况处理机制
非正式情况下，需要进行特别处理的形式：

上线后，生产正式环境发现紧急重大错误，需要马上修改并更新正式环境的，可优先更新生产正式环境再提交修改后的版本到测试环境，让测试工程师再测试。
测试过程中发现测试需要的时间与计划的时间有很大差别，需要及时向项目经理、测试主管以及产品部的负责人汇报情况；
测试过程中测试工程师根据要求和约定，及时有效的汇报测试情况。
3.3.3 报告机制

3.4 测试完成标准
软件产品发布须符合以下标准：
完成计划中所有的工作；
实现了需求定义的所有功能特性；
完成所有的测试；
严重的缺陷都已修正；
新发现的缺陷趋于稳定并接近零；
产品、文档都已就绪；
达到其它行业质量标准，完成计划中所有的工作；
软件产品未经测试合格，有严重 bug 时，不允许发布：
一级缺陷、致命错误，100% 得到修改并且复测通过；
二级缺陷、致命错误，100% 得到修改并且复测通过
特殊情况由产品、开发、测试负责人等共同商议。

3.5 产出文档标准与模板
文档名称
对应模板
测试计划
测试方案
测试用例
测试报告