自動化測試在美團外賣的實踐與落地

隨著美團到家業務的發展，系統複雜度也在持續增長。測試用例數量近兩年增長約一倍，單端數量超過1萬2千條，而研發人員的工作從大部分時間在開發，轉變成一半時間在開發、一半時間在模擬環境和自測。因此，引入自動化測試就顯得十分有必要，本文介紹了美團外賣在自動化測試方向做的一些探索和實踐，希望對從事相關領域工作的同學能夠帶來一些啟發或幫助。

1. 專案背景

美團外賣的業務場景比較多元化，除了外賣自身的業務，還作為平臺承接了閃購、團好貨、醫藥、跑腿等其他業務。除此之外，在全鏈路動態化的大基調下，外賣各個頁面的技術形態也變得越來越複雜，除了Native程式碼，還包括Mach（外賣自研動態化框架）、React Native、美團小程式、H5等，不同技術棧的底層技術實現不同，渲染機制不同，進而對測試方式要求也有所不同，這也在無形中增加了測試的難度。下圖彙總了美團多業務、多技術、多App的一些典型場景。

在產品交付上線的過程中，測試的佔比也是非常大的，甚至大於總時長的30%。如下圖所示，整個測試包括了冒煙測試、新功能測試、二輪迴歸測試、三輪測試。然而，現在需求測試絕大部分還是採用非自動化的方式，這就使得人力成本變得非常之高。

另一方面，相比於2018年，2022年的測試用例數量增長近3倍，已經超過1萬2千條（如下圖所示）。同時，外賣的業務是“三端複用”，除了外賣App，還需要整合到美團App和大眾點評App上，這樣一來，測試工作量就翻了3倍，業務測試壓力之大可想而知。如果按照當前的增長趨勢持續下去，要保障外賣業務的穩定，就必須持續不斷地投入大量的人力成本，所以引入能夠支援外賣“多業務場景”、“多App複用”、“多技術棧” 特點的自動化測試工具來提升人效和質量，勢在必行。

2. 專案目標

為了解決外賣面臨的測試困境，我們嘗試去探索一種零學習成本、低維護、高可用的自動化測試方案，能夠支援外賣複雜多變的測試場景，它必須同時滿足下面幾點要求：

• 易用性：工具/平臺的上手難度，使用複雜度應該儘可能的低，因為自動化測試的目的是提效人力，而不是增加人力負擔。
• 平臺支援：移動端至少需要覆蓋iOS和Android雙平臺，同時基於外賣的業務特點，不僅需要對Native支援，也需要支援Mach（自研區域性動態化框架）、H5、React Native、美團小程式等技術棧。
• 穩定性：自動化測試用例的執行需要有足夠的穩定性和準確性，測試過程中不應因測試工具本身的不穩定而出現穩定性問題。
• 維護成本：維護成本很大程度上決定了測試工作量的大小，因需求產生變動或架構重構等問題時，用例的維護成本應該儘可能的小。
• 可擴充套件性：當測試方案不能滿足測試需求時，工具/平臺應具備可擴充套件的能力。

3. 方案選型

自動化測試工具那麼多，自研是重複造輪子嗎？

針對終端的UI自動化測試工具/平臺可謂“屢見不鮮”，市面上也有很多相對成熟的方案，相信大家都有用過，或者至少有所耳聞，但這些方案是否能真的滿足我們提效的訴求呢？以下我們挑選了三類非常具有代表性的自動化測試工具/平臺 - Appium、Airtest Project、SoloPi進行了分析，來幫助大家對自動化測試技術建立一個認知：

---	Appium	Airtest Project	SoloPi
指令碼語言	支援Python，Java，JavaScript，PHP，C#，Ruby，OC等	Python	/
資料記錄（網路/本地）	不支援	不支援	不支援
環境模擬	不支援	不支援	不支援
上手難度	高，需要各種環境支援和語言學習	一般，不熟悉程式語言，也可以一定程度使用	低，用例即操作，不展示
問題溯源成本	高	高	高
維護成本	高	高	高
檢視檢索	基於UI控制元件的檢索，支援10多種UI控制元件查詢方式	基於影象識別和基於UI控制元件檢索兩種方式	基於影象識別和基於UI控制元件檢索兩種方式
原始碼整合	無需	可選	無需
WebView支援	支援	支援	支援
用例編輯	支援	支援	支援
平臺支援	iOS、Android、Windows	iOS、Android、Windows、遊戲測試	Android

