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

• 1. 項目背景

• 2. 項目目標

• 3. 方案選型

• 4. 實踐和探索

• 4.1 問題和挑戰(zhàn)

• 4.2 前置條件準備

• 4.3 用例錄制與回放的數(shù)據(jù)一致性

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

• 4.5 可溯源的自動化測試

• 4.6 用例的維護

• 4.7 跨App回放用例

• 4.8 埋點的錄制回放

• 5. 測試流程

• 5.1 自動化任務(wù)觸發(fā)

• 5.2 回放集群調(diào)度

• 5.3 斷言服務(wù)

• 5.4 消息推送

• 6. 落地與實踐

• 6.1 業(yè)務(wù)共建

• 6.2 實踐效果

1. 項目背景

2. 項目目標

• 易用性：工具/平臺的上手難度，使用復(fù)雜度應(yīng)該盡可能的低，因為自動化測試的目的是提效人力，而不是增加人力負擔。
• 平臺支持：移動端至少需要覆蓋iOS和Android雙平臺，同時基于外賣的業(yè)務(wù)特點，不僅需要對Native支持，也需要支持Mach（自研局部動態(tài)化框架）、H5、React Native、美團小程序等技術(shù)棧。
• 穩(wěn)定性：自動化測試用例的執(zhí)行需要有足夠的穩(wěn)定性和準確性，測試過程中不應(yīng)因測試工具本身的不穩(wěn)定而出現(xiàn)穩(wěn)定性問題。
• 維護成本：維護成本很大程度上決定了測試工作量的大小，因需求產(chǎn)生變動或架構(gòu)重構(gòu)等問題時，用例的維護成本應(yīng)該盡可能的小。
• 可擴展性：當測試方案不能滿足測試需求時，工具/平臺應(yīng)具備可擴展的能力。

3. 方案選型

自動化測試工具那么多，自研是重復(fù)造輪子嗎？

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

4. 實踐和探索

4.1 問題和挑戰(zhàn)

注：這里我們將生成的自動化腳本統(tǒng)稱為指令，將平臺生成的用例統(tǒng)稱自動化用例，將錄制回放變成可視化的腳本指令，讓用例變的易懂、易維護。

4.2 前置條件準備

一鍵環(huán)境模擬，解決操作繁瑣的用例執(zhí)行前的環(huán)境準備。

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

與其它測試框架不同的是，AlphaTest采用了SDK集成，但對業(yè)務(wù)無侵入的方式，因此可以通過編寫白盒代碼來實現(xiàn)前置條件的自動配置，只需要在平臺添加需要的指令，下發(fā)到SDK后，即可根據(jù)相關(guān)指令完成前置條件的自動配置，不再需要重復(fù)進行相關(guān)的操作。并且這些前置條件支持復(fù)用，也不需要每次進行用例準備時的重復(fù)配置。AlphaTest的前置條件，不僅有著基于美團內(nèi)部服務(wù)及底層Hook的默認實現(xiàn)，也提供了API支持業(yè)務(wù)方自定義實現(xiàn)，比如實現(xiàn)不同的賬號體系。

4.3 用例錄制與回放的數(shù)據(jù)一致性

影響用例執(zhí)行的不僅是代碼，還有數(shù)據(jù)。

很多時候，自動化用例無法正常執(zhí)行完成，可能是因為App回放時的本地數(shù)據(jù)及網(wǎng)絡(luò)數(shù)據(jù)與錄制時的不一致，從而導(dǎo)致用例執(zhí)行流程的阻塞或App界面展示的不同。這也是大多數(shù)自動化測試工具/平臺測試通過率不高的主要因素，因此要保證測試成功率，我們需要控制變量，排除由數(shù)據(jù)產(chǎn)生的影響。

App運行依賴的數(shù)據(jù)，有兩部分——本地數(shù)據(jù)和網(wǎng)絡(luò)數(shù)據(jù)：

