app 崩潰測試 （轉：CSDN 我去熱飯）

首先，崩潰有幾種狀況：

• 閃退
• 提示中止運行
• 無響應

( 不一樣狀況雖然沒有嚴格意義上區分開引發緣由，可是都有側重。在以後的工做中，我會實時補充統計。)

 

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串過長
［解決辦法］：體型用戶換更快網絡，客戶端對此操做增長等待時間。接口返回進行異步處理。增長翻頁功能。
［測試方法］：用抓包工具模擬出弱網環境，包含丟包率，穩定性等元素。而後對接口返回值構造超長數據進行測試。