技术方案评审（DDD或ADD评审）

1. 提供相关的方案文档 @测试 @架构参与评审，评审后，所有问题被解答和落地才算真正评审通过；

2. 明确渐进式提测，增加相关功能和接口的易测性； @测试 @开发

3. 明确相关工具的使用和mock的使用； @测试 @开发

技术方案评审通过

1. 全部通过，开发开始进入编码阶段 @开发 @架构 @测试

2. 测试提供测试方案和相关的测试具体方法 @测试

第一次内部代码review

1. 时机最好为第一个接口完成后立即内部代码review，参与人可以为架构、测试和内部需要了解该服务的技术人员； @开发 @架构

2. 数据库数据表规范：commmet必须要在创建表时创建，在字段更新时，必须更新相关comment字段（mysql数据库）；@架构@开发@运维

3. 依赖第三方服务mock提供，根据easy-mock平台，开发提供相关的涉及三方或者其他未完成服务的依赖接口返回情况和调用数据；@测试 @开发

4. 代码可以支持硬代码切换环境，以便在真实联调时，能够自动切换真实调用依赖； @测试 @开发

5. 开发和主要测试负责人：单元测试要求，单元测试覆盖率大于80%； @测试 @开发

6. 接口文档，接口文档中，哪些字段为必填，哪些字段为选填，接口操作数据表明确； @开发 @测试

7. 开发或架构提供本次涉及服务的中加解密工具或方式，不提供则测试不接受提测该涉及的部分； @架构 @开发 @测试

最终代码review通过，开发提测

满足以下条件：

1. 单元测试成功率100%，覆盖率80％；@开发 @测试

2. 接口全部自测通过，成功率100%；@开发

3. 与服务消费方无任何理解差异 ；@开发

4. 数据库表符合要求；@开发 @运维 @测试

5. mock依赖清晰，环境切换正确；@开发 @测试

6. 分支代码拉取，本地成功build；@开发 @测试

7. 测试用例评审通过； @开发 @测试 @架构

8. 整理Case，标出高优先级Case @测试

提测成功，进入正式测试（偏服务整体测试）

测试开始对接口、服务中的分布式解决方案、服务中的中间件等的风险点进行测试和度量 @测试 @开发

测试同学在方案评审通过后到成功提测过程中的涉及事项：

1. 在渐进式提测过程中，开发PACT（可以基于开发提供的单元测试或者双方的约定文档）；

2. 代码风格和结构的review；

3. 相关业务逻辑的整理和review；

4. 接口测试的准备和测试，为下一步的接口自动化提前准备好相关数据和代码准备；

5. 静态代码扫描以及单元测试覆盖率确认统计；

6. 服务项目风险的发现和上报；

测试通过

1. 单元测试成功率100%，覆盖率80％ ；@开发 @测试

2. 接口测试通过率100%，场景覆盖100%；@开发 @测试

3. 分布式解决方案、服务中的中间件等的风险点分析清晰，测试覆盖率 90%；@开发 @测试

4. 服务性能测试满足各方要求； @业务方 @运维 @架构 @开发 @测试

5. 通过故障演练，降级、熔断处理经过测试参与，通过； @运维 @架构 @开发 @测试

6. 业务方接入相关服务无错误 @开发 @测试