導語

UTP自動化測試平臺是TMQ的一個聯合項目，目的是方便各項目測試人員更好地開展自動化測試建設工作，減少重複平臺建設的成本，提高產品的自動化測試效率。

該平臺可以提供通用的自動化執行環境和豐富的安卓雲手機資源（包含安卓雲模擬器），用戶可以方便的把本地的自動化測試遷移到平臺統一管理和調度，平臺還可以通過用例拆分併發執行爲自動化的執行加速，並提供豐富的報表功能。

本文主要介紹平臺的架構和如何進行一步步優化的。該系列後續幾篇文章，會分別對任務管理、用例管理、前段等進行詳細的展開介紹和心得輸出。

1 UTP初設計

UTP在設計之處就把系統劃分爲了任務管理、用例管理、資源管理和報表管理四個子系統，各個子系統由不同的開發人員負責開發，能獨立運作提供不同類型的服務，也可以提供組合的服務，或者與其他系統對接組合服務。

UTP在初期是基於傳統的web服務的模式快速搭建了整個系統，所以這些子系統各自都是部署在一個web容器中的web服務。在功能上劃分，任務管理系統，主要做自動化測試任務的配置和調度，還要做構建平臺（如RDM）的關聯，是用戶交互的核心，web端用php實現、後臺邏輯用python。其他幾個子系統都是java的web，用例系統主要負責用例的解析和配置，併發執行的時候也通過用例系統拆分；資源系統負責對接和管理優測的雲手機資源以及本地手機資源，並負責封裝自動化測試任務到jenkins系統；報表系統負責測試結果的上報和展示；jenkins主要是負責測試任務的執行和測試執行集羣的管理。測試執行集羣初期是2臺實體機。

基於此種架構和實現，系統初期是遇到了很多問題，尤其是自動化的執行數量上來之後，系統可用性很差。

（1）系統整體異常，常見有由某個子系統引起的oom，另外個別子服務發佈重啓的相互影響；

（2）單個子系統故障傳遞，導致其他子系統調用異常；

（3）單個自動化測試任務執行過程中異常情況很多，包括由網絡波動引起的雲手機斷線、雲手機適配、執行機資源不足oom等；

（4）執行機資源隔離不足，容易相互影響，比如adb掛了該執行機上所有的任務都不能正常執行；

（5）jenkins二次開發帶來的bug，之前各個測試團隊也經常用jenkins作爲持續集成或者測試的驅動平臺，很方便，但做二次開發的時候沒有足夠的預研和經驗，一是容易自己帶來很多bug，二是使用各種插件的過程中也容易遇到很多bug；

（6）第三方平臺依賴問題，對第三方服務異常沒有做隔離，導致整體服務異常。

2 架構優化之服務隔離和能力提升

基於當前的服務現狀，首先要解決的是服務的可用性和穩定性問題，讓服務自身能穩定的提供服務。首先要解決的問題是服務隔離，各個子系統的服務，首先要獨立運行在獨立的環境中，互不影響，利用公司的現有的隔離平臺很方便的就能實現服務隔離的目的，而且能根據業務的發展動態的擴容各個子服務。執行機並行執行任務的時候也存在相互影響的情況，所以執行機集羣也要遷移，而且通過隔離平臺動態創建實例可以更合理的增減執行集羣的資源，每個執行機實例只負責一個任務的執行，這就做到了自動化任務執行的隔離，而且出現單臺機器adb故障對其他任務的影響極大減小了。

通過隔離平臺擴容服務的實例，再通過負載均衡和錯誤重試的基礎能力，去掉了各個子系統服務的單點狀態，進一步提升了服務的可用性，基本消減了單個子服務異常或者子服務的發佈造成的短期不可用的影響，並且可以在單個節點出現異常或者超時的時候自動進行重試。

基於隔離平臺的分區域部署能力，調整了執行機的部署配置，通過就近原則（部署位置離優測雲服務最近的idc），之前執行任務的時候出現的雲手機斷線情況也得到了明顯的改善。

3 架構優化之服務拆分

在整體子系統隔離後，又進一步在各個子系統內部做了邏輯劃分，朝着微服務又進了一步，比如報表管理模塊，經常出現用戶上報的測試結果內容太大導致整體服務掛掉的情況，連帶影響了報表系統的其他對外接口和web服務，這樣報表系統就專門劃分除了一個結果上報的服務，只提供結果上報的服務，其他的作爲另外一個獨立的服務；資源系統也把手機資源的管理獨立成一個服務，與jenkins的對接也做成一個獨立的服務。

4 架構優化之服務容錯 #

在服務隔離和劃分的情況下，涉及的服務越來越多，調用鏈越來越長，另外服務實例的增長也帶來了更多的單點故障風險，從而使得整體流程可能因爲一個服務節點故障而中斷。這就要做好服務容錯，前面提到了已經處理了子服務的單點故障，另外加上了在子服務間的接口調用的邏輯重試，基本保證了偶發的異常情況。

另外一個需要做好服務容錯的是第三方服務的容錯，之前主要碰到的問題是內部的雲存儲平臺的故障，而UTP把自動化執行的任務、資源、結果等文件都存儲在那裏，當雲存儲平臺偶發嚴重故障的時候，UTP也連帶不可用。在容錯方面，UTP專門剝離出來了一個文件服務，通過本地文件和網絡文件雙源共存的方式，使得在雲存儲平臺故障或者有波動的情況下，UTP仍舊能夠使用本地文件執行自動化測試。當然本地文件有個問題就是需要定期清理以避免磁盤空間的持續上漲，這可能導致部分資源本地缺損的，但基本上近期的任務資源等文件都能命中本地資源。通過這種方法做到了的服務降級，在有損的情況下保證了服務的可用性。另外通過本地資源的命中，做到了熱點數據本地化，減輕了與雲存儲平臺交互的網絡負擔，也優化了任務資源文件下載的網絡延時。

5 總結和心得

經過一系列的優化，UTP的整體服務的穩定性終於提升上來可以提供穩定的自動化服務了，而這些處理也基本上是本着微服務的架構思想不斷優化。UTP雖然不屬於大請求量的服務，但是本身的業務邏輯比較複雜，涉及的子系統比較多，一個良好的架構能快速支撐服務的不斷髮展，如果一開始沒做好架構設計，可能就會陷入各種問題中難以提升。

如果你來設計一個自動化測試平臺系統，你覺得最需要考慮的是哪些點呢？架構怎麼設計呢？

版權所屬，禁止轉載

掃描下方二維碼，關注微信公衆號：騰訊移動品質中心TMQ，獲取更多測試乾貨！