验证——做出来的东西是否符合预期

测试 = 自动化断言「代码按设计工作」（对不对）。验证 = 判断「做出来的东西是否符合预期、有没有价值」（好不好、能不能用、有没有意义）。 测试可以自动化，验证往往需要人、AI、Bot 参与。对普通软件，验证≈功能验收；对游戏，验证是另一套东西——可通关性、可玩性、新手体验、趣味性——这些不能靠 gtest 断言，必须有人玩、自动玩、模拟世界运行。

一、测试 vs 验证

1
2
3
4
5
6
7
8
9
10
11
测试：自动化断言「代码按设计工作」
  → 单元测试、集成测试、E2E
  → 回答「对不对」——功能有没有实现
  → 可以自动化，结果确定（通过/失败）
  → 依据：设计文档、功能点、接口

验证：判断「做出来的东西是否符合预期、有没有价值」
  → 可通关性、可玩性、新手体验、趣味性、性能
  → 回答「好不好、能不能用、有没有意义」——体验是否符合预期
  → 往往需要人/AI/Bot 参与，结果有程度（好玩/一般/劝退）
  → 依据：设计意图、玩家体验、世界规则

游戏测试最核心的一点：普通软件主要验证「功能有没有实现」；游戏还要验证「设计的世界规则运行后产生的体验是否符合预期」。 这也是为什么游戏测试不能只靠 gtest，必须有人玩、自动玩、模拟世界运行。

1
2
测试：Damage = Attack - Defense → 断言等于 80   ← 对不对
验证：玩家能不能通关？好不好玩？新手会不会卡住？ ← 好不好

二、游戏的验证标准（十个闭环）

游戏可玩性验证是分层的闭环——每一层都是「输入 → 处理 → 输出 → 验证」，只是验证的尺度越来越大：

1
2
3
4
5
6
7
8
9
10
1. 运行不崩        启动闭环      —— 程序能不能跑起来
2. 核心循环能玩    可玩闭环      —— 玩家能不能完成基本操作循环
3. 玩家能理解目标  引导闭环      —— 玩家知不知道要做什么
4. 操作有反馈      反馈闭环      —— 每个操作有没有视觉/声音响应
5. 难度曲线合理    挑战闭环      —— 挑战难不难、卡不卡
6. 有重复游玩价值  循环闭环      —— 玩完一遍还想不想再玩
7. 边界情况不出错  健壮闭环      —— 各种边界情况会不会崩
8. 手感符合预期    体验闭环      —— 移动、跳跃、攻击的手感对不对
9. 不同设备正常    平台闭环      —— 不同设备/系统上是否正常
10. 长期玩不腻     留存闭环      —— 长时间玩会不会腻

每一层都是验证的一个维度。 测试（自动化）覆盖 1/7 这类「对不对」的维度；2/3/4/5/6/8/10 这类「好不好」的维度要靠验证。

三、验证方法一：可通关性——AI/Bot 迭代规则通关

验证「游戏能不能被完成」。 这是游戏验证里最基础的、也是最容易被自动化的一层。

内部 AI 迭代规则通关

Code Agent 不擅长像人一样连续操作复杂游戏系统——需要实时观察、精确移动、判断时机、连续输入。于是让 AI 通过迭代规则自动通关：

1
2
通不过 → 修改物理 → 还是通不过 → 增加速度
→ 还是通不过 → 调整碰撞 → Shift 加速 → 通关

这个测试的是「可通关性」——存在一条从起点到终点的可达路径，没有死路、没有卡死、没有穿墙、没有掉出地图。

Bot 测试 / 自动化游戏测试

1
2
3
模拟输入（Left/Jump/Attack）自动运行 10000 次
检查：是否卡死、崩溃、穿墙、掉出地图
大型游戏：AI 控制角色随机移动、随机攻击、随机探索，发现异常

可通关性验证的发现

  • 死路：存在无法通过的关卡
  • 卡死：角色卡在某个位置无法继续
  • 穿墙/掉出地图：物理/碰撞边界问题
  • 不可达出口：出口在逻辑上无法到达
  • AI 找到的最低成本解：AI 只关心 goal = reach_goal，可能找到「Bug 通关路线」——这暴露了设计上「正常路径」缺失或过难

