核心思路
规范并完善自测流程，将Bug扼杀在自测阶段，显著降低提测后的线下Bug率。质量和效率乍一看是存在冲突的，更高的质量要求会花费更多的时间，但如果通过更多的自测时间，来减少测试和返工所占用的时间，那么在提升项目质量的同时，未必会牺牲效率，甚至还可能缩短整体工时
操作流程
- 在开发工作完成后，提测节点前，产出Checklist形式的自测用例文档，对照文档进行自测，通过所有检查项，并在每一项后打勾确认
- 提测时除了提供项目、分支等必要信息外，还应该提供该需求对应的自测用例文档和测试结果，方能提交测试，否则测试人员有权打回本次提测
- 留存自测文档，如果提测后质量问题依然严重，方便复盘总结经验
执行依赖
- 测试人员需在提测前提前产出规范的测试用例文档，并组织评审会议进行对齐。因为开发人员自行编写自测用例是非常低效、且很难系统覆盖大部分case的，故而自测用例文档是在经过评审对齐后的测试用例的基础之上，进行扩展的。并且较早的产出测试用例，也有助于开发人员尽早规避一些异常，提升开发效率
- 提测打回机制。为了约束并规范自测的执行，测试人员应该拥有打回提测的能力，并可以针对明显没有自测，但已显示自测通过的情况发起复盘
- 质量问题定期统计和总结。如果在自测后提测，依然存在较高的Bug率，应该总结原因，是测试用例覆盖范围不够，还是开发人员没有用心自测，或者其他什么原因，有总结才有执行力约束和未来进步的空间，对测试团队和开发团队都有提升
- 明确执行范围。质量和效率是存在一定程度冲突的，追求极致的质量很可能会牺牲开发效率，这需要寻找平衡点，故而并非所有项目都按照自测规范来执行，具体执行标准可以根据团队情况制定
结果预期
- 显著降低提测期间的线下Bug率，争取将问题都解决在自测阶段
- 有效降低线上Bug率，越来越完善的测试/自测用例，以及开发/测试人员的二次执行确认，确保常见流程不会出现问题
- 综合开发效率提升，自测虽然会延长一部分开发时间，但能有效降低测试和返工时间，整体效率获得提升
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。