客戶端穩定性異常檢測:函式介面“掃雷”實踐

語言: CN / TW / HK

作者:安晴

背景

在過去的財年中,支付寶客戶端高可用團隊持續保障著支付寶客戶端線上的高可用穩定性,但只有線上的應急快反能力是不夠的,還需要線下提前發現客戶端的穩定性風險建設風險挖掘能力,完善整體的客戶端高可用保障體系。通過總結過去1-2年的線上閃退問題可以發現其中NPE問題,RPC資料型別不匹配和config變更導致的閃退問題佔比較大,完全可以線上下通過一定機制提前發現。

基於此我們對影響穩定性的因素進行分類,按照優先順序構建了客戶端的穩定性“掃雷”體系,主要包括函式介面掃雷,rpc&config&jsapi掃雷,scheme&廣播&通知掃雷,lottie&antmation&鳥巢模板變更掃雷等,通過這套掃雷能力建設我們希望可以完全避免線上出現以上穩定性故障,同時以issue的形式推動研發優化程式碼,不斷提高客戶端穩定性,從事前的角度去完善客戶端高可用保障體系。

技術方案

根據經驗分析在客戶端的函式呼叫中由於對函式引數檢查不夠導致的各類閃退問題佔比在20%左右。現階段方案Android端針對public和private的static靜態介面,iOS端針對所有public介面進行Fuzz測試,通過對安裝包掃描獲取到全量的介面函式資訊,然後對函式入參Fuzz製造各類異常場景,測試客戶端的穩定性。

與傳統的程式碼靜態掃描相比,本方案在真實客戶端上執行,貼近真實場景可製造真實的異常資料。整個技術實現方案包括以下幾點:

  • 程式碼掃描給出詳細介面檔案
  • 客戶端無侵入實現批量介面反射執行能力
  • 引數Fuzz異常構造能力
  • 自動化測試用例控制真機執行用例和客戶端異常恢復
  • issue上報分析處理

程式碼函式掃描

基於開源框架https://github.com/androguard/androguard提供的apk掃描能力,可對某個支付寶版本apk生成全量的函式介面檔案,目前Android和IOS端均可掃出大量函式介面資料進行測試。

客戶端函式執行模組

使用支付寶動態bundle能力,可在不侵入支付寶客戶端的情況下進行函式介面穩定性測試,測試過程分為以下幾個階段:

1、掃描執行方式

由於全量的介面執行耗時過長,目前支援版本差異執行,通過計算大版本介面差異進行測試,可快速得到版本間差異介面的穩定性資料,同時支援特定bundle程式碼掃描,可針對某個業務方的程式碼執行掃描檢測,將函式介面穩定性檢測能力輸出到業務方。

2、引數fuzz異常構造

引數異常構造是一個非常專業的課題,目前已經有大量基於機器學習的方案去構造異常資料覆蓋更多程式碼邏輯,目前只是按照經驗和業務語義構造了一組異常測試集,通過排列組合去遍歷函式程式碼,目前1個介面根據引數個數可變異5-10個函式呼叫。從程式碼覆蓋率結果看可以穿透60%介面的邏輯。

3、被測函式呼叫

被測函式呼叫過程主要解決的問題是執行效率,資料記錄和斷點續跑,執行效率依靠介面分組和多執行緒執行解決,函式執行過程嚴格分離保證結果可靠性。在介面掃雷測試過程中會出現大量的閃退和ANR卡死情況導致測試停止,為了自動完成整個測試過程,需要詳細記錄測試過程資料,捕獲閃退時的關鍵資料儲存並輸出到客戶端儲存空間,為斷點續跑提供關鍵資料。

4、閃退資料回放

執行完的測試用例有效儲存到本地,程式支援直接回放異常用例驗證程式碼修復後效果。

3 自動化指令碼執行

自動化指令碼的目的是喚起客戶端執行測試用例,並且能夠檢測到客戶端的異常情況,拉取測試資料確定斷點位置,重新拉起客戶端執行,保證整個測試流程可以完全自動化的執行無需人工干預。

總結與展望

支付寶客戶端函式介面掃雷已經執行10多個大版本,雙端累計發現近千條有效問題,並且在工具的迭代中持續降低問題誤報率,提高Fuzz變異能力覆蓋更多風險問題。同時函式介面掃雷的問題已經加入到客戶端攻防演練中,作為真實閃退場景去攻擊業務方。目前函式介面掃雷還有很多不完善的地方,像引數fuzz的智慧變異構造,業務語義引數構造等還有待提高。未來還會繼續補充客戶端穩定性檢測能力,力爭將問題都在發版前解決。

關注我們,每週 3 篇移動技術實踐&乾貨給你思考!