APP弱網測試

1、網絡測試的通常流程

step1：首先要考慮網絡正常的狀況

①　各個模塊的功能正常可用

②　頁面元素/數據顯示正常 

 

step2：其次要考慮無網絡的狀況

①　APP各個功能在無網絡狀況下是否可用

②　APP各個頁面之間切換是否正常

③　發送網絡請求時是否會致使閃退、卡死等異常狀況

④　APP各個頁面是否顯示完整美觀，未刷新的頁面是否作了相應的提示和處理

⑤　在無網絡狀況下數據是否會丟失

⑥　無網絡提示信息是否友好

 

step3：再次考慮弱網狀況

①　弱網狀況下APP是否針對請求作了超時處理

②　網絡延遲的狀況下，操做app進行數據同步、OTA升級是否會發生Crash、ANR等嚴重錯誤

③　弱網狀況下，APP請求回調未完成時，執行其餘動做以及交互時，是否會出現APP閃退（如：駕考IOS開屏閃退）等異常。

④　弱網狀況下，原始數據是否出現丟失的狀況（弱網下載時會出現丟包狀況）

⑤　弱網環境下，是否會出現請求堆積的狀況

⑥　弱網環境下，APP各個頁面是否顯示完整

⑦　系統超時，提示信息是否清晰明確

⑧　弱網狀況下APP的響應時間是否在一個合理的時間範圍內

⑨　請求回調未完成--駕考科四難題攻克彈窗

⑩　這個彈窗是服務器說了算，服務器知道該用戶啥時候彈彈窗。若用戶在作題頁面時返回了，則該用戶下次進入且在服務器緩存時間內，應該給出彈窗（產品邏輯：彈窗出現後用戶必須看到才消失）

⑪　請求堆積：水池注水排水問題

 

step4：最後考慮網絡狀態之間的轉變

①　斷開網絡鏈接之後，操做APP各個功能是否正常

②　同步數據過程當中，斷開網絡鏈接，APP是否出現異常狀況

③　傳輸數據過程當中，網絡由wifi切換到gprs，APP是否出現異常狀況

④　弱網環境下發送的請求是否在恢復網絡之後出現重複提交的狀況

tips：gprs---就是我們一般所說的流量

 

2、背景介紹

弱網測試做爲健壯性測試的重要部分，對於移動端的測試來講必不可少。

目前的網絡並不是徹底的流暢WiFi，目前使用最多的是2G,3G，4G，且使用場景多變，如近地鐵，上公交，進電梯，進山區等是的弱網測試顯得尤其重要。

 

測試維度

 ​

 

弱網測試的思路

​

 

總結：

一、弱網測試主要進行特殊網絡狀態下的功能測試，同時關注用戶體驗。

二、弱網測試主要包括弱網功能測試、無網狀態測試、網絡切換測試等

 

3、弱網功能測試

①　這一部分主要是在各類非wifi網絡環境下進行的功能測試，同時模擬高延時和高丟包的異常網絡環境進行健壯性測試。

②　2G/3G/4G的網絡能夠經過使用電話卡移動／聯通／電信等網絡進行模擬，關注頁面的響應時間、頁面呈現是否完整一致等。

③　高延遲和高丟包的網絡環境須要藉助工具來模擬，如Charles。

④　弱網功能測試建議將總體的功能測試用例在弱網環境下進行一輪測試，相同模塊下的功能能夠分多個網絡條件進行測試。這部分發現的問題可能會有：

• 頁面圖片在弱網環境下加載不出來（圖片加載邏輯需優化）
• 須要模版的頁面版式結構混亂（模版文件在弱網環境的加載需優化）
• 頁面響應時間較長沒有任何顯示（頁面顯示邏輯待優化、重試機制加入）

 

4、弱網UI測試

弱網狀況下：

• APP極可能出現UI刷新不及時或者不刷新的狀況，此時就可能會致使呈如今用戶面前的是一個殘缺的頁面；
• 偶會也會致使出現頁面UI元素錯亂的狀況（如：駕考vip頁面）；

 

5、無網狀態測試

無網狀態測試則是在切換網絡的狀況下進行的測試，主要關注頁面的顯示與交互、本地數據的存儲、斷網功能的使用等，常常該部分也須要與網絡切換部分協同進行。

