独立游戏 QA 测试与 Bug 修复工作流：从崩溃日志到稳定发售的实战指南

独立游戏开发是一场漫长的马拉松，而 QA 测试往往是最后一公里中最容易被忽视的环节。很多独立开发者在功能开发阶段充满激情，却在测试阶段疲于奔命，最终带着大量未修复的 Bug 仓促发售，换来一片差评。

本文将从实际工作流出发，系统梳理从崩溃日志收集到稳定发售的全流程，帮助你用有限的资源做好 QA 测试。

一、QA 测试为什么是独立游戏最容易被忽略的环节

1.1 Steam 差评中的 Bug 关键词分析

根据 SteamSpy 和 Steam Reviews 的公开数据分析，在"多半差评"和"褒贬不一"的独立游戏评论中，以下关键词的出现频率令人触目惊心：

这意味着 超过 60% 的差评直接与软件质量相关，而非玩法设计问题。

1.2 发售崩溃的连锁反应

Steam 的推荐算法对好评率极其敏感。以下是好评率与算法流量的关系：

• 好评率 > 80%：Steam 算法积极推荐，出现在"热门新品"“特别好评"等标签页
• 好评率 70-80%：算法推荐有限，需要依靠外部流量
• 好评率 < 70%：算法几乎不推荐，自然流量断崖式下跌

一款游戏如果在发售首周因为 Bug 导致好评率跌破 70%，将面临：

1. Steam 算法不给流量 → 自然曝光下降 80% 以上
2. 评测媒体看到差评 → 不愿撰写评测
3. 主播/UP主看到差评 → 不愿直播/做视频
4. 口碑传播变负面 → 社区讨论以吐槽为主
5. 销量断崖 → 没有资金支持后续开发

1.3 因 Bug 导致首发失败的典型案例

案例 1：No Man’s Sky（2016 首发）

Hello Games 在首发时承诺了大量未实现的功能，加上频繁崩溃、存档损坏等 Bug，好评率一度跌至低谷。虽然团队后来通过多年的免费更新挽回了口碑，但首发阶段的负面评价至今仍然可见。

案例 2：Cyberpunk 2077（2020 首发）

CD Projekt Red 的这款游戏在 PC 端表现尚可，但在 PS4/Xbox One 上几乎无法正常游玩。大量崩溃、穿模、任务无法完成等 Bug 导致 Sony 直接从 PlayStation Store 下架该游戏，公司股价暴跌超过 30%。

案例 3：Anthem（2019 首发）

BioWare 的这款在线射击游戏首发时存在大量 Bug：无限加载画面、装备数据丢失、技能失效、频繁崩溃。好评率长期维持在 30% 左右，最终 BioWare 宣布停止后续开发。

对独立开发者的启示：即使是拥有数百人团队的大厂也无法承受首发 Bug 的代价，更何况是一两个人的独立团队。QA 测试不是可选项，而是必选项。

1.4 独立游戏 QA 的核心挑战

二、Bug 分类与优先级体系

2.1 Bug 严重等级分类

建立清晰的 Bug 严重等级是高效修复的基础：

P0 — 崩溃级（Blocker）

• 游戏崩溃（Crash to Desktop）
• 存档损坏或无法加载
• 软锁（Softlock）：游戏无法继续但未崩溃
• 数据丢失：玩家进度永久丢失
• 安全漏洞：作弊、远程代码执行

P1 — 严重级（Critical）

• 主线任务卡死（有 workaround）
• 关键游戏机制失效（战斗系统、移动系统）
• 严重性能问题（帧率低于 15 FPS）
• 音频完全丢失
• 多人游戏断连

P2 — 一般级（Major）

• 视觉错误：穿模、贴图错误、光照异常
• 音效异常：音效延迟、音效错误、音量不平衡
• UI 错位：按钮重叠、文字溢出、菜单无法打开
• 非关键功能异常：排行榜、成就系统、设置选项

P3 — 轻微级（Minor）

• 文案错误：拼写错误、翻译不准确
• 动画微小瑕疵：偶尔的动画跳帧
• 视觉微调：对齐不完全精确
• 建议性改进：操作手感优化建议

2.2 Bug 处理优先级矩阵

优先级由"严重度"和"出现频率"两个维度共同决定：

2.3 Bug 追踪工具推荐

方案 A：GitHub Issues（推荐，免费）

优势：与代码仓库集成，支持标签、里程碑、Assignee。适合代码与 Bug 在同一平台的团队。

配置建议：

