如何將Crash率從2.2%降至0.2%

天天P圖作為圖像處理類APP，內部集成了很多功能，包括濾鏡、人臉檢測、美白、磨皮、美妝、拼圖、相機等，而且這些功能多是用底層算法依靠GPU實現，如何保證這些功能在眾廠商生產的Android手機上正常高效運行，對於測試來說是一項極具挑戰的任務。本文主要針對Android天天P圖業務介紹我們在降低Crash率方面所做的工作，當然這裡也離不開開發同學們的大力支持。

一、Android天天P圖業務介紹

1.Android天天P圖功能模塊數據及潛在測試挑戰

Android天天P圖內部共9個大模塊，共包含近200個子功能，其中各模塊內部子功能數目如下表所示：

其中：<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4NCjxwPjEpw8C7r9XVxqy1xMLLvrUvwu3I/L/Lo6zDwMjdw8DXsbXExKXGpC/DwLDXL8nP17G1yLmmxNy++dDo0qrTw7W9TmF0aXZlsuO1xMvjt6i/4qOsvt/T0LGst6K117LjU0lHU0VHVqGiU0VHQUJSVLXIy+O3qMDgPGEgaHJlZj0="http://bugly.qq.com/">crash問題的風險，但此類問題很難在單一手機上通過測試數量有限的圖片發現，需要考慮如何在有限的機型及時間的情況下，盡可能的暴露此類問題；

2)自拍相機模塊由於需要適配各種定制的Android的平台設備，同樣存在兼容性Crash的爆發風險，自拍相機的兼容性問題對測試人員來說是一項很具挑戰的任務；

3)Android天天P圖作為圖像處理類軟件，美容美妝/故事拼圖等模塊對內存的要求較為苛刻，需要預防OOM的風險，測試需要知道如何判斷鑒別P圖內存使用效率及釋放時機是否高效合理；

2.Android天天P圖各版本Crash率趨勢圖

面對如上風險，我們再來看一下Android各版本的Crash率情況

從上表可以看出，產品問世初期的兩個版本Crash率較高，但在隨後的版本中，在不斷增加新功能的同時，Android天天P圖的Crash率整體呈下降趨勢，由最初版本發布的2.2%降低到目前的0.24%。

（小優注：因數據涉及產品隱私，小優打了馬賽克，還請各位看官見諒）

二、問題分析與解決策略制定

1.問題分析

1）存量問題分析

Android天天P圖接入了RDM（小優注：騰訊內部研發管理工具）異常上報和Bugly異常上報用於觀察外網用戶遇到的Crash問題，這裡先看下版本發布初期上報的主要問題：

下圖為V2.0版本上報的TOP10 Crash問題

從上圖可以可到，Crash主要分如下幾類：

–lRuntimeException

–lSIGSEGV/SIGBUS

–lNullPointerException(NPE)

其中RuntimeException需要具體問題具體分析，SIGSEGV/SIGBUS類的問題屬於底層算法類問題，NullPointer類的問題為代碼保護不規范類問題。

2)新增問題預防

為了降低Crash率，不只是要解決存量遺留的問題，同時需要關注新增問題的預防，保證無突出嚴重的新增Crash問題。

2.策略制定

1)分層測試

天天P圖內部的很多功能使用底層算法庫，如人臉識別、五官定位、彩妝上妝等。鑒於圖片和環境的多樣性，以及在上層無法驗證部分異常場景，測試團隊將APP Java層和Native層代碼分開測試的策略。

針對算法層的測試使得測試更具針對性，覆蓋的場景更多，同時使用自動化測試工具也使得在圖片多樣性覆蓋上的測試效率更高。下圖為部分P圖SDK測試圖片集。

2)存量問題解決

天天P圖測試團隊持續關注每個版本外發後的異常上報，篩選出其中較嚴重的10-20個Crash問題，分析提單跟進，在下一版本中進行解決，截止當前版本，測試配合開發共修復超過100個Crash問題，有效保證了Crash率的降低。

以下數據為V3.3版本外發後Crash的分布分析，在V3.4版本針對性解決部分Crash問題後，Crash率降低了1個千分點。