• 斷網狀況下請求非本地數據的頁面須要設定必定的時間等待上限，及時提示網絡異常以及提示重試；
• 斷網狀況下請求部分本地數據的頁面須要觀察本地數據的部分是否加載顯示正常，待請求的部分是否符合交互給的缺省樣式一致；
• 斷網狀況下請求徹底本地數據的頁面是否顯示正常。這裏還需考慮本地數據存儲的狀況，有些須要聯網後上報服務器的數據本地是否正確存儲，聯網後這些數據可否正常上報。
• 無網狀態測試建議按照頁面劃分進行，針對每一個頁面單獨測試無網狀態的顯示，頁面間跳轉的顯示，頁面內功能的點擊和顯示，同時關注無網到有網時的頁面恢復顯示狀態、數據上報狀況是否正常。

注：以駕考課件視頻爲例作個補充

• 無網無緩存時作題頁面不顯示課件視頻模塊；
• 無網有緩存，且在緩存時間內，點擊視頻時能夠正常播放；

 

6、網絡切換測試

這部分主要是進行幾個不一樣網絡場景的切換，包括：

wifi-2G/3G/4G、wifi-無網、2G/3G/4G-wifi、2G/3G/4G-無網、無網-2G/3G/4G、無網-wifi

主要關注頁面的顯示與交互，尤爲：

• 弱網到wifi
• wifi到弱網

以上兩種狀況驗證是否會有頁面的crash以及顯示的錯亂、session是否一致、請求堆積處理等。

 

7、用戶體驗關注

弱網測試的目的就是儘量保證用戶體驗，測試點以下：

（1）頁面響應時間是否可接受，關注包括熱啓動、冷啓動時間，頁面切換，先後臺切換，首字時間，首屏時間等。

（2）頁面呈現是否完整一致

（3）超時文案是否符合定義，異常信息是否顯示正常。

（4）是否會有超時重連

（5）安全角度：是否會發生dns劫持

（6）大流量事件風險：是否會在弱網下進行更新apk包、下載文件等大流量動做。

熱啓動：已經啓動過APP了，而後切換到後臺，或者退出，可是這時候應用並無徹底退出，可能應用還有一些服務在後臺啓動

冷啓動：就是以前沒啓動過APP

dns劫持：又稱域名劫持，是指在劫持的網絡範圍內攔截域名解析的請求，分析請求的域名，把審查範圍之外的請求放行，不然返回假的IP地址或者什麼都不作使請求失去響應，其效果就是對特定的網絡不能訪問或訪問的是假網址。常見的分爲2種：網頁劫持/運營商劫持

好比：輸入www.baidu.com，結果打開了淘寶網，就說明百度的dns被劫持了；

Android駕考寶典進入vip頁面時被劫持；

 

8、響應時間

• 安卓手機通常超過5秒鐘無響應就會報ANR的錯誤
• ios手機響應時間過長也會報錯
• 2-5-10原則（或3-5-8）：
• 用戶可以忍受的最佳響應時間是2秒之內；
• 超過5秒無響應的話，通常性子比較急躁的用戶極可能就會直接退出頁面了；
• 若是超過10秒無響應，不少人都會選擇殺掉APP；
• APP常常處於無響應或者響應時間過長的狀態，會致使大批的用戶轉移到競爭對手的產品上。

 

9、異常測試

異常測試是指驗證APP針對各類網絡異常狀況是否作出了容錯處理，這裏麪包括：

①　異常提示信息

②　出錯容錯機制

③　超時判斷處理機制（代碼級別）

④　出錯之後自動重連等

tips：

容錯機制---簡單點可理解爲： 我快速點擊屢次，可是就響應一次

出錯後重連---就是訪問網絡，沒獲得數據，在錯誤的地方從新訪問網絡。如：駕考VIP

10、弱網測試工具--Charles模擬慢速網絡

 ​

在 Charles 的菜單上，選擇 「Proxy」–>「Throttle Setting」 項，在以後彈出的對話框中，咱們能夠勾選上 「Enable Throttling」，而且能夠設置 Throttle Preset 的類型。如右圖1所示：

 若是咱們只想模擬指定網站的慢速網絡，能夠再勾選上圖中的 「Only for selected hosts」 項，而後在對話框的下半部分設置中增長指定的 hosts 項便可。

 進行這項設置後，咱們會看到小紅旗處於工做狀態，如右圖2

​

 

  ​  

 

PS：弱網、2G、3G建議的上下行速率以下，同時還能夠控制丟包率的數據

      網絡             上行               下行

      弱網               10                 30

      2G                 15                 50

      3G                384               2800

  

補充：瞭解下2G/3G網絡

 ​

 

​