淺談弱網測試

梳理下弱網測試場景和測試點。

一、【弱網測試場景】

既然APP異常測試中,弱網測試屬於必須考慮的測試項,哪些業務適合驗證,哪些不需要驗證呢?以下是個人淺見,歡迎拋磚引玉:

1.結合APP本身屬性

比如社交類APP(聊天、搶紅包)對網絡環境依賴性大且用戶關注度高,弱網環境下需要重點關注。

結合互聯網金融APP,申購流程中創建訂單後是否支付成功,用戶關注度最高(涉及扣費)。例如 弱網環境,創建訂單失敗,用戶關注是否被扣費;創建訂單成功後支付失敗,再次支付是否重複扣費等

2.使用頻率&易遇到弱網的場景

比如微博APP【觀看小視頻】,用戶在碎片時間極易【觀看小視頻】(APP用戶喜歡使用碎片化時間進行娛樂操作),同時增加了【刷微博】(微博小視頻和刷微博 操作場景重合)此處就需要加強弱網環境測試

比如金融APP,用戶在碎片化時間使用金融APP,領取獎品、查看理財類新聞、查看收益

好的例子:據我所知,微信的升級就會監聽用戶是否插着電,連着wifi,一旦監聽到了,就馬上告訴你,現場可以升級

二、【弱網環境測試點總結】

1.場景:弱網環境下某個操作響應時間

原因:APP用戶對等待時間容忍度低,若弱網環境loading超過5s,用戶很容易kill應用後再次進入應用

【測試點】性能測試中,加入弱網環境測試點,檢測各個場景網絡請求的 API 消耗時間(此處可以放入性能測試中,做爲衡量APP性能好壞的指標)

2.場景:弱網環境下直至超時,UI界面友好度&APP是否穩定

原因:容錯機制主要是考慮弱網情況下帶來的不穩定,常見的問題是:loading超時導致ANR or crash

【測試點】弱網環境直至超時,判定爲斷網狀態,UI界面和提示,友好且理解無歧義

3.場景:斷網後環境下,是否自動重發請求

原因:不同模塊,開發對請求處理不同。測試前可瞭解,代碼是否支持自動重複請求,自動重發請求的頻率是什麼?

【測試點】斷網後恢復網絡,是否堆積網絡請求(目前來說 理財模塊 當10s左右無返回 則會重發請求),此時請求和返回正常情況下,是否出現異常情況。比如1次支付操作,斷網後堆積多個支付請求,恢復網絡後因堆積多個支付請求,是否完成多次支付

ps:斷網後恢復網絡,考慮APP進行操作目的是否對傷害用戶體驗,通過哪種手段 可以達到操作目的同時用戶體驗無感或者低傷害

比如,微信希望在線升級某些內容,會自動監聽用戶是否插着電 or 連着wifi,一旦監聽符合上述場景,APP自動升級:

1)插電場景 確保升級過程中,耗電不會導致手機低電量甚至沒電

2)wifi場景,確保升級過程中,流量消耗不會使用用戶話費中流量包,不會導致因消耗話費流量傷害用戶體驗

4.網絡請求中,kill進程 (導致APP登錄態掉線)

登錄同一個賬號成功,應該不繼續相同網絡請求(要和RD確認,程序實際實現)

登錄不同賬號成功,應該不繼續相同網絡請求(要和RD確認,程序實際實現)

三、【常見弱網問題和原因分析】

1.場景:上傳大圖或者多圖時,在弱網絡環境下出現進度條走到一半卡住然後又從頭開始

原因:採用分段上傳方式,直至請求超時,分段傳輸沒有結束,代碼邏輯不對,導致每次重試都重頭上傳,一直循環

2.場景:在弱網絡環境下容易出現登錄不上或者登陸後立即掉線

原因:登錄沒有緩衝機制,而請求超時時間的設置沒有區分同網絡情況

解決方案:建議開發針對wifi、2g、3g、4g設置不同的超時時間

3.場景:弱網絡環境下,請求的數據返回時間較長,等待的過程中,如果頁面上的相關控件仍然可以操作,則容易出現異常現(閃退現象、觸發底部時獲得原頁面請求數據)

原因:依賴數據的控件操作,在數據返回前沒有做兼容處理

4.場景:搜索時輸入關鍵字會連續發請求,停下時,顯示最終的關鍵字搜索結果,但很快又會被前面的關鍵字搜索結果覆蓋了;

原因:中間的請求返回較慢,顯示了最終的結果後,之前的請求返回的數據應不做處理。


原文:
作者:siyu8023
鏈接:https://www.jianshu.com/p/06be11140413
來源:簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章