提测达标（Submission Gate）⭐
这是测试守住质量的最关键门禁。不达标一律退回，不迁就。
什么是提测达标
提测达标 = 开发交付给测试的版本，必须满足一系列条件，测试才会接收并开始测试。
不达标就退回，不浪费测试资源。
为什么需要提测达标
没有它的后果
- 开发"扔过墙"心态：写完就丢给测试
- 测试环境一启动就报错，测试变成"开发的调试助手"
- Bug 修复反复打回，一个版本测 5 遍才稳定
- 测试团队成为最大瓶颈，背锅最多
有它的好处
- 倒逼开发提升自测质量
- 测试资源用在"找深层 Bug"上，而不是"找低级错误"
- 责任边界清晰
- 减少 30%-50% 的无效测试轮次
达标标准（4 个维度 × 17 个检查项）
维度 1：代码层面
| # | 检查项 | 标准 | 验证方式 |
|---|---|---|---|
| 1.1 | 代码已合并 | 已合并到测试分支（release/x.y.z） | 查 Git 提交记录 |
| 1.2 | MR/PR 评审通过 | 至少 1 人 approve | 查平台状态 |
| 1.3 | CI 流水线绿灯 | 所有 CI 任务通过 | 查 CI 状态 |
| 1.4 | 单元测试通过 | 通过率 100%，覆盖率 ≥ 80% | 查 CI 报告 |
| 1.5 | 静态扫描通过 | 无 P0/P1 级别问题 | 查 SonarQube 等 |
维度 2：自测层面
| # | 检查项 | 标准 |
|---|---|---|
| 2.1 | 冒烟测试通过 | 核心流程能跑通（登录→主流程→退出） |
| 2.2 | 自测报告完整 | 每个改动点都有自测记录 |
| 2.3 | 覆盖本次变更 | 不能"改了 A 只测了 B" |
| 2.4 | 已知缺陷已修复 | 之前 Bug 必须验证修复 |
维度 3：文档层面
| # | 检查项 | 标准 |
|---|---|---|
| 3.1 | 提测申请单 | 必须提交，格式见 submission 模板 |
| 3.2 | 接口文档已更新 | 与代码一致（Markdown 接口文档） |
| 3.3 | 数据库变更说明 | SQL 变更脚本 + 回滚脚本 |
| 3.4 | 配置变更说明 | 新增/修改的配置项有说明 |
| 3.5 | 部署文档更新 | 部署步骤、依赖变化已记录 |
维度 4：环境层面
| # | 检查项 | 标准 |
|---|---|---|
| 4.1 | 测试环境已部署 | 服务已启动，可访问 |
| 4.2 | 环境信息完整 | 地址、账号、版本、依赖服务版本 |
| 4.3 | 数据库已就绪 | 表结构、初始化数据 |
| 4.4 | 依赖服务正常 | MQ、Redis、第三方接口可用 |
拒绝提测的常见场景
| 场景 | 测试处理 |
|---|---|
| 没有提测申请单 | 直接打回 |
| 冒烟测试失败 | 退回，记录"提测失败" |
| CI 没通过就提测 | 退回，要求先修复 CI |
| 测试环境起不来 | 退回，要求开发先保障环境 |
| 接口文档跟代码不一致 | 退回，要求先对齐 |
| 自测明显不充分（一测就崩） | 退回，要求重新自测 |
| 影响范围说不清楚 | 退回，要求评估清楚 |
拒绝提测的话术（避免冲突）
本次提测因 [具体原因] 不符合提测标准，已暂停接收。
请补充/修复后再次提交，提测达标标准详见 [链接]。
预计补齐时间？
关键：对事不对人，明确指出哪条不达标，给出补救方案。
落地机制
流程层
- 提测达标写进研发流程文档
- 全员培训，确保知晓
- 首次违规警告，二次上报
- 每月统计违约情况
工具层
- GitLab MR 模板：把 checklist 做进 MR 描述 — 见 workflows/gitlab
- CI 强制门禁：CI 不过不允许合入测试分支
- 自动化校验脚本：
check-submission.js校验提测申请单完整性 （源码）node tools/cross-platform/scripts/check-submission.js your-submission.md
度量层
| 指标 | 目标值 |
|---|---|
| 提测一次通过率 | ≥ 80% |
| 冒烟测试通过率 | ≥ 95% |
| 因提测不达标导致的延期 / 月 | ≤ 2 次 |
| 平均提测准备时间 | 持续下降 |