每一个测试都通过了，用户却依然无法玩游戏

“API 返回了 200 OK！”

在我的第一份工程工作中，我发现了一个重大问题。我的前辈们热衷于仪表盘，热衷于高代码覆盖率。他们认为只要测试是绿色的，产品就是正常的。

他们错了。

代码运行正常与用户获得所需体验是两回事。一个按钮可以返回成功代码，却让用户卡在一个损坏的界面上。

我开发了一种无需运行应用程序即可发现这些 UX 死胡同的方法。我称之为“双智能体静态走查”（two-agent static walkthrough）。它使用两个 AI 智能体进行循环对话。

  • 智能体 A 是用户。该智能体有一个明确的目标。它很固执，不会在犯一次错后就放弃，而是会不断尝试不同的路径。
  • 智能体 B 是应用程序。它拥有对实际源代码的读取权限。它会追踪用户每一个动作的代码路径。它会准确报告代码的行为，并引用具体的文件和行号。它不会凭空想象代码中不存在的东西。

我在一个损坏的 AI 小游戏生成器上进行了测试。以下是发生的情况：

回合 1：按钮失效。 用户点击了“Generate”。代码将请求发送到了一个旧的、已失效的端点，而不是新的端点。测试通过了，因为旧的 API 仍然有效。

回合 2：无法点击的虚无。 用户尝试点击结果。代码将文本放在了一个没有任何点击处理程序的普通框中。什么也没发生。

回合 3：虚假的祝福。 用户尝试修复错误。由于缺少 ID，后端运行失败。尽管系统已经崩溃，屏幕上却显示了绿色的成功消息。

回合 4：被截断的希望。 用户尝试手动复制代码。API 在中途截断了文本。代码是损坏的。

用户离开了。

大多数单元测试只检查端点是否返回 200。它们并不检查用户是否真正达到了目标。

如何使用：

  • 让用户智能体变得固执。真正的 Bug 往往隐藏在第一次错误之后。
  • 让应用智能体基于真实代码。这能将角色扮演转化为真实的 Bug 报告。
  • 将其作为测试的补充。它能发现逻辑与现实交汇处的缝隙。

这种方法是静态且低成本的。甚至在你编写第一个测试夹具（test fixture）之前，它就可以运行。它将“代码能跑通”转变为“用户能成功”。

Source: https://dev.to/terum/every-test-passed-the-user-still-couldnt-play-the-game-388o

Optional learning community: https://t.me/GyaanSetuAi