What is 测试金字塔？

我的女朋友是一名测试工程师，但她之前却不知道测试金字塔的概念，为此我曾经在家里的白板上画了一个图一层一层给她讲解过。我和同事在给团队面试测试和开发岗位时，也会必问到这个问题，想到可能有很多开发童鞋都不知道，这里我就用一篇推文给大家科普一下。

一、传说中的金字塔

我们都知道，针对项目的测试有很多分类，比如单元测试、集成测试、组件测试、端到端测试 以及 探索性测试等。那么，测试金字塔其实就是给我们的一个指导，它指导我们要在不同类型的测试工作投入多少的精力是最合适的。

废话不多说，先上图：

测试金字塔示意图（来自波波老师的课程）

从上图中我们可以看到，测试金字塔建议我们：

（1）尽可能地多做单元测试 和 集成测试，因为他们的执行速度相较于上层的几个测试类型来说快很多且相对稳定，可以一天多次执行。一般来说，我们都会将单元测试 和 集成测试 做到持续集成构建任务中去，比如放到Jenkins中每天定时执行1~2次，或者每次push代码到git仓库后执行，总之，就是要确保可以频繁执行以确保代码质量。

（2）尽可能地少做 组件测试、端到端测试 和 探索性测试，因为他们的执行速度相较单元测试 和 集成测试 会慢很多，且不够稳定，无法做到一天多次执行，每次执行都要等很久才能获得反馈结果。但是，他们的覆盖面比下层的单元测试 和 集成测试 要广一些。总之，就是要确保一定周期内 或者 关键节点时间 执行以下这几个测试以确保软件质量。

画外音：金字塔里，越往下速度越快且越稳定，那么就可以频繁执行，反正执行一次也花不了多久时间，开发人员还可以知道我的代码有没有影响到其他模块。越往上则速度越慢且越不稳定，跑一次要N久，开发人员往往会觉得还是先继续开发吧，到时候出了bug再说，我可不想加班等测试结果。

二、端到端的测试实践

在具体实践中，位于上层的端到端测试是粒度相对较粗 但是 我们又不得不做的测试实践。在微服务架构风格中，端到端测试涉及到的相关服务依赖很多，且异步等可变的因素较多，因此它也是一种最不稳定的测试。

端到端测试示意图（来自波波老师）

端到端测试：验证工作流中的所有流程，以检查一切是否按预期工作。它还确保系统以统一的方式工作，从而满足业务需求。

这里也跟大家分享一下在微服务架构场景中，对于端到端测试的一些实践要点，仅供参考：

（1）80/20原则，花更多的精力聚焦核心业务服务；对于我司来说，可能就是统一登录服务、订单下单服务、统一支付、设计反馈服务等；

（2）用户使用场景驱动，即尽可能使用最终用户的用例流程来驱动测试，这样可能更加容易覆盖到产生业务价值的场景；

（3）适当Mock不稳定测试点，如果有些微服务依赖的第三方服务不够稳定的话，那么可以适度牺牲一些覆盖面，使用Mock来测试。

（4）规范测试环境和环境自动化，即团队可以具备几种测试环境一键创建的能力，比如使用Docker + Kubernetes就可以帮助实现这个点。这一点，我相信大部分的小团队都不具备这个能力，我司其实也一样，所以我建议小团队尽可能上云，直接使用云上的能力帮助我们克服自身团队的技术储备弱的问题，提升端到端测试的效率。

（5）测试数据管理，即团队可以具备一键生成测试数据的能力，而不是每次环境启动起来才去修改数据以便于测试，一般都会通过维护测试数据的自动化脚本来实现。

画外音：对你们团队的测试同事好点，他们做端到端测试的时候会问候你的。

三、小结

本文介绍了测试金字塔的概念 及 耗时的端到端测试的实践要点，最后温馨提示一下，快下班时尽量别改自己不了解影响范围的Bug，否则你会像下面这样：

参考资料

杨波，《Spring Boot与K8s云原生应用开发》（极客时间课程，推荐学习）

杨波，《微服务架构160讲》（极客时间课程，推荐学习）

作者：周旭龙

出处：https://edisonchou.cnblogs.com

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。