如何快速掌握阿里巴巴內部高效測試流程？

09-05

如何快速掌握阿里巴巴內部高效測試流程？

近日，阿里巴巴產品專家金桐從自動化的煩惱，到分層自動化單元測試、業務服務層測試和UI測試的優劣勢分析，再到阿里巴巴分層自動化的實踐之路，為大家提供一套分層自動化實施解決方案。

自動化

為什麼要做自動化？

手工測試效率低下，發布頻繁，回歸量大、成本高，重複勞動很枯燥。自動化測試，就是用機器執行替代測試手工操作的一種測試方法，能夠幫助測試人員從重複、枯燥的手工測試中解放出來，從而節省人力、時間或硬體資源。

節約勞力為（N-1）M，M為此項工作單次需要投入的資源，N為此項工作需要重複工作的次數。

自動化的煩惱

如果自動化這麼好，為什麼大家沒有全部做自動化呢？特別是對於初創公司，自動化測試非常少，原因大致如圖。

上圖不難看出，阿里該部門這一周的自動化失敗次數不僅沒有與發現bug數成正比，還浪費了測試人員41次自動化失敗的排查時間，而這些時間對於做自動化查bug的初衷，都是無意義之舉。

為什麼外部環境、業務變更、應用環境問題、執行機問題、數據問題、框架問題這些都能引起這麼多失敗呢？而單單真正查出bug的概率這麼低呢？

結合我們的多年自動化實踐與總結，自動化存在如下這些缺點：

成本高

人員成本高：基本要懂某種自動化框架的代碼語言，要有一定的編碼能力，同時代碼邏輯要清晰，否則如何能保證合理性、邏輯性、業務性與健壯性這些大大影響自動化成功率的因素？如何能保證自動化測試腳本本身沒有bug？

環境成本高：開發環境、運行環境、調度環境等等，接觸過代碼的同學都知道，一次環境的安裝，沒有大半天甚至一天是完不成的。同時要讓自動化對接到項目自動化流程中，或定時監控等，還需要再開發調度平台，這些成本對於從0到有的測試組，甚至是一家公司，將會是多大？需要投入多少人日的工作量可以完成這些？

效果差

從上圖分析就知道效果如何，圖中還只是阿里某部門單周的一個採樣，就已經浪費了41次排查時間，這樣的自動化測試，若運行一年，那效果又會如何？能確保後面沒有這些干擾的失敗嗎？失敗次數可以和bug數成正比嗎？

覆蓋率低

經常有同學抱怨自動化的覆蓋率低，很多分支和邏輯無法覆蓋，這大部分原因是這些同學的理解偏差，很多人都將UI自動化作為自動化測試的全部。然而沒有一種自動化測試框架可以覆蓋一個系統的所有功能點的測試，所以出現「自動化」覆蓋率低的觀點。那該如何提高自動化的覆蓋率呢？

及時性低

其實從圖中10次業務變更引起的自動化失敗，就是這一缺點的佐證。所謂業務變更，是指正常的項目變更，但腳本未及時更新引起的自動化失敗。這種失敗恰恰又證明自動化測試是有用的，只要測試覆蓋到的內容，一旦有變，自動化就能測試出來。那如何提高我們的腳本及時性呢？

面對上述那些問題，我們不禁自問：做自動化測試真的有必要嗎？如果有必要，那如何降低這些成本，如何提高測試效果呢？經過不斷的實踐，我們引入了分層自動化測試的策略。

分層自動化

提到分層自動化，就會想到自動化經典的金字塔，第一層UI層針對頁面系統，第二層服務層針對於業務集成，最後底層單元測試針對底層服務等。

分層自動化的特點比較如下：

Unit（單元/底層服務）：

它可以通過mock框架，模擬各種異常場景，外部依賴最少，且可以做到測試粒度到最小的一種測試方法。也因為依賴少，可方便隨時隨地執行，也讓問題排查很簡單。這是一切測試的地基。優點是可到最小可測單元、其功能明確，特定條件、特定場景均可測，測試性價比很高，缺點是基本依賴開發同學去做，開源工具多、測試代碼多，要想全覆蓋，需要投入較多時間。

Service（介面/集成服務）：

它是單元組裝、功能組裝、條件組裝、場景組裝的集合，要求測試人員對系統的結構和系統間的調度非常清楚，同時要了解介面邏輯關係，否則介面測試代碼很容易遺漏一些異常場景。因此，我們需要測試人員的場景設計、構造測試數據、應用環境部署、同時也依賴介面單元的質量。同時，這一層由於含有一些業務邏輯和多介面的一個集成，所以相對單元測試來說，多了一些外界依賴，導致問題定位不會有單元測試層那麼準確。因此，維護和問題排查上的投入會比單元測試多一些。

UI（系統/頁面）：

