弱网测试学习记录(2)

文章探讨了游戏交互的基础,强调TCP/UDP在游戏中的作用,以及客户端和服务器之间的消息逻辑。重点讲述了弱网测试的重要性,包括测试目标如资源加载、支付、购买和状态同步等,并详细分析了超时处理、断线重连机制以及在网络恢复后的请求处理。此外,还讨论了多次请求可能导致的服务端逻辑验证问题和应对策略。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

游戏交互的基本原理:

​ 游戏基本都是基于TCP/UDP协议(传输层),

简单理解:
TCP 长连接,游戏登录后一直保持连接,

S 服务端:一直监听请求/响应请求

C 客户端:向服务器发送请求/接收请求

游戏实质:客户端只是躯壳,隐藏在各个界面元素身上的各种消息逻辑才是触发界面表现的根本原因。C、S通过各种消息实现状态转换,触发界面表现的变化。

举例:

购买道具:你点了购买按钮,客户端向服务器发了购买消息(金币数、账号信息等),服务端收到后判断(钱够不够,合法性)后回复响应消息,客户端收到消息认定购买成功或者失败(提示成功扣钱,提示失败,xxx)

异常情况:(比如:C发了购买消息,上行丢包超时,不会发出去购买消息, 那么客户端和服务端状态都不会刷新, 但是如果下行丢包超时,S状态已经变化,C的状态如果不刷新,会出现按钮操作无响应或者其他异常)

弱网测试是指弱网络场景下测试游戏表现,实质上是借助弱网络的丢包、乱序等发现游戏设计的逻辑异常,其中核心是上、下行丢包及触发重连机制后前后端逻辑一致性。

弱网络常见问题:
资源、数据未加载
操作无响应
不同步
卡流程
测试重点
游戏流程(例如:启动、登录、进入游戏、准备/选人、跳流程阶段、游戏结算等)

支付(例如:充值,iOS特别要注意下拉起较慢的情况)

购买、领奖等货币相关(例如:购买钻石、购买道具、游戏复活等;每日奖励、任务奖励、抽奖等)

状态相关(例如:跳转、刷新界面、刷新按钮、使用技能等)

断线重连机制(例如:断网提示、自动重连、失败提示等)

网络敏感的交互功能(例如:实时对战,多人一定要考虑相互影响,注意同步方案-帧同步/状态同步等)

单位时间内重复操作(例如:快速重复操作,一般情况下会做点击限制)


测试过程

了解及理解游戏,从前、后端技术栈、架构上,游戏类型同类参考上,特别是要搞清楚断线重连机制,初步分析风险点。
写用例,参考测试重点,参考弱网络用例模板,
开始测试,在各条用例上完成以下几步操作
编写报告
总结经验、归档


超时处理
超时处理是指验证游戏从断网开始到触发断线重连到恢复的整个过程,一般情况表现为:一定时间后提示断网(图标或者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)。

流程图:
在这里插入图片描述

异常网络(分上行、下行2部分):
超时处理(一直观察从弱网参数生效开始的游戏表现,主要是验证断线重连逻辑)

再次请求(重连后再次进行操作,比如:弱网参数下点击领奖后,重连完成,再次点击领奖的表现)

多次请求(弱网参数下多次进行操作,比如:弱网参数下多次点击领奖,如做限制则无法点击)

切换网络(切换不同网络,一般情况下WIFI/4G)

分别在以上操作下验证是否符合测试标准,如:

预期:
1.不会无限重试
2.有合理提示,引导玩家回到登录前界面
3.网络恢复后可以正常登录/重回
4.登录/重回转菊花期间网络恢复,无异常
5.多次请求后网络恢复,可以正常登录

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值