AI驱动自动化测试:Midscene框架与YAML配置的工程实践

📅 2026/7/1 21:30:06
AI驱动自动化测试:Midscene框架与YAML配置的工程实践
1. 项目概述当AI测试框架遇上YAML效率革命来了最近在搞自动化测试的同行们估计都听过一个词AI赋能。但说实话很多所谓的“AI测试”要么是噱头要么就是上手门槛高得吓人配置复杂学习曲线陡峭最后往往沦为“玩具”。直到我上手试了试Midscene这个框架再结合YAML这种简洁的配置语言才真正体会到什么叫“降维打击”。今天我就以一个真实的电商支付流程为例带你看看如何在5分钟内用几行YAML配置就生成一套可执行、可维护的AI自动化测试脚本。这不仅仅是写脚本更快了更是对整个测试设计思路的一次刷新。简单来说Midscene是一个基于自然语言理解和AI驱动的自动化测试框架。它的核心思想是“描述即测试”。你不需要再一行行地写driver.find_element(By.ID, “submit”).click()这样的底层代码而是用人类语言描述你要测试的场景和操作。框架背后的AI模型通常是集成的大语言模型会理解你的意图并自动生成对应的底层执行代码比如基于 Playwright 或 Selenium。而YAML在这里扮演了“场景蓝图”的角色它是一种结构化的数据格式用非常易读的键值对来定义测试场景、步骤、数据和断言。两者结合让编写自动化测试从“编码”变成了“配置”极大地提升了效率降低了技术门槛。这套组合拳最适合谁呢首先是测试工程师尤其是那些业务能力强但编码能力相对薄弱的同学可以快速将测试用例转化为可执行的自动化脚本。其次是开发工程师在开发自测或者做冒烟测试时可以快速搭建测试场景无需深入测试框架细节。最后是团队负责人追求测试脚本的易读性、可维护性和快速迭代YAML 格式的场景文件像文档一样清晰非常利于团队协作和知识传承。2. 核心设计思路为什么是Midscene YAML在深入实操之前我们得先弄明白为什么这个组合能如此高效。这背后是一套经过深思熟虑的设计哲学解决了传统自动化测试的几个核心痛点。2.1 痛点解析传统脚本的“阿喀琉斯之踵”我做了这么多年测试传统基于代码的自动化脚本最头疼的就这几件事维护成本高页面元素定位符如XPath、CSS Selector一旦变化就需要在代码里到处查找修改牵一发而动全身。一个支付按钮的ID变了可能得改好几个地方的代码。可读性差一堆find_element、send_keys、assert的代码堆在一起非原作者或者一段时间不看很难快速理解这个脚本到底在测什么业务逻辑。新同事接手成本极高。编写效率低即使是简单的流程也需要编写大量样板代码。一个完整的支付流程从登录、选商品、填地址、选支付方式到确认支付代码量不小且容易出错。技能门槛要求测试人员具备相当的编程能力熟悉测试框架的API这在一定程度上限制了自动化测试的普及。2.2 Midscene的破局之道意图驱动测试Midscene 的思路很巧妙它做了一个“翻译层”。你不需要关心具体的元素怎么定位、用什么API操作你只需要告诉它“要做什么”。比如你输入“在搜索框输入‘手机’并点击搜索”Midscene 的AI引擎会做两件事语义理解识别出“搜索框”是一个输入框“输入”是输入文本操作“手机”是输入值“点击搜索”是点击按钮操作。代码生成根据理解的结果结合对当前被测应用AUT的上下文学习可能需要初始配置或录制自动生成底层测试框架如Playwright的代码来执行这些操作。这意味着测试脚本的核心从“如何实现”变成了“要测什么”也就是从How转向了What。这极大地解放了测试设计者的心智负担。2.3 YAML的桥梁作用结构化的场景蓝图光有自然语言描述还不够我们需要一种方式来结构化地组织一个复杂的测试场景包含多个步骤、测试数据、预期结果等。这就是YAML的用武之地。YAMLYAML Ain‘t Markup Language是一种对人类友好易读易写的数据序列化语言。它用缩进和简单的符号来表示结构比JSON更简洁比XML更清晰。在Midscene的上下文中YAML文件定义了一个完整的测试场景Scene。它的优势在于极佳的可读性即使不懂代码的产品经理或业务人员也能大致看懂这个YAML文件描述的测试流程。分离关注点测试逻辑步骤流和测试数据可以分离便于数据驱动测试。易于版本管理作为纯文本文件可以很好地用Git等工具进行版本控制和差异比较。灵活可扩展可以方便地定义变量、循环、条件判断等逻辑虽然Midscene的YAML语法可能对其进行了封装和简化。所以Midscene YAML 的组合本质上是将“用自然语言描述的业务测试意图”通过“结构化的YAML场景蓝图”传递给“AI驱动的代码生成与执行引擎”最终落地为可运行的自动化测试。这个流程将测试人员从繁琐的编码中解脱出来专注于更重要的测试设计和业务验证。3. 环境准备与工具链搭建理论讲完了我们动手实操。首先你需要准备好运行环境。别担心整个过程非常轻量。3.1 基础环境配置Midscene 通常是一个基于 Node.js 或 Python 的框架。为了通用性我们以 Python 环境为例进行说明因为它生态丰富且Playwright对Python支持很好。安装Python确保你的系统安装了 Python 3.8 或更高版本。可以在终端输入python --version或python3 --version检查。安装Node.js可选但推荐部分Midscene的实现或其依赖的AI服务可能需要Node.js环境。建议安装最新的LTS版本。安装PlaywrightMidscene 底层很可能使用 Playwright 作为浏览器自动化引擎。通过 pip 安装pip install playwright。安装后需要安装浏览器驱动playwright install。这个命令会下载 Chromium、Firefox 和 WebKit 的二进制文件。3.2 Midscene框架安装与初始化目前Midscene 可能是一个较新的或特定社区的项目你需要查找其官方文档或仓库。假设它可以通过 pip 安装。# 假设Midscene的Python包名为 midscene-ai pip install midscene-ai安装完成后通常需要进行初始化配置比如设置AI模型的API密钥如果它使用OpenAI GPT、通义千问等大模型作为引擎。# 可能是一个初始化命令用于创建配置文件 midscene init这个命令可能会在用户目录下生成一个配置文件如~/.midscene/config.yaml你需要在这里填入你的AI服务API Key和端点等信息。注意关于AI模型的选择和配置是关键一步。如果Midscene支持本地模型如通过Ollama部署的Llama 3那么你的数据隐私和运行成本会更有保障。如果使用云端API请务必注意测试脚本中可能涉及的敏感数据如支付信息的安全性最好使用测试环境的假数据。3.3 编辑器选择YAML编写体验提升编写YAML文件一个好用的编辑器能事半功倍。我强烈推荐Visual Studio Code并安装以下插件YAML(Red Hat)提供YAML语法高亮、自动补全和格式验证。Prettier - Code formatter统一代码格式保持YAML文件的整洁。如果Midscene有自定义的YAML Schema可以配置进去获得更精准的智能提示。4. YAML场景文件深度解析以电商支付为例现在我们进入最核心的部分编写YAML场景文件。我将以一个简化但完整的“电商平台支付流程”为例一步步拆解每个部分。假设我们测试的是一个电商网站流程是登录 - 搜索商品 - 加入购物车 - 进入结算 - 填写收货地址 - 选择支付方式 - 确认支付 - 验证订单结果。4.1 场景元数据与全局配置一个YAML场景文件通常以一些元数据开始定义场景的基本信息。# test_payment_scene.yaml scene: “电商平台完整支付流程验证” # 场景名称 description: “验证用户从登录到支付成功的完整业务流程使用测试账号和虚拟支付方式。” # 场景描述 author: “Your Name” # 作者 version: “1.0” # 版本 baseUrl: “https://test-shop.example.com” # 被测应用的基础URL browser: “chromium” # 使用的浏览器可选 chromium, firefox, webkit headless: false # 是否无头模式调试时设为false可以看到浏览器操作 timeout: 30000 # 全局超时时间毫秒 ai_model: “gpt-4” # 指定使用的AI模型根据Midscene配置来定baseUrl非常重要所有相对路径的操作都会基于这个URL。headless: false在脚本开发调试阶段建议关闭无头模式直观地观察浏览器执行过程便于排查问题。timeout设置一个合理的全局超时避免因为网络或页面加载慢导致脚本无限等待。4.2 数据驱动变量与测试数据定义在步骤中硬编码测试数据如用户名、商品名是不好的实践。我们应该在文件顶部或单独的数据区定义它们。# ... 接上面的元数据部分 variables: username: “test_user_001” password: “Test123456” search_keyword: “无线蓝牙耳机” shipping_address: name: “张三” phone: “13800138000” province: “广东省” city: “深圳市” district: “南山区” detail: “科技园南路100号” card_number: “4111111111111111” # 测试用的信用卡号 card_expiry: “12/30” card_cvv: “123”为什么这么做维护方便当测试数据需要变更时只需修改这一个地方。数据驱动你可以轻松地将这个variables块扩展为一个列表或者从外部CSV、JSON文件读取从而实现用多组数据运行同一个场景。清晰安全将敏感信息即使是测试数据集中管理比散落在步骤中更安全。4.3 核心步骤Steps定义与自然语言指令这是YAML文件的灵魂。每个step代表一个用户操作或一个验证点。Midscene 的核心魔力就在于action字段下的自然语言指令。steps: - name: “导航到登录页面” action: “打开网站首页” # AI会理解为在浏览器中访问 baseUrl (‘/’) - name: “执行用户登录” action: “在页面顶部的登录链接处点击” # AI会找到登录链接并点击 - name: “输入用户名” action: “在用户名输入框中输入 {{ username }}” # 使用变量AI会找到用户名输入框并输入变量值 - name: “输入密码” action: “在密码输入框中输入 {{ password }}” - name: “提交登录” action: “点击‘登录’按钮” # AI会识别文本为“登录”的按钮并点击 - name: “搜索商品” action: “在搜索框内输入‘{{ search_keyword }}’并按下回车键” # 这是一个复合指令AI会分解为“找到搜索框”、“输入文本”、“按回车” - name: “选择第一个商品” action: “在搜索结果列表里点击第一个商品的图片或标题” # AI需要理解“搜索结果列表”、“第一个”、“商品图片/标题”这些概念 - name: “加入购物车” action: “在当前商品详情页点击‘加入购物车’按钮” # “当前页面”是重要的上下文 - name: “进入购物车并结算” action: “点击页面右上角的购物车图标然后在弹出的购物车浮层中点击‘去结算’按钮” # 这是一个稍复杂的多步指令但AI可以处理 - name: “填写收货地址” action: | 在结算页面完成以下操作 1. 点击‘新增收货地址’。 2. 在收货人姓名栏输入‘{{ shipping_address.name }}’。 3. 在手机号栏输入‘{{ shipping_address.phone }}’。 4. 选择所在地区为‘{{ shipping_address.province }}’、‘{{ shipping_address.city }}’、‘{{ shipping_address.district }}’。 5. 在详细地址栏输入‘{{ shipping_address.detail }}’。 6. 点击‘保存’。 # 使用‘|’可以编写多行文本清晰地描述一个包含多个子操作的任务。AI会将其作为一个整体任务来理解和执行。 - name: “选择支付方式” action: “在支付方式区域选择‘信用卡支付’” - name: “填写信用卡信息” action: | 在信用卡支付表单中 - 输入卡号 ‘{{ card_number }}’ - 输入有效期 ‘{{ card_expiry }}’ - 输入CVV码 ‘{{ card_cvv }}’ - name: “提交订单并支付” action: “点击‘确认支付’按钮” # 关键操作点关键点解析action字段这是你与AI沟通的桥梁。指令要清晰、无歧义。尽量使用页面上的可见文本如按钮文字、元素的角色如“搜索框”、“登录链接”或相对位置如“第一个”、“右上角”来描述。避免使用内部ID或复杂的CSS路径除非必要。变量注入使用{{ variable_name }}的语法将之前定义的变量注入到指令中实现数据驱动。多行指令对于复杂步骤使用|或-等YAML多行字符串语法使指令更结构化易于阅读。上下文AI模型通常能理解步骤间的上下文。例如在“进入购物车并结算”这一步它知道“页面右上角”指的是整个浏览器窗口的右上角区域。4.4 断言Assertions与验证点测试不止是操作更重要的是验证结果。我们可以在步骤中或步骤后加入断言。# ... 接在支付步骤之后 - name: “验证支付成功” action: “等待页面跳转或出现成功提示” assertions: - “页面上应该包含‘支付成功’或‘订单已生成’的文字” - “当前页面的URL应该包含‘order/success’” - “页面上应该显示订单编号通常是一串数字” # Midscene的AI会解析这些断言语句将其转化为具体的检查代码如检查元素文本、URL等。 - name: “验证订单详情” action: “点击‘查看订单详情’链接” assertions: - “订单状态应显示为‘待发货’或‘已支付’” - “订单中的商品名称应包含‘{{ search_keyword }}’” - “收货地址信息应与填写的‘{{ shipping_address.name }}’、‘{{ shipping_address.phone }}’一致”断言的设计技巧正向与反向除了验证“应该出现什么”也可以验证“不应该出现什么”比如“页面不应显示‘支付失败’的报错信息”。等待与稳定性在断言前action里可以加入“等待...”的指令给页面足够的加载和渲染时间避免因页面未就绪而导致的误判。这是提高脚本稳定性的关键。多维度验证像上面的例子从提示文字、URL、关键数据多个维度验证确保测试的健壮性。5. 运行脚本与调试技巧YAML文件写好了怎么让它跑起来5.1 执行命令与参数根据 Midscene 的设计执行命令可能类似于# 运行单个场景文件 midscene run test_payment_scene.yaml # 运行一个目录下的所有场景 midscene run ./test_scenes/ # 可能支持指定报告输出 midscene run test_payment_scene.yaml --report html执行后Midscene 会解析YAML文件。将每个step中的action和assertions自然语言指令通过配置的AI模型“翻译”成具体的 Playwright 代码这个过程可能在后台完成也可能生成临时脚本。启动浏览器按顺序执行这些代码。收集执行结果成功/失败并在控制台或生成报告中输出。5.2 调试与问题排查实录AI不是万能的尤其是在面对复杂或动态的网页时。脚本运行失败是常态关键在于如何快速排查。以下是我踩过坑后总结的排查清单问题现象可能原因排查思路与解决方案AI无法找到元素1. 页面未加载完成。2. 指令描述歧义多个相似元素。3. 元素是动态生成的如Ajax加载。4. 页面结构已变更。1.增加等待在action中明确加入“等待页面加载完成”或“等待XX元素出现”。2.更精确描述使用更独特的文本或结合位置如“点击红色的‘立即购买’按钮”。3.使用更稳定的定位器如果Midscene支持可以在步骤中附加selector提示如selector: “button:has-text(‘确认支付’)”。4.手动验证用浏览器开发者工具检查元素是否还在文本是否一致。断言失败1. 验证条件太严格或错误。2. 异步数据未更新。3. 页面状态未达到预期。1.检查断言语句确保“应该包含”的文字完全匹配包括空格和标点。2.添加显式等待在断言前增加一个等待步骤如“等待订单状态变为‘已支付’”。3.分步调试临时将headless设为false观察执行到哪一步时页面状态与预期不符。脚本执行顺序错误1. 步骤间存在依赖但上一步未成功。2. 页面跳转或弹窗未处理。1.检查上一步的日志确保每个步骤都成功执行了。2.处理弹窗如果支付后有弹窗提示需要在YAML中增加步骤如“处理弹窗点击‘确定’按钮”。3.使用断言作为检查点在关键步骤后加入断言确保页面进入了正确状态再执行下一步。AI理解偏差自然语言指令存在二义性。1.简化指令将一个复杂步骤拆分成多个更简单、明确的步骤。2.提供上下文在步骤的name或注释中提供更多背景信息如果Midscene支持注释。3.查看生成的代码如果Midscene提供调试模式查看AI生成的底层代码是什么反向推断它理解错了什么。实操心得一描述的艺术给AI下指令就像和一个聪明但刻板的新手同事沟通。指令要具体、唯一、无歧义。例如“点击大的按钮”就不如“点击那个写着‘提交订单’的蓝色大按钮”。多使用页面上可见的、稳定的文本作为锚点。对于图标按钮可以描述其旁边的文字或其在容器中的位置。实操心得二稳定性优先网络、性能、动态内容都是自动化测试的天敌。在关键操作如点击后页面跳转、数据提交后一定要加入明确的等待或状态验证而不是依赖固定的sleep。在YAML中可以通过action: “等待成功提示出现最多等10秒”这样的指令来实现智能等待。6. 进阶技巧与最佳实践掌握了基础之后我们可以让测试脚本更强大、更优雅。6.1 场景复用与模块化一个复杂的系统会有很多共享流程比如登录、退出、添加商品到购物车。我们可以将这些流程抽离成子场景或函数。# common_scenes.yaml scenes: login: steps: - action: “在登录框输入用户名 {{ username }}” - action: “在登录框输入密码 {{ password }}” - action: “点击登录按钮” logout: steps: - action: “点击用户头像” - action: “在下拉菜单中点击‘退出登录’”在主场景中可以通过类似call或include的语法来复用它们具体语法取决于Midscene是否支持。这样登录逻辑只需维护一份。6.2 数据驱动测试扩展前面我们用了variables。更强大的数据驱动是使用外部数据文件。# 在场景文件中配置数据源 dataSource: file: “./test_data/payment_cases.csv” format: csv然后在步骤中使用数据行的字段名来引用数据如{{ row.card_number }}。这样用一个YAML场景文件搭配一个CSV数据文件包含多组用户名、地址、支付卡号就能自动运行多个测试用例。6.3 集成到CI/CD流水线自动化测试的最终归宿是持续集成。由于Midscene最终驱动的是Playwright这类工具它可以很容易地集成到Jenkins、GitHub Actions、GitLab CI等平台中。无头模式与容器化在CI中将headless设置为true并确保CI环境安装了所需的浏览器驱动。依赖安装在CI脚本中加入pip install midscene-ai playwright和playwright install步骤。执行与报告运行midscene run命令并配置将生成的测试报告如JUnit XML格式、HTML报告归档到CI的制品库中。失败处理设置CI任务在测试失败时通知相关人员如通过邮件、Slack。6.4 维护策略当页面发生变化时没有一成不变的页面。当被测应用UI更新时你的YAML场景文件如何维护影响评估首先判断变更影响的是哪个或哪些步骤的描述。是按钮文字变了还是整个流程重组了更新指令修改对应步骤的action描述使其匹配新的页面。例如按钮文字从“提交”改为“确认提交”你只需要修改那一条指令。回归测试修改后重新运行相关的场景文件确保整个流程依然畅通。版本控制将YAML场景文件纳入Git管理。每次页面大改版可以创建一个对应的分支或标签来管理测试脚本的版本与代码版本同步。与传统脚本维护的对比传统脚本中一个元素定位符可能散落在多个地方维护时需要全局搜索替换且容易遗漏。而在MidsceneYAML中你只需要关注业务描述是否准确。只要“确认支付”这个按钮在页面上对用户来说仍然是那个“确认支付”的按钮即使它的底层HTMLid从btn-submit变成了btn-confirm-payment你的YAML文件也不需要任何修改因为AI是根据视觉/文本语义来理解的而不是脆弱的代码定位符。这是其维护性上最大的优势。7. 局限性与适用场景思考Midscene YAML 的模式并非银弹清楚它的边界才能更好地使用它。优势再强调一次极低的编写门槛让业务专家和测试人员能直接参与自动化脚本创建。极高的可读性YAML文件本身就是最好的测试文档。强大的维护性对前端UI变化有更好的适应性。快速原型5分钟搭建一个可运行的复杂流程测试用于快速验证需求或进行冒烟测试。当前的局限性AI理解成本与不确定性AI可能误解指令尤其是在面对复杂、非标准的UI组件时。调试需要一定的技巧和对AI“思维”方式的了解。执行速度每个步骤都可能涉及一次AI调用取决于实现可能比直接执行硬编码的脚本要慢。复杂逻辑处理对于需要复杂条件判断、循环、数据库校验或调用外部API的测试场景纯自然语言描述可能不够用可能需要框架提供更高级的YAML语法或与自定义代码的扩展接口。环境与成本依赖AI服务可能产生API调用费用且需要稳定的网络环境。使用本地大模型则需要一定的硬件资源。我的建议是将 Midscene YAML 作为你自动化测试武器库中的一件高效速射武器。它非常适合端到端E2E业务流程测试就像本文的电商支付流程。冒烟测试/Sanity Check快速验证核心功能是否正常。探索性测试的辅助记录在手动探索时用YAML快速记录下操作步骤稍后即可自动回放。让非技术成员贡献测试用例产品经理可以用YAML描述他们期望的用户旅程。而对于需要极致性能、复杂逻辑或与内部系统深度集成的测试场景传统的基于代码的自动化框架如Pytest Playwright仍然是更可靠、更灵活的选择。两者可以结合使用用Midscene覆盖大部分稳定的业务流程用传统脚本处理那些“硬骨头”。