本節書摘來自異步社群《精通自動化測試架構設計》一書中的第1章，第1.6節再啟航，作者陳冬嚴 , 邵傑明 , 王東剛 , 蔣濤，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
1.6 再啟航
盡管面臨這樣或者那樣的問題，一些測試團隊仍然成功獲得了開發團隊的信任，建立起了雙方每周對話的機制，在周例會上溝通彼此遇到的技術問題，并決定自動化測試任務的優先級。也有些測試團隊的成員，開始代替開發人員着手修複或者建立架構中的類，并送出代碼進代碼庫而不再隻作為缺陷描述中的補充。這樣做所取得的直接效果就是降低了與自動化測試架構相關的缺陷的修複時間。
在測試組織内部，也通過這兩年的鍛煉，吸引了一些熟練掌握架構api并且熟悉産品知識的自動化測試人員，他們通過bco牽頭，成立了一個虛拟的自動化測試團隊。
在這個背景下，終于有人喊出了測試組織需要拿回架構所有權的口号，并逐漸運用上述團隊的力量實施這一戰略。而開發團隊也終于越來越意識到加大投資自動化測試的必要性。于是整個工程部門召開了一次由相關方參與的自動化測試峰會。會議上基于自動化測試金字塔方針，提出了“做更有效的自動化測試”的政策。
1.6.1 自動化測試金字塔與冰淇淋
lisa crispin在其廣為流傳的《靈活軟體測試：測試人員與靈活團隊的實踐指南》一書中提到了自動化測試金字塔[4]。依據圖1.8所示的金字塔，自動化測試的資源投入或者收益額度從大到小的分别是單元測試、api測試、ui測試。
随着靈活這一軟體工程實踐日益成為主流，這一模式目前已經被行業遵守，甚至還演化出了其他不同的形式。例如，alister scott 提出了冰激淩模式[5]，這也是目前很多從ui開始自動化測試實踐的測試團隊的現狀。
在這種自動化測試的反模式下，如圖 1.9 所示，單元測試在冰激淩杯的底部，表示其數量或者投入很少，甚至有可能完全沒有。接着中間部分是內建測試，其情況略好于下部的單元測試。冰激淩杯的最上部，也就是體積最大的杯口部分，則是 ui 自動化測試。而在這個冰激淩杯裡面所盛放的，是一塊超級大的冰淇淋，名字叫做手工測試。冰淇淋是一種讓人産生愉悅感覺的食物，而這款自動化測試冰激淩，估計吃過的人很少會感覺好吃并且願意推薦給其他人。
1.6.2 橄榄形的自動化測試
自動化測試金字塔看似美好卻很難達到，而更多的自動化測試團隊，則是吃着自動化測試冰激淩大餐并且難以下咽。為了解決這一挑戰，an君從自身所經曆的經驗教訓出發，認為自動化測試首先要達到橄榄形的自動化模式。如圖1.10所示，接口測試位于中間，且占比最大，ui測試和單元測試位于橄榄的兩端。建議在測試組織的自動化測試達到這個穩定的橄榄形之後，再另行考慮自動化金字塔的可達到性。
從面向業務的角度來說，接口測試同樣可以覆寫業務邏輯的測試需求，并且相比于ui自動化測試其運作效率、穩定性和可靠性更高。從面向技術的角度來說，接口測試比單元測試進入的門檻更低，并且單個測試用例的覆寫範圍更廣，機關收益也更高。
從投資收益的角度考慮，也可以得出類似的結論。按照邊際效用遞減法則的原理，在進行自動化投資的初期，邊際效用會增加，自動化投資的總收益也随之增加。随着自動化投資的持續，其邊際效用會逐漸減少。而當邊際效用遞減至0時，表示總收益達到最大。如果此後再進行投資，反而會因為負的邊際效益而使總收益降低。
顯而易見，ui 自動化測試雖然覆寫範圍最廣，卻因為後期的高維護成本，ui 自動化測試投資的邊際效用是最早遞減至0的。單元測試卻因為前期的高投入，以及關注代碼自身，而不是業務的緣故，限制了其後期的總收益。是以，在各類型的自動化測試中，接口測試的綜合收益最高。
綜合來說，建議測試組織在自動化測試的發展路徑圖的初期，最大限度集中可投入的有限資源，首先實施接口測試或者內建測試，而後再涉及部分的ui/端到端自動化測試。而單元測試則可以交由開發人員自行完成，并交由內建團隊收集并執行，成為版本內建的前置測試的方式納入測試組織的用例庫。
這也是本書取名《自動化測試架構設計再入門》的緣由。讀者在讀完本書之後，會發現這裡假借webdriver自動化之名，卻是将讀者帶入到了統一自動化測試架構這扇門之前。由反式脂肪酸造出的自動化測試冰激淩即使好吃也不健康，是時候出來運動運動，打一場自動化測試橄榄球了。
本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。