可通关性 ≠ 可玩性。 AI 通关只证明「存在一条路」，不证明「这条路对玩家是合理的、有趣的」。AI 的 Shift 加速通关，可能只是它找到的最低成本解——人类玩家未必能发现，也未必觉得好玩。

四、验证方法二：可玩性——玩法测试（人工）

验证「玩起来是否符合设计」。 这是游戏特有的验证——测「玩起来是否符合设计意图」。

1
2
例如设计「玩家获得二段跳可以到达隐藏区域」，测试实际是否真的到达
检查：路线是否可通、难度是否合理、奖励是否有价值

玩法测试通常人工测试——因为「好不好玩」没法用断言表达。

1
2
3
4
5
可玩性验证的维度：
  路线可通    玩家能不能按设计路线走通
  难度合理    挑战难度是否在玩家能力范围内
  奖励有价值  收集/奖励是否值得玩家去拿
  机制可探索  核心机制玩家能不能发现、能不能玩出花样

五、验证方法三：新手体验——新手测试（第一次玩的人）

验证「一个从没见过这个机制的人，第一次玩会经历什么」。 这是游戏验证最容易被忽略、也最重要的。

开发者疲劳 ≠ 玩家无趣

1
2
3
4
「开发者已经玩腻了」≠「玩家会觉得无趣」
「开发者觉得有趣」也≠「玩家一定会觉得有趣」

开发者没有办法恢复「第一次」，所以不能用自己的感觉判断游戏。

新手测试怎么做

拿一个完全没接触过的人，不要解释，让他直接玩，观察：

1
2
3
4
5
第一次看到新机制：会不会停顿？「嗯？」——如果有，这是好信号
会不会主动尝试：跳、走、Shift、碰撞——如果他开始实验，更好的信号
失败后会不会马上再试：「刚刚好像差一点，再来一次」——非常好
发现机制后：有没有出现「哦——原来是这样」？——这个瞬间特别重要
通关后：「还有下一关吗？」——这才是最有价值的反馈

新手体验的关键指标

1
2
第一次接触 → 理解成本 → 发现速度 → 第一次成功
→ 失败后的重试意愿 → 机制掌握 → 掌握后的新鲜感还能持续多久

难 ≠ 卡

1
2
好的挑战让玩家产生：「我再试一次，这次应该可以。」
坏的挑战让玩家产生：「我不知道该怎么办。」

新手测试回答的不是「好不好玩」，而是「玩家能不能进入这个游戏」。 目的明确、反馈快、失败成本低、重试快、难度递进、机制新颖——这些是新手体验的验证指标。

六、验证方法四：趣味性——反馈密度

验证「单位时间内产生多少有效反馈」。 游戏趣味靠的不是「内容很多」，而是单位时间内不断产生有效反馈。

1
2
3
趣味 = 认知闭环的密度
  → 玩家不断经历「发现 → 尝试 → 反馈 → 理解」的闭环
  → 闭环越密，越有趣

趣味性的验证维度：

1
2
3
4
5
6
目的明确：玩家知道要做什么
反馈快：操作后立即有响应
失败成本低：失败不可怕，马上能重试
重试快：失败到重试的间隔短
难度递进：挑战逐渐增加
机制新颖：每个阶段只增加少量新信息

短篇机制制

1
机制 A（5～10分钟）→ 结束 → 机制 B（5～10分钟）→ 结束 → 机制 C……

每一章重新产生一次「我没见过这个」——比不停堆复杂系统更符合反馈密度原则。

七、验证方法五：性能与平台

1
2
3
4
5
6
7
8
9
10
性能验证（游戏非常重要）：
  CPU：1000 个敌人 EnemySystem Update() 是否超过 16.6ms/帧（60FPS ≈ 16ms/帧）
  GPU：Draw Call、Shader、粒子数量
  内存：加载地图、切换场景、释放资源——防止 Level1→Level2→Level3 内存越来越大

平台验证：
  不同设备/系统上是否正常（Windows/Linux/不同 GPU）

兼容性验证：
  不同分辨率、不同输入设备、不同驱动

性能验证可以自动化（基准测试），但「手感符合预期」这类体验维度仍需人工。

八、验证的层级（从自动到人工）

1
2
3
4
5
6
7
8
9
10
11
12
可自动化：
  可通关性（AI/Bot 迭代通关）
  性能（基准测试、FPS/内存）
  健壮性（边界情况、压力测试）
  平台（多设备运行）

需要人工：
  可玩性（玩法测试——好不好玩）
  新手体验（第一次玩的人——能不能进入）
  趣味性（反馈密度——有没有意思）
  手感（输入到感知的反馈回路——对不对）
  留存（长期玩——腻不腻）

验证从「能不能跑」到「好不好玩」逐层递进，自动化程度递减、人工程度递增。

九、验证与测试的分工

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────┐
│  测试（自动化断言）                          │
│    单元/系统/数据/状态/关卡/集成/流程/E2E     │
│    回答：对不对（功能有没有实现）             │
│    依据：设计文档、功能点、接口               │
├─────────────────────────────────────────────┤
│  验证（体验判断）                            │
│    可通关性（AI/Bot）/ 可玩性（人工）         │
│    新手体验（第一次）/ 趣味（反馈密度）       │
│    性能 / 平台 / 留存                        │
│    回答：好不好、能不能用、有没有意义         │
│    依据：设计意图、玩家体验、世界规则         │
└─────────────────────────────────────────────┘

测试保证「做出来了」，验证判断「做得好不好」。 先测试（对不对）再验证（好不好）——一个功能连测试都过不了，谈不上验证体验。

十、与其他线的关系

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
本线 ←→ 测试（05-测试，同主题内）
  测试 = 自动化断言「代码按设计工作」（对不对）
  验证 = 判断「做出来的东西是否符合预期、有没有价值」（好不好）
  先测试再验证

本线 ←→ 趣味设计（12-游戏/03-趣味设计）
  趣味设计讲「什么让游戏有趣」——本线的趣味性验证用它的结论
  开发者疲劳与新手测试、AI 测试通道 是趣味设计线里验证的部分

本线 ←→ 最小闭环（最小闭环/）
  验证是闭环的最后一环（输入→处理→输出→验证）
  十个验证闭环 = 最小闭环在游戏验证上的展开

本线 ←→ 游戏开发的最小闭环（最小闭环/03）
  空窗口→方块→移动→碰撞→关卡，每一步都是可验证的闭环
  可玩性验证分层：运行不崩→可玩→理解目标→反馈→难度→循环→健壮→手感→平台→留存

本线 ←→ 工程控制（07-工程控制）
  工程控制讲「怎么保证工程不跑偏」——验证是其中「好不好」的手段
  测试解决「对」，验证解决「好」

本线 ←→ 从输入到交互
  用户流程测试（测试线）测「用户流程文档」；新手体验验证测「用户第一次接触」

收束

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
验证 = 判断「做出来的东西是否符合预期、有没有价值」

测试回答「对不对」，验证回答「好不好、能不能用、有没有意义」

游戏的验证标准（十个闭环）：
  运行不崩 / 核心循环能玩 / 理解目标 / 操作有反馈
  / 难度合理 / 重复价值 / 边界不出错 / 手感 / 平台 / 留存

验证方法：
  可通关性  AI/Bot 迭代规则通关（存在可达路径）
  可玩性    玩法测试（人工——好不好玩）
  新手体验  新手测试（第一次玩的人——能不能进入）
  趣味性    反馈密度（单位时间有效反馈）
  性能/平台 基准测试、多设备（可自动化）
  留存      长期玩（腻不腻）

从自动到人工：可通关性→性能→健壮性→平台（自动）
             →可玩性→新手→趣味→手感→留存（人工）

先测试（对不对）再验证（好不好）

测试保证「做出来了」，验证判断「做得好不好」。 游戏验证最独特的在于——它验证的不只是功能，而是「设计的世界规则运行后产生的体验是否符合预期」。