AutoGenesis：基于 AI + MCP 的跨平台自动化测试实践

作者：熊月 / Microsoft Edge QA 项目贡献成员：芈峮、佟玉、刘竞屏、王政达、熊月 📂 开源地址：github.com/microsoft/AutoGenesis

自动化测试之所以难以真正铺开，很多时候并不是因为团队不重视，而是因为门槛太高: 业务人员不会写代码，测试脚本又难维护。Microsoft Edge QA 团队开源的 AutoGenesis，想解决的正是这个问题: 让测试人员只需要用自然语言描述场景，就能借助 AI 生成自动化代码，并由确定性的程序稳定执行。基于这一路径，团队在 Windows、macOS、iOS、Android 四个平台上验证了方案可行性。本文将拆解其基于 MCP 的架构设计、代码生成与执行机制，以及它如何帮助非技术背景成员真正参与自动化建设，并通过 200 万+ 月执行步骤、99% 通过率、700+ 用例规模等数据，展示这套方案在效率、稳定性和规模化落地上的实际价值。

一、背景：测试自动化困境

频繁发版、需求变化飞快、不管团队什么规模……相信很多测试工程师都经历过这样的噩梦：

版本一周发一次，手工回归根本跑不完

好不容易写了自动化脚本，界面一改就得重写

这些困境背后，是两个核心问题：自动化门槛高、脚本维护难。

Microsoft Edge 浏览器也面临同样的压力。Edge 基于开源 Chromium 开发，跟随 Chrome 节奏高频发版，每次 Chromium 的变更都难以预测，回归测试量极大。

为了破解这一困局，Edge QA 团队展开了一场全员探索，经过多轮技术调研和方案验证，最终形成了今天要介绍的主角 AutoGenesis——一个为了解决真实痛点而诞生的方案。

二、解决方案：AI + MCP 的系统设计

随着 AI 能力的快速提升，一个新的可能性浮现出来：能否用 AI 来同时解决所有自动化的难题？

理解自然语言：可以直接从测试场景描述执行或生成代码，降低技术门槛

快速学习：能够理解不同平台的 UI 结构，减少学习成本

但关键问题是：如何用 AI？是让 AI 直接执行测试，还是让 AI 生成测试代码？这个选择决定了方案的成败。

2.1 技术选型：三种方案的对比

面对自动化测试的困境，团队系统对比了三条可能的路径：

方案优点致命缺陷传统代码录制结果稳定门槛高，非技术人员无法维护AI 直接执行测试快速上手结果不稳定，长期成本高AI 生成代码（AutoGenesis）门槛低 + 结果稳定✅ 两全其美'}}">

为什么不让 AI 直接执行测试？

AI 的不确定性，是它在"执行"环节最大的隐患。这种不确定性主要体现在两个方面：

① 执行过程容易发散，难以控制

AI 在执行长任务时容易"走神"：

测试步骤多了，AI 可能忘记之前的上下文，重复执行某些步骤

遇到意外弹窗或页面变化，AI 可能陷入无限循环或执行错误的操作

无法准确追踪"当前执行到哪一步"，出错后难以定位

让 AI 基于截图判断"测试是否通过"存在严重缺陷：

模糊判断：AI 可能将"看起来像成功"误判为"测试通过"

无法量化：传统断言可以精确验证文本、属性、数值，AI 只能给出主观判断

不可回溯：AI 的判断过程是黑盒，失败时无法追溯为什么判断错误

就像让一个人在黑暗中蒙眼走路——偶尔走对，但你不敢信任它。这种不确定性在 Demo 阶段可能被接受，但在生产环境中是致命的。

AutoGenesis 的核心理念：让 AI 做它最擅长的事（理解意图、生成代码），让确定性的程序来做它最擅长的事（稳定执行）。

有了这个理念，接下来的问题是：如何在工程上实现？

2.2 系统架构：四层协作，AI 只在生成层工作

为了将"AI 只生成不执行"的理念落地，AutoGenesis 采用了分层架构设计，每一层都有明确的职责边界。

架构全景

整个系统由四层构成，关键原则是 AI 的工作边界严格限定在第二层（LLM 层），第四层（执行层）完全不依赖 AI：

架构设计解决了技术可行性，但要让它真正发挥价值，还有一个更关键的问题：如何落地？

三、落地实践：从方案到成果

3.1 落地方案

Edge 团队的测试团队中，外包人员占大多数。他们懂业务、会设计测试用例，但不懂编程。传统自动化对他们来说门槛太高，只能继续做手工测试。

AutoGenesis 恰好能解决这个问题——让非技术背景的人员也能参与自动化建设。

具体做法是重新定义团队分工：FTE 工程师构建工具链、制定标准并培训外包团队；外包团队用自然语言写测试场景，由 AI 生成代码。

