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

語言: CN / TW / HK

總第535 篇 |  2022年 第052篇

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

  • 1. 項目背景

  • 2. 項目目標

  • 3. 方案選型

  • 4. 實踐和探索

    • 4.1 問題和挑戰

    • 4.2 前置條件準備

    • 4.3 用例錄製與回放的數據一致性

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

    • 4.5 可溯源的自動化測試

    • 4.6 用例的維護

    • 4.7 跨App回放用例

    • 4.8 埋點的錄製回放

  • 5. 測試流程

    • 5.1 自動化任務觸發

    • 5.2 回放集羣調度

    • 5.3 斷言服務

    • 5.4 消息推送

  • 6. 落地與實踐

    • 6.1 業務共建

    • 6.2 實踐效果

1. 項目背景

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

圖1 多業務、多技術棧、多App

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

圖2 外賣迭代模型

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

圖3 近幾年用例增長變化

2. 項目目標

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

  • 易用性 :工具/平台的上手難度,使用複雜度應該儘可能的低,因為自動化測試的目的是提效人力,而不是增加人力負擔。

  • 平台支持 :移動端至少需要覆蓋iOS和Android雙平台,同時基於外賣的業務特點,不僅需要對Native支持,也需要支持Mach( 自研局部動態化框架 )、H5、React Native、美團小程序等技術棧。

  • 穩定性 :自動化測試用例的執行需要有足夠的穩定性和準確性,測試過程中不應因測試工具本身的不穩定而出現穩定性問題。

  • 維護成本 :維護成本很大程度上決定了測試工作量的大小,因需求產生變動或架構重構等問題時,用例的維護成本應該儘可能的小。

  • 可擴展性 :當測試方案不能滿足測試需求時,工具/平台應具備可擴展的能力。

3. 方案選型

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

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

  • 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 指令編輯器
圖5 手機錄製演示

圖6 平台遠端錄製演示

4.2 前置條件準備

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

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

圖7 前置條件

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

4.3 用例錄製與回放的數據一致性

影響用例執行的不僅是代碼,還有數據。

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

圖8 數據一致性

App運行依賴的數據,有兩部分——本地數據和網絡數據:

  • 本地數據是App在運行期間產生的緩存數據或持久化的存儲數據。為了讓用例在錄製回放時都能夠保持一致的本地數據環境,我們在錄製和回放前都對App的本地數據進行了清理操作,這樣用例在錄製和回放的過程中,都可以保持一致的App初始化環境。

  • 網絡數據是驅動App交互呈現的基石,各種策略和API升級都會影響網絡數據的響應,因此我們將用例錄製過程中產生的網絡數據也進行了錄製,並將網絡數據和對應的操作指令進行了關聯和綁定,確定了數據產生的事件源。排除數據影響後,我們的自動化測試的成功率就取決於自動化操作的準確性了,這就回到了常見自動化框架範疇。

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

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

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

  • 目標控件定位準確性:

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

圖9 圖像識別示意圖
  • 手勢定位的精準性:

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

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

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

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

圖10 手勢識別示意圖

4.5 可溯源的自動化測試

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

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

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

圖11 回放報告-圖文詳情

4.6 用例的維護

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

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

  • 需求發生重大變更,整體的業務執行流程及相關的校驗點都需要進行大量的調整。對於這種情況,無論是何種自動化測試工具/平台,都是需要正常進行用例變更重錄以適應新的需求。

  • 需求發生略微變更,業務流程基本一致,需要調整的校驗點、操作以及數據或不影響整體流程的步驟。對於此場景,AlphaTest通過指令編輯器與操作錄製,支持指令增刪改以及數據和場景的還原,幫助用户快速的進行用例調整,而無需重新錄製用例。例如:修改網絡數據字段、視圖變更路徑、斷言替換目標等。

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

圖15 自修復能力

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 埋點的錄製回放

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

圖16 埋點自動化測試示意圖
  • 字段規則配置 :埋點自定義參數千姿百態,甚至有些字段每次代碼執行都不一致,如果進行完全匹配結果註定是失敗的,所以我們在AlphaTest平台提供了埋點字段規則配置功能,通過人為設置的方式來避免埋點自定義參數校驗失敗。App重啟進入錄製狀態時,用户就可以操作App,平台會記錄用户的操作行為,當產生相應的埋點日誌的時候會將日誌信息打印在日誌區域( 如下圖17所示 ),在該過程中也會對埋點日誌進行一定的校驗。重點將操作時機、埋點日誌一併保存到服務端。