• Appium是一個開源工具，用於自動化測試iOS手機、Android手機和Windows桌面平臺上的原生、移動 Web和混合應用。它使用了各系統自帶的自動化框架，無需SDK整合，Appium把這些系統本身提供的框架包裝進一套API——WebDriver API中，可以使用任何語言編寫Client指令碼向伺服器傳送適當的HTTP請求。這讓不同技術棧的人員都能快速上手編寫測試用例，可以選擇自己最為熟悉的語言，但是對於沒有語言開發基礎的人來說，還是有一定學習成本，而且這種方式在多人協作時並沒有太大作用，為了保證自動化用例的可維護性，團隊內部應該需要統一指令碼語言。值得一提的是：Appium在iOS、Android和 Windows 測試套件之間可做的一定程度的複用程式碼。但是由於不同端介面及元素定位的差異，這往往是不現實的，更無法保證測試的準確性，所以這種所謂的“跨端”就變得毫無意義。
• Airtest Project是由網易遊戲推出的一款自動化測試平臺，除了支援通過系統自帶的自動化測試框架，還支援了通過影象識別的方式，對於非基於原生UI系統的一些遊戲引擎提供了SDK的支援。其上手難度稍低，可以一定程度上通過IDE進行相關操作來生成簡單的指令碼指令。Airtest雖然基於影象進行控制元件識別，為跨端提供了一定的可能性，然而影象識別並不能達到人眼識別的準確度，除此之外移動端頁面的構成和遊戲頁面也存在不小的差別，頁面元素的展示規則和樣式受螢幕解析度影響較大，單純依靠影象識別來進行元素查詢成功率不高，無法保證測試的準確性。
• SoloPi是一個無線化、非侵入式的自動化測試工具，通過錄制回放的方式進行UI自動化測試，SoloPi雖然只支援Android，但是在錄製回放的這種方式中，還是極具代表性的。傳統的自動化測試工具由於需要編寫測試指令碼，所以存在著一定的上手難度（Airtest還是存在程式碼編輯的），便產生了SoloPi這種純基於錄製回放的自動化測試方式，將用例的所有操作事件進行錄製，生成一個完整的錄製指令碼，通過對指令碼的回放來還原所有的操作，從而進行自動化測試。但是，這種方式只能記錄操作，而不能記錄資料，在外賣這種資料驅動展示的場景下無法滿足測試要求。並且外賣的業務要複用到美團App和大眾點評App中，不同App存在部分檢視和邏輯性的差異，SoloPi也無法支援我們“一端錄製多端回放”的測試場景。

可以看出，以上這些自動化測試工具/平臺對於資料記錄，環境模擬、維護成本、跨App複用等方面，都是有所欠缺的。所以無論是哪種方案，在易用性、維護成本、穩定性、可擴充套件性以及最終的測試效果上，都無法滿足我們對自動化測試的需求。我們並不是為了自動化而自動化，而是要解決實際的提效問題。

那麼，怎樣才能確定一個自動化工具/平臺的可用性，並長期落地去使用自動化，帶著上述提到的較高門檻的上手成本、操作繁瑣的環境模擬、差強人意的測試成功率、定位模糊的測試缺陷、難以維護的用例指令碼等幾大重要痛點，本文我們將介紹美團外賣自研的測試平臺——AlphaTest，都具備哪些能力以及是如何解決這些問題。

4. 實踐和探索

一個自動化測試工具/平臺能不能用起來，取決於他的上手成本和穩定性，即使工具的測試穩定性做的再好，使用的門檻高也會讓人望而生卻，反之亦然。所以AlphaTest平臺為了上手簡單，降低使用成本，採用了基於錄製回放的方式進行設計，並且彌補了常規錄製回放無法編輯的痛點，同時在手勢操作的基礎上增加了資料錄製。整合美團系App的特性增加了環境模擬、跨App支援、混合技術棧的支援等能力，在使用簡單的同時，也保障了用例的可維護性、測試的準確性等。我們先通過視訊簡單的瞭解一下：

