楠风测开复习日记 Day3

测试金字塔到底怎么用？

🏛️ 测试工程师必懂的测试结构 👉 Day 3 / 90 天 ⏱️ 阅读 8 分钟 | 建议收藏 ⭐

👋 朋友们好，我是楠风

Day 1 讲了测试工程师的 4 个阶段。

Day 2 讲了功能测试的用例设计。

今天讲一个很多团队都在掉坑里的事：测试金字塔。

我见过不少测试团队：

❌ 投入 80% 精力做 UI 自动化

❌ 单元测试几乎没人写

❌ 上线后 bug 频发

为什么？

因为他们没有搞懂测试金字塔。把资源用错了地方。

🏛️ 一、什么是测试金字塔

测试金字塔是 Mike Cohn 在 2009 年提出的。

         /\
        /UI\           ← 顶层：UI 测试（10%）
       /----\
      / API \          ← 中间：API 测试（20%）
     /--------\
    /   单元    \      ← 底层：单元测试（70%）
   /--------------\

3 个核心原则：

1. 越底层越多（单元测试占比最高）
2. 越顶层越少（UI 测试占比最低）
3. 越底层越便宜（单元测试 1 分钟能跑完）

为什么这样设计？

底层测试覆盖核心逻辑，跑得快、容易维护。

顶层测试覆盖用户路径，跑得慢、维护成本高。

金字塔结构能用最少资源，覆盖最多测试场景。

⚠️ 二、国内团队为什么都是"反金字塔"

真实数据：我看过一份调研，国内 200+ 互联网公司的测试结构大概是：

UI 自动化：60%
API 自动化：30%
单元测试：10%

这就是"反金字塔"。

❌ 原因 1：考核导向

很多团队考核看"自动化覆盖率"。

测试工程师为了 KPI，去做 UI 自动化（最容易出效果）。

但 UI 自动化维护成本高、稳定性差。

❌ 原因 2：团队结构

很多公司测试团队和开发团队分开。

单元测试被认为是开发的事，测试团队不管。

但单元测试是金字塔的底座，没人做就塌了。

❌ 原因 3：工具门槛

写单元测试需要懂代码、写 mock。

很多功能测试工程师不会写，团队也没人带。

🎯 三、3 个测试金字塔变体

标准金字塔不是万能的。不同场景有不同最佳结构。

🍦 变体 1：冰淇淋 Cone（移动端）

        ╱╲
       ╱UI ╲           ← UI 测试占大头
      ╱──────╲
     ╱  集成   ╲
    ╱──────────╲
   ╱   单元     ╲       ← 单元测试较少
  ╱─────────────────╲

适用：移动端 App

原因：

• 移动端 UI 复杂（手势、横竖屏、推送）
• 单元测试难写（依赖 Android/iOS 框架）

典型比例：UI 50% / 集成 30% / 单元 20%

🏆 变体 2：奖杯 Trophy（前端）

        ╱╲
       ╱e2e╲
      ╱──────╲
     ╱ 集成  ╲          ← 集成测试（最大）
    ╱──────────╲
   ╱   单元     ╲
  ╱─────────────────╲
   ╱   静态分析   ╲     ← 静态代码分析（底层）
  ╱─────────────────╲

适用：前端项目（React/Vue）

原因：组件交互复杂，集成测试覆盖 80% 价值。

典型比例：静态 30% / 单元 20% / 集成 30% / E2E 20%

🐝 变体 3：蜂巢 Honeycomb（微服务）

    ⬡  ⬡  ⬡  ⬡
   ⬡  ⬡  ⬡  ⬡  ⬡
    ⬡  ⬡  ⬡  ⬡
   ⬡  ⬡  ⬡  ⬡  ⬡

适用：微服务架构

原因：每个服务独立测试，重点是契约测试。

典型比例：契约测试 50% / 集成 30% / 单元 20%

📐 四、怎么用测试金字塔

Step 1：自检你的团队

□ UI 测试占比？       ____%
□ API 测试占比？     ____%
□ 单元测试占比？     ____%

