目录

前言

平时测3C比较多，这篇讲一下拿到一个新的3C功能之后，怎么展开测试，重点是状态、操作、动画表现，以及它和环境的交互。也算是目前工作的一个快照吧，肯定是还有很多局限性，以及可以改进的地方的。
工作里的具体细节不方便展开，所以工作那部分只讲做法；涉及实现细节的例子，用的是我自己 Demo 里的东西。

拿到一个新的3C功能后，测试路径大概是这样的：
了解功能 > 制定测试计划 > 测试功能本身 > 与其他3C功能的耦合 > 与整个游戏世界的耦合

了解功能

3C 功能的特点

一般来说，3C功能有这么几个特点，后面很多测法都是从这里来的。

• 注重细节。3C 和玩家的操作手感直接相关，一个很小的问题都可能被玩家感受到。而且作为会被反复使用到的基础功能，一个细节往往会被多次呈现到玩家面前，即使是很细微的问题玩家也很容易察觉到。所以测试一个表现时，要多次反复看、放慢看。
• 协同性。3C 的三个 C 是相互关联的，比如角色移动就会和相机跟随互相影响。一个完整的 3C 功能大概率会涉及到所有的 C。所以测试时也要看这三个 C 配合起来的表现。
• 开放性。3C 大部分时候都发生在一个 3D 空间里，角色和相机可以处在各种不同的位置、角度和环境里。不可能真的把所有情况都测一遍，所以实际测试的时候，需要想办法把这些无限的情况划分成一些有限的场景和区间去覆盖。
• 强耦合性。3C 基本贯穿整个游戏，一套 3C会被用在整个项目里的各种地方，一个看起来很细微的修改，实际影响到的东西往往会比想象中的多得多。

需要确认的内容

拿到一个新功能，我一般先看这几样东西：

• 策划案：让我更全面地了解这个功能，决定用例怎么写；同时也要看这个功能会给整个游戏带来什么影响，需要同步给哪些别的组的 QA。
• 配置表、资源：大部分是拿来检查的，同时也用来补全用例。具体后面测试那一节会说。
• 代码：老实说我看得很少，一般会先丢给 Agent 速览一遍，看看功能大概是怎么实现的。

尽量看看实现

拿我自己 Demo 里的一个例子说。之前在 Demo 里搭了一个测试场地，其中一组是不同高度的台子，用来测角色最高能跳上多高。角色用的是引擎默认参数，JumpZVelocity 是 420，按 v²/2g 算跳跃顶点大约 90 cm，实测也差不多是这个数。但 120 cm 的台子，它也能上去。

翻了下落地判定 IsValidLandingSpot()，里面有这么一段：

// Reject hits that are above our lower hemisphere (can happen when sliding down a vertical surface).
// 胶囊体下半球上边界及以上的碰撞点，不认为是有效落点。
const float LowerHemisphereZ = GetGravitySpaceZ(Hit.Location) - PawnHalfHeight + PawnRadius;

// 如果碰撞点达到或高于下半球上边界，则不是有效落点。
if (GetGravitySpaceZ(Hit.ImpactPoint) >= LowerHemisphereZ)
{
	return false;
}

简单地说，就是胶囊体下半球的侧面碰到台子边缘，在满足其他落地条件时，也可能被判定为落地（如下图），站住以后剩下的那一小截高度，其实是走上去的。所以在这个 Demo 里，能上去的台子高度会超过角色正常的跳跃顶点，Demo 里实测 120 的台子能上。

所以实际测试的时候，不能只看角色能跳多高，还得看角色实际能上多高的台子。前者是跳跃本身的高度，后者还会受到胶囊体大小、落地判定这些实现细节的影响。如果只按照跳跃高度去摆测试台子，很容易把测试边界搞错。

制定测试计划

确定所需测试资源与人力

了解完功能之后，就可以开始确定具体怎么测了。
首先是测试资源，需不需要新的 GM 工具，用例是否需要评审走读，是否需要多人协作，以及大概要投入多少测试人力、是否需要专项 QA 介入。这些都需要尽快定下来。

写用例

