自动关联目录：自动化测试

1. 定位

UE 项目常常"没有测试"，因为游戏逻辑不好测。但完全不测的结果是：改动只能靠手点验证，回归成本高到没人敢重构。

一句话定位：UE 的自动化测试分三层：单元测试 → 功能/集成测试 → 冒烟测试。从最便宜的一层开始做。

2. 三层

层	测什么	成本	稳定性
单元测试	纯逻辑、算法、数据结构	低	高
功能/集成测试	系统组合（GAS、网络、资产加载）	中	中
冒烟测试	能不能启动、进关卡、跑一段	高	低（但价值大）

建议顺序：先做单元测试（最便宜），再做冒烟测试（防最坏情况），功能测试按需。

3. UE 的机制

机制	说明
Automation Tests	引擎自带的测试框架（`FAutomationTestBase`）
Commandlet 驱动	无人值守下跑测试
编辑器内运行	Session Frontend 里手动跑
Gauntlet	自动化运行游戏并验证（冒烟/端到端）

IMPLEMENT_SIMPLE_AUTOMATION_TEST(FMyTest, "MyGame.Basic.Math",
    EAutomationTestFlags::ApplicationContextMask | EAutomationTestFlags::ProductFilter)
bool FMyTest::RunTest(const FString& Parameters)
{
    TestEqual(TEXT("Add"), Add(1, 2), 3);
    return true;
}

4. 什么值得测

值得	不值得
数值/公式（伤害、掉落、经济）	纯表现（特效、UI 布局）
状态机与规则（胜负、条件）	需要人眼判断的效果
序列化与存档兼容	一次性脚本
网络复制的关键路径	—

GAS 的数值结算尤其值得测：它涉及 Execution Calculation 与聚合顺序，手算容易错（见 UGameplayEffect）。

5. 冒烟测试

项	说明
目的	防"根本起不来"
内容	启动 → 进关卡 → 跑一段固定回放 → 无崩溃无错误
频率	每次构建
成本	高，但能挡住最坏情况

冒烟测试 + 崩溃聚合是最实用的组合（见崩溃与 Dump）。

6. 代价与权衡

设计	收益	代价	什么时候不该用
单元测试	便宜、稳定	覆盖面有限	从不做——这是最该先做的
冒烟测试	挡住最坏情况	慢、偶发失败	项目早期可先手动
端到端/回放测试	接近真实	维护成本高	小项目不必
追求高覆盖率	—	投入产出比下降	游戏项目通常不追求
测试不稳定（flaky）	—	比没测试更糟（大家忽略失败）	不稳定的测试要修或删

一条硬经验：不稳定的测试会训练团队忽略 CI 失败，那 CI 就白建了。宁可少而稳。

7. 踩坑与排查

坑	现象	怎么验证
完全没测试	回归靠手点	从数值逻辑开始加
测试不稳定	大家忽略失败	修或删除
只测琐碎逻辑	关键路径没覆盖	优先测数值与规则
测试依赖渲染/时序	flaky	改成纯逻辑
没接 CI	测了也没人跑	见构建农场与 CI
测试跑太慢	拖慢流水线	分层，慢的每日跑

8. 排查顺序

1. 有没有测试？→ 从 GAS 数值/规则开始加单元测试
2. 测试稳不稳？→ 修或删 flaky 的
3. 有没有冒烟测试？→ 挡住"起不来"
4. 是否接入 CI？→ 见 CI 篇
5. 慢？→ 分层

参考

构建农场与 CI · UGameplayEffect · 崩溃与 Dump
性能方法论（性能基线也是一种自动化验证）