一、无线上故障

• 灰度放量

• 监控：接口监控/巡检、埋点、自动化能力补齐

  • 报警及时性

  • 先止损（及时回滚服务、热修、关闭入口等）

  • 后排查定级

二、无严重线上bug

• 需求评审：

  • 需求详评测试一定要参与，提前熟悉需求且能尽早参与就尽早参与

• 测试前：

  • 技术方案的评审要参加（需要开发、测试以及影响的三方业务参与）

    • 提前了解影响范围

    • 确认涉及到几方，依赖方都有哪些；

    • 依赖方有无代码修改/测试参与，需要做好兜底策略，风险预知；

    • 提前了解回滚策略及方案；

    • 本次需求涉及几个工程有改动、都改动的哪些代码逻辑；

    • 关注动态下发、缓存、消息队列；

    • 本次需求是否有数据库及表结构相关的改动，对现有业务是否有影响，改动是否都有兜底；

    • 迭代需求需要支持快速回滚且不影响线上已有功能；

  • case评审（三方、共同评估影响范围）+ 周知 + 自测   

    • 需要产品、开发、测试共同参与；

    • 确认是否需要单独做安全测试；

  • 测试设计：case完成后创建测试计划、开发自测case都执行完成；

  • 对于迭代比较频繁的需求，开发人员和测试人员均有变动的情况下，尽量确保测试人员对于需求的了解要足够全面，能够覆盖整个逻辑；

  • 测试需要代码review，做影响范围评估；

  • 开发提测的代码需要自己内部提前review（防止出现测试完了，开发内部review不通过，结构全变了，又需要重新测试的情况）

• 测试中

  • 每日进度同步：及时周知风险，通知开发和产品，对齐歧义点

  • 比较大的需求需要每天定时同步进度/组织站会

  • 关注时间风险安全风险

  • C端相关要考虑通用逻辑、兼容

• 上线前

  • 需求上线前检查所有资源完整；

  • 对齐：提前申请资源、check上线sql、上线顺序、上线服务、配置、开关

  • 测试代码和上线代码必须是一致的

  • 补齐自动化覆盖（测试环境、线上环境）

  • 大需求组织众测（众测手册输出、众测环境搭建、众测报告产出）

三、上线后质量保障

• 上线后

  • 监控：接口监控/巡检、埋点、自动化

    • 关注报警及时性

    • 先止损（及时回滚服务、热修、关闭入口等）

    • 后排查定级

• 回滚策略

• 线上问题优先排查

四、后续工作

• 定期组织复盘、团队内分享；

• 需求总结、常见问题解决方案汇总。