• 本地數(shù)據(jù)是App在運行期間產(chǎn)生的緩存數(shù)據(jù)或持久化的存儲數(shù)據(jù)。為了讓用例在錄制回放時都能夠保持一致的本地數(shù)據(jù)環(huán)境，我們在錄制和回放前都對App的本地數(shù)據(jù)進行了清理操作，這樣用例在錄制和回放的過程中，都可以保持一致的App初始化環(huán)境。
• 網(wǎng)絡(luò)數(shù)據(jù)是驅(qū)動App交互呈現(xiàn)的基石，各種策略和API升級都會影響網(wǎng)絡(luò)數(shù)據(jù)的響應(yīng)，因此我們將用例錄制過程中產(chǎn)生的網(wǎng)絡(luò)數(shù)據(jù)也進行了錄制，并將網(wǎng)絡(luò)數(shù)據(jù)和對應(yīng)的操作指令進行了關(guān)聯(lián)和綁定，確定了數(shù)據(jù)產(chǎn)生的事件源。排除數(shù)據(jù)影響后，我們的自動化測試的成功率就取決于自動化操作的準確性了，這就回到了常見自動化框架范疇。

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

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

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

• 目標控件定位準確性：

操作行為是否一致首先需要確認操作目標是否一致。與一般測試工具/平臺不同的是AlphaTest采用了ViewPath + 圖像 + 坐標的多重定位方案。得益于SDK集成的方式，我們的ViewPath可以記錄更多的元素視圖特征和執(zhí)行不同的匹配策略。定位過程中會優(yōu)先使用ViewPath進行目標控件檢索，當目標控件查找異常時，會結(jié)合圖像匹配和坐標匹配的方式進行兜底查找，來確保界面變化程度不大時，也能準確的查找到目標控件。

• 手勢定位的精準性：

有了基于控件的目標定位之后，對于一些常用簡單操作手勢，比如點擊、長按、斷言、甚至輸入都可以做到很好的支持，只需要找到對應(yīng)的控件，在控件所在位置下發(fā)相應(yīng)的觸摸事件即可。我們知道，App真正接收的觸摸事件是屏幕上一個個精準的觸摸點，在系統(tǒng)處理后，分發(fā)給當前App窗口，App在接收事件后再繼續(xù)分發(fā)，直到找到事件的最佳響應(yīng)者，后續(xù)通過響應(yīng)者鏈對事件消化處理。那我們要還原一個觸摸事件的坐標點要如何確定呢？由于我們確定的只有控件，所以這個點自然而然就成了控件的中心點了。

大多數(shù)情況下，這些都可以很好地進行工作，但是對于一些多響應(yīng)控件重疊的情況，可能會產(chǎn)生預(yù)想不到的操作誤差。為了解決這樣的問題，我們把控件定位與坐標定位進行了結(jié)合：基于純坐標的定位是一種定位精準度非常高的定位方式，但是穩(wěn)定性非常差，只有在屏幕分辨率完全一致且回放頁面控件位置完全一致的情況下，才具備足夠的可靠性，但這往往是不現(xiàn)實的，對測試環(huán)境機器量要求過高。

基于控件的定位，又存在著精準度不夠的問題。使用坐標定位，如果定位區(qū)域足夠小的話，那么受屏幕尺寸的影響就會越小，只需要確定在小范圍內(nèi)的相對位置即可。而基于控件目標的定位，恰恰可以把目標區(qū)域縮小到一個指定區(qū)域，我們剛好可以將二者結(jié)合起來，同時解決定位精準度和穩(wěn)定性的問題。

對于復(fù)雜手勢的支持，我們同樣可以采用微分的方式，將一個復(fù)雜手勢拆成多個簡單手勢的組成，比如我們可以將一個滑動操作的定位拆成兩個部分：起始位置和終止位置，而這兩個位置的定位，就變成了兩個普通的單點手勢操作定位了，可以通過上面提到的一個目標控件+相對坐標的形式進行定位。核心思想都是將基于屏幕坐標點的定位操作，縮小的目標控件的區(qū)域范圍內(nèi)，以達到不受設(shè)備分辨率的影響，實現(xiàn)操作行為一致的效果。

4.5 可溯源的自動化測試

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

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

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

4.6 用例的維護

自動化用例需要持續(xù)地投入人力來維護么？架構(gòu)升級，頁面重構(gòu)，用例需要全部重新錄制么？

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