• 创建标签：bug-p0、bug-p1、bug-p2、bug-p3
• 创建里程碑：v1.0-launch、v1.1-hotfix
• 使用 Issue Template 规范 Bug 报告格式

方案 B：Trello（免费，看板式）

优势：直观的看板视图，适合小团队。创建"待修复"“修复中"“待验证"“已完成"四列。

方案 C：Notion（灵活，适合小团队）

优势：数据库功能强大，可自定义视图（表格/看板/日历），适合需要同时管理文档和 Bug 的团队。

方案 D：Bugzilla（免费，专业级）

优势：老牌 Bug 追踪系统，功能全面。劣势：界面老旧，配置复杂，对独立团队可能过于重量级。

2.4 Bug 报告标准模板

【标题】[P0/P1/P2/P3] 简明描述问题（不超过 50 字）

【环境信息】
- 平台：PC / Mac / Linux / 具体型号
- 操作系统：Windows 11 / macOS 14.2 / Ubuntu 22.04
- 游戏版本：v0.8.2-beta
- 硬件配置：CPU / GPU / RAM

【复现步骤】
1. 进入第二关"暗影森林"
2. 与 NPC"老铁匠"对话
3. 选择第三个对话选项
4. 打开背包查看获得的物品

【期望结果】
背包中应显示"铁匠之锤"道具，且道具描述完整。

【实际结果】
背包中出现空白道具槽位，点击后游戏崩溃。

【复现率】
5/5（5 次尝试均复现）

【附件】
- 崩溃日志：crash_20260225_143022.log
- 截图/视频：bug_screenshot.png
- 存档文件：save_slot_001.dat

【额外信息】
在 v0.8.1 版本中该功能正常，疑似 v0.8.2 引入的回归 Bug。

三、测试策略设计

3.1 测试金字塔模型

测试金字塔是软件工程中经典的测试分层策略，同样适用于游戏开发：

底层：单元测试（占比约 60%）

测试核心系统的独立逻辑，执行速度快，覆盖范围广。

适合测试的模块：

• 伤害计算公式
• 经验值/升级曲线
• 掉落概率逻辑
• 存档/读档序列化
• AI 决策树逻辑
• 碰撞检测算法

中层：集成测试（占比约 30%）

测试系统间的交互，确保各模块协同工作。

适合测试的场景：

• 战斗系统 + 动画系统 + 音效系统
• 存档系统 + UI 系统 + 数据管理
• 关卡加载 + 资源管理 + 场景切换

顶层：E2E 测试（占比约 10%）

模拟玩家的完整游戏流程，验证端到端体验。

适合测试的流程：

• 新游戏 → 教程 → 第一关完整通关
• 存档 → 退出 → 重新加载 → 验证进度
• 购买 → 装备 → 使用 → 验证效果

3.2 手动测试方法

冒烟测试（Smoke Test）

每次构建新版本后，执行以下基础验证（约 15-20 分钟）：

1. 游戏能否正常启动
2. 主菜单是否正常显示和操作
3. 能否开始新游戏
4. 角色移动是否正常
5. 核心战斗机制是否正常
6. 第一个关卡能否正常加载
7. 存档和读档是否正常
8. 音频是否正常播放
9. 设置菜单是否正常工作
10. 退出游戏是否干净退出

如果以上任何一项失败，该版本无法进入正式测试流程，需要先修复。

回归测试（Regression Test）

每次修复 Bug 后，验证以下三个方面：

1. 被修复的 Bug 确实已修复
2. 修复没有引入新的 Bug
3. 相关功能仍然正常工作

回归测试的范围建议：修复涉及的文件/模块的所有相关功能。

探索性测试（Exploratory Testing）

不按预设步骤，自由操作以发现边缘 Bug。常用技巧：

• 快速连续按键（连击所有按钮）
• 在动画播放中切换场景
• 在对话中打开/关闭菜单
• 同时触发多个事件
• 在加载过程中强制操作
• 极端输入（负数、超大数值、空字符串）
• 断网后重连
• 最小化/最大化窗口
• 拔插外设（手柄、耳机）

压力测试（Stress Test）

对系统进行极端操作以测试极限：

• 同时生成 1000 个敌人
• 背包塞满 999 个物品
• 连续快速存档 100 次
• 持续运行 24 小时（稳定性测试）
• 快速切换场景 50 次

3.3 自动化测试方案

Unity Test Framework 使用指南

Unity 内置 Test Framework（基于 NUnit），支持 Edit Mode 和 Play Mode 两种测试模式。

