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

[[284794]]

會上，阿里巴巴測試開發專家巴圖做《基于圖片對比的頁面自動化測試實踐》的內容分享。巴圖對比了傳統軟件公司和互聯網公司在軟件發布流程中有的不同，并指出如下三點：

1、頁面用例的自動生成，是阿里測試智能化探索的一部分；

2、測試平臺需要更好的穩定性以及自動化運維；

3、測試平臺需要建立Bug閉環，統計出一段時間內攔截的Bug數量，這才能體現平臺的真正價值。”

以下為巴圖演講實錄：

大家上午好，我是來自阿里巴巴CBU技術部的巴圖，今天為大家帶來的議題是基于圖片對比的頁面自動化測試實踐。這里有一些老朋友，可能聽過這個議題了，我今天盡可能深入的多講一些。

本次議題包括以下五個議程，首先我們來看一下對于傳統軟件公司和互聯網公司他們的軟件發布流程有什么不同？首先從發布周期來講，傳統軟件公司一般都是以年為單位，比如說微軟的Windows、Visual Studio等，都是兩到三年一個周期發布，而對于互聯網公司迭代是以天為單位，Bug修復是以小時為單位。互聯網公司在Bug修復成本方面成本比較低，對于用戶體驗來講會友好一些，因為有很多人在做體驗，數據的收集難度和接觸用戶成本也比較低。

傳統的軟件公司協同方式是強流程的，互聯網公司協同方式是強平臺的。在軟件發布之后，不同公司的QA的職責也是不一樣的，軟件公司的QA是研發環節最后一環，以盡可能發現Bug為主要職責，零Bug率是其主要的目標，QA是公司的流程推動者和權限的制約者；而在互聯網公司又不太一樣，QA要構建一個全流程的質量體系，還是工具平臺的發起者和創造者，需要捍衛真實的用戶體驗。實際上現在很多公司都擁有測試開發工程師，就是說測試要具備一定的開發能力，實際上阿里巴巴的測試還需要具備一定的算法能力，后面我再細說。

我們BU有一個三到五年的規劃，推行的測試策略是實時質量，就是運行含測試，實時可反饋。一句話總結就是將質量手段以模塊、組件乃至系統化的方式嵌入到業務型應用當中。在我們看來，開發的代碼和測試的代碼是兩個領域，開發寫的代碼是為業務特性服務的代碼，測試寫的代碼是為業務質量服務的代碼。

今年我們推出了“無人職守智動化”，就是基于變更，提供全流程、多樣化、智能化的無人職守診斷能力，做到質量的實時反饋，到現在為止，QA不僅做驗收測試，還要為整個的產品質量做一些診斷，要為全流程環節的質量做保障。

首先，來看全流程看護的層面，我們要在發布的各個階段進行看護，包括變更前的預發階段、變更中的灰度階段和變更后的上線階段。另外，要覆蓋所有的變更，包括代碼類變更、配置類變更和DB類變更，還需要多維度診斷，包括自動化診斷、業務監控診斷和業務日志診斷，最終擁有發布門禁，作為發布的準入，如果有質量問題會卡發布，在預發階段和灰度階段進行發布卡口。

這張圖是我們現在的協同流程，我們會在把很多的feature創建分支，進行并行開發，這些分支在不同時間進行集成和發布。阿里不同的BU是不同策略，螞蟻那邊是在一個固定的時間大家統一來集成，統一進行回歸測試的。但是對于新零售的電商業務，分支都是很難統一一個時間發布的，所以處于高頻集成狀態，這種高頻集成狀態也為質量保障帶來了很大的挑戰。

我們需要用分層自動化模型來應動挑戰，左邊是一些自動化框架&平臺，包括UI層的MyDiff和MYUI，接口層的QTest和Doom，還有線上壓測的Amazon。分層主要分4個層面，從上到下來是展示層、接口層、服務層和數據層，越上層穩定性越差，但是自動化效果越好。

再看執行階段，在生產運行階段我們要進行故障診斷和線上壓測，預發布階段進行變更檢測和預發布自動化。開發/功能調試階段進行無線組件測試和適配測試。

剛剛提到了UI層有MyDiff，MyDiff是零成本配置的截圖對比自動化平臺，有以下幾個特點：成本低、預發布攔截、全屏與區域截圖、自定義操作、支持多瀏覽器和多語言。

首先測試平臺的發展要把自身融入到整個公司的研發生態里，所以我們要進行一些測試平臺和協同平臺的對接，包括蓋亞、Tesla、AONE等平臺。我們支持10個以上BU，包括CBU、ICBU、AE，零售通，阿里云，盒馬等。MyDiff提供了任務管理、結果管理、執行機管理、數據統計、告警通知和API接口等功能，還具有兩大核心能力：截圖能力和對比能力。

