站在QA的角度浅谈软件测试流程

背景

在你们的团队中是否有这样的问题？你们是怎么解决的，希望和大家一起交流。

天天在谈测试技术，回过头来发现，技术背后的基础是测试最本质的内容：测试用例。

从我工作到现在，做了将近 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/业务验收通过
• 项目组发布评审通过