专项-弱网络测试
-
弱網絡
簡單理解：網絡不好；網絡環境復雜、使用場景多變；異常邏輯檢查。
-
弱網絡測什么
測試標準
客戶端的核心場景必須有斷線重連機制，并在有網絡抖動、延時、丟包的網絡場景下，客戶端需達到以下要求：
一. 不能出現以下現象：
1、游戲中不能出現收支不等、客戶端卡死/崩潰等異常情況；
2、游戲核心功能（如登錄、單局、支付等）不能有導致游戲無法正常進行的UI、交互問題；
3、不能有損害玩家利益或可被玩家額外獲利的問題；
4、需要有合理的斷線重連機制，避免每次重連都返回到登錄界面。
二. 需要對延時的有合理的提示
參數：
特征參數
2G、3G、4G、5G
異常參數
? 上行100%丟包
? 下行100%丟包
測試內容：
體驗：合理提示、主流網絡場景下不會影響正常使用（持續表現）
邏輯：健壯、安全（斷網過程、斷網重連后狀態）
游戲交互的基本原理：
? 游戲基本都是基于TCP/UDP協議（傳輸層），
簡單理解：
TCP 長連接，游戲登錄后一直保持連接，
S 服務端：一直監聽請求/響應請求
C 客戶端：向服務器發送請求/接收請求
游戲實質：客戶端只是軀殼，隱藏在各個界面元素身上的各種消息邏輯才是觸發界面表現的根本原因。C、S通過各種消息實現狀態轉換，觸發界面表現的變化。
舉例：
購買道具：你點了購買按鈕，客戶端向服務器發了購買消息（金幣數、賬號信息等），服務端收到后判斷（錢夠不夠，合法性）后回復響應消息，客戶端收到消息認定購買成功或者失敗（提示成功扣錢，提示失敗，xxx）
異常情況：（比如：C發了購買消息，上行丟包超時，不會發出去購買消息， 那么客戶端和服務端狀態都不會刷新， 但是如果下行丟包超時，S狀態已經變化，C的狀態如果不刷新，會出現按鈕操作無響應或者其他異常）
弱網測試是指弱網絡場景下測試游戲表現，實質上是借助弱網絡的丟包、亂序等發現游戲設計的邏輯異常，其中核心是上、下行丟包及觸發重連機制后前后端邏輯一致性。
弱網絡常見問題：
- 資源、數據未加載
- 操作無響應
- 不同步
- 卡流程
測試重點
-
游戲流程（例如：啟動、登錄、進入游戲、準備/選人、跳流程階段、游戲結算等）
-
支付（例如：充值，iOS特別要注意下拉起較慢的情況）
-
購買、領獎等貨幣相關（例如：購買鉆石、購買道具、游戲復活等；每日獎勵、任務獎勵、抽獎等）
-
狀態相關（例如：跳轉、刷新界面、刷新按鈕、使用技能等）
-
斷線重連機制（例如：斷網提示、自動重連、失敗提示等）
-
網絡敏感的交互功能（例如：實時對戰，多人一定要考慮相互影響，注意同步方案-幀同步/狀態同步等）
-
單位時間內重復操作（例如：快速重復操作，一般情況下會做點擊限制）
上下行丟包超時重連、切換網絡、無網絡等場景下關注以上內容
誤區
-
弱網絡 ≠ 異常中斷
異常中斷 會觸發 斷線重連（物理中斷、非物理中斷）
斷線重連分2種，第1種是從登陸（冷啟動）完成重連（殺進程），第2種是過程中（熱啟動）重連（超時重連、斷wifi快速重連）
熱啟動/冷啟動，進程在/不在，是否需要重新加載。
弱網絡上、下行丟包超時重連屬于非物理中斷中的斷線重連，
常規測試中，物理性的異常中斷（殺進程、斷wifi、電話短信）是需要測試的。
-
上、下行丟包 ≠ 斷網（上、下行100%丟包）
斷網好比把路堵了；上、下行丟包好比單向通行。
-
專業術語
-
丟包
TCP/IP協議通信傳輸中的數據單位，一般也稱“數據包”，它包含發送者和接收者的地址信息。這些包然后沿著不同的路徑在一個或多個網絡中傳輸，并且在目的地重新組合。
-
延時
-
帶寬
-
誤碼
編碼、解碼、轉碼
-
亂序
不同消息包發送先后不一，傳輸路徑不同，理論上是先發先至，但極低概率會后發先至
-
上、下行
上行： C—S（客戶端到服務器）
下行： S—C（服務器到客戶端）
-
-
工具及原理
工具
-
QNET
-
Fiddler 、Charles、WiFi管家等等
模擬弱網絡的原理
-
WIFI-設備之間（中間加代理）
-
WIFI（出口做限制）
QNET是在連接的網絡和設備內的應用之間建立了VPN（=代理），通過控制相應參數，以控制對應用上、下行消息的網絡狀態。
C — S （消息直傳，只受所連接的網絡條件影響）
C — 代理 —S（消息均會經過代理進行轉發，代理控制 丟包、延遲、帶寬）
-
怎么開展弱網絡測試
工具（QNET）下載安裝
https://wetest.qq.com/product/qnet
工具使用演示（略）
略
測試過程
- 了解及理解游戲，從前、后端技術棧、架構上，游戲類型同類參考上，特別是要搞清楚斷線重連機制，初步分析風險點。
- 寫用例，參考測試重點，參考弱網絡用例模板，
- 開始測試，在各條用例上完成以下幾步操作
- 編寫報告
- 總結經驗、歸檔
用例
2部分，1部分是測試異常網絡（上、下行丟包、切換網絡），1部分測試特征網絡（2、3、4、5G等），如：
異常網絡（分上行、下行2部分）：
超時處理（一直觀察從弱網參數生效開始的游戲表現，主要是驗證斷線重連邏輯）
再次請求（重連后再次進行操作，比如：弱網參數下點擊領獎后，重連完成，再次點擊領獎的表現）
多次請求（弱網參數下多次進行操作，比如：弱網參數下多次點擊領獎，如做限制則無法點擊）
切換網絡（切換不同網絡，一般情況下WIFI/4G）
分別在以上操作下驗證是否符合測試標準，如：
| 1.不會無限重試 |
| 2.有合理提示，引導玩家回到登錄前界面 |
| 3.網絡恢復后可以正常登錄/重回 |
| 4.登錄/重回轉菊花期間網絡恢復，無異常 |
| 5.多次請求后網絡恢復，可以正常登錄 |
特征網絡（2G/3G/4G等）
游戲體驗（流暢、一般、難以忍受、無法游戲）
| 流暢：操作體驗流暢，沒有響應失敗，反復重連的現象 |
| 一般：操作體驗一般，偶爾有響應失敗和響應時間長的現象 |
| 難以忍受：操作體驗極差，經常性連接失敗，反復重連 |
| 無法游戲：無法正常游戲，經常性掉線 |
測試
進入測試場景后，開啟當前需測試網絡參數，持續觀察游戲表現或進行相關操作。
比如：購買物品測試過程，
開啟上行丟包超時，開啟后點擊購買，此時會出現菊花等待響應狀態，觀察界面表現，正常情況下一定時間會有網絡斷開提示，提示后會觸發自動重連，重連n次失敗，會提示框回到登錄。
恢復正常網絡，再次點擊購買
開啟上行丟包超時，連續點擊購買
選中4G，切換3G，馬上點擊購買，切換4G，再次點擊購買
分別在2G/3G/4G網絡參數下，購買物品，觀察體驗
報告
報告包含內容（根據情況加入解決建議）：
測試結論（問題列表）、項目概述（測試標準、測試參數、測試場景）
總結、歸檔
略
分享總結
分享后需要理解內容：
- 什么是弱網絡
- 弱網絡與斷線重連的關系
- 弱網絡測試方法
- 弱網絡測試重點
- 如何編寫弱網絡測試報告
擴展學習了解內容：
- OSI七層網絡模型
- TCP\UDP協議，Protocol Buffer， socket
- 冷啟動、熱啟動
- 計算機默認初始時間1970-1-1
后續進階
弱網絡測試理解原理后，擴展到 消息亂序和改包后的處理已經涉及一定安全測試范疇，后續可結合服務器壓測，實現脫離客戶端對服務端測試，結合起來可進行性能及安全相關的進一步測試。
弱網絡異常部分詳解
（上、下行100%丟包超時 分別進行如下測試，即測試內容*2）
測試過程
超時處理、恢復網絡再次請求、多次請求后恢復網絡
- 超時處理
超時處理是指驗證游戲從斷網開始到觸發斷線重連到恢復的整個過程，一般情況表現為：一定時間后提示斷網（圖標或者tips），后進入自動重連狀態（后臺重連幾次，前臺無明顯表現），超出設定重連次數還失敗則彈出提示框（回到登錄頁面或檢查網絡）
測試點：檢查各功能是否表現一致
風險點：不同的功能不同的人做，特別是非戰斗和戰斗功能，戰斗有可能有特殊重連處理，會互相影響，導致表現不一致或其他問題。（籃球出現過：戰斗中沒有斷網提示，重連邏輯互相影響）
- 恢復網絡再次請求
斷網過程理解：一般情況下從斷網開始到重連有3個階段，1是還在等待中（還在判定是否超時觸發斷線重連的閾值時間內），2是斷線重連中（超出判定閾值），3是已經斷線重連后
測試點：
恢復再次請求在不同的狀態下進行表現不一樣，具體如下：
上行丟包：等待中恢復，操作會生效（√）
上行丟包：斷線重連中恢復，操作不生效（×，因為消息沒有發出去）
上行丟包：斷線重連后，操作生效（√）
下行丟包：等待中恢復，操作會生效（√）
下行丟包：斷線重連中恢復，操作會生效（√）
下行丟包：斷線重連后，操作會生效（√）
風險點：上、下行丟包超時異常時，如果狀態不一致，會導致前后端狀態不一致，再次進行操作無法操作或數據異常。上行丟包出異常大概率是狀態存在客戶端，下行丟包出異常大概率是客戶端沒有刷新狀態。
（如：新手引導，下行丟包點擊下一階段，服務端狀態已經進入下一階段，客戶端無法刷新狀態，則會卡死在當前界面；
領獎，下行丟包點擊領獎，服務端狀態已經領取，客戶端如無法刷新狀態，則會顯示未領獎但是無法領取；）
- 多次請求后恢復網絡
是指重復發送請求，主要是為了驗證服務端邏輯。
原理：多次重復請求，發送同樣的請求，檢查客戶端、服務端是否有去重處理，服務端邏輯是否正確。
測試點：
舉例：
斷網了點擊沒反應，可能點了10次購買按鈕（意味著發了10次請求），恢復網絡后，查看結果。
測試點：第1是否買了10次，第2是否扣錢正確。（玩家期望：只買了1次，扣了1次的錢正確）
異常情況：響應了10次，買了10次（沒有丟棄重復請求），扣錢只扣了1次（為什么扣1次，服務端判定錯誤）。
分析：當服務器使用錯誤緩存數據或者客戶端數據做驗證時，下行丟包超時情況下，客戶端請求消息一直是一樣的（如：10000塊錢買個1000的東西），服務端使用前端數據判定，則10次請求每次都是10000塊錢買1000的東西，最后買了10次剩余9000塊錢。
正常情況：
1符合邏輯的表現：響應10次，扣了10次錢，買了10個東西（第1次買完剩9000，第2次買完剩8000,10次買完剩0元。。。）
2符合體驗的表現：正常處理應該只響應1次（沒反應習慣性一直點，避免玩家誤操作扣錢），服務端判定扣除貨幣且數據正確（買1個東西，剩余9000）。
流程圖：
總結
- 上一篇： foobar2000 用了那么久 才学会
- 下一篇： 无线传感器网络