• 需求發(fā)生重大變更，整體的業(yè)務(wù)執(zhí)行流程及相關(guān)的校驗點都需要進行大量的調(diào)整。對于這種情況，無論是何種自動化測試工具/平臺，都是需要正常進行用例變更重錄以適應(yīng)新的需求。
• 需求發(fā)生略微變更，業(yè)務(wù)流程基本一致，需要調(diào)整的校驗點、操作以及數(shù)據(jù)或不影響整體流程的步驟。對于此場景，AlphaTest通過指令編輯器與操作錄制，支持指令增刪改以及數(shù)據(jù)和場景的還原，幫助用戶快速的進行用例調(diào)整，而無需重新錄制用例。例如：修改網(wǎng)絡(luò)數(shù)據(jù)字段、視圖變更路徑、斷言替換目標等。

• 和業(yè)務(wù)需求不同，我們的技術(shù)實現(xiàn)也會發(fā)生迭代。隨著App技術(shù)架構(gòu)不斷的演進，經(jīng)常會面臨著架構(gòu)升級，頁面重構(gòu)甚至技術(shù)棧變遷等這樣的技術(shù)升級。這些變動需要覆蓋大量的測試用例，其中大量的自動化用例又可能會因為變動而導(dǎo)致失效，需要重新錄制。為此，AlphaTest設(shè)計一套利用相近分辨率機器進行用例自動修正的功能：利用圖像 + 坐標進行二次識別定位，元素定位成功并校驗通過后，生成新的ViewPath，更新對應(yīng)的用例指令，對用例進行自動修復(fù)，修復(fù)后可在任意回放。

4.7 跨App回放用例

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

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

• 前置條件和初始頁面：業(yè)務(wù)的初始頁面進入路徑不同，例如外賣App打開App就進入到了外賣首頁，但是在美團App中就需要從美團首頁跳轉(zhuǎn)到外賣頻道。同時由于不同App的樣式風(fēng)格、設(shè)計規(guī)范、業(yè)務(wù)特性等因素，也會造成首頁代碼邏輯和視圖層級的差異。
• AB實驗配置：不同App所配置的實驗可能不同，不同的實驗會導(dǎo)致不同的樣式和代碼邏輯。
• 網(wǎng)路接口映射：不同App中相同業(yè)務(wù)場景涉及的接口有所不同。
• 頁面Scheme映射：不同App中相同頁面的跳轉(zhuǎn)Scheme也不相同。

AlphaTest平臺支持App維度各項差異數(shù)據(jù)配置，當SDK檢測用例回放環(huán)境與錄制環(huán)境不一致時，會自動進行映射適配，從而讓用例運行到了不同App上。

4.8 埋點的錄制回放

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

• 字段規(guī)則配置：埋點自定義參數(shù)千姿百態(tài)，甚至有些字段每次代碼執(zhí)行都不一致，如果進行完全匹配結(jié)果注定是失敗的，所以我們在AlphaTest平臺提供了埋點字段規(guī)則配置功能，通過人為設(shè)置的方式來避免埋點自定義參數(shù)校驗失敗。App重啟進入錄制狀態(tài)時，用戶就可以操作App，平臺會記錄用戶的操作行為，當產(chǎn)生相應(yīng)的埋點日志的時候會將日志信息打印在日志區(qū)域（如下圖17所示），在該過程中也會對埋點日志進行一定的校驗。重點將操作時機、埋點日志一并保存到服務(wù)端。

• 埋點時機校驗：針對時機校驗，程序并不支持埋點曝光的"1px曝光"，"下拉刷新曝光"，"頁面切換曝光"，"切前后臺曝光"這些規(guī)則，主要的原因是每一個業(yè)務(wù)方在對埋點曝光的規(guī)則都是不一致的，而且該規(guī)則的實現(xiàn)會極大耦合業(yè)務(wù)代碼。在針對時機校驗我們目前只支持：

  [1] 點擊埋點上報時機校驗，程序通過事件監(jiān)聽和埋點類型信息來判斷點擊埋點上報的時機是否是在點擊的操作下產(chǎn)生的，如果不是則報錯。

  [2] 埋點重復(fù)上報校驗，針對一般情況下用戶一次操作不會產(chǎn)生兩個相同的埋點上報，所以程序會校驗?zāi)硞€事件下發(fā)生的所有埋點日志進行一一校驗，檢測是否具有2個或多個埋點日志完全一致，如有發(fā)生則會上報錯誤。

