Steam 游戏自动化烟测实战：2021 年 5 月个人项目如何检查启动、菜单、存档和关键流程

自动化烟测不等于完整测试

个人开发者听到自动化测试，可能会觉得成本太高。游戏确实很难把所有玩法自动测完，但烟测目标不同：它只检查构建是否能启动，主菜单是否可操作，新游戏是否进入场景，存档是否能写入，关键流程是否没有崩溃。它不替代人工试玩，却能挡住很多低级问题。

Steam 发布前，最怕的是上传一个根本打不开、菜单按钮失效、读档崩溃、配置缺文件的包。自动化烟测可以在每次候选构建后跑一遍，给发布多一层底线。

先定义烟测范围

烟测范围要小而稳定：

不要把复杂战斗和随机流程放进基础烟测。烟测越稳定，越容易长期执行。

启动检查

启动测试可以做几件事：

• 从构建目录或 Steam 安装目录启动。
• 等待主窗口出现。
• 等待主菜单文本或按钮出现。
• 检查进程没有退出。
• 读取日志确认启动阶段完成。

如果游戏有 Steam API 依赖，最好在 Steam 客户端环境下也跑一次。直接运行可执行文件和从 Steam 启动不是同一条路径。

菜单导航

菜单烟测不需要识别复杂 UI，可以用固定输入：按确认进入新游戏，按返回回主菜单，打开设置修改音量再取消。重点是确认输入系统、UI 焦点和状态切换没有断。

菜单测试常能发现：

• 默认焦点丢失。
• 设置页打不开。
• 弹窗阻塞。
• 手柄确认和键盘确认行为不同。
• 返回主菜单后按钮不可用。

这些问题人工也能发现，但自动化能每次构建都检查。

存档烟测

存档烟测很有价值。流程可以是：

1. 删除测试存档目录。
2. 启动游戏并新开一局。
3. 到达第一个检查点。
4. 退出到主菜单。
5. 继续游戏。
6. 检查玩家回到正确场景。

如果做不到自动走到检查点，可以在内部构建提供测试入口，但要确保发行候选也能用正常路径验证。存档 bug 很容易阻断玩家流程，值得放入烟测。

日志断言

自动化测试不一定要理解游戏全部状态，但可以检查日志。比如烟测结束后搜索：

• Fatal
• Unhandled
• save_failed
• asset_missing
• steam_init_failed
• quest_invalid_state

不是所有 Error 都一定阻断，但关键错误要让烟测失败。日志断言能发现肉眼没看到的问题，比如某个图标缺失但游戏用默认图标继续运行。

截图检查

截图检查可以防止黑屏、UI 丢失和场景未加载。简单做法是截主菜单和第一关，检查图片不是纯黑、不是纯白、尺寸正确。更进一步可以和基准图比较，但个人项目先做非空检查就很有用。

每次大改 UI 或光照后，更新基准截图。不要让截图对比变成频繁误报，否则你会很快不再相信它。

处理随机性

烟测要减少随机性。可以固定随机种子，使用固定测试存档，关闭动态每日内容。随机流程适合人工测试或专门模拟，不适合基础烟测。基础烟测的价值在于稳定地告诉你“这包有没有明显坏掉”。

在构建流程中的位置

烟测应该在构建后、上传 Steam 前跑一次；上传到 internal 分支后，从 Steam 客户端安装再跑一次。前者验证包本身，后者验证 Steam 分发路径。

流程：

1. 导出构建。
2. 跑本地烟测。
3. 上传 internal。
4. 从 Steam 安装。
5. 跑 Steam 安装版烟测。
6. 人工做关键试玩。
7. 决定是否切候选分支。

失败后的处理

烟测失败要能快速定位。输出内容包括：失败步骤、截图、日志路径、构建编号。不要只显示“测试失败”。自动化工具本身也要保持简单，失败信息越直接越好。

如果烟测偶发失败，要先判断是测试不稳定还是游戏不稳定。偶发失败也可能是真问题，比如加载时序、焦点抢占、异步资源未准备。

