专项-弱网络测试
-
弱网络
简单理解：网络不好；网络环境复杂、使用场景多变；异常逻辑检查。
-
弱网络测什么
测试标准
客户端的核心场景必须有断线重连机制，并在有网络抖动、延时、丢包的网络场景下，客户端需达到以下要求：
一. 不能出现以下现象：
1、游戏中不能出现收支不等、客户端卡死/崩溃等异常情况；
2、游戏核心功能（如登录、单局、支付等）不能有导致游戏无法正常进行的UI、交互问题；
3、不能有损害玩家利益或可被玩家额外获利的问题；
4、需要有合理的断线重连机制，避免每次重连都返回到登录界面。
二. 需要对延时的有合理的提示
参数：
特征参数
2G、3G、4G、5G
异常参数
上行100%丢包
下行100%丢包
测试内容：
- 前、后端在不同网络（2G/3G/4G/5G/调参数）下的体验表现（体验性）
- 前、后端在异常网络（上、下行丢包）下的功能表现（逻辑性）
体验：合理提示、主流网络场景下不会影响正常使用（持续表现）
逻辑：健壮、安全（断网过程、断网重连后状态）
游戏交互的基本原理：
游戏基本都是基于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是已经断线重连后
测试点：
- 在等待中 恢复网络，检查上、下行是否符合预期
- 在断线重连中 恢复网络，检查上、下行是否符合预期
- 在重连恢复后， 再次进行请求， 检查上、下行是否符合预期
恢复再次请求在不同的状态下进行表现不一样，具体如下：
上行丢包：等待中恢复，操作会生效（√）
上行丢包：断线重连中恢复，操作不生效（×，因为消息没有发出去）
上行丢包：断线重连后，操作生效（√）
下行丢包：等待中恢复，操作会生效（√）
下行丢包：断线重连中恢复，操作会生效（√）
下行丢包：断线重连后，操作会生效（√）
风险点：上、下行丢包超时异常时，如果状态不一致，会导致前后端状态不一致，再次进行操作无法操作或数据异常。上行丢包出异常大概率是状态存在客户端，下行丢包出异常大概率是客户端没有刷新状态。
（如：新手引导，下行丢包点击下一阶段，服务端状态已经进入下一阶段，客户端无法刷新状态，则会卡死在当前界面；
领奖，下行丢包点击领奖，服务端状态已经领取，客户端如无法刷新状态，则会显示未领奖但是无法领取；）
- 多次请求后恢复网络
是指重复发送请求，主要是为了验证服务端逻辑。
原理：多次重复请求，发送同样的请求，检查客户端、服务端是否有去重处理，服务端逻辑是否正确。
测试点：
- 响应次数（1次）
- 响应正确性（服务端判定）
举例：
断网了点击没反应，可能点了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）。
流程图：