用例錄製：

點選檢視視訊

用例回放：

點選檢視視訊

回放報告：

點選檢視視訊

4.1 問題和挑戰

注：這裡我們將生成的自動化指令碼統稱為指令，將平臺生成的用例統稱自動化用例，將錄製回放變成視覺化的指令碼指令，讓用例變的易懂、易維護。

錄製回放本身是一連串的操作資料的集合，是連續性的、不可拆分，因此幾乎不具備可編輯性，這也就導致了用例維護成本極高。AlphaTest雖然同樣基於錄製回放的方式生成自動化用例，但是我們將每一步的操作都具化成結構化的指令資料，並提供視覺化指令編輯器，以支援檢視編輯。

這些視覺化的指令，完全通過錄制自動生成，也不依賴於任何指令碼語言。通過視覺化用例指令編輯器，不僅為用例提供了編輯的可能性，同時大大地提高了用例的可閱讀性，每一條測試用例在測試過程中每一步都做了什麼、當時的介面是什麼樣的、都有哪些斷言校驗點，是顯而易見的，不會存在像傳統圖文描述的測試用例那樣，出現理解偏差。指令生成演示，手機錄製與平臺遠端錄製雙模式支援：

4.2 前置條件準備

一鍵環境模擬，解決操作繁瑣的用例執行前的環境準備。

進行一個用例的測試之前，往往需要做大量的準備工作，比如切換API環境，定位到某個地點，登入指定賬戶等。這些需要準備的環境條件我們統稱為前置條件。我們知道，前置條件的準備操作通常都不是一兩個步驟就可以完成的，比如賬號登入/切換：我們需要進入登入頁，填寫手機號+密碼/驗證碼，點選登入等一系列動作來完成這個過程，非常繁瑣，並且每次測試我們都需要準備，重複性高。因此，我們給AlphaTest設計了獨立的前置條件模組，將用例拆成了兩個部分：前置條件 + 操作步驟。

與其它測試框架不同的是，AlphaTest採用了SDK整合，但對業務無侵入的方式，因此可以通過編寫白盒程式碼來實現前置條件的自動配置，只需要在平臺新增需要的指令，下發到SDK後，即可根據相關指令完成前置條件的自動配置，不再需要重複進行相關的操作。並且這些前置條件支援複用，也不需要每次進行用例準備時的重複配置。AlphaTest的前置條件，不僅有著基於美團內部服務及底層Hook的預設實現，也提供了API支援業務方自定義實現，比如實現不同的賬號體系。

4.3 用例錄製與回放的資料一致性

影響用例執行的不僅是程式碼，還有資料。

很多時候，自動化用例無法正常執行完成，可能是因為App回放時的本地資料及網路資料與錄製時的不一致，從而導致用例執行流程的阻塞或App介面展示的不同。這也是大多數自動化測試工具/平臺測試通過率不高的主要因素，因此要保證測試成功率，我們需要控制變數，排除由資料產生的影響。

App執行依賴的資料，有兩部分——本地資料和網路資料：

• 本地資料是App在執行期間產生的快取資料或持久化的儲存資料。為了讓用例在錄製回放時都能夠保持一致的本地資料環境，我們在錄製和回放前都對App的本地資料進行了清理操作，這樣用例在錄製和回放的過程中，都可以保持一致的App初始化環境。
• 網路資料是驅動App互動呈現的基石，各種策略和API升級都會影響網路資料的響應，因此我們將用例錄製過程中產生的網路資料也進行了錄製，並將網路資料和對應的操作指令進行了關聯和繫結，確定了資料產生的事件源。排除資料影響後，我們的自動化測試的成功率就取決於自動化操作的準確性了，這就回到了常見自動化框架範疇。

4.4 用例錄製與回放的操作一致性

目標定位的準確性與手勢定位的精準性。

UI自動化測試的本質就是代替人去自動的做一步步的操作（點選、長按、輸入、滑動等）。錄製與回放過程的操作能否一致，是否精準，直接影響測試的成功率，決定了工具/平臺的可用性。

• 目標控制元件定位準確性：

