测试流程规范建议

测试流程规范建议
关于测试流程规范的讨论，可查看敏捷测试话题中的# 提问：测试活动的价值流是什么？#
该话题主要探讨了测试活动的价值如何进行流动，经过了哪些阶段，每个阶段要做些什么，每个阶段的准入标准是什么。
一、测试流程
经过话题的讨论，总共有以下几个流程出过：

对以上四个流程进行整理后，大致得出测试流程为：
需求阶段 —> 测试准备阶段 —> 测试执行阶段 —> 上线阶段
如果存在发布和复盘，可扩展为：
需求阶段 —> 测试准备阶段 —> 测试执行阶段 —> 上线阶段 —> 发布阶段 —> 复盘阶段

二、测试阶段
各阶段从何时开始以及都包含了哪些活动
需求阶段
需求前期：
需求文档还未形成之前，可先提前了解后续大致的需求内容，依据之前的经验，针对这些内容提出合理的见解及看法。在提建议和看法前，最好能先思考可行的解决方案。
需求宣讲之前，先把需求文档过一遍，了解需求背景，思考本次需求的必要性，列出疑问点，找出需求不合理或者遗漏的地方，会上进行讨论。
需求分析：
检查需求文档 、原型图、 UI 图 ，宣讲时提出的问题是否已完善到需求文档中，是否还存在描述不清楚或者有矛盾的地方，找产品核实和确认，无法及时回复的记录下来持续跟踪。
分析需求的合理性以及完整性， 针对需求提出自己的看法。
需求确定：
跟踪以上提出的关于需求的问题，沟通需求内容，与产品、开发对本次的需求达成统一的认识。

测试准备阶段
测试范围：
基于以上确定的需求，整理测试思路，确定测试范围。其中的测试范围包括本次需求覆盖的范围及本次需求可能影响到的范围。
选定测试策略，确定本次测试侧重点，预估工作量，评估大致时间节点（后续根据实际情况动态调整）。
用例设计：
根据需求编写测试用例。目前公司使用的测试平台是OTP，基于OTP形成了一些规范以便于后期的维护，编写规范可参考：用例在OTP上的运用以及规范
标注用例等级。
根据测试范围和影响范围生成用例评审计划。
对于一些公共的测试元素，可以形成一些设计规范，如：后台页面测试规范 。也可以运用OTP的公共用例库，形成一些公共的用例模板。
用例评审：
记录问题评审中提出的问题，修改错误的用例，补充遗漏的用例，删除多余用例。
梳理测试流程，强调重要测试场景，与开发和产品确定本次需求的验收标准。验收标准可参考：产品验收规范
完善用例：
针对用例评审结果，修改用例。
通过开发同学的设计文档、设计思路、开发框架了解开发实现，评估可测试性，补充测试点。
扩展思维，多角度（如：并发问题、性能、安全、审计等方面）思考，不断扩大测试范围。
测试计划：
生成开发自测计划。一般涵盖的是主流程的测试用例和一些重要功能的用例。
生成冒烟测试计划。基本同开发自测计划。
生成常规测试计划。应包含本次测试范围+影响范围的所有测试用例。
生成预生产测试计划。应包含常规测试中一些重要的测试用例，和测试环境出现问题较多的模块。
生成验收测试计划。根据评审时确定的验收标准筛选的测试用例。
测试预热：
准备测试数据、测试环境（配置中心值、基础数据等）、测试场景。
若被测系统与其他系统存在交互，则应该提前与其他系统测试人员进行沟通，确定系统间的测试职责划分，避免重复测试或者遗漏测试。
根据情况，可提前开始接口测试或者提前开始设计自动化测试脚本。自动化测试脚本规范可参照：自动化测试项目简介
跟踪开发进度，保证在约定时间点提测，开发自测计划由开发执行，须在提测之前执行完成。

测试执行阶段
冒烟测试：
由测试执行，开发提测之后可先进行冒烟测试，提前发现主流程问题。冒烟测试存在严重问题，可打回给开发，拒绝提测。
测试环境：
由测试执行，原则上须在上预生产之前完成所有用例，部分用例无法执行的可酌情在预生产环境中测试。
期间产生的Bug，根据Bug管理规范进行处理。Bug管理规范请参照：（待补充）
尽量实现自动化，后续也会对自动化覆盖率进行统计，帮助完善自动化测试用例。
沟通与协作：
对于需求问题，积极与产品和开发进行沟通，及时报告进度，反馈风险。
推荐产品、开发、测试能够参加每日站会，及时反馈问题，暴露风险。
预生产环境：
由测试执行，原则上须在上线之前完成所有用例，部分用例无法执行的与产品及开发沟通解决方案，方案落实之后根据方案
进行处理。
在时间允许的情况下开展探索性测试。
协助验收：
协助产品进行验收测试，评估是否达到上线标准，参照：产品验收规范
制定上线计划，上线计划应包含上线计划、发布计划、线上验证范围、应急处理方案、回退方案，尽量保证项目能够完美上线。

上线阶段
线上验证：
慎重！有条件的话，一般只会做一些简单的验证操作，禁止出现高危操作，对于未知的操作不盲目操作，必须保证对线上环境的0影响。
线上监控：
通过公司的监控平台hawk-monitor使用手册，观察系统是否运行稳定，一般会看下项目是否有报错，各项机器指标是否正常等。
线上问题处理：
线上问题处理第一处理原则，将影响降到最低。对于没有把握的操作，及时请教相关人员。
根据验收标准，确定问题处理方式，一般有：终止上线回退版本、修复后再次上线、确定修复时间继续上线。

发布阶段
如果公司有采用灰度发布的话，才会有这个发布阶段。
线上监控：
观察是否根据上线前制定的发布方案，正确的进行了发布，灰度范围是否正确。
其他同上线阶段的线上监控。
收集反馈：
收集业务方反馈的问题或者是优化点，针对这些与产品及开发确定排期。
是否可全部发布：
根据发布方案，评估是否可以进行全部发布。

复盘阶段
对本次需求进行梳理和总结，继续完善测试用例并归档，形成知识文档（业务知识建议放在自己部门下），定期进行分享。
缺陷统计：
遵守缺陷管理规范，可以使缺陷统计更加精确。
对Bug进行分类，多维度、多角度进行Bug的分析。
质量分析：（待补充）
改进措施：
针对复盘会上提出的问题，做出相应的改进措施并且落实。
在下一个复盘中，回顾改进措施的执行情况，进行适当调整。

以上的测试活动并不局限于在某个阶段进行，执行的顺序也是根据实际情况灵活运用，更多的还是要思考怎么让测试发挥出更大的价值。

三、准入标准
在进入每一个阶段之前，需要达到的标准：
测试准备阶段准入标准
有完善的需求文档，功能描述清晰，有明确的需求范围，对于本次的所有需求，三方已达成共识。
如果本次的开发活动有可能对原先的功能产生影响，需要开发列出明确的影响范围。

测试执行阶段准入标准
对于需求的排期已做出初步的预估。
在测试执行之前，用例已经完善。
已确认本次需求的验收标准。
生成上面列举的测试计划。
开发完成自测，正常提测且测试环境已准备好。

上线阶段准入标准
完成多轮次的验证和产品验收测试，符合验收标准。
所有不影响上线后功能正常运行的Bug均已解决，且遗留Bug经过讨论，已经确定解决方案和排期。多方评估达到上线标准。
上线计划制定完成。

发布阶段准入标准
已完成上线，项目运行稳定，并且评估后确认可进行灰度发布/全部发布。