企业官网建设流程全解析

测试金字塔到底怎么用？90% 的团队都用错了

作者：楠风测开 | 5 年测试工程师 | 上海 本文 3000 字 | 阅读 8 分钟 | 建议收藏 ⭐

先说为什么

Day 1 我讲了测试工程师的 4 个阶段，Day 2 讲了功能测试最基础的方法论。

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

我见过不少测试团队：

• 投入 80% 精力做 UI 自动化
• 单元测试几乎没人写
• 上线后 bug 频发，测试团队背锅

为什么？

因为这些团队没有搞懂测试金字塔。把资源用错了地方。

今天这篇文章，把测试金字塔完整讲透。看完你会知道，自己的测试资源应该怎么分配。

一、什么是测试金字塔

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

他把测试分成三层，越往下越基础、越快、越便宜：

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

3 个核心原则：

1. 越底层越多：单元测试占比最高（70%+） 2. 越顶层越少：UI 测试占比最低（10%） 3. 越底层越便宜：单元测试 1 分钟能跑完，UI 测试要几分钟

为什么这样设计？

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

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

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

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

真实数据：

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

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

这就是"反金字塔"。

为什么？

原因 1：考核导向

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

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

但 UI 自动化维护成本高、稳定性差，1 个月能写 50 个用例，但能稳定跑通的不到 30 个。

原因 2：团队结构

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

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

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

原因 3：工具门槛

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

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

补充：单元测试其实是性价比最高的测试投入。

三、3 个测试金字塔变体

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

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

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

适用：移动端 App

原因：

• 移动端 UI 复杂（手势、横竖屏、推送）
• 单元测试难写（很多逻辑依赖 Android/iOS 框架）
• 集成测试价值大（API + UI 联动）

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

变体 2：奖杯 Trophy（前端）

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

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

原因：

• 组件交互复杂，集成测试覆盖 80% 价值
• 静态分析（ESLint）能发现很多低级错误
• 端到端测试慢但必须

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

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

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

适用：微服务架构

原因：

• 每个服务独立测试
• 重点是服务间的契约测试
• 不需要传统的 UI 测试

典型比例：契约测试 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：找到最大短板

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

举例： - 如果单元测试只有 5%，优先补单元测试 - 如果 API 测试只有 10%，优先补 API 测试

Step 3：3 个月改造路径

第 1 个月：补底层

- 推动开发补单元测试（覆盖率从 10% 提到 30%） - 团队内部做单元测试培训 - CI 加上覆盖率门禁

第 2 个月：补中间层

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

第 3 个月：优化顶层

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

Step 4：选对工具栈

底层（单元测试）：

Java：JUnit + Mockito Python：pytest + unittest.mock 前端：Jest + Vue Test Utils

中间层（API 测试）：

Python：requests + pytest Java：REST Assured 工具：Postman / Apifox（手动） + 自研平台（持续运行）

顶层（UI 测试）：

Web：Playwright / Selenium 移动端：Appium / Airtest 桌面端：PyAutoGUI / WinAppDriver

五、楠风的实践

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

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

问题：

• 上线后 bug 频发
• UI 自动化维护成本高（每月修 200+ 用例）
• 单元测试覆盖率只有 5%
• 开发说"我代码没问题"，测试说"我覆盖不到"

改造方案：

第 1 个月：补单元测试 - 推动开发每周补 20 个单元测试 - 引入 Jacoco 看覆盖率 - 把覆盖率纳入考核 第 2 个月：补 API 自动化 - 测试团队选 5 个核心 API 写自动化 - 用 pytest + requests 第 3 个月：精简 UI 自动化 - UI 自动化从 70% 降到 30% - 只保留 P0 级别的核心场景 - 释放的精力做更底层的工作

3 个月后的数据：

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

核心心得：

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

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

六、3 个月行动清单

如果你也想优化团队的测试金字塔：

□ Step 1：自检团队当前的测试结构 □ Step 2：找到占比最低的那种测试 □ Step 3：制定 3 个月改造计划 □ Step 4：选对工具栈 □ Step 5：推动团队配合 □ Step 6：每个月底复盘一次

今天

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

本周

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

90 天后

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

七、写在最后

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

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

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

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

评论区聊聊

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

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

我会尽量回复。

关于作者

楠风测开 | 5 年测试工程师 | 测试开发 做测试平台、写技术博客、分享成长路径 如果你想看更多我的内容，可以搜索楠风测开 或者关注我的同名账号

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

1. 点赞 + 收藏（建议收藏）
2. 评论区告诉我你们团队的结构
3. 转发给同样迷茫的测试 leader

全文 3000 字 | 阅读 8 分钟 | 建议收藏

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