知乎移動端性能測試實踐

知乎移動端性能測試實踐

來自專欄知乎技術專欄49 人贊了文章

在移動客戶端的測試環節中,性能測試是比較重要的一部分,相對於普通的常規測試,性能測試實施複雜、環境配置困難、測試問題場景很難復現、報告編寫和結果分析對測試人員要求較高等等因素導致性能測試很難在實際的測試過程中推行。

實際的測試過程中我們經常會遇見通訊異常、客戶端停止運行,還有各種崩潰、卡死、頁面載入一直轉圈、手機運行過熱、耗電嚴重等等問題,如下是幾款典型的性能測試工具對比:

可以看出上述工具的實施難度都比較高,並且在一定程度上都會依賴本地開發環境配置,在跨平台方面常規第三方工具必須添加低侵入式 SDK,生成報告又需要手動獲取文件,整理文件數據手動生成各類報表等。所以考慮到性能測試的便捷性、低成本等方面的要求,儘可能在測試階段解決上述這一類問題,於是設計了一個便捷、無門檻的性能測試工具,我會從工具的使用步驟、設計目標、問題發現、工具實現細節、自動化接入、工具擴展等方面來進行介紹。

使用步驟

首先簡單介紹一下工具的主要步驟如下:

1.打開工具頁面

2.APP 掃碼

使用 APP 內置的掃碼工具掃描二維碼,使 APP 內置的地址修改為測試伺服器的地址,這時工具頁面會自動跳轉至性能數據實時查看頁面。

3.APP 實時性能表現查看

CPU/MEM

流量上傳下載

Java GC

幀率

內存佔用

4.測試報告生成和留存

完成測試之後系統會直接生成測試報告,開發、產品、測試可以用來共同分析測試過程中遇到的問題。

系統設計目標

  1. 環境配置、易用性

    在環境配置方面、基本上不需要再依賴本地環境,由客戶端內置代碼和服務端通訊完成數據上傳,完整的測試過程一共只有 4 個步驟即可,測試門檻幾乎基本上全部消失、通過掃碼 → 報告的方式,最大程度簡化了使用流程,帶來了極大的便捷性和易用性。
  2. 數據展示

    1) 基礎數據展示

    客戶端第一次上傳數據時,系統會自動識別客戶端的基礎信息、包括平台、客戶端版本、設備型號、測試人員、測試時間等相關信息。

    2) 性能數據展示

    數據展示方面使用了 bizcharts 對數據進行可視化、分別採用區域圖、線圖、點陣圖展示最近 5 - 10 分鐘的性能數據,在測試期間、系統會動態定時刷新性能數據。
  3. 結果分析

    在上面的圖表中,可以看到『流量下載』部分的圖表中存在某一區域明顯上升,在通常的操作過程中這種流量下載的突然增高可能會是用戶使用時進行了下載、語言、視頻、音樂等操作,在測試過程中實際上並沒有上述操作,可以判斷是由一些 API 的數據請求造成,復現幾次後可以得到實際的請求 API,然後由開發人員判斷是否需要針對這個 API 進行瘦身優化,減少請求流量的消耗。

  4. 質量報告

    質量報告的生成沒有時間限制,也不需要進行特殊處理,在測試人員完成性能測試、或者手動結束性能測試之後,系統會自動生成性能測試結果報告的頁面,並生成唯一的測試報告鏈接。
  5. 實施難度和擴展

    在設計開發和測試實踐過程中,遇到的主要難度是:

    客戶端數據收集上傳的過程中、需要保證數據的完整,保證數據的連貫性。所以客戶端數據上傳時採用隊列的方式存儲數據,當系統出現問題、網路異常、伺服器故障時把數據存入隊列,在問題解決之後再將隊列中的數據發送到服務端。

實現過程和細節

性能數據獲取的前提是質量團隊和客戶端團隊對指標的獲取達成共識,主要方式由客戶端實現後質量團隊 review 代碼確認後確定數據獲取方式,在數據獲取方面沒有做更加深入的自定義,包括一些指標如下:

  1. CPU、內存、網路流量、幀率
  2. Android GC 數據
  3. 電池、電量相關數據
  4. 異常、卡頓、自定義代碼運行問題

客戶端架構設計:

客戶端採取隊列方式上傳數據,提供可配置的間隔控制和開關。

服務端數據交互

數據採用 base64 加密後,傳輸 gzip 壓縮,服務接收數據解析

@Throws(IOException::class)private fun preProcess(request: HttpServletRequest): ByteArray { // 獲取輸入流 // 轉 GZIP 輸入流 // 獲取解密方式 base64 解密 // 捕獲異常並返回位元組流數據}

自動化性能測試接入

1. 通過自動化介面調用服務端生成性能測試實例

2. 客戶端自動化打開開關進行自動化性能測試

客戶端通過自動化腳本打開性能測試開關、同時調整性能測試伺服器 url 的指向,然後執行編寫完成的自動化性能測試腳本,同時上傳數據並記錄時間戳,當發現問題時用於核對性能數據和操作步驟。

3. 調用性能測試結束介面

當自動化性能腳本反覆執行完畢之後,達到 2 小時的標準建議或者手動調用測試結束介面,系統會結束測試不再接收後面的數據,生成測試報告同時按照規則生成報告的唯一 url 地址。

4. 自動獲取生成的性能測試報告

自動化性能測試完成之後,會拿到性能的報告地址,可以通過郵件、IM 等方式將報告發送給相關人員或進行下一步的其他測試。

擴展

系統還在建設過程中,後續的擴展主要基於下圖:

在客戶端、瀏覽器、測試伺服器之間建設一個性能測試閉環,同時在後面的性能測試過程中還會擴展關注如下一些指標:

1.卡頓異常(卡頓堆棧信息、異常定位數據)

2.過程耗時(冷啟、熱啟、重要業務耗時)

3.頁面切換、載入時間

4.內存泄漏、抖動、頁面渲染(FPS)、圖片/視頻/語音等專項指標

團隊介紹

知乎的質量保障團隊,屬於知乎技術中台事業部, 承擔了公司各產品線的質量保障工作及以下平台的設計開發工作:

  • 移動端雲測平台
  • 性能數據分析監控報警平台
  • 移動端持續集成平台
  • 移動端內測及發布平台
  • 知乎質量平台
  • 介面自動化平台
  • ...

國際慣例,歡迎有志於質量保障工作的知友們加入知乎 QA 團隊,與知乎一起發現更大的世界,詳細職位可以參見 這裡,期待知友們的加入 ~


推薦閱讀:

Jmeter性能測試系列-性能測試需求評審
如何進行安全性測試?
混凝土保護塗層的性能測試研究
Jmeter性能測試系列-腳本用例設計
Jmeter壓力測試

TAG:性能測試 | 科技 | 移動端 |