AI驱动操作流程测试：从用户手册到自动化脚本的实践

1. 项目概述：当AI遇见操作流程测试

最近在做一个挺有意思的项目，核心是把那些躺在文档库里的用户手册、操作指南，变成一套能自动运行的测试脚本。听起来是不是有点像“让文档自己动起来”？没错，这就是“AI驱动的操作流程测试”。我们团队手头有大量来自不同产品线的用户手册，从复杂的工业软件（比如FlexSim、STAAD Pro）到消费电子设备（比如各种型号的打印机、路由器），维护和验证这些操作步骤的正确性一直是个体力活，而且容易出错。新版本发布了，手册要更新，对应的功能测试也得重做一遍，费时费力。

这个项目的初衷，就是想用AI技术，特别是当前的大语言模型和智能体（AI Agent）技术，来啃下这块硬骨头。它的核心目标很明确：输入一份自然语言编写的用户手册或操作流程文档，输出一套可执行、可验证的自动化测试用例。这不仅仅是简单的文本解析，它涉及到对操作意图的理解、对上下文环境的判断、对异常情况的处理，以及对测试结果的智能验证。适合谁来关注呢？如果你是测试开发工程师、质量保障负责人，或者任何需要处理大量标准化操作流程验证的团队，比如软件实施、客户支持甚至内部培训部门，这套思路都能给你带来直接的效率提升和可靠性保障。

2. 核心思路与技术选型背后的考量

为什么选择AI来解这个问题？传统的自动化测试，无论是基于UI的Selenium还是基于接口的Postman，都需要测试工程师将操作步骤手动翻译成脚本。这个过程存在几个痛点：一是翻译有歧义，不同工程师对同一段描述可能写出不同的脚本；二是维护成本高，UI一变或者接口一改，脚本就得大面积调整；三是对复杂逻辑和条件分支的处理不够灵活，手册里一句“如果系统报警，则先检查A再操作B”，在脚本里可能就是一堆复杂的if-else和等待条件。

AI驱动的思路，是想让机器自己去“读”懂手册。我们不是要做一个能理解一切文档的通用AI，那是科幻片。我们的目标是做一个垂直领域的、任务明确的智能体。它的输入是特定格式（但允许一定自然语言变化）的操作文档，输出是结构化的测试动作序列。这里的技术选型就非常关键了。

2.1 为什么是“AI驱动”而非“完全AI”

首先得明确，我们追求的是“AI驱动”（AI-Driven），而不是“完全AI”（Fully AI）。完全自动化生成完美无缺的测试脚本，在当前技术下还不现实，尤其是在涉及复杂图形界面识别、非标控件操作时。我们的设计是“人机协同”：AI负责理解、规划和生成测试骨架，甚至是部分脚本代码；测试工程师负责提供领域知识、审核结果、处理AI搞不定的“边角料”以及设置测试环境。这就像让AI当“初级测试开发”，工程师当“技术负责人”进行审核和兜底。

2.2 大模型 vs. 专用规则引擎

面对“理解操作文档”这个任务，我们评估了两条路：一是基于大语言模型（LLM）的语义理解，二是基于传统NLP规则和专用领域语言（DSL）的解析引擎。

• 大模型路线：优点是灵活，能处理自然语言中多样的表达方式、同义词和隐含逻辑。比如，手册里写“点击‘确定’按钮”，它可能知道按钮的文本可能是“OK”、“Confirm”或者是一个对勾图标。Spring AI、LangChain这类框架能很好地帮助我们构建基于提示词（Prompt）的流程解析链。缺点是存在“幻觉”，可能生成不存在的操作步骤；且对上下文窗口依赖大，处理长文档时可能丢失细节；每次调用也有成本。
• 规则引擎路线：优点是精确、可控、速度快。我们可以定义一套严格的语法，比如[动作] [对象] [参数]，然后进行解析。这对于格式非常规范的手册（如某些API文档）很有效。缺点是极其脆弱，手册写法一变，规则就可能失效，扩展性差。

我们的选择是以LLM为核心，以规则和知识库为约束。用LLM做初步的语义理解和步骤拆分，然后通过一套我们预先定义好的“操作原子动作”知识库和业务规则，对LLM的产出进行校验、对齐和结构化。例如，LLM输出“向系统提交数据”，我们的校验层会将其映射到具体的原子操作，如api_call(endpoint=‘/submit’, method=‘POST’, data=…)或ui_input(field=‘data_field’, value=…) ; ui_click(button=‘submit’)。

2.3 工具链的搭建

在具体工具上，我们没有局限于某一个。核心的LLM能力，我们通过API调用主流的大模型服务，同时也部署了部分开源模型以备内网使用。在应用开发层，Spring AI 2.0 提供了一个不错的抽象，能让我们相对方便地切换底层模型提供商。对于前端演示和简单交互，我们也会用一些开源的AI应用框架快速搭建原型。

注意：工具选型上切忌追新。我们早期尝试过一些非常新的AI编程工具（如Cursor、一些AI IDE插件），它们在某些代码生成上很惊艳，但用于构建稳定、可维护的系统框架时，其项目管理和集成度往往不如成熟的IDE（如IntelliJ IDEA、VS Code）加上精心设计的提示词工程来得可靠。最终，我们的主力开发环境仍是传统IDE，AI工具作为辅助。

3. 系统核心模块拆解与实现要点

整个系统可以拆解成几个核心模块，像一个流水线一样工作：文档处理 -> 意图理解与步骤提取 -> 测试脚本生成 -> 执行与适配 -> 结果验证与反馈。

3.1 文档预处理与信息结构化

用户手册格式千奇百怪，有PDF、Word、HTML，甚至图片。第一步是把它变成机器能更好理解的文本。

• 格式转换：使用像Apache PDFBox、python的pdfplumber、docx2txt等工具进行文本提取。对于图片格式的手册，需要OCR识别，这里AI也能帮忙，一些多模态模型（如GPT-4V）或专用OCR服务（如Tesseract结合预训练模型）可以提取文字，但需要后处理来纠正格式错误。
• 关键信息抽取：不是所有文本都是操作步骤。我们需要识别出章节标题、操作序号、前置条件、注意事项、图表标题等。这里我们结合了规则（如正则表达式匹配“步骤1”、“Figure 1”）和LLM（通过提示词让模型识别文档结构）。提取出的信息会存储为一个结构化的JSON或XML，包含章节、步骤列表、每个步骤的描述、可能的截图引用等。

3.2 操作步骤的语义解析与原子化

这是最核心也最挑战的一环。目标是把一段自然语言描述，比如“登录系统后，在‘订单管理’页面，查询状态为‘待处理’的订单，并导出为Excel文件”，解析成一连串原子操作。

• 定义操作原子：我们首先定义了一个有限的“操作原子”集合。这是我们的“测试词汇表”。例如：
  • navigate(url)：导航到页面。
  • ui_input(selector, value)：在输入框输入。
  • ui_click(selector)：点击元素。
  • ui_select(selector, option)：下拉框选择。
  • api_call(method, endpoint, payload)：调用API。
  • wait(condition, timeout)：等待条件。
  • validate(assertion)：进行断言验证。
• LLM的角色：我们给LLM的提示词（Prompt）会包含：当前的结构化文档片段、定义好的操作原子列表及示例、以及当前应用的一些领域知识（例如，我们系统的登录URL通常是什么，某个功能的页面名称是什么）。然后要求LLM将自然语言步骤翻译成原子操作序列。提示词工程在这里至关重要，需要反复迭代优化，以提高准确率。
• 上下文关联处理：手册中经常有“如上所述”、“参见步骤3”这样的指代。我们需要在解析时维护一个上下文记忆，让LLM能理解这些指代。这可以通过在提示词中注入之前的步骤解析结果来实现。

3.3 测试脚本的生成与执行适配

解析出的原子操作序列还不能直接运行，需要转换成特定测试框架的脚本。

• 模板化代码生成：我们为每种操作原子准备了对应不同测试框架（如pytest for Python, Jest for JavaScript, Selenium, Cypress, Postman等）的代码模板。例如，ui_click(selector=‘#submitBtn’)可能被转换成Selenium的driver.find_element(By.CSS_SELECTOR, ‘#submitBtn’).click()。这是一个相对直接的转换过程。
• 选择器（Selector）的智能生成与维护：UI自动化中最头疼的元素定位问题。手册里只会说“点击提交按钮”，但不会给出CSS选择器或XPath。我们采用混合策略：
  1. 知识库匹配：维护一个元素选择器知识库，将常见的页面元素名称（如“提交按钮”、“用户名输入框”）映射到对应的选择器。这需要前期积累。
  2. AI辅助生成：结合页面截图或HTML快照，使用多模态模型或专门训练的模型来预测元素的选择器。例如，给模型一张截图并圈出“提交按钮”，让它生成可能的选择器。这仍在探索中，准确率有待提高。
  3. 模糊匹配与回退：生成的选择器可能失败。我们的执行引擎需要包含重试机制，并尝试备用选择器策略（如通过文本内容查找）。
• 参数化与数据驱动：手册中的操作常常涉及测试数据。我们会从步骤描述中提取出需要参数化的部分（如“输入用户名‘admin’”），并将其转换为脚本中的变量，方便从外部数据源（如CSV文件）读取，实现数据驱动测试。

4. 实操流程：从一份手册到可执行测试用例

让我们用一个简化的例子，走一遍核心流程。假设我们有一份HP C7000刀片服务器机柜的用户手册片段，其中包含一个操作：“通过管理界面，将刀片服务器Blade#3的电源状态设置为‘开启’。”

4.1 预处理与输入原始文档经过OCR和文本提取后，我们得到纯文本：“步骤5：登录到C7000 Onboard Administrator管理界面，在‘设备列表’中找到‘Blade#3’，点击其‘电源管理’选项，在下拉菜单中选择‘开启’。”

4.2 语义解析我们将这段文本和我们的“操作原子”定义一起提交给LLM。提示词大致如下： “你是一个测试自动化专家。请将以下操作描述，分解为一系列原子操作。可用的原子操作有：[列出所有原子操作及示例]。已知信息：C7000 OA管理界面的登录地址通常是 https:// ，登录后默认进入仪表板。” LLM可能返回如下结构化的输出：

{ "steps": [ { "action": "navigate", "params": {"url": "https://<oa-ip>"} }, { "action": "ui_input", "params": {"selector": "knowledge_base:username_field", "value": "${username}"} }, { "action": "ui_input", "params": {"selector": "knowledge_base:password_field", "value": "${password}"} }, { "action": "ui_click", "params": {"selector": "knowledge_base:login_button"} }, { "action": "wait", "params": {"condition": "page_contains", "value": "设备列表", "timeout": 10} }, { "action": "ui_click", "params": {"selector": "text:设备列表"} }, { "action": "ui_click", "params": {"selector": "css:tr[data-blade='3'] .power-management-dropdown"} }, { "action": "ui_click", "params": {"selector": "text:开启"} } ] }

注意，这里的selector字段，knowledge_base:和text:是我们的前缀，用于指示选择器的生成策略。

4.3 脚本生成与适配解析器接收到这个JSON后，会根据目标执行框架（假设是Python + Selenium）进行模板填充。它会查询“知识库”，将knowledge_base:username_field替换为实际的选择器，比如#username。对于text:设备列表，则生成使用Selenium的文本定位方式。最终生成类似下面的Python脚本：

from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def test_power_on_blade3(): driver = webdriver.Chrome() try: # 步骤1: 导航 driver.get("https://<oa-ip>") # 步骤2&3: 登录 driver.find_element(By.ID, "username").send_keys("${username}") driver.find_element(By.ID, "password").send_keys("${password}") driver.find_element(By.ID, "loginBtn").click() # 步骤5: 等待并点击‘设备列表’ WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.LINK_TEXT, "设备列表")) ).click() # 步骤6: 点击Blade#3的电源管理下拉菜单 (这里假设通过属性定位) driver.find_element(By.CSS_SELECTOR, "tr[data-blade='3'] .power-management").click() # 步骤7: 点击‘开启’ driver.find_element(By.XPATH, "//*[text()='开启']").click() # 可以添加验证步骤，如检查状态是否变为‘已开启’ # ... finally: driver.quit()

4.4 执行与结果验证生成的脚本会被放入测试执行队列。执行引擎（如Jenkins、GitLab CI）会运行它，并注入实际的参数（如OA的IP地址、登录凭证）。执行完成后，需要验证操作是否成功。验证方式可以是：

• 断言页面元素：检查页面上是否出现“操作成功”的提示，或者Blade#3的状态图标是否变为“开启”状态。
• 调用API验证：如果管理界面有后端API，可以直接调用查询接口，验证电源状态是否已改变。
• 截图对比：在操作前后截图，进行差异比较（这种方法较粗糙，通常作为辅助）。

实操心得：在解析步骤时，一定要让LLM输出明确的验证点。我们在提示词中强制要求，每个关键操作步骤后，都应跟随一个validate原子操作。即使手册里没写，AI也可以基于常识建议一个验证点（比如，点击登录后，应该验证是否跳转到主页）。这能极大提升生成测试用例的健壮性。

5. 面临的挑战与针对性解决方案

在实际推进中，我们遇到了不少坑，也总结出一些应对策略。

5.1 文档质量的参差不齐这是最大的挑战。理想的手册结构清晰、用语规范。但现实中，很多手册步骤模糊、截图过时、甚至存在错误。

• 解决方案：建立“文档质量评分”机制。在预处理阶段，就用规则和轻量级模型对文档进行打分，例如：步骤是否有编号、描述是否包含明确的操作对象和动作、是否有配套截图等。对于低分文档，系统会标记出来，建议人工优先审核或介入补充信息，而不是盲目尝试自动化。

5.2 AI“幻觉”与错误解析LLM可能会“发明”不存在的步骤或误解操作对象。

• 解决方案：采用“分步确认”和“知识库约束”策略。不要一次性让LLM解析整个长流程。而是先让它拆分出高级步骤，然后对每个步骤逐一进行详细解析。同时，将公司内部的系统术语、页面对象名称、API清单作为强知识库提供给LLM，限制其生成范围。对于关键操作（如删除、重启），生成的脚本必须经过人工审核才能加入自动化测试集。

5.3 动态UI与元素定位失效这是UI自动化的经典难题。页面结构一变，选择器就失效。

• 解决方案：除了前面提到的多策略选择器，我们更推崇“从UI自动化向API自动化倾斜”。很多后台操作，最终都是通过调用一系列API完成的。如果手册描述的操作有对应的后端API，我们优先让AI生成API测试脚本（使用Postman集合或pytest-requests）。这比UI自动化稳定得多。我们的系统会尝试将操作描述映射到已知的API清单上。

5.4 测试环境的准备与清理手册中的操作通常假设系统处于某个初始状态。自动化测试需要可重复的环境。

• 解决方案：在生成的测试脚本前后，自动添加环境准备（Setup）和清理（Teardown）步骤。这可以通过分析操作步骤的上下文来实现。例如，如果测试流程是“创建订单->审核订单”，那么AI在生成“审核订单”的测试时，应该能识别出其前置条件是“存在一个待审核的订单”，从而自动生成或关联一个“创建订单”的准备工作。这需要构建一个简单的领域模型来描述业务对象的状态生命周期。

5.5 处理条件逻辑和异常流程手册中常有“如果…则…”，“否则…”，“当报警出现时…”等描述。

• 解决方案：我们在操作原子的定义中加入了branch和try_catch这样的控制流原子。在解析时，LLM需要识别出条件语句，并将其转化为测试脚本中的条件判断和异常处理块。同时，我们会构建一些常见的异常场景知识库（如“登录失败”、“网络超时”），让AI在生成测试时，能顺便生成一些对应的异常处理或验证逻辑。

6. 效果评估与未来演进方向

目前，这个系统在我们内部几个产品线的文档测试上进行了试点。对于格式规范、描述清晰的操作手册，步骤解析的准确率能达到85%以上，生成的脚本经过少量人工修正即可运行。对于复杂的、涉及图形交互或专业硬件的流程，准确率会下降，但依然能极大地减少测试脚本的编写工作量，大约能提升60%的用例编写效率。

6.1 关键收益

1. 一致性：AI解析避免了人为理解偏差，保证了测试用例与文档描述的一致性。
2. 可维护性：当手册更新时，只需重新解析新版手册，即可快速生成新的测试脚本骨架，维护成本显著降低。
3. 覆盖度：可以快速地对所有历史手册进行“回归测试”，确保文档描述的功能在最新版本中依然有效，这是人工难以全面覆盖的。
4. 知识沉淀：过程中构建的“操作原子库”和“元素选择器知识库”，本身就成了团队宝贵的测试资产。

6.2 遇到的典型问题与排查表

6.3 未来的思考这个项目远未结束。我们正在探索几个方向：

• 多模态深度集成：不仅仅是OCR识别文字，而是让AI直接“看”操作视频或交互式演示（如操作录屏），从中学习操作流程并生成测试脚本。这需要更强的视频理解和动作序列识别能力。
• 自我进化与闭环：让测试执行的结果反馈给解析模型。如果某个步骤生成的脚本总是失败，系统可以自动标记，并尝试用不同的方式重新解析，或者提示人工介入，形成“执行-反馈-优化”的闭环。
• 从验证到生成：未来，也许这个系统不仅能验证已有手册，还能在软件界面更新后，自动对比新旧版本的差异，并建议更新用户手册中的操作步骤和截图，实现文档的协同维护。

AI驱动的操作流程测试，本质上是将人类的知识（手册）和意图（测试）进行标准化、结构化的翻译。它不会取代测试工程师，而是将他们从重复、繁琐的翻译工作中解放出来，去从事更富创造性的测试设计、探索性测试和复杂场景构建。这个过程里，最大的挑战不是技术，而是如何设计好人与AI协同工作的流程，让AI成为得力的助手，而不是一个需要时刻盯防的“黑盒”。