Steam 发布前 QA 实战教程：2021 年 3 月个人游戏回归测试、缺陷分级与候选版本

QA 的目标是降低未知风险

个人开发者常说“我自己已经玩过很多遍”，但这不等于 QA。开发者熟悉关卡路线、知道隐藏操作、会绕开未完成区域，也容易忽略新玩家会遇到的问题。Steam 发布前 QA 的目标不是证明游戏没有缺陷，而是找出会影响购买、审核、通关和评价的风险，并决定哪些必须上线前修，哪些可以写进已知问题。

QA 流程不需要大团队。一个人也可以建立测试清单、缺陷分级、候选版本和回归记录。关键是不要让测试停留在感觉层面。

先定义测试范围

发布前至少覆盖这些范围：

如果游戏体量大，无法每次完整通关，就要拆成关键路径和抽样路径。关键路径每个候选版本都测，抽样路径按风险轮换。

缺陷分级

缺陷必须分级，否则所有问题都会挤在一起。一个实用分级：

分级不是为了逃避问题，而是为了保护发布节奏。个人开发者时间有限，如果上线前把精力花在低频小穿模上，却没修存档损坏，就是优先级错误。

缺陷记录格式

每个缺陷至少记录：

• 构建编号。
• 平台和系统。
• 复现步骤。
• 实际结果。
• 预期结果。
• 截图、录像或日志。
• 严重级别。
• 修复提交或处理结论。

示例：

这样的记录能让修复和回归变得具体。只写“读档有问题”几乎无法处理。

回归矩阵

每次修复后要回归，不只是看 bug 是否消失，还要看相关功能是否被影响。可以做一个矩阵：

回归矩阵的意义是防止“修一个坏两个”。个人项目没有专职测试，更要靠表格保护记忆。

候选版本和冻结规则

发布前要建立候选版本，例如 rc1、rc2。进入候选后，不再随意加新内容，只修缺陷。冻结规则可以写得很简单：

个人开发者最容易在上线前“顺手加一个小功能”。小功能也会引入测试成本。发布前的目标是稳定，不是继续扩展。

Steam 审核准备

提交 Steam 审核前，QA 要确认的不只是游戏能玩：

• 商店页描述和实际内容一致。
• 截图没有展示不存在功能。
• 可执行文件启动项正确。
• 运行库依赖齐全。
• 语言支持和页面勾选一致。
• Demo 与正式版内容边界清楚。
• 存档和设置写入用户目录。
• 没有明显版权风险素材。

审核被退回并不可怕，怕的是没有记录。每次审核反馈都要写入 docs/review-log.md，包括原因、修改、构建编号和重新提交时间。

外部测试者怎么用

即使预算有限，也建议找几位外部测试者。不要只发一个包说“帮我玩玩”。给他们任务：

给测试者反馈模板，减少无效信息。让他们记录时间点、场景、感受和是否愿意继续玩。对个人游戏来说，外部测试的价值往往高于多做一个小功能。

上线前一天的检查

上线前一天不要做大改。检查重点：

• 当前 default 或候选分支是不是正确构建。
• 构建编号和发布日志一致。
• 商店页价格、折扣、发售时间无误。
• 社区公告和支持邮箱准备好。
• 已知问题列表有内部记录。
• 回滚方案清楚。
• 开发机和测试机都能从 Steam 安装运行。

如果这一天发现 P0/P1，修；发现 P3，记录到补丁计划。发布不是把所有问题清零，而是把阻断风险降到可接受范围。

发布后 48 小时 QA

QA 不在上线瞬间结束。上线后 48 小时要重点看：

• 崩溃反馈。
• 退款和差评中的技术原因。
• 讨论区重复问题。
• 云存档和成就异常。
• 特定硬件或语言问题。

把玩家反馈按缺陷分级处理。不要被单条情绪化评论带着乱改，也不要忽略重复出现的小问题。重复出现就是信号。

最终检查清单

• 测试范围覆盖启动、主流程、存档、输入、设置和 Steam 功能。
• 缺陷按 P0 到 P3 分级。
• 每个问题有构建号、步骤、预期和实际结果。
• 修复后按矩阵回归相关功能。
• 候选版本进入冻结规则。
• Steam 审核反馈有记录。
• 外部测试者有明确任务。
• 上线前一天只处理阻断问题。

个人游戏 QA 的关键不是流程多复杂，而是让每个发布决策有依据。Steam 上架后，玩家面对的是一个产品，不是开发过程。把 QA 做扎实，就是给自己的内容争取更公平的第一印象。

QA 也要检查内容承诺

发布前测试不只看程序是否崩溃，也要看内容是否兑现商店页承诺。商店页写“包含十个关卡”，游戏里就不能因为临时删减只剩九个还没改文案；写“支持手柄”，就要完成从启动到退出的手柄流程；截图展示某个能力，正式包里就不能把它藏在不可到达的测试房间。

可以把商店页拆成承诺清单：

这类检查能减少“页面说得比游戏多”的风险。玩家进入游戏后发现承诺不一致，比遇到一个小 bug 更容易失去信任。

补丁预案提前写

上线前即使 QA 做得认真，也可能有玩家机器上才出现的问题。提前准备补丁预案，能让上线后反应更稳。预案包括：谁收集反馈，问题如何分级，热修分支从哪里切，补丁说明怎么写，哪些问题需要先在测试分支验证。

个人开发者可以把补丁节奏写成三档：当天热修只处理崩溃、丢档、无法启动；三天内补丁处理高频体验问题；一到两周补丁处理平衡、文案和低频兼容。这样遇到反馈时不会全部混在一起，也不会为了小问题频繁打包引入新风险。

回滚方案不要临时想

候选版本进入 Steam 分支后，要知道上一个可用构建是哪一个。如果新包出现严重问题，回滚到旧构建通常比现场继续修更稳。回滚方案需要记录旧构建编号、对应提交、Steam 分支状态和是否兼容新存档。尤其是存档格式变化后，回滚并不总是简单切回旧包，必须提前判断。

发布前把这件事写进清单，可以避免上线当天在压力下做错误决定。