背景
在你们的团队中是否有这样的问题？你们是怎么解决的，希望和大家一起交流。
天天在谈测试技术，回过头来发现，技术背后的基础是测试最本质的内容：测试用例。
从我工作到现在，做了将近 3 年的产品测试，一直都在研究测试技术，如果突然有一天产品质量发生雪崩，让我们开始思考原因：
为什么：产品出现 BUG；因为：测试发布了带 BUG 的线上产品
为什么：测试发布了带 BUG 的线上产品； 因为：测试用例不完善
为什么：测试用例不完善； 因为：？？？？？
接下来让我们聊聊研测流程吧~~~
项目通过研测流程
流程关键节点说明
- QA同学，完成测试分析/用例编写后，需要组织项目组开发、产品用例评审；
- 用例评审完成后，QA从用例(P0)筛选功能核心用例，导入到禅道/JIRA中，作为开发自测用例。
开发自测完成后，由测试负责人或项目owner审核，满足『提测准入条件』后，才可以进入测试阶段。- 测试
冒烟不通过(发现严重、或严重阻塞测试问题)，测试有权驳回提测，测试通过后，进行第一轮全面测试。 - 第一轮全面测试完成后，Bug关闭率达到85%，没有已知P0&P1严重问题，可进入回归测试。
- Bugfix验证版本提测数量需要控制，
建议每日软件版本数≤2个，特殊情况(如定位问题加打印日志)除外。 - 回归测试，采用的用例集采用非全量用例(P0)，还是全量用例，据全面测试发现问题多少及提测质量而定。
- 定版测试，如果Bug关闭率达到90%，没有已知P0&P1严重问题，该版本可作为最终发布版本，开发冻结相应代码；定版测试期间，根据质量情况，研发可组织最终的代码评审，业务方可组织进行最终的业务验收。
定版测试通过+UI/业务方验收通过+发布评审通过，项目发布成功。
约定与要求遵循
- 各个公司按照编码规范进行编码，开发自行遵守。
- Bug解决时效要求，
P0/P1级Bug 12小时内需回应，原则上24小时内解决；P2级以下(含P2)24小时内回应，48小时内解决，响应是指解决处理好、要么备注原因说明、要么转移给正确的同学。 - Bug root cause，需要在备注栏写明清楚。
- Bug reopen率≤5%。(根据业务实际情况定)。
提测准入条件
-
测试环境(测试数据、测试机)等满足测试条件。
-
开发自测用例（一般从P0级用例筛选，
同时确保覆盖到项目P0需求主要流程,避免冒烟范围过小虽而影响后续测试效率）原则上用例执行覆盖率需要达到
100%，如有特殊原因未达到标准，需要提前沟通。 -
开发自测用例执行通过率>=90%以上，不存在已知严重问题，或阻塞测试无法执行的问题。提测邮件，必须包含不限于releaseNote，自测报告，提测软件信息，测试依赖的操作方法(如三方环境依赖)，测试建议等。
-
说明：未满足以上条件的，提测无条件驳回提测申请。
发布通用标准
- 无P0/P1 级别BUG
- BUG解决率≥90%
- UI/业务验收通过
- 项目组发布评审通过