Android 效能測試之方向與框架篇

假期結束，你的狀態有沒有迴歸？那麼，放空腦袋後，先來學習學習，歡迎大家繼續關注騰訊雲技術社群。

作者：李帥

導語

借專案的開發週期，把思考了一段時間的場景化效能測試框架搭建起來，包括耗電效能測試、記憶體洩漏測試、UI流暢度效能測試、後臺介面效能測試、app啟動速度測試等。方案應用於專案的測試，也發現了產品中的不少問題。接下來將用七八個篇幅詳細記錄一下心路歷程。為分享輪子或為回憶總結。

簡述

效能測試，在通訊裝置測試界，是一個非常成熟的領域，IETF組織在這個範疇制定了諸多RFC以規範測試行為。但在筆者接觸移動測試領域的四年裡，效能測試彷彿是一個可有可無的專項；效能問題，在各個專案中，總是停留在“使用者報障->開發關注 -> 測試復現”。

顯然，如果效能問題，如果也能最大限度的按照“測試發現->問題定位 ->開發修改”的正常流程來走，對產品質量是有非常大貢獻的。下文的介紹，目標就在於此：測試過程中，測試工程師識別更多的產品關鍵場景，通過場景化、工程化、自動化的測試手段，發現更多的效能問題，使得效能BUG收斂於產品釋出前。

目標與戰法

嘗試概括下效能測試：通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。成功的效能測試，會具備以下幾個特點：

提供給開發的資訊具有精準性（必備）；
測試方法高效，測試資料穩定可靠（必備）；
使用的分析方法具有高可信度（必備）；
測試熟練使用工具幫助開發定位效能問題（可選）。

提供給開發的資訊具有精準性。如果測試或使用者告訴開發同學：“你們這個版本效能很差！”、“用著用著手機就開始發燙了，你搞定一下！”開發同學內心肯定是迷茫的。

如果測試將自己的措辭換成：“資訊頁面，觀看視訊過程耗電量高，這個版本比上個版本jiffs高了30%。”，這樣開發團隊可以根據模組指定跟進人，知道具體的路徑，知道耗電量的優化目標（這個版本多出的這30%），那問題的推進必然會更加順利。

測試方法高效，測試資料穩定可靠。在設計本框架前，團隊執行效能測試，包括長板效能測試（亮屏後臺耗電及記憶體）、手工驅動的場景效能測試、基於頁面驅動的流暢度測試。

1、長板效能，場景過於單一，基本只校驗了管家後臺程式無任何操作下的效能表現；

2、相比於UI自動化驅動，手工測試無法保證收集到大樣本資料（讓人反覆做一個操作30分鐘，這種任務毫無疑問是對員工的摧殘）；

3、頁面驅動的流暢度測試，經常出現兩次對同一版本的測試得出截然不同的測試結果，測試資料不穩定，難以向開發證明其程式碼有問題。後文介紹流暢度測試時再詳述優劣。

使用的分析方法具有高可信度。傳統的分析方案中，往往簡單地採用均值來評估效能項。筆者認為，合理的選用評估演算法，也能讓你的測試報告更有說服力。一個存在少量毛刺的資料序列，如下圖，由於毛刺偏離嚴重，將嚴重拉低平均值。多一個毛刺，少一個毛刺，均值都會有很大不一樣，在樣本量較少時，往往會出現兩次測試獲得的效能資料差異大的問題。（如何解決後面詳述）。

圖一流暢度樣本

測試熟練使用工具幫助開發定位效能問題。測試左移一點，多做一點，開發就可以少花一點精力在縮小問題訪問上。在功能測試中，一個BUG從偶然復現到找到必現路徑，會讓開發減少大量定位問題時間。同樣，在效能測試中，如果測試能指明哪個執行緒是功率消耗大戶，哪個物件是記憶體洩漏禍首，那麼開發也能更加迅速地修復問題。同時，測試在定位過程中，不僅僅提升了自身能力，也建立起了自己的技術形象。

效能測試框架設計