判断标准：

✅ 健康：UI < 20%，API 20-30%，单元 50%+
⚠️ 亚健康：UI 30-50%，API 20-30%，单元 20-30%
❌ 不健康：UI > 50%，API < 20%，单元 < 20%

Step 2：找到最大短板

找到占比最低的那种测试，重点投入。

Step 3：3 个月改造路径

第 1 个月：补底层

- 推动开发补单元测试
- 团队内部做单元测试培训
- CI 加上覆盖率门禁

第 2 个月：补中间层

- 测试团队开始写 API 自动化
- 选 1 个核心接口作为试点
- 跑通后批量推广

第 3 个月：优化顶层

- UI 自动化从 60% 降到 30%
- 只保留核心场景的 UI 自动化
- 释放精力做更底层的工作

Step 4：选对工具栈

底层（单元）：JUnit / pytest / Jest
中间层（API）：requests / REST Assured / Apifox
顶层（UI）：Playwright / Appium / PyAutoGUI

🛠️ 五、楠风的实践

我之前待过一个团队，测试结构是这样的：

UI 自动化：70%
API 自动化：20%
单元测试：10%

问题：

❌ 上线后 bug 频发

❌ UI 自动化维护成本高（每月修 200+ 用例）

❌ 单元测试覆盖率只有 5%

3 个月改造：

第 1 个月：补单元测试
- 推动开发每周补 20 个单元测试
- 引入 Jacoco 看覆盖率
- 把覆盖率纳入考核

第 2 个月：补 API 自动化
- 测试团队选 5 个核心 API 写自动化
- 用 pytest + requests

第 3 个月：精简 UI 自动化
- UI 自动化从 70% 降到 30%
- 只保留 P0 级别的核心场景

3 个月后的数据：

✅ 上线 bug 数：月均 30 个 → 月均 8 个
✅ 自动化维护成本：节省 50%
✅ 单元测试覆盖率：10% → 45%
✅ 团队效率：测试周期缩短 30%

核心心得：

💡 测试金字塔不是理论，是工程实践。

很多人知道金字塔，但不会用。真正用好，需要团队配合、流程配套、工具支持。

✅ 六、3 个月行动清单

🎯 今天

□ 列出你们团队的测试结构（UI/API/单元各占多少）
□ 找到占比最低的那种测试

🎯 本周

□ 学 1 种你团队欠缺测试类型的最佳实践
□ 找 1 个团队成员讨论改造路径

🎯 90 天后

□ 团队测试结构符合"健康"标准
□ 上线 bug 数明显下降
□ 自动化维护成本降低
□ 团队效率整体提升 30%+

📝 七、写在最后

测试金字塔不是空理论，是工程实践。

很多团队知道金字塔，但反着做。

把资源用对地方，比努力更重要。

希望这篇文章能帮你看清：测试资源应该往哪里投。

💬 评论区聊聊

你们团队的测试结构是什么样的？

UI/API/单元测试各占多少？

我会尽量回复。

📚 关于楠风测开

我是楠风，5 年测试工程师，做测试平台方向。

• 🔧 自研 4 端测试平台：Web / 接口 / Android / PC
• 📝 写测试工程师成长日记

AI 重塑测试，一个人就是一个团队

🔗 找到楠风

📱 公众号：楠风测开（同名）
🌐 知乎 / 掘金 / CSDN：搜索"楠风测开"
💬 想进测试圈交流群：加我微信备注「测试」

📅 下期预告

Day 4 · 黑盒 vs 白盒 vs 灰盒测试，一张图讲透

→ 关注不迷路，建议收藏 ⭐

如果这篇文章对你有帮助：

🌟 点赞 + 在看 + 转发
🌟 关注公众号「楠风测开」（同名）
🌟 加我微信（备注"测试"，进测试圈交流群）

🌱 楠风测开 · 测试工程师复习日记 Day 3 / 90 天 全文 3000 字 | 阅读 8 分钟

【免责声明】本文为楠风测开原创，转载请联系作者授权。