首先，崩潰有幾種情況：

• 閃退
• 提示停止執行
• 無響應

( 不同情況雖然沒有嚴格意義上區分開引起原因，但是都有側重。在之後的工作中，我會實時補充統計。)

1.介面返回值

 ［直接原因］：app無法解析介面返回值／獲取不到要獲取的引數／引數型別不對 導致客戶端程式碼報錯
 ［引起原因］：髒資料／網路問題導致介面超時或漏了陣列元素／前後臺沒有統一引數型別標準／引數名錯誤／實體消失 
 ［解決辦法］：在網路順暢/不順暢情況下抓包，對著api文件一個一個的引數對比，返回值有陣列可以橫向對比，可能是其中某個元素內的某個引數和其他元素內的這個引數有內容不同/型別不同／為空/不存在/規範不同。
 ［測試方法］：首先要從2個角度考慮。1：後臺不要返回這種髒資料，或者有髒資料要進行處理再返回給app。2：app要有一定的容錯性，不能因為一個引數這麼一點小事就導致崩潰（低階bug瞬間升級到致命bug）。所以要從倆邊測試。1：先進行正常的介面測試，保證正常資料返回沒有問題。再通過操作資料庫或其他手段進行構造髒資料，測試伺服器的錯誤處理能力。2：再利用mock或抓包工具，強行修改返回值，測試app端的容錯能力。用指令碼或手動把所有/特定 的引數進行更改，包括 型別/內容長度／為空／刪除掉／不符合規範 等情況來測試app的容錯性和成熟性。
 其次網路問題也是有概率引起崩潰，就是在網路環境很惡劣 或變動頻繁的情況下進行所有介面測試，保證返回值全面完整。觀察介面返回是否有拉下的陣列元素。因為app的超時判定 和伺服器的超時判定是不統一的。可能介面超時要60秒，但是app只等待10秒鐘，10秒沒到就判定失敗了，但這不是導致崩潰的原因。導致崩潰的原因在於伺服器返回超時後（不是無網路，不是關掉wifi或資料流量），介面報什麼http狀態碼，一般是502，app原則上是要對所有介面502都有對應處理和提示，但實際情況是，很多介面有提示不崩潰，更多的介面會崩潰。所以測試的時候要構造特殊環境，來讓所以介面依次超時。方法可以是在抓包工具上打斷點，然後不進行繼續操作，挺著看app最終會不會崩潰。
 實體消失問題導致崩潰，其實是介面規範上的原因，當因為先後操作，頁面未及時重新整理的情況，導致app對一個已經在後臺數據庫抹除的實體或關係進行訪問時，後臺又恰好沒考慮過此情況，導致後臺返回結果不可預料，app又沒有抓取某種異常返回，導致崩潰。測試辦法就是測試點中計劃好所有這種可以操作到消失實體的情況，來進行模擬測試。或者抓包時強行更改請求實體，來達到請求一個不存在實體的場景，觀察伺服器如何處理並返回，app又是否會因此而崩潰。
 

2.記憶體問題

［直接原因］：客戶端app程式碼報錯。
［引起原因］：相容不好／記憶體不足/記憶體洩露造成app開闢記憶體空間失敗/記憶體洩漏。
［解決辦法］：提醒使用者更換手機或關掉後臺其他app程序，崩潰的app要進行全面測試，定位到具體什麼操作導致崩潰。
［測試方法］：先進行相容性測試，用不同的作業系統/手機型號／品牌／系統版本／藍芽版本去執行一些跟寫入讀取有關的功能的用例。用emmagee監控app，看到各種操作後，佔用的記憶體是否超過預期。讓開發規範程式碼，及時釋放掉佔用的儲存空間。手機安裝很多app，然後後臺都開啟，然後再執行自家app，觀察其是否會崩潰頻繁，可以用monkey測試（雖然monkey無法表明到底是什麼原因引起崩潰，但是可以通過 觀察後臺乾淨／後臺執行過多app 這倆種情況下多次測試，看是否因為後臺執行過多app 就導致monkey崩潰概率高。而判斷出大致自家app的生存能力）其他待補充。
 

