一、评审阶段
1、需求评审
要求在需求讲解前先将需求文档和DEMO提供，在讲解会议上同步进行评审。
2、任务计划评审
开发TL和测试负责人协商工时评估，共同制定里程碑任务计划表，发起评审
3、设计评审
开发完成简要设计文档，API接口文档，发起评审
4、用例评审
测试完成冒烟测试用例、系统测试用例、发起评审，对开发反串讲。
二、测试阶段
1、准入
单元测试、代码review（静态代码工具扫描，例如：sonar），冒烟测试用例，接口自动化用例，提供的自测报告需满足自测问题少于5个才可以正式转测试。
2、版本发布说明书
版本号、版本存放路径、版本修改点及可能影响的模块提供相应的发布说明书
3、版本打回
出现阻塞性BUG、L1、L2测试用例通过率低于60%，致命级BUG数>=2；严重级BUG数>=4；打回版本，并通报批评，修复完成并自测通过后再转测试
4、准出
A、需求覆盖率100%
B、测试用例执行率100%
C、L1与L2测试用例通过率100%
D、L3与L4测试用例通过率>=90%
E、sonar扫描结果全部A
F、缺陷修复完成率100%，已拒绝、已挂起的缺陷均已正确处理
三、上线阶段
1、上线评审
对功能测试报告、接口测试报告、数据测试报告、性能测试报告（优先级低、仅要求新项目上线提供，需要架构参与）、安全测试报告、版本发布说明书进行评审、全部评审通过、才可以部署正式环境。
2、正式环境验证
A、B、C、D都测试验证通过，才可以正式上线。
A、线上接口巡检
B、线上日常测试
C、数据一致性核查
D、兼容性测试
3、输出经验教训
开发、测试对本次迭代进行复盘，新的经验总结和教训需要输出精简的文档
四、缺陷管理
1、问题单处理
被提单人当天需要确认是否为缺陷，不是缺陷的需要打回，确认为缺陷的尽量当天修复完毕
2、自测
改完代码、需要先自测通过，才可以修复问题单状态，让测试回归
3、确认修复代码已提交
测试人员回归测试通过后，检查是否引入新的问题。再跟开发人员确认修复的代码是否已经提交
五、变更管理
1、产品变更申请通知到位
产品需要邮件通知相关对应人员、并将变更内容更新到需求文档
2、落实到位
开发TL、测试TL共同协商调整任务计划，并分配给对应负责的开发、测试人员
3、无法满足变更需求
一个迭代周期，变更后导致新增功能点过多，评估任务计划无法在交付时间点完成，需要向产品反馈，要求分优先级进行开发，低优先级的下一个迭代周期完成。
如果产品分不出优先级，默认都不重要，请产品向项目经理反馈，申请资源
转载：https://blog.csdn.net/luoxuexi2020/article/details/116104153