功能测试：捕获真实 bug 的枯燥基础

Source: Dev.to

TL;DR

What it is: 用于限时单人测试的功能测试工作流。
Backing project: Battletoads PC 版（Game Pass），为期一周的测试通行证（2025 年 10 月 27 日 – 11 月 1 日）。
Approach: 首先验证 Start → First Control 与 Pause/Resume，随后在风险出现的地方扩展测试（通常是输入和焦点）。
Outputs: 通过/失败结果、可复现的缺陷报告，以及支持每个发现的简短证据记录。

在为期一周的 Battletoads（PC）测试期间使用的功能测试工作流。

功能测试工作流的背景与范围

本文基于对 Battletoads（PC，Game Pass） 的自我导向作品集通关，构建版本 1.1F.42718，在一周的时间盒中进行。

测试重点是 核心功能流程 和 混合输入所有权（controller + keyboard），并捕获了简短的证据剪辑以便复现。

什么是功能测试（实践中）

对我而言，功能测试很简单：产品是否如其声称的那样端到端工作，没有借口或解释？

我验证核心流程，确认预期行为，并编写问题，使开发者能够在不猜测的情况下复现它们。

错误在于把功能测试当作“容易”的，从而认为它价值较低。它是基础。如果基础出现裂缝，所有建立在其上的东西都会以更复杂的方式失败。

功能测试输出：带证据的通过/失败结果

• 明确的结果：pass 或 fail，并附有证据和可复现的步骤。
• 不是感受。不是观点。

我首先验证的两个流程

1. 从开始到第一次控制
   第一分钟决定产品是否感觉已损坏。 如果 “New Game” 不能可靠地让你开始游戏，其他一切都无关紧要。
   在 Battletoads 中，我在标题画面进入第 1 关并通过第一次竞技场过渡时进行验证，然后再expanding scope。

2. 暂停与恢复
   暂停会对状态、焦点、输入上下文、UI 导航和覆盖层造成压力。 如果暂停不稳定，你会遇到一连串看似随机但实际有因果的缺陷。
   在 Battletoads (PC) 中，这一问题早期表现为键盘和手柄在暂停及Join In 时的路由问题。

输入所有权测试：控制器与键盘交接

混合输入是一个特性，而不是边缘情况。当连接了控制器并使用键盘时，行为必须保持可预测。

• 暂停必须始终打开。
• 导航必须遵循当前的输入方式。
• 确认和返回不能悄然失效。
• 交接不能导致错误的 UI 路由或禁用输入。

我将键盘 ↔ 控制器的交接视为专门的测试领域，因为它会产生高影响、易于复现的缺陷。在本次 Battletoads 测试中，混合输入可能会误导动作（例如 Resume opening Join In）并暂时破坏控制器响应。

常见模式：混合输入导致菜单焦点错误

控制器已连接 + 键盘输入 + 菜单打开 = 焦点错误。

• 易于复现。
• 易于验证。
• 隔离后易于修复。

Bug 证据：我捕获的内容及原因

我倾向于使用短视频片段（10 – 30 秒），仅在截图能提高清晰度时才使用截图。目标是让缺陷一目了然，而不需要让人去浏览冗长的录制。

如果证据无法回答按下了什么、发生了什么和应该发生什么，则它不算证据。

我如何为一周的通行设定时间盒

实用提示: 我在每次会话开始时先进行一个简短的基线循环（加载、获取控制、暂停、恢复），然后再进行更深入的检查。它能及早捕获明显的故障，防止浪费时间。

用于功能验证的测试 Oracle

• 游戏内 UI 与结果 – 可观察到的核心流程行为（控制、进度、暂停/恢复）。
• 控制菜单绑定 – 作为预期键位行为的 Oracle（例如 Esc 和 Enter 键的绑定）。
• 重复运行的一致性 – 通过重新运行确认行为，以排除一次性差异。

示例来自 Battletoads 功能通关

示例错误模式：混合输入导致暂停和覆盖层错误路由

• 在 PC 上连接手柄时，使用手柄 Start 可以可靠地打开和关闭暂停。
• 在暂停界面使用键盘交互可能被忽略或错误路由到 Join In，并且在一次观察中，手柄在覆盖层关闭前一直无响应。

已捕获简短的证据剪辑，以同时展示输入、时机和结果。

微章程：暂停和覆盖层的混合输入所有权

• 章程： 暂停和覆盖层的混合输入所有权（手柄 + 键盘）。
• 目标： 在常见 PC 设置下确认可预测的焦点、导航以及确认/返回操作。

Functional testing takeaways (flows, input, evidence)

• 功能测试能够及早发现高影响缺陷，因为它针对的是其他所有系统依赖的核心系统。
• 暂停和叠加层是可靠的 bug 生成器，因为它们会对状态和输入路由施加压力。
• 在 PC 上，混合输入应当 tre

功能测试常见问答（手动 QA）

功能测试仅仅是基础或初级测试吗？

否。 功能测试验证所有其他功能所依赖的核心系统。若执行不当，团队会追踪看似“随机”的缺陷，实则是基础性故障。

功能测试只检查顺畅路径吗？

否。 测试从顺畅路径开始，但会在出现风险的任何地方展开。输入所有权、暂停/恢复以及状态转换是常见的失败点。

功能测试与回归测试有什么区别？

功能测试验证预期行为的 端到端 表现。回归测试则确认在代码变更后，之前正常的行为仍然保持。两者有交叉，但回答的是不同的问题。

即使有自动化，功能测试仍然有意义吗？

是。 自动化依赖于对预期行为的正确理解。功能测试提供这一基准，并能发现自动化常常遗漏的问题。

什么样的功能缺陷报告算“好”？

• 清晰的操作步骤
• 明确的预期结果
• 明确的实际结果
• 简短的证据，能够同时展示输入、时机和结果

附加要点

• Primary scenario vs. edge case: 将主要场景视为重点；边缘情况为次要。
• Evidence clips: 短的证据剪辑可以降低复现歧义并加快分流。
• Repetition: 重复相同的步骤是将“随机”问题转化为可诊断模式的方式。

Evidence and Case‑Study Links

• (Add link here)
• (Add link here)

这篇 dev.to 文章专注于工作流程。案例研究链接到工作簿结构、运行情况和证据。