• 結(jié)果校驗：回放完成后，我們會對比錄制和回放時的埋點數(shù)據(jù)，根據(jù)配置好的字段規(guī)則校驗埋點上報是否符合預(yù)期。

5. 測試流程

AlphaTest的核心測試流程始終聚焦在用例的錄制與回放環(huán)節(jié)，整個流程涉及到自動化任務(wù)觸發(fā)、回放集群調(diào)度、斷言服務(wù)、消息推送等核心模塊。

以UI自動化和埋點自動化的流程為例，AlphaTest以業(yè)務(wù)團隊為基本單元，可以和各團隊的測試用例進行關(guān)聯(lián)，定時同步狀態(tài)。同時利用需求評審線上化做為基礎(chǔ)，將自動化用例和研發(fā)流程中的PR、集成打包、二輪回歸等節(jié)點相結(jié)合，定時觸發(fā)自動化用例并將結(jié)果報告推送給相關(guān)負責(zé)人。

• 錄制用例：

  [1] 首先在AlphaTest平臺選擇要錄制的測試用例，打開待測試App進行掃碼即可進入用例待錄制狀態(tài)，此時可以設(shè)置用例需要的前置條件（賬號信息、Mock數(shù)據(jù)、定位信息等），之后點擊開始按鈕后，手機便會自動重啟，開始錄制。

  [2] 用戶按照測試用例步驟，正常操作手機，AlphaTest會將用戶的操作行為全部記錄下來，并自動生成語義化的描述語言顯示在AlphaTest平臺上，與此同時產(chǎn)生的網(wǎng)絡(luò)數(shù)據(jù)、埋點數(shù)據(jù)等校驗信息也會一并存儲下來。

  [3] 在錄制的過程中可以快捷的打開斷言模式，將頁面上想要校驗的元素進行文本提取/截圖等操作記錄下來，用于后續(xù)回放過程中對相同元素進行校驗。

  [4] 測試步驟全都執(zhí)行完畢后，點擊保存按鈕即可生成本條自動化用例。

• 用例回放：

  [1] 掃描對應(yīng)自動化用例的二維碼即可進行回放，回放過程中會將用戶錄制的行為、網(wǎng)絡(luò)數(shù)據(jù)進行一比一還原，并且輔助有全過程視頻錄像，用于后續(xù)問題排查和溯源。

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

  [3] 回放過程中的埋點數(shù)據(jù)也會一并記錄下來，并和錄制時候的埋點數(shù)據(jù)和上報時機進行對比，自動提取出其中的差異項。

  [4] 回放完成后，會生成完整的測試報告并將結(jié)果通過OA推送至相關(guān)人員。

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

5.1 自動化任務(wù)觸發(fā)

在整個外賣C端敏捷迭代的流程中，打包平臺主要承接了業(yè)務(wù)需求發(fā)起到需求交付的流程，作為AlphaTest的上游平臺，可以提供打包信息并觸發(fā)自動化用例回放任務(wù)。以下簡單展示AlphaTest與敏捷協(xié)同平臺的交互流程：

5.2 回放集群調(diào)度

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

• 執(zhí)行流程：回放任務(wù)通過用戶在平臺手動觸發(fā)或者二輪自動觸發(fā)。新增的回放任務(wù)經(jīng)過任務(wù)拆分系統(tǒng)拆分成n個子任務(wù)，加入到不同設(shè)備的回放任務(wù)隊列中。每個子任務(wù)經(jīng)過占用設(shè)備->安裝待測App->應(yīng)用授權(quán)->打開scheme->上報結(jié)果等步驟完成回放操作。
• 節(jié)點保活機制：針對回放流程中每一個節(jié)點，失敗后進行N（默認為3）次重試操作。減少因網(wǎng)絡(luò)波動，接口偶現(xiàn)異常導(dǎo)致的回放失敗數(shù)量。
• 子任務(wù)保活機制：每個回放流程，失敗后進行N（默認為3）次斷點重試。減少因設(shè)備異常，SDK心跳上報異常導(dǎo)致的回放失敗數(shù)量。
• 父任務(wù)保活機制：一個父任務(wù)會被拆分成N個子任務(wù)，當其中的一個子任務(wù)S1在節(jié)點保活機制和子任務(wù)保活機制下仍然執(zhí)行失敗之后，父任務(wù)保活機制會嘗試將子任務(wù)S1中未執(zhí)行完畢的用例轉(zhuǎn)移到其他活躍狀態(tài)的子任務(wù)中。減少因設(shè)備異常，設(shè)備掉線等問題導(dǎo)致的回放失敗數(shù)量。

