1. 游戏测试的本质不是机械执行而是研发场景的重构做了这么多年游戏研发我越来越觉得“测试”这个词被低估了。很多人以为测试就是点点点、找找bug、提交一下问题单顶多是看策划文档写几条用例。但真正进入开发流程之后你会发现测试在游戏项目里承担的是“质量模型设计者”的角色。你要是只把它当执行环节后面上线时的返工量绝对让你怀疑人生。先说清楚游戏测试和我们常说的通用软件测试确实同宗同源但游戏有自己的特殊体质。通用软件追求的是“功能正确”游戏追求的则是“体验闭环”。举个最简单的例子一个OA系统里用户上传文件失败你记一个bug开发改了接口流程恢复这就完事了。但游戏里一个角色技能放出去没伤害这个问题的根源可能关联到技能配置表、服务器判定、客户端表现、网络延迟补偿、数值策划表甚至美术动画的播放时长和攻击帧对齐。一个问题背后经常牵扯三四个模块它的排查链路远比普通CRUD复杂得多。所以游戏测试第一件事是搞明白自己要测的是哪一块。按我习惯的做法先把测试范围粗暴分成四个大块再分别设计方案玩法逻辑测试技能、状态、数值成长、NPC行为、任务流程、战斗结算、资源产出。这是游戏的心脏也是bug重灾区。UI与交互测试界面跳转、按钮响应、异常操作、分辨率适配、多语言截断。这里面的坑看起来小但最容易让玩家打出低分。网络与同步测试延迟、断线重连、弱网表现、广播同步、帧同步与状态同步两种模型下的校验逻辑。多人游戏的核心都在这一层。性能与兼容测试帧率、内存、加载耗时、长时间运行的稳定性、不同设备和操作系统的适配表现。这层直接决定你的游戏能不能上主流渠道。这四块听起来不复杂但真正的难度在于测试策略怎么跟研发节奏咬合。我见过不少团队测试计划写得特别漂亮一到实际排期就被需求变更冲得七零八落。后来我学到一个原则以版本里程碑为锚点把测试工作拆成内嵌式动作而不是事后大检查。每个里程碑开发完成前测试提前介入先跑冒烟再逐步深入。不要等所有功能做完了再排队等着测那样你测的永远是昨天的旧代码问题堆积到最后一天集体爆发是谁都救不回来的。这里多说一句热词里常刷到的“测试左移”概念。在游戏项目里左移的核心不是让测试多开会多写文档而是让测试直接参与玩法设计阶段的评审。比如MOBA类游戏新英雄上线测试如果能在数值方案阶段就问你“这个技能范围是圆还是扇形半径多少如果飞行弹道被打断效果存不存在”这些问题在实现前提出成本几乎为零但放到开发完成后再提可能就是四五个人重新加班的代价。所以我的定位一直是测试不是在开发末端等活的人而是从立项到上线的全程质量把关人。适合谁来参考这篇内容如果你是刚入行的游戏测试或者正在从通用软件测试转向游戏领域又或者一个小团队里需要身兼数职的开发者想快速建立测试体系这篇文章就是你想要的地图。整套方法论不止适用于手游端游、H5小游戏、休闲游戏、竞技类游戏全都吃这套框架。2. 核心测试点拆解与实操要点游戏测试的细致程度直接决定你能发现什么层级的问题。我习惯把测试点拆到“一个操作引起状态变化”这个粒度也就是把玩家的一次输入拆成前置条件、操作动作、预期状态、关联系统四段。这四段想清楚了一条合格的用例就出来了。2.1 玩法逻辑测试从数值到状态的链路验证玩法逻辑是游戏测试的核心我已经不记得自己在这块踩过多少坑了。先说最容易忽略的一条数值验证别只看配置表一定要走实际对局验证。很多数值策划会直接配一个攻击系数开发也照着表做完了但从技能释放到伤害结算中间走了一条极长的链路。你要是不实际打一场你根本发现不了暴击率和文案里写的不一样原因是结算模块把暴击乘区加在了穿透之前导致实际收益和策划预期差了两倍。我举一个自己做卡牌游戏时的真实案例。当时策划配置了某个角色的大招描述是“对敌方全体造成攻击力300%的伤害并使其受到伤害提升15%”。测试用例第一版只验证了伤害数值是否等于攻击力乘以3确实没问题。但后来我多追问了一句“这个提升15%的易伤效果是加法叠加还是乘法叠加如果目标身上已经有一个20%的易伤buff两个效果并存时是35%还是1.35倍”开发当时愣了一下回去查代码才发现做的是独立乘区。就这么一个细节在面对高防boss时伤害差异能到40%以上。这就是玩法逻辑测试的真相你以为在测数值其实你在测策划意图和代码实现的一致性。再往下说状态类测试更要命。按我看的经验游戏里七八成的严重bug都出在状态切换上而不是普通的数值对错。什么叫状态切换就是玩家控制的单位在一个时刻只能处于一种状态比如站立、跑步、施法、眩晕、击飞、倒地、死亡。你开发时每个状态单独测都正常但状态一叠加就出事。最典型的bug是玩家角色被眩晕时同时被位移技能推走——有些引擎里这两个系统是分开管的最后角色位置被推走了但状态机还停在眩晕玩家爬起来之后移动速度不对甚至直接卡在贴图里。这类案子的检验方法我的建议是设计状态机矩阵测试。把游戏里所有单位状态列成一张表两两组合逐个测试互切是否正常。这张表看起来很枯燥但它覆盖的是游戏体验中最微妙的地方玩家感知到的“手感好”或“手感差”很大程度就取决于这些状态切换是否干净利落。平时测玩法不要只关注“最终结果对”要花两倍精力去关注“过程里单位的状态流转是否符合预期”。还有一个常被遗漏的类别叫边界与容错测试。背包满了还能不能开宝箱金币最大值溢出会变负数吗倒计时快到零的时候再点一次购买会不会双扣体力上限满了能不能继续领邮件这些问题基本都是边界问题用例设计时一定要把上下边界、临界点、重复操作、极端输入都列进去。你不需要很高的数学水平只要抱着“玩家一定会干出我没想过的事”这种心态去设计用例覆盖率马上就上来了。2.2 UI与交互测试最容易被低估的环节UI测试表面门槛低实际坑特别多。很多团队把UI测试交给新人做觉得就是点一点但真正上线后玩家吐槽最狠的往往就是这些“底层逻辑看着没问题”的地方。UI层第一个大问题是层级与遮挡。弹窗叠加顺序错了、按钮被透明层挡住点不到、关闭按钮在部分分辨率下超出屏幕、聊天框弹出时把商店的购买按钮盖住——这些全靠人工在真机上点的体验问题没有任何自动化能做全。所以我建议团队无论如何都要留一个“真机探索测试”的时间段别只在模拟器上点。模拟器里鼠标操作和手指操作在手感、误触概率、缩放逻辑上完全不同。第二是异常操作流。正常用例永远是“点击→弹窗→点击确认”但玩家不按套路来。他会快速连点、双击、在弹窗还没弹出时又点另一个按钮、在网络卡顿期间反复切换页面。这种异常流的测试用例一定要单独写我最常用的一种写法是“前置条件→连续高频率操作→观察最终状态是否一致”。比如疯狂点击十次“十连抽”系统到底应该弹几次确认框强制关闭应用再重开抽到的道具还在不在这些场景太值钱因为线上高频投诉里这类“操作没毛病但状态不对”的占比相当大。第三是多语言与屏幕适配。如果游戏出海界面文案截断问题铁定遇到。德文、俄文的单词长度比中文长一大截按钮如果宽度固定文字就会被切掉看起来非常廉价。早期做测试规划时就要把“每种语言的三个最长文案”整理出来专门给UI同学当作适配测试用例。屏幕适配方面我的建议是自己维护一张真机遮罩列表上面把刘海屏、挖孔屏、全面屏的布局安全区写清楚测试过程中每轮都要过一遍。提示UI自动化测试也有用但别指望它解决所有布局问题。自动化的强项是回归核心链路的稳定性弱项是感知“看起来舒不舒服”这种主观体验。两件事必须并行不能互相替代。2.3 网络同步与弱网测试网络这层是游戏测试里复杂度最高的部分。尤其MOBA这类实时对战游戏一局游戏里所有玩家的操作要在一个时间轴上得到一致的演绎网络稍微抖动体验立刻崩。先从两种同步模型说起。帧同步最常见于MOBA和格斗游戏核心思路是所有客户端运行同一份逻辑服务器只转发操作指令。它的优点是同步效率高、带宽消耗小缺点是对客户端逻辑一致性要求极高。如果两个玩家手机帧率不同或者引擎浮点运算有微小差异游戏里就会出现“我这边看到你闪现了你那边看到我原地站着”之类的不同步问题。状态同步则是服务器说了算客户端只表现结果对一致性有保障但服务器的计算压力和带宽压力都更大。不管是哪种模型测试网络层都要覆盖三类场景网络切换场景Wi-Fi切到4G、切换路由器、从电梯里出来信号恢复。要注意游戏能不能自动重连、重连后是否能快速恢复对局状态。延迟场景模拟固定延迟比如100ms、200ms、500ms观察技能释放是否有明显延迟感、移动是否跟手、操作是否被吞。抖动与丢包场景这是弱网里最容易暴露问题的场景。网络在短时间内忽好忽坏丢包率从0%跳到30%服务器如果处理不当客户端就会出现角色瞬移、技能不同步、伤害结算对不上。这里说一句经验之谈iOS上可以用系统自带的Network Link Conditioner来模拟弱网Android上比较麻烦一般用PC上搭一个代理服务器来做流量控制。常见的工具有Charles、Fiddler它们都支持设置延迟、丢包、带宽限制。把代理服务器的地址填到测试机上整个手机的网络流量就会走这个通道模拟起来非常顺手。注意使用代理工具时请留意企业内网合规要求并且不要用于任何违规的网络访问。弱网测试工具只做延迟、丢包、带宽限制这类常规功能即可。再往深一点说MOBA这类游戏掉线重连是测试必须重点压的场景。掉线以后玩家角色在服务器端是怎么处理的是站在原地挨打还是AI托管继续作战重连回来之后当前的血量、金币、等级、装备和经济状态能不能和服务器完全对齐这里最容易出那种“看着连回来了实际数据差了一分钟”的隐蔽bug。我的建议是测试掉线重连时不只要测“能不能连回来”还要把掉线前后的本地操作记录和服务器日志对上看数据到底丢没丢。3. 自动化测试落地从手工到持续回归的进阶之路手工测试再多也顶不住回回归的痛苦。尤其是游戏每周更新一个版本、每两周加一个新英雄的节奏你让测试人员每次都手动把核心玩法跑一遍用不了三轮他们就疲惫了注意力一散bug就溜过去了。所以自动化测试不是可选项是规模化研发的必选项。但自动化的落地方式和通用软件不太一样我给你捋一下我自己的实际经历。3.1 先动手搭环境接口与协议层自动化是性价比之王如果你团队的测试工作量已经很大但还没有任何自动化基础我的建议是从接口层自动化开始而不是一上来就做UI自动化。原因很简单接口自动化的开发和维护成本低得多跑一轮只要几十秒覆盖的是逻辑正确性——也就是我前面说的数值、状态、结算这些核心问题。UI自动化适合验证界面跳转和流程但游戏UI变动太频繁每个版本都在调脚本维护成本高得吓人。接口层自动化用什么框架我用的最顺手的是Pytest。在Python测试生态里Pytest是老牌了pu器uitive、简洁还有一个很大优势就是插件体系丰富。它是Python语言为主但测试的东西不限于Python服务。游戏的服务端只要开放HTTP或WebSocket协议Python都能直接调。就算你们用的是私有TCP协议也没关系Python里直接用socket连上去把请求包按你们的二进制格式拼出来发出去一样能测。我当时给一款SLG项目搭了套接口自动化用的是Pytest Requests专门跑核心经济系统的接口。一组用例覆盖签到、充值、抽卡、购买体力、挑战副本、结算奖励等20多套玩法接口。每轮版本更新CI里自动跑一次十几分钟出结果比人工点一小时快得多而且是凌晨跑天亮上班直接看结果。基token登录、余额充足与否、角色等级条件等前置数据由测试框架自动造出来。第二步按用例里的步骤依次调用接口。第三步拿到返回值后做断言断言的是三样东西返回码、关键字段值、落库数据变化。比如抽卡接口跑完库里玩家的抽卡次数应该1并且当次抽到的稀有卡应该在结果列表里。这些细节都验证到才算一个真正可用的接口用例。接口自动化的框架结构其实很简单。最外层是conftest.py放公共fixture比如创建测试账号、清理脏数据、登录token。中间层是封装好的API操作函数把“登录”“战斗”“抽卡”“商店购买”这些动作封装成可复用的方法。最上层是具体的测试用例文件把业务场景串起来。这套结构的关键是把公共数据和业务数据分开不然测试用例之间共享状态一个用例改了数据另一个用例就跟着挂了白排查半天。3.2 UI自动化选型Airtest与Appium的取舍UI自动化在游戏里的应用比接口层要谨慎得多。因为游戏UI是渲染引擎画出来的不是操作系统原生控件这意味着很多通用UI自动化框架选不到游戏里的按钮。游戏UI自动化大体有两条路线一个是图像识别路线一个是引擎内取控件路线。Airtest是网易开源的UI自动化框架走的就是图像识别路线。它对跨平台支持得不错支持Android、iOS、Windows以及Unity引擎。核心用法是截图驱动你把游戏界面的某个按钮截图放到脚本里执行时就通过图像匹配去找到屏幕上的对应位置并点击。好处是不用改游戏代码坏处是换了一套皮肤或者改了布局截图就得重新弄维护量不小。但Airtest作为冒烟测试和探索回归工具真的非常好用。比如每天早上起来先用Airtest脚本把主界面、商城、背包、设置、战斗入口依次点一遍过一遍冒烟确认基本界面和流程没问题再让人工深入去测效率会高很多。Appium走的是原生控件路线对原生App的UI测试非常合适但对游戏引擎渲染的界面支持有限。如果是混合应用——外层是原生壳、里面嵌了游戏场景——那Appium可以测外层壳的安装、启动、权限弹窗、账号登录页这些原生部分游戏内场景还是得交给Airtest这类图像识别工具。两者不是互斥关系很多团队是“Appium管壳、Airtest管游戏、Pytest管接口”三层并行。还有一个现在讨论度很高的路是基于游戏引擎的自动化测试。Unity项目有官方的Unity Test Framework可以写C#的PlayMode测试直接在编辑器里运行验证逻辑代码是否正确。这种测试跑起来最快适合验证纯逻辑层。还有一种玩法是用热更新框架或者开发团队的专用接口来做测试比如给测试开一个内置控制台、或者用命令行参数驱动游戏进入特定战斗再配合自动化工具操作UI可以造出很复杂的测试场景。但这些技术方案需要开发团队从一开始就预留后门属于“测试基建”规模足够大时值得投入。3.3 让自动化在CI流水线里真正跑起来自动化脚本写好了如果只是放在本地偶尔手动跑价值就少了一大半。真正的价值在于把自动化接进持续集成流水线里提交代码自动触发、编译完自动部署、凌晨自动跑测试、天亮一上班看报告。这一整套流程走通了测试才能从“质量保证的最后一道关”变成“开发过程里的一个实时仪表盘”。我实践下来一个能用的流程大致分这几步首先开发提交代码到测试分支CI触发编译打包。这里有个细节测试环境用的包要单独出最好打一个“Debug版”或者“测试版”里面带上日志开关、FPS显示、内存监控面板、GM指令等辅助工具。不带这些工具的包测试很难定位问题。第二步编译产物自动部署到测试服务器和设备群。性能允许的团队可以拿一批真机直接挂上去什么品牌型号都放一台组成真机机房。第三步CI自动跑接口自动化用例跑完后跑Airtest冒烟用例。结果统一汇总到测试报告平台。第四步用例挂了就把失败日志、截图、录屏一并收集起来自动发送到群里。我印象最深的体验是流水线刚接起来的第一周几乎每天早上都会收到两三个自动化失败的推送群里一阵哀嚎。但坚持跑到第三周大家慢慢习惯了这些通知开发自己都能看着报告定位到是自己改坏的地方还没来得及喊测试就已经把hotfix提交了。这个场景真的让我深刻体会到——自动化测试的意义与其说是帮测试省力不如说是把质量反馈的周期从以天计算压缩到了以小时计算。4. 性能、稳定性和兼容性的测试实施如果说玩法逻辑是游戏的心脏那性能就是游戏的血管。画面再好看帧率掉到十几帧玩家一样卸载。这一节就聊这些偏“硬”的测试科目每一项都要动手实测纸上谈兵没用。4.1 帧率、内存和耗电的可量化监控做性能测试第一步是先定标准。没有标准就没法谈测试。我常用的标准是以主流中端机型为基准在复杂战斗场景中帧率不低于30帧平均不低于45帧场景切换的加载时间不超过3秒内存占用在低端机不超过700MB在中高端不超过1GB。耗电的标准不特别好定但可以横向对比玩10分钟温度不超过45度掉电不超过百分之多少在不同机型上有自己的阈值。帧率怎么测Android机最简单的方法是打开开发者选项里的“GPU呈现模式分析”和“帧率显示”系统会把每帧绘制的时间直方图画给你看。更准确的方式是用PerfDog这类工具连接手机它能看到实时的FPS、帧时间分布、CPU占用、内存占用。PerfDog的商业版是收费的但试用版和部分开源替代方案也足够日常使用。iOS设备用Xcode自带的Instruments就可以Xcode连接真机之后能拿到按帧统计的渲染性能数据。我这几年测试下来内存泄漏是手游最常见的老大难问题。它的特点是你玩一个小时内存没崩但挂着游戏过一夜第二天发现内存已经吃掉2G了。这类问题的测试方法其实很简单长时间挂机测试。打开游戏进入一个稳定状态然后用自动化脚本或者简单的手工操作每隔一段时间截图记录一次内存占用拉个趋势图看内存是平稳波动还是一路爬升。一旦发现内存只进不出那就是泄漏让开发配合抓堆栈定位到是哪张Texture、哪个AudioClip、哪个对象池成员没释放。我见过最离谱的一次一个SLG项目的地图组件每次切场景都会多留一份残留数据导致连续切换二十次后直接闪退。类似的问题没有长时间挂机监控很难复现。耗电控制这块硬件厂商会在游戏运行的高性能需求下释放CPU频率如果开发没有做好帧率限制就会出现全程满帧运行的“偷跑”现象。解决思路一般是对游戏做分级画质检测到低端机自动降分辨率、关闭阴影、调低特效密度。测试人员要做的就是造出低端真机、跑高负载场景、确认降级策略真的触发了以及降级后画面是否还在可接受范围内。4.2 Monkey测试与异常场景的极限施压Monkey测试是Android平台上一项经典的压力测试方法它通过向系统随机发送伪随机的用户事件流——点击、滑动、返回、调整音量、切换应用等等——来测试应用在高强度随机操作下会不会崩溃。这个方法的逻辑相当狠猴子都会乱点但真正的玩家也会乱点。具体操作很简单Android SDK自带monkey命令一条命令行就能跑。比如adb shell monkey -p com.yourgame.package --throttle 200 -s 12345 100000这条命令的意思是对指定包名启动monkey测试每个事件间隔200毫秒用12345作为随机种子连续发送10万个事件。如果游戏在五万个事件内崩溃基本可以确定有稳定性隐患。我习惯让Monkey测试每轮版本都跑一遍一般持续6到8小时中间结合查看logcat一旦发生crash用adb logcat把崩溃前后的日志抓出来能看到堆栈信息这能帮助开发快速定位。这里有个小技巧监控崩溃不只看“闪退”还要看“错乱”。有些bug不会导致程序退出但会让界面状态变得一塌糊涂比如背包里的道具错位、角色动作卡住、UI贴图花屏、点击某个按钮没有可预期的反应。Monkey测试之后页面状态校验是必须要做的人工复查步骤。我在实际流程里会在自动化Monkey测试结束后让测试人员打开APK包手动点一遍核心页面确认主链路功能没有遭到结构性的破坏。4.3 兼容性不是把APK装到每台手机上就完了兼容性测试的目的是确认游戏能在一大堆不同配置、不同品牌、不同系统的设备上稳定运行。很多人以为“安装打开不闪退”就是兼容性达标其实陶吧各有一层又一层的问题。屏幕比例不同导致UI错位处理器规格不同导致性能实际表现各异显卡或GPU驱动不同导致渲染的效果有差异操作系统版本不同导致权限逻辑不一致防截屏/录屏机制在某些系统上阻断游戏画面等等。这些问题只有真机测试才能发现模拟器上跑不出这些差异化现象。所以我建议搭建一套真机兼容矩阵哪怕规模不大也至少把三个维度覆盖好操作系统分布主流Android版本至少各一款机型iOS上覆盖近三代系统版本硬件档次分布一台两年前的入门机、一台中等价位机、一台最新旗舰机这已经能暴露性能分级问题屏幕比例分布标准16:9、刘海屏19.5:9、挖孔屏20:9、折叠屏的特殊比例兼容性测试怎么做效率高核心是先做自动化冒烟兼容。拿一个脚本自动往测试设备安装游戏、启动、登录、进入战斗场景、截几张图、退出。所有设备同时跑半小时之后所有截图汇总出来测试人员统一看图判断画面是否异常。这套流程能快速筛掉那些“装不上、闪退、黑屏、花屏”的大问题剩下的精细UI适配问题再交人工去逐个设备确认。5. 常见问题与排查技巧实录做游戏测试这么多年有些问题是反复出现的。我把自己实战中遇到的高频问题整理成一个速查表再挑几个典型的说说排查思路准备上车的读者建议保存下来对照着用。问题现象常见根因方向排查手段角色卡在某个场景里无法移动状态机未复位、碰撞体残留、导航网格失效检查状态切换日志、查看Transform信息、检查Trigger技能伤害偶尔丢失网络延迟补偿错误、判定帧与动画帧不一致、服务器裁决与客户端表现不同步对比客户端日志与服务器结算日志、回放战斗录像背包物品数量异常扣物品和发物品逻辑竞态、数据库写入覆盖、补发补偿逻辑重复执行查看数据库金额变动流水、在关键方法加日志、重放异常操作序列切场景后内存持续上涨Texture/Audio资源未卸载、对象池容量无上限、场景单例未清理记录内存趋势图、抓堆栈定位引用持有者、Profiler分析部分机型只有声音没有画面图形API兼容问题、着色器版本不匹配、一次加载纹理数量超上限导致黑屏对比正常与异常机型的GPU信息、抓取渲染Log、降低显存压力复测充值到账延迟或丢失支付回调与发货流程的时序问题、客户端与服务器状态不一致、回调重试机制缺失检查支付回调日志、核对订单状态表、模拟支付回调节点异常过场动画和对话卡住资源异步加载未完成时触发表现、事件监听被提前释放、UI层级被遮挡检查异步加载回调链路、确认所有UI事件在进出场景时是否重新挂载5.1 技能伤害丢失一次真实的排查复盘技能伤害偶尔丢失这个问题真的很让人崩溃因为它不是必现的一周未必能复现一次。前两年做一个MOBA类项目时就遇到过某个英雄的2技能偶尔打出去全部命中但伤害结算只有一半。最开始测试组怀疑是数值配置错误盯着表里查了半天也没发现问题。后来又怀疑是技能描述不对但对照策划案也完全一致。最后是把问题定性成“偶发”决定加日志重兵排查。我们当时同时在客户端和服务端各加了一层日志把一次技能释放的完整链路全部打出来客户端记录技能指令发出时间、技能ID、目标ID、命中判定位置服务端记录收到指令时间、裁决结果、伤害数值、暴击与否。用脚本反复触发这个技能跑了整整一天半终于抓住了两条对不上的日志服务端收到的目标ID有12个但客户端判定命中的是13个。为什么会差一个继续追踪发现是网络抖动时客户端对第13个目标发出了一次极快的预测判定但服务端还没有同步到该目标的最新位置就开始了裁决落空也在情理之中。根因清楚了这个英雄的技能有“后撤步”的前摇如果玩家在技能后撤步发出的瞬间恰好处于目标快速位移的窗口客户端预测命中了服务端按旧位置裁决就miss了。最后开发在服务端的同步算法里加了一条“目标瞬时位置缓冲”的处理问题才彻底消失。这个案例让我印象极其深刻因为它告诉我一个道理网络同步类的问题别靠眼睛猜一定靠日志定责。测试工具再花哨最终在问题定位上起决定作用的依然是干干净净的日志链路。5.2 弱网测试怎么造出可复现的场景很多测试同学跟我说弱网测试难做因为家里网络太好想模拟卡顿都模拟不出来。其实方法很成熟关键是不要靠路由器拔网线去碰运气。Android和iOS都有比较方便的弱网模拟手段。iOS上Xcode自带的Network Link Conditioner就可以针对当前连接设置延迟、丢包、带宽设置之后你在手机上的任何流量都会按照这个配置走。Android上相对麻烦一点UI层没有全局开关但可以借助Charles等工具在PC上把手机代理指过去然后对代理配置弱网策略。注意这类代理工具的使用要限于企业内网或自己的测试环境不要触碰任何违规翻越的边界这一点务必谨慎。还有一个我常用的“穷办法”用两台手机一台正常连Wi-Fi另一台开热点把测试机连到热点上然后人在楼道里来回走等信号弱的时候下手时机。这种“物理弱网”虽然不好量化但能模拟出非常真实的移动网络环境比数字模拟往往更贴近真实玩家体验。两种方式配合着用数字模拟跑测试用例物理弱网做抽查验证。5.3 中断测试容易被遗漏的重磅用例做游戏测试中断测试是我个人的心头好。所谓中断测试是指在游戏运行的过程中强行插入来电、短信、闹钟、微信通知、应用切换、下拉状态栏、锁屏等系统级事件检查游戏能否正确处理这些打断。这类测试为什么重要因为现在手游以社交为心脏玩家挂机时一定会切出去回微信、接电话。如果游戏被切到后台超过三十秒回来要么黑屏要么闪退那玩家给差评是免不了的。中断测试的用例怎么写我列几个最典型的对局中接起电话通话端保持后台挂断后游戏能否快速恢复对局而不掉线观看广告中途锁屏再解锁时广告进度是否丢失、奖励是否正确发放切到其他应用再切回来游戏是重连服务器还是本地恢复本地数据与服务器数据是否需要二次确认对局中系统内存不足Android系统回收游戏进程重进游戏后能否回到大厅而不丢账号状态这些测试听起来简单但每一个都不能想当然。我遇过最坑的一次是游戏切后台再切回来本地缓存和服务器数据不一致导致玩家金币数量凭空多了一笔而玩家自己完全没发现。方便的是这种bug如果不做中断测试线上出了事就是安全事故级别。中断测试对测试人员的设备要求不低至少需要一台能够频繁弹通知的Root或开发者模式Android机以及一台能跑Xcode调试的iOS设备。简单来说就是手机上所有能打断你游戏的入口全都要测一遍而且要搭配不同场景反复测。5.4 Fuzz测试在游戏里的另类用法搞崩输入再谈兼容热词里“Fuzz测试”和游戏开发绑在一起很少见但我认为逻辑是完全成立的。Fuzz测试的思路是向系统输入大量随机、异常、非预期的数据观察系统是否崩溃或产生异常行为。这个思路在游戏里特别好用只是大多数人没往这个方向想。游戏客户端最常见的Fuzz对象是谁是输入框和协议数据。输入框里的昵称如果有超长字符、全角半角混合、表情符号、甚至SQL注入词汇会导致什么轻则UI错乱重则崩服。协议端的Fuzz则是往测试服发一堆非法字段和越界数值看服务器是直接崩溃还是优雅拒绝。我在一个H5游戏项目里就用Python随机生成了几百条畸形请求把所有边界字段都打了一遍还真打出了两个服务端未捕获异常导致一串后台进程重启。Fuzz测试做得好能在上线前帮你堵住一大波外挂入口和异常输入的相关漏洞。Fuzz的审计意识一定要有不是测出来崩了就行还要看崩溃时的响应是否把数据库拖垮了日志是否被刷爆有没有把其他玩家的会话也弄断。这类测试建议在独立的环境里跑远离正常测试库不然一天就能把环境搞烂。6. 最后再说两句掏心窝的话游戏测试这行确实不轻松。它不像开发那样有明确的产出物你辛辛苦苦发现的100个bug里有80个在开发眼里可能是“小问题”但正是这些小问题叠加在一起让玩家喊出那句“这游戏好烂”。我始终觉得做游戏测试的人要有一种“偏执的认真”一个数值对不上不要想着“反正影响不大”而要多追问一句“为什么会差”一次偶发崩溃不要想着“可能是网络抖动”而要多花半小时把日志抓齐。正是这种较真才能把一个游戏从60分的完成度推进到90分的品质。如果你正打算入行游戏测试或者正在为一个小团队的测试方案发愁我的建议很简单先把手工测试的用例结构建好再逐步引入接口自动化、UI自动化、CI集成、性能监控一步一步来。不需要一步到位但只要这套体系的第一块砖铺下去了后面每一块都会变得越来越顺。我这里讲的每一段经验都是从真实的项目里摸爬滚打出来的希望能帮你在游戏测试这条路上少踩几个坑多省几晚加班。测试不是开发的敌人而是质量合伙人。这句话是我做了这么多年游戏测试最想送给同行们的。