苦於APP專項測試的專業性和複雜性,99%的測試人員很迷茫

特斯汀軟件測試 發佈 2022-05-26T03:32:48.137500+00:00

說起APP測試,大部分人都感覺簡單的很,手機上裝個APP,然後點點點就行了。其實這只是APP的功能測試,在移動網際網路飛快發展的今天,僅僅測試APP的功能是遠遠不夠的。圖片你在使用APP時,有沒有遇到以下問題呢?

說起APP測試,大部分人都感覺簡單的很,手機上裝個APP,然後點點點就行了。其實這只是APP的功能測試,在移動網際網路飛快發展的今天,僅僅測試APP的功能是遠遠不夠的。

圖片

你在使用APP時,有沒有遇到以下問題呢?

流量使用過多

耗電量多

某些設備終端機型上出現閃退,運行時突然崩潰,數據丟失等問題

弱網環境下無法使用

CPU消耗過高,發熱嚴重

程序出現卡頓、無響應

後台自動運行等各種各樣的問題

其實這都屬於APP的專項測試,隨著用戶群體的增多,市場競爭的壓力,專項測試越來越受重視。但是苦於APP專項測試的專業性和複雜性,很多同學想學習根本無從下手。

今天就來說下移動端專項測試到底怎麼做?文末附測試移動端測試用例


專項測試測什麼?

資源類性能測試

CPU占用

內存占用/內存泄漏

低資源環境表現

弱網絡測試


速度類性能測試

FPS測試

端到端業務延時

速度分析:客戶端+網絡+伺服器


穩定性測試

MTTF

Monkey test


兼容性測試

Android版本

解析度

硬體配置


應用定製測試項

協議測試、數據冗餘比、成功率


專項測試怎麼做?



1.需求評審階段

網絡風險

斷網重連,斷點續傳邏輯

是否會產生大流量,流量合理性(流量消耗和發送的文件大小是否近似)

請求-響應來回次數較多,是否會增加失敗率

協議必須有壓縮策略

有沒有緩存機制


UI風險

存在IO操作,例如保存,導入,導出,發送,上傳,當遇到大數據時是否有加載過程

元素或動態/可變元素過多過複雜,是否會造成界面卡頓和CPU長期偏高(如LISTVIEW複雜格式或有動態圖)

元素加載時機(如滑動列表時,頭像加載的時機)


電量/CPU風險

地理位置相關邏輯,檢測邏輯(如人臉識別、貼耳檢測),

後台服務(如tcp心跳邏輯),

音視頻相關


OOM風險

緩存策略,加載大數據策略(如拉取查看大圖bitmap)

GC策略


兼容性風險

較新的系統特性

通過系統API/系統資料庫獲取數據

硬體相關(攝像頭,屏幕觸碰效果,聲音大小,gps)


2.新功能階段

原則:發現問題為先,兼顧數據沉澱

事前能做的:

可對比的歷史場景數據(注意再測試的設備/環境一致性)

缺乏對比的歷史數據先補充,沉澱現有數據

用MonkeyRunner簡單的自動化腳本,可以讓資源監控的曲線的趨勢更加明顯

測試環境準備:如測試號碼,手機選型,測試數據預先構造等等

流量指標可以先測

發現專項問題,請直接先提單

功能穩定後,再關注FPS,內存,CPU等

關注FPS:動畫效果

例如,列表滾動,展示內容的滾動

關注內存,CPU,線程:可重複執行的動作

例如,切換帳號,界面打開關閉

關注流量,耗時,成功率:網絡相關操作

例如,發送消息,發送圖片,下載數據

關注電量/CPU:持續的動作和用戶高頻率的操作

例如,放置後台,發送心跳包

關注速度:界面切換,內容加載

例如,啟動速度

資源類測試

主要測試場景:

  • 測試場景是和用戶密切相關的:要包含用戶實際的使用場景、特性;
  • 高資源消耗場景:加載大數據、重複性高的操作;
  • 產品的關鍵路徑:更多的考慮產品的特性,制定明確的關鍵路徑;
  • 需要嘗試/探索測試的點:專項測試中的資源類和速度類測試包括發現相關問題以及性能的優化兩方面;

測試工具:

1) CPU、內存、流量:AndroidResMonitor(python腳本工具);

2) 電量消耗:PowerMonitor(硬體設備檢測),手機管理軟體,如android助手等

http://www.infoq.com/cn/articles/how-subject-test-works


Android

痛點工具名推薦原因工具類別落地優先級落地成本


