回归测试工作流：风险优先检查以保持发布稳定
Source: Dev.to
Workflow shown: 风险优先的回归范围 → 黄金路径基线 → 目标探测 → 基于证据的结果。
Example context: Sworn 在 PC Game Pass（Windows）上，仅用作真实案例示例。
Build context: 在 PC Game Pass 构建 1.01.0.1039 上进行测试。
Scope driver: 使用公开的 SteamDB 补丁说明作为外部变更信号（不假设平台一致性）。
Outputs: 回归矩阵，包含逐行结果、会话时间戳以及带有证据的缺陷工单。
回归测试流程用于在限定时间的 Sworn（PC）通关期间验证变更后的稳定性。
回归测试范围：我验证了什么以及原因
本文基于对 Sworn 在 PC Game Pass (Windows) 构建 1.01.0.1039 的自驱动作品集回归测试，使用了一周的单人时间盒进行。
范围是 变更驱动 且 风险导向 的：
- 黄金路径稳定性（启动 → 游玩 → 退出 → 重新启动）
- 保存并继续的完整性
- 核心菜单
- 音频健康检查
- 输入交接
- 上游补丁说明中建议的副作用探针
不作 Steam 与 Game Pass 的等价性声明。
回归测试是什么（实践中）
对我而言，回归测试很简单：在一次更改之后，现有行为是否仍然保持？
- 不是“重新测试所有东西”。
- 不是“因为我们惯例而执行检查清单”。
回归测试本身是有选择性的设计。覆盖范围由风险驱动：
- 最有可能受到影响的是什么？
- 如果出现故障，代价最高的是什么？
- 为了让构建可信，必须保持稳定的是什么？
回归测试输出：带证据的 pass/fail 结果
- 清晰的结果：pass 或 fail。
- 有证据支持且可重复验证。
- 没有意见，没有“vibes”。
回归测试的黄金路径冒烟基线
我在每个回归周期开始时都会进行可重复的黄金路径冒烟测试，因为它可以防止浪费时间。如果基线不稳定，后续更深入的测试就会变成噪音。
在本次 Sworn 通过中，基线行是 BL‑SMOKE‑01：
cold launch → main menu → gameplay → quit to desktop → relaunch → main menu我还会在此流程中快速检查音频是否出现断裂。
“有些系统绝对不能出错。这些系统就是你在每次构建时都需要先验证的对象，之后再进行更深入的测试。”
— Conrad Bettmann，质量保证经理（Rovio Entertainment）
为什么基准稳定性在回归测试中很重要
黄金路径包括最常见的玩家操作（启动、播放、退出、恢复）。如果这些操作不稳定，就会出现级联故障，伪装成无关的缺陷。
回归测试范围：变更信号和风险
在本项目中，我使用 SteamDB 的补丁说明作为 外部预言机：
SWORN 1.0 Patch #3 (v1.0.3.1111)，2025 年 11 月 13 日
这并 不 意味着我假设这些更改已经出现在 PC Game Pass 上。相反，我把补丁说明当作 变更信号，用来决定在 Game Pass 版本上哪里可能出现副作用并进行探测。当你没有内部访问权限、没有工作室数据，也没有平台的变更日志时，这种做法非常有用。
了解哪些内容发生了变化以及变化的具体位置，能够让你将回归测试聚焦在受影响的区域，而不是进行范围过大的检查，这类检查往往找不到有价值的信息。通常最好结合多个预言机，而不是仅依赖单一来源。
“当内部文档不可用时，外部预言机是一种务实的方式，用于驱动基于风险的回归测试。”
— Conrad Bettmann，质量保证经理（Rovio Entertainment）
Regression outcomes: pass vs. not applicable (with evidence)
- SteamDB 备注提到了 music‑cutting‑out fix，因此我运行了音频运行时探测 (STEA‑103‑MUSIC) 并验证了在战斗、暂停/恢复以及关卡加载期间音乐的连续性 —— pass。
- SteamDB 还提到了 Dialogue Volume 滑块。在 Game Pass 版本中该控制不存在，因此检查记录为 not applicable，并提供了缺失的证据 (STEA‑103‑AVOL)。
我的回归矩阵结构
我的回归矩阵行编写为可审计的。每行包括：
- 直接检查
- 副作用检查（如适用）
- 明确的结果
- 证据链接
这使得结果可审查，并防止“我觉得没问题”的报告。
示例矩阵行
| ID | Description |
|---|---|
| BL‑SMOKE‑01 | 基线冒烟 |
| BL‑SET‑01 | 设置持久化 |
| BL‑SAVE‑01 | 保存并继续完整性 |
| BL‑DEATH‑01 | 死亡后流程合理性 |
| STEA‑103‑MUSIC | 音频运行时连续性探测 |
| STEA‑103‑AVOL | 音频设置存在性检查 |
| STEA‑103‑CODEX | Codex 与 UI 导航合理性 |
| BL‑IO‑01 | 输入交接 + 热插拔 |
| BL‑ALT‑01 | Alt‑Tab 合理性 |
| BL‑ECON‑01 | 增强消耗 + 所有权持久化 |
Save‑and‑Continue 回归测试：锚点，而非氛围
Save‑and‑Continue 流程是经典的回归风险区域，因为故障可能表现为间歇性。为减少歧义，我使用 锚点 进行验证。
在本次测试 (BL‑SAVE‑01) 中，我设置了以下锚点：
- Room splash name – Wirral Forest
- Health bucket – 60/60
- Weapon type – sword
- Start of objective text
随后，我在 menu Continue 之后以及 full relaunch 之后验证了这些锚点。
结果: 通过 – 锚点在整个过程中匹配 (会话 S2)。
为什么锚点使回归结果可重复
如果其他人无法验证你所恢复的内容，“继续工作”并没有用。锚点把“看起来不错”转化为可重复的验证结果。
回归测试的 QA 证据：我捕获的内容及原因
对于回归测试，证据至关重要。我为每一次检查捕获以下内容：
| 证据类型 | 目的 |
|---|---|
| 屏幕录制 | 提供 UI 状态、页面切换以及任何异常的可视化证明 |
| 日志摘录 | 展示内部状态、错误信息或操作确认 |
| 音频片段 | 验证连续性、无中断以及正确的音量水平 |
| 带时间戳的截图 | 将视觉状态与测试会话中的具体时刻关联 |
| 自动化测试输出（如有） | 提供可复现的脚本步骤和结果 |
所有证据都会存放在共享文件夹中，并在回归矩阵中进行链接，确保任何人都能在不依赖记忆或主观描述的情况下审计测试结果。
证据指南
- 视频剪辑 – 同时显示输入、时间和结果（适用于流程和音频检查）。
- 截图 – 支持 UI 状态、菜单的出现/消失以及错误的清晰度。
- 会话时间戳 – 在不需要快速浏览长录音的情况下，使验证可审查。
- 环境备注 – 平台、构建版本、输入设备、是否启用云存档。
如果证据无法回答 已完成的操作、发生了什么以及本应发生的情况，则它不算证据。
回归测试示例（来自 Sworn 通过）
示例回归缺陷：失败覆盖层阻挡统计界面 (SWOR‑6)
缺陷： [PC][UI][Flow] 失败覆盖层阻挡统计；继续会启动新一局 (SWOR‑6)
- 预期： 失败后，点击 Continue 应在前景显示完整的统计界面，并等待玩家确认。
- 实际： 失败画面仍停留在前景，统计界面在其下方渲染并出现加载图标，随后自动开始新一局。结果——无法查看统计信息。
- 复现率： 3/3（在进度验证 S2 中观察到，并在专门的复测 S6 中再次确认）。
补丁说明探查示例：音乐连续性检查 (STEA‑103‑MUSIC)
SteamDB 备注提到修复了音乐中断问题，于是我执行了 STEA‑103‑MUSIC：
- 测试： 10 分钟运行时间，包含战斗切换、暂停/恢复以及关卡加载。
- 结果： 通过 – 音乐在这些切换过程中保持连续 (S3)。
有证据支持的“不可适用”示例：缺失对白音量滑块 (STEA‑103‑AVOL)
SteamDB 备注提到有对白音量滑块，但在 Game Pass 版本的音频菜单中仅显示 Master、Music 和 SFX。
- 结果： 不可适用，并提供缺失证据 (STEA‑103‑AVOL, S4)。
- 这样避免了自行编造对应性，并保持矩阵的真实性。
记录为已知集群的可访问性问题（暂无新构建可复测）
在第 0 天 (S0) 我将入门可访问性问题捕获为已知集群 (B‑A11Y‑01：SWOR‑1、SWOR‑2、SWOR‑3、SWOR‑4)。
- 由于本周没有更高版本的构建，回归复测 不可适用，直至出现新构建。
- 该情况已明确记录，而非隐含。
Results Snapshot (for transparency)
In this backing pass the matrix recorded:
- 8 Pass
- 1 Fail
- 1 Not applicable
- 1 Known accessibility cluster captured on Day 0 with no newer build available for retest
Counts are included for context, not as the focus of the article.
回归测试要点（风险、证据与验证）
- 回归测试是 基于变更的验证，而不是“重新测试所有内容”。
- 可重复的 黄金路径基准 能防止你在不稳定的构建上浪费时间。
- 外部补丁说明可用作 风险信号，无需假设平台一致性。
- 锚点 使进度和恢复验证具有可信度且可重复。
- 不适用 是有效的结果，只要有证据支持，而不是随意说明。
- 通过的结果也需要证据，因为它们仍然是声明。
回归测试 FAQ（手动 QA）
回归测试只是重新测试旧的 bug 吗？
No. 它验证在更改后现有行为仍然正常，无论是否曾对这些系统记录过 bug，都会覆盖之前正常工作的系统。
在回归测试中需要重新测试所有内容吗？
No. 有效的回归测试是有选择性的。范围由更改和风险驱动，而不是功能数量。
如何在没有内部补丁说明的情况下确定回归测试范围？
通过使用外部变更信号，如公开的补丁说明、以前的构建以及观察到的行为作为判据，而不假设平台一致性。
回归测试与探索性测试有什么区别？
- 回归测试： 在更改后验证已知行为。
- 探索性测试： 搜索未知风险和新出现的失效模式。
它们相互补充，但回答的是不同的问题。
在回归测试中通过结果有意义吗？
Yes. 通过仍然是一种声明，因此回归通过应有证据支持，而不仅仅是勾选框。
何时“不可适用”是有效的回归结果？
当被测构建中不存在某个功能且该缺失已通过证据确认时。明确记录这一点比假设一致性或悄悄跳过检查更诚实。
证据与案例研究链接
- (添加指向工作簿标签的链接：Regression Matrix、Sessions Log、Bug Log)
- (添加指向证据剪辑的链接)
此 dev.to 帖子专注于回归工作流。案例研究链接指向工作簿标签和证据剪辑。