游戏测试全栈实战：从手工用例到自动化与性能优化

1. 游戏测试的本质：不是机械执行，而是研发场景的重构

做了这么多年游戏研发，我越来越觉得“测试”这个词被低估了。很多人以为测试就是点点点、找找bug、提交一下问题单，顶多是看策划文档写几条用例。但真正进入开发流程之后你会发现，测试在游戏项目里承担的是“质量模型设计者”的角色。你要是只把它当执行环节，后面上线时的返工量绝对让你怀疑人生。

先说清楚，游戏测试和我们常说的通用软件测试确实同宗同源，但游戏有自己的特殊体质。通用软件追求的是“功能正确”，游戏追求的则是“体验闭环”。举个最简单的例子：一个OA系统里，用户上传文件失败，你记一个bug，开发改了接口，流程恢复，这就完事了。但游戏里一个角色技能放出去没伤害，这个问题的根源可能关联到技能配置表、服务器判定、客户端表现、网络延迟补偿、数值策划表，甚至美术动画的播放时长和攻击帧对齐。一个问题背后经常牵扯三四个模块，它的排查链路远比普通CRUD复杂得多。

所以游戏测试第一件事，是搞明白自己要测的是哪一块。按我习惯的做法，先把测试范围粗暴分成四个大块，再分别设计方案：

1. 玩法逻辑测试：技能、状态、数值成长、NPC行为、任务流程、战斗结算、资源产出。这是游戏的心脏，也是bug重灾区。
2. UI与交互测试：界面跳转、按钮响应、异常操作、分辨率适配、多语言截断。这里面的坑看起来小，但最容易让玩家打出低分。
3. 网络与同步测试：延迟、断线重连、弱网表现、广播同步、帧同步与状态同步两种模型下的校验逻辑。多人游戏的核心都在这一层。
4. 性能与兼容测试：帧率、内存、加载耗时、长时间运行的稳定性、不同设备和操作系统的适配表现。这层直接决定你的游戏能不能上主流渠道。

这四块听起来不复杂，但真正的难度在于测试策略怎么跟研发节奏咬合。我见过不少团队测试计划写得特别漂亮，一到实际排期就被需求变更冲得七零八落。后来我学到一个原则：以版本里程碑为锚点，把测试工作拆成内嵌式动作，而不是事后大检查。每个里程碑开发完成前，测试提前介入，先跑冒烟再逐步深入。不要等所有功能做完了再排队等着测，那样你测的永远是昨天的旧代码，问题堆积到最后一天集体爆发，是谁都救不回来的。

这里多说一句热词里常刷到的“测试左移”概念。在游戏项目里，左移的核心不是让测试多开会多写文档，而是让测试直接参与玩法设计阶段的评审。比如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和格斗游戏，核心思路是：所有客户端运行同一份逻辑，服务器只转发操作指令。它的优点是同步效率高、带宽消耗小，缺点是对客户端逻辑一致性要求极高。如果两个玩家手机帧率不同，或者引擎浮点运算有微小差异，游戏里就会出现“我这边看到你闪现了，你那边看到我原地站着”之类的不同步问题。状态同步则是服务器说了算，客户端只表现结果，对一致性有保障，但服务器的计算压力和带宽压力都更大。

不管是哪种模型，测试网络层都要覆盖三类场景：

1. 网络切换场景：Wi-Fi切到4G、切换路由器、从电梯里出来信号恢复。要注意游戏能不能自动重连、重连后是否能快速恢复对局状态。
2. 延迟场景：模拟固定延迟，比如100ms、200ms、500ms，观察技能释放是否有明显延迟感、移动是否跟手、操作是否被吞。
3. 抖动与丢包场景：这是弱网里最容易暴露问题的场景。网络在短时间内忽好忽坏，丢包率从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. 常见问题与排查技巧实录

做游戏测试这么多年，有些问题是反复出现的。我把自己实战中遇到的高频问题整理成一个速查表，再挑几个典型的说说排查思路，准备上车的读者建议保存下来对照着用。

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集成、性能监控，一步一步来。不需要一步到位，但只要这套体系的第一块砖铺下去了，后面每一块都会变得越来越顺。我这里讲的每一段经验，都是从真实的项目里摸爬滚打出来的，希望能帮你在游戏测试这条路上少踩几个坑，多省几晚加班。

测试不是开发的敌人，而是质量合伙人。这句话是我做了这么多年游戏测试，最想送给同行们的。