你还只知道测试金字塔？

写在前面

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

Most people know about the the Test Pyramid due to , when he described it in his 2009 book . 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 around 2006.

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

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

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

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

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

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

2. 遗留系统改造

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

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

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

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

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

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

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

《》 《》 《》