Edit Mode 测试示例：

using NUnit.Framework;

public class DamageCalculatorTests
{
    [Test]
    public void CalculateDamage_BasicAttack_ReturnsCorrectValue()
    {
        var calculator = new DamageCalculator();
        int damage = calculator.Calculate(baseAttack: 10, defense: 5, multiplier: 1.5f);
        Assert.AreEqual(8, damage); // (10 - 5) * 1.5 = 7.5, 向上取整 = 8
    }

    [Test]
    public void CalculateDamage_DefenseExceedsAttack_ReturnsMinimumOne()
    {
        var calculator = new DamageCalculator();
        int damage = calculator.Calculate(baseAttack: 3, defense: 10, multiplier: 1.0f);
        Assert.AreEqual(1, damage); // 最低伤害保底为 1
    }
}

Godot GdUnit4 测试框架

GdUnit4 是 Godot 引擎的单元测试框架，支持 GDScript 和 C#。

extends GdUnitTestSuite

func test_calculate_exp_for_level() -> void:
    var player = Player.new()
    var exp_needed = player.get_exp_for_level(5)
    assert_int(exp_needed).is_equal(500)  # 5级需要500经验

func test_level_up_increases_max_hp() -> void:
    var player = Player.new()
    var old_max_hp = player.max_hp
    player.gain_exp(1000)  # 足够升级的经验
    assert_int(player.max_hp).is_greater(old_max_hp)

自动化构建流水线（GitHub Actions）

name: Game Build and Test
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Unity Tests
        uses: game-ci/unity-test-runner@v4
        with:
          unityVersion: 2022.3.20f1
          testMode: EditMode
          githubToken: ${{ secrets.GITHUB_TOKEN }}
      - name: Run PlayMode Tests
        uses: game-ci/unity-test-runner@v4
        with:
          unityVersion: 2022.3.20f1
          testMode: PlayMode

四、崩溃分析与修复

4.1 崩溃日志收集系统搭建

Unity：Unity Cloud Diagnostics / Sentry

Unity 内置 Cloud Diagnostics 可以自动收集崩溃信息，但更推荐使用 Sentry，原因如下：

• 支持更丰富的上下文信息（玩家操作路径、设备信息、游戏状态）
• 更好的 Stack Trace 符号化
• 实时告警功能
• 支持面包屑（Breadcrumb）追踪崩溃前的操作序列

Sentry 集成示例（Unity）：

using Sentry;

public class CrashReporter : MonoBehaviour
{
    void Awake()
    {
        SentrySdk.Init(options =>
        {
            options.Dsn = "https://your-dsn@sentry.io/project-id";
            options.TracesSampleRate = 1.0;
            options.SendDefaultPii = false;  // 不发送个人身份信息
        });
    }

    void OnEnable()
    {
        Application.logMessageReceived += HandleLog;
    }

    void HandleLog(string condition, string stackTrace, LogType type)
    {
        if (type == LogType.Exception || type == LogType.Error)
        {
            SentrySdk.CaptureMessage(condition, scope =>
            {
                scope.SetExtra("stackTrace", stackTrace);
                scope.SetExtra("currentScene", SceneManager.GetActiveScene().name);
                scope.SetExtra("gameVersion", Application.version);
            });
        }
    }
}

Godot：自定义崩溃日志

Godot 没有内置的崩溃收集系统，需要自建：

extends Node

var log_file: File
var log_path := "user://crash_logs/"

func _ready():
    DirAccess.make_dir_recursive_absolute(log_path)
    var timestamp = Time.get_datetime_string_from_system().replace(":", "-")
    log_file = FileAccess.open(log_path + "session_" + timestamp + ".log", FileAccess.WRITE)
    log_message("Session started - Version: " + ProjectSettings.get_setting("application/config/version"))

func log_message(msg: String):
    var timestamp = Time.get_time_string_from_system()
    log_file.store_line("[%s] %s" % [timestamp, msg])

func log_error(error: String, context: Dictionary = {}):
    var entry = {"error": error, "context": context, "time": Time.get_datetime_string_from_system()}
    log_file.store_line("[ERROR] " + JSON.stringify(entry))

4.2 崩溃日志解读方法

Stack Trace 分析

一个典型的 Unity 崩溃 Stack Trace：

NullReferenceException: Object reference not set to an instance of an object
  at InventorySystem.AddItem (ItemData item) [0x00023] in InventorySystem.cs:145
  at LootDrop.CollectLoot () [0x00045] in LootDrop.cs:78
  at PlayerInteraction.Interact (GameObject target) [0x00012] in PlayerInteraction.cs:34