操作行為是否一致首先需要確認操作目標是否一致。與一般測試工具/平臺不同的是AlphaTest採用了ViewPath + 影象 + 座標的多重定位方案。得益於SDK整合的方式，我們的ViewPath可以記錄更多的元素檢視特徵和執行不同的匹配策略。定位過程中會優先使用ViewPath進行目標控制元件檢索，當目標控制元件查詢異常時，會結合影象匹配和座標匹配的方式進行兜底查詢，來確保介面變化程度不大時，也能準確的查詢到目標控制元件。

• 手勢定位的精準性：

有了基於控制元件的目標定位之後，對於一些常用簡單操作手勢，比如點選、長按、斷言、甚至輸入都可以做到很好的支援，只需要找到對應的控制元件，在控制元件所在位置下發相應的觸控事件即可。我們知道，App真正接收的觸控事件是螢幕上一個個精準的觸控點，在系統處理後，分發給當前App視窗，App在接收事件後再繼續分發，直到找到事件的最佳響應者，後續通過響應者鏈對事件消化處理。那我們要還原一個觸控事件的座標點要如何確定呢？由於我們確定的只有控制元件，所以這個點自然而然就成了控制元件的中心點了。

大多數情況下，這些都可以很好地進行工作，但是對於一些多響應控制元件重疊的情況，可能會產生預想不到的操作誤差。為了解決這樣的問題，我們把控制元件定位與座標定位進行了結合：基於純座標的定位是一種定位精準度非常高的定位方式，但是穩定性非常差，只有在螢幕解析度完全一致且回放頁面控制元件位置完全一致的情況下，才具備足夠的可靠性，但這往往是不現實的，對測試環境機器量要求過高。

基於控制元件的定位，又存在著精準度不夠的問題。使用座標定位，如果定位區域足夠小的話，那麼受螢幕尺寸的影響就會越小，只需要確定在小範圍內的相對位置即可。而基於控制元件目標的定位，恰恰可以把目標區域縮小到一個指定區域，我們剛好可以將二者結合起來，同時解決定位精準度和穩定性的問題。

對於複雜手勢的支援，我們同樣可以採用微分的方式，將一個複雜手勢拆成多個簡單手勢的組成，比如我們可以將一個滑動操作的定位拆成兩個部分：起始位置和終止位置，而這兩個位置的定位，就變成了兩個普通的單點手勢操作定位了，可以通過上面提到的一個目標控制元件+相對座標的形式進行定位。核心思想都是將基於螢幕座標點的定位操作，縮小的目標控制元件的區域範圍內，以達到不受裝置解析度的影響，實現操作行為一致的效果。

4.5 可溯源的自動化測試

測試全流程記錄，問題溯源一鍵即達。

測試的目的是保證App執行的穩定，測試過程中出現Bug導致測試未通過時，需要溯源問題原因，發生的場景，乃至具體的執行步驟。這也是大多自動化測試工具/平臺所欠缺的，即使發現了問題，排查工作也很困難；這個問題在手工測試的時候，更為嚴重，往往因為很多缺陷無法復現而難以定位。

AlphaTest的自動化用例最小執行單元是操作指令，我們將測試過程的每一條指令的執行狀況和過程中的介面快照進行了記錄，並在指令執行失敗時，對異常原因進行了初步分析。然後將整個用例的執行組合成了一份完整的測試報告，可快速溯源問題步驟。除此之外，我們還增加大量的日誌上報，並將整個用例測試過程進行了視訊錄製，來進一步幫助疑難問題的排查。真正做到了用例回放測試可溯源。

4.6 用例的維護

自動化用例需要持續地投入人力來維護麼？架構升級，頁面重構，用例需要全部重新錄製麼？

因自動化工具/平臺眾多，阻礙長期落地使用的一大問題是用例維護成本高，很多工具/平臺讓我們即便是使用上了自動化，但還需要持續投入人力維護用例的更新，最終的提效收益微乎其微。對於用例更新維護，我們可以梳理劃分成三個場景：

