Can LLMs Test Terminal User Interfaces?
arXiv 论文 2608.03743v1 调查了 197 个真实 TUI 应用，发现仅 12% 的测试代码覆盖界面，45% 的测试从不发送输入。作者构建了跨 ratatui/Rust、bubbletea/Go、textual/Python、ink/TypeScript 的无头基准，比较四个前沿 LLM 与随机探索。结果显示无模型占优，随机基线在时间预算下更强，但 LLM 每次交互更高效且能到达输入门控故障。自动推导启动输入带来最大实际收益。行覆盖率不能预测崩溃发现。
发展脉络
- 首次出现Can LLMs Test Terminal User Interfaces?arXiv cs.AI
- 当前判断TUI 在开发者工具中日益普遍，但测试方法缺失，LLM 驱动的自动化测试可能填补空白。当前 LLM 在 TUI 测试中未占优，说明该领域尚未成熟，存在工具和基准的机会。Agent Pulse · 分析
该论文针对终端用户界面（TUI）缺乏专门测试方法的问题，调查了 197 个真实 TUI 应用，发现仅 12% 的测试代码实际与界面交互，45% 的测试从不发送输入。作者构建了一个无头基准，涵盖 ratatui/Rust、bubbletea/Go、textual/Python 和 ink/TypeScript 四种框架，将每个应用打包为带插桩的 Docker 镜像，记录行覆盖率、组件覆盖率、渲染状态和崩溃。在相同墙钟时间预算下，比较了四个前沿 LLM 与随机探索。结果显示没有模型全面占优；随机探索在时间预算下是强基线，但其崩溃优势来自更高吞吐量，而 LLM 每次交互更高效，且能独特地到达输入门控故障。自动推导启动输入带来最大实际收益，使原本无法启动的应用得以运行。行覆盖率对崩溃发现的预测能力弱，削弱了其作为测试有效性代理的可靠性。论文结论是自动化 TUI 测试可行但远未解决。
该研究揭示了 LLM 在 TUI 测试中的能力边界：在固定时间预算下，随机探索因吞吐量高而崩溃发现更多，但 LLM 每次交互更高效，且能到达输入门控故障，说明 LLM 的指导性在交互层面有独特价值。行覆盖率与崩溃发现弱相关，表明覆盖率指标可能不适用于 TUI 测试。自动推导启动输入是最大增益点，提示未来可优先研究启动参数生成。
TUI 在开发者工具中日益普遍，但测试方法缺失，LLM 驱动的自动化测试可能填补空白。当前 LLM 在 TUI 测试中未占优，说明该领域尚未成熟，存在工具和基准的机会。
对 TUI 开发者工具厂商，LLM 测试可降低测试成本，但当前效果有限，需谨慎投资。对测试工具创业公司，该基准提供了评估和改进 LLM 测试的起点。
未来可期待更高效的 LLM 测试策略，如结合随机探索与 LLM 指导，以及自动推导启动输入的工具。行覆盖率作为代理指标可能被更有效的指标取代。