解读步骤：

1. 从最后一行（调用栈底部）开始阅读，这是最初的调用位置
2. 逐行向上追踪，找到问题的根本原因
3. 本例中，AddItem 方法接收了一个 null 的 ItemData 参数

常见崩溃类型及解决方案

4.3 内存泄漏检测方法

Unity Profiler

1. 打开 Window → Analysis → Profiler
2. 选择 Memory 模块
3. 勾选 “Detailed” 模式
4. 执行游戏流程，观察内存变化曲线
5. 如果内存持续增长不释放，存在泄漏

常见内存泄漏原因

• 未取消注册的事件监听器（+= 后没有 -=）
• 未销毁的 GameObject（场景切换后残留）
• 未释放的 Texture/RenderTexture
• 静态引用持有已销毁对象的引用
• 协程（Coroutine）在对象销毁后继续运行

4.4 崩溃修复工作流

标准化的崩溃修复五步法：

1. 复现：找到 100% 复现的步骤。无法复现的 Bug 通常难以修复
2. 定位：通过日志、调试器、Profiler 确定问题代码位置
3. 修复：编写最小化修复代码，避免引入副作用
4. 验证：在原复现步骤下确认 Bug 已修复
5. 回归测试：验证相关功能未受影响

4.5 20 个高频崩溃场景与解决方案

1. 场景切换时崩溃：异步加载资源时对象已被销毁 → 使用 DontDestroyOnLoad 或在回调中检查对象有效性
2. 存档时崩溃：序列化包含不可序列化字段 → 标记 [NonSerialized] 或使用 JSON 序列化
3. UI 操作崩溃：在 UI 回调中销毁触发 UI 的对象 → 延迟到下一帧销毁
4. 物理系统崩溃：高速移动物体穿透碰撞体 → 使用 Continuous Collision Detection
5. 音频崩溃：同时播放过多音频源 → 限制最大同时播放数量
6. 网络断连崩溃：未处理网络异常 → 添加 try-catch 和重连逻辑
7. 输入崩溃：手柄热插拔 → 监听设备变更事件
8. 分辨率崩溃：UI 适配异常 → 使用 Canvas Scaler + 锚点布局
9. 多语言崩溃：缺少翻译键 → 实现 Fallback 机制
10. 粒子系统崩溃：粒子数过多 → 限制最大粒子数 + 使用 LOD

五、外部测试（Beta Testing）管理

5.1 内测与公测的区别

5.2 测试人员招募

Discord 社区招募（推荐）

步骤：

1. 在 Discord 服务器中创建 #beta-testers 频道
2. 发布招募公告，说明测试时间和要求
3. 要求申请者填写：游戏平台、配置信息、每周可测试时长
4. 选择 20-50 名活跃度高、配置多样的测试者
5. 授予特殊角色和权限

Steam Playtest 功能

Steam 提供了内置的 Playtest 功能：

1. 在 Steamworks 后台启用 Playtest App
2. 设置 Playtest 的可见性（公开申请 / 邀请制）
3. 上传 Playtest 构建版本
4. 管理申请者（批准/拒绝）
5. 通过 Steam 社区功能收集反馈

5.3 测试反馈收集

结构化问卷（5 个核心问题）

1. 你在测试过程中是否遇到了崩溃或卡死？请描述具体情况。
2. 你觉得哪个关卡/区域的难度最高？为什么？
3. 有哪些操作让你感到困惑或不直观？
4. 游戏在哪个时刻最让你感到有趣/满足？
5. 如果有 3 个改进建议，你会提什么？

Bug 报告表格字段设计

• 问题标题（必填）
• 复现步骤（必填）
• 发生频率（必填：每次/经常/偶尔/仅一次）
• 严重程度自评（必填：致命/严重/一般/轻微）
• 截图/视频（选填但鼓励）
• 系统配置信息（自动收集）
• 游戏版本号（自动收集）

六、发售前稳定性冲刺

6.1 “Stability Sprint"方法论

在计划发售日前 2-4 周启动"稳定性冲刺”：

第 1 周：全面排查

• 停止所有新功能开发
• 全面执行 QA Checklist
• 收集所有已知 Bug 清单
• 按优先级矩阵排序

第 2 周：集中修复

• 修复所有 P0 和 P1 Bug
• 每日构建 + 冒烟测试
• 更新 Bug 燃尽图

第 3 周：回归验证