• 需求發生重大變更，整體的業務執行流程及相關的校驗點都需要進行大量的調整。對於這種情況，無論是何種自動化測試工具/平臺，都是需要正常進行用例變更重錄以適應新的需求。
• 需求發生略微變更，業務流程基本一致，需要調整的校驗點、操作以及資料或不影響整體流程的步驟。對於此場景，AlphaTest通過指令編輯器與操作錄製，支援指令增刪改以及資料和場景的還原，幫助使用者快速的進行用例調整，而無需重新錄製用例。例如：修改網路資料欄位、檢視變更路徑、斷言替換目標等。

• 和業務需求不同，我們的技術實現也會發生迭代。隨著App技術架構不斷的演進，經常會面臨著架構升級，頁面重構甚至技術棧變遷等這樣的技術升級。這些變動需要覆蓋大量的測試用例，其中大量的自動化用例又可能會因為變動而導致失效，需要重新錄製。為此，AlphaTest設計一套利用相近解析度機器進行用例自動修正的功能：利用影象 + 座標進行二次識別定位，元素定位成功並校驗通過後，生成新的ViewPath，更新對應的用例指令，對用例進行自動修復，修復後可在任意回放。

4.7 跨App回放用例

同一份程式碼執行在不同的App上，是否需要重新編寫多份用例？

美團系的一些業務可能會複用在多個App上。比如外賣有獨立App，但同時也要複用到美團和點評App上，這些功能，幾乎共用一份程式碼，而測試人員卻不得不對每個App上的業務功能都進行測試，維護多份用例。由於業務本身實現是一致的，那我們可以通過適配不同App之間的差異，來讓一個業務Case可以橫跨多個App回放，這便可以將成本縮減好幾倍，這些差異主要體現在：

• 前置條件和初始頁面：業務的初始頁面進入路徑不同，例如外賣App開啟App就進入到了外賣首頁，但是在美團App中就需要從美團首頁跳轉到外賣頻道。同時由於不同App的樣式風格、設計規範、業務特性等因素，也會造成首頁程式碼邏輯和檢視層級的差異。
• AB實驗配置：不同App所配置的實驗可能不同，不同的實驗會導致不同的樣式和程式碼邏輯。
• 網路介面對映：不同App中相同業務場景涉及的介面有所不同。
• 頁面Scheme對映：不同App中相同頁面的跳轉Scheme也不相同。

AlphaTest平臺支援App維度各項差異資料配置，當SDK檢測用例回放環境與錄製環境不一致時，會自動進行對映適配，從而讓用例執行到了不同App上。

4.8 埋點的錄製回放

除了功能測試，我們在日常開發和測試的工作中，還會面臨另外一個比較重要的問題就是埋點測試。因此，我們在自動化的基礎上擴展出埋點自動化測試。埋點自動化測試的核心思想是，通過對比錄製時期和回放時期的埋點上報時機和上報引數進行判斷。為了保證埋點自動化測試的穩定性，我們主要採用以下的障機制：

• 欄位規則配置：埋點自定義引數千姿百態，甚至有些欄位每次程式碼執行都不一致，如果進行完全匹配結果註定是失敗的，所以我們在AlphaTest平臺提供了埋點欄位規則配置功能，通過人為設定的方式來避免埋點自定義引數校驗失敗。App重啟進入錄製狀態時，使用者就可以操作App，平臺會記錄使用者的操作行為，當產生相應的埋點日誌的時候會將日誌資訊列印在日誌區域（如下圖17所示），在該過程中也會對埋點日誌進行一定的校驗。重點將操作時機、埋點日誌一併儲存到服務端。

• 埋點時機校驗：針對時機校驗，程式並不支援埋點曝光的"1px曝光"，"下拉重新整理曝光"，"頁面切換曝光"，"切前後臺曝光"這些規則，主要的原因是每一個業務方在對埋點曝光的規則都是不一致的，而且該規則的實現會極大耦合業務程式碼。在針對時機校驗我們目前只支援：

  [1] 點選埋點上報時機校驗，程式通過事件監聽和埋點型別資訊來判斷點選埋點上報的時機是否是在點選的操作下產生的，如果不是則報錯。

  [2] 埋點重複上報校驗，針對一般情況下使用者一次操作不會產生兩個相同的埋點上報，所以程式會校驗某個事件下發生的所有埋點日誌進行一一校驗，檢測是否具有2個或多個埋點日誌完全一致，如有發生則會上報錯誤。

