原創 浴風 淘系技術 4月16日
引言
作為前端大家是否遇到過在項目快上線的時候在某種機器上測試出有相容性問題，自己一個人在機房debug看看原因是什麼以及如何解決？大家又是否遇到過項目上線後在某個業務方tl的手機上出現了頁面展示問題，然後自己到業務方工位被一群業務圍住現場debug問題？是的作為前端，頁面的相容性問題是影響使用者體驗的問題，一直是我們需要重點保障的一個問題，保障消費者體驗的一緻性是我們的職責。今天的主題将為大家分享一種新的方法去保障我們的這個職責，減少我們的窘境。
今天的分享将從這三個角度為大家介紹這種方案：首先介紹現有階段我們遇到的一些典型的體驗問題以及這些問題所出現的複雜的業務背景，然後介紹針對這些複雜的業務我們是如何詳細設計這樣的一套方案去解決我們面臨的問題，最後通過一些實際使用案例的分享，為大家介紹我們是如何使用這樣的一套方案的。
典型的體驗問題
我們所說的體驗問題到底是什麼樣子的呢？上面為大家列舉了我們實際遇到的幾類，第一個是某個業務在某個機器的某個app上出現了頁面被放大，進而導緻貨品展示被截斷了；第二個是某個頁面在使用者浏覽時出現了商品展示圖檔缺失以及價格展示位NaN，第三個是某個頁面在使用者輸入了特定文本後出現了null的提示文案，這些問題都是影響到了實際使用者體驗的問題，有些屬于前端的适配，甚至有些是服務端傳回或者營運投放導緻的，當被使用者看到小則一笑而過認為這個産品前端沒有處理好，大則可能直接提了一個輿情。是以我們需要一套很好的方案去減少這類問題的出現，更好的以及更及時的發現這些問題，保障我們使用者的體驗。
複雜的業務背景
好的解決方案離不開特定的業務場景，現階段随着業務的不斷發展，我們的業務場景也變得逐漸複雜，不再是單一狀态、單一app的适配問題。以使用者增長的業務舉例：使用者增長負責在其他的一些app裡面通過權益、貨品等手段觸達使用者，然後将使用者引導喚端至手淘、再在手淘裡面承接使用者引導其購買轉化。
我們的産品業務可能是多狀态的。比如進來時候的紅包彈層、催用彈層、詳細面闆彈層以及分享之後的回流彈層等。其次這些頁面可能被投放到各個合作的app裡面去觸達使用者，比如二方的：UC、支付寶、優酷，甚至三方的：愛奇藝、百度、頭條、快手等。再者因為使用者群體的龐大，使用者使用的機型也分布廣泛，小米、華為、oppo、榮耀、甚至聯想、360、諾基亞等。
傳統的适配方法有兩種：第一種我們通過制作多個賬号、然後使用這些賬号去登陸、再由外包同學掃碼、通過人工比對的方式去判斷我們的頁面相容性是否良好，第二種是通過我們制作不同的mock碼去模拟各個狀态、再有外包同學掃碼通過人工對比去完成相容性适配。無論哪種方案對于我們這種多狀态、多機型、多app的X乘場景都是工作量巨大、耗時耗力的。其次對于一些掃碼功能隐藏得很深甚至沒有掃碼能力的app比如“美圖秀秀”更是變得無能為力。
詳細設計
▐ 設計思路
我們該如何去解決這些問題呢？首先我們分析問題所在的業務特性，我們的業務橫跨多個端，淘寶、支付寶、優酷這樣的的一方二方app，甚至抖音、頭條、快手、微信這樣的三方app，那麼我們基于用戶端能力的方法就失效不通用了；其次我們的業務橫跨了多個技術棧，H5、小程式、WEEX、輕應用，那麼我們基于浏覽器能力的方法也會變得無力，是以我們需要一種不依賴于用戶端不依賴于技術棧的解決方案。
我們同多個團隊同學進行了溝通和調研，發現有兩個技術現在正在逐漸發展成熟，一是真機技術、二是視覺技術。真機技術使得我們可以通過代碼指令排程機器去完成很多事情，比如：截屏，錄屏，滾動、點選、輸入甚至檔案操作、APP操作等。視覺技術随着opencv和機器學習的發展，圖像識别、檔案識别等能力變得比較成熟，并逐漸可以被作為判斷标準使用，于是我們有了去建構一個以真機和圖像為基礎的自動化架構的思路，這樣的一個方案是與app無關、與開發技術無關的。
▐ 核心互動
這樣的一套方案核心互動邏輯便為：首先使用adb指令去打開我們的應用頁面，然後在通過adb去截屏，再通過圖像識别出截屏中的元素和位置，之後就可以去斷言或者根據識别結果判斷下一步的操作，再通過adb去執行操作、截屏如此循環。
▐ 能力推導
有了這樣的一個核心流程之後，我們還需要一些其他能力，才能使得整個方案能完整的跑起來，我們從功能性、穩定性、易用性三個方向去考慮這些能力該如何建設。
首先是功能性方面：對于那些沒有掃碼能力的app，我們需要借助adb+scheme去打開app，而每個app的scheme是不同的，是以我們需要借助業務以及技術的手段去建構一個scheme池，這裡面涵蓋我們業務所涉及的常用的scheme形式。
其次我們的業務多以人群和裝置的次元呈現出不同的功能，是以我們需要去管理一個賬号池和裝置池，并能夠讓這些池子有個動态擴張、更新的機制，比如随着業務的發展，定時的去統計常用的機器，以擴充我們的測試裝置池。
再者我們業務增長快、業務多狀态互動，我們需要一套具備強擴充能力和動态性的解決方案去适應各種業務場景，我們選擇建構一個js腳本解析器+一些通用的js api函數的組合形式，使得各個業務能夠通過自定義腳本去定制自己的适配流程。
在機器的排程上，對于無登入或者支援多點登入的場景，我們需要支援并行機器排程的能力以提升效率，對于一些強登入、單點登入的場景，我們需要支援按賬号串行的排程機器，甚至對于多個任務使用同一個裝置這種沖突情況，我們需要一個排隊排程機器的能力。
對于同一個任務我們有重複定時執行的訴求，是以我們需要一個定時任務的機制。在任務執行完成或者發現異常以及一些通用的自定義提示場景我們需要及時的通知與回報，是以需要有消息體系去管理這些通知。
在穩定性方面，一個任務執行可能長達數個小時，期間受機器狀态等影響可能會出現一些異常，是以我們需要一些任務執行異常的異常處理邏輯。其次是日志debug系統，幫助我們及時的調試腳本執行的邏輯，快速找到問題以修改。對于一個任務我們也需要去監控他執行的狀态和結果，關注他的狀态，是以需要任務監控體系。
對于一個系統，易用性也同等重要，腳本的編輯時我們需要一個良好的腳本編輯器，具備文法校驗和api提示等通用輔助功能。其次對于一個通用的執行邏輯，我們可以通過腳本錄制去快速的生成我們需要的腳本。然後對于一些通用的高頻的場景，我們可以把他們抽象出基礎能力，直接通過勾選機器、app就可以建立任務，而非一定要手動寫腳本，比如對于通用的h5頁面多app的打開測試。
▐ 整體架構
至此便推導出了目前我們整個系統的整體架構，底層是我們業務涉及的app集合，以及常用的測試機器集合。中間核心是我們的JS腳本引擎，能夠簡析通用的JS邏輯，左右是我們抽象出的一系列真機操作和圖像相關的api，可以通過JS的調用和機器互動。上層是我們系統的通用能力，包含：scheme池、賬号池、裝置池...等等。
▐ API設計
在api的設計上，為了能夠更好的和機器互動，使它能夠更好以及更簡潔的完成我們的任務，我們把api分為5類：app操作、圖檔操作、基礎方法、行為操作、同時包含一些常用的複合功能。
app操作包含：安裝app并處理通用的app設定邏輯、比如授權權限這類彈窗；通過scheme去打開app；在某個app中去打開我們的h5頁面；以及判斷目前系統是哪個app，用于判斷crash或者喚端是否成功；關閉app、解除安裝app等。
圖檔操作包含：擷取目前螢幕截圖、或者目前螢幕中文字的位置、擷取螢幕中某個局部圖檔的位置、對比圖檔的相容性相似度、以及上傳圖檔到手機相冊等。
基礎的方法包含：執行特殊的adb指令、等待時間、儲存結果、記錄日志等api。
行為操作api可以去模拟使用者的基本行為，包含：滾動、點選、傳回、輸入等操作。
複合功能類api包含一系列常用api的組合去處理常用的功能，如：處理各種系統、app彈窗、站外H5登入、一些常用app的登入封裝、發送釘釘消息等。
以上便是目前的整體架構設計和api設計思路。
▐ 适配流程
基于這樣的一套解決方案，以一個标準的h5頁面适配流程為例：首先我們正常的開發我們的頁面或者局部子產品，然後我們可以建構mock資料用于聯調和展示，在開發完成之後我們便可以基于mock資料定義各标準狀态的截圖，然後我們通過scheme池擷取到待測試app的打開h5的scheme形式，之後我們就可以編寫測試腳本，通過api打開h5頁面，然後模拟使用者的行為操作頁面，再關鍵狀态截圖與标準狀态對比。之後把這樣的腳本在多個機器和app上運作，便可以擷取到這個頁面的“多狀态”X“多機型”X“多app”測試報告資料。
使用案例
接下來我們看兩個實際的使用例子
▐ 使用案例一
第一個例子是品牌新享搜尋功能相關的适配流程。當我們頻道貨品數量達到一定數量的時候單純的推薦可能沒法很好的滿足使用者的需求，需要考慮增加搜尋功能以滿足使用者的個性化查找。該搜尋功能包含三個狀态：搜尋框、搜尋清單頁、搜尋結果頁。
我們在平台裡面建立這樣的一個任務，選擇機器、并編寫自定義測試腳本。
腳本第一段是通過scheme 使用app去打開我們的頁面，第二段是找到搜尋框并點選進入搜尋清單頁，然後第三段通過點選搜尋按鈕進入搜尋結果頁，并在搜尋結果頁同标準的頁面狀态進行對比，得到一個相容性相似度評分。
整個腳本在不同機器上運作之後就産出了這樣的一張适配結果圖，我們可以發現在honor 8x這個機器上是有相容性問題了，頁面被撐開了找不到搜尋按鈕。
▐ 使用案例二
第二個是利用腳本去做線上頁面巡檢的例子，在充值中心業務中，我們期望定時的去執行任務，輸入不同的省、市、營運商的手機号，并判斷頁面上針對這個手機号是否出現異常展示。 【幹貨】通過真機實作頁面自動化适配（含直播回放） 同樣是在平台建立一個任務 【幹貨】通過真機實作頁面自動化适配（含直播回放）
然後腳本邏輯中，第一段通過scheme去打開充值中心頁面，第二段找到輸入框，然後最後通過一個for循環對96個不同省、市、營運商的号碼輸入、判斷有沒有異常展示，并清空輸入框、輸入下一個手機号碼。
運作中一旦出現異常便會通過釘釘告警。
好處
我們在多個業務中使用了這樣一套方案去幫助我們完成适配以及線上頁面的巡檢任務，發現有三個方向的好處，首先通過腳本排程機器完成任務，減少了測試成本，提升了我們整個項目的測試效率。其次，這些腳本可複用，我們在做了一個項目的技術疊代後，直接可以回歸驗證，無需重新編寫。再者，我們借助定時任務，可以定時去巡檢我們的線上頁面，持續的保障産品的品質和消費者的體驗。
優缺點
這樣的一套方案，對比傳統的自動化測試架構有優勢也有不足，首先優勢是：通過真機執行，更好的能反應使用者的真實環境，其次排程機器的鍊路短，更穩定，二是這樣的方案是不依賴開發語言和待測試的app的，更不依賴于代碼的實作，腳本的編寫也相對簡單，隻需要一些核心的api就可以完成大部分工作。不足處在于：斷言依賴于圖像的識别能力，沒法深入到請求資料、頁面的dom節點結構等。
解決問題歸類
基于圖像識别的斷言我們可以解決這幾類問題：檢測頁面上是否有特殊字元 undefined null等判斷頁面是否展示不全，空窗、元素丢失等檢測頁面是否出現了異常，如白屏、無效的連結、crash等以及其他的一些通過圖像和app層判斷的斷言類型。
擴充場景
這樣的一套方案在保障使用者體驗上除了用于做适配和定時巡檢，我們還可以用在其他的一些場景。
▐ 素材監測
比如針對我們投放的素材監測鍊路，我們可以通過真機模拟使用者行為去浏覽一些合作的app，當發現我們投放的廣告素材時，點選看看承接鍊路是否正常以及喚端鍊路是否正常。
▐ 開屏監測
第二個是我們通過真機去打開通路一些app，去識别出一些開屏廣告，去判斷他的喚端和承接鍊路是否正常以及判斷投放的這些素材是否有損使用者體驗。