• 完整回归测试
• 外部测试者最终验证
• 性能优化最终调整

第 4 周：发布准备

• 代码冻结（Code Freeze）
• 最终构建验证
• 准备首日补丁（Day 1 Patch）

6.2 Bug 燃尽图追踪

Bug 燃尽图是追踪修复进度的可视化工具：

• X 轴：天数
• Y 轴：剩余 Bug 数量
• 理想线：从总 Bug 数线性下降到 0
• 实际线：每天更新实际剩余 Bug 数

如果实际线持续高于理想线，说明修复速度不够，需要：

1. 增加修复人手
2. 降低部分 Bug 的优先级
3. 推迟发售日期

6.3 发售前验收清单

功能验收（必须全部通过）：

• 全流程通关无崩溃（至少 3 次完整通关）
• 所有 P0 Bug 已修复并验证
• 所有 P1 Bug 已修复并验证
• 存档系统可靠性验证（100 次存读档无错误）
• 所有成就/解锁条件正常
• 所有教程步骤可完成
• 所有 Boss 战可击败
• 所有支线任务可完成

兼容性验收：

• Windows 10/11 测试通过
• macOS 测试通过（如支持）
• Linux 测试通过（如支持）
• 最低配置帧率 ≥ 30 FPS
• 推荐配置帧率 ≥ 60 FPS
• 1080p / 1440p / 4K 分辨率测试通过
• 超宽屏（21:9）测试通过
• 手柄（Xbox / PlayStation）测试通过

商店页面验收：

• Steam 商店页面信息准确
• 截图和预告片为最新版本
• 系统需求描述准确
• 支持的语言列表正确

七、发售后 Bug 响应

7.1 首日/首周紧急修复流程

发售后的黄金 72 小时响应流程：

1. 监控（持续）：实时监控 Sentry/Steam 讨论区的崩溃报告和 Bug 反馈
2. 分类（1 小时内）：将新发现的 Bug 分类并评估严重度
3. 修复（4 小时内）：修复 P0 Bug，准备热修复
4. 测试（2 小时内）：快速验证修复有效且无新问题
5. 发布（1 小时内）：通过 Steam 发布热修复

7.2 “已知问题"公告模板

【已知问题公告 v1.0.x】

感谢大家的购买和反馈！以下是目前已确认的问题和修复进度：

🔴 已修复（将在下个补丁中上线）：
- [P0] 第二关 Boss 战后存档损坏的问题
- [P1] 部分玩家在第四章遇到无法触发剧情的 Bug

🟡 正在修复：
- [P1] AMD 显卡在特定场景下帧率骤降
- [P2] 设置菜单中音量滑块不生效

🟢 已确认，排入计划：
- [P2] 部分文本翻译错误
- [P3] 第三章 NPC 穿模问题

下一次更新预计在 [日期] 发布，包含以上所有修复。

八、QA 测试 Checklist

8.1 功能测试（30 项）

• 新游戏正常启动
• 继续游戏正常加载
• 角色移动（前后左右）正常
• 角色跳跃/冲刺/闪避正常
• 攻击系统（轻攻击/重攻击/连招）正常
• 防御/格挡系统正常
• 技能系统（所有技能可释放、冷却正常）
• 物品拾取/使用/丢弃正常
• 背包系统（添加/移除/排序）正常
• 装备系统（装备/卸下/替换）正常
• 对话系统（所有对话选项可触发）正常
• 商店系统（购买/出售）正常
• 存档系统（手动存档/自动存档）正常
• 读档系统（所有存档槽位可加载）正常
• 地图系统（显示/标记/导航）正常
• 成就系统（解锁条件/通知）正常
• 设置系统（画面/音频/控制）正常
• 暂停菜单（暂停/恢复/退出）正常
• 游戏结束/死亡流程正常
• 教程/引导系统完整可通关

8.2 兼容性测试（15 项）

• Windows 10 64-bit 运行正常
• Windows 11 运行正常
• 最低配置（GTX 1060 / RX 580）帧率达标
• 推荐配置（RTX 3060 / RX 6700）帧率达标
• 1920x1080 分辨率正常
• 2560x1440 分辨率正常
• 3840x2160 分辨率正常
• 窗口模式/全屏模式/无边框窗口切换正常
• Xbox 手柄正常
• PlayStation 手柄正常
• 键盘鼠标正常
• 多显示器环境下正常
• 切换分辨率后恢复正常
• Alt-Tab 切出后切回正常
• Steam Deck 运行正常（如适用）