圖17 埋點上報數據控制枱打印
  • 埋點時機校驗:針對時機校驗,程序並不支持埋點曝光的"1px曝光","下拉刷新曝光","頁面切換曝光","切前後台曝光"這些規則,主要的原因是每一個業務方在對埋點曝光的規則都是不一致的,而且該規則的實現會極大耦合業務代碼。在針對時機校驗我們目前只支持:

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

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

  • 結果校驗 :回放完成後,我們會對比錄製和回放時的埋點數據,根據配置好的字段規則校驗埋點上報是否符合預期。

圖18 埋點校驗流程圖

5. 測試流程

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

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

圖19 建設自動化測試流程閉環
  • 錄製用例:

    [1] 首先在AlphaTest平台選擇要錄製的測試用例,打開待測試App進行掃碼即可進入用例待錄製狀態,此時可以設置用例需要的前置條件( 賬號信息、Mock數據、定位信息等 ),之後點擊開始按鈕後,手機便會自動重啟,開始錄製。

    [2] 用户按照測試用例步驟,正常操作手機,AlphaTest會將用户的操作行為全部記錄下來,並自動生成語義化的描述語言顯示在AlphaTest平台上,與此同時產生的網絡數據、埋點數據等校驗信息也會一併存儲下來。

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

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

  • 用例回放:

    [1] 掃描對應自動化用例的二維碼即可進行回放,回放過程中會將用户錄製的行為、網絡數據進行一比一還原,並且輔助有全過程視頻錄像,用於後續問題排查和溯源。

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

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

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

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

5.1 自動化任務觸發

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

圖20 AlphaTest與敏捷協同平台交互流程圖

5.2 回放集羣調度

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

  • 執行流程 :回放任務通過用户在平台手動觸發或者二輪自動觸發。新增的回放任務經過任務拆分系統拆分成n個子任務,加入到不同設備的回放任務隊列中。每個子任務經過佔用設備->安裝待測App->應用授權->打開scheme->上報結果等步驟完成回放操作。

  • 節點保活機制 :針對回放流程中每一個節點,失敗後進行N( 默認為3 )次重試操作。減少因網絡波動,接口偶現異常導致的回放失敗數量。

  • 子任務保活機制 :每個回放流程,失敗後進行N( 默認為3 )次斷點重試。減少因設備異常,SDK心跳上報異常導致的回放失敗數量。

  • 父任務保活機制 :一個父任務會被拆分成N個子任務,當其中的一個子任務S1在節點保活機制和子任務保活機制下仍然執行失敗之後,父任務保活機制會嘗試將子任務S1中未執行完畢的用例轉移到其他活躍狀態的子任務中。減少因設備異常,設備掉線等問題導致的回放失敗數量。

圖21 機器集羣

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進行度量學習。

圖22 訓練過程

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

[2] 數據增強 :為增加數據的豐富性、提高網絡的泛化性能,數據增強的方式主要包括:圖像右下部分的隨機剪切和添加黑色蒙層( 相應改變圖像對的標籤 )。這種數據增強符合控鍵截圖實際情況,不會造成數據分佈的改變。

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

圖23 訓練過程

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

5.4 消息推送

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

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

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

6. 落地與實踐

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

6.1 業務共建

用例的轉化與維護

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

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

外賣二輪落地情況

目前,AlphaTest已經在外賣多個業務落地,支持了大於15個版本的二輪迴歸測試,用例覆蓋率達到70%。現已 覆蓋了Native、Mach、React Native、美團小程序、H5 技術棧的測試工作,能力上可進行支持: UI自動化測試、埋點自動化測試、動態化加載成功率自動化測試、無障礙適配率自動化測試。

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

6.2 實踐效果

7. 參考資料

[1] https://appium.io

[2] http://docs.seleniumhq.org/projects/webdriver

[3] http://airtest.netease.com/index.html

[4] https://github.com/alipay/SoloPi

----------  END  ----------

也許你還想看

  |  Spock單元測試框架以及在美團優選的實踐

  | 美團智能支付穩定性測試實戰

  | Lego:美團接口自動化測試實踐

閲讀更多

前端  |     算法  |   後端  |  數據

安全  |  Android  |   iOS    |   運維  |  測試