APP崩潰測試

　　移動App測試與傳統臺式機 測試相比有必定的複雜性。這些複雜性能夠被分類爲： 
　　　　環境（大量的設備，各類移動OSs，適應頻繁OSs變化） 。 
　　　　設備（觸摸式和非觸摸式設備，有限的內存容量，電池耗電量） 。 
　　　　網絡（不一樣的網絡和運營商，在很差或無網絡的狀況下的App行爲，離線支持） 。 
　　　　可用性（方向，觸摸，多觸摸，縮放，分頁和導航的侷限性，各類干擾，如來電，來電短信，鬧鐘，和低電量警報） 。 
　　全部這些手機專有的複雜性須要新的針對移動App測試的測試用例設計方案。

---

　　根據調查的結果，移動App崩潰是最多見的移動App Bug ，這是預料中的結果，由於很容易發現一個移動App崩潰。 Android  OS上一個寫着「強制關閉錯誤」的彈出窗口跳上屏幕；當發生崩潰時，iOS中App屏幕忽然消失消失。最壞的狀況下，App崩潰可能會致使系統故障，操做 系統崩潰。

---

移動App崩潰緣由 
　　爲何移動App常常崩潰？App崩潰有幾個緣由：從平臺或環境到開發問題。 
一些崩潰緣由（排名不分前後） ： 
　　設備碎片化：因爲設備極具多樣性，App在不一樣的設備上可能有表現不一樣。 
　　帶寬限制：帶寬不佳的網絡對App所需的快速響應時間可能不夠。 
　　網絡的變化：不一樣網絡間的切換可能會影響App的穩定性。 
　　內存管理：可用內存太低，或非受權的內存位置的使用可能會致使App失敗。 
　　用戶過多：鏈接數量過多可能會致使App崩潰。 
　　代碼錯誤：沒有通過測試的新功能，可能會致使App在生產環境中失敗。 
　　第三方服務：廣告或彈出屏幕可能會致使App崩潰。

移動App崩潰的測試用例設計 

　　測試用例是移動測試最重要部分之一，準備和執行預先定義的針對移動App崩潰的測試用例將簡化和加速移動App崩潰的測試。 
　　一些通用的觸發移動App崩潰的測試場景，以下： 
　　　　1 驗證在有不一樣的屏幕分辨率， 操做系統 和運營商的多個設備上的App行爲。 
　　　　2 用新發布的操做系統版本驗證App的行爲。 
　　　　3 驗證在如隧道，電梯等網絡質量忽然改變的環境中的App行爲。 
　　　　4 經過手動網絡從蜂窩更改到Wi-Fi ，或反過來，驗證App行爲。 
　　　　5 驗證在沒有網絡的環境中的App行爲。 
　　　　6 驗證來電/短信和設備特定的警報（如警報和通知）時的App行爲。 
　　　　7 經過改變設備的方向，以不一樣的視圖模式，驗證App行爲。 
　　　　8 驗證設備內存不足時的App行爲。 
　　　　9 經過用測試工具施加載荷驗證App行爲。 
　　　　10 用不一樣的支持語言驗證App行爲。 
　　顯然，還會有更多的致使App崩潰的App特定場景

 

幾種常見的類型設計方法

 

1. 網絡異常

　　一般在網絡異常的狀況下，客戶端發出的請求，沒有在必定時間內獲得恢復，可是通常都會有一個超時的概念，若是程序在沒有處理好的狀況下，超時以後沒法處理程序的邏輯，則常常會出現Crash。這種問題在網絡差的狀況下，常常出現，好比瀏覽論壇的時候，正常網絡下訪問無問題，在網絡極其差的狀況下，常常性的崩潰就是屬於這個問題。因此，測試的過程當中，我會經過拔路由器的網線的方式來進行測試，提交一個接口請求以後，當即拔去路由器的線。這樣數據沒法正常返回到客戶端，等待超時以後，看前端的處理方式。若是處理很差的狀況下，就會出現崩潰發生。

 

2. 內存問題 

　　一般在開發程序的時候，內存的泄露或者沒有正常回收，形成程序隨着操做愈來愈多，佔用的內存愈來愈大，最終致使崩潰的發生。

測試的過程當中，這類問題會比較麻煩，總的來講，一款內存小的手機在測試的過程當中是必須的，我會選擇一款256M內存，Android 2.3的機器來進行測試。同時會使用Emmagee的小軟件進行檢測，固然有一個合理的測試用例也是必須的。根據測試用例來正常跑軟件，測試結束以後獲得一張關於內存使用的圖標，慢慢進行分析，對照測試用力進行分析查看是否能發現內存泄露的操做，若是有可疑的操做就要對其進行重複性測試，仍是使用Emmagee的軟件，不斷的檢測一個點。知道確認內存泄露的功能模塊。高級的測試還會使用DDMS進行查看，原理基本相同，具體方法能夠查看網上寫的邏輯。

　　總的來講，內存泄露對於測試人員，特別是手動測試人員比較困難，可是不是沒有方法來進行。

 

3. 接口返回值錯誤

　　一般會遇到接口返回值和預期返回值不相同的問題，若是App前端處理不太周全的狀況下，會出現程序崩潰。

　　在遇到這樣的問題的時候，通常會採用協調前臺和後臺之間的信息來處理。根據公司的經驗，通常後臺傳輸數據都須要本身的檢測程序來查看具體的接口傳輸數據，有了合理的工具合理的分析平臺才能處理的更好，在此感謝Don， Jason的努力，在能查看接口傳輸數據以後，確實對測試的工做產生了正面的影響。

 

4. 手機特定類型錯誤

　　由於安卓手機畢竟有着衆多的品牌和類型，軟件在運行的過程當中不免會出現功能和某些測試機器，或者不一樣UI上出現崩潰的問題。

　　目前沒有太好的方案來解決，通常會採用Testin自動化平臺運行App，從測試中發現的問題進行斷定是否出現的問題時固定能夠重現的。彙總的說，其實Umeng平臺仍是提供了良好的方式來處理這些崩潰問題，在友盟捕捉到的錯誤日誌中分析，能夠不斷的提高產品質量。不是作廣告，只是告訴你們明智的敏捷開發團隊必定會採用這樣輕量級的平臺來提高品質。

 

5. 渲染圖片出現的問題

　　由於在Android系統在渲染圖片的時候須要加載到內存中，因此App上的一些圖若是過大，能夠形成崩潰事件的發生。

　　在系統版本爲2.3 一下的手機上容易出現，其實這也是與手機的性能相關的，在2.3如下的時候，一般手機的內存都比較小 256兆 和 512的內存上常常會出現相似的狀況。