5.3 斷言服務(wù)

用例斷言是整個自動化用例驗證的核心步驟，我們的斷言服務(wù)依據(jù)用例的實際情形可以分別進行文字與圖像的斷言。其中圖像斷言服務(wù)依托于自建的圖像對比算法服務(wù)，可以高效進行錄制回放斷言圖像的對比，圖像對比準確率可以達到99%以上。

• 錄制階段：

  [1] 錄制時增加斷言決策信息的自動采集。

  [2] 和正常流程一樣，提取區(qū)域的截圖信息。

  [3] 如果是文本組件，則提取文本內(nèi)容，如果是圖片組件，則提取圖片二進制編碼或圖片URL，同時提取區(qū)域內(nèi)的布局信息。

• 回放階段：

  [1] 回放時，提取和錄制時一致的內(nèi)容（文本信息、圖片編碼、區(qū)域截圖、布局信息）。

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

  [3] AlphaTest平臺對斷言結(jié)果進行校驗，首先是基于模型的圖像對比，如果判定為一致，則直接標記結(jié)果。

  [4] 如果判定為不一致、則匹配“斷言失敗數(shù)據(jù)集”，如果能夠匹配上，則標記結(jié)果。如果匹配不上，則需要人工選擇匹配類型。

  [5] 匹配類型為“文本校驗”、“根據(jù)圖片信息校驗”、“人工校驗”。如果前兩項判定為一致，則直接標記結(jié)果。如果“人工校驗”的結(jié)果為確實兩張圖不一致，則直接標記結(jié)果，結(jié)束。

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

  [7] 模型自動訓(xùn)練，當數(shù)據(jù)集超過一定的閾值、通過定時觸發(fā)、或者手動觸發(fā)的方式，觸發(fā)模型自動訓(xùn)練，訓(xùn)練完成后自動部署到AlphaTest平臺，不斷迭代。

• 圖像服務(wù)：圖像對比模型采用基于度量學(xué)習(xí)的對比算法，將圖像對的一致性判別轉(zhuǎn)換為圖像語義的相似度量問題。度量學(xué)習(xí)（Metric Learning），也稱距離度量學(xué)習(xí)（Distance Metric Learning，DML）屬于機器學(xué)習(xí)的一種。其本質(zhì)就是相似度的學(xué)習(xí)，也可以認為距離學(xué)習(xí)。因為在一定條件下，相似度和距離可以相互轉(zhuǎn)換。比如在空間坐標的兩條向量，既可以用余弦相似度的大小，也可以使用歐式距離的遠近來衡量相似程度。度量學(xué)習(xí)的網(wǎng)絡(luò)采用經(jīng)典的Siamese結(jié)構(gòu)，使用基于resnext50的主干網(wǎng)絡(luò)提取圖像的高級語義特征，后接spplayer完成多尺度特征融合，融合后的特征輸出作為表達圖像語義的特征向量，使用ContrastiveLoss進行度量學(xué)習(xí)。

[1] 預(yù)訓(xùn)練過程：resnext50網(wǎng)絡(luò)是使用ImageNet的預(yù)訓(xùn)練模型。

[2] 數(shù)據(jù)增強：為增加數(shù)據(jù)的豐富性、提高網(wǎng)絡(luò)的泛化性能，數(shù)據(jù)增強的方式主要包括：圖像右下部分的隨機剪切和添加黑色蒙層（相應(yīng)改變圖像對的標簽）。這種數(shù)據(jù)增強符合控鍵截圖實際情況，不會造成數(shù)據(jù)分布的改變。

