主流的"测试" vs 我的"6 阶段"
很多团队的测试流程是 3 段式:
UT → 集成 → 上线
每阶段都做"测试"——只是测试对象不同。
我的判断不一样:
▌ 测试不是"测一遍"—— ▌ 是按 6 个阶段性质拆分, ▌ 每阶段有"该阶段独有、其他阶段无法替代"的验证内容。
不是 6 次相同动作 —— 是 6 类不同性质的验证。
6 阶段是什么
┌──────────────────────────────────────────────────────────┐
│ │
│ ① 单元测试 ── 验证"函数内部" │
│ ↓ │
│ ② 集成测试 ── 验证"跨网络" │
│ ↓ ← 比对工具进场 │
│ ③ Code Review ─ 验证"设计 + 性能" │
│ ↓ │
│ ④ 他测 ────── 验证"用户视角" │
│ ↓ ← 比对工具回访 │
│ ⑤ 灰度 ────── 验证"生产数据兼容" │
│ ↓ ← 比对工具在线 │
│ ⑥ 上线观察 ── 验证"业务大盘波动" │
│ │
└──────────────────────────────────────────────────────────┘
每阶段独有验证内容:
| 阶段 | 性质 | 独有验证 |
|---|---|---|
| ① 单元 | 函数内部 | UT 覆盖率 + 冒烟 + 功能埋点 |
| ② 集成 | 跨网络 | 跨服务冒烟 + DML 比对 |
| ③ Review | 设计性能 | 设计审查 + 性能分析 + 回滚方案 |
| ④ 他测 | 用户视角 | 提测文档 + Test Case + 修复后再比对 |
| ⑤ 灰度 | 生产数据 | 时间窗口 + 分工 + DML 在线比对 |
| ⑥ 上线 | 业务大盘 | 6 项指标 + 四方确认 |
→ 第 ②④⑤ 阶段的"比对"动作,就是上一篇讲的"比对工具体系"。 → 第 ⑥ 阶段是大多数团队最常省的——本文重点讲它。
阶段拆分的核心标准
我自己的判断标准很简单:
两个阶段如果验证内容重叠 —— 说明阶段拆分错了。
举个例子:很多团队把"集成测试"和"他测"混在一起做—— 都让测试同事跑一遍。
但这两个阶段性质完全不同:
- 集成测试是 "跨网络"性质 —— 关心服务调用、数据穿透是否对
- 他测是 "用户视角"性质 —— 关心 case 覆盖、修复后再验证是否对
合在一起做的代价: 集成阶段没暴露的跨服务 bug,会被他测的"用户场景"掩盖—— 等到灰度才发现,代价是集成阶段的 N 倍。
第 6 阶段最贵 —— 也最被忽视
很多团队的"上线观察"=刷一下监控大盘。
我的版本:6 项指标 + 四方确认。
6 项观测指标:
1. 产品功能有没有执行
2. 数据有没有问题
3. 系统有没有性能问题
4. 跨系统交互有没有影响
5. 财务大盘是否波动 ← 关键!
6. 业务大盘是否波动 ← 关键!
▌ 把"财务大盘 / 业务大盘波动" ▌ 作为发布观察指标 —— ▌ 这是大多数团队最常省的一步。
因为这两项指标"看起来不归技术管"。 但实际上 —— 80% 的"上线后才发现"的事故,在前 4 项指标 里全是绿的,只有第 5 、6 项暴露异常。
例子:
某次上线某个改动,前 4 项指标全绿; 3 天后才发现财务对账差异——这种 bug 在 UT/集成/灰度 都看不出来,只有"业务大盘"能看见。
四方确认 —— 不是签字流程
四方确认 = 开发 / 测试 / 技术 TO / 产品 都同意才能"上线观察通过"。
听起来像 PPT 流程,但反共识在于:
▌ 测试同意 ≠ 验收通过 —— ▌ 业务大盘没波动,不代表产品认为"功能符合预期"。 ▌ 产品同意 ≠ 验收通过 —— ▌ 数据正常,不代表开发认为"性能达标"。
四方共同确认——任何一方说"我看到的不对"——就回退。
我经历的项目里,真发生过 "3 方都过了,产品最后说不对" 的情况。如果没有四方流程,这个回退根本走不动。
反共识在哪
主流:测试 = UT + 集成 + 上线(3 阶段) 我的版本:6 阶段,每阶段独有验证
主流:每阶段都做"测试"动作 我的版本:每阶段对应该阶段性质独有的验证手段
主流:上线观察看"是否有大故障" 我的版本:6 项观测指标 + 四方确认
主流:业务大盘归运营管 我的版本:把"财务大盘 / 业务大盘"作为发布观察指标
主流:验收 = 测试通过 我的版本:四方确认(开发 / 测试 / 技术 TO / 产品)
什么时候不该用这套
也踩过坑。
某次内部小工具改动,代码量不到 200 行。 我也想搞 6 阶段——leader 直接说:"过度。"
事后是对的。
我的判断:
- 核心业务系统改造 → 必上(尤其涉及财务 / 业务大盘)
- 跨多研发角色的项目 → 必上(否则四方确认走不通)
- 内部工具 / 后台脚本 → 别上(单人项目,4 阶段够)
- DDL 类无法灰度的改动 → 跳过第 5 阶段(灰度),其余照走
- 不影响 KPI 的小项目 → 简化为 3 阶段(UT+集成+上线)
阴面 · 这套也有副作用
我自己用了这套 4 年,踩过的坑:
- 重型流程 —— 小项目用不上,6 阶段成本太高
- 跨公司不通用 —— 没有"四方确认 / 业务大盘"概念的公司套不进来
- 可能流于形式 —— 团队成员把 6 阶段当 6 个 checkbox 而非 6 类性质
- 决策慢 —— 至少 6 次评审 / 检查
最后一条最关键 —— **6 阶段的代价是"决策周期变长"**。 所以才有上面那句:"小项目别上 / 不影响 KPI 的项目简化为 3 阶段"。
写在最后
把测试拆 6 阶段,不是为了"显得专业"—— 是因为我经历过太多次:
"你那阶段不是测过吗?怎么还出问题?"
仔细看,会发现:那阶段测的不是这一类问题。
每阶段性质不同 —— 验证手段就该不同。 6 阶段是"性质拆分",不是"动作拆分"。
跟"渐进式改造"和"比对工具"一样,这是一套关心可逆性、关心 追溯性的工程纪律。
写到这,我也不太确定 6 阶段对所有团队都成立。
我经历的项目都是"核心业务系统 + 跨多角色 + 业务大盘敏感"—— 这种场景 6 阶段几乎是必修。 但创业团队 / 内部工具 / 没有"业务大盘"这个概念的公司—— 搞这套可能反而是负担。
这点我自己也还在想。
下一篇打算写 17 类业务迁移分类—— 跟 6 阶段是一对:6 阶段是纵向(时间),17 类是横向(业务域)。 两者合起来才是完整的迁移管理体系。
(以上 SOP 都做了脱敏。 如果你做过核心系统改造,欢迎评论区聊聊你们的验收流程长什么样, 特别想听6 阶段简化为 3 阶段后,踩过的坑。)
Select Language