從統計數據上看，主要的Crash問題集中在自拍相機模塊，測試調整NewMonkey運行參數，針對自拍相機進行集中測試，

3)新增問題預防

由上面的分析，我們確定主要的Crash集中在底層算法、NullPointer和其他Java層異常導致，如何在版本測試初期盡快發現這類問題，我們主要采用Crash問題分析總結反饋補充測試用例、引入改造現有工具等方式完成，具體可參考第三部分；

4)Crash問題分析總結補充測試場景

每一個版本外發後，天天P圖測試團隊會總結分析前一版本系統測試中及bugly異常上報發現的Crash問題，歸類發生場景，分析誘因，最後反補到測試用例中，截止目前，共補充測試用例34條，總結文檔11篇。

三、解決方案實施

接入和改造的工具發現Crash問題數目一覽表

1.NewMonkey接入改造：讓嚴重Crash無處藏身

1）引入背景

終端產品需要迭代快，而外發前一個阻礙發布的問題是發現嚴重的Crash問題，在這個時間修改Bug一是可能會引入其他問題，同時也極有可能導致外發延期，測試團隊需要考慮如何避免這種問題，保證產品按時高效發布。

2)NewMonkey接入改造

NewMonkey是社交網絡質量部測試開發團隊以Android Monkey為基礎，訂制的一個更高效的自動化穩定性測試工具，相較於Monkey，NewMonkey的測試更具有平均性，能夠覆蓋APP內更多的Activity。NewMonkey運行於測試開發團隊維護的NewMonkey Wall上，接入後測試手機會每天定時拉取最新RDM安裝包進行測試，這樣能夠保證今早發現版本中存在的嚴重Crash問題。

但鑒於天天P圖APP內操作的特殊性，天天P圖測試團隊針對NewMonkey的操作封裝了更多適用於天天P圖的測試操作，如：塗抹屏幕、滑動滑竿等，同時結合天天P圖業務模塊使用的分布，通過配置文件修改測試Blacklist文件使得定制後的NewMonkey運行更高效，如下是改造前後NewMonkey發現Crash問題的相關數據：

截止目前，本地運行的NewMonkey共在天天P圖項目中發現148個Crash問題，有效的保證了外發版本質量。

（小優注：NewMonkey系騰訊內部研發的測試工具，據小優所知暫不支持接入外部app，但需要相關工具介紹文檔的童鞋們可以在公眾賬號留言哦。

插播廣告一則：有需求的童鞋可以試試優測的自動化測試，實現原理一致，效果更優哦 [手動驕傲臉]）

2.Coverity/CodeDog為代碼保駕護航

1)引入背景

正如第二部分問題分析中介紹的V2.0版本外發後的存量問題分析，版本中存在的Crash類問題有一部分為NullPointerException，根據統計數據，Android天天P圖各個版本測試中發現的NullPointerException問題大部分都在10個以上，而NPE的問題可以通過代碼靜態掃描進行預防。

2)Coverity/CodeDog接入與自動提單實現

代碼掃描工具很多，天天P圖測試團隊采用CodeDog和Coverity進行空指針檢查。CodeDog是社交網絡質量部開發的一款集成工具，工具內部集成了findBugs，Coverity等工具，目前天天P圖接入的CodeDog服務包含findBugs、安裝包大小檢查等，但鑒於資源限制，不包含Coverity，測試團隊單獨使用了MIG的Coverity進行掃描，由於MIG的Coverity不支持自動提單，測試團隊在前人提供的基礎提單腳本上進行了優化去重，配合findBugs發現空指針問題。

Coverity共發現96個NPE問題，各個版本發現的空指針數據如下：

CodeDog共發現163個NPE問題，各個版本發現的問題數據如下：

從數據上看，兩個工具各有互補，但觀察具體的提單可以發現，兩個工具之間有一定交集，即提有重復Bug單，但也存在彼此都未發現的Bug。測試團隊對自動提單工具進行了一定優化，減少了重復提單問題。

（小優注：同上，CodeDog系騰訊內部研發的測試工具，需要相關工具介紹文檔的童鞋們可以在公眾號中留言哦。）

3.LeakCanary 內存洩露檢測利器

1)引入背景