• 結果校驗：回放完成後，我們會對比錄製和回放時的埋點資料，根據配置好的欄位規則校驗埋點上報是否符合預期。

5. 測試流程

AlphaTest的核心測試流程始終聚焦在用例的錄製與回放環節，整個流程涉及到自動化任務觸發、回放叢集排程、斷言服務、訊息推送等核心模組。

以UI自動化和埋點自動化的流程為例，AlphaTest以業務團隊為基本單元，可以和各團隊的測試用例進行關聯，定時同步狀態。同時利用需求評審線上化做為基礎，將自動化用例和研發流程中的PR、整合打包、二輪迴歸等節點相結合，定時觸發自動化用例並將結果報告推送給相關負責人。

• 錄製用例：

  [1] 首先在AlphaTest平臺選擇要錄製的測試用例，開啟待測試App進行掃碼即可進入用例待錄製狀態，此時可以設定用例需要的前置條件（賬號資訊、Mock資料、定位資訊等），之後點選開始按鈕後，手機便會自動重啟，開始錄製。

  [2] 使用者按照測試用例步驟，正常操作手機，AlphaTest會將使用者的操作行為全部記錄下來，並自動生成語義化的描述語言顯示在AlphaTest平臺上，與此同時產生的網路資料、埋點資料等校驗資訊也會一併儲存下來。

  [3] 在錄製的過程中可以快捷的開啟斷言模式，將頁面上想要校驗的元素進行文字提取/截圖等操作記錄下來，用於後續回放過程中對相同元素進行校驗。

  [4] 測試步驟全都執行完畢後，點選儲存按鈕即可生成本條自動化用例。

• 用例回放：

  [1] 掃描對應自動化用例的二維碼即可進行回放，回放過程中會將使用者錄製的行為、網路資料進行一比一還原，並且輔助有全過程視訊錄影，用於後續問題排查和溯源。

  [2] 回放過程中碰到斷言事件時，會將斷言的元素進行文字提取/截圖，上傳至AlphaTest平臺。回放完成後，會將回放時候的斷言截圖和錄製時的斷言截圖進行影象對比，作為整個測試結果的一項。

  [3] 回放過程中的埋點資料也會一併記錄下來，並和錄製時候的埋點資料和上報時機進行對比，自動提取出其中的差異項。

  [4] 回放完成後，會生成完整的測試報告並將結果通過OA推送至相關人員。

• 回放計劃：二輪迴歸測試中，回放用例數量多達幾百條，為了做到全流程的自動化，我們提供了回放計劃的概念，可以將多個自動化用例進行編組管理，每一組就是一個回放計劃。觸發一個計劃的回放即可自動觸發計劃內的所有自動化用例。整個計劃都執行完成後，會通知到指定的計劃負責人或群組。

5.1 自動化任務觸發

在整個外賣C端敏捷迭代的流程中，打包平臺主要承接了業務需求發起到需求交付的流程，作為AlphaTest的上游平臺，可以提供打包資訊並觸發自動化用例回放任務。以下簡單展示AlphaTest與敏捷協同平臺的互動流程：

5.2 回放叢集排程

整個測試過程真正的解放雙手，才能算的上是自動化。因此，我們著手搭建了自己的自動化機器叢集，可以 24小時不間斷的執行測試任務。為了保證任務回放能夠順利完成，我們在不同階段增加了相應的保活策略。在極大程度上提高了任務執行完畢的成功率。

• 執行流程：回放任務通過使用者在平臺手動觸發或者二輪自動觸發。新增的回放任務經過任務拆分系統拆分成n個子任務，加入到不同裝置的回放任務佇列中。每個子任務經過佔用裝置->安裝待測App->應用授權->開啟scheme->上報結果等步驟完成回放操作。
• 節點保活機制：針對回放流程中每一個節點，失敗後進行N（預設為3）次重試操作。減少因網路波動，介面偶現異常導致的回放失敗數量。
• 子任務保活機制：每個回放流程，失敗後進行N（預設為3）次斷點重試。減少因裝置異常，SDK心跳上報異常導致的回放失敗數量。
• 父任務保活機制：一個父任務會被拆分成N個子任務，當其中的一個子任務S1在節點保活機制和子任務保活機制下仍然執行失敗之後，父任務保活機制會嘗試將子任務S1中未執行完畢的用例轉移到其他活躍狀態的子任務中。減少因裝置異常，裝置掉線等問題導致的回放失敗數量。

