如何从0到1建立和规范测试流程

本文分为两部分：前半部分是理想情况下完整的测试流程，后半部分是精简后的必要流程。

一、完整的项目测试流程：

在理想情况下，完整的项目流程是这样的：

如图，根据项目阶段，划分了产品、开发、测试等主要角色在项目的不同阶段对应的工作内容。

1、需求阶段

在这个阶段中，产品经理主导，测试跟开发参与需求评审。

在需求评审的过程中，需要了解需求的细节和设计逻辑，同时对于有疑问的地方要提出疑问，达成对需求理解的一致。

需求评审结束后，开发先评估工时，然后测试要根据需求文档并结合开发的工作量，来完成测试工时的评估。

排期表规范：

包含角色：产品、设计、前后端、测试等（根据具体的项目来定）

关键时间节点：

1. 产品：需求串讲时间，项目上线时间
2. 开发：开发起止时间，前后端联调时间
3. 测试：提测时间，测试起止时间

2、开发阶段

排期定好之后，就进入开发阶段了。

首先，开发同学会先出一个整体的技术设计方案，包含本次需求的设计思路和实现逻辑等。

这时一般会有技术评审的环节（开发主导，产品和测试参与），在技术评审的时候，可以对开发的技术设计提出疑问，从而获得更加全面的了解，了解越多，测试用例设计才会更全面。

技术评审之后，测试要制定测试方案（测试范围、测试手段、测试时间等）。

然后编写测试用例是很重要的一部分。

编写用例可以用excel或xmind，建议测试团队统一标准。

测试用例完成后，需要跟开发和产品拉会，进行用例评审。

用例评审的目的是找出遗漏点和逻辑理解不一致的地方，最终统一对预期效果的理解。

3、测试阶段

开发完成后，接下来就是提测。

在提测环节，建议制定测试准入（也称为提测规范）。

为什么要制定提测规范：为了规范开发的提测质量，加强前期质量控制，降低提测后因提测质量问题造成的风险。

测试准入标准（根据实际业务增减）：

1. 开发人员按需求及原型图完成软件的业务流程及功能的开发
2. 开发人员编码结束，并已完成单元测试，并提供自测功能报告
3. 软件的基本业务流程可以运行通过（冒烟测试），功能操作正确，且符合需求
4. 开发人员需提供软件的最新版本，并安装测试通过
5. 开发人员需提供接口文档、部署文档、提测申请、提测功能列表

提测质量达标之后，就正式进入测试了。

测试一般分为后端测试（接口测试）和前端测试，后端测试通过之后再进行前端测试。

怎样才算合格的测试，同样也需要制定测试准出标准（测试完成标准）

测试准出标准：

1. 所有功能和业务流程都按需求实现
2. 测试用例都已经执行完成，测试执行覆盖率为100%
3. 测试发现的所有 BUG 问题中，致命、严重、都已被修复且被验证通过
4. 允许遗留不影响业务流程的轻微bug，但是需要有解决方案及时间点
5. 完成测试后，出具测试报告

4、发布阶段

测试完成后，就进入发布阶段。

发布规范包含以下几点：

1. 发布时间：为了避免上线后有问题及时修复，发布日期建议避开周五及节假日前两天，上线时间避开用户活跃高峰期
2. 发布流量控制：为了避免线上问题影响到线上用户，建议小流量灰度发布，在线上回归没有问题后再逐步放量

项目上线后，建议做一次项目复盘，看看那些地方做得不好，要分析原因并找到解决方案；那些地方做得好，以后继续保持。

通过复盘这个环节，可以总结经验并更好地规范项目流程。

二、从0到1怎么做

从0到1 基本意味着以往的流程不规范，开发人员不愿意配合等问题。

所以想要在短时间内落实很细致完整的测试流程是很有一定难度的，那么就需要先从一些必要的和容易的环节入手，逐步完善。

1. 必要的环节：对项目的流程和效率影响大 2.容易的环节：产品或开发等角色容易做的，愿意配合的

下面，我们从【 需求→ 开发 →测试 → 发布】这个流程来理一下头绪

1. 需求阶段：
   1. 需求文档：要落实为文档，而非口头的，方便产品、开发、测试对需求有统一的理解和依据（有必要）
   2. 需求评审：开发、测试拿到产品的PRD⽂档后，需要提前阅读并标出有疑问的地⽅，在需求评审上提出并沟通达到⼀致。保证产品、开发、测试对需求的理解⼀致，前期的修改成本是最低的。
   3. 定排期：评估工作量，方便对整体进度有把控（有必要、落实难度不大）
2. 开发阶段：
   1. 开发设计：测试有条件的话应该参与到开发的设计评审和接⼝评审中，⼀⽅⾯可以达到理解开发设计的思路和逻辑，对之后的⽤例设计起到帮助，另⼀⽅⾯可以及早的发现开发设计上的错误和遗漏，将维护成本降到最低（建议做）
   2. 接口文档：开发要写接口文档，方便测试过程中查阅（有必要，落实难度一般）
   3. ⽤例设计：根据需求分解出测试功能点并标出优先级，根据功能点设计测试⽤例。
   4. ⽤例评审：测试⼈员针对需求写出测试⽤例之后，再让产品和开发review一遍，⽬的还是发现需求的遗漏点（建议做）
   5. 单元测试（开发自测）：在开发的过程中要做单元测试，避免小错误造成大的影响（落实难度一般）
3. 测试阶段：
   1. 提测：开发提测的质量也是⾄关重要的，如果出现⼀些流程性的问题，将影响到整个测试进度。接收到提测单后先将冒烟测试⽤例过⼀遍，没有问题⽅可开始测试，否则打回重新开发直到符合标准（有必要）
   2. 部署测试环境：需要跟开发同学沟通协助（有必要，落实难度可能较大）
   3. 测试并追踪bug：上线前需要开发修复完所有bug（必要环节）
   4. 测试报告：当项⽬达到上线标准时，应该出具测试报告发送⾄整个项⽬组，说明测试结果及存在的风险，并告知产品和运营进⾏验收测试，保证项⽬功能是符合预期的（必要环节）
4. 发布阶段
   1. 发布时间：选择合适的上线时间，出现问题方便及时修复（容易落实）
   2. 上线后跟踪：如果线上有反馈问题，测试应该及时跟进，通知对应开发最快速度修复和总结出问题出现的场景和原因（有必要）
   3. 总结复盘：把本次的问题总结归纳，下次项目流程中应该重点关注（建议做）

最后来一张图总结一下

如上，大致思路应该有了。

建议根据实际状况，先做容易的和必要的，推动公司产品和开发等角色共同完成基础测试流程的搭建，然后在后续的迭代中，逐步完善和优化，最终形成适合自己公司的测试流程。