8.3 性能测试（10 项）

• 主菜单帧率 ≥ 60 FPS
• 游戏内平均帧率 ≥ 30 FPS（最低配置）
• 游戏内平均帧率 ≥ 60 FPS（推荐配置）
• 加载时间 < 10 秒（SSD）
• 加载时间 < 20 秒（HDD）
• 内存占用 < 系统可用内存的 80%
• 长时间运行（4 小时）无内存泄漏
• 场景切换流畅无卡顿
• 大量敌人同屏时帧率可接受
• CPU 占用率合理（未占满单核）

8.4 存档系统测试（10 项）

• 手动存档功能正常
• 自动存档触发正常
• 多存档槽位互不干扰
• 存档后退出再读档，进度完整
• 存档文件损坏时有提示（不崩溃）
• 云存档同步正常（Steam Cloud）
• 存档版本兼容性（旧版本存档可在新版本加载）
• 存档加密/完整性校验正常
• 存档文件大小合理（不过大）
• 存档目录备份功能正常

8.5 UI/UX 测试（15 项）

• 所有菜单可正常打开/关闭
• 所有按钮可点击且有反馈
• 文字无溢出/截断
• 图标显示正确
• 动画过渡流畅
• 手柄导航正常（焦点切换）
• 键盘导航正常（Tab 键切换）
• 不同分辨率下布局正确
• 超宽屏下无拉伸/黑边
• 色盲模式下可辨识
• 字体大小可调
• 音量控制即时生效
• 亮度/Gamma 调节正常
• 字幕显示/隐藏正常
• 键位重映射正常

8.6 本地化测试（10 项）

• 所有语言的文本完整（无漏翻译）
• 特殊字符（中文/日文/韩文/俄文）显示正常
• 文本方向正确（阿拉伯语 RTL）
• 文本长度适配 UI（德语通常比英语长 30%）
• 字体在各语言下清晰可读
• 日期/时间格式符合地区习惯
• 数字格式（千位分隔符）正确
• 货币符号正确
• 音频字幕与语音同步
• 文化敏感性检查（无冒犯性内容）

九、附录

附录 A：崩溃日志分析工具推荐

附录 B：自动化测试框架配置指南

Unity + GitHub Actions 完整配置

# .github/workflows/test.yml
name: Unity CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  run-tests:
    name: Run Unity Tests
    runs-on: ubuntu-latest
    strategy:
      matrix:
        testMode: [EditMode, PlayMode]
    steps:
      - uses: actions/checkout@v4
        with:
          lfs: true

      - uses: actions/cache@v3
        with:
          path: Library
          key: Library-${{ hashFiles('Assets/**', 'Packages/**') }}

      - name: Run Tests
        uses: game-ci/unity-test-runner@v4
        with:
          unityVersion: 2022.3.20f1
          testMode: ${{ matrix.testMode }}
          githubToken: ${{ secrets.GITHUB_TOKEN }}
          coverageOptions: generateBadgeReport

      - uses: actions/upload-artifact@v3
        if: always()
        with:
          name: Test results (${{ matrix.testMode }})
          path: artifacts

附录 C：月度 QA 报告模板

【项目名】QA 月报 - [年/月]

1. 概览
   - 本月构建次数：XX
   - 发现 Bug 总数：XX（P0: X, P1: X, P2: X, P3: X）
   - 修复 Bug 总数：XX
   - 剩余 Bug 总数：XX
   - Bug 修复率：XX%

2. 崩溃统计
   - 本月崩溃总次数：XX
   - Top 5 崩溃原因：
     1. [崩溃描述] - XX 次
     2. ...
   - 崩溃率变化趋势：上升/下降/稳定

3. 测试覆盖
   - 冒烟测试执行次数：XX
   - 回归测试执行次数：XX
   - 探索性测试时长：XX 小时

4. 风险评估
   - 当前最大的质量风险：
   - 建议采取的措施：

5. 下月计划
   - 重点测试区域：
   - 预计修复的 Bug 列表：

QA 测试是一项需要系统性思维和持续投入的工作。对于独立开发者而言，资源有限意味着必须更聪明地分配测试精力。核心原则是：优先保证游戏不崩溃、不坏档、不卡死，在此基础上逐步修复其他问题。

记住一条铁律：一个稳定的 7 分游戏，永远比一个充满 Bug 的 9 分游戏卖得更好。

希望本文提供的工作流、模板和清单能帮助你建立适合自己项目的 QA 体系，让你的游戏以最佳状态与玩家见面。