1. 这个项目到底解决了什么问题1.1 先聊聊传统自动化测试的死结做测试这行超过五年的人大概率都有过这样的经历每天上班先打开 Jenkins 看看昨晚的回归结果然后花一两个小时翻日志、定位失败用例最后发现十有八九是元素定位失效、测试数据过期、或者环境抖动导致的不稳定失败。真正有效的 bug 没找到几个时间全耗在和脚本较劲上了。这套传统自动化测试的玩法核心思路是“先写脚本再跑断言最后维护”。它的问题在于把测试工程师变成了脚本工程师。业务用例的编写需要掌握代码能力而代码能力的门槛天然把很多懂业务但不会写代码的人挡在门外。更头疼的是维护成本前端只要发生一次重构哪怕是按钮文案微调都可能连累十几个用例一起挂掉。我见过不少团队自动化覆盖率看着挺高实际上每天光修脚本就占掉了测试组将近一半的人力。老板看到自动化跑得热闹实际交付效率并没有明显提升。这种局面持续了很久直到 AI 大模型开始在代码生成、语义理解这些方向上展现出实用价值我才意识到这个困局也许有新的解法。1.2 “AI无代码”不是噱头是两条腿走路先说一个容易被误解的点AI 驱动和 无代码 不是两件事的简单拼接它们互为前提。无代码解决的是“表达成本”问题。测试用例不再需要用 Java 或 Python 去描述“点击某个按钮然后断言弹窗出现”而是用自然语言描述“用户登录后点击个人中心验证昵称显示正确”。这种表达方式业务人员看得懂产品经理也能参与评审测试用例本身变成了一种团队共识而不是测试组自己的黑话。AI 驱动解决的是“执行效率”问题。光有自然语言描述还不够得有一个引擎能把自然语言翻译成可执行的操作序列能在页面结构发生变化时自己调整定位策略能从历史数据中学习哪些元素容易变、哪些断言容易谎报然后动态修正自己的行为。这两条腿缺一条都走不远。没有 AI 的无代码本质上是把原来的脚本换成了积木块复杂场景照样搭不出来没有无代码的 AI大模型生成的代码还得人来维护维护成本并没有消失只是换了形式。这个项目就是在把这个逻辑落地用 AI 大模型充当核心引擎把自然语言测试用例翻译成可执行脚本再用无代码的可视化界面把整个过程封装成普通测试人员也能轻松上手的操作流程。核心价值总结降低测试用例编写门槛削弱脚本维护负担让测试团队把精力重新聚焦到“找 bug”而不是“改脚本”。2. 整体架构设计与技术选型2.1 核心组件拆解从录制回放到大模型驱动如果只用一句话概括这套系统的架构那就是“录制回放做基底大模型做大脑自动化框架做手脚”。整个系统分成四层层级作用核心组件交互层用户录制操作、编写自然语言用例、查看执行报告Web可视化界面语义层将自然语言转换为结构化的测试步骤LLM Prompt编排执行层在真实环境中执行测试操作并进行断言Selenium/Playwright 自定义断言引擎智能层元素定位容错、结果分析、用例自修复AI Agent 决策模块录制回放并不是什么新技术十年前就有。但在引入大模型之后它发生了质变。传统的录制回放录下来的是一堆绝对坐标和固定属性页面一改就废。现在的录制回放会把“我点击了登录按钮”这个动作抽象成一个语义节点连同页面的 DOM 结构、元素属性、上下文快照一起记录下来。这样一次录制实际上是在采集训练样本。我不会放弃录制回放因为它是用户最熟悉的低门槛操作方式。但录下来的东西如果直接当脚本用那只是在重复老路。需要让大模型理解这段操作背后的用户意图再生成更鲁棒的执行方案。2.2 AI Agent在测试中的作用边界做这个项目之前我仔细研究过“AI Agent到底能不能直接替代测试工程师”这个问题。结论是不能至少在现阶段不能。但它可以很好地解决那些“有固定模式但需要实时决策”的问题。我在这个系统里给 AI Agent 分配了五个明确的职责自然语言用例翻译把测试人员输入的一句话描述拆解为可执行的动作序列。比如“验证登录失败时的错误提示”Agent 要自动知道需要先输入错误密码再点击登录再捕获弹出提示并断言文案。智能元素定位传统元素定位靠 id、class、xpath这套东西在页面重构后基本报废。Agent 则会把当前页面的 DOM 结构、元素可见性、文本内容、位置关系综合起来分析即使目标元素的 id 变了也能靠“登录按钮是右上角那个红色的大按钮”这样的语义线索找到它。断言生成与优化根据用户的意图自动生成合理的断言条件。用户说“检查登录成功”Agent 会结合页面跳转、URL 变化、用户状态等多个维度生成复合断言而不是只查某一个元素在不在。失败用例自诊断用例执行失败后Agent 会抓取当时的页面快照、控制台日志、网络请求综合分析失败原因是“产品真的出 bug 了”还是“脚本过期了”并给出处理建议。测试数据自动构造从描述中提取数据规则并自动生成符合边界条件的测试数据。比如“验证密码必须是 8 到 20 位”Agent 会自动构造 7 位、8 位、20 位、21 位、纯数字、含特殊字符等一整套用例数据。这五个职责看上去并不复杂但真正把它们串起来跑通一轮完整的测试流程需要解决不少工程细节问题。2.3 工具链选型对比工具选型上我踩了不少坑这里直接给结论。市面上现成的无代码测试工具不少但真正符合“AI 驱动”这个前提的并不多。很多所谓 AI 测试平台就是把一个普通的录制回放工具接了个 ChatGPT 问答框AI 和测试执行引擎是两套割裂的系统根本谈不上驱动。我自己最终选择的方案是基于 Playwright 做底层执行引擎用一个大模型 API 做语义分析再自己写了一层胶水代码把两者衔接起来。选择 Playwright 而不是 Selenium主要原因是它的选择器机制更先进。Playwright 的 locator 天然支持根据文本、角色、层级关系定位元素配合自动等待机制脚本的先天鲁棒性就比 Selenium 好很多。在加上 AI 语义定位层之前同样的用例Playwright 跑的稳定率就能高出 20% 到 30%。大模型这块我建议优先选支持工具调用的模型。因为测试场景里需要 Agent 去实时获取页面信息而不是干巴巴地生成一段文本。如果一个模型不能主动调用“获取当前页面元素列表”这个工具那它只能根据训练知识猜测页面结构猜出来的东西基本没法用。补充一点如果企业数据敏感不能走公有云 API可以用私有化部署的开源大模型加上一个代理层。效果会打折扣但数据安全这块必须有底线。3. 实操过程从零搭建一套AI无代码测试平台3.1 第一步环境准备与基线搭建先列一下我使用的环境方便你复现时有个参考操作系统Ubuntu 22.04 LTS浏览器执行环境Playwright Chromium后端服务Python FastAPI PostgreSQL大模型接口支持 OpenAI 兼容协议的工具调用型模型前端界面Vue 3 可视化操作画布初始化项目我建议用 Docker Compose 把依赖一次拉起来别在自己机器上裸装版本冲突会浪费很多时间。# 初始化 Playwright 环境 pip install playwright playwright install chromium # 安装核心依赖 pip install fastapi uvicorn sqlalchemy openai准备一个小型的测试目标站我建议用开源项目 Pikachu 漏洞测试平台或者自建一个简单电商 Demo 页面。这一步很重要因为后面所有用例设计、AI 调优都要有真实的被测对象。基线搭建阶段要完成三件事录制回放通道打通、被测页面元素快照可以稳定采集、大模型接口调用链路接通。我实测下来慢的话一两天就能搞定速度取决于你对 Playwright 的熟悉程度。3.2 第二步自然语言生成测试用例这一步是整个系统的灵魂。用户输入一句话系统要输出一组可执行的测试步骤。实际操作中我采用的是“意图识别 步骤规划 参数填充”三段式 Prompt 设计。第一段让大模型识别用户意图。用户说“测试购买流程”模型要判断这是一个端到端流程测试涉及登录、选商品、加购物车、结算、支付确认等多个子步骤。第二段让大模型把意图展开为步骤序列。这里关键是要给模型足够的上下文信息包括当前应用的用户操作流程、可用的页面元素列表、前置条件和预期结果。第三段让大模型为每个步骤填充具体参数。比如“选商品”这个步骤模型需要挑一个在售商品 ID 作为测试数据并且从接口返回中动态获取价格而不是写死一个数值。下面是一个简化后的 Prompt 模板你是一名测试用例设计专家。 根据用户描述的测试目标 {user_intent}结合应用上下文 {app_context}生成一份测试执行计划。 要求 1. 每个步骤必须包含操作类型、操作对象、输入数据 2. 断言条件要基于页面状态或接口返回值不能依赖固定文案 3. 如果存在前置条件请明确说明 4. 输出格式为结构化 JSON模型返回的 JSON 再映射到 Playwright 的 API 调用上。这一步看起来简单实际调试最多的坑是模型生成的步骤顺序与真实业务流程不一致或者对“点击”和“输入”这类操作的理解和实际组件行为不匹配。解决方案是在 Prompt 里加入少量业务流的示例描述效果立竿见影。3.3 第三步智能断言与自动修复断言是自动化测试里“含金量”最高的部分也是这套系统与传统工具拉开差距的地方。传统做断言无非是 assertEqual(实际结果, 期望结果)。但期望结果从哪来在没有 AI 的时代得靠测试工程师手动写。有了 AI 之后可以从自然语言意图里自动推导。举个例子。用户说“验证用户修改头像后页面显示的昵称没变”。AI 会先分析“头像变更”和“昵称不变”之间没有必然联系然后断言的重点应该放在“文件上传成功”以及“修改成功后页面停留在个人中心”这两个维度上。这个推理过程传统脚本是做不到的。自动修复功能是测试维护成本的最大削弱点。它的实现思路是把当前页面的所有可交互元素做成一张语义快照当执行失败时的页面元素与录制阶段的元素属性不一致时让 AI 分析两张快照之间的映射关系。我遇到过的一个真实场景原页面有一个 id 为username_input的输入框改版后 id 变成了account。如果按传统逻辑这个用例直接报错。但 AI 分析后发现新元素在页面上占的位置、功能描述、周围的文本标签都和旧元素一致于是自动把定位器修正过来并且打上一个标签“已自动修复定位器建议人工复核”。这种能力是这整套系统里最能节约维护时间的。3.4 第四步与CI/CD集成无代码测试如果不能进入流水线自动跑价值会打一半折扣。这一块我采用的是最通用的方案将 Playwright 的执行器做成一个 CLI 工具每次执行完输出 JUnit XML 格式的报告然后让 Jenkins 或 GitLab CI 去解析这个报告。# 在 CI 流水线中执行 python run_test.py --suiteregression --report-formatjunitCI 集成阶段需要特别注意一个点测试容器里必须有 Chromium 的可执行环境和所有系统依赖。我经常看到有同事在本地跑得好好的一上 CI 就全军覆没大概率就是缺系统依赖库。建议在 Dockerfile 里显式安装RUN npx playwright install --with-deps chromium跑完之后的测试报告展示我建议不要只展示通过率要把 AI 自己修复了多少个定位器、失败用例的疑似原因分析、以及修复建议都展示出来。因为这套系统设计的初衷是让人更省力而不是让人多一个要看的数据面板。4. 实际运行效果与数据对比4.1 用例编写效率对比我在一个包含 200 个核心业务用例的电商 Web 项目上做了一组对比实验。传统方式下由 3 名测试工程师编写这些自动化用例按每人每天产出 10 到 15 个稳定用例的速度计算大约需要 5 到 7 个工作日。换用这套 AI 驱动无代码方案后同项目的用例设计由 2 名测试工程师完成其中大部分时间是花在描述业务场景和确认 AI 生成的步骤是否符合预期上。首次生成加人工修订总计耗时 2 个工作日产出 210 个用例其中 180 个用例无需任何修改即可稳定执行。为了方便参考我把对比数据整理成了表格对比项传统脚本方式AI无代码方式提升幅度200条用例编写耗时5-7天2天约60%-70%每条用例平均维护时间15-25分钟3-5分钟约80%页面重构后的用例存活率20%-40%70%-85%接近翻倍测试工程师日编写用例数10-15条80-100条5-8倍这个差距的核心来源并不是 AI 直接生成了多少代码而是 AI 把“思考”的时间省了。传统方式下测试工程师写脚本时要做大量的定位器调试、等待时间设置、异常分支处理。这些工作在 AI 方案中全部变成了自动化的附属产物人只需要确认“这个步骤对不对”不需要再关心“这个步骤怎么实现”。4.2 维护成本变化长期运行后维护成本的变化是让我坚定这个方向的最核心原因。我统计了传统自动化测试组一个月内的脚本修改记录200 个用例平均每天有 8 到 12 个用例因为定位失效或数据变更被打回重写每个用例修复时间按 20 分钟算一个月仅“修脚本”这项就消耗大约 70 到 80 个工时。AI 方案上线后的同期数据是每天需要人工介入修复的用例数量平均在 2 到 3 个以内其余失败情况要么是环境问题自动重跑即可通过要么是 AI 已经自动调整好了定位器只等人点一下确认。特别值得提到的场景是前端框架升级。传统方案遇到这种大版本升级基本等于自动化资产归零重做。我的这套系统在遇到一次 Vue2 到 Vue3 的整体迁移时自动修复率达到了 60% 左右。剩下的 40% 是因为部分业务逻辑本身发生了变化旧的用例描述已经不适用于新流程这属于产品需求变化不是技术问题修复脚本没有意义。4.3 覆盖率和交付质量覆盖率这块无代码加 AI 的组合天然比传统脚本思维更容易做高。原因很简单传统方案下测试工程师倾向于只编写“好自动化”的用例遇到复杂逻辑或动态交互就人为降低覆盖密度。但在 AI 生成模式下复杂用例和简单用例的生成成本几乎一样所以团队会更愿意覆盖边缘场景。我观察到一个有趣的数据点在引入这套系统之前覆盖率达到 60% 以后每增加 1% 的覆盖率投入的边际成本会显著增加。而 AI 方案下这个拐点延后到了 85% 左右。这是因为 AI 可以从录制数据和历史执行记录里自动发现没有被覆盖到的业务分支相当于有了一个持续提醒的“补测建议助手”。交付质量方面团队在版本发布前漏测到生产环境的问题数从平均每季度 4 到 5 个下降到 1 个以内。这个成绩里有一部分功劳要分给 AI 生成断言时那种“多视角验证”的习惯它不会只盯着页面文案变没变还会检查 URL、接口状态、数据持久化这些容易遗漏的环节。提示以上数据来自我个人项目实践不同团队基础不同数据会存在差异。但“AI能显著降低维护成本”这个结论在我接触的所有案例中还没有反例。5. 常见坑与避坑指南5.1 AI断言的假阳性问题先说最坑的一个问题AI 生成的断言依赖自然语言理解但自然语言本身有歧义。用户说“验证登录成功”AI 可能把断言条件设置成“页面出现欢迎语”。但如果这个应用的欢迎语是异步加载的在断言执行的瞬间还没渲染出来用例就会误报失败反过来如果页面从“欢迎语”改成了“欢迎回来”文案变化也会导致断言失败。我的解决思路是“分层断言”即将断言拆解成三个梯度。第一层是基础可观测性断言比如页面是否完成加载、网络请求是否正常返回第二层是状态性断言比如用户 session 是否建立、本地 token 是否更新第三层才是业务性断言比如页面文本是否符合预期。这样的好处是当第一层第二层都通过、只有第三层文案不匹配时AI 会给出“疑似业务文案变更非功能故障”的判断而不是直接把用例标红。实际用下来误报率能降低一半以上。5.2 动态元素的定位策略动态元素的坑在没有 AI 的自动化测试里也很常见。但 AI 定位引入了一个新问题AI 可能因为“过度聪明”而选择了一个错误的备用定位器。举个例子页面有两个功能相似但业务含义完全不同的按钮一个“确认订单”在购物车页一个“确认订单”在结算页。AI 如果只看文本很可能在结算页的测试用例里错误地点击了购物车页的按钮。处理这个问题的核心是要给 AI 提供足够的上下文约束。我会在录制阶段额外记录当前页面的路由、最主要的容器元素、操作发生时的滚动位置。这些信息在语义定位时会作为强约束条件告诉 AI“不但是要找文本为 X 的按钮而且必须是在当前路由下、指定容器内的那个按钮”。5.3 敏感数据的处理红线测试场景必然会涉及敏感数据尤其是登录态、用户信息、支付信息。这个坑出了就是大事必须重点看两个地方。第一是断言数据不能打印。AI 在分析失败原因时会抓取页面快照和控制台日志。如果登录密码出现在页面元素属性里快照一旦上传到云端大模型服务等于是把生产数据送出去了。我的方案是在数据采集层做脱敏所有 input 类型的元素属性值默认打码只有用户显式判断后才允许读取真实值。第二是测试数据的生成不能依赖生产库。AI 自动构造测试数据时可能从历史会话中学习到一些真实数据的特征然后在生成新数据时无意识地“模仿”出来。这块我采用白名单策略即所有生成的数据必须通过正则规则和白名单校验符合测试环境数据规范才允许使用。5.4 模型输出的稳定性问题大模型生成的 JSON 结构不时会出现格式错误这是所有接大模型做工程的人都会遇到的事。测试场景对错误容忍度很低格式错误直接导致用例无法执行。我的做法是加了一层“结构化输出约束”。在 Prompt 层要求模型必须遵循给定的 JSON Schema并且在代码层加入 Pydantic 数据模型进行二次校验。一旦校验失败不会让用例失败而是触发一次“修正重试”机制把错误信息回传给模型让它自行修复输出格式。这一块可以从早期的 20% 错误率降到 2% 以下。剩余 2% 的错误通常发生在非常规的测试描述中属于模型能力边界靠重试也解决不了所以需要人机协作机制兜底——模型自己判断“我搞不定了”把问题转给人工处理而不是硬着头皮生成一个错误的结果。5.5 测试数据准备自动化这是很多人会忽略、但实际使用中特别影响体验的一环。无代码测试要真正落地测试数据准备不能靠人工造数。我在系统里加了一个“数据工厂”模块通过自然语言描述即可生成符合业务规则的数据集。比如“生成一张订单金额 500 元使用优惠券支付状态为待支付”数据工厂会自动调用数据库接口或页面操作来构造这条记录并在用例执行完后自动清理避免脏数据堆积。6. 这套体系还能扩展到哪里项目跑通到现在我复盘时最深的感受是AI 驱动无代码测试不是一个孤立的工具它实际上是一套“业务语言到工程执行”的翻译体系。这套翻译体系的价值可以被复制到很多相邻领域。在安全测试方向目前很多渗透测试的前置信息收集和基础漏洞探测都可以用自然语言描述后自动执行。比如“扫描这个登录接口是否存在弱口令漏洞”“验证这个上传接口是否限制文件类型”AI Agent 可以自动调用现成的扫描工具并整理报告。当然安全测试的结果解释和责任判定还是需要人来把关但重复性的探测工作完全可以让 AI 来做。在企业级应用测试中车载系统测试和芯片测试也在走同样的路。这些领域的共性是硬件状态复杂、测试步骤繁琐、依赖大量专业性极强的底层工具。如果能把“转动钥匙打开仪表盘”这样的中文描述直接翻译成对底层 CAN 报文或寄存器配置的操作序列测试工程师就能把更多精力放在分析数据异常而不是编写底层驱动脚本上。我个人判断未来一到两年内AI Agent 在测试领域的落地形态会从“用例生成助手”升级为“测试策略制定者”。它不仅能告诉你怎么测还能根据产品变更历史、线上故障记录、代码覆盖率数据主动告诉你“这次版本发布最应该重点测哪三个模块”。这个愿景能不能落地得看 AI 对业务上下文的理解深度能走多远。不过这个方向值得持续投入毕竟测试的本质目标从来没有变过让交付质量可控让团队把时间花在真正重要的事情上。