它是最常見的黑盒自動化測試場景，能覆蓋的場景全面、條件全面、環境全面，最接近用戶。但也因為測試範圍全面，對測試人員、自動化腳本的健壯性等要求也會相對全面，需要考量場景設計能力、全面測試能力、框架選型成功、相關環境部署、業務邏輯清晰、功能測試邊界、依賴底層質量。因此，只要有一環薄弱，就會大大增加自動化的失敗率，而排查成本也因為環境太多太複雜而成倍增加。

以上就是分層自動化的主體三層，由此可見，分層自動化測試倡導的就是，將系統分層，根據層次特點用合適的自動化方法進行測試的一種測試策略。某個項目如何用自動化覆蓋，根據項目技術特點與項目屬性，設定合理的自動化測試補充，與整個產品的自動化測試體系結合保障。

除了分層方法與建議外，還有分層投入比，究竟花了多少時間做單測、多少時間作介面和UI？我們清楚知道，根據（N-1）M的勞力節約公式，不是所有項目都需要做自動化測試，主幹核心、業務穩定、項目周期長和重複工作多的項目是需要做項目自動化測試的，圖中展示了Google產品分層自動化投入比，它是比較完美的，當我們底層建設很完善的時候，上層建築的確可以花費較少時間，維護成本也會相對降低。我們目前達不到，但可向這個比例去發展。

阿里巴巴分層自動化的實踐

阿里巴巴分層自動化在經過策略的沉澱調整後，又經歷了長期的工具與流程實踐，並從自動化成本和效果這兩個重要缺點上突破，進行分層自動化工具和項目流程的雙重革命，最終達到業內領先的研發測試比。

首先，分層自動化工具革命

自動化測試框架，無論UI，介面還是單元，外部開源框架、收費軟體等很多，各有利弊。阿里測試綜合多種框架的實踐，對其進行改良與創新，突破了傳統自動化框架的眾多難題，大大降低了自動化的成本、提升了自動化效果。如下圖所示的四款重要工具，AUI主攻UI自動化，SAT主攻介面自動化，Amon主攻單元測試，以及Perf主攻性能，在傳統測試框架基礎的弱點上進行全面攻克與改造，最終實現鳥槍換大炮，全面提升測試工作效率。

UI自動化—AUI：

介面自動化—SAT：

單測—Amon：

不僅如此，阿里雲效還從需求-開發-測試-發布整個項目流程中可工具化、平台化的手工工作，全面進行工具化、平台化的改造，如圖所示。

開發環節：從拉分支開始，到自測的部署環境與單元測試，全部平台工具化。一鍵拉分支、一鍵部署、一鍵觸發單測集成，不到喝杯咖啡的時間，即可查看環境部署結果和findbugs、PMD、Sonar等代碼掃描結果。

測試環節：手工測試中有用例和缺陷兩款主打產品，平台沉澱，無需再做一些文件傳輸，加上前面介紹的分層自動化相關測試平台與工具，在自動化測試工作上的效率提升，最終實現整體測試工作的平台與工具化。

其次，項目流程革命

除了單個工具的成本減少與效果提升，雲效還優化了項目流程。如下圖是我們常見的項目流程，其中自動化測試工作經常只有單一自動化測試框架進行測試。

這樣的流程，經過長期實踐發現，研發測試比最多提升到3:1，是否還有改進空間呢？

我們再看這些流程，可以看到測試工作，尤其是自動化測試工作，獨立於開發項目流程。這種流程帶來最直接的問題就是自動化發現問題不及時，對於開發自測項目也沒有很好的介入保障，同時全手工觸發，人為因素影響非常大，這是限制開發測試比大幅提升的重要原因。

假設我們的項目在合理運用分層自動化的測試策略後，並將其觸發-問題排查-結果反饋都平台化地納入到整個需求-開發-測試-發布這個項目流程中，會產生什麼樣的效果呢？

圖為阿里項目分層自動化持續集成完整示意圖，我們多了集成自動化平台，該平台可以把分層自動化工具串聯在一起，去做整個持續集成、持續交付操作，讓工具具備了平台能力。不僅如此，我們還將分層自動化測試納入到了擬發布流程中，開發同學提交環境部署後，會自動提交自動化測試，不需要測試同學介入，如果失敗了才會通知測試人員排查，完全做到了CI／CD的理想效果。

項目集成可以使用，那麼日常的產品回歸也可以用，圖為阿里產品分層自動化持續集成完整示意圖，集成自動化給日常回歸產品做了賦能，將分層自動化工具平台和集成自動化串聯，去保證日常產品質量的回歸。

通過流程優化，在各個方面都得到了很大益處：

阿里內部：大幅提高研發測試比，減少重複勞動帶來的加班，更多高效工具的誕生，使用這套體系，B2B研發測試配比達到了8:1，部分產品線13：1，卻全年無故障。
研發：單測成本降低，覆蓋率可視化，自測有保障，故障降低。
測試：測試要求降低，重複工作減少，增加工作成就感，各種工具誕生。
雲效客戶：企業快速賦能，提高研發測試效率，快速掌握阿里內部高效測試流程。