<b>一體化</b>：統一技術體系、統一管控模式、統一排程模式、統一使用者體驗，有效地提升了平台本身的可維護性，極大地提升了平台的使用者體驗，降低了使用成本；
<b>分層回歸</b>：支援分層自動化（單元測試、接口測試、webui自動化、前端測試）和端到端（全鍊路webui自動化）持續回歸；
<b>內建性</b>：提供豐富的api，便于與其他平台（如研發協作平台等）的內建；
<b>原子性</b>：方案的運作具備獨立的使用周期，不依賴于其他平台或系統；
<b>擴充性</b>：自主研發，可快速進行方案擴充，如代碼品質度量體系、覆寫率、持續內建等；
<b>業務解耦</b>：自動化管控子產品aqc-auto與手動用例管控子產品aqc-case解耦，自動化用例和手動用例将進行有機結合，為用例管控帶來了新的模式；
<b>平台規劃</b>：為開發自測、開發對産品品質負責、持續內建奠定基石；
<b>品質2.0</b>：沿襲小微産品品質團隊品質2.0，着力探索和落地技術助力效率提升理念。
整個平台主要涵蓋四大功能子產品，web管控、排程中心、心跳中心、資源管控，具體請參見圖1。方案架構圖請參見圖2，在後面将逐一進行解讀。
圖1
圖2
<b>1) 測試工程</b>：衆所周知，支付寶自動化測試用例（單元測試、接口測試、web ui自動化測試）都是在标準的java工程中；
<b>2) 自動化用例</b>：對于java工程，測試class中的method，我們定義為平台的自動化用例；
<b>3) 用例同步</b>：通過parse器對svn的java工程解析，確定實時的同步或增量同步到我們的自動化用例庫中，見圖3。
圖3
<b>1) 測試實驗室</b>：使用者可以基于測試工程，選擇待測用例集，建立測試實驗室，并配置相關的運作時候所必備的參數；
<b>2) 排程模式</b>：實驗室支援3種運作方式（onevent：提供api供其他平台調用執行，有效提升平台的內建性；onmanual：通過人工觸發，便于随時執行；ontime：無人值守定時觸發模式。）,排程設定見圖4。
圖4
<b>3) 執行粒度</b>：為了提升用例執行的便捷性，本平台還支援通過web頁面，人工手動運作單個用例或多個用例的方式；
<b>4) 通知機制</b>：支援郵件、郵件組、旺旺等通知機制；
<b>5) 排程記錄</b>：可以檢視不同實驗室的不同運作記錄以及運作明細，圖5與圖6。
圖5
圖6
<b>1) 回歸實驗室</b>：一個回歸實驗室，對應多個測試實驗室，見圖7；
圖7
<b>2) 排程模式</b>：可以批量執行多個同類型實驗室，以适應sit回歸、端到端回歸、資損用例回歸等業務需求，見圖8。
圖8
<b>1) 報告粒度</b>：提供測試實驗室和回歸實驗室的執行報告，使用者可以快速的定位到特定實驗室在特定的輪次中的特定用例的運作情況，見圖9。
圖9
<b>2) 透明化</b>：透明化了用例的整個執行過程，可以動态檢視到測試工程編譯失敗日志等，見圖10。
圖10
<b>3) 趨勢分析</b>：透明化各個測試實驗室運作趨勢資訊，為用例維護推動提供便捷，見圖11。
圖11
<b>1) 服務注冊</b>：不同類型的實驗室排程模式是不一樣的，需要将不同的排程模式的接口注冊到排程中心，實作業務的解耦和排程中心的通用性；
<b>2) 任務管控</b>：不同的測試運作，都會形成任務隊列中的一個任務，任務的執行與觸發，是通過執行排程中心的任務子產品去完成的。
<b>1) 适配中心</b>：本平台是一體化平台，但是針對不同測試類型的實驗室，需要不同的runner去适配；
<b>2) 環境治理</b>：不同類型的用例對環境的要求不一樣，可以通過一些通用腳本的執行，完成環境的初始化和清理工作；
<b>3) 回調管理</b>：主要是将運作的結果、日志、運作情況寫入平台。
<b>1) 裝置管理</b>：平台提供分門别類的裝置管理和開放的openapi，承載着回歸體系所需要的硬體資源，進行統籌和調配；
<b>2) 透明化</b>：為了透明化測試資源的使用情況，這裡會提供相應的報警機制，讓使用者可以實時檢視到機器裝置的使用狀況，便于即可對硬體資源做相應的處理；提供openapi，因為本平台不單單承載在pc自動化回歸體系所需要的裝置，目前工具研發團隊所研發的安全産品測試平台的硬體資源也來源于此；
<b>3) 資源池</b>：提出資源池的概念，源于特定測試回歸實驗室對硬體資源的配置性要求的不同，確定回歸實驗室的原子性和隔離性，在平台資源管控中，我們也設定了相應的公共資源池，有效提升資源使用率；
<b>4) 快捷操作</b>：提供一些便捷的操作，如重新開機tomcat、安裝jdk、安裝maven等；
<b>5) 統一資源池</b>：本裝置管理子產品即将成為小微回歸體系平台的資源池，為業務的擴充做好充分的準備，見圖12。
圖12
筆者認為，工具平台不是目的，隻是助力效率提升的手段，不論是工具平台建設的本身，還是工具平台的服務化能力，高質高量研發出高效的效率工具，助力業務成長，提升研發效率，才是根本，在自動化回歸體系建設中，工具平台建構起三套回歸體系（無線、全站、cro），走出去，引進來，打造網際網路金融測試之回歸體系标杆，和業界同仁一起共促自動化回歸體系建設。
無線-自動化回歸體系：針對快捷支付、錢包、商戶app特點，無縫支援自主研發架構（trobot）和開源架構（如robotium）；支援性能監測、安裝解除安裝啟動測試的無縫接入；
全站-pc端分層與端到端回歸體系：無縫支援從分層（單元測試、接口測試、webui自動化、前端測試）回歸和端到端（全鍊路webui自動化）回歸；
安全部-安全産品回歸體系：支援無線用戶端産品的回歸，支援python、ruby等語言用例。
自動化不是萬能的，但自動化必将越來越受重視，将作為手動測試的必要補充；
自動化回歸體系也許将成為開發自測、開發對産品品質負責的必備武器；
提升自動化回歸體系服務化能力，将成為自動化建設的核心之一；
自動化價值最大化，才能提升全員對自動化的信心；
工具平台建設，不同于傳統的研發，我們每個同學都需要具備pd+dev+tester能力；
作為工具研發團隊，我們不僅僅要輸出我們的工具平台，還要提升工具服務化能力；
作為工具研發團隊，我們更要輸出我們的技術，提升技術服務化能力，促進建構線下工具平台建設生态體系，讓工具去驅動未來，讓工具去為研發保駕護航。
<b>王超</b>，花名于龍，現任支付寶進階技術專家。2007年計算機軟體與理論專業碩士畢業，先後在微軟、sap、淘寶網從事自動化測試用例開發、自動化架構研發、測試平台建設、資訊系統研發、測試工具研發團隊管理等工作，主導研發淘寶網pc自動化測試架構automanx、支付寶品質風險防控平台aqc、支付寶無線測試平台、資損防控t+1核對平台等産品，目前負責支付寶産品品質部工具研發團隊，專注于支付寶線下工具平台建設，業務涉及持續內建、自動化回歸體系、資料平台、資損防控、技術風險防控、性能評測中心、測試管控等平台或工具建設。作者郵箱：[email protected]。
感謝侯伯薇對本文的審校。
本文轉載自infoq