共计 829 个字符，预计需要花费 3 分钟才能阅读完成。
外围思路
标准并欠缺自测流程，将 Bug 扼杀在自测阶段，显著升高提测后的线下 Bug 率。品质和效率乍一看是存在抵触的，更高的品质要求会破费更多的工夫，但如果通过更多的自测工夫，来缩小测试和返工所占用的工夫，那么在晋升我的项目品质的同时，未必会就义效率，甚至还可能缩短整体工时
操作流程
- 在开发工作实现后，提测节点前，产出 Checklist 模式的自测用例文档，对照文档进行自测，通过所有查看项，并在每一项后打勾确认
- 提测时除了提供我的项目、分支等必要信息外，还应该提供该需要对应的自测用例文档和测试后果，方能提交测试，否则测试人员有权打回本次提测
- 留存自测文档，如果提测后品质问题仍然重大，不便复盘总结经验
执行依赖
- 测试人员需在提测前提前产出标准的测试用例文档，并组织评审会议进行对齐。因为开发人员自行编写自测用例是十分低效、且很难零碎笼罩大部分 case 的，故而自测用例文档是在通过评审对齐后的测试用例的根底之上，进行扩大的。并且较早的产出测试用例，也有助于开发人员尽早躲避一些异样，晋升开发效率
- 提测打回机制。为了束缚并标准自测的执行，测试人员应该领有打回提测的能力，并能够针对显著没有自测，但已显示自测通过的状况发动复盘
- 品质问题定期统计和总结。如果在自测后提测，仍然存在较高的 Bug 率，应该总结起因，是测试用例覆盖范围不够，还是开发人员没有用心自测，或者其余什么起因，有总结才有执行力束缚和将来提高的空间，对测试团队和开发团队都有晋升
- 明确执行范畴。品质和效率是存在肯定水平抵触的，谋求极致的品质很可能会就义开发效率，这须要寻找平衡点，故而并非所有我的项目都依照自测标准来执行，具体执行规范能够依据团队状况制订
后果预期
- 显著升高提测期间的线下 Bug 率，争取将问题都解决在自测阶段
- 无效升高线上 Bug 率，越来越欠缺的测试 / 自测用例，以及开发 / 测试人员的二次执行确认，确保常见流程不会呈现问题
- 综合开发效率晋升，自测尽管会缩短一部分开发工夫，但能无效升高测试和返工工夫，整体效率取得晋升
正文完