如下圖，本次設計的效能測試框架，包含有資料收集、資料分析、UI自動化、驅動框架四個模組，各自獨立解耦。這樣設計能夠降低用例接入成本，可擴充套件性好。

圖二框架設計原理圖

資料收集方案

我們需要通過一種或多種資料，直接反應一項效能的好壞。所以如何收集資料樣本？收集那些資料樣本，是效能測試框架必備的一個模組。

UI驅動方案

移動客戶端的效能測試，主要是模擬使用者操作來創造類使用者使用場景，獲取使用過程中的CPU、mem、流暢度等資料，以衡量該使用場景下，被測應用的效能指標。

本框架的UI自動化框架，選擇了python 版的uiautomator（GitHub開原始碼）。主要有如下幾點原因：

資料收集模組需要使用adb工具，做adb輸出結果處理、文字分析，python在這方面有較大優勢，程式碼量低；
Xiaocong封裝的開源python版uiautomator，非常輕量級，功能全面，直接使用開源專案，能夠節省非常多的框架開發時間；

驅動框架介紹

在本框架中，測試人員能夠用如下的命令列直接驅動一個或多個用例的執行，所以設計了類testng邏輯的方案。

Python startTest.py -t 3 -c SwitchTabTest
Python startTest.py -t 3 -m SwitchTabTest,swipeDownTest

如下圖，CaseExecutor類用來驅動和組織各個用例的suite_up()，set_up()，test()，tear_donw()，suite_down()等方法。

圖三類junit的驅動部分

而用例中包含的這些方法，主要作用是：

a) suite_up() : 用於執行初始化環境

b) set_up() : 主要用於拉起相應的效能資料收集執行緒、使用UI自動化初始化應用到被測場景，如閃屏滑動，進入主頁等。

c) test() : UI自動化執行場景的關鍵邏輯，如：測試“連續播放不同視訊”場景的記憶體洩漏。則用例需要在test()方法中，使用uiautomator實現迴圈點選不同視訊播放的邏輯。

d) tear_down() : 該方法主要用於通知資料收集執行緒停止資料收集，進行資料歸檔；

e) suite_down() : 該方法將清空環境，將所有資料彙總到報告中，並使用資料分析演算法得到可以直接用於報告的內容。

圖四執行邏輯

如圖四，UI自動化在test()中執行相應場景時，效能資料收集執行緒會持續收集效能資料

註明：上述的五個步驟並不需要在每個case中實現，對應同一專項，除了test()，其他四個方法，都具有相同的邏輯，抽象到父類中實現即可，這樣可以做到同一個專項下的不同場景用例，只需要寫一個test方法。

資料分析方案

拿到資料後，想要最大化資料的價值。合理合適的資料分析方案顯得尤為重要。筆者一開始做效能測試，所能想到的也就是拿到一大堆樣本資料，取平均值，再做對比分析。

本框架試圖提供除了平均值外，提供其他更為豐富的資料來評估各類效能指標。包括：

a) 中位數：以它在所有標誌值中所處的位置確定的全體單位標誌值的代表值，不受分佈數列的極大或極小值影響，從而在一定程度上提高了中位數對分佈數列的代表性。中位數用於評估網路延遲樣本，效果明顯優於平均值。原因在於，如大部分延遲在20ms時，其中有幾個異常樣本值2000ms以上，它們會嚴重拉高均值，導致均值不能完全代表該延遲資料序列。

b) 方差與標準差：結合均值來評估資料序列，可以評估到資料序列的離散程度。

c) 分佈圖或分佈表：分佈圖或分佈表也能比較好的評估一個資料序列的好壞，用它來做流暢度、網路頻寬、網路延遲等效能評估，能夠比較直觀、詳細地給出對比結果。

圖五流暢度優化效果示意

d) 曲線圖：記憶體效能的評估，最優解莫過於佔用曲線+ 平均值了。

圖六佔用記憶體曲線

f) 平均值：最傳統的均值，依然是一柄利器。

g) 極大值、極小值。

必要的說明

框架使用了開原始碼：

以上對具體程式碼的介紹比較少，後續幾篇繼續闡述下具體邏輯是怎麼實現的。