阿里巴巴CI：CD之分層自動化實踐之路

阿里巴巴CI：CD之分層自動化實踐之路

2018-05-30 摘自：阿里巴巴CI：CD之分層自動化實踐之路

目錄 

1 自動化
  1.1 爲何要作自動化？
  1.2 自動化的煩惱
  1.3 自動化的追求
2 分層自動化
3 阿里分層自動化的實踐
  3.1 首先，分層自動化工具革命
  3.2 其次，項目流程革命

 

6月29日，由阿里雲研發協同RDC、阿里云云效和雲棲社區聯合舉辦的「首屆阿里巴巴研發效能嘉年華」上，阿里巴巴高級產品經理金桐帶來「分層自動化實踐之路」的演講。本文從爲何要作自動化開始談起，進而對分層自動化單元測試、業務服務層測試和UI測試進行優劣勢分析，最後重點分享了阿里分層自動化的實踐，包括工具分層和流程優化等。

隨着雲計算、大數據、AI智能等前沿科技的發展，傳統的研發速度愈來愈難知足企業快速發展的需求，研發效能也成了繼商業模式、技術突破以後的另外一核心競爭力。分層自動化測試倡導的就是將系統分層，不一樣層次須要用合適的自動化方法進行測試的一種測試策略。本文從你們熟知的單元測試、業務服務層的測試及UI自動化測試，進行優點和劣勢的分析，同時從執行速度、維護成本、測試方法、完成優先級、覆蓋範圍及實施團隊等多個維度，爲你們提供一套分層自動化實施解決方案，最後重點分享了阿里分層自動化的實踐，包括工具分層和流程優化等。一塊兒來了解下吧： 

1 自動化

---

 

 返回

1.1 爲何要作自動化？

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

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

1.2 自動化的煩惱

若是自動化這麼好，爲何你們沒有所有作自動化呢？特別是對於初創公司，自動化測試很是少，緣由大體如圖。

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

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

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

總結來看，自動化的煩惱包括如下四方面：

成本高：

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

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

效果差：

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

覆蓋率低：

常常有同窗抱怨自動化的覆蓋率低，不少分支和邏輯沒法覆蓋，這大部分緣由是這些同窗的理解誤差，不少人都將UI自動化做爲自動化測試的所有。然而沒有一種自動化測試框架能夠覆蓋一個系統的全部功能點的測試，因此出現「自動化」覆蓋率低的觀點。那該如何提升自動化的覆蓋率呢？

及時性：

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

1.3 自動化的追求

面對上述那些問題，咱們不由自問：作自動化測試真的有必要嗎？若是有必要，那如何下降這些成本，如何提升測試效果呢？通過不斷的實踐，咱們引入了分層自動化測試的策略。 

2 分層自動化

---

 返回

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

分層自動化的特色比較以下：

• Unit（單元/底層服務）：

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

• Service（接口/集成服務）：

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

• UI（系統/頁面）：

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

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

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

3 阿里分層自動化的實踐

---

 返回

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

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

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

• UI自動化—AUI：

• 接口自動化—SAT：

• 單測—Amon：

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

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

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

3.2 其次，項目流程革命

除了單個工具的成本減小與效果提高，雲效還優化了項目流程。以下圖是咱們常見的項目流程，其中自動化測試工做常常只有單一自動化測試框架進行測試。

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

咱們再看這些流程，能夠看到測試工做，尤爲是自動化測試工做，獨立於開發項目流程。這種流程帶來最直接的問題就是自動化發現問題不及時，對於開發自測項目也沒有很好的介入保障，同時全手工觸發，人爲因素影響很是大，這是限制開發測試比大幅提高的重要緣由。

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

圖爲阿里項目分層自動化持續集成完整示意圖，咱們多了集成自動化平臺，該平臺能夠把分層自動化工具串聯在一塊兒，去作整個持續集成、持續交付操做，讓工具具有了平臺能力。不只如此，咱們還將分層自動化測試歸入到了擬發佈流程中，開發同窗提交環境部署後，會自動提交自動化測試，不須要測試同窗介入，若是失敗了纔會通知測試人員排查，徹底作到了CI／CD的理想效果。

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

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

• 阿里內部：大幅提升研發測試比，減小重複勞動帶來的加班，更多高效工具的誕生

• 研發：單測成本下降，覆蓋率可視化，自測有保障，故障下降

• 測試：測試要求下降，重複工做減小，增長工做成就感，各類工具誕生

• 雲效客戶：企業快速賦能，提升研發測試效率，快速掌握阿里內部高效測試流程

使用這套體系，B2B研發測試配比達到了8:1，部分產品線13：1，卻整年無端障。