目前我写的是这样的
但是感觉太粗糙了，有没有大佬可以说说怎么细化？
这只是手段，核心是让开发联调自测，不自测 bug 当然多，就不准提测，那测试应该提供冒烟用例，冒烟用例不通过就打回，打回要发邮件让领导知道提测质量差，具体到那部分功能谁负责开发导致打回的。写那么多隔靴搔痒的东西都没人当回事。
一、通常都是针对提测，打回也是不符合提测标准，比如：
- 单元测试未通过。
- 静态代码扫描未通过。
- 自测用例未通过。
- 产品验收未通过。 （1 和 2 因修 bug 引起的，不算，但是测试准出要卡住）
二、一旦进入测试阶段，那都按 bug 处理，因为涉及的因素很多，比如
- 团队能力成熟度。
- 项目性质。
- 核心/非核心业务。
- 组织意志。
三、比打回更重要的是带领整个团队提升质量意识，形成质量文化。
- 线下质量提报。
- 线上质量运营。
- 过程质量跟踪。
- 质量可视化分析。
- 代码质量减少低级问题。
四、质量体系的重要性
- 流程上可以持续进行过程改进和缺陷分析。
- 测试左移、右移标准建立。
- 质量通晒，周报/双周报体现各团队的差异。
- 共性问题分析及治理。
- 专项/横向或某些疑难杂症/技术攻坚。（我很讨厌专项和横向这两个词，听了 7、8 年了）
- 有空再说。
五、总结
这个范围太大，一时半会儿说不完。打回只是其中的一个手段，如何逐步提升团队质量意识是一套体系的思考。否则，会陷入无休止的扯皮。可以从一个点突破，一步一步完善，提升自己的影响力，做好质量守门员，从救火到防火。
附赠
情商也得在线，村里还是人情世故的社交，思考一下如何做一个让团队即不讨厌又能解决问题的优秀工程师。
本来是没打算做到这一步的，但是新来一批人，开发质量真的很差才不对应开始制定这样的制度
一楼已经给答案了，就是提供冒烟用例给开发，他们冒烟通过流程才到测试这边
就像一楼说的
- 设立主流程冒烟用例
- 不符合就需要公告到相关领导
规则和流程其实不需要写太多，实际情况复杂多变，类似你设立的【基础质量不达标】这个，事实上你发现超 45 个 bug 了，那实际工作量就已经做了，不管是打回还是修复后重新验证，工作量都差不多。
而且需要认清一个现实是，项目打回并不是换开发，
现实就是你依然得和这个开发一起磨合，打回几次都改变不了上线日期，
类似 2 楼那些阿里味的条条框框（术语堆砌、宏大叙事、强调体系文化、落地路径模糊、内部视角浓厚）看看就行了，短期解决不了任何问题，长期也是需要大量的资源投入
对广大中小型公司、创业公司或处于快速迭代、生存压力下的团队来说，这套东西会水土不服
缺陷太多打回，这个治标不治本，打回后提测缺陷还是很多时难道还打回？上线时间不会变，这样只会压缩测试时间。正确的做法是向上反馈，测试提供自测用例，开发增加自测步骤，自测用例通过后才允许提测。推行制度与团队规模大小正相关。团队规模足够大，需要好的制度约束团队每一个人。团队规模小时就需要精简制度，怎么方便并且效果好怎么来，弹丸之地就不要搞三省六部制度。即浪费人力又浪费时间。
增加了冒烟测试，冒烟测试通过后还有大量缺陷就打回
我有个附件的问题想问一下：项目的最终质量，是不是跟开发者的水平绝对线性相关的？
补充一下，换个思路（玩个文字游戏，改成需求返工）。
需求返工与打回的区别在于：
- 打回是某一项不符合提测标准，基本卡主了需求评审，技术方案评审，单测，静扫，cr，自测，产品走查。
- 返工是质量太差，需要要重做，重新走一遍流程，“拉着大家一起下水”，这样才会拉拢有缘人帮你说话、配合你提升质量。
需求返工，从意义上更具有震慑作用，更能引起领导层的重视。