自动化测试和敏捷软件开发常常是成对出现，但敏捷中的自动化往往说起来容易做起来难。大多数开发人员都已经认识到测试自动化的好处：它加快了测试速度、降低了成本、增加了覆盖率等。但是，许多人从未超过开始所需的初始投资。就像这幅漫画中的穴居人一样，许多团队陷入了困境，他们采用着低效率的方式，因为自认为根本没有时间去做出改变。而实际上，他们是自己受到损害。不要养成这个坏习惯！

今天，我们将与你分享我们对于敏捷团队的最佳测试实践之一。

要如何开始？如何知道要关注哪些领域？哪些测试方案应该采用自动化？

在非敏捷软件开发中，很多人不经意地陷入了“冰淇淋蛋筒反模式”的测试中，因为该模式更加强调 UI 层面的自动化。 Abstracta团队更喜欢将冰淇淋蛋筒倒过来的模式——由Mike Cohn推广流行的方法，即敏捷测试自动化金字塔。它可以给自动化成本带来最大收益，提高自动化的投资回报率，保证你将从自动化中获得最大收益。

当我们的大部分工作都集中在 UI 级别的自动化上时，重点是发现错误；而对于敏捷金字塔，其重点为避免错误。

在下图中，你可以看到两种方法的不同之处。

基础层：单元测试 显然，在金字塔中（作为敏捷团队最佳测试实践的一部分），大部分测试应该在开发阶段进行，在每次构建后进行单元测试。这些测试是最容易、最低成本及最快完成的，并且是测试驱动开发的一个重要方面。在较低的级别运行更多的测试可以让我们在运行过程中即可检查相应的工作，立即获得反馈，并让团队在错误难以隐藏的时候准确地知道错误出现在哪里。

在这里，这些错误的寿命也会更短，可能在不到一分钟的时间内就被发生、被清除了。而在 UI 测试过程中，错误会存活更长时间，并产生更激烈的矛盾，因为它们已经舒适地生活了相对更长的时间。

中间层：API/集成/组件测试 运行所有单元测试并通过之后，就可以进入 API/集成/组件测试阶段。

运行集成测试是为了确保所有组件正常配合工作。这里无需通过 UI 即可测试大部分逻辑和业务流程，在此处最好尽可能地采用自动化。

如果纠结于在此处自动化还是UI级别自动化，选择这里问题将变少、维护会更容易、测试执行会更快（意味着能更快发现错误，缩短它们的寿命），而且可以测试系统的逻辑。这些测试比单元测试更慢、更复杂，但它们仍然比 UI 测试更快、且不那么脆弱。

顶层：UI 测试 最后讲的，也是运行最少的是 UI 测试。最好尽可能少地进行UI 测试，因为它们成本高、难准备、难维护，并且需要很长时间。在这一步，只是要确保用户界面本身正常工作，系统的所有其他方面都已经过测试。只测试端到端最重要的部分，流程从用户登录开始，以如交易成功消息这样的最终操作结束。

关注与浏览器或 UI 相关的事情也很有帮助。运行 UI 测试后，可以进行手动和探索性测试（如金字塔上方的球体形状所示）。

如上所述，与把重点放在自动化 GUI 测试上，并且无意中遵循“冰淇淋蛋筒反模式”比起来，金字塔方法是实现测试自动化的更强大、更有益和更具成本效益的方法。金字塔在单元测试阶段提供了一个强大的基础，可以在集成和 UI 阶段进行进一步的测试，而冰淇淋蛋筒方法更头重脚轻且稳定性较差。

为了在敏捷开发世界中脱颖而出，就须遵循自动化金字塔测试，以尽可能生产出质量最好的软件。但不需要只遵循一家之言，可多方参考资料并不断实践以获得最适合团队的测试方法。