2019年10月26日，由Testin主辦的第二屆NCTS中國云測試行業峰會在京召開，此次峰會以“AI+未來”為主題，匯聚來自國內外測試領域的知名專家學者、領先企業決策者、高層技術管理者、媒體從業者等，共同探討高端云測試技術，幫助測試從業者了解最前沿行業趨勢，及最新的行業實踐。

[[284797]]

會上，阿里巴巴技術專家羽瑤做《基于圖像智能算法的端上h5頁面測試提效輕量化解決方案》的內容分享。羽瑤指出，“自動化能力多多少少都有穩定性的問題，我們非常注重算法能力，正在探索基于圖像算法能不能真實檢測頁面的問題。”

以下為羽瑤演講實錄：

大家好我是來自阿里巴巴的羽瑤，我們組主要負責集團的平臺化產品來服務業務測試。這是我演講的目錄結構，我首先介紹一下這個方案的背景，我們有一個業務團隊負責所有淘系級A+級大促，每次大促頁面非常多，比如19年1到9月總A+級大促59個，A+以上就是S級，比如雙十一這種活動。大促活動非常多，我們前端開發和技術做了很多動態化配置方案來方便頁面及時發布，就是每次大促活動的每一個會場，會場的發布顯示時間，要加載的數據都可以動態配置，然后大促活動當中可能運營會及時調整策略，可能就有一些樓層下掉，或者運營不同配置不同算法，個性化策略來把不同的商品突出出來，包括模塊的配置化，它的頁面結構在整個上線階段會不停的變化。

伴隨著這些問題我們測試時間非常短，比如“99大促”時第一輪預演，就是指整個頁面的數據搭建都完成，有一個比較完整的頁面效果開始，然后到真正的上線可能“99”時候中間就只有4個工作日的時間，因為這些問題，所以我們有一些頁面是測試從來不去介入過程當中的，有一些有問題頁面會泄露到線上用戶看到的頁面中，這塊是缺乏監控的，因為我們所有動態化的配置是沒有實現，測試沒有精力兼顧每次改動和變動，我們業務團隊幫助他們不停的探索有什么自動化方案可以覆蓋這些問題。

介紹一下現在會場的保障方案有哪些，一是數據源管控，商家每次上傳商品，上傳圖片，編輯商品的信息，可能就是在上傳的當時或者N+1時間對這層數據做算法檢測和過濾，以及一些清退。另外上線過程當中會做一些數據監控方案，應對這些算法調整帶來的問題。

測試階段就是一個新頁面剛來的時候，或者有一個新模塊新上線的時候，有大量外包適配投入，業務方全民預演，因為每次新搭建，運營和產品很關心頁面是否正常，這時候我們可能會組織一輪產品、運營、技術、測試把大家都拉過來一起看頁面有沒有問題，這兩塊其實都是純人力的投入。

一部分不太重要的大促活動可能就是運營自己看一下沒有問題，就是這種技術或者有沒有問題大家自測去保證的。

其實這都是在端上看到的，我們介紹一下現在集團在端上自動化有哪些方案，大概來說其實每一個BU每一個團隊有自己的一套，大體分成三類，一類是基于Appium/Uiautomator，基于開源的框架基礎能力，自己搭建持續集成的平臺，自己跟自己發布系統對接寫腳本，純寫腳本的這種。

另外一種是應用侵入型，以伽利略為代表，開發端上SDK，相當于自己調用自己的能力做腳本驅動，可能搭載自己守護的APP進程跟后臺做一些設備驅動。

現在這一兩年比較火的是天畫的產品，做了模塊級的和數據級驅動，這個模塊只是一個頁面來了以后自己可以寫腳本，底層是基于這個自動化框架能力，一個頁面來了可以定義頁面做哪些模塊切分，哪些模塊有一些ID是固定的可以寫每一個頁面，某一個模塊的某一個控件，這個方案是為了應對框架級變動導致自動化運行的失敗，同時結合我們集團線上流量的抓取，DOOM（采集線上機器的流量，對beta測試機器進行流量回放并對比）的平臺能力，根據運行數據生成頁面的能力，做數據驅動型的運行。

但是這三種可能都有問題，就是需要去寫腳本人工寫腳本，伽利略（使用很多內外部底層hack技術，自有守護進程，設備管理維護，嵌入待測試APP）可能自己定制APP，同時運行來講，穩定性都是會有問題的，動化能力多多少少都有穩定性的問題，我們非常注重算法能力，正在探索基于圖像算法能不能真實檢測頁面的問題。

下面介紹一下我們的方案，我們的方案跟這個都不太相同，因為他們可能要解決端上h5，所有的Native級別比較多，我們解決的是會場級，是以h5為主。這個是圖像算法、便捷、輕量化、貼合不同業務方不同業務場景，比如我們有業務方卡發布，他們必須靠一遍我們應用，確認沒有問題才可以發布，另外還有不同業務方也時間穿越的方案，就是指你頁面沒有上線階段，外面看不到的時候我們可以調整底層系統級時間，讓頁面提前進入雙十一狀態場景當中，會做這些打通再調系統運行來做提前驗證和檢測。

