1. 项目概述AITS是什么以及它想解决什么问题最近在测试圈子里AITSAI-driven Test System这个名词开始频繁出现尤其是在一些前沿的课程和分享里。乍一看它像是一个被AI包装过的自动化测试工具但如果你真这么想可能就低估了它背后试图掀起的变革。我花了些时间结合一些公开的课程资料和社区讨论深入拆解了一下AITS的架构和思路。简单来说AITS不是一个简单的“脚本生成器”它的野心在于重构测试工程师的工作范式——从“写脚本的执行者”转向“设计规则和验证逻辑的架构师”。传统的自动化测试无论是UI还是接口核心痛点在于“创建”和“维护”。写一个脚本需要熟悉编程语言、测试框架、元素定位业务一变动脚本就得跟着改维护成本高企。AITS瞄准的就是这个痛点它试图用大模型LLM的自然语言理解能力让测试人员用“说人话”的方式描述测试场景然后由系统自动将其转化为可执行的测试用例。这听起来很美好但实现路径远比喊口号复杂。它的核心价值并非仅仅是“生成代码”而是构建一个能够理解业务、沉淀知识、并实现人机高效协同的智能测试中枢。对于测试团队而言这意味着效率的质变和角色的升级对于整个研发流程则可能意味着测试左移和右移的边界被进一步模糊测试活动更早、更智能地融入开发周期。2. 核心架构拆解AITS的四大支柱一个能落地的AITS平台绝不是一个大模型接口调用那么简单。它需要一套精密的系统工程来支撑。根据我的分析其稳固性依赖于四个相互咬合的支柱高质量的知识库、智能的用例生成引擎、稳定可靠的执行器以及至关重要的人机协同闭环。缺少任何一环整个系统都可能沦为华而不实的演示玩具。2.1 基石向量知识库——系统的“长期记忆”这是整个AITS平台的基石也是决定其智能上限的关键。你可以把它想象成测试领域的“谷歌”但存储的不是网页而是结构化的测试知识。大模型本身是“通才”缺乏对特定业务系统的深度了解。向量知识库的作用就是通过检索增强生成RAG技术为模型提供精准的、上下文相关的业务知识使其输出更准确、更专业。这个知识库需要系统性地整合多维度信息业务逻辑与流程这是最高层的知识。需要将用户故事、产品需求文档、甚至会议纪要中关于“谁在什么情况下做什么得到什么结果”的描述转化为结构化的业务流程节点图。例如“用户登录 - 浏览商品列表 - 选择商品加入购物车 - 进入结算页 - 支付成功”这个链条需要被清晰地定义和存储。UI自动化元数据这是让“自然语言操作页面”成为可能的关键。它需要包含页面对象模型每个页面的标准URL、页面名称、关键状态。元素定位策略页面上每个可操作元素按钮、输入框、链接的多种定位方式如XPath、CSS Selector、ID。这里不能只存一种因为前端框架变更可能导致某种定位方式失效。更重要的是需要存储元素的语义描述比如一个按钮除了ID是“submit-btn”它的文本可能是“提交订单”它的邻近文本可能是“请确认订单信息后提交”。这些自然语言描述正是大模型理解“点击‘提交订单’按钮”指令的桥梁。交互依赖例如某个下拉框的选项依赖于前一个输入框的值。这类逻辑关系如果被编码进知识库能极大提升生成用例的合理性。接口自动化规范这部分相对成熟主要是集成来自Swagger、OpenAPI、YApi等工具的接口文档。但AITS的知识库需要更进一步不仅存储接口的路径、方法、参数还要理解参数之间的约束关系、接口调用的前置条件例如调用下单接口必须先有有效的用户token和商品ID以及接口返回数据的结构用于后续的断言校验。历史测试资产将已有的自动化测试脚本Selenium、Pytest、Postman集合等进行解析和向量化存储作为高质量的正样本供模型学习“好的测试用例长什么样”。流量回放数据进阶通过代理或日志收集生产或测试环境的真实用户操作序列和接口调用链。这些数据是构建复杂业务场景编排的黄金素材能发现人工难以覆盖的异常路径和参数组合。注意构建知识库最大的坑在于“知识污染”和“更新滞后”。如果导入过时或错误的页面定位信息生成的用例会从一开始就失败。因此必须建立知识库的版本管理和定期巡检机制最好能与CI/CD流水线集成在每次前端部署后自动触发相关页面的元素信息更新扫描。2.2 引擎智能用例生成——从“描述”到“可执行代码”有了知识库下一步就是让大模型扮演“测试开发工程师”的角色。这个过程不是一步到位的魔法而是一个分步解析和组装的过程。自然语言意图解析用户输入“测试用户登录后将第一个商品加入购物车”。模型首先需要理解这个指令的意图这是一个涉及“登录”和“加购”两个动作的业务流程测试。知识检索与上下文构建模型根据解析出的意图登录、加购从向量知识库中检索相关的知识片段。例如检索出“登录页面的URL”、“用户名输入框的定位”、“密码输入框的定位”、“登录按钮的定位”、“商品列表页的URL”、“第一个商品卡片的定位”、“加入购物车按钮的定位”等。同时也会检索出“登录接口的调用方式”、“登录成功后返回的token如何传递”等接口知识。测试步骤生成与代码转换模型结合检索到的上下文生成具体的、顺序化的测试步骤。例如步骤1 导航至登录页https://example.com/login步骤2 在元素#username中输入test_user步骤3 在元素#password中输入password123步骤4 点击元素//button[text()登录]步骤5 验证是否跳转至首页https://example.com/home步骤6 导航至商品列表页https://example.com/products步骤7 定位第一个商品元素.product-item:first-child步骤8 点击该商品元素内的.add-to-cart按钮步骤9 验证购物车图标数量变为1断言Assertion智能生成这是体现测试思维的关键。模型需要根据步骤和业务常识自动添加验证点。比如在登录后除了验证页面跳转可能还需要验证页面某个区域显示了用户名“test_user”在加入购物车后除了验证数量可能还需要调用购物车接口验证商品ID是否正确加入。好的断言策略需要模型理解“什么是成功的状态”。这个过程中平台可能会采用MCPModel Context Protocol或类似架构让大模型能够“调用工具”。例如模型在生成“点击登录按钮”步骤时实际上是调用了一个预定义的“click_element”函数并传入了从知识库查到的定位器。这使得生成的输出不再是模糊的自然语言而是结构化的、可被后续引擎解析的中间表示如JSON最终再转换为Python配合Selenium/Playwright或JavaScript等具体的可执行脚本。2.3 执行与稳定性保障让“智能”可靠落地生成用例只是第一步能稳定执行才是价值所在。UI自动化 notoriously臭名昭著地脆弱AITS在这方面需要做大量加固工作。双重定位策略这是对抗前端变化的核心手段。系统生成的脚本不应只依赖模型解析出的单一定位如“包含‘提交’文本的按钮”。在执行时驱动引擎应同时携带从知识库中获取的该元素的多个备选精准定位器如ID、CSS Selector、XPath。执行时采用“降级策略”优先使用最稳定的定位方式如唯一的ID如果失败则依次尝试其他备选方式。这相当于为每个元素上了一道保险。智能等待与重试机制传统的time.sleep是糟糕的实践。AITS生成的脚本应内置智能等待逻辑例如在点击按钮前显式等待该按钮变为可点击状态clickable在输入前等待输入框可见。对于网络请求或页面加载可以设置动态超时和自动重试。这部分逻辑可以由框架层统一封装无需模型每次生成。执行环境隔离与数据管理每个自动化用例应在干净、一致的环境中执行避免测试数据相互污染。AITS平台需要集成测试数据工厂的能力能够按需生成或清理测试账号、测试商品等数据。模型在生成用例时可以调用这些数据服务来获取合适的参数。结果收集与可视化执行过程需要详细记录每个步骤的截图、网络请求日志、控制台错误。当用例失败时这些信息是后续分析和修复无论是修复脚本还是补充知识库的关键证据。平台需要提供清晰的报告指出失败是在哪一步可能的原因是什么元素未找到、断言失败、超时等。2.4 闭环人机协同与持续进化——从Demo到生产这是决定AITS能否在真实团队中活下去的灵魂。完全依赖AI生成在当前技术阶段风险极高。必须设计流畅的人机协同流程。人工审核与精修系统生成的用例必须经过测试工程师的审核。这个界面不是展示代码而应该是一个可视化的、可交互的用例编辑器。测试工程师可以修正错误定位如果系统为“提交订单”按钮找到了错误的元素工程师可以从知识库中选择正确的定位或直接录制新的定位方式系统会自动更新知识库。补充边界和异常场景AI通常基于“快乐路径”生成用例。工程师需要手动添加“密码错误时登录失败”、“库存不足时无法加购”等边界用例。平台可以提供模板或引导“您是否需要添加反向测试用例”来辅助这个过程。优化测试数据将AI生成的通用测试数据如user123替换为更符合业务规则的数据如符合邮箱格式的测试账号。调整断言逻辑增强或简化AI生成的断言确保其准确且不过于脆弱。反馈学习循环人工修改的行为应该被系统记录和学习。例如如果一个元素的定位被多次手动修正系统应该提示“该元素定位信息可能已过期建议更新知识库”。如果工程师频繁为某个场景添加同类型的边界用例系统可以学习这种模式在未来生成类似场景时主动建议添加。知识库的持续运营AITS不是一个“部署即结束”的项目而是一个需要持续“喂养”和“调教”的系统。需要设立规则每次前端发布自动触发UI扫描更新元素定位知识库。每次接口文档变更自动同步到接口规范知识库。将稳定运行的测试用例集定期反哺到知识库中作为高质量样本。建立测试用例的“健康度”看板标记那些因环境或知识陈旧导致频繁失败的“不稳定用例”优先安排人工巡检和知识更新。3. 核心场景实现剖析UI与接口自动化如何智能化理解了整体架构我们再深入到两个最核心的应用场景看看AITS具体如何施展拳脚。3.1 UI自动化自然语言驱动的革命传统UI自动化脚本充斥着driver.find_element(By.ID, “kw”).send_keys(“Selenium”)这样的代码编写和维护都需要一定的编程能力。AITS的目标是将其变成“搜索‘Selenium’并点击第一个结果”。实现路径示例用户输入 “在百度首页搜索‘AITS自动化测试’并点击第一个搜索结果。”平台解析与规划意图识别识别出两个核心操作“输入文本”和“点击”。场景分解分解为子任务a. 打开百度首页b. 定位搜索框c. 输入关键词d. 触发搜索e. 定位结果列表的第一个链接f. 点击。知识检索从知识库查找“百度首页”的URLhttps://www.baidu.com“百度搜索框”的多种定位方式如#kw,name‘wd’“百度一下按钮”的定位“搜索结果列表项”的通用选择器如.result .t a。代码生成与执行平台将上述规划结合检索到的具体定位信息生成如下的可执行结构以Playwright为例的伪代码表示# 步骤1: 导航 page.goto(‘https://www.baidu.com’) # 步骤2: 输入 - 使用知识库中优先级最高的定位器 search_box page.locator(‘#kw’).first # 备选: page.locator(‘[name“wd”]’) search_box.fill(‘AITS自动化测试’) # 步骤3: 点击搜索按钮 search_button page.locator(‘#su’) search_button.click() # 步骤4: 等待结果并点击第一个 page.wait_for_selector(‘.result .t a’) first_result page.locator(‘.result .t a’).first first_result.click()稳定性加固在实际执行page.locator(‘.result .t a’).first之前执行器会检查知识库中是否有关于“百度搜索结果第一个链接”的更稳定定位方式例如通过数据属性>
