移動端測試探索之路

引言

O2O 市場和智能手機在高速發展中，餓了么作為一家領先的 O2O 移動互聯網公司，業務也在隨之不斷擴張。App 功能越來複雜，加之移動端的技術方案多樣化、國內網路環境複雜等問題，做好 App 的測試就面臨著諸多挑戰，本文大致講述目前餓了么在 App 測試上遇到的挑戰，以及應對挑戰所作出的努力。

挑戰

餓了么目前 DAU 已達千萬級，在快速適應市場需要、迎合用戶需求、提供良好的用戶體驗的背景和要求下，移動端的測試、開發人員都面臨著一些新的挑戰。

第三方自動化工具不夠給力

餓了么業務高速發展中，場景越來越複雜和多樣化，App 的新功能、新特性也越來越豐富，因此回歸測試所需時間和人力也越來越多，急需能夠有效提高測試效率的自動化解決方案。

對於測試人員來說，在快速迭代、UI頻繁變動的情況下，時間、人力有限，無法做到全面的回歸測試是最大的痛點。使用一些第三方工具進行腳本錄製或者腳本編寫 (如 appium 等) ，ROI 很低，測試人員往往需要根據 UI 的變動反覆修改腳本，同時還要兼顧迭代內的測試任務，腳本的修改速度跟不上 UI 的變動速度，維護成本很高，最終還是不能很好的解決回歸測試覆蓋率不足的問題。

App性能問題越來越被重視

在用戶至上、體驗為王的當下，如何節省電量、流量，如何保證 App 順暢運行變得越來越重要。相應的，測試人員在測試過程中，需要對 App 的性能問題進行更多的關注。因此需要測試人員全程採集App的實時性能數據 (內存、CPU、流量、FPS 等) ，並針對這些數據做進一步的綜合分析，比如內存突然增大且沒有回落出現在哪個時間點，對應的測試步驟、功能頁面是哪個等等。性能數據多且分散、手工測試和數據記錄時間線的分離，都會造成測試人員發現、定位問題變得困難。

對於開發人員來說性能問題的解決起來也不輕鬆。測試過程中採集到的性能數據僅能反應 App 運行時的外在表現，對應到代碼內部，涉及的範圍非常的廣，除了 App 本身的源碼，還會涉及 SDK 等第三方的源碼，排查起來非常的耗費時間。

小結

面對以上挑戰，許多大廠&對移動技術有追求的公司，都會去下功夫研發自己的自動化測試平台。餓了么移動基礎框架團隊通過研發 Stellar 測試平台，來幫助測試人員更好、更高效的完成移動端的測試工作。

解決方案 - Stellar測試平台

有了移動端的錄製回放 SDK ，就需要一個可以管理腳本、執行腳本、記錄結果的操作平台，將錄製-回放-記錄結果這個過程串聯起來。因此誕生了 Stellar 移動測試平台。

架構設計

下圖是平台的分層架構圖：

平台主要分為前端、服務、移動端3層。其中前端為 Web 頁面，是與用戶交互的入口，提供腳本管理、腳本調試、測試報告查看等功能。服務層是前端和移動端的承接層，負責腳本管理、腳本執行任務調度、測試報告生成、網路請求 mock 等。移動端以 SDK 的形式接入被測 App，記錄UI操作和控制項、代理網路請求並發送給 mock server、回放腳本、記錄 log 和性能數據等。

流程

被測 App 接入 SDK 後，用戶可通過連接碼將手裡的測試機與平台建立連接，從而實現腳本錄製、回放等操作。除了打開平台，建立連接之外，腳本錄製均在移動端進行。測試人員將測試機與平台連接後，可正常按照測試用例在手機端進行操作，SDK 會錄製整個測試過程並將網路請求發送給 mock server，對於測試人員來說沒有其它額外操作，提高了腳本錄製的效率、降低了操作複雜度。

為了方便測試人員快速到達被測功能，SDK 提供了場景選擇功能，在錄製時可選擇起始場景，直接到達被測頁面，節省測試人員的時間。由於錄製過程中已經將網路請求保存在 mock server，在回放時，請求全部來自於 mock server，保證回放的穩定性。測試人員可根據實際情況選擇某個請求走 mock server 還是使用真實的數據。後續還會提供網路請求編輯的功能，由測試人員自己定義網路請求。

技術方案簡介

前端主要是用餓了么大前端研發的 Element 框架結合 WEditor 開發。Element 詳細介紹請移步：http://element.eleme.io/#/zh-CN

Service 層主要是 Java 後端，還有一小部分基於 STF 的二次開發。其中 Java 後端包括腳本管理、測試報告、mock server，任務調度部分由基於 STF 的二次開發來實現。

移動端通過內嵌 SDK 的方式，對 UI 操作進行代理和記錄， 同時支持 iOS 和 Android 端。Android 端的實現思路是通過內嵌 SDK 的方式，對 UI 操作進行代理和記錄。基本原理是在 App 之上增加一層中間層，用來獲取和記錄屏幕上的 UI 操作。如下圖：

Android SDK 的實現思路是對 UI 操作進行代理和記錄，在回放時基於 Instrumentation 方式進行回放。iOS SDK 的實現思路是監聽 Responder Chain 中分發的事件，對事件進一步分析，記錄事件的路徑及點擊區域。回放時採用同樣方法下發。

以上的平台設計，對於測試人員來說，幾乎不需要額外的操作就可以進行錄製回放。只需要打開錄製開關，按照已編寫好的測試用例對 App 進行手工測試，測試完成後，腳本就錄製完成了。平台將錄製的腳本轉化成易讀性強的步驟，測試人員可以通過平台進行二次編輯和腳本回放操作。

在實現了錄製回放功能後，根據測試人員的使用場景，又增加了對起始錄製場景的支持，可在接入 SDK 時由開發人員根據測試人員的需求定製錄製的起始場景，方便測試人員快速到達自己負責的功能模塊，不需要額外錄製 App 的起始頁面到被測模塊之間的過路場景。

後續會有介紹技術方案的文章，歡迎大家持續關注。

總結

Stellar 測試平台研發的目的是為了解決移動端測試的痛點和挑戰，測試人員可通過便捷的操作，對 UI 頁面進行自動化腳本錄製、回放，同時可在腳本回放過程中收集 App 的性能數據，並可在測試過程中一鍵記錄 bug 對應的系統快照、提交至 bug 管理系統。未來還將增加深度性能分析，在代碼層級給出性能問題點，幫助開發人員快速定位問題。

在移動測試快速發展的今天，希望通過我們的探索和努力，幫助更多的測試、開發人員提高效率。