最近听了多场 workshop，看了一些大会议题，以及网友们在群里的提问。其中一个热点话题是关于 AI 赋能 GUI 自动化测试。一些设想和实践讨论都带着同一个基调——把 LLM 或 Agent 使劲用一把，兴许大力能出奇迹，解决 GUI 自动化的各种痛点。但是，我们的痛点到底在哪里？AI 解决这些痛点会比非 AI 方案更快更好吗？
先说结论——AI 在 GUI 自动化测试的"探索"还处于早期阶段，面临各种各样的挑战。下面展开多个场景探讨 GUI 自动化面临的挑战，以及 AI 能为我们做些什么：
我们对 GUI 自动化目标和改进的评价标准是什么？软件工程上，自动化是用来替代手工测试的。所以一个目标是完全替代手工测试。但是这样的目标在不同的组织和公司中是完全不一样的，"覆盖率提升 100%、成本节省 50%"之类的说法过于空泛，不具有参考意义和现实意义。近年来，自动化优化的另一个方向是提升测试覆盖（通过自主遍历），而不是照搬手工用例，那么如何评价自动化方法的改进比没有改进更好呢，这确实是一个评价难题。如果说代码覆盖率和需求点覆盖率，这也不具有普世意义，从 A 系统到 B 系统，结果完全不同。此外，"减少测试自动化维护成本、降低自动化开发投入"之类的说法，也过于抽象且缺乏借鉴意义。在当前 AI 应用的探索中，更多看到的是将某个大模型部署在自身工作中，然后截图，通过 LLM 解析截图，得到期望的结果，以此来评价 AI 应用的效果。当然，最近有另外一种趋势，就是试图参考学术界，开发一个基准测试来研究优化的优势。但是，属于 A 公司项目的基准，能用在 B 公司上吗？这和 ImageNet 在图像处理中的广泛采用相距甚远。所以，我们在讨论任何 GUI 自动化测试改进时，我们的评价标准是什么？这样的度量衡能够统一吗？
自动化失败是让它 Pass？还是报告 Bug？最近，在 AI 赋能 GUI 自动化上有个方向就是自愈——希望在被测试对象版本 1 开发的 GUI 测试脚本能够自动迁移到版本 2 上。这个方向的动机是希望降低自动化维护的成本（这也是 GUI 自动化测试最痛的痛点）。但是，从版本 1 迁移到版本 2 后，你发现某个 GUI 的变化（例如文字从"1"变成"I"），在这样的情况下：1）你是希望自动化能自我演化，让原本 Failure 的测试能 Pass？还是 2）你要坚守这样的 GUI 变化是不被期望的，不能启动自愈，必须维持自动化不变然后报告缺陷？在你不微调 AI 模型的情况下，如何知道使用的 AI 具有泛化能力，能够解决（以多大的概率）你实际碰到的问题（多少问题、多少不同的场景），正确地把 1 和 2 按照人的意志（GUI 测试本身也存在主观认知的个体差异性）区分开。把一个通用的黑盒 AI 模型应用在区分 1 和 2 的任务上，这陷入了 AI 不可解释的窘境。而如果你打算通过微调来解决的话，你能准备足够的样本吗？训练是正确且高效的吗？微调的成本就比不基于 AI 的方案更小吗？可以观察到的一个现象背后的原因是，有时人们混淆了"GUI 自动化"和"GUI 自动化测试"这两个概念，这也是 Agent 最近爆发给大家带来的误解——看到 Agent 可以自主完成复杂的操作任务，而忽视了我们自动化的目标不仅要"容忍"错误，也要"坚守"真理。所以，在改进 GUI 自动化时，如何把两个任务都高效地完成，AI 并没有展现出高人一等的趋势。
GUI 自动化真能代替人的视觉感知吗？基于 AI 去感知当前 UI 界面是否与预期符合，这取决于你怎么定义"预期"和怎么定义"符合"。最原始和直接的办法是"预期"就是整张截屏，"符合"就是每个 Pixel 的 RGB 都相等。但是，这样做的问题是当有局部扰动时，就会造成测试执行失败。于是，后来出现了控件标识识别、图像模板匹配、OCR 以及其他一些方案。这些方案是将"预期"缩小到局部，将"符合"变成一致性断言算法。再到后，深度学习出现了，它将"预期"和"符合"整合在一起，都通过 AI 模型来实现"特征"和"比较"的学习与预测。这样基于深度学习的方案降低了设计图像感知和判别器的门槛（因为端到端的学习和预测都由 AI 模型来完成），但是除了成本（准备训练样本和训练硬件）的提升外，和传统方案一样会陷入过拟合和泛化能力不足的情况。现今的大语言模型（或者多模态模型）表面上看似乎能解决成本问题（免费和低成本），但延时过高和泛化能力问题依然未被解决。当然这些都是基于当前时刻截图所做的努力，这就好比一个人每十几秒睁开眼睛然后迅速闭上的状况。你必须创造一个具有 240FPS、8K、超大缓存、并且知晓 UI 操作因果关系的拟人视觉智能体，才能称得上代替你的眼睛。如果你还造不出这样的超级智能体，要么就接受各种的特征提取和比对算法（不论是 AI 还是非 AI，都是将高维视觉信息压缩成低维可对比信息，这样的压缩是有损的），要么还是雇佣经验丰富的手工测试人员去做 GUI 测试。
无法逃离基于模型驱动的测试？我们依然基于通用人工智能来探讨 GUI 的自动化测试。从用户需求或对产品的设想出发，开发和测试走上两条分支。开发建立计算机模型去将产品的设想实例化和物理化。测试走在另外一条路上，通过模型去抽象用户的交互过程，然后通过测试用例去实例化这种交互过程。AI 无法改变这样的开发和测试模式，因此也就无法处理最终产品和测试的"不一致"和"保持一致"这种看似自相矛盾、但需要测试去维护的状态。目前，在 GUI 自动化测试的学术和工业领域，基于模型驱动测试（测试需求->测试模型->测试脚本）依然是采用的范式，而维护 “一致性” 这个矛盾在 AI 的加持下依旧无法很好地被解释、定义，就更谈不上解决和工业界的采用了。
当然，GUI 自动化测试还有很多挑战，本文只是提出了一些有代表性的案例进行探讨。这些挑战能否解决，取决于 AI 在测试领域的三个未来问题的解决程度和结果，我在另外一篇文章中已经进行了阐述。总而言之，AI 虽然在个别领域和某些案例上有效果，但并没有表现出广泛性地比非 AI 方法更高效的"提升"趋势，况且我们对"提升"本身都存在模糊的定义。
和你一样，我也在思考如何破局。但是，现在来看，这样的期望似乎只是反映了当下 AI 依旧很火热的状况，仅此而已。
前路慢慢，与各位一起求索。
张昊翔
2025/05/22
WeChat: hzhan11
QQ: 22321262
Email: xjtu_xiangxiang@hotmail.com
LinkedIn: https://www.linkedin.com/in/hzhan11/