测试不是测一遍 —— 是 6 个阶段每阶段都不一样

主流的"测试" vs 我的"6 阶段"

很多团队的测试流程是 3 段式:

UT → 集成 → 上线

每阶段都做"测试"——只是测试对象不同。

我的判断不一样:

▌ 测试不是"测一遍"—— ▌ 是按 6 个阶段性质拆分, ▌ 每阶段有"该阶段独有、其他阶段无法替代"的验证内容。

不是 6 次相同动作 —— 是 6 类不同性质的验证。

6 阶段是什么

┌──────────────────────────────────────────────────────────┐
│                                                          │
│  ① 单元测试 ── 验证"函数内部"                              │
│         ↓                                                │
│  ② 集成测试 ── 验证"跨网络"                                │
│         ↓                       ← 比对工具进场             │
│  ③ Code Review ─ 验证"设计 + 性能"                         │
│         ↓                                                │
│  ④ 他测 ────── 验证"用户视角"                              │
│         ↓                       ← 比对工具回访             │
│  ⑤ 灰度 ────── 验证"生产数据兼容"                          │
│         ↓                       ← 比对工具在线             │
│  ⑥ 上线观察 ── 验证"业务大盘波动"                          │
│                                                          │
└──────────────────────────────────────────────────────────┘

每阶段独有验证内容:

→ 第 ②④⑤ 阶段的"比对"动作,就是上一篇讲的"比对工具体系"。 → 第 ⑥ 阶段是大多数团队最常省的——本文重点讲它。

阶段拆分的核心标准

我自己的判断标准很简单:

两个阶段如果验证内容重叠 —— 说明阶段拆分错了。

举个例子:很多团队把"集成测试"和"他测"混在一起做—— 都让测试同事跑一遍。

但这两个阶段性质完全不同:

• 集成测试是 "跨网络"性质 —— 关心服务调用、数据穿透是否对
• 他测是 "用户视角"性质 —— 关心 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 阶段后,踩过的坑。)