自動化測試和敏捷軟件開發常常是成對出現，但敏捷中的自動化往往說起來容易做起來難。大多數開發人員都已經認識到測試自動化的好處：它加快了測試速度、降低了成本、增加了覆蓋率等。但是，許多人從未超過開始所需的初始投資。就像這幅漫畫中的穴居人一樣，許多團隊陷入了困境，他們採用着低效率的方式，因爲自認爲根本沒有時間去做出改變。而實際上，他們自己受到損害。不要養成這個壞習慣！
今天，與你分享敏捷團隊的最佳測試實踐之一。
要如何開始？如何知道要關注哪些領域？哪些測試方案應該採用自動化？在非敏捷軟件開發中，很多人不經意地陷入了“冰淇淋蛋筒反模式”的測試中，因爲該模式更加強調 UI 層面的自動化。 Abstracta團隊更喜歡將冰淇淋蛋筒倒過來的模式——由Mike Cohn推廣流行的方法，即敏捷測試自動化金字塔。它可以給自動化成本帶來最大收益，提高自動化的投資回報率，保證你將從自動化中獲得最大收益。
當我們的大部分工作都集中在 UI 級別的自動化上時，重點是發現錯誤；而對於敏捷金字塔，其重點爲避免錯誤。
在下圖中，你可以看到兩種方法的不同之處。
基礎層：單元測試
顯然，在金字塔中（作爲敏捷團隊最佳測試實踐的一部分），大部分測試應該在開發階段進行，在每次構建後進行單元測試。這些測試是最容易、最低成本及最快完成的，並且是測試驅動開發的一個重要方面。在較低的級別運行更多的測試可以讓我們在運行過程中即可檢查相應的工作，立即獲得反饋，並讓團隊在錯誤難以隱藏的時候準確地知道錯誤出現在哪裏。在這裏，這些錯誤的壽命也會更短，可能在不到一分鐘的時間內就被髮生、被清除了。而在 UI 測試過程中，錯誤會存活更長時間，併產生更激烈的矛盾，因爲它們已經舒適地存在了相對更長的時間。
中間層：API/集成/組件測試
運行所有單元測試並通過之後，就可以進入 API/集成/組件測試階段。運行集成測試是爲了確保所有組件正常配合工作。這裏無需通過 UI 即可測試大部分邏輯和業務流程，在此處最好儘可能地採用自動化。如果糾結於在此處自動化還是UI級別自動化，選擇這裏問題將變少、維護會更容易、測試執行會更快（意味着能更快發現錯誤，縮短它們的壽命），而且可以測試系統的邏輯。這些測試比單元測試更慢、更復雜，但它們仍然比 UI 測試更快、且不那麼脆弱。
頂層：UI 測試
最後講的，也是運行最少的是 UI 測試。最好儘可能少地進行UI 測試，因爲它們成本高、難準備、難維護，並且需要很長時間。在這一步，只是要確保用戶界面本身正常工作，系統的所有其他方面都已經過測試。只測試端到端最重要的部分，流程從用戶登錄開始，以如交易成功消息這樣的最終操作結束。關注與瀏覽器或 UI 相關的事情也很有幫助。運行 UI 測試後，可以進行手動和探索性測試（如金字塔上方的球體形狀所示）。
如上所述，與把重點放在自動化 GUI 測試上，並且無意中遵循“冰淇淋蛋筒反模式”比起來，金字塔方法是實現測試自動化的更強大、更有益和更具成本效益的方法。金字塔在單元測試階段提供了一個強大的基礎，可以在集成和 UI 階段進行進一步的測試，而冰淇淋蛋筒方法更頭重腳輕且穩定性較差。
爲了在敏捷開發世界中脫穎而出，就須遵循自動化金字塔測試，以儘可能生產出質量最好的軟件。但不需要只遵循一家之言，可多方參考資料並不斷實踐以獲得最適合團隊的測試方法。