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

時間 2019-11-25

原文原文鏈接

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

做者：李帥

導語

借項目的開發週期，把思考了一段時間的場景化性能測試框架搭建起來，包括耗電性能測試、內存泄漏測試、UI流暢度性能測試、後臺接口性能測試、app啓動速度測試等。方案應用於項目的測試，也發現了產品中的很多問題。接下來將用七八個篇幅詳細記錄一下心路歷程。爲分享輪子或爲回憶總結。git

簡述

性能測試，在通訊設備測試界，是一個很是成熟的領域，IETF組織在這個範疇制定了諸多RFC以規範測試行爲。但在筆者接觸移動測試領域的四年裏，性能測試彷彿是一個無關緊要的專項；性能問題，在各個項目中，老是停留在「用戶報障->開發關注 -> 測試復現」。github

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

目標與戰法

嘗試歸納下性能測試：經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。成功的性能測試，會具有如下幾個特色：網絡

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

提供給開發的信息具備精準性。若是測試或用戶告訴開發同窗：「大家這個版本性能不好！」、「用着用着手機就開始發燙了，你搞定一下！」開發同窗心裏確定是迷茫的。學習

若是測試將本身的措辭換成：「資訊頁面，觀看視頻過程耗電量高，這個版本比上個版本jiffs高了30%。」，這樣開發團隊能夠根據模塊指定跟進人，知道具體的路徑，知道耗電量的優化目標（這個版本多出的這30%），那問題的推動必然會更加順利。

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

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

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

三、頁面驅動的流暢度測試，常常出現兩次對同一版本的測試得出大相徑庭的測試結果，測試數據不穩定，難以向開發證實其代碼有問題。後文介紹流暢度測試時再詳述優劣。

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

圖一流暢度樣本

測試熟練使用工具幫助開發定位性能問題。測試左移一點，多作一點，開發就能夠少花一點精力在縮小問題訪問上。在功能測試中，一個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) 極大值、極小值。

必要的說明

框架使用了開源代碼：

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