為了讓大家更有體會，看一下我們的方案運行，這是最簡單的場景例子，可以整體看清楚整體怎么串的，我們手機在任何一個端環境下可以掃描這個二維碼進入我們的中間頁，中間頁以后就不停去做任務輪巡，掃了以后，任何機器上傳到我們平臺，可以作為實時運行的手機環境，我們在這里新建任務，然后這是單頁面檢測場景，現在主要是用在線上頁面巡檢和檢測當中。選擇我們剛才的機器，這后面的場景，我們還有一些算法的定制，行動點定制和應對，錄制、回放或者應對復雜頁面交互場景的需求，新建完成以后后面有端定制的，創建完成以后機器就會在這里跑起來，跑的每一步會做截圖，然后截圖上傳到后臺以后，后臺算法就會確實是檢測有沒有什么問題。

這些算法目前來說可能檢測一些空樓層，空樓掉坑，異常詞之類的，這個跑完以后后臺可以實時看到當前頁面效果。這左邊是我們每一步截圖信息，右邊是拼接好的長圖，這個頁面是沒有問題的，在頁面有問題的時候，那邊有錯誤信息的出現，大家可以點擊不同的信息到具體的錯誤頁面。然后這個頁面是在A客戶端上跑的，速賣通的，跑完以后跟系統對接的，他們跑完跳到我們這里看具體錯誤信息。

看一下我們的方案怎么做的，我們核心就是手機打開中間鍵做任務下發，下發的時候其實輸入只是輸入頁面URL，輸入URL以后我們對這個URL拼接系統運行的參數，比如ID，任務類型，重要的是我們拼接了我們自己的一個腳本，就是紅色的腳本，拼接完這個腳本以后我們就會落庫，當時我們新建任務是針對不同機型的，跑完以后就會，機器只要在中間頁輪訓有任務執行的話，他就拿到任務開始執行。拿到任務我們腳本插入原生頁面當中，我們原來基于頁面本身有模塊可以讀取URL腳本做插入，后面我們直接做天貓端上的，在頁面漏以后會檢測有沒有符合條件的特殊參數，有沒有符合安全限制的一個域名環境，一個腳本插入到頁面當中。

剛剛演示的場景就是一種半自動調度為主的方案，那種方案可能有穩定性問題，比如說頁面跳轉到了異常的錯誤頁面，那個頁面不知道會跳到那里，或者異常場景導致APP關了的話，自動化方案就停掉設備離線，我們后面加入自動調度，就是真機操控能力方便讓它再回到中間頁。

因為我們有這個能力，支持三種任務類型，一種是錄制型任務，我們早期開人工錄制口子，就是人工去在平臺上新建任務后做操作，操作的每一步都會實時上傳到平臺上，當運行任務完成后可以確認這一次的任務做錄制，剛剛演示的一種場景就是自動化錄制場景，是純算法，純后臺驅動的去做哪些行為和操作的，回放型任務是指模塊級更改上線，頁面級適配場景的，我們針對某一個錄制型任務在其他機型做回放，這個回放和自動化原理不一樣的是，以前寫腳本大家可能是在其他的機型找某一個iOS或者PaaS是否有這個，然后再做回訪和點擊，我們基于前端開發需要實現自適應的方案，自適應方案指UAD設計375的視覺圖，聯想情況下應該是實現不同尺寸上是等比放大的關系，我們基于這個原理回放時候會做不同尺寸信息換算做運行、點擊和查找。如果我們點擊某一個位置的話失敗了，這個時候對比就有問題了，兩種圖可能出現差異，我們就會認為它的自適應或者是其它頁面是有Bug的。

我們單頁面場景就是剛剛視頻演示的簡單場景，也是那種場景純算法的，就是做驅動和單步問題檢測，然后單步就是做滾動操作和最后做全圖拼接。

我們方案的一些細節，剛剛看到我們所有的整個驅動過程其實就是插入頁面當中的腳本和后臺交互的，我們腳本是怎么做到可以監控它的行為，怎么做到操縱點擊呢？其實是結合了很多庫的能力，就是去檢測手機上的一些TUCH事件，檢測行為做人工錄制場景，還可能根據一些庫獲取設備信息的能力，或者設備ID能力，設備唯一指紋，利用集團的一些能力做上傳。端內截圖方案，我們截圖方案有四種，一種瀏覽器上，腳本監測是瀏覽器環境就調瀏覽器插件的截圖，如果在端上，淘系段上主流有兩種，淘系就是淘寶天貓用Windone的能力，就是h5使用能力有一個容器能力。支付寶可能是另外一個自己開發的容器，在容器環境中我們會調動容器能力，如果進入異常場景，上傳有問題，我們會借助腳本庫的能力，用純腳本實現來截圖。有了底層的這些，我們可以像人一樣操作頁面滾動和點擊，結合我們后臺就有一些真機管理，常用后臺管理能力，然后調動各個方面算法的檢測能力做到實現人工合自動的錄制和回放。