类似的功能，项目里有一份模板用例。模板用例里已经有完整的用例框架（使用说明、功能流程、耦合模块、联机、通用测试），也有很多可以直接执行的通用用例，照着它去写自己负责功能的用例，能减少很多遗漏。然后在这个基础上，再补功能本身的用例。

另外我也经常会用AI来写一版用例，对比着看看自己的用例有没有遗漏，最终还是得自己判断。

常见的基础测试面

除此之外，还有一些 QA 基本都会关注的测试面，也需要单独过一遍，不能因为功能本身看起来比较简单就漏掉。
比如：

• 边界与极值：数值溢出、计算精度、极端场景
• 时间周期：跨天、跨时区、客户端还是服务器时间、活动开关时间
• 中断：流程各阶段退出，顶号、重登、断网重连、切后台、杀进程等
• 联机：多人情况下的表现和同步
• 网络与异常：极限操作、重复请求、失败后的重试与提示、核心流程的保底逻辑
• 数据：数据是否持久化、怎么刷新、老玩家旧数据是否兼容、后期扩展是否有问题
• 耦合：状态冲突、老功能逻辑是否受到影响、是否需要额外适配
• 性能：速度过快对 Streaming 的影响、多人同屏等
• 兼容性：不同平台、不同画质、不同分辨率、帧率等
• 运营与后台：功能开关、审核、运营指令等

这些是比较基础的测试面，不一定每个功能都会涉及到，但我都会尽量把它们都过一遍，确认当前功能有没有对应的测试点。

功能本身的测试

资源和配置检查

动画资源：先在 Editor 里播放检查一遍，比在游戏里看得更清楚一点。然后根据项目的命名规范，大概就能知道这个动画资源在游戏里是干嘛用的、什么时候会播出来。再配合游戏包体里的动画检查 GM，看看游戏里实际播出来的动画，和 Editor 里的对不对得上。
DA：主要看功能本身的数值。比如一个功能有能量条机制，就会看什么情况下开始恢复、不同情况下的消耗速率是多少、能量条最大值是多少等等。
配置表：多数情况下会涉及状态表。不同项目的配置规范不太一样，最好的方法还是直接找负责功能的策划，确认这个功能用到了哪些配置表、有没有新增的配置表，然后再做相应检查。

状态冲突

3C 功能之间经常会有状态和操作上的冲突。比如角色正在移动的时候，按下跳跃应该进入跳跃；正在下落的时候，按下某些操作可能就应该被拒绝。类似这种“当前是什么状态，接下来能做什么”的关系，是我测新 3C 功能时比较关注的一块。
具体项目里的状态、指令和配置表就不展开了，主要说一下我的测试思路。拿到一个新功能后，我一般会先搞清楚它会产生哪些状态、有哪些操作，以及这些状态和操作分别会在什么情况下出现。这个通常直接问程序、策划最快，也可以自己开调试工具把功能完整走一遍。
然后再看它和原有 3C 的关系。哪些操作应该允许，哪些应该拒绝，以及新操作生效后，原来的状态应该继续保留还是被取消。这里一部分可以从策划案里的设计预期确认，另一部分就是靠自己去想有没有容易漏掉的边缘情况。
最后再回到游戏里实际跑一遍。除了测试新功能自己的正常流程，也会挑一些比较容易产生冲突的状态和操作去试。如果发现关系不太合理，就录下来找策划、程序确认。
如果是一个和已有功能比较类似的新功能，我会测得更细一些，因为这时候除了验证新功能自己能不能工作，还可以直接参考旧功能，看看设计预期相同的部分，两者在状态和操作上的处理是不是一致。

一些个人测试习惯

