從探索到突破：網易雲音樂Android自動化效能測試實踐

某些平臺上輸出的效能監控報告，資料沒有統一標準、進一步分析無法進行，自動化測試往往成為雞肋，你是否滿意？

那麼，面對複雜的線上環境，如何才能完成效能相關的自動化測試？面對線下環境，又該如何模擬使用者操作，制定一個物件導向的標準？

本章內容，網易雲音樂高階Android工程師李宗駿為您解讀《雲音樂Android自動化效能測試實踐》。

概述

本章將從卡頓監控的角度，介紹網易雲音樂在效能方面的自動化測試實踐。 內容涵蓋三方面：

1、明確平臺架構的搭建目標； 2、雲音樂在卡頓監控中的實踐經驗； 3、從測試閉環到開發閉環中的實踐經驗。

雲音樂的目標

提出目標前，先要了解清楚我們想處理什麼樣的問題，收集什麼樣的問題，達成什麼樣的目的？ 反覆的思考和探討後，網易雲音樂在效能自動化測試上提出了以下目標：

• 可執行的標準：標準可量化、面向線下環境、面向使用者體驗；
• 可分析的問題：保證收集的問題可被分析，能產出在程式碼邏輯上的優化修改；
• 持續整合能力；
• 向開發側閉環：對開發過程有一定約束。

以下是雲音樂的目標規劃圖——

在卡頓監控中的實踐

在卡頓監控中，BlockCanary是一個比較高效的分析方法，最初雲音樂採用的就是這一方案，但在實踐中遇到了一些問題：

• 顆粒度較大，無法細分具體的場景，導致分析困難；
• 無法監控非msg和多個msg耗時。 BlockCanary的原理是它能監控主執行緒的Message執行耗時，同時在判斷髮生卡頓的同時開始採集堆疊資訊。所以這決定了它的本質就是——一個場景（主執行緒Message耗時）+ 可分析的內容（堆疊資訊）。 因此，沿著這種思路，我們可以想到監控卡頓問題，主要就是找到一些場景，然後收集場景中可分析的內容。 在這一思路的啟發下，我們嘗試做了一個組合的模式： Step1：將問題按照場景進行細分，總結常見的發生卡頓的場景。

  

  但在執行一段時間之後發現這種思路也有一定不足： 場景過於細分，導致分體不夠內聚； 很多卡頓問題的場景不是單一的，而是多個場景的組合。 以上都對問題最終的分類和定位造成一定困難。 又做了進一步改進——

Step2：讓所有的檢測向BlockCanary聚合。

這種做法有兩個好處：

• 能夠根據場景制定不同標準，增加有效性；
• 通過收集關鍵資訊，提高分析效率。 首先，問題的輸入不再限制是BlockCanary，而是我們任意定義的卡頓場景都可以觸發資訊收集。

另外，所有與效能相關的環境資訊都會被抽象成事件，統計發生卡頓前後整個時間段內的所有發生過的效能事件和對應的時間點，比如生命週期事件，繪製事件，佈局載入事件，Input、動畫事件等。 通過類比可以發現，這種資訊採集的方式剛好相當於systrace和traceview的結合，明確目標之後，可以參考systrace所收集的資訊，進一步優化採集的策略、豐富採集的資訊。

Step3：對採集資訊進行分類。 目前網易雲音樂採用的分類方法比較簡單，即從下向上建立堆疊，找到第一個耗時卡頓總時間二分之一的業務程式碼，就會將其標記為問題的核心方法，然後根據核心方法歸類問題，如果幾個問題的核心方法一致，就將其歸為一類。 #從測試閉環到開發閉環#

上圖可以看到，這是我們團隊之前開發和測試之間的流程關係： 通過自動化的測試解析發現bug——開發消解bug——投入到下一輪測試 這種方法的缺點在於測試結果沒有在團隊中同步，開發過程缺乏約束。 針對以上問題，團隊回顧了效能測試從最初到最後的過程，進行問題分類，得到結論如下圖：

分析出這些Top級的問題後，發現可以更進一步：除了依賴之前的BlockCanary流程發現問題，也可以直接按照所發現的問題進行統計和問題定位。 同時，Top級問題也會加入到靜態程式碼檢查中，這樣在開發過程中就可以預先消解潛在的效能問題，對開發產生約束。 通過這種方式，形成了一個開發過程的新閉環，最終達到了下圖的流程：

即出現bug後提取Top問題——將Top問題一方面作為新的測試專案投入到測試當中，另一方面把它作為程式碼掃描輸入。 這種方法就能夠利用靜態程式碼檢測，增加開發過程的約束。

#總結# 在團隊的自動化效能測試工作中，總結出以下經驗： 1、要制定一個比較明確的目標：想做什麼？是以線上環境為主還是測試為主？怎樣採集資料？制定穩定的標準？ 2、效能測試本身雖然是一個閉環，但也是可以被持續整合的，可以隨著測試方法動態發生發展。這一過程中不僅要可以做到測試過程閉環，也可以做到開發環境閉環，去約束開發。