测试金字塔曾经神一样的存在，很多人认为制定测试策略知道测试金字塔就够了。真的是这样吗？
今天，利用这篇短文跟大家聊聊测试金字塔。
如果你恰好知道测试金字塔，也把它奉为测试策略的指导方针，那么这篇文章正好适合你。
如果你还不了解测试金字塔，但是很关注质量和测试，那么不管你是什么角色，这篇文章也适合你。
测试金字塔最早由Mike Cohn提出，Martin Fowler在文章《TestPyramid》（https://martinfowler.com/bliki/TestPyramid.html）中有详细介绍。如果你对测试金字塔不了解，可以先看Martin的文章。
总得说来，测试金字塔是自动化测试分层覆盖情况的一个参考模型，其特点是：
- 金字塔底层的测试是最接近代码的测试——单元测试，编写成本低、执行速度快、定位问题也更准确，但是离业务层较远，不能很好的体现业务价值；
- 金字塔顶层的测试是UI层的自动化测试，这一层离业务近，能够体现业务流程覆盖情况，但是编写成本较高、执行速度较慢、不够稳定、定位问题也更难；
- 而中间层的集成测试，则是成本和价值都是处于居中位置。
因此，金字塔建议底层单元测试占比应该最多，而顶层UI层测试占比较少，中间层的集成测试居中，整体呈现金字塔结构。
这适合比较理想的项目，而实际项目中可能有很多不适合测试金字塔的情形存在：
1、微服务架构的系统
微服务系统服务间的依赖关系和连通性，是微服务测试的关键，相对而言，服务内部出错可能性小。因此，对于微服务架构下的自动化测试应该是蜂巢结构或纺锤形，也就是中间层服务间的集成测试最多，底层的单元测试和上层的UI测试都相对较少。
2、遗留系统改造
为了支撑新型业务形态，越来越多的传统行业在向数字化转型，面临的一个问题是需要对大型业务复杂的遗留系统进行改造。这种情况，一般不适宜写大量的单元测试，技术和能力可能都不允许，而应该从顶层业务开始梳理，先增加业务层的功能测试作为基本保障，同时编写API集成测试和适量的单元测试。整个自动化测试覆盖情况，有可能是呈现为甜筒冰淇淋结构形式。
3、人员技能不匹配的团队
有的团队可能开发人员忙着开发不参与写测试，只有测试人员来负责写测试，而测试人员的要写单元测试还得熟悉底层代码实现，可能比较困难，通常也只能是写更多的UI测试。
当然，这不是一个健康的状态，虽然客观存在，但是不提倡。
4、测试策略不能仅依靠测试金字塔
把测试金字塔当做测试策略制定的唯一参考规范，是不合适的。别说是只关注测试金字塔，就是只关注测试金字塔背后的分层策略，也是远远不够的。
测试分层理论更多的是对自动化测试分层的指导，而测试策略需要考虑和关注的因素则比这个要多得多，比如：业务风险、质量目标、交付周期……很多很多，需要根据具体项目来确定。
如果只是关注自动化测试要测哪些，没有关注业务风险，有可能把精力都放在了对错误功能的测试上，事倍功半，得不偿失。
最后，测试金字塔不是万能的，不要只强调测试金字塔。
源自公众号 BY林子