我們剛剛講了截圖有四種場景的，所以我們運行其實可以在瀏覽器或者是任何移動端上運行的，但是在非有容器能力，比如說用純腳本截圖場景APP下可能針對特別復雜頁面，因為腳本截圖可能會有一些失真的情況。

我們上傳在端內的淘系APP里，上傳到我們的圖片空間做管理，然后到國際站，到AE可能要轉海外的基站，我們就上傳到阿里云OSS服務的位置。

剛剛講到自動調度來提升它的穩定性，可能調度ATS自動調度的能力，然后有了這一套之后跟業務方整體鏈路，有的是頁面發布時候就叫我們，或者頁面需要有一些線上巡檢任務調我們，或者需要一些其他的創新方案時候，檢測頁面調我們，現在我們還接了任務，就是有一個訂單，這兩天報了一個問題，就是簽訂的訂單可能空白了也會調我們應用跑一下異常空白的檢測。

我們算法能力就是這些，最終顯示單機檢測有犬兔拼接能力，還有掉坑，適配檢測有含個性化數據圖片對比，因為不同賬戶或者同一個賬戶在不同時間訪問頁面也是不一樣的，用傳統的錄制回放對比會有較大的差異問題，然后會檢測異常詞，這會調用OCR的能力，或者是搶光，這種看業務方不同業務需求做定制。

大家看一下實際例子，就是素材圖模塊級數量變動，我們可能通過對比發現對比失敗人會去看這種問題導致的，還有商品和坑的自適應，商品坑寫死寬度導致不同機型寬度有問題，這是通過對比能力發現的。還有空坑能力，頁面圖沒有加載出來，或者默認加載了沒有實時商品數據的。然后還有掉坑，這就是指我們會場頁面一行兩個或者一行三個商品坑或者是卷的坑缺失的時候這也是業務場景需要關心的。

還有相同素材，就是我們只是檢測單品，單品如果出現了相同的推薦，相同的品牌或者相同的商品，我們這種場景下面其實后臺算法沒有做到正確打散，打散邏輯有問題的他們也會關心，還有空樓層的問題，有樓層名稱但是下面整個樓層沒有數據。

還有異常詞下面營銷利益點是null，這可能后臺沒有填或者前端拉取異常導致的。整屏或者大半屏沒有數據，還包括利益點的折疊。

我們介紹其中一種算法，就是含個性化區塊的圖像對比，運行過程中可以支持登錄自動化賬戶跑，但是難免跑實際場景或者同一個賬戶出現的異常，這是我們需要做圖像對比需要解決的問題。剛剛說我們整個實現是基于前端自適應，但是理想情況下可以做到100%的完美，但是不同瀏覽器環境不同開發的問題，或者邊框級1px適配差異導致累積換算時候，GS換算有精度問題，會有略微差異，我們會首先做一個平移，就是找兩張圖，通過一些換算找到差值最小的匹配位置，這一步目的就是把頂部對企業。

我們找的位置計算差值區域，就是兩張圖有差異的部分，這里有噪聲我們進行形態學操作，拿到主要差別區域，拿到差別區域以后，我們用邊緣檢測找到圖片邊緣，然后將差異化大的部分蓋掉，我們對比時候這兩個圖做對比的，然后會計算他們的特征和相似值，通過這個展示框架級差異，個性級差異是可以對比出來的。

除此之外，因為我們剛剛見過很多算法場景，還運用了特征點匹配，OCR，不同分類模型訓練，包括MobileNet。同時，因為插入頁面當中腳本和后臺交互，所以腳本可以拿到多一層信息就是頁面的DOM信息，這是指整個頁面有塊級元素存在，這個在頁面當中具體位置是什么樣的，比如說這里有商品坑，可以拿到這個坑位大小、長寬、具體頂部和左部位置，有這個信息可以進一步提高算法檢測的精度。

我們的運行數據是這樣的，如果人力適配投測試過程，主要是參加上線階段，上線前開發完以后，投入一輪去不同的機器看不同效果。這個在上線階段、測試階段、改完Bug的任何一個階段都可以實時跑，所以我們頁面覆蓋數比它高很多。同時，因為我們的算法能力，幫助他發現了更多的體驗類的問題。這是之前6月的數據，人力投入是當時有設備異常掉線場景維護，還有一部分是算法結果人工確認的投入，這種隨著算法精度提升和自動調度方案的改進，其實是可以進一步縮小的。這個是剛剛演示的單日巡檢，兩小時跑一次，一小時跑一次的場景下檢測到每天頁面有問題的數。

我的演講到這里結束，謝謝！