敏捷團隊的最佳測試實踐：自動化金字塔
本篇目錄
自動化測試和敏捷軟件開發常常是成對出現，但敏捷中的自動化往往說起來容易做起來難。大多數開發人員都已經認識到測試自動化的好處：它加快了測試速度、降低了成本、增加了覆蓋率等。但是，許多人從未超過開始所需的初始投資。就像這幅漫畫中的穴居人一樣，許多團隊陷入了困境，他們采用著低效率的方式，因爲自認爲根本沒有時間去做出改變。而實際上，他們自己受到損害。不要養成這個壞習慣！
今天，與你分享敏捷團隊的最佳測試實踐之一。
要如何开始？如何知道要关注哪些领域？哪些测试方案应该采用自动化？在非敏捷软件开发中，很多人不经意地陷入了“冰淇淋蛋筒反模式”的测试中，因为该模式更加强调 UI 层面的自动化。 Abstracta团队更喜欢将冰淇淋蛋筒倒过来的模式——由Mike Cohn推广流行的方法，即敏捷测试自动化金字塔。它可以给自动化成本带来最大收益，提高自动化的投资回报率，保证你将从自动化中获得最大收益。
当我们的大部分工作都集中在 UI 级别的自动化上时，重点是发现错误；而对于敏捷金字塔，其重点为避免错误。
在下圖中，你可以看到兩種方法的不同之處。
基礎層：單元測試
显然，在金字塔中（作为敏捷团队最佳测试实践的一部分），大部分测试应该在开发阶段进行，在每次构建后进行单元测试。这些测试是最容易、最低成本及最快完成的，并且是测试驱动开发的一个重要方面。在较低的级别运行更多的测试可以让我们在运行过程中即可检查相应的工作，立即获得反馈，并让团队在错误难以隐藏的时候准确地知道错误出现在哪里。在这里，这些错误的寿命也会更短，可能在不到一分钟的时间内就被发生、被清除了。而在 UI 测试过程中，错误会存活更长时间，并产生更激烈的矛盾，因为它们已经舒适地存在了相对更长的时间。中間層：API/集成/組件測試
运行所有单元测试并通过之后，就可以进入 API/集成/组件测试阶段。运行集成测试是为了确保所有组件正常配合工作。这里无需通过 UI 即可测试大部分逻辑和业务流程，在此处最好尽可能地采用自动化。如果纠结于在此处自动化还是UI级别自动化，选择这里问题将变少、维护会更容易、测试执行会更快（意味着能更快发现错误，缩短它们的寿命），而且可以测试系统的逻辑。这些测试比单元测试更慢、更复杂，但它们仍然比 UI 测试更快、且不那么脆弱。頂层：UI 测试
最后讲的，也是运行最少的是 UI 测试。最好尽可能少地进行UI 测试，因为它们成本高、难准备、难维护，并且需要很长时间。在这一步，只是要确保用户界面本身正常工作，系统的所有其他方面都已经过测试。只测试端到端最重要的部分，流程从用户登录开始，以如交易成功消息这样的最终操作结束。关注与浏览器或 UI 相关的事情也很有帮助。运行 UI 测试后，可以进行手动和探索性测试（如金字塔上方的球体形状所示）。
如上所述，与把重点放在自动化 GUI 测试上，并且无意中遵循“冰淇淋蛋筒反模式”比起来，金字塔方法是实现测试自动化的更强大、更有益和更具成本效益的方法。金字塔在单元测试阶段提供了一个强大的基础，可以在集成和 UI 阶段进行进一步的测试，而冰淇淋蛋筒方法更头重脚轻且稳定性较差。
爲了在敏捷開發世界中脫穎而出，就須遵循自動化金字塔測試，以盡可能生産出質量最好的軟件。但不需要只遵循一家之言，可多方參考資料並不斷實踐以獲得最適合團隊的測試方法。
