分享一下目前正在执行中的需求评审到发布的测试流程，主要是针对产品开发，项目开发的流程跟这个稍有区别。
需求评审
组织者：产品经理
参与人员：开发、测试、产品经理、相关领导
目的：确认需求是否完整、业务逻辑是否合理
通过标准：需求不存在逻辑漏洞，文档相对完善
作为测试人员可以做的事情：①提前阅读需求文档；②评审前或者评审中积极参与讨论，提出建议；③需求明显不合理的情况下有勇气拒绝；
任务拆分和评估
- 组织者：测试负责人（master）
- 参与人员：开发、测试、产品经理
- 任务拆分原则：可独立测试；必现实现和可选择实现的任务分开；可以发布和暂时不能发布的任务拆开；拆分后的任务可评估，不能太大；
测试方案和用例设计
- 公司内部统一测试用例编写方式，便于后期管理和维护；
- 尽量指定同一个人来编写，可以保持用例设计方法一致，后期维护快捷；
- 统一测试用例编写工具。
- 测试方案模板统一。
测试方案和用例评审
- 组织者：方案和用例设计者
- 参与人员：测试领导、测试人员、开发、产品经理
- 目的：用例和方案设计是否合理，逻辑是否清晰；覆盖率是否达标，有无遗漏点；对需求文档理解是否一致；
冒烟测试 -
执行者：开发或者测试人员
目的：冒烟通过是测试准入的标准，如果冒烟都不通过，那么就没有必要浪费时间了。
通常公司都要求开发自测，如果开发一直说已自测过，但是经常冒烟都不通过的情况下，测试可以提供一些冒烟用例给开发进行自测。
系统测试 -
- 执行测试：测试人员
- 测试方式：手动或者自动
- 注意试项：用例需要标注通过或失败；有问题必须建issue，不能口头通知后直接进行修改；
测试报告
- 编写人员：测试人员
- 注意试项：测试报告格式统一；包含发布风险和测试结果；包含依赖服务编排和测试通过编排；还可以增加更多的质量统计数据；
预发布环境验证
- 执行者：测试人员
- 目的：防止升级失败；一定程度上可以发现程序里写死某些环境变量的问题；验证开发提供的升级流程和运维编写的发布脚本是否正确；
最后附上流程图一张
