Drizz 的 AI 应用测试野心与现实

移动应用测试往往是一场与变化的赛跑。重新设计的界面、被改名的按钮或意外弹出的窗口，都可能让自动化测试失败，迫使开发者花时间修复脚本，而不是测试功能。

总部位于班加罗尔的 Drizz 希望用 AI 让这一过程不那么脆弱。其智能体 Fathom 使用视觉模型来解读应用界面，并根据自然语言指令执行测试，而不是仅仅依赖预定义的元素标识符。

但让 AI 与应用交互，比让它可靠地做到这一点要容易得多。Drizz 的基准测试显示，在不同测试环境中性能急剧下降，凸显了让 AI 稳定地操作真实世界应用的挑战。

始于测试的问题

Drizz 的想法源于移动软件开发中一种常见的挫败感。

“我们会快速开发，然后会有两到三天的端到端测试，”Drizz 首席技术官兼联合创始人 Yash Varyani 说。

该公司首席执行官兼联合创始人 Asad Abrar 从业务侧也看到了类似的问题。

两人于 2024 年相识，当时视觉模型开始展现出解读计算机屏幕的能力。Yash 开始尝试这些模型，探索它们能否用于软件测试。

超越基于代码的测试

大多数移动自动化工具依赖应用的底层结构来识别元素。Appium 等工具让测试人员编写脚本，使用内部标识符定位按钮，并执行点击或输入文本等操作。

但软件变化频繁。即使应用功能保持不变，按钮改名或界面重新设计也可能导致现有测试失败。

Yash 表示，对于管理数千个测试用例的公司来说，代码库可能会变得“极其庞大”，导致测试难以维护。

Drizz 采取了不同的方法。

“而我们这边，只是理解屏幕并执行，”Yash 说。

该系统并不完全依赖预定义的元素标识符，而是解读屏幕上可见的内容，并据此采取行动。

当应用不按脚本运行时

以一款外卖应用为例。用户下单时可能会遇到促销优惠、权限请求或其他弹窗。Drizz 希望其 AI 能识别这些干扰，并继续执行预期任务。

“理想情况下，弹窗不应让你的测试用例中断，”Yash 说。“它应该说你的结账功能运行正常。尽管我们在途中看到了三个弹窗。”

当界面元素发生变化时，同样的原则也适用。如果标有“编辑”的按钮被铅笔图标取代，AI 仍应识别该功能并继续执行。

“即使在这种情况下，它也应该能够自愈，”Yash 说。

该公司表示，根据内部基准衡量，它已将测试不稳定率从 15% 至 50% 降至约 3%。不过，它提醒说，结果因客户和用例而异。

“看见”屏幕的局限

Drizz 在 Android 上对 Fathom 进行了测试，涵盖六种前沿模型配置和两种环境下的 20 项任务。Drizz 对每种任务与模型的组合各运行了五次。

在较简单的测试套件中（使用标准 Android 镜像），模型在 300 次计分任务运行中通过了 217 次，通过率为 72.3%。

较难的测试套件使用了已获取 root 权限的 Android 镜像，使评分器能够检查应用的数据库，而不必依赖屏幕上显示的内容。这些任务也被设计得更加困难。在这组单独的任务中，模型在 300 次计分运行中通过了 86 次，通过率为 28.7%。

两个套件使用了不同的任务集和设备镜像。Drizz 表示，第一个套件所用的镜像此后已停用，导致公司无法重新运行该套件。

各模型之间的表现也差异很大，且两个套件之间的排名发生了变化。GPT 5.6 Luna 在较简单的套件中得分为 64%，但在较难的套件中仅为 4%。Gemini 3.5 Flash 在第一个套件中得分最低，为 54%，但在第二个套件中达到 34%，表现优于在那里测试的所有 GPT 配置。

Drizz 提醒不要将这些结果解读为对 AI 能力的决定性衡量。其基准测试衡量的是完整系统，包括模型、Fathom 的智能体脚手架以及特定的 Android 镜像，而非仅衡量模型本身。

关于较难的套件，还有一些未解的问题。其 10 项任务中有 5 项在全部六种模型配置下均得零分。Drizz 表示，它在运行测试前已在设备上验证了每项任务的设置，并不认为测试本身有缺陷导致了这些结果。然而，在没有逐项任务审查的情况下，这些零分仍无法解释。该公司尚未量化它们对整体通过率的影响程度。

这些结果并不能证明 AI 无法测试应用。但它们确实表明，性能在很大程度上可能取决于任务、环境以及用于执行任务的系统。可靠地操作真实应用仍然是一项挑战。

将敏感数据保留在设备上

视觉测试还引发了数据安全问题，尤其是当应用包含个人或财务信息时。

“截图不应离开设备，”Yash 说。

他表示，对于客户部署，Drizz 会在本地部署自有模型，而不是完全依赖在云端运行的大型前沿模型。

Yash 将参数少于 10 亿、能够处理一半或更多工作负载的模型描述为近期里程碑。这样的模型可以减少对更大模型的依赖，不过该公司尚未确定它在生产环境中能处理多少工作负载。

从命令行工具走向更广阔的市场

Drizz 的首款产品是一个命令行工具。该公司表示，它曾与沃尔玛一起对该工具进行试点，允许用户在纯文本文件中编写测试，并在本地模拟器上运行。

该产品目前通过四种途径提供：桌面端、Web 端、持续集成与持续交付（CI/CD）流水线，以及带有模型上下文协议（MCP）接口、用于终端使用和 AI 编码助手的命令行工具。

MCP 接口的工作方式与 Fathom 自有智能体不同。在这种设置中，助手的模型负责推理，并使用 Drizz 的设备工具与手机交互。Fathom 本身则在桌面应用中运行。

Yash 表示，在美国，大多数客户来自开源移动测试工具 Maestro。他预计 Drizz 更多时候会补充 Maestro，而不是取代它。

Yash 说，Maestro 使用基于 YAML 的测试流程、自动等待与重试，以及应用的无障碍树来定位元素。Drizz 的方法解决的是另一个问题：当界面元素或布局发生变化时测试会失效。

其他公司正在开发从产品文档、设计文件或 Jira 工单生成测试的工具。Drizz 认为，生成测试只是问题的一部分。规格说明描述的是产品应该做什么，而不一定是应用在实际中如何表现。仍然依赖元素标识符的测试可能无法改变维护负担。

该公司表示，它可以支持从设计文件生成测试，前提是生成的测试针对渲染后的应用运行，而不是仅依赖设计规格。

验证 AI 智能体可能成为下一个市场

Drizz 已筹集 270 万美元种子资金，拥有约 15 名员工。该公司表示，它在印度拥有 10 多家企业客户和 20 多家中小企业客户。它已获准将 Tata 1mg 列为客户。

随着 AI 智能体开始代表用户与应用交互，Yash 看到了常规软件测试之外的市场。Drizz 最终可能帮助验证这些智能体是否能正确、安全地完成任务。

他相信，这项工作的合同最终可能比公司目前的测试交易大七到十倍。不过，他称这只是方向性估计。Drizz 目前并不销售 AI 智能体验证服务。

目前，这仍是一个潜在市场，而非已确立的收入来源。该公司眼前的挑战是证明视觉 AI 测试能够在真实应用运行的各种条件下提供一致的结果。