近期基於Testin 大資料發現，App 崩潰是最常見的Bug ，這直接的影響就是使用者體驗，是造成使用者流失的根本原因，也是咱們測試同學非常頭疼的問題,如果上線前不能將這些問題發現....

AD：

在這裡為大家整理了一些通用可能觸發崩潰的使用以及操作場景，希望可以幫助大家補充完善基礎用例庫!

一些通用的觸發移動App 崩潰的測試場景，如下：

驗證在有不同的螢幕解析度，作業系統和運營商的多個裝置上的App 行為。

用新發布的作業系統版本驗證App 的行為。

驗證在如隧道，電梯等網路質量突然改變的環境中的App 行為。

通過手動網路從蜂窩更改到Wi-Fi ，或反過來，驗證App 行為。

驗證在沒有網路的環境中的App 行為。

驗證來電/簡訊和裝置特定的警報(如警報和通知)時的App 行為。

通過改變裝置的方向，以不同的檢視模式，驗證App 行為。

驗證裝置記憶體不足時的App 行為。

通過用測試工具施載入荷驗證App 行為。

用不同的支援語言驗證App 行為。

當然還有些崩潰主要來自於移動裝置本身較為複雜的環境比如：

環境(大量的裝置，各種移動OSs，適應頻繁OSs 變化) 。

裝置(觸控式和非觸控式裝置，有限的記憶體容量，電池耗電量) 。

網路(不同的網路和運營商，在不好或無網路的情況下的App 行為，離線支援) 。

可用性(方向，觸控，多觸控，縮放，分頁和導航的侷限性，各種干擾，如來電，來電簡訊鬧鐘，和低電量警報) 。

為大家總結了出現崩潰最主要的原因：

裝置碎片化：由於裝置極具多樣性，App 在不同的裝置上可能有表現不同。

頻寬限制：頻寬不佳的網路對App 所需的快速響應時間可能不夠。

網路的變化：不同網路間的切換可能會影響App 的穩定性。

記憶體管理：可用記憶體過低，或非授權的記憶體位置的使用可能會導致App 失敗。

使用者過多：連線數量過多可能會導致App 崩潰。

程式碼錯誤：沒有經過測試的新功能，可能會導致App 在生產環境中失敗。

第三方服務：廣告或彈出螢幕可能會導致App 崩潰。

結語：

上述總結的內容僅算拋磚引玉製作，同學們還是需要儘可能多的去積累以及更新迭代貴司的

用例庫，最好在開發週期中就可以發現可能發現崩潰的bug，將使用者體驗發揮到極致！