天天P圖作為圖像類處理APP，對內存使用要求很苛刻，大量的圖片資源加載導致即便微小的內存洩露也有引發OOM的風險，從異常上報看，版本發布初期OOM問題比較突出。

2)LeakCanary接入

LeakCanary是Square開源發布的一款內存洩露檢測工具，接入簡單，使用方便，在功能測試中便可以發現APP內隱藏的部分內存洩露問題，開發人員在V2.6版本接入了LeakCanary，目前Canary共發現了27個內存洩露問題。

接入LeakCanary後，Android天天P圖的OOM問題呈逐步減少狀態，相關數據如下：

LeakCanary問題報告詳情：

4.騰訊優測雲測試平台 發現機型兼容性問題

1)引入背景

Android平台測試最復雜的便是機型兼容性測試，Android天天P圖外發後有時候會遇到個別機型頻繁上報Crash，由於本地機型限制，及考慮到測試周期，測試團隊需要一個自動化的機型兼容性測試平台/團隊來解決這類Crash問題；

2)引入騰訊優測

騰訊優測是（utest.qq.com）一個自動化測試平台，MIG的產品，主要工作原理是維護大量測試機，進行自動化測試。利用優測的自動化測試Android天天P圖共發現64個Crash異常問題，版本外發前進行一次測試，可基本保證外發無嚴重漏測Crash問題。

除了用線上的免費測試功能，去年開始Android天天P圖開始使用優測的vip測試服務，每個版本做top50機型的核心遍歷測試和一些專項測試。

3）優測雲手機

優測線上有一個雲手機功能，可以遠程操控真機（不是模擬器），用戶反饋哪個機型有bug，手裡又沒有對應機型的話，可以在優測直接在線復現，大部分熱門機型都有，對測試同學來說挺實用。

5.Crash問題分析-測試場景補充

借助工具和功能測試發現的Crash問題只是第一步，我們需要從發現的Crash問題中尋找共性及復現場景，進而補充到功能測試用例中，避免此類問題再度發生。

Android天天P圖經過近幾個版本Crash分析積累，共補充測試用例34條，總結相關文檔11篇。

1)舉例1-Activity與Animation使用注意事項

問題描述：

天天P圖分享界面有一個保存動畫，如果在動畫未完成時返回主界面，天天P圖發生閃退；

問題分析：

為驗證Activity的生命周期是否影響Animation的播放，在這裡做了一個Demo，Demo裡包含兩個Activity: Main Activity與Animation Activity。其中Animation Activity由Main Activity呼起，在Animation Activity中點擊Button播放動畫，通過log形式輸出各個階段的時間戳。部分代碼如下：

測試步驟如下：

1)在Main Activity中啟動Animation Activity;

2)在Animation Activity中點擊Button啟動動畫；

3)在動畫播放期間點擊返回按鈕返回至Main Activity;

測試結果：

15:47:32.863: V/com.tencent.test(21258):Animation Start

15:47:40.822：V/com.tencent.test(21258):Animation Activity Destroyed.

15:48:02.858：V/com.tencent.test(21258):Animation End

程序代碼中設置動畫時間為30s，從log可看出實際Animation start與Animation End時間間隔為30s。

測試用例補充：

在動畫未完成的時候，返回上一級或進入下一級

2)舉例2-Activity數據狀態恢復

問題描述：

在使用P圖美化完自己的照片後進入分享頁面，此時可供用戶選擇的有如下三種操作

1）一直點返回鍵直至退出程序；

2）點擊右上角按鈕回到主頁面使用其他功能；

3）使用Home鍵將進程切換到後台；

問題發生在使用第三種操作，在切換到後台很長一段時間後，再次啟動桌面APP時，Android會呈現APP上次退出的Activity界面，也即分享界面，此時，若點擊左上角返回按鈕，P圖並沒有返回上一個Activity，而是發生了crash。

問題分析：

首先對比操作1和操作3，兩者的不同之處在於操作1是直接退出APP，而操作3是先將APP置於後台一段時間後再嘗試退出。所以問題的關鍵在於APP在被置於後台時，Android對我們的APP做了什麼。