最终检查清单

• 烟测范围小，覆盖启动、菜单、存档和关键场景。
• 从普通构建和 Steam 安装路径都验证。
• 菜单测试覆盖确认、返回和设置。
• 存档测试覆盖写入和继续游戏。
• 日志断言检查关键错误。
• 截图检查避免黑屏和未加载。
• 测试流程减少随机性。
• 失败输出包含截图、日志和构建编号。

自动化烟测不是为了替代人，而是让个人开发者在反复打包和上传时不靠记忆。它能挡住低级事故，把人工精力留给真正需要体验判断的部分。

烟测脚本要和构建编号绑定

每次烟测输出都要写入构建编号、平台、运行时间和结果。不要只保留一串截图。一个简单的结果文件可以包含：构建号、Git 提交、测试开始时间、通过步骤、失败步骤、日志路径、截图目录。

这样当候选包很多时，你能知道 rc4 是否真的跑过 Steam 安装版烟测，而不是凭印象判断。

测试账号和测试数据

烟测建议使用独立测试存档和测试配置。不要用开发者日常存档，因为里面可能已经解锁所有内容，掩盖新玩家路径问题。测试前清理配置，或复制一份标准配置，尽量让每次从相近环境开始。

如果需要 Steam 功能，使用测试账号或明确的测试分支。测试账号的云存档也要定期清理，否则旧数据会影响结果。

可以先从半自动开始

如果没有时间写完整自动化，也可以先做半自动清单：一键启动游戏、打开日志目录、生成测试存档、截图主菜单。半自动比完全靠记忆强。等流程稳定后，再逐步加入输入模拟和日志断言。

自动化测试的价值在于重复执行，不在于一开始多高级。个人项目最需要的是每次构建都有同一套最低检查。

维护烟测

游戏改 UI、改菜单、改流程后，烟测也要更新。否则测试会因为找不到旧按钮而失败。把烟测脚本当成项目的一部分维护，不要让它变成一次性工具。每次烟测误报，都要判断是脚本过时还是游戏行为真的变了。

适合自动化的断言

游戏烟测不一定能判断“好不好玩”，但可以判断很多明确条件：

这些断言朴素，但非常适合每个候选包重复跑。烟测不需要理解 Boss 是否平衡，它只需要确认构建没有基础性损坏。

烟测和人工测试分工

烟测通过后，人工测试仍然要做。人工测试负责体验判断：教学是否清楚，战斗是否公平，关卡是否无聊，商店页承诺是否兑现。烟测负责重复性底线：启动、菜单、存档、日志、关键场景。

把分工写清楚，可以避免两种误区：一是因为有烟测就不试玩；二是因为人工玩过就不跑烟测。两者解决的问题不同。

构建失败时不要继续上传

如果本地烟测失败，就不要上传 Steam internal 分支继续试。先修本地构建，除非问题只可能发生在 Steam 环境。否则你会在 Steam 后台留下多个坏构建，增加混乱。候选阶段要让每个上传包都有基本可信度。

烟测通过标准要固定

烟测结果需要明确通过标准。比如主菜单 20 秒内出现、第一关 40 秒内加载、日志没有关键错误、存档文件存在、退出进程在 5 秒内结束。没有标准时，测试者会凭感觉判断，通过结果不稳定。

标准可以随项目成熟调整，但每次调整要记录原因。候选阶段不要临时放宽标准，除非你清楚知道失败来自测试脚本，而不是游戏本身。

保存历史结果

保留最近几次烟测结果很有用。某个构建突然启动变慢、日志错误变多、截图异常，就能和上一个构建对比。历史结果不需要长期保存全部，只要保留候选阶段的记录即可。

如果烟测结果开始频繁波动，要优先排查加载时序、异步资源和测试环境，而不是简单反复重跑。

稳定的烟测比覆盖更多但经常误报的烟测更适合候选阶段。

如果后续要扩展，可以先增加第二个代表关卡和一个旧存档读取场景。扩展顺序应从高风险路径开始，而不是追求测试数量。