建站
咨詢
售后
建站咨詢
新聞中心
2019年10月26日，由Testin主辦的第二屆NCTS中國云測試行業(yè)峰會在京召開，此次峰會以“AI+未來”為主題，匯聚來自國內外測試領域的知名專家學者、領先企業(yè)決策者、高層技術管理者、媒體從業(yè)者等，共同探討高端云測試技術，幫助測試從業(yè)者了解最前沿行業(yè)趨勢，及最新的行業(yè)實踐。
10年積累的網(wǎng)站設計、網(wǎng)站制作經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有馬鞍山免費網(wǎng)站建設讓你可以放心的選擇與我們合作。
會上，阿里巴巴測試開發(fā)專家巴圖做《基于圖片對比的頁面自動化測試實踐》的內容分享。巴圖對比了傳統(tǒng)軟件公司和互聯(lián)網(wǎng)公司在軟件發(fā)布流程中有的不同，并指出如下三點：
1、頁面用例的自動生成，是阿里測試智能化探索的一部分；
2、測試平臺需要更好的穩(wěn)定性以及自動化運維；
3、測試平臺需要建立Bug閉環(huán)，統(tǒng)計出一段時間內攔截的Bug數(shù)量，這才能體現(xiàn)平臺的真正價值?！?/p>
以下為巴圖演講實錄：
大家上午好，我是來自阿里巴巴CBU技術部的巴圖，今天為大家?guī)淼淖h題是基于圖片對比的頁面自動化測試實踐。這里有一些老朋友，可能聽過這個議題了，我今天盡可能深入的多講一些。
本次議題包括以下五個議程，首先我們來看一下對于傳統(tǒng)軟件公司和互聯(lián)網(wǎng)公司他們的軟件發(fā)布流程有什么不同？首先從發(fā)布周期來講，傳統(tǒng)軟件公司一般都是以年為單位，比如說微軟的Windows、Visual Studio等，都是兩到三年一個周期發(fā)布，而對于互聯(lián)網(wǎng)公司迭代是以天為單位，Bug修復是以小時為單位?；ヂ?lián)網(wǎng)公司在Bug修復成本方面成本比較低，對于用戶體驗來講會友好一些，因為有很多人在做體驗，數(shù)據(jù)的收集難度和接觸用戶成本也比較低。
傳統(tǒng)的軟件公司協(xié)同方式是強流程的，互聯(lián)網(wǎng)公司協(xié)同方式是強平臺的。在軟件發(fā)布之后，不同公司的QA的職責也是不一樣的，軟件公司的QA是研發(fā)環(huán)節(jié)最后一環(huán)，以盡可能發(fā)現(xiàn)Bug為主要職責，零Bug率是其主要的目標，QA是公司的流程推動者和權限的制約者；而在互聯(lián)網(wǎng)公司又不太一樣，QA要構建一個全流程的質量體系，還是工具平臺的發(fā)起者和創(chuàng)造者，需要捍衛(wèi)真實的用戶體驗。實際上現(xiàn)在很多公司都擁有測試開發(fā)工程師，就是說測試要具備一定的開發(fā)能力，實際上阿里巴巴的測試還需要具備一定的算法能力，后面我再細說。
我們BU有一個三到五年的規(guī)劃，推行的測試策略是實時質量，就是運行含測試，實時可反饋。一句話總結就是將質量手段以模塊、組件乃至系統(tǒng)化的方式嵌入到業(yè)務型應用當中。在我們看來，開發(fā)的代碼和測試的代碼是兩個領域，開發(fā)寫的代碼是為業(yè)務特性服務的代碼，測試寫的代碼是為業(yè)務質量服務的代碼。
今年我們推出了“無人職守智動化”，就是基于變更，提供全流程、多樣化、智能化的無人職守診斷能力，做到質量的實時反饋，到現(xiàn)在為止，QA不僅做驗收測試，還要為整個的產(chǎn)品質量做一些診斷，要為全流程環(huán)節(jié)的質量做保障。
首先，來看全流程看護的層面，我們要在發(fā)布的各個階段進行看護，包括變更前的預發(fā)階段、變更中的灰度階段和變更后的上線階段。另外，要覆蓋所有的變更，包括代碼類變更、配置類變更和DB類變更，還需要多維度診斷，包括自動化診斷、業(yè)務監(jiān)控診斷和業(yè)務日志診斷，最終擁有發(fā)布門禁，作為發(fā)布的準入，如果有質量問題會卡發(fā)布，在預發(fā)階段和灰度階段進行發(fā)布卡口。
這張圖是我們現(xiàn)在的協(xié)同流程，我們會在把很多的feature創(chuàng)建分支，進行并行開發(fā)，這些分支在不同時間進行集成和發(fā)布。阿里不同的BU是不同策略，螞蟻那邊是在一個固定的時間大家統(tǒng)一來集成，統(tǒng)一進行回歸測試的。但是對于新零售的電商業(yè)務，分支都是很難統(tǒng)一一個時間發(fā)布的，所以處于高頻集成狀態(tài)，這種高頻集成狀態(tài)也為質量保障帶來了很大的挑戰(zhàn)。
我們需要用分層自動化模型來應動挑戰(zhàn)，左邊是一些自動化框架&平臺，包括UI層的MyDiff和MYUI，接口層的QTest和Doom，還有線上壓測的Amazon。分層主要分4個層面，從上到下來是展示層、接口層、服務層和數(shù)據(jù)層，越上層穩(wěn)定性越差，但是自動化效果越好。
再看執(zhí)行階段，在生產(chǎn)運行階段我們要進行故障診斷和線上壓測，預發(fā)布階段進行變更檢測和預發(fā)布自動化。開發(fā)/功能調試階段進行無線組件測試和適配測試。
剛剛提到了UI層有MyDiff，MyDiff是零成本配置的截圖對比自動化平臺，有以下幾個特點：成本低、預發(fā)布攔截、全屏與區(qū)域截圖、自定義操作、支持多瀏覽器和多語言。
首先測試平臺的發(fā)展要把自身融入到整個公司的研發(fā)生態(tài)里，所以我們要進行一些測試平臺和協(xié)同平臺的對接，包括蓋亞、Tesla、AONE等平臺。我們支持10個以上BU，包括CBU、ICBU、AE，零售通，阿里云，盒馬等。MyDiff提供了任務管理、結果管理、執(zhí)行機管理、數(shù)據(jù)統(tǒng)計、告警通知和API接口等功能，還具有兩大核心能力：截圖能力和對比能力。
首先看截圖能力，截圖能力中包含環(huán)境管理、登錄管理、區(qū)域管理和前置操作四種能力：
阿里分四種環(huán)境：日常環(huán)境，預發(fā)環(huán)境，安全生產(chǎn)環(huán)境和線上環(huán)境。除了線上環(huán)境之外，所有的環(huán)境都需要綁定HOST訪問，所以需要進行環(huán)境管理；
阿里一般分很多種登錄系統(tǒng)，比如說大家經(jīng)常登錄天貓?zhí)詫氂玫摹疤韵档卿洝?、大麥登錄、內網(wǎng)BUC登錄，還有其他的系統(tǒng)自建的登錄，所以，需要完善的登錄管理，在我們統(tǒng)計過程當中90%以上頁面都需要登錄以后才能訪問的；
區(qū)域管理，我們提供了區(qū)域截圖的能力，在整個頁面圖片對比很難解決用戶的業(yè)務問題時，用戶可以定義他在一個頁面具體截哪一部分，把這部分進行截圖對比；
前置操作可以理解為簡單的腳本功能，因為我們的MyDiff提倡的是零成本配置，所以不會提供復雜的腳本能力，復雜的腳本能力是剛才提到的MIUI提供的。
再看對比能力，對比分像素級和非像素級兩種。
像素級對比，比如PC上頁面在自動化過程當中可以控制瀏覽器尺寸，就意味著截圖尺寸是一樣的，可以通過簡單的像素級對比來檢測出他們之間有什么差異，對于無線端來講，每一個手機的尺寸和分辨率都不相同，所以截圖從像素級別來講像素點對不上，通過傳統(tǒng)像素對比解決不了問題，我們就進行非像素級的探索。
無論像素級或非像素級，都需要提供相似度評估和差異標定。適用的場景包括頁面回歸測試、頁面巡檢、頁面異常檢測和適配測試。其他場景還在探索中。
接下來看一下MyDiff在整個自動化流程里是如何工作的：
首先，開發(fā)在AONE提交代碼進行發(fā)布，預發(fā)環(huán)境部署后執(zhí)行STC安全掃描、CodeReview和自動化測試，這些測試都成功后才允許進行發(fā)布。我們的GAP平臺接受AONE的消息，會檢測應用關聯(lián)哪些平臺自動化的測試件，比如說UI層MyDiff或MYUI，接口層的DOOM，隨后調取分層自動化的框架，框架執(zhí)行完成以后會把結果反饋給GAP，GAP把結果同步給AONE。如果自動化測試失敗，就需要測試人員上AONE處理，才能流轉到下一步，測試人員需要判斷這是一個正常業(yè)務變更引起的自動化失敗還是確實測出了Bug。如果是Bug，通知開發(fā)處理，如果不是Bug就進行跳過處理。
再看一下技術實現(xiàn)架構：
MyDiff通過Web提供服務，需要有Web集群， Web集群里面應用的技術是阿里開源的Tengine項目和Pandora Boot框架；共享存儲層，由IDB提供的MySQL集群服務、Tair提供的緩存服務和阿里云提供的OSS文件存儲服務；Web集群，圖片對比集群和任務調度集群之間是通過消息來進行交互的，這里寫的RockeMQ作為一個開源方案，在內部RockeMQ叫MetaQ，任務調度集群和執(zhí)行機集群通過HTTP進行交互。
下面是我們在圖片對比算法方面的一些實踐：
圖片對比的常規(guī)方案是將一個原始圖片進行灰度化后再生成差值圖，最后進行圖片對比。但是這種方案在頁面元素輕微平移后，對比的結果就不準確了。我們在生成差值圖后，增加了形態(tài)學膨脹和形態(tài)學腐蝕兩步關鍵操作，膨脹是為了把離散的差值像素點膨脹成一個一個連通區(qū)域，連通以后為了避免連通區(qū)域擴大再進行一次腐蝕，這樣就會把各個離散的像素點都組成區(qū)域。
舉個例子，比如UI上一行文字，如果不進行膨脹腐蝕的時候可能每個字是一個區(qū)域，進行膨脹和腐蝕處理后一段話是一個區(qū)域，這樣再進行標定結果就會更準確。
再來看我們在非像素級圖片對比的探索，用肉眼看這兩張圖是有一定的差異，第一個差異點是上面的導航欄，第二個差異點是右圖下面的一個toast提示，第三個是虛擬按鍵。但實際上對于計算機識別來說，會認為這兩個圖是完全不一致的，因為我們來看兩張圖，首先字體就不太一樣，所以從像素點比較來看，他們之間是對不上的。再就是卡號，包括后面“請輸入銀行卡號”文本框和按鈕尺寸都不一樣，位置也不一樣。這為我們對比提供了一定的挑戰(zhàn)，我們首先會通過一些預處理，把一些與業(yè)務無關的圖片剪切掉，然后再進行相應的元素輪廓提取，把所有的元素提取出來，在兩張圖互相搜索，在另一方搜索不到的元素實際上就是差異了。
當時我們測試了幾種算法，包括SSIM、直方圖、PSNR和兩種組合算法，發(fā)現(xiàn)SSIM和感知哈希的組合算法的效果最好，可以達到86.74%的識別率，當時用了362組阿里系的樣本。
現(xiàn)在看一下SSIM，自然圖像信息高度結構化，像素信息具有強烈的依賴性，在空間上接近時依賴性攜帶關于視覺場景中的對象結構信息，SSIM算法的優(yōu)勢在于契合人類的視覺系統(tǒng)的觀察特性，它的實現(xiàn)主要是通過亮度、對比度和結構的度量組合來實現(xiàn)的相似度的評估。
接下來看一下感知哈希的算法，圖像都是二維信號，包括不同頻率的部分，亮度比較小的頻率是低頻的部分，實際上在左邊的第二張圖就是一個低頻部分，但是實際上，通過肉眼來看低頻部分基本上是這張圖的信息了。再就是亮度變化劇烈的區(qū)域實際上是高頻部分，高頻部分肉眼基本上看到是一塊黑或者一塊藍的區(qū)域。所以要通過下采樣提取低頻信息。
提到了感知哈希一般都會與均值哈希進行對比，均值哈希的實現(xiàn)，首先將圖片縮放成8乘8的尺寸，再把圖片灰度化，之后再進行二值化求值，然后對平均值進行計算以后得到哈希指紋。均值哈希實際上有一些缺點，對它進行伽馬校正或直方圖均衡會影響均值，從而影響hash值?，F(xiàn)在業(yè)界大多應用感知哈希，是把圖縮放到32乘32的尺寸，通過離散余弦變換來獲得低頻部分，離散余弦變換后有一個8乘8矩陣的低頻部分映射到左上角了，大家看到藍圖就是高頻的部分，提取出來左上角8乘8部分算出來指紋就會比較穩(wěn)定。
這是最后對比出來的實際結果，首先進行預處理，識別出來上面的導航欄的特征和下面的虛擬按鍵的特征，因為會干擾對比切掉了。然后兩張圖進行元素提取，把一些元素提取出來后去另外一張圖搜索，搜索不出來的就是兩張圖的結構差異，這里面可以看到，toast就是差異，對于右圖來講toast遮擋的7、8、9、完成等元素，所以會把位置整體框出來。
接下來是卡發(fā)布的實踐，各家公司協(xié)同平臺不太一樣，但原理都是一樣的，比如，在我們AONE當中可以新建UI測試，這張圖被遮蓋了實際上可以選擇MyDiff服務，也可以在這個流程配置當中建立發(fā)布流程的配置，比如預發(fā)布正式的流程，就是先進行預發(fā)環(huán)境發(fā)布，會觸發(fā)自動化，自動化通過以后才進行正式發(fā)布。
這里用日常發(fā)布舉例，包括開始、構建、日常部署、日常集成測試、日常驗證、結束。關鍵點在于日常集成測試，大家會把自動化關聯(lián)到這個環(huán)節(jié)，部署完成以后立刻去觸發(fā)集成測試。這里可以為我們的測試服務添加驗證點，比如，我們設置在預發(fā)需要WebUI測試100%通過后，才能進行下一步。
這實際上是在AONE當中真實案例，比如預發(fā)集成測試過程當中失敗了，就已經(jīng)卡住后面的正式構建了，需要測試人員來上協(xié)同平臺看一下，點擊查看結果看一下具體的問題，如果沒有問題就可以進行跳過，如果有Bug的話就打回去讓開發(fā)進行修改。
上面這張圖是MyDiff列表里的一條任務，總數(shù)是兩個，代表兩個頁面，相同的是兩個的話就證明執(zhí)行通過沒有問題。下面的是一條不通過的結果，詢報價單頁面里有訂單區(qū)域，我們?yōu)橄嗨贫仍O置0.98，如果不滿足0.98代表測試不通過。
這里就是一個具體的真實的兩張截圖，上面截圖是在預發(fā)環(huán)境的截圖，下面這個是在線上環(huán)境的截圖。我們電商一般都會有一些大促活動，大促期間發(fā)貨時間比日常延長，所以一般會在大促的過程中進行一些文字提示，然后這就是本次發(fā)版與線上之間會有一些差異，MyDiff平臺會直接把他們兩張圖之間的差異標出來，這樣測試人員就可以一眼定位到問題在哪里，也可以判斷這是一個正常業(yè)務變更，還是Bug。
現(xiàn)在說一下我們對未來的規(guī)劃，首先體驗要持續(xù)優(yōu)化，降低用戶門檻，因為我們現(xiàn)在是在阿里整個經(jīng)濟體下進行推廣，所以降低門檻有助于讓它生存得更好。再就是流量錄制，今天會議的主題是“AI+未來”，現(xiàn)在大家都在探索智能化，阿里接口測試領域已經(jīng)實現(xiàn)初級智能化，我們的智能化定義也在于自動生成，接口完全可以通過線上流量生成自動化用例，UI也計劃著使用線上流量來實現(xiàn)，一個是智能url推薦，還有就是對于某一個頁面用例自動生成。還要在穩(wěn)定性上下工夫，為各個部門提供穩(wěn)定的服務，做一些自動化運維的實踐。平臺的價值需要評估出來，比如，在一個財年或者一段時間內，能攔截多少Bug，這才是平臺真正的價值。我們需要建立Bug的閉環(huán)，把我們能攔截的所有的Bug統(tǒng)計出來。再就是一些能力優(yōu)化，比如執(zhí)行速度、對比能力以及算法能力。
我的分享就到這里，謝謝。
文章名稱：【NCTS峰會回顧】阿里巴圖：基于圖片對比的頁面自動化測試實踐
轉載源于：http://www.dlmjj.cn/article/djghgsh.html
