软件测试的工作流程

一、评审阶段

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、无法满足变更需求

一个迭代周期，变更后导致新增功能点过多，评估任务计划无法在交付时间点完成，需要向产品反馈，要求分优先级进行开发，低优先级的下一个迭代周期完成。

如果产品分不出优先级，默认都不重要，请产品向项目经理反馈，申请资源