卡頓

Chrome for android開源性能測試工具(surface_stats.py)裡面已經涵蓋了FPS和janky採集的方法,用python寫的命令行,簡單直接地跟自動化測試結合。發現P0低


卡上報(AnimationPerfMon.java)在空間落地卡上報,跟處理crash一樣,通過堆棧快速定位解決問題, 補充ANR的缺失發現+定位P0中


聽雲/OneAPM基於UIThread/主線程的監控,都有不錯的卡頓的發現能力。但是因為沒有獲取堆棧,而只有簡單的方法名和activity,所以對於複雜的軟體定位稍微困難。發現+定位(弱)P1低


Fresco通過內存緩存的優化達到流暢的圖片及列表展示性能解決P1低


Realm通過更優秀的I/O性能,降低APP對持久化數據讀寫的損耗,從而提升交互性能。可替代sqlite。解決P1中


閃退

LeakCanary高效率發現大部分內存泄漏導致的OOM。發現+定位P0低


Bugly/聽雲/OneAPM/TestinCRASH監控的能力大同小異,都能對數據上報的統計分析,清晰現網情況,用戶痛點。但我會推薦騰訊的BUGLY, 因為ANR, CRASH都能提供比較足夠的信息定位問題,另外,因為是騰訊的。發現+定位+反饋上報P0低


Testin兼容性/穩定性測試利器,關鍵是機器的量夠!發現+定位P0低


待機時間短


Chkbugreport從用戶手機中提取BUGREPORT。通過這個工具是可以分析簡單的耗電問題,如sensor或攝像頭沒有關閉,wakelock的問題。發現+定位P0中


IOS

痛點指標工具名推薦原因工具類別落地優先級落地成本


卡頓

FastImage通過節省decode的耗時等方法,提升圖片及圖片列表的展示性能解決P1低


Realm通過更優秀的I/O性能,降低APP對持久化數據讀寫的損耗,從而提升交互性能。可替代coredata,userdefault,sqlite。解決P1中


MGWatchdog實現類似ANR的機制,主要是要跟上報結合發現+定位P0低


閃退

Infer解決因內存泄漏導致的內存耗盡導致的閃退。能掃描簡單的循環引用導致的內存泄漏。發現+定位P0低


Bugly/聽雲/OneAPM/TestinCRASH監控的能力大同小異,都能對數據上報的統計分析,清晰現網情況,用戶痛點。但我會推薦騰訊的BUGLY, 因為ANR, CRASH都能提供比較足夠的信息定位問題,另外,因為是騰訊的。發現+定位+反饋上報P0低


待機時間短


iOSDiagnostics可以獲取一些耗電的模塊的信息,如果可以融合到數據上報中的話就更好了。發現+定位P0中


通用

痛點指標工具名推薦原因工具類別落地優先級落地成本


流量大/速度慢

BPG(android,類似webp)


BPG(ios)

BPG是H265幀內壓縮做圖片壓縮,webp是利用VP8幀內壓縮做圖片壓縮。圖片壓縮對於圖片應用來說,除了能提升用戶下載顯示圖片的速度,還能為企業節約帶寬成本。解決P1中


Pngquant利用PNG8壓縮PNG圖片,顏色單一的圖片,效果會非常明顯。解決P0低


Wireshark實用的流量分析工具,包括export http object, I/O graph等等發現+定位P1中


EmmageeAndroid的性能測試組件,裡面涵蓋很多性能數據獲取的方法,可參考使用。發現P1低


HAR + PageSpeed利用tcpdump在手機上獲取的PCAP, 利用HAR轉換PCAP,然後給pagespeed組件分析。定位P1低


弱網兼容性差(ios通用)ATCFacebook弱網絡模擬工具。好處是模擬丟包,抖動的時候比較穩定,而且還有HTTP API可以調用, 方便和自動化配合。發現P0中


SPDY/QUIC特別是QUIC, 就是為了網絡抖動而設計的。解決P2中


OKHTTP推薦的HTTP組件。性能好,弱網兼容也不錯。解決P1低


APP的下載,安裝,卸載。

   能否正常下載

   安裝是否正常(有網,無網是否都正常),路徑是否正確,文件或者占用手機內存大小等(如果需要)

   是否沒有得到用戶允許就自啟動

   特殊情況下,比如內容不足情況下的安裝。不要導致系統死機,重啟,斷電等嚴重問題。要提示用戶內存不足,然後取消安裝。重新安裝沒有問題。

   卸載是否正常,是否將全部必要文件刪除(如果需求需要,有的APP是要保留部分文件的,尤其是用戶使用產生的文件)

   直接刪除文件導致不能使用,是否有提示

