测试规范

2.1 测试前：

• 需求评审：

理解业务是第一要义，在梳理清楚需求点以及交互后，可以尝试做下面的事情（挑重点需求，毕竟没那么多时间）：思考如果是自己来设计技术方案该怎么做（包含不限于 ① 主流程的时序图 ② 涉及的接口，每个接口要处理的核心逻辑以及用到的中间件 ③ 会有哪些异常场景 ④ 自己的方案可能会产生或者无法解决什么问题）。

我认为这个过程很有帮助：1）主动思考后产生的想法和问题，会让后面的技术评审、用例编写等环节更充分有效，不会变成 QA/RD 一方的表演，会碰撞出很多隐藏问题 2）不断提升自己的技术能力与业务理解，一方面可以发现更多系统设计上的缺陷 提升代码质量，另一方面大部分的测试平台会使用与业务一致的技术栈，在平台开发时更加得心应手 3）与研发可以平等交流，增进信任度。很多业务线研发认为 QA 只会点点点，往往并不愿意与 QA 进行很深入的交流，QA 在推动质量专项时也会很被动

• 技术评审：

在这个环节 QA 需要搞定这几件事：1）熟悉 RD 的技术方案，先看技术方案完备度（应该有一个技术方案模板） 2）主流程是否遗漏或存在逻辑漏洞 3）结合自己此前的思考，将疑问与 RD 交流

• 用例编写：

我一般写服务端测试用例的思路是：

1. 【新】依照时序图，将一个完整流程按拆分为独立的多个独立模块/接口
2. 【新】对于每个模块/接口，列出接口文档、接口核心改动逻辑、数据存储&中间件校验点以及异常场景，标注优先级
3. 【回归】反模式补充：结合之前踩过的坑以及线上问题，补充 case
4. 【回归】主流程：结合测试模板，加入主流程的回归 case
5. 在这个过程中，如果对技术方案或者需求有些疑问，阻塞的即使沟通，不阻塞的在用例评审时沟通
6. 脑海里提前过一遍测试可能遇到的可测性问题，给一个初版解决方案

• 用例评审：

提前发出自己的用例，评审时 P0/P1 逐条过，P2/P3 如果太多可以简要过（毕竟精力有限，如果上百条无关紧要的 case 也要挨个念，RD 可能会抓不到重点），将自己的疑问都沟通明白

• 准入：这没啥说的，按照准入标准（自动化、冒烟用例、静态扫描、FTF）缺一不可

测试中：

依照测试用例严格执行（测试 Case 需要有明确的校验点和可执行性），测试过程中可能用到的方法：

• postman、charles 等接口工具，也有 rpc 转 http 的工具
• 代码 debug
• Mock 数据（上下游、系统内、第三方）
• 端到端测试
• 日志分析
• 代码覆盖率
• 使用各种中间件工具（DB、MQ、Cache、ES……）

测试后

1. 准出：

   自动化+FTF+行覆盖率+代码扫描+缺陷修复率+用例执行率+是否通过代码 review

2. 上线：

   分级发布，观察日志，及时回归

3. 补充核心功能自动化用例、压测…