这只是手段，核心是让开发联调自测，不自测 bug 当然多，就不准提测，那测试应该提供冒烟用例，冒烟用例不通过就打回，打回要发邮件让领导知道提测质量差，具体到那部分功能谁负责开发导致打回的。写那么多隔靴搔痒的东西都没人当回事。

一、通常都是针对提测，打回也是不符合提测标准，比如：

1. 单元测试未通过。
2. 静态代码扫描未通过。
3. 自测用例未通过。
4. 产品验收未通过。 （1 和 2 因修 bug 引起的，不算，但是测试准出要卡住）

二、一旦进入测试阶段，那都按 bug 处理，因为涉及的因素很多，比如

1. 团队能力成熟度。
2. 项目性质。
3. 核心/非核心业务。
4. 组织意志。

三、比打回更重要的是带领整个团队提升质量意识，形成质量文化。

1. 线下质量提报。
2. 线上质量运营。
3. 过程质量跟踪。
4. 质量可视化分析。
5. 代码质量减少低级问题。

四、质量体系的重要性

1. 流程上可以持续进行过程改进和缺陷分析。
2. 测试左移、右移标准建立。
3. 质量通晒，周报/双周报体现各团队的差异。
4. 共性问题分析及治理。
5. 专项/横向或某些疑难杂症/技术攻坚。（我很讨厌专项和横向这两个词，听了 7、8 年了）
6. 有空再说。

五、总结
这个范围太大，一时半会儿说不完。打回只是其中的一个手段，如何逐步提升团队质量意识是一套体系的思考。否则，会陷入无休止的扯皮。可以从一个点突破，一步一步完善，提升自己的影响力，做好质量守门员，从救火到防火。

附赠
情商也得在线，村里还是人情世故的社交，思考一下如何做一个让团队即不讨厌又能解决问题的优秀工程师。

本来是没打算做到这一步的，但是新来一批人，开发质量真的很差才不对应开始制定这样的制度

一楼已经给答案了，就是提供冒烟用例给开发，他们冒烟通过流程才到测试这边