• 抓动画切换的瞬间。单独播放一个动画时，往往看不出什么问题，但两个动画切换时，还涉及衔接、过渡和状态切换的逻辑，这时候就要多留意一下。
• 把各种可能性分区测试。角色可以 360° 转身，如果只是随便转几下，很容易漏掉某些方向上的问题。这时候可以把方向划分成多个区间，比如每 22.5° 一个分区，分别检查不同方向下的转身表现。这样就能把无限的可能性，转换成有限、可执行的测试用例。
• 一个表现要反复观看。有时候测一个表现，会过于注重脚步表现，而忽略了头部的问题；或者过于注重手部表现，忽略了脚的问题。一个表现要反复看，局部观察细节，整体感受下是否自然，这样测试结果才比较稳妥。一些不方便反复操作的，可以录视频多看几遍。
• 把角色当成真人。测试的时候，可以试着把角色当成一个真实的人，一个人跑起来、跳起来，大概会是什么样？再对比游戏里的表现，有没有哪里看起来不自然、不合理，或者和这个功能想表达的感觉不一致。这些地方都值得记下来，再和策划或者导演确认是不是需要调整。
• 善用 Slomo 指令，放慢看。有些动画衔接、动作瞬间的问题，在正常速度下不太容易看清楚，放慢以后就容易观察了。不过 Slomo 主要是辅助观察，最终还是要回到正常速度下确认实际表现。
• 对手感、数值敏感。数值变化可能会影响操作手感，而有些数值问题也会先表现为手感不对。测试时如果感觉角色跑得不对劲、跳得不对劲，除了确认实际表现，也可以回头检查相关参数，看看是不是数值或逻辑发生了变化。当然手感异常不一定就是数值问题，得看实际情况去排查。

功能的耦合测试

这一步主要想的是：这个功能放到了整个游戏世界之后，会不会影响到别的东西？下面举两个例子。

关卡或任务流程的逃课

一个是任务流程逃课。比如原本要求玩家打败沿途的怪物才能到达终点，但新能力可以让玩家绕过战斗，直接走到终点。
又或者出了一个能无限飞行的能力，原本设计需要玩家逐步跳跃才能抵达奖励点位，玩家可以直接飞过去拿到奖励，关卡策划辛辛苦苦设计的流程就被绕过去了。这种绕过是否需要修复，还要看它是否符合新能力和关卡的设计预期。

移动速度对性能的影响

另一个是移动速度对大世界关卡加载（streaming）的影响。
这类问题我一般会先同步给专门测性能的专项 QA，同时把速度数据同步给负责关卡的 QA。我自己会在 PC、PS、Mobile 上各挑一些机型简单跑一跑，看看高速移动时有没有明显的场景加载异常。自己的初步检查没发现明显问题后，再结合专项 QA 的测试结果判断。

整理思路

回头看，一个新的 3C 功能拿到手以后，我大概是从「它自己能不能工作」，一步步想到「它放进整个游戏以后会不会出问题」。大概可以分成三层。
第一层，它自己能不能工作。功能本身的流程、参数、资源，也就是前面了解功能、检查资源和配置，再实际验证正常流程这些事情。
第二层，它和原来的 3C 怎么相处。比如说走路的时候能不能进来？跳起来以后呢？下落呢？被别的状态打断以后呢？退出以后会不会留下什么？这一层基本就是状态冲突在测的东西。
我自己会把这几种关系简单理解成：允许和拒绝，回答的是「能不能进来」；取消回答的是「进来以后，原来的状态还在不在」。如果该取消的时候没有取消，原来的状态就可能一直留在角色身上。另外还要区分状态取消和操作意图保留。拿我 Demo 里的冲刺举个例子：始终按住冲刺键，冲刺中按下蹲，速度掉到 300；松开蹲，速度自动回到 1000，不用重新按冲刺。这里保留的是冲刺意图，蹲伏结束后它重新生效。被打断以后能不能恢复回来、恢复是否符合设计，也是这一层要看的。
第三层，它放到真实世界里会不会出问题。再往外，就会想到坡度、台阶、缝隙、高度、streaming、相机、网络、性能……前面只展开了其中几个。
功能一旦离开孤立的测试场景，就会开始和环境、和其他系统发生关系，测试维度也会越来越多。

题外话

由于 3C 比较基础和底层，很多功能都会影响到 3C 的表现，经常一遇到问题，大家的第一反应就是「3C 看看吧」。面对不断反馈过来的问题，还是要有耐心帮忙处理。
不过看得多了，有时候也能快速判断出来不是 3C 的问题。比如其他组反馈一个 BUG，说可能是 3C 的问题，但我排查下来发现更像是他们组的功能导致的，就会让报给我的 QA 单独开一个 BUG，转给对应组的程序跟进。