首先看截圖能力，截圖能力中包含環境管理、登錄管理、區域管理和前置操作四種能力：

阿里分四種環境：日常環境，預發環境，安全生產環境和線上環境。除了線上環境之外，所有的環境都需要綁定HOST訪問，所以需要進行環境管理；

阿里一般分很多種登錄系統，比如說大家經常登錄天貓淘寶用的“淘系登錄”、大麥登錄、內網BUC登錄，還有其他的系統自建的登錄，所以，需要完善的登錄管理，在我們統計過程當中90%以上頁面都需要登錄以后才能訪問的；

區域管理，我們提供了區域截圖的能力，在整個頁面圖片對比很難解決用戶的業務問題時，用戶可以定義他在一個頁面具體截哪一部分，把這部分進行截圖對比；

前置操作可以理解為簡單的腳本功能，因為我們的MyDiff提倡的是零成本配置，所以不會提供復雜的腳本能力，復雜的腳本能力是剛才提到的MIUI提供的。

再看對比能力，對比分像素級和非像素級兩種。

像素級對比，比如PC上頁面在自動化過程當中可以控制瀏覽器尺寸，就意味著截圖尺寸是一樣的，可以通過簡單的像素級對比來檢測出他們之間有什么差異，對于無線端來講，每一個手機的尺寸和分辨率都不相同，所以截圖從像素級別來講像素點對不上，通過傳統像素對比解決不了問題，我們就進行非像素級的探索。

無論像素級或非像素級，都需要提供相似度評估和差異標定。適用的場景包括頁面回歸測試、頁面巡檢、頁面異常檢測和適配測試。其他場景還在探索中。

接下來看一下MyDiff在整個自動化流程里是如何工作的：

首先，開發在AONE提交代碼進行發布，預發環境部署后執行STC安全掃描、CodeReview和自動化測試，這些測試都成功后才允許進行發布。我們的GAP平臺接受AONE的消息，會檢測應用關聯哪些平臺自動化的測試件，比如說UI層MyDiff或MYUI，接口層的DOOM，隨后調取分層自動化的框架，框架執行完成以后會把結果反饋給GAP，GAP把結果同步給AONE。如果自動化測試失敗，就需要測試人員上AONE處理，才能流轉到下一步，測試人員需要判斷這是一個正常業務變更引起的自動化失敗還是確實測出了Bug。如果是Bug，通知開發處理，如果不是Bug就進行跳過處理。

再看一下技術實現架構：

MyDiff通過Web提供服務，需要有Web集群， Web集群里面應用的技術是阿里開源的Tengine項目和Pandora Boot框架；共享存儲層，由IDB提供的MySQL集群服務、Tair提供的緩存服務和阿里云提供的OSS文件存儲服務；Web集群，圖片對比集群和任務調度集群之間是通過消息來進行交互的，這里寫的RockeMQ作為一個開源方案，在內部RockeMQ叫MetaQ，任務調度集群和執行機集群通過HTTP進行交互。

下面是我們在圖片對比算法方面的一些實踐：

圖片對比的常規方案是將一個原始圖片進行灰度化后再生成差值圖，最后進行圖片對比。但是這種方案在頁面元素輕微平移后，對比的結果就不準確了。我們在生成差值圖后，增加了形態學膨脹和形態學腐蝕兩步關鍵操作，膨脹是為了把離散的差值像素點膨脹成一個一個連通區域，連通以后為了避免連通區域擴大再進行一次腐蝕，這樣就會把各個離散的像素點都組成區域。

舉個例子，比如UI上一行文字，如果不進行膨脹腐蝕的時候可能每個字是一個區域，進行膨脹和腐蝕處理后一段話是一個區域，這樣再進行標定結果就會更準確。

再來看我們在非像素級圖片對比的探索，用肉眼看這兩張圖是有一定的差異，第一個差異點是上面的導航欄，第二個差異點是右圖下面的一個toast提示，第三個是虛擬按鍵。但實際上對于計算機識別來說，會認為這兩個圖是完全不一致的，因為我們來看兩張圖，首先字體就不太一樣，所以從像素點比較來看，他們之間是對不上的。再就是卡號，包括后面“請輸入銀行卡號”文本框和按鈕尺寸都不一樣，位置也不一樣。這為我們對比提供了一定的挑戰，我們首先會通過一些預處理，把一些與業務無關的圖片剪切掉，然后再進行相應的元素輪廓提取，把所有的元素提取出來，在兩張圖互相搜索，在另一方搜索不到的元素實際上就是差異了。

當時我們測試了幾種算法，包括SSIM、直方圖、PSNR和兩種組合算法，發現SSIM和感知哈希的組合算法的效果最好，可以達到86.74%的識別率，當時用了362組阿里系的樣本。

