App穩定性測試


什么是App穩定性測試

App穩定性指移動應用的可靠性。
即在長期各種場景的使用過程中都可以正常使用,不出現或極少出現崩潰(閃退)、無響應等問題。

崩潰、無響應等問題如果頻繁出現,會極大的影響用戶的正常使用。偶現的不穩定問題也會影響用戶的體驗。

因此在App每次發版前,對App穩定性進行測試和評估是非常重要的

影響App穩定性的因素

導致App崩潰的常見原因

  • 內存管理問題
    • App所需內存超過設備限制(如可用內存過低時),導致App崩潰閃退;
    • App內存泄漏,耗盡設備全部內存導致整個系統崩潰;
    • App內存越界,使用了非授權的內存位置導致App崩潰;
  • 程序邏輯錯誤
    • 數組越界,如負數索引、超過數組長度的索引
    • 堆棧溢出,如堆棧區緩沖區被填滿,堆棧空時取數據等
    • 並發操作,如並發時調用了一個已釋放的指針
    • 邏輯錯誤,如0除等問題
  • 未處理等中斷及異常
    • App在使用過程中面臨很多中斷、如切后台、接聽電話、切換網絡、斷網以及用戶的一些非預期操作,如果處理不當也可能引起崩潰
  • 網絡因素:
    • 比如網速欠佳,無法達到app所需的快速響應時間,導致App崩潰或者是不同網絡的切換也可能會影響app的穩定性

導致App無響應的常見原因

  • 主線程執行了耗時操作,比如數據庫操作或網絡編程
  • 其他進程(就是其他程序)占用CPU導致本進程得不到CPU時間片,比如其他進程的頻繁讀寫操作可能會導致這個問題。

細分的話,導致無響應的原因有如下幾點:

  • 耗時的網絡訪問
  • 大量的數據讀寫
  • 數據庫操作
  • 硬件操作(比如攝像頭)
  • 其他線程持有鎖,導致主線程等待超時
  • 其它線程終止或崩潰導致主線程一直等待

導致iOS應用奔潰的常見問題

  • 循環引用導致的內存泄漏
  • Delegate、NSTimer、Block的使用不當都可能出現循環引用導致內存泄漏
  • NSNotification不斷添加而不移除觀察者以及不斷重復的動畫也會導致內存泄漏
  • 大量數據加載導致的內存告警: 大數據量的下載、大文件的拷貝以及應用在使用較大內存空間時也很容易因內存告警而出現崩潰現象

如何衡量和確保App的穩定性

App的穩定性可以通過1-崩潰率來衡量,崩潰率約小,穩定性越好。

線下測試穩定性衡量方法

崩潰率 = 崩潰次數 / 總操作次數 * 100% 

線上測試穩定性衡量方法

崩潰率 = 一段時間內崩潰用戶數 / 一段時間內總用戶數 * 100% 

如何檢查和測試App的穩定性

App上線前

  • Code Review及靜態代碼檢查:大部分App穩定性問題是代碼邏輯造成的,通過Code Review及靜態代碼檢查可以提取發現一些循環引用、以及潛在的Bug。基於Objective-C的iOS應用常用的靜態代碼檢查工具有Clang Static Analyzer、OCLint、Infer等
  • App性能測試:在App測試過程中監控內存、CPU、FPS、電量、網絡流量等指標,及時發現內存泄漏問題。
  • 異常測試:對異常中斷、切后台、切App、弱網、斷網、網絡變化、更改系統時間、內存不足、電量低等情況進行測試,檢查App是否有崩潰現象
  • Monkey測試:Monkey測試是只使用工具生成快速的一系列隨機操作,通過大量的隨機操作來驗證App的穩定性。如使用開源工具Fastmonkey對iOS應用進行穩定性測試。
  • 反復測試:即對一些業務場景進行反復對測試,如反復進出教室、反復切班、反復發送選項卡等操作來測試App的穩定性。可以借助Appium等自動化工具進行執行

App上線后

  • App崩潰監控:統計崩潰率並手機崩潰日志。
  • App性能監控:采集上報客戶端內存、CPU、網絡流量等數據及時發現應該內存泄漏問題
  • 用戶行為監控:埋點采集用戶行為數據,為復現及定位崩潰問題提供數據


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM