干货 | 通过实时调试，让AI编写有效的UI自动化

原创 Thales Fu 携程技术

作者简介

Thales Fu，携程高级研发经理，致力于寻找更好的方法，结合AI和工程来解决现实中的问题。

引言

在快速迭代的软件开发周期中，用户界面（UI）的自动化测试已成为提高效率和确保产品质量的关键。然而，随着应用程序变得日益复杂，传统的UI自动化方法逐渐显露出局限性。AI驱动的UI自动化出现了，但仍面临着准确性和可靠性的挑战。在这个背景下，本文提出一个创新的视角：通过实时调试技术，显著提升AI编写的UI自动化脚本的有效性。

这个问题不仅仅是技术上的挑战，它关系到如何在保证软件质量的同时加速软件的交付。本文将探讨实时调试如何帮助AI更准确地理解和执行UI测试脚本，以及这种方法如何能够为软件开发带来革命性的改变。

一、UI自动化的现状

从最初的记录与回放工具到复杂的脚本编写框架，UI自动化经历了显著的发展。然而，尽管技术进步，传统的UI自动化方法在应对快速变化的应用界面时仍然面临诸多挑战。

手动编写测试脚本不仅效率低下，而且在应用更新时需要大量的重新工作。据行业调查显示，UI自动化测试脚本的维护可能占到整个测试工作的60%至70%。在一个典型的敏捷开发环境中，每次应用更新可能需要超过100小时来重新编写和测试现有的自动化脚本。这种高昂的维护成本凸显了传统UI自动化方法的低效性和资源消耗。

二、行为驱动开发BDD的引入

行为驱动开发（BDD）是一种敏捷软件开发的实践，它鼓励软件项目的开发者、测试人员和非技术利益相关者之间进行更有效的沟通。Cucumber是实现BDD方法论的一个流行工具，它允许团队成员使用自然语言编写明确的、可执行的测试用例。

Cucumber使用一种称为Gherkin的域特定语言（DSL），这种语言是高度可读的，使得非技术背景的人员也能理解测试的内容和目的。测试场景被写成一系列的Given-When-Then语句，描述了在特定条件下系统应该如何响应。

例如，一个在线购物网站的购物车功能可能有如下的Gherkin场景：

这种方法通过使用自然语言描述功能，帮助技术和非技术团队成员之间建立更好的理解和沟通。自然语言的测试场景也充当了项目文档，帮助新团队成员快速理解项目功能。让非技术人员可以直接参与测试用例的编写和验证过程，确保开发工作与业务需求紧密对齐。

但是它也存在着局限性，尽管测试场景用自然语言编写，每个步骤背后的实现（步骤定义）仍然需要技术人员使用编程语言来编写。这意味着实现测试逻辑可能涉及复杂的代码编写工作。随着应用程序的发展和变化，维护和更新与之相对应的测试步骤可能会变得繁琐。特别是在UI频繁更改的情况下，相关的步骤定义也需要相应地进行更新。还有灵活性和适应性限制：Cucumber测试脚本依赖于预定义的步骤和结构，这可能限制测试的灵活性。对于一些复杂的测试场景，实现特定的测试逻辑可能需要创造性地规避框架的限制。

三、当前AI在UI自动化中的应用

近年来，AI技术被集成到UI自动化中，特别是以GPT为代表的大模型出现后，因为它本身就有代码生成能力。业界也开始试着通过大模型来直接把Gherkin的测试用例描述语言生成成测试代码。

不过，当前大模型生成的测试代码并不能完全达到预期，主要有几个问题：首先，生成出来的脚本，因为语法错误可能无法运行；其次，也可能没有准确的覆盖到测试用例需要它去测试的校验点。在我们的实践下，真正能第一次就成功的比例不超过5%。

它生成失败后，接着就需要人介入再进行一些补救的工作。包括：调试，修改用例重新生成，或者直接修改生成的脚本。

而这些工作本身也需要消耗不少的人力，和我们系统通过AI来自动生成测试脚本的初衷相违背。

四、AI全自动的来编写有效的测试脚本

为了解决这个问题，我们重新思考了AI生成测试脚本的整个过程。

我们把人的工作也放在里面一起考虑。人在系统中做了调试和修改的工作，那这部分工作是不是可以让AI来做呢，让系统自己运行生成的代码，让AI来调试和修改自己生成的错误代码。

因此，我们调整了系统设计，让AI代替人自主地来做这些工作。最终，对于携程酒店订单详情页的全部用例，在无人参与的情况下，生成可以执行成功的占全部的83.3%，在生成脚本过程中，有8%的case就已经发现了Bug。我们连续生成这些用例三次，成功率分别在84.3%，81.4%和83.3%，系统是稳定有效的。

具体的测试用例和代码如下：

首先，需要滑动到订单详情页下放的用户权益模块，然后点击订房优化区域，来弹出价格浮层。

然后再看，费用明细里面是否包含黑钻贵宾。

最终生成的测试代码如下：

五、系统实现

整个系统的核心架构示意图如下。系统的核心部分是一个langchain框架的程序。它会去访问大模型，我们给它配备了多个工具，主要分成两类，一类是页面信息的获取工具，一类是调试工具。

Langchain会自动根据需要，使用页面信息获取工具，去拿页面的数据，来判断当前的操作需要具体哪个控件，来生成代码。然后再使用调试工具在手机中真实的执行代码，基于调试的反馈来判断自己生成的代码是否正确。

5.1 提示词

有了基本的架构后，我们需要提示词，来把这些工具粘合起来，让AI理解它该如何工作。我们的提示词从结构上来说包含了几部分内容：首先告诉AI它该如何思考和工作，其次告诉它一定要通过Debug调试它每一句生成的语句，再次告诉它输出格式是什么，最后是告诉AI要处理的完整用例文本。

对于告诉AI它该如何思考和工作，展开包含以下部分：首先看页面有哪些模块，我要操作的这个步骤应该是哪个模块，这个模块里有哪些控件和组件，我当前要操作的是哪个控件或组件，我要操作的动作是什么，以及我可以用的特殊的语法是什么，然后生成语句。

5.2 调试工具

调试工具的本质是通过adb工具远程连接到手机上。连接后，我们就可以把AI生成的指令发送给手机去运行，并且读取到运行后的结果给到AI，让AI去判断自己生成的指令是否正确。

5.3 页面信息获取工具

页面信息获取工具的最终目的是帮助AI判断出，BDD的用例上面写得要操作的内容，它具体要操作的控件的ID是什么，有了ID才能基于ID生成后续的程序指令。而为了拿到ID，我们需要有个控件和组件库，这个库里面的核心是每个控件和组件的ID以及它们的描述。有了这两项内容后，才能帮助AI看了BDD用例后，基于控件的描述去猜需要的是哪个控件。

为了达到这个目的，我们建立了一个页面控件库。这个库除了包含页面上每个控件的ID和描述外，还包含了页面和组件的关系，以及组件和控件的关系。能方便AI一步步的进行查询。