5.3 斷言服務

用例斷言是整個自動化用例驗證的核心步驟，我們的斷言服務依據用例的實際情形可以分別進行文字與影象的斷言。其中影象斷言服務依託於自建的影象對比演算法服務，可以高效進行錄製回放斷言影象的對比，影象對比準確率可以達到99%以上。

• 錄製階段：

  [1] 錄製時增加斷言決策資訊的自動採集。

  [2] 和正常流程一樣，提取區域的截圖資訊。

  [3] 如果是文字元件，則提取文字內容，如果是圖片元件，則提取圖片二進位制編碼或圖片URL，同時提取區域內的佈局資訊。

• 回放階段：

  [1] 回放時，提取和錄製時一致的內容（文字資訊、圖片編碼、區域截圖、佈局資訊）。

  [2] 將回放時的斷言資訊上傳至AlphaTest平臺。

  [3] AlphaTest平臺對斷言結果進行校驗，首先是基於模型的影象對比，如果判定為一致，則直接標記結果。

  [4] 如果判定為不一致、則匹配“斷言失敗資料集”，如果能夠匹配上，則標記結果。如果匹配不上，則需要人工選擇匹配型別。

  [5] 匹配型別為“文字校驗”、“根據圖片資訊校驗”、“人工校驗”。如果前兩項判定為一致，則直接標記結果。如果“人工校驗”的結果為確實兩張圖不一致，則直接標記結果，結束。

  [6] 如果“人工校驗”結果為一致，既上述所有判定都不準確，則需要人工對兩張圖中判定錯誤的原因進行分類（具體型別待定），同時將斷言儲存到失敗資料集。

  [7] 模型自動訓練，當資料集超過一定的閾值、通過定時觸發、或者手動觸發的方式，觸發模型自動訓練，訓練完成後自動部署到AlphaTest平臺，不斷迭代。

• 影象服務：影象對比模型採用基於度量學習的對比演算法，將影象對的一致性判別轉換為影象語義的相似度量問題。度量學習（Metric Learning），也稱距離度量學習（Distance Metric Learning，DML）屬於機器學習的一種。其本質就是相似度的學習，也可以認為距離學習。因為在一定條件下，相似度和距離可以相互轉換。比如在空間座標的兩條向量，既可以用餘弦相似度的大小，也可以使用歐式距離的遠近來衡量相似程度。度量學習的網路採用經典的Siamese結構，使用基於resnext50的主幹網路提取影象的高階語義特徵，後接spplayer完成多尺度特徵融合，融合後的特徵輸出作為表達影象語義的特徵向量，使用ContrastiveLoss進行度量學習。

[1] 預訓練過程：resnext50網路是使用ImageNet的預訓練模型。

[2] 資料增強：為增加資料的豐富性、提高網路的泛化效能，資料增強的方式主要包括：影象右下部分的隨機剪下和新增黑色蒙層（相應改變影象對的標籤）。這種資料增強符合控鍵截圖實際情況，不會造成資料分佈的改變。

[3] 對比損失：對比損失函式採用ContrastiveLoss，它是一種在歐式空間的pair based loss，其作用是減少一致影象對距離，保證不一致影象對的距離大於margin，其中margin=2。

[4] 相似度量：相似度量也是採用計算影象對特徵向量的歐式距離的方法，並歸一化到區間[0, 1]，作為輸出的影象對相似度。

5.4 訊息推送

訊息推送作為回放流程的最終環節，我們依賴於美團內部自建的訊息佇列服務與OA SDK訊息推送能力，可以進行測試報告的實時推送。在此之上，還可以針對不同團隊的推送訴求，做訊息模板的定製化。