AutoGenesis 带来的改变：让外包员工用自己擅长的方式（自然语言描述测试场景）直接产出专业级自动化代码，完全不需要学编程。

3.2 用数据说话

事实胜于雄辩，数据可以最直接简单的说明问题。以下是 AutoGenesis 在 Microsoft Edge 项目中的月度运行数据：

指标成果🖥️ 平台覆盖4 个平台（Windows / macOS / iOS / Android）全覆盖）🔢 月执行规模200 万+ 测试步骤⏰ 节省时间3022 小时/月（≈ 370人天）✅ 通过率稳定性99%，近零抖动🐛 缺陷发现提前发现 107 个 问题📋 自动化用例700+ 条标准化测试用例🔄 自动触发流水线10 条持续集成流水线👥 外包团队贡献413 个 Pull Requests⚡ 编写效率单场景编写时间：2-3小时 → 10-15分钟（提升约 10 倍）'}}">

核心价值

AutoGenesis 不只是技术工具，更是一套可复制的方法论：技术人员专注架构设计与知识传递，非技术人员从手工测试升级为自动化建设者。

从落地方案到数据成效，我们看到了 AutoGenesis 在实际业务中的价值。那么，它背后的技术实现是什么样的？让我们深入细节。

四、核心模块详解

4.1 从用户视角看：工作流有多简单？

整个工作流程出乎意料地简单——不需要懂 Selenium，不需要懂 Appium，只需要会描述"我想测什么"：

第一步：用 Gherkin 格式写测试场景（接近自然语言）

Feature: Edge Pagerendering TestsScenario: Test msn.com website on EdgeGiven I have launched Edge browserWhen I click the search box in NTP pageAnd I input "msn.com" in the search boxAnd I press enter to navigate to the pageAnd I wait for the page to load completelyThen I should see the tab with the title "msn.com"

第二步：让 AI 生成测试代码
方式一（推荐）：使用 BDD AI Toolkit 扩展，点击 Scenario 上方的 "Send to Copilot" 按钮
 方式二：在 GitHub Copilot Chat 中直接调用 autoGenesis-run skill，如： use autoGenesis-run skill to execute scenario "Test msn.com website on Edge"
第三步：Copilot 自动调用 MCP 工具逐步执行，生成 Python 步骤定义代码
第四步：执行测试（不再调用任何 AI）
方式一：点击 "Run" 按钮（扩展提供）
 方式二：命令行运行 behave features/
这个简洁的用户体验背后，是四层架构各司其职的结果。接下来我们深入每一层，看看它们是如何协作的。
4.2 LLM 层：AI 的职责边界在哪里？
在 AutoGenesis 的设计中，AI 的角色被严格限定——它既不负责执行测试，也不负责判断结果，而是专注于做一件事：将自然语言翻译成结构化的测试代码。
LLM 仅承担一件事：将 Gherkin 步骤翻译为 MCP 工具调用序列，并生成 Python 步骤定义代码。
完整的工作流程（录制模式）
LLM 层通过 MCP 协议与底层设备能力交互。那么，这些设备能力是如何封装的？这就引出了第三层的两个关键组件。
4.3 MCP Server 层：跨平台能力的统一封装
为了支持 Windows、macOS、iOS、Android 四大平台，AutoGenesis 实现了两个 MCP Server，它们都遵循相同的 MCP 协议，但底层调用不同的自动化引擎。
4.3.1 PyWinauto MCP Server：Windows 桌面应用自动化
 PyWinauto MCP Server 是 AutoGenesis 针对 Windows 桌面应用的自动化能力封装，基于 pywinauto 库，通过 MCP 协议为 AI 提供标准化的 Windows UI 自动化工具集。
Windows 自动化原理
 PyWinauto 通过 Windows UI Automation API 和 Win32 API 访问应用程序的控件结构：
UI Automation（推荐）：支持现代 Windows 应用（UWP、WPF、WinUI 等）
 Win32 API：兼容传统桌面应用（Win32、MFC 等）
