糯米O2O移動自動化測試實踐

本文介紹了基于百度糯米O2O體系移動技術框架下的自動化測試方案，這是一種突破傳統的移動領域測試方案，由組件自動化測試和端監控問題報警定位兩個部分組成。

背景

移動App從早期的Native架構體系發展為Hybrid框架，再到現在的組件化架構，開發技術不斷創新，測試自動化框架也層出不窮，包含有Appium（跨平臺iOS 和Android），Robotium, Calabash及EarlGrey（google的iOS開源自動化框架）等。

這些工具在很多產品的測試中起到很大幫助，但是與App開發技術的變革相比，測試技術的發展有些滯后，測試自動化框架總感覺不能滿足現有產品的測試需求，就比如組件抑或是React Native這樣架構體系的產品出現后，先前介紹的那些測試開源框架就顯得有些不足。

為此在糯米組件之路變革后(組件概念詳細請參考《糯米移動組件架構演進之路》這里不詳細說明)，在測試自動化技術上面又有了新的質變。

組件自動化測試方案

早期自動化工具及方案的弊端

移動App組件團隊為解決手工測試所帶來的迭代測試任務的繁重、線下回歸的漏測、測試覆蓋率低等問題，開始選擇使用自動化工具或者框架。但是逐漸會發現自動化工具某種程度上并不能很好的降低手工測試成本，反而苦惱于自動化工具的易用性，增加了學習成本，并且運行成功率不近人意。有些部門將自動化測試用例運行的結果作為上線前的最后防線，這里面的大家可以想想最終的數據是否真實，測試人員是否真能得益于這些所謂的測試工具。

從現有的當下比較流行的測試工具來做個分析：

(點擊放大圖像)

基于以上工具很多公司也會建立起一系列云端測試技術框架，同時也會附帶滿足很多自動化專項測試項目，包括提供測試真機。但是對于基于組件的架構的app，而且這些開發技術正運用的越來越廣泛，基于以上工具的方案就無法滿足產品功能迭代需求。

• 組件元素的識別問題 – 組件加載到iOS和Android平臺上面其代碼都是同樣的，如果說appium可以滿足現在的測試需求，但是識別組件頁面控件屬性就是唯一的缺陷，同時在兩端上識別出來的可以使用的屬性元素完全不一樣，給測試人員增加了維護成本，同時也給運行自動化用例增加了不穩定性。

• 長距離到達組件入口的穩定性問題 – 特定組件的頁面往往需要注冊登錄，選擇一些必要的步驟后才能到達需要測試的組件頁面，那里才是測試重點，但是冗長的測試步驟增加了運行自動化的不穩定性，半路可能被中斷。如果可以跳過一些不必要的步驟直接進入入口，那樣就可以避免這樣的問題。

• 跨平臺穩定性問題 – 跨平臺的穩定性一直是很多公司為之擔心的一個問題，如何保證客戶端與服務端之間的無縫交互，服務端的api被長時間調用和運行能不請求失敗，都是現有工具存在的缺陷。

• 學習維護成本問題 – 自動化平臺或工具如果對環境配置，使用規范，腳本等有較復雜的要求的話，那么對于入門剛剛的測試工程師來說有一定的學習成本。

糯米組件自動化框架解決方案

針對以上問題，百度糯米NA團隊提供如下解決方法：

1）實現元素的識別方式通過Google Chrome將組件Dom頁面結構抓取，通過元素的屬性，或寫出支持xpath，jQuery選擇器表達式。元素的定位結果同時適合iOS與Android兩端。

(點擊放大圖像)

2）對于測試要求驗證的頁面，及頁面上的元素，如果頁面路徑較長，到達頁面的入口前的步驟較多會增加case運行的不穩定性，糯米通過Schema實現入口直接跳轉，直奔主題的測試方案，縮短距離，提高穩定性，對于其他產品頁面通過Schema跳轉的方式亦可參考此類方案。

比如下圖測試關注的是電影院內部的測試功能，達到入口的中間環節往往會導致case的不穩定性，通過現有方案的方式就可以避免。

(點擊放大圖像)

3）手機安裝App獨立拉取服務端下發的cases運行，切斷物理連接，這樣對于特殊不穩定異常或者對于特殊機型的需求，比如最新的iPhone系列或者最新的Android系的手機，團隊可自行運行，填補平臺的特殊情況下的資源空缺。

4）單獨case，實現單一業務測試需求，測試集合被實現對手機移動測試的daily運行方案中，將多個單一場景的測試需求集成為統一復雜的測試場景，組件團隊，自行觸發daily運行的時間段。

(點擊放大圖像)

5）為滿足業務快速迭代需求，通過平臺配置化，無需特殊語言技能，業務測試工程師只需要配置特定業務運行場景即可實現腳本穩定dialy運行，零成本學習與培訓投入。

為實現以上功能優點，通過客戶端安裝自動化App,服務端配置化腳本與設置場景，就可以將自動化運用到極致，以下是手機Android端的無線自動化運行框架：

(點擊放大圖像)

手機端安裝該自動化App，HTTP請求部分為后端平臺的能力支持，包括配置信息，腳本信息，case運行報告統計信息等在平臺上面創建、更新和匯總，待準備后，手機端輸入或者daily運行一個指定的測試集合ID號，便可實時運行，產生包括自動化在內的功能case回歸情況，以及其他專項測試的性能指標等信息。

框架基于uiautomator實現，封裝相關接口，對case的各類動作實現解析，調用封裝的api來驅動頁面ui的操作，失敗的case步驟實現截圖上傳，以判斷當前失敗的具體情況。因為支持無線連接，持續job觸發，所以并行運行能力也可滿足。

