目录

前言

项目每时每刻都有修改，新开发的功能、BUG修复、配置修改…..可以说 QA 大部分时间就是对着修改在工作的。这篇大概说下，拿到自己负责功能的一条修改后，我怎么判断它影响了什么，以及该怎么验证。只是记录我现在的做法，不算什么标准答案。
我平时能看到的修改，主要是 Lua（项目用的是 UnLua）、表格配置，以及 Editor 里的 DA 和各种UE资源。
拿到一条修改后，工作路径大概是这样的：
确认修改内容 > 判断影响范围 > 预期修改后表现 > 实际测试回归

确认修改内容

先说一个前提：dev 阶段开发中的功能，我基本不会逐条去看它的修改。功能还在开发的中间阶段，这时候一条条去看修改，性价比老实说我觉得不高，不如去看点别的内容。

Lua

Lua 的修改我一般直接丢给公司的 Agent，给它一条 P4 里的 CL，它会直白地告诉我这次的变更概述、功能描述、潜在问题和测试建议。
但有一定的局限性，这部分放下面说。

表格

表格用diff工具 BCompare 对比。
大部分时候看的是状态指令表：确认策划是怎么配置的，和其他同类型的功能有没有差异，有差异的话就去确认一下。另外就是一些道具表、关卡表之类的，重点确认别出现因为配置错了、导致功能直接用不了的低级情况。
主要是表格配错了，很容易影响到一大片功能，甚至游戏服务器都起不来，工作群里被大伙儿轮番@你的情境可不好受…

DA和UE资源

这些 UE 资源，我通常是在 Editor 里看的。
DA 我大部分看的是能力数值本身。
UE资源那可太多了，如果改的是BP，思路就会像是Lua那样，得知道改动的内容或者逻辑是什么，具体改动具体测，没法在这里总结….
至于一些动画或者特效资源，得在Editor里面自己细看。

如果功能很重要

不管修改大小，测试前总得先弄清楚这次想改成什么样。如果这个修改，是属于某个非常重要的功能的话，除了上面说的这些，还需要找到这条修改的归属人是谁，向那个人明确确认修改后的预期，最好还要知道修改的背景，也就是为什么要这样修改，是为了修BUG？还是说需求变了？

还不太会看的地方

Lua 调到 C++ 的时候，C++ 我看得比较少，那一块的影响的判断，我还把握不好。（在学了在学了

判断影响范围

影响范围怎么判断，老实说很难讲清楚。主要还是靠工作经验，以及对项目本身的理解，看得多了，大概就能判断出一条修改的影响范围有多大。
因为功能逻辑上的改动，不像是母材质，或者关卡那样，可以先通过资源引用找到一部分直接关联。逻辑上的东西很多时候都是用起来才知道影响了什么东西，特别是3C功能的逻辑。
影响范围超出自己负责的模块时，务必要同步给其他 QA。

有个个人比较喜欢用的方法，就是每个版本都看一下项目里的分工表，一路看下来，就大概知道自己的项目有什么内容了，当然平时自己也要多玩玩项目的游戏。

举个例子

有一个变身功能，变身以后有很强的 3C 性能：跑得很快、跳得很高，甚至能无限飞行。原本的设计是只能在某一个关卡里使用，后来要求把使用范围放宽到整个游戏的所有关卡，无限飞行则仍然只能在原来那个关卡里用。
需求上只是放宽了使用范围，但这之后要测的耦合，一下子从一个关卡，变成了整个游戏的所有关卡，测试所需的人天几乎翻了一倍。

确认预期与实际测试

AI不能全信啊

前面说 Lua 我一般直接丢给 Agent。
它给的测试建议我也会测，不过只是当作补充，测什么还是以我自己的判断，以及和程序确认为主。
当 AI 拿到的只有当前修改、缺少其他代码和项目背景时，它不一定能判断影响了哪些操作的手感，也不一定能看到整个项目的全貌。所以它给出来的东西，我更多是当成一条待验证的推测，而不是直接拿来当测试范围。

一个公开的例子：冲刺跳的速度

工作里的修改不方便贴，拿自己 Demo 里的一个例子说。
之前给 CMC 子类加了冲刺，修改本身很小：

bool UGymCharacterMovementComponent::IsSprinting() const
{
    // 有想要冲刺的意图，处于行走状态，不在下蹲状态，则进入冲刺状态
	return bWantsToSprint && MovementMode == MOVE_Walking && !IsCrouching();
}

float UGymCharacterMovementComponent::GetMaxSpeed() const
{
    //冲刺状态返回冲刺速度，冲刺速度是1000
	if(IsSprinting()) return SprintSpeed;
    // 其他情况调用父类同名方法
	return Super::GetMaxSpeed();
}

只看这段修改，AI给的推测是：IsSprinting() 要求 MOVE_Walking，起跳以后变成 Falling，IsSprinting() 不再成立，GetMaxSpeed() 回落到 600，冲起来的 1000 应该会被拉回去才对。

但实测结果是，按住 Shift 起跳，Max（p.VisualizeMovement 1 调试信息中 Velocity 那一行的速度上限）显示 600，但水平速度保持在 1000，和AI给的推测不一致。速度上限变了，不代表已有速度立即下降。保持 1000 是否符合设计，还要回到需求判断。具体原因就不再展开了，感兴趣的话可以看《给Character换一个自己的CMC》。

至少从我自己的使用经验来看，我使用AI容易遇到的两个问题是，推测冒充事实，以及遗漏前提…这两点在测试角度上来看都是大忌。
后面有机会的话会再出一篇AI踩坑记录的文章。

PIE和包体补丁

除非测试环境受限，我多数都会将修改打个补丁，放到游戏包体里面，在包体内确认最终修改后的表现。
一是因为大世界项目PIE流畅度属实是灾难，就算是跳过了着色器编译。
二是，玩家最终玩到的是我们的游戏包体，而不是 Editor。有很多BUG都是PIE里正常，但是包体内出现问题，表现问题和逻辑问题都有。所以最终修改后的表现必须要以包体为准。

最后，记得更新用例（笑