元素定位支持多种策略：AutomationId、ControlType、Name、ClassName 等。
PyWinauto MCP Server 支持的完整工具集
工具名称功能说明使用场景app_launch启动 Windows 应用测试开始前初始化应用app_close关闭应用窗口清理测试环境app_screenshot应用截图视觉证据留存'}}">
工具名称功能说明使用场景element_click点击元素按钮、菜单项等点击交互right_click右键点击元素打开上下文菜单send_keystrokes发送键盘快捷键Ctrl+C、Alt+F4 等快捷键操作enter_text输入文本到控件表单填写、文本框输入select_item选择列表项下拉框、列表框选择open_folder打开文件夹（文件资源管理器）文件管理场景'}}">
工具名称功能说明使用场景mouse_drag_drop拖拽元素到目标位置文件拖拽、控件重排mouse_hover鼠标悬停在元素上触发悬停提示、下拉菜单mouse_scroll鼠标滚轮滚动页面/列表滚动'}}">
工具名称功能说明断言规则verify_element_exists验证元素存在控件可见性检查verify_element_not_exist验证元素不存在控件消失验证verify_checkbox_state验证复选框状态检查 checked/unchecked 状态verify_element_value验证元素值文本框、标签内容验证verify_elements_order验证元素排列顺序列表项、控件布局顺序验证verify_visual_task视觉验证任务基于 LLM 的视觉断言'}}">
工具名称功能说明before_gen_code初始化代码生成会话（清空缓存、生成 UUID）preview_code_changes预览生成的代码 diffconfirm_code_changes确认写入 steps/*.py 文件'}}">
4.3.2 Appium MCP Server：Mac 与移动端能力封装
 与 PyWinauto 类似，Appium MCP Server 为 iOS、Android、macOS 提供统一的自动化接口。Appium 通过系统级 UI 接口访问控件树：
Android：UIAutomator2
 iOS：XCUITest
所有元素定位基于控件属性（accessibility_id、xpath 等），而非视觉坐标。
Appium MCP Server 支持的完整工具集
 MCP Server 通过 FastMCP 框架按平台注册工具，避免无关工具干扰 AI 选择：
📱 通用操作工具（所有平台共用）工具名称功能说明使用场景app_launch启动应用测试开始前初始化应用app_close关闭应用清理测试环境session_close关闭 Appium 会话测试结束后释放资源find_element查找元素元素定位验证click_element点击元素按钮、链接等交互send_keys输入文本表单填写、搜索框输入swipe滑动屏幕页面滚动、抽屉菜单scroll_to_element滚动直到元素可见查找列表中的目标项double_click_element双击元素特殊交互场景tap_coordinates点击坐标无明确控件标识的场景pinch_zoom缩放手势地图、图片缩放hide_keyboard隐藏键盘输入完成后收起键盘switch_element_to_on/off开关切换设置项开关控制app_state获取应用状态检查应用前后台状态get_page_source_tree获取页面结构树AI 理解当前页面布局take_screenshot截图视觉证据留存time_sleep等待指定秒数处理加载延迟verify_visual_task视觉验证任务基于 LLM 的视觉断言'}}">
✅ 验证断言工具（所有平台共用）
工具名称功能说明断言规则verify_element_exists验证元素存在元素可见性检查verify_element_not_exists验证元素不存在元素消失验证verify_element_attribute验证元素属性支持 == / != / contains`verify_element_relative_location验证元素相对位置布局关系断言'}}">
🔧 代码生成工具（所有平台共用）
工具名称功能说明before_gen_code初始化代码生成会话（清空缓存、生成 UUID）preview_code_changes预览生成的代码 diffconfirm_code_changes确认写入 steps/*.py 文件'}}">
工具名称功能说明dismiss_alert关闭系统警告弹窗（权限、通知等）directly_send_keys绕过键盘直接设置文本值long_press_element长按元素触发上下文菜单'}}">
🤖 Android 专属工具
工具名称功能说明press_key模拟系统按键（返回、Home、菜单键等）long_press_element长按元素'}}">
💻 macOS 专属工具
工具名称功能说明right_click_element右键点击元素press_key模拟键盘按键drag_element_to_element拖拽元素到目标位置mouse_hover鼠标悬停在元素上verify_elements_order验证元素排列顺序（垂直/水平）'}}">
4.4 代码生成机制：如何防止 AI "乱写"代码？
 前面提到，AI 负责生成测试代码。但 AI 有不确定性，如何保证生成的代码可控、可审查？AutoGenesis 设计了三阶段 Preview-Confirm 工作流，将代码写入控制权交还给人类。
Step 1 — before_gen_code(feature_file, step_file)├── 清除 gen_code_cache 录制缓存├── 生成唯一 gen_code_id（UUID），防止会话混淆└── 根据 feature 文件路径自动推断 steps/ 目标目录

↓ Copilot 逐步调用操作工具`

@record_calls 装饰器自动将每次调用录入缓存Step 2 — preview_code_changes()`├── 读取 gen_code_cache，生成 diff_preview└── 返回给 Copilot 确认（人工可在此介入审查）

↓ Copilot 确认 diff 无误

Step 3 — confirm_code_changes()├── 将 proposed_changes 追加写入 steps/*.py`└── 清除缓存，输出写入行数

4.5 Behave BDD 框架：生成的代码如何执行？

代码生成后，需要一个稳定的执行引擎。AutoGenesis 选择了 Behave—— Python 生态中成熟的 BDD 框架，它的优势在于：

① LLM 天然能理解 Given/When/Then 结构

Gherkin 的 BDD 语法与 LLM 的推理模式天然契合，降低了 AI 理解测

AutoGenesis：基于 AI + MCP 的跨平台自动化测试实践