組件端監控主動巡檢

組件從下發到App加載渲染，整個過程中每個環節都會有各種意料之外的問題。常規的線上監控，一般都是接口級別，策略性運行，通過報警閾值，實時監控；端上對ANR，Crash，響應時間等都可以通過App內植入埋點方案或者接入第三方sdk，后端平臺上提供報警信息，進行實時監控；但是對于組件頁面完整渲染的監控一直無法做到全面覆蓋，比如后端服務正常返回到前端，但是手機在特定情況下定位功能出現解析問題導致頁面一直加載中；特定App端上的api初始化接口沒有ready,組件沒有進行判斷就直接調用內部方法導致頁面出現異常等都是一般離線日志，或者埋點，接口報警平臺不能發現的。為此業務方對此提出以下訴求問題：

1. 怎樣在前端對ui組件頁面加載異常做監控；

2. 出現異常之后怎么定位，需要提供哪些必要輔助信息方便排查；

3. 監控點怎么部署，運行機制，報警策略怎么實現；

組件頁面加載異常監控方案

糯米團隊對ui組件頁面加載異常做監控，主要通過真機實時運行組件頁面列表，輪巡跳轉，頁面掃描，除了實現對組件頁面元素缺失的監控外，還加了js彈框異常阻塞的監控，請求錯誤的監控，具體方案如下：

(點擊放大圖像)

1） 監控引擎 - 整個核心就是注入的Luban.js文件，該文件可以對組件，對h5頁面進行掃描分析(如上圖提供了三種能力)。js怎么被注入到被測app? 我們通過平臺下發js注入文件，被監控的app監聽js文件是否有更新判斷進行加載，使用方開啟被測app開關實現js動態注入，使得每個組件或者h5頁面都能引用到該文件。從而實現監控引擎的功能。

2） 監聽頁面 – 監聽頁面主要功能是拉取平臺配置的監控點，監控策略，配置信息等（如上圖）供監控引擎進行分析，比如當組件1頁面被打開，監控引擎自動觸發，分析來自監聽頁面的信息，對該頁面進行掃描，成功或者失敗的標識會被回傳到監聽頁面，監聽頁面上傳到平臺中。

大家可以看一下該方案可以做哪些事情:

當監聽頁面獲取到我們手工添加頁面的監控項的時候，監聽引擎就會進行以下一些事情

Dom元素存在判斷，請求失敗判斷，js異常彈框出現判斷

以下是實際線上報警監控抓到的問題：

1）頁面元素的監控失敗情況（Dom元素存在判斷）：

(點擊放大圖像)

2）為某個組件的頁面js報錯彈框（js異常彈框出現判斷）：

(點擊放大圖像)

3)為某個組件的頁面接口請求報錯具體鏈接（請求失敗判斷）：

(點擊放大圖像)

UI層面以上三種類型的判斷邏輯基本已經覆蓋到了整個組件頁面的加載異常的監控。

當然，app框架本身也會存在日志監控實時上傳到后端平臺，平臺做比如組件包下載成功監控，組件更新成功率監控，組件端到端響應時間監控等，這些都是拿線上用戶的監控日志來做分析，對于我們QA團隊來說，要求第一時間能夠反映線上用戶的體驗，就需要這樣一種主動巡檢的方式，在大量報警前盡全力查找潛在的風險，提前杜絕。

組件定位方案

線上問題查找與定位對于測試人員來說一直是非常痛苦的問題，當用戶反饋一個偶現的問題的時候尤其如此，通過手機號，日志，發生時間，用戶反饋的現象，查找用戶使用操作的問題，這種方式比較常見，也是很難定位具體問題，涉及用戶手機狀況類型，網絡情況，系統，app版本，組件版本，是否命中反作弊等各種可能性都有。如果能夠獲取用戶當時的請求和后端的返回數據，以及當時的頁面問題表現，加上之前提到的一些信息基本能80%可以定位一些問題，對于線上主動巡檢也是如此。

我們通過luban.js文件將接口請求，和json的返回結果一并記錄，同時端上自動將頁面截圖，報警時間，運行系統等信息供給各組件方排查：以下截圖大家可以看到request_params,http_reponses是當時報警獲取的請求和對應該請求所返回的結果。

(點擊放大圖像)

報警還提供精準的報警時間，報警的監控元素問題，以及截圖，通過這些就能定位問題原因，如上圖外賣一家本應該有菜單的shop店的“熱銷”菜單，后端數據間隙性缺失，可能原因后端redis問題，需要對errorno:114013進行后端日志排查，這個信息很大程度上給值班人員提供更小范圍內的有力的信息依據，對快速排查線上問題大有幫助，及時止損。

監控點部署及報警策略

組件頁面布局一般分為banner,品類，searchfilter,列表頁面等，針對這些特點，我們將使dom元素的監控涉及到這些信息，如下圖：

(點擊放大圖像)

對于報警可以設置為組件id連續報警日志出現一定數量后，通過短信和郵件進行接口人催辦盡快解決。

目前整個糯米NA QA團隊通過實際真機進行主動巡檢，分iOS和Android端，主要是核心組件，對于其他組件想在特殊場景下或者特殊機型下監控，可以自行配置監控任務，整個平臺既可提供獨立服務，亦可提供監控真機服務，這種方式可以極大滿足各類組件的監控需求，保障整個糯米App的真實的用戶體驗。

 

 

來自：http://www.infoq.com/cn/articles/the-practice-of-nuomi-o2o-mobile-automatic-testing