测试金字塔到底怎么用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 33 个月改造路径第 1 个月补底层- 推动开发补单元测试覆盖率从 10% 提到 30% - 团队内部做单元测试培训 - CI 加上覆盖率门禁第 2 个月补中间层- 测试团队开始写 API 自动化 - 选 1 个核心接口作为试点 - 跑通后批量推广第 3 个月优化顶层- UI 自动化从 60% 降到 30% - 只保留核心场景的 UI 自动化 - 释放精力做更底层的工作Step 4选对工具栈底层单元测试JavaJUnit Mockito Pythonpytest unittest.mock 前端Jest Vue Test Utils中间层API 测试Pythonrequests pytest JavaREST Assured 工具Postman / Apifox手动 自研平台持续运行顶层UI 测试WebPlaywright / 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 年测试工程师 | 测试开发 做测试平台、写技术博客、分享成长路径 如果你想看更多我的内容可以搜索楠风测开 或者关注我的同名账号如果这篇文章对你有帮助点赞 收藏建议收藏评论区告诉我你们团队的结构转发给同样迷茫的测试 leader全文 3000 字 | 阅读 8 分钟 | 建议收藏【原创声明】本文为楠风测开原创转载请联系作者授权。