Android為提升用戶體驗，系統通過ActivityManager為每一個APP都維護了一個Activity棧，APP第一次被啟動時，Main Activity被壓入棧（如P圖的主界面），當用戶點擊使用魔法摳圖功能時，圖庫預覽Activity被壓入棧，此時若使用返回鍵，棧頂部的Activity將被彈出並銷毀，返回主界面Activity，如下圖。在本案例中，我們是在點擊返回按鈕回到上一層Activity時Crash的，所以首先懷疑的是在構建上一層Activity時失敗。

從Activity生命周期以及其基本狀態圖可知，當APP被切換到後台時，Activity變為Stopped狀態，但當用戶在後續操作中啟動多個占內存較多的APP時，P圖會被系統默默殺掉，流程圖如下。

這裡需要注意的是，Android在後台殺死進程和調用任務管理器殺死進程有很大不同：

l調用任務管理器殺死進程：系統中有關APP上次啟動的全部狀態被清除，包括Activity棧信息，再次啟動APP時進入APP主Activity;

l系統在後台殺死進程：Android首先調用onSaveInstanceState()保存Activity的一些狀態信息，再次啟動APP時返回到上次切換APP前的Activity;

進程在後台被殺死的場景可以通過使用DDMS中的stop按鈕模擬。當使用P圖美化完照片進入分享界面後，使用Home切換APP至後台，啟動DDMS，選中P圖進程使用stop按鈕，此時由ActivityManager維護的該APP的Activity棧信息將被全部清空。在此時，若使用返回鍵，Android將重新調用前一Activity的onCreate()創建該Activity，但在這裡必須傳遞給該函數一個Bundle信息，用來恢復Activity顯示內容。而開發在此處未使用Bundle信息來恢復前一Activity，這在大多數情況下都是可以正常工作的，因為多數情況下該Activity可以在棧中被找到，尤其是在內存較大的手機，但當Activity棧被清空時，問題便顯現出來。所以問題的根源最終被定位為Activity的onCreate()函數實現。

測試用例補充：

在用戶可能直接切換至後台的場景，使用DDMS或Android Studio裡的模擬系統殺死進程工具殺掉進程，再次啟動APP後使用返回鍵等操作。

1)舉例3-IndexOutOfBounds類問題分析

問題描述：

在使用動效拍最後一個濾鏡後，點擊切換模式選擇，發生閃退。

問題分析：

回想Crash發生時的具體場景，Crash多發生在選擇一個濾鏡後，再點擊模式切換按鈕。再參考堆棧信息頭部的相關信息，Crash的主要誘因在於索引position位置在39的元素時出錯，從這裡可以得到一個重要信息：一個包含至少三十個元素的ViewHolder在進行索引時出錯，再查看自拍相機裡所有的子功能，只有濾鏡選擇功能模塊的元素有42個，因此，將定位范圍縮小到濾鏡選擇子功能。

結合初步縮小的定位范圍，查看本版本與之相關的新需求，與之相關的只有在模式切換時需要隱藏濾鏡子模塊中的兩個子Icon，到這裡很自然的會想到，由於隱藏兩個子Icon導致Index索引發生變更，導致末尾的兩個Index失效，這裡剩下的就是驗證了。

由第一部分得出的推斷，是當切換到動效拍模式後，濾鏡模塊中的子Icon隱藏後會引發Crash，因此，首先我們會選擇濾鏡模塊中位於第39位的濾鏡素材，然後切換動效拍模式。為了觸發濾鏡的索引，需要再次點擊模式切換按鈕（使用濾鏡），此時APP發生Crash，log日志與上報一致，問題得以重現。

測試用例補充：

當ViewHolder內部數據數目發生變化時，應該關注Index更新的問題，針對邊界值素材及相關功能進行測試；

三、總結與規劃

一切測試工作的開展源於對服務業務的理解，以及對當前業務痛點的把握，分析問題，制定方案，通過接入或開發改造工具幫我們提高效率，解決問題。問題的解決並不是最終的目的，我們需要從問題的解決歸納總結出測試的疏漏點，指導我們繼續下一次的測試工作開展。（寫得太好了，小優忍不住點個贊！）

Android天天P圖業務之後的穩定性測試工作開展依然會立於當前業務痛點，通過解決留存問題，接入和改造成熟的測試工具來預防新問題，不斷提高產品質量。