3.下標越界問題

［直接原因］：客戶端app程式碼報錯。
［引起原因］：需要操作的元素已經消失/程式碼錯誤，超出實體數量/讀取or寫入本地檔案或快取時的IO錯誤
［解決辦法］：調查引起崩潰的具體操作步驟，然後提交開發解決，前端程式碼容錯率需要提高。
［測試方法］：邊界值測試為核心思想，測試正常情況有關數量的功能用例
要進行程式碼review1：保證程式碼沒有錯誤，迴圈中沒有超出實體數量。2：保證程式碼容錯性高，每個迴圈都要有越界異常捕獲並處理。／
要進行手動破壞性測試，1：如刪除本地檔案，比如app要調取本地快取的4張圖片，在app剛要呼叫的時候，已經選擇好的時候，切換到本地檔案管理中，刪掉其中一個，那麼app就會訪問到一個不存在的檔案，會引發越界等程式碼報錯。2：破壞掉這個檔案。那麼app就會讀取的時候發生io錯誤。等情況來進行測試。
 

4.渲染不及時問題

［直接原因］：控制元件生成/呼叫受阻，導致前端app程式碼報錯
［引起原因］：渲染過慢，操作過快，相容性不好
［解決辦法］：讓使用者換手機，或慢點點，重新設計避免使用者連點造成的操作過快，重新設計減輕頁面載入渲染負擔，非同步處理
［測試方法］：對複雜／卡頓頁面進行快速操作來讓本不應該出現在一起的倆個控制元件出現在一起，或用monkey最大速度測試。待補充

5.許可權問題

［直接原因］：客戶端未對無許可權情況處理，導致程式碼報錯
［引起原因］：使用者訪問未獲取到系統相關許可權的功能，客戶端又未對此情況進行處理
［解決辦法］：修改崩潰bug，設計此情況的處理機制，如提示使用者去手動開許可權，或自動退出等情況。
［測試方法］：關掉app所有的系統許可權，然後去訪問所有系統許可權相關的頁面和功能。例如：相簿，照相，定位，開啟wifi，藍芽，gps 等等許可權。

6.第三方問題

［引起原因］：第三方廣告的突然彈出／其他app分享進來和出去／各種第三方app的強行搶鏡（如搶紅包提醒）
［測試方法］：在各個頁面，手動觸發大多數app的 或 本app的外接 廣告來測試。用其他主流app測試分享，或自家app分享出去再回來看是否已經被退出。突然收到其他app的強制提醒。

7.系統高優先順序app問題

［直接原因］：導致自家app突然被掛起或放置後臺
［引起原因］：突然來電話，突然收簡訊，鬧鐘，會議提醒系統原生app等情況
［測試方法］：在各個頁面，功能執行前中後。進行接電話／簡訊來測試。主要測試是否會影響電話/簡訊，電話/簡訊結束後 app是否能恢復到之前的頁面,還是已經閃退被強關了。

8.裝置檢視方向問題

［直接原因］：因橫豎屏導致app崩潰
［解決方法］：重啟app
［測試方法］：
1.先橫，再開app
2.先豎，再開app
3.開app後，各種頁面上，功能前中後，橫屏／豎屏來回切換

9.多語言問題

［直接原因］：各種語言導致崩潰
［測試方法］：
1.先切換成各國語言，再開app進行各種功能用例測試
2.先開app，再來回切換各國語言進行測試

10.其他程式碼錯誤

［直接原因］：客戶端app程式碼錯誤
［引起原因］：各種異常操作，正常操作
［解決辦法］：adb shell logcat抓日誌，後臺檢視崩潰日誌
［測試方法］：執行全部測試用例即可。

11.弱網問題

［直接原因］：客戶端無法解析json返回值
［引起原因］：網路差，json串過長
［解決辦法］：體型使用者換更快網路，客戶端對此操作增加等待時間。介面返回進行非同步處理。增加翻頁功能。
［測試方法］：用抓包工具模擬出弱網環境，包含丟包率，穩定性等元素。然後對介面返回值構造超長資料進行測試。