權限的驗證

   獲取的權限是否得到用戶的許可,尤其是部分重要的權限,如使用網絡,使用攝像頭,讀取通訊錄,簡訊,通訊記錄等。

   使用發送簡訊,打電話前要提示用戶。

   沒有網絡時,要提示用戶。這裡包含各頁面時的提示,尤其是註冊登錄時,也可以放在功能模塊的測試中。

   如果得到簡訊權限,可能得到簡訊關鍵內容。例如接收簡訊驗證碼。

   上面這些,其實也屬於安全測試,但因為較簡單,也可以當作功能測試。 至於是否存在用戶數據泄漏,屬於更專業的安全測試。

UI界面的驗證

  各界面是否需要需求,以需求文檔和用戶習慣為準。

各功能模塊的驗證

   一般的功能模塊包含:註冊,登錄,個人中心,各相應功能

註冊登錄的通用的重要測試點:

   沒有網絡時的提示

   登錄後,直接進入個人中心,或者是首頁

   密碼的驗證,密碼的保存(是否加密保存在手機中),密碼的長度,錯誤的提示,找回密碼,密碼最多錯誤次數的限制及後續處理邏輯(多久後或者怎麼操作後可以重新登錄)。

   是否允許多設備的登陸,台式機和手機的同時登錄,多台手機的同時登錄

登錄後,系統是否正確處理(個人信息是否正確,用戶權限是否正確)

  登錄超時的處理

   一般現在沒有註銷功能,若有,註銷後是否能重新註冊,且信息是否處理正確(新用戶不受原用戶信息的影響)

運行APP的重要點有:

   應用前後台的切換,是否崩潰,是否能正常使用(時間短,正常使用;時間長了,相當於重新打開應用),是否能正常接收新數據

   鎖屏解屏對應用的影響,是否能正常接收新數據。

   有電話進來後,再使用APP,功能是否正常。

   關閉APP後再打開APP,是否正常

   對於有數據交換的頁面,每個頁面都要進行前後台切換,鎖屏觸屏,電話接入等測試,因為這種頁面最易出問題。

免登錄功能

   關閉APP後,再重新打開,是否免登錄

   切換登錄用戶,用戶信息是否更新

   修改密碼後,是下次登錄或者開戶時校驗新密碼,還是本次登錄要馬上退出重新登錄?

數據更新

   哪些頁面的數據是自動更新,哪些手動更新

   前後台切換時,數據是否更新

   哪些數據是實時從服務端請求,哪些緩存到本地

離線瀏覽

   是否支持離線瀏覽?

   支持離線時,前後台切換或者鎖屏觸屏後,是否都能瀏覽本地信息?

   手動刷新時,是否有對連接網絡的提示?

APP更新

   打開老版本時,是否有新版本的更新提示

   是否強制升級

   不刪除老版本情況下,直接更新,是否正常,更新後,是否能正常使用

相機使用

   專門提到相機,是因為相機使用頻繁。而照相質量,用戶也很在意。所以當APP調用相機時,功能是否正常,質量是否可靠,也要多次測試。

** 消息推送**

   用戶接受消息推送時,是否能正常接收各類消息?

   不打開應用時,能否接收消息

  打開應用時,能否接收消息

   登錄與不登錄情況下,接收消息是否有區別(其實這些需求中都要明確,才能針對性展開測試)

   精確推送,是否只推送給指定用戶

兼容性測試

   兼容性測試,嚴格來說不是功能測試。但這裡功能測試,只是與性能測試,專業的安全測試區分後,籠統地稱其它測試全為功能測試。

   包括設備的兼容性測試,及網絡的兼容性測試。

  設備包括,不同品牌,不同系統(miui等)的手機,不同版本的android, ios, 不同屏幕大小的手機。

  網絡包括,WIFI,各種制式的3G, 各種制式的4G

  對http和https分別適應,這點是以前沒考慮到的。在星巴克等場所,需要輸入用戶名和密碼才能上網,這樣的網絡通常是https。

希望本文對你有所幫助~~如果對軟體測試、接口測試、自動化測試、面試經驗交流感興趣可以私聊我。免費領取最新軟體測試大廠面試資料和Python自動化、接口、框架搭建學習資料!技術大牛解惑答疑,同行一起交流。

關鍵字: