网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多团队做鸿蒙游戏测试时，仍然停留在这样一种模式：

开发写完
 ↓
测试点击
 ↓
提Bug
 ↓
开发修复

项目小时候没问题，但随着游戏复杂度上升：

关卡越来越多
技能越来越多
地图越来越大
AI越来越复杂

很快就会出现一个现实问题：

人已经测不过来了。

例如：

100个关卡
50个技能
30种怪物
10种装备

理论组合数量：

几十万种场景

人工测试根本不可能覆盖，所以越来越多游戏团队开始转向：

AI 驱动测试（AI Testing）

这并不是让 AI 帮你点按钮，而是：

让 AI 代替玩家探索整个游戏世界。

一、传统测试为什么越来越失效？

先看一个简单例子，技能系统：

火球术
冰冻术
闪现
护盾

测试人员可能会验证：

单独释放正常

然后通过，但真实玩家可能会：

闪现
↓
冰冻
↓
火球
↓
护盾

甚至：

网络波动
+
切后台
+
重新进入
+
释放技能

这种组合场景：

人工几乎无法覆盖

二、AI 测试的本质是什么？

很多人理解：

AI测试
=
自动点击

其实不是，真正的 AI 测试：

AI Agent
      ↓
模拟玩家行为
      ↓
发现异常状态

例如：

玩家移动
玩家攻击
玩家购买
玩家升级

全部由 AI 自动完成。

三、鸿蒙游戏为什么特别适合 AI 测试？

因为我们前面一直在讲：

Store
System
UI

架构，而 AI 最喜欢的就是：

状态

例如：

store.playerHp
store.gold
store.level

AI 不需要看界面，它直接读取：

Store

四、传统 UI 测试的问题

很多自动化测试：

查找按钮
↓
点击按钮
↓
判断页面

例如：

findButton("attack")
.click()

问题：

UI改版
测试全挂

非常脆弱，而 System 架构下：

Input
 ↓
System
 ↓
Store

可以直接测试：

battleSystem.attack(store)

验证：

expect(store.enemyHp)

五、第一层：System 单元测试

例如：

class BattleSystem {

  attack(store: GameStore) {
    store.enemyHp -= 10
  }

}

测试：

it('attack enemy', () => {

  const store = new GameStore()

  battleSystem.attack(store)

  expect(store.enemyHp).toBe(90)

})

优势：

运行快
稳定
覆盖高

六、第二层：AI 行为测试

模拟玩家行为，例如：

class TestAgent {

  run() {

    attack()

    move()

    attack()

    useSkill()

  }

}

看起来像脚本，实际上已经出现了：

AI玩家

七、随机探索测试

很多 Bug：

不是固定触发

而是：

随机出现

例如：

连续点击
疯狂拖动
快速切换页面

人工很难复现，AI 可以：

for (let i = 0; i < 10000; i++) {

  randomAction()

}

不断探索，例如：

攻击
移动
拾取
升级
装备

随机组合，最终发现：

状态异常
崩溃
死循环

八、状态验证测试

游戏最怕：

状态漂移

例如，玩家金币：

-100

出现负数，经验值：

超过上限

背包：

数量异常

AI 测试时可以加入：

assert(store.gold >= 0)

assert(store.hp >= 0)

assert(store.level <= 100)

持续检查，这种方式叫：

Invariant Test（状态不变量测试）

九、AI 压力测试

很多问题只有高频操作才会出现，例如：

for (let i = 0; i < 100000; i++) {
  battleSystem.attack(store)
}

验证：

内存泄漏
状态错误
性能下降

对于，下面内容尤其重要：

AISystem
BattleSystem
InventorySystem

十、AI 驱动的寻路测试

例如地图：

1000 × 1000

人工：

不可能走遍

AI：

findRandomPath()

持续运行，验证：

是否卡死
是否穿墙
是否死循环

这是大型游戏团队非常常见的方法。

十一、AI 测试 Agent 架构

推荐结构：

TestAgent
      ↓
InputSystem
      ↓
BattleSystem
MoveSystem
SkillSystem
      ↓
Store

注意：

AI和玩家共用输入层

例如：

玩家点击攻击

产生：

ATTACK

AI：

ATTACK

完全一致。

十二、LLM 开始进入测试系统

随着大模型发展，未来测试可能变成：

GPT
 ↓
理解游戏规则
 ↓
自动生成测试场景

例如：

玩家死亡时切后台
重新登录
领取奖励

自动生成，甚至：

发现异常
↓
分析原因
↓
自动生成报告

这已经开始在部分大型项目中落地。

十三、鸿蒙游戏未来的测试体系

未来推荐架构：

Unit Test
      ↓
System Test
      ↓
AI Agent Test
      ↓
Stress Test
      ↓
Release

而不是：

开发
 ↓
测试点点点
 ↓
上线

十四、一个关键认知升级

初学者理解测试：

验证功能

进阶开发者理解测试：

验证状态变化

而大型项目理解测试：

验证整个 System 是否仍然遵守规则。

因为游戏本质上是：

Store
+
System

构成的状态演化系统。

总结

鸿蒙游戏自动测试的最佳实践：

System单元测试
+
AI行为测试
+
随机探索测试
+
状态不变量测试
+
压力测试

推荐架构：

AI Agent
      ↓
InputSystem
      ↓
System
      ↓
Store
      ↓
Assertion

如果用一句话总结：

未来的鸿蒙游戏测试，不再是“测试人员找 Bug”，而是“AI 在游戏世界中持续探索并验证规则”。