[3] 對比損失：對比損失函數(shù)采用ContrastiveLoss，它是一種在歐式空間的pair based loss，其作用是減少一致圖像對距離，保證不一致圖像對的距離大于margin，其中margin=2。

[4] 相似度量：相似度量也是采用計算圖像對特征向量的歐式距離的方法，并歸一化到區(qū)間[0, 1]，作為輸出的圖像對相似度。

5.4 消息推送

消息推送作為回放流程的最終環(huán)節(jié)，我們依賴于美團內(nèi)部自建的消息隊列服務(wù)與OA SDK消息推送能力，可以進行測試報告的實時推送。在此之上，還可以針對不同團隊的推送訴求，做消息模板的定制化。

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

• 一鍵觸達：以往的研發(fā)人員冒煙測試，主要依賴于測試人員在用例管理平臺建立測試計劃，研發(fā)人員根據(jù)用例進行手工用例測試結(jié)果標記，之后去提測完成后續(xù)流程。這中間缺失的主要環(huán)節(jié)是，難以對研發(fā)人員冒煙測試的質(zhì)量進行把控。而AlphaTest正可以解決此問題，流程轉(zhuǎn)換為，研發(fā)人員在敏捷協(xié)同平臺觸發(fā)一鍵提測流程，調(diào)用AlphaTest的自動化測試能力對冒煙用例進行自動化測試回歸，完成之后將測試生成的測試報告同步提測平臺，作為研發(fā)人員冒煙的結(jié)論依據(jù)，同時在冒煙過程中發(fā)生的問題，也可以及時通知到對應(yīng)的研發(fā)人員與測試人員進行改正。既保證了質(zhì)量，又避免了人力空耗。

6. 落地與實踐

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

6.1 業(yè)務(wù)共建

用例的轉(zhuǎn)化與維護

AlphaTest 在外賣C端測試團隊的落地初期，我們采用了共建的模式，也就是業(yè)務(wù)研發(fā)人員與對應(yīng)測試人員共同來進行用例錄制與維護的工作；推薦這種工作模式的核心原因是，在C端功能迭代流程中的二輪周期的原有工作模式為，研發(fā)人員進行二輪冒煙測試，完成測試之后提交二輪包交由測試人員進行二輪回歸測試，所以這本來就是一個雙方都需要參與的環(huán)節(jié)；而二輪測試作為版本上線前的最重要一個測試流程，保證核心流程的正常也是測試人員與研發(fā)人員所關(guān)心重點。

經(jīng)過多輪的使用與磨合之后，這種模式被證明是行之有效的，在整個C端二輪用例的轉(zhuǎn)化過程中，測試人員主要負責(zé)了用例的錄制與迭代流程，研發(fā)人員則主要負責(zé)版本回放數(shù)據(jù)的統(tǒng)計及問題用例的發(fā)現(xiàn)與解決。

外賣二輪落地情況

目前，AlphaTest已經(jīng)在外賣多個業(yè)務(wù)落地，支持了大于15個版本的二輪回歸測試，用例覆蓋率達到70%。現(xiàn)已覆蓋了Native、Mach、React Native、美團小程序、H5 技術(shù)棧的測試工作，能力上可進行支持：UI自動化測試、埋點自動化測試、動態(tài)化加載成功率自動化測試、無障礙適配率自動化測試。

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

6.2 實踐效果

7. 參考資料

推薦閱讀：
世界的真實格局分析，地球人類社會底層運行原理
不是你需要中臺，而是一名合格的架構(gòu)師（附各大廠中臺建設(shè)PPT）
企業(yè)IT技術(shù)架構(gòu)規(guī)劃方案
論數(shù)字化轉(zhuǎn)型——轉(zhuǎn)什么，如何轉(zhuǎn)？
華為干部與人才發(fā)展手冊（附PPT）
企業(yè)10大管理流程圖，數(shù)字化轉(zhuǎn)型從業(yè)者必備！
【中臺實踐】華為大數(shù)據(jù)中臺架構(gòu)分享.pdf
華為的數(shù)字化轉(zhuǎn)型方法論
華為如何實施數(shù)字化轉(zhuǎn)型（附PPT）
超詳細280頁Docker實戰(zhàn)文檔！開放下載
華為大數(shù)據(jù)解決方案（PPT）