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

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. 有空再说。

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

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

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

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

就像一楼说的

1. 设立主流程冒烟用例
2. 不符合就需要公告到相关领导

规则和流程其实不需要写太多，实际情况复杂多变，类似你设立的【基础质量不达标】这个，事实上你发现超 45 个 bug 了，那实际工作量就已经做了，不管是打回还是修复后重新验证，工作量都差不多。

而且需要认清一个现实是，项目打回并不是换开发，
现实就是你依然得和这个开发一起磨合，打回几次都改变不了上线日期，
类似 2 楼那些阿里味的条条框框（术语堆砌、宏大叙事、强调体系文化、落地路径模糊、内部视角浓厚）看看就行了，短期解决不了任何问题，长期也是需要大量的资源投入

对广大中小型公司、创业公司或处于快速迭代、生存压力下的团队来说，这套东西会水土不服

缺陷太多打回，这个治标不治本，打回后提测缺陷还是很多时难道还打回？上线时间不会变，这样只会压缩测试时间。正确的做法是向上反馈，测试提供自测用例，开发增加自测步骤，自测用例通过后才允许提测。推行制度与团队规模大小正相关。团队规模足够大，需要好的制度约束团队每一个人。团队规模小时就需要精简制度，怎么方便并且效果好怎么来，弹丸之地就不要搞三省六部制度。即浪费人力又浪费时间。