• 訊息定製：訊息推送與觸達的核心，是滿足業務訴求；不同業務對自動化測試報告中各項指標的關注點不同，這就需要AlphaTest具備訊息推送定製的能力；將訊息推送的模板以配置檔案的形式提供出來，不同的業務使用不同的業務訊息配置檔案；再利用OA提供的圖文、多媒體等訊息推送能力，可以將自動化測試報告的各項指標自定義拆分；除此之外，訊息還需要減少冗餘，在這個資訊氾濫的時代，我們願意為無孔不入的訊息、通知做減法，只將最重要、最核心的訊息推送給最需要的人，既可以推動自動化測試流程的高效流轉，又可以讓各相關業務人員享受到自動化測試能力的便捷性。

• 一鍵觸達：以往的研發人員冒煙測試，主要依賴於測試人員在用例管理平臺建立測試計劃，研發人員根據用例進行手工用例測試結果標記，之後去提測完成後續流程。這中間缺失的主要環節是，難以對研發人員冒煙測試的質量進行把控。而AlphaTest正可以解決此問題，流程轉換為，研發人員在敏捷協同平臺觸發一鍵提測流程，呼叫AlphaTest的自動化測試能力對冒煙用例進行自動化測試迴歸，完成之後將測試生成的測試報告同步提測平臺，作為研發人員冒煙的結論依據，同時在冒煙過程中發生的問題，也可以及時通知到對應的研發人員與測試人員進行改正。既保證了質量，又避免了人力空耗。

6. 落地與實踐

外賣C端主要承擔了使用者在App端點餐、下單、配送的所有核心流程，場景繁多、業務複雜，這也給測試人員的版本測試帶來了諸多挑戰，其中最核心也最耗費人力的便是二輪迴歸測試環節。目前，C端採用的雙週敏捷迭代的開發方式，每個迭代週期給測試人員用來進行二輪核心流程迴歸的時間為三天，為此C端測試團隊投入了許多人力資源，但即便如此，仍難以覆蓋全部流程；而AlphaTest的設計初衷也正是為解決此問題——UI測試流程全覆蓋及自動化驗證。

6.1 業務共建

用例的轉化與維護

[1] AlphaTest 在外賣C端測試團隊的落地初期，我們採用了共建的模式，也就是業務研發人員與對應測試人員共同來進行用例錄製與維護的工作；推薦這種工作模式的核心原因是，在C端功能迭代流程中的二輪週期的原有工作模式為，研發人員進行二輪冒煙測試，完成測試之後提交二輪包交由測試人員進行二輪迴歸測試，所以這本來就是一個雙方都需要參與的環節；而二輪測試作為版本上線前的最重要一個測試流程，保證核心流程的正常也是測試人員與研發人員所關心重點。

[2] 經過多輪的使用與磨合之後，這種模式被證明是行之有效的，在整個C端二輪用例的轉化過程中，測試人員主要負責了用例的錄製與迭代流程，研發人員則主要負責版本回放資料的統計及問題用例的發現與解決。

外賣二輪落地情況

[1] 目前，AlphaTest已經在外賣多個業務落地，支援了大於15個版本的二輪迴歸測試，用例覆蓋率達到70%。

[2] 覆蓋了Native、Mach、React Native、美團小程式、H5 技術棧的測試工作，能力上可進行支援：UI自動化測試、埋點自動化測試、動態化載入成功率自動化測試、無障礙適配率自動化測試。

未來，我們會朝著“智慧化”和“精準化”兩個方向探索，覆蓋更多測試場景的同時，更進一步提升測試人效。

6.2 實踐效果

測試方向	同App回放成功率	跨App回放成功率
功能自動化	iOS:97.4%、Android: 94.7%	iOS:95.8%、Android: 91.1%
埋點自動化	iOS:96.3%、Android: 96%	iOS:95%、Android: 91%

7. 參考資料

• [1] http://appium.io
• [2] http://docs.seleniumhq.org/projects/webdriver
• [3] http://airtest.netease.com/index.html
• [4] http://github.com/alipay/SoloPi

閱讀美團技術團隊更多技術文章合集

前端 | 演算法 | 後端 | 資料 | 安全 | 運維 | iOS | Android | 測試

| 在公眾號選單欄對話方塊回覆【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可檢視美團技術團隊歷年技術文章合集。

| 本文系美團技術團隊出品，著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容，敬請註明“內容轉載自美團技術團隊”。本文未經許可，不得進行商業性轉載或者使用。任何商用行為，請傳送郵件至[email protected]申請授權。