現在看一下SSIM，自然圖像信息高度結構化，像素信息具有強烈的依賴性，在空間上接近時依賴性攜帶關于視覺場景中的對象結構信息，SSIM算法的優勢在于契合人類的視覺系統的觀察特性，它的實現主要是通過亮度、對比度和結構的度量組合來實現的相似度的評估。

接下來看一下感知哈希的算法，圖像都是二維信號，包括不同頻率的部分，亮度比較小的頻率是低頻的部分，實際上在左邊的第二張圖就是一個低頻部分，但是實際上，通過肉眼來看低頻部分基本上是這張圖的信息了。再就是亮度變化劇烈的區域實際上是高頻部分，高頻部分肉眼基本上看到是一塊黑或者一塊藍的區域。所以要通過下采樣提取低頻信息。

提到了感知哈希一般都會與均值哈希進行對比，均值哈希的實現，首先將圖片縮放成8乘8的尺寸，再把圖片灰度化，之后再進行二值化求值，然后對平均值進行計算以后得到哈希指紋。均值哈希實際上有一些缺點，對它進行伽馬校正或直方圖均衡會影響均值，從而影響hash值。現在業界大多應用感知哈希，是把圖縮放到32乘32的尺寸，通過離散余弦變換來獲得低頻部分，離散余弦變換后有一個8乘8矩陣的低頻部分映射到左上角了，大家看到藍圖就是高頻的部分，提取出來左上角8乘8部分算出來指紋就會比較穩定。

這是最后對比出來的實際結果，首先進行預處理，識別出來上面的導航欄的特征和下面的虛擬按鍵的特征，因為會干擾對比切掉了。然后兩張圖進行元素提取，把一些元素提取出來后去另外一張圖搜索，搜索不出來的就是兩張圖的結構差異，這里面可以看到，toast就是差異，對于右圖來講toast遮擋的7、8、9、完成等元素，所以會把位置整體框出來。

接下來是卡發布的實踐，各家公司協同平臺不太一樣，但原理都是一樣的，比如，在我們AONE當中可以新建UI測試，這張圖被遮蓋了實際上可以選擇MyDiff服務，也可以在這個流程配置當中建立發布流程的配置，比如預發布正式的流程，就是先進行預發環境發布，會觸發自動化，自動化通過以后才進行正式發布。

這里用日常發布舉例，包括開始、構建、日常部署、日常集成測試、日常驗證、結束。關鍵點在于日常集成測試，大家會把自動化關聯到這個環節，部署完成以后立刻去觸發集成測試。這里可以為我們的測試服務添加驗證點，比如，我們設置在預發需要WebUI測試100%通過后，才能進行下一步。

這實際上是在AONE當中真實案例，比如預發集成測試過程當中失敗了，就已經卡住后面的正式構建了，需要測試人員來上協同平臺看一下，點擊查看結果看一下具體的問題，如果沒有問題就可以進行跳過，如果有Bug的話就打回去讓開發進行修改。

上面這張圖是MyDiff列表里的一條任務，總數是兩個，代表兩個頁面，相同的是兩個的話就證明執行通過沒有問題。下面的是一條不通過的結果，詢報價單頁面里有訂單區域，我們為相似度設置0.98，如果不滿足0.98代表測試不通過。

這里就是一個具體的真實的兩張截圖，上面截圖是在預發環境的截圖，下面這個是在線上環境的截圖。我們電商一般都會有一些大促活動，大促期間發貨時間比日常延長，所以一般會在大促的過程中進行一些文字提示，然后這就是本次發版與線上之間會有一些差異，MyDiff平臺會直接把他們兩張圖之間的差異標出來，這樣測試人員就可以一眼定位到問題在哪里，也可以判斷這是一個正常業務變更，還是Bug。

現在說一下我們對未來的規劃，首先體驗要持續優化，降低用戶門檻，因為我們現在是在阿里整個經濟體下進行推廣，所以降低門檻有助于讓它生存得更好。再就是流量錄制，今天會議的主題是“AI+未來”，現在大家都在探索智能化，阿里接口測試領域已經實現初級智能化，我們的智能化定義也在于自動生成，接口完全可以通過線上流量生成自動化用例，UI也計劃著使用線上流量來實現，一個是智能url推薦，還有就是對于某一個頁面用例自動生成。還要在穩定性上下工夫，為各個部門提供穩定的服務，做一些自動化運維的實踐。平臺的價值需要評估出來，比如，在一個財年或者一段時間內，能攔截多少Bug，這才是平臺真正的價值。我們需要建立Bug的閉環，把我們能攔截的所有的Bug統計出來。再就是一些能力優化，比如執行速度、對比能力以及算法能力。

我的分享就到這里，謝謝。