Can LLMs Test Terminal User Interfaces?

想象一下你是一名游戏开发者。你构建了一个美丽而复杂的世界，有山脉、城市和角色，但你忘了测试门是否真的能打开，或者玩家是否会卡在墙里。在软件的世界里，这简直是一场噩梦。为了防止这种情况，程序员使用“自动化测试器”——这些是机器人助手，它们点击按钮、输入命令，并试图破坏软件，以便在真实用户使用之前发现漏洞（bug）。

长期以来，我们一直有两种主要的测试软件类型。首先是图形用户界面（GUI），比如你手机或电脑上的应用。这些就像是装饰华丽、带有标签门窗的房间。测试者可以轻松地询问计算机：“‘开始’按钮在哪里？”然后点击它。其次是命令行界面（CLI），它们像是老式的电报。你输入一段秘密代码，计算机就会以文本形式回复你。这些很容易测试，因为它们很简单：输入这个，得到那个。

但有一种更隐蔽的第三类软件叫做终端用户界面（TUI）。把它们想象成“复古未来主义”的应用。它们看起来像旧式电报（黑屏上的纯文本），但其行为却像那些华丽的房间。它们有移动的光标、弹出菜单，以及随着你的输入而改变的复杂状态。这类应用在黑客、系统管理员甚至 AI 编程助手群体中非常流行。问题在于，我们并不真正了解如何正确地测试它们。它们对于简单的电报测试器来说太复杂了，但又不像华丽房间的测试器那样拥有“标签化的按钮”。这篇论文提出了一个大问题：现代人工智能（AI）机器人能否学会测试这些棘手的文本应用，还是说它们也会像我们一样感到困惑？

---

伟大的 TUI 侦探故事

这篇论文背后的研究人员决定扮演侦探。他们收集了 197 个真实的现实世界 TUI 应用——从文件管理器到系统监视器不等——并将它们置于严格的压力测试之中。但首先，他们必须解开一个谜团：这些应用的测试现状究竟如何？

他们窥视了这 197 个应用的内部代码，发现了一个令人震惊的秘密。只有大约 12% 的测试代码实际上尝试与屏幕进行交互。更糟糕的是，近一半在“触碰”屏幕的测试甚至从未输入过任何按键！它们只是检查应用刚启动时屏幕看起来是否正常，就像是在检查汽车的喷漆，却从未发动引擎。事实证明，大多数 TUI 都是在“闭着眼睛”进行测试的。

于是，团队构建了自己的工具，以观察如果让他们把 AI 和随机性释放到这些应用中会发生什么。他们创建了一个“无头”实验室（一个没有屏幕、只有一个虚拟终端的计算机），并将每个应用封装在一个特殊的容器中。随后，他们设置了一场四种策略之间的竞赛：

1. 随机猴子： 一个只会尽可能快地输入随机按键的机器人。
2. AI 指南： 一个聪明的语言大模型（LLM），它观察屏幕并决定下一步输入什么。
3. 带有地图的 AI 指南： 同一个聪明的机器人，但这一次它还弄清楚了正确的“启动代码”（参数），以便让应用正常启动。
4. AI 剧本作家： 一个阅读源代码并在开始前编写测试计划的机器人。

他们针对这 197 个应用运行了这些策略，给每个应用正好 600 秒（10 分钟）的时间来寻找漏洞。

结果：谁赢了？

结果令人惊讶，甚至有些反直觉。

1. “聪明”的机器人并不是最快的。
当研究人员观察每轮运行中各策略发现的漏洞数量时，随机猴子实际上发现的崩溃次数最多。为什么？因为它速度极快。在 600 秒内，这个随机机器人可以输入数百个按键。而 AI 机器人由于需要思考并等待答案，显得过于“聪明”，在相同时间内它们只能输入大约十几个按键。

2. 但“聪明”的机器人效率更高。
这里有一个转折：如果你以“每次按键”为衡量标准，AI 机器人的表现比随机猴子高出 13 倍。随机猴子只是在黑暗中盲目投掷飞镖，靠运气撞上几个目标；而 AI 机器人则是在精准瞄准。它们能够独特地发现“输入门槛型”漏洞——即只有通过输入特定按键序列才能解锁隐藏菜单才会触发的崩溃。随机猴子永远无法破解那个代码，但 AI 可以。

3. “启动代码”才是真正的英雄。
最大的突破并非来自 AI 的智能，而是它理解如何启动应用的能力。许多 TUI 需要特定的文件或参数才能打开界面，否则它们会直接退出。使用 AI 自动推导启动输入的策略发现了最多的漏洞，并覆盖了最多的代码。事实证明，如果你不知道如何转动车钥匙，你就无法测试一辆车。

4. “崩溃”陷阱。
研究人员还发现了一个我们在统计漏洞时经常掉入的陷阱。他们发现，82% 的所谓“崩溃”（程序意外停止）实际上只是程序在说：“嘿，我需要一个文件！”或者“我被告知要停止了！”这些并不是真正的漏洞，只是正常的行为。如果仅仅计算程序停止的次数，你会得到大量的假警报。团队必须构建一个特殊的“崩溃检测器”，通过观察屏幕上的实际文本，来判断这是一个真正的错误还是一个礼貌的退出。一旦过滤掉这些噪音，他们在 197 个应用中发现了 179 个真实的、有效的漏洞。

5. 代码覆盖率 $\neq$ 更多漏洞。
在软件测试领域，人们通常认为如果覆盖了更多的代码行，就能发现更多的漏洞。论文指出，这对 TUI 并不成立。他们发现，发现最多崩溃的测试往往具有较低的代码覆盖率。为什么？因为一旦发生崩溃，测试就会立即停止！测试被提前切断了，因此永远无法覆盖剩余的代码。这意味着，对于 TUI 而言，通过计算触及了多少行代码来衡量测试质量是一种错误的方法。

核心结论

论文总结道，虽然对这些基于文本的界面进行自动化测试是可能的，但远未解决。没有任何一个 AI 模型是绝对的胜者；事实上，一个简单的随机测试器也很有竞争力，因为它速度更快。成功的关键在于混合策略：利用 AI 来确定如何启动应用并导航到正确的状态，然后利用高速随机测试来对界面进行压力测试。

作者同时警告我们，我们需要更好的工具。目前的测试方式（仅仅检查程序是否停止）充满了假警报。他们发布了自己的工具 tuicov 和 tuibot，以帮助他人更正确地测试这些应用。传达的信息很明确：TUI 是我们软件世界中巨大且增长中的一部分，但目前它们仍处于测试的“西部荒野”阶段。我们已经有了开始驯服它们的工具，但我们需要停止依赖旧规则，开始设计能够理解这些界面独特的、基于文本特性的测试方法。