首先，崩潰有幾種情況：
- 閃退
- 提示停止運行
- 無響應
崩潰原因：
1.接口返回值
直接原因：
app無法解析接口返回值 導致客戶端代碼報錯
- 獲取不到要獲取的參數
- 參數類型不對
引起原因：
- 髒數據
- 網絡問題導致接口超時或漏了數組元素
- 前後臺沒有統一參數類型標準
- 參數名錯誤
- 實體消失
解決辦法：
在網絡順暢/不順暢情況下抓包，對着api文檔一個一個的參數對比，返回值有數組可以橫向對比，可能是其中某個元素內的某個參數和其他元素內的這個參數有內容不同/類型不同／爲空/不存在/規範不同。
測試方法：
首先要從2個角度考慮。
- 後臺不要返回這種髒數據，或者有髒數據要進行處理再返回給app。
- app要有一定的容錯性，不能因爲一個參數這麼一點小事就導致崩潰（低級bug瞬間升級到致命bug）。
所以要從倆邊測試。
- 先進行正常的接口測試，保證正常數據返回沒有問題。再通過操作數據庫或其他手段進行構造髒數據，測試服務器的錯誤處理能力。
- 再利用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錯誤
解決辦法：
調查引起崩潰的具體操作步驟，然後提交開發解決，前端代碼容錯率需要提高。
測試方法：
邊界值測試爲核心思想，測試正常情況有關數量的功能用例
要進行代碼review
1：保證代碼沒有錯誤，循環中沒有超出實體數量。
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
［測試方法］：
1.先橫，再開app
2.先豎，再開app
3.開app後，各種頁面上，功能前中後，橫屏／豎屏來回切換
8.系統高優先級app問題
［直接原因］：導致自家app突然被掛起或放置後臺
［引起原因］：突然來電話，突然收短信，鬧鐘，會議提醒系統原生app等情況
［測試方法］：在各個頁面，功能運行前中後。進行接電話／短信來測試。主要測試是否會影響電話/短信，電話/短信結束後 app是否能恢復到之前的頁面,還是已經閃退被強關了。
9.多語言問題
［直接原因］：各種語言導致崩潰
［測試方法］：
1.先切換成各國語言，再開app進行各種功能用例測試
2.先開app，再來回切換各國語言進行測試
10.其他代碼錯誤
［直接原因］：客戶端app代碼錯誤
［引起原因］：各種異常操作，正常操作
［解決辦法］：adb shell logcat抓日誌，後臺查看崩潰日誌
［測試方法］：執行全部測試用例即可。
11.弱網問題
［直接原因］：客戶端無法解析json返回值
［引起原因］：網絡差，json串過長
［解決辦法］：體型用戶換更快網絡，客戶端對此操作增加等待時間。接口返回進行異步處理。增加翻頁功能。
［測試方法］：用抓包工具模擬出弱網環境，包含丟包率，穩定性等元素。然後對接口返回值構造超長數據進行測試。