互联网大厂需求测试流程规范

实习期间第二天就接触到的真实企业级别的测试流程梳理，Leader指派了mentor专门给我们两个实习生一块去会议室讲解一些最基础的业务知识以及测试基础，在之后的工作接触中，不断加深测试对流程的理解。

1、需求评审

  产品这边收集好需求，然后拉产品、开发、测试一块进行会议，产品主持开一个需求评审会。

  对产品需求设计方案进行评估，收集意见。开发对需求进行提问，对不明白的地方进行追问，了解需求，方便后面进行技术设计以及实现，测试也需要从测试的角度考虑，追问这个需求是否具有可测性，能否开展测试工作，通过后进行下一步。

2、技术评审

  在上一步需求评审完毕之后，开发人员对需求进行技术评估、技术方案设计，看一下需求是否能够实现，使用什么技术来实现，实现的方案具体是什么，具体的开发时间周期是几天，怎么安排。

  开发拉产品、测试主持一场技术评审会，形成技术方案设计文档进行阐述，产品人员初步判断这个实现的过程是否符合需求的设计，测试需要对开发的方案进一步了解，明白测试的场景和时机以及预期的结果、明白后续如何开展测试用例设计工作。

3、开发、测试用例设计

  开发人员确定好需求进行正式的 代码开发阶段，

  测试与开发同步开展任务，确定好最终需求后 进行设计测试用例（这个过程中需要测试一直与开发进行同步沟通，哪里不清楚不明白及时问，把需求搞明白，测试用例设计清楚），使用 xmind 进行设计用例，使用公司内部平台QAMP 创建迭代、任务、关联需求、关联用例集

4、 测试用例评审

  测试用例设计完之后，要进行用例评审，必选需求的产品测试开发，将评审的用例提前对应人员熟悉，并针对性的进行答疑或者沟通，组内有专门记录用例评审的同事来参与。

（1）对照需求文档和技术文档，将用例与产品和开发对齐，确保测试点不遗漏。P0用例标红、接口协议字段单独评审、马达开关、A/B实验、埋点验证等一一确认。
（2）测试的主持人对于疑问意义解释清楚
（3）对于有争议的点、不确定的内容，5分钟没有结论的，测试主持人及时中断，作为TODO
（4）评审后 测试用例及时更新到飞书文档中，做好记录，及时更新TODO项，并@研发或者产品

5、开发自测 （showcase）

  测试人员写好了测试用例之后，P0级别的用例（优先级别最高）要专门标注出来，开发这边做好需求，要拿着我们P0级别的用例去自测，开发自己走一遍用例看 核心用例是否能够跑通，要是不通过说明根本没有测试的必要，再进行修改。

  开发人员这边测试没有问题之后，然后拉产品、开发、测试一块进行线上会议，进行演示，演示开发这边做的功能都实现了主要的需求。

（相当于冒烟测试，开发人员自测，之后演示，各方都没有问题，进入到提测环节）

6、提测

开发完成需求之后，自测也完成，在质量管理平台上进行提测。需要给测试发送提测包来进行测试环境的验证工作。如果测试不认可提测需求，可以打回。

7、增量测试

主要是针对于本次需求的功能测试

测试人员在测试环境 手工或者自动化执行测试用例，记录预期结果，发现bug进行确认。

这个阶段各个业务功能没有进行集成到某个版本中，只是单条业务线进行测试。遇到问题随时和开发进行沟通确认。

8、发送业务需求测试报告

  在质量管理平台填写需求测试模版，作为本次需求的增量测试报告，发送给开发、产品等，包含测试结论、测试环境、风险评估、测试范围、发现bug问题、静态扫描、覆盖率 ）

9、产品验收

本次需求增量测试没有问题之后，开发就可以正式把代码merge到 master分支了，最后可以等其他业务线完成需求后打出一个集成包交给产品进行验收本次需求。

10、集成测试+回归测试（全量测试）

不同业务都要集成到一个app中，我们在单测的时候可能没有问题，此时需要将几条业务线（每条业务线可能都有修改的需求）集成到一个应用包（一般会发集成的测试包和release包，有一点区别就是测试包可以抓包，release包不能抓到报文）

对集成包再次进行测试，可能不同业务之间还会影响，所以要进行集成测试，查看集成包中需求是否受到影响。

打出集成包之后，在测试环境还需要进行

• 稳定性测试（monkey随机测试或者设计稳定性测试场景8小时查看日志是否有crash或者崩溃卡死）

• 性能测试（拖图、快进快出、或者正常操作开启性能测试数据，最后查看fps、cpu、memory数据是否波动异常，满足小于5%的起伏满足准出）

• 兼容性测试（在不同机器上、不同型号、不同系统版本，都查看本次需求是否正确）

• 等等。。。

  这个需求的集成测试也没有问题之后,开始执行回归测试，对照回归用例查看其他功能是否影响。

  如果用例数目几百条，每个环节都要重复执行起来很费时间，所以还可以使用自动化脚本进行测试，可以提高效率。（公司是使用的jenkins流水线平台来走的这一个部分，当开发在 git merge的时候自动触发流水线任务，直接执行我们在平台写的代码扫描、接口测试、UI自动化脚本，然后将自动化执行的流水线结果直接发到飞书群。最后自动生成测试报告，返回流水线通过结果）

11、编写集成测试文档

集成以及回归测试完成之后，已经完成本次需求的所有测试流程。

没有问题的话就要记录一个飞书文档对本次需求的功能/性能/稳定性/兼容性分别填写测试报告和测试结论，

我们编写完测试报告文档，对于本次需求进行完整记录。

12、灰度上线

• 上线先进行放量限流、白名单等机制进行产品的试用。
• 选择性的将应用上线到应用商店进行使用，放到oppo商店，不放华为商店、不放vivo商店等之类的，控制流量

比如先允许100个用户进行使用，如果10个以上用户都反馈有问题，那么就不进行正式上线，重新回去测试调整。

13、正式上线

放量的过程没有问题后，交给负责人进行正式的上线，上线到对应的应用商店中供用户下载。

• 如果正式线上有问题，采用降级方案对其进行处理
• 一般在技术方案评审会有一个兜底的降级方案，降级方案一般会在增量测试的环节进行验证。
• 马达配置关闭（开发控制）
• A/B实验关闭 （产品控制）

14、线上环境监控

在真实的线上环境可能还会有问题，所以还要进行线上持续监控，发现是否存在线上问题。