写在前面

测试金字塔曾经神一样的存在，很多人认为制定测试策略知道测试金字塔就够了。
真的是这样吗？今天，利用这篇短文跟大家聊聊测试金字塔。

如果你恰好知道测试金字塔，也把它奉为测试策略的指导方针，那么这篇文章正好适合你。

如果你还不了解测试金字塔，但是很关注质量和测试，那么不管你是什么角色，这篇文章也适合你。

---

Most people know about the the Test Pyramid due to Mike Cohn, when he described it in his 2009 book Succeeding with Agile. In the book he refers to it as the “Test Automation Pyramid”, but in use it’s generally referred to as just the “test pyramid”. He originally drew it in conversation with Lisa Crispin in 2003-4 and described it at a scrum gathering in 2004. Jason Huggins independently came up with the same idea around 2006.

测试金字塔最早由Mike Cohn提出，Martin Fowler在文章TestPyramid中有详细介绍。如果你对测试金字塔不了解，可以先看Martin的文章。

总结说来，测试金字塔是自动化测试分层覆盖情况的一个参考模型，其特点是：

• 金字塔底层的测试是最接近代码的测试——单元测试，编写成本低、执行速度快、定位问题也更准确，但是离业务层较远，不能很好的体现业务价值；
• 金字塔顶层的测试是UI层的自动化测试，这一层离业务近，能够体现业务流程覆盖情况，但是编写成本较高、执行速度较慢、不够稳定、定位问题也更难；
• 而中间层的集成测试，则是成本和价值都是处于居中位置。

因此，金字塔建议底层单元测试占比应该最多，而顶层UI层测试占比较少，中间层的集成测试居中，整体呈现金字塔结构。

这适合比较理想的项目，而实际项目中可能有很多不适合测试金字塔的情形存在：

1. 微服务架构的系统

微服务系统服务间的依赖关系和连通性，是微服务测试的关键，相对而言，服务内部出错可能性小。因此，对于微服务架构下的自动化测试应该是蜂巢结构或纺锤形，也就是中间层服务间的集成测试最多，底层的单元测试和上层的UI测试都相对较少。

2. 遗留系统改造

为了支撑新型业务形态，越来越多的传统行业在向数字化转型，面临的一个问题是需要对大型业务复杂的遗留系统进行改造。这种情况，一般不适宜写大量的单元测试，技术和人员能力可能都不允许，而应该从顶层业务开始梳理，先增加业务层的功能测试作为基本保障，同时编写API集成测试和适量的单元测试。整个自动化测试覆盖情况，有可能是呈现为甜筒冰淇淋结构形式。

3. 人员技能不匹配的团队

有的团队可能开发人员忙着开发不参与写测试，只有测试人员来负责写测试，而测试人员的要写单元测试还得熟悉底层代码实现，可能比较困难，通常也只能是写更多的UI测试。

当然，这不是一个健康的状态，虽然客观存在，但是不提倡。

4. 测试策略不能仅依靠测试金字塔

把测试金字塔当做测试策略制定的唯一参考规范，是不合适的。别说是只关注测试金字塔，就是只关注测试金字塔背后的分层策略，也是远远不够的。

测试分层理论更多的是对自动化测试分层的指导，而测试策略需要考虑和关注的因素则比这个要多得多，比如：业务风险、质量目标、交付周期……很多很多，需要根据具体项目来确定。

如果只是关注自动化测试要测哪些，没有关注业务风险，有可能把精力都放在了对错误功能的测试上，事倍功半，得不偿失。

最后，测试金字塔不是万能的，不要只强调测试金字塔。

测试分层是测试策略的指导框架之一，另一个是测试四象限。更多的关于测试策略的内容，欢迎参考以下文章：

• 《精益测试》
• 《一页纸测试策略》
• 《微服务测试的思考与实践》