谜一样的测试金字塔

作为一个优秀的QA(老脸一红)，最近突然对各种测试相关概念产生了兴趣。比如BDD，测试金字塔等等。
其实这些大佬们提出的概念是好的，但我们知道了这些概念，却无法将它应用到实际工作中，或者应用错了，那就很尴尬。
因此，对这些概念我们不仅要知其然，更要知其所以然。不要让这些好理论变成假大空的纸上模型，那今天就来分析一下“测试金字塔”理论和实际应用😎

啥是测试金字塔

测试金字塔是按照分层测试的理论，将各种测试方法和测试对象分层，用来解决敏捷开发中测什么和怎么测的问题。一般划分为四层：

单元测试

根据单元测试测试范围窄，运行速度快，维护方便的特点，把它放在测试金字塔的最底层，所以它的数量和覆盖率也应当是所有测试中最多的。

服务测试

第二层，包括集成测试/组件测试/接口测试/契约测试。

大佬说：所有常见的应用都会和一些外部环境做集成（数据库，文件系统，向其他应用发起网络请求）。为了使测试有更好的隔离、运行更快，我们通常不会在编写单元测试时涉及这些外部依赖。不过，这些交互始终是存在的，它们也需要被测试覆盖到。这正是集成测试的用处所在。它们测试的是应用与所有外部依赖的集成。

大佬还说：服务测试是一个难以掌握的术语，所以很多开发人员完全忽略了这一层。在单页应用框架（如 react，angular，ember.js 等）的时代，UI 测试显然不必位于金字塔的最高层，因为完全可以用这些框架对 UI 进行单元测试。

UI&端到端测试

• UI测试

就是用户界面测试，有时也可以用某些框架提供的组件来写单元测试代替UI测试，所以UI测试并不等于端到端测试。但主流的UI测试还是用Selenium或者Appium等工具自动化完成的。

• 端到端测试

包括针对API和用户界面的端到端测试。

手工测试

第四层，包括必要的手工测试，探索测试和验收测试。有时候，一些功能无法用自动化进行测试，比如页面的美观性可用性等，只能手工测试。而且尽管有单元测试和自动化测试在前，但依然无法保证覆盖所有边缘情况。此时，一些探索测试是非常有必要的。

一些需要注意的点

不要纠结各种测试术语

比如有些人说集成测试就是API测试，UI测试就是端到端测试，有人却说这些概念都是不同的。有人喜欢把集成测试叫组件测试等等。这就会导致同一个东西有很多的名字。容易陷入“你说的黑是什么黑，他说的白是什么白”这种无意义的牛角尖中。这个时候，大佬说的话，就很好👏：

各种测试术语并无绝对的对与错。软件开发社区至今也没法给出关于测试术语的明确定义。
术语含义本身有模糊性，不必孜孜不倦于其中。你认为的集成测试，可能和其他公司的人的认知也不同，这也没问题。
找到适合你和你团队的术语，这就足够了。

时刻维护金字塔形状，避免测试重复

首先要避免在金字塔不同层级进行重复测试，因为浪费时间、浪费金钱😂
在高层次测试发现的问题，想办法写低层测试去覆盖它，尽可能把测试往金字塔下层迁移，维护金字塔形状。

整理测试代码

重构是个好概念，希望你也知道😆。
测试代码加tag, 根据功能分支分类。
运用Given,When,Then口诀写测试，一些BDD的测试工具就很好用，比如 Cucumber。

测试金字塔是一成不变的吗

答案是否定的。

在实际项目中，上面的三层金字塔模型也许过于简单和概括化了。但它却足够简洁，上述三种测试方法也确实是目前最主流的。所以，可以根据实际情况建立自己的金字塔模型，比如可以再细分几层，把里面的测试方法改成别的等等。但一定要遵守这两条法则：

• 按照测试粒度分层
• 层次越高，你写的测试应该越少

参考文章

1.ThoughtWorks洞见-测试金字塔实战