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 来同时解决所有自动化的难题？

AI 的优势显而易见：

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

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

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

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

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

为什么不让 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 项目中的月度运行数据：

核心价值

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

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

四、核心模块详解

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

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

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

Feature: Edge Pagerendering Tests  Scenario: Test msn.com website on Edge    Given I have launched Edge browser    When I click the search box in NTP page    And I input "msn.com" in the search box    And I press enter to navigate to the page    And I wait for the page to load completely    Then 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 支持的完整工具集

🖥️ 应用管理工具

🖱️ 交互操作工具

🖱️ 鼠标高级操作

✅ 验证断言工具

🔧 代码生成工具

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 选择：

📱 通用操作工具（所有平台共用）

✅ 验证断言工具（所有平台共用）

🔧 代码生成工具（所有平台共用）

📱 iOS 专属工具

🤖 Android 专属工具

💻 macOS 专属工具

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 理解测试意图的难度。

② 非技术人员也能读懂并参与用例编写

自然语言描述的用例让 QA、PM 甚至外包团队都能参与测试场景的定义，打破了"自动化只能靠开发者"的壁垒。

③ 生态成熟，社区支持强大

Python + Behave 是业界验证过的成熟技术栈，与 Appium/PyWinauto 无缝集成。

由于 Behave 是同步框架，而 MCP 的 Python 实现是异步的，before_all 中用 janus.Queue 实现了线程桥接：

def before_all(context):    context._task_queue = janus.Queue()   # 线程安全的同步/异步双向队列    context._result_queue = janus.Queue()    session_ready = threading.Event()    def run_loop():        loop = asyncio.new_event_loop()        async def mcp_worker():            # 自动从 .vscode/mcp.json 向上遍历发现 MCP Server 配置            mcp_config = load_mcp_config(server_name=AUTO_GENESIS_MCP_SERVER or None)            async with stdio_client(StdioServerParameters(...)) as streams:                async with ClientSession(*streams) as session:                    await session.initialize()                    context.session = session                    session_ready.set()   # 通知主线程 MCP 就绪                    while True:          # 工具调用循环                        task = await context._task_queue.async_q.get()                        if task is None: break                        result = await task                        await context._result_queue.async_q.put(result)        loop.run_until_complete(mcp_worker())    threading.Thread(target=run_loop, daemon=True).start()    session_ready.wait()  # 主线程阻塞直到 MCP Session 就绪

步骤函数通过 call_tool_sync 以同步方式调用异步工具（超时 400 秒）：

def call_tool_sync(context, coro, timeout=400):    context._task_queue.sync_q.put(coro)    start = time.time()    while True:        try:            return context._result_queue.sync_q.get_nowait()        except queue.Empty:            if time.time() - start > timeout:                raise TimeoutError("MCP tool invocation timed out.")            time.sleep(0.1)

4.6 BDD AI Toolkit 扩展：可选的效率增强工具

重要说明：VS Code 扩展不是必须的。AutoGenesis 提供了两种使用方式：

1. VS Code 扩展：可视化界面，一键操作（适合非技术人员）

2. GitHub Copilot Skill：通过 autoGenesis-run skill 调用

扩展的价值在于显著降低使用门槛，将复杂操作简化为可视化界面。

扩展提供的核心能力

① 一键录制与回放

在 .feature 文件中，每个 Scenario 上方自动显示两个按钮（CodeLens）：

• "Send to Copilot"：一键触发 AI 生成测试代码

• "Run"：一键执行测试场景

// CopilotIntegrationService.ts —— 真实实现async sendToCopilot(text: string): Promise<void> {    await vscode.commands.executeCommand('workbench.panel.chat.view.copilot.focus');    await vscode.commands.executeCommand('workbench.action.chat.open', { query: text });}

② 环境自动检测与配置

Setup 管理面板提供可视化环境配置，自动检测并解决：

• Python / Node.js 安装状态

• MCP Server 依赖安装

• 配置文件生成与验证

• MCP Server 连接状态

// extension.tsexport async function activate(context: vscode.ExtensionContext) {    GlobalState.initialize(context);    activateBddFeatureSupport(context);    // 注册 Gherkin CodeLens 按钮    registerTools(context);                // 注册 Copilot 工具    setupWebViewProvider = new SetupWebViewProvider(context.extensionUri, context);    vscode.window.registerWebviewViewProvider(SetupWebViewProvider.viewType, setupWebViewProvider);    await checkForMcpServerUpdates(context);  // 静默检查 MCP Server 版本更新}

结论：AutoGenesis 提供了从可视化到命令行的完整使用路径，满足不同技术背景用户的需求。扩展和 Skill 是效率增强工具，核心能力完全独立于它们存在。

至此，AutoGenesis 的四层架构全部介绍完毕。从架构设计到具体实现，每一层都有明确的边界和职责。

五、总结：四个核心优势

回到开篇的问题——技术门槛高、脚本维护难，AutoGenesis 是如何解决它们的？总结起来有四个核心优势：

① 降低自动化门槛，让非技术人员也能参与

用自然语言（Gherkin）描述测试场景，由 AI 自动生成代码。Edge 团队的外包人员（非技术背景）贡献了 413 个 PR，证明这不是理论，而是可行的实践。

② 跨平台统一，消除碎片化测试栈

一套技术栈（Python + Behave + MCP + LLM）覆盖 Windows、macOS、iOS、Android 四大平台，告别各平台独立维护工具链的噩梦。

③ 从根本上解决 AI 不稳定性问题

MCP 协议约束 AI 行为边界 + 执行层完全脱离 AI 推理，99% 的通过率稳定性证明了这一设计的有效性。从架构层面隔离不确定性，而非依赖 AI 自身的进步。

④ 效率与规模双重提升

单场景编写时间从 2-3 小时缩短至 10-15 分钟；后续执行零 AI 调用成本，规模越大 ROI 越高。

写在最后

测试自动化做了很多年，大家都知道它重要，但真正推进时总会遇到一些难题

AutoGenesis 的价值，恰恰就是同时解决这两个问题——用 AI 降低门槛和维护成本，用"AI 只生成不执行"的策略保证稳定性。

这不是一个炫技的工具，而是一次从工程师需求出发、在真实业务中打磨出来的务实实践。

如果你的团队也正面临这些挑战，AutoGenesis 这个案例或许能给你一些真正"能落地"的启发：

• 🔥 敏捷团队：每周发版，需要快速建立回归体系

• 🔥 资源受限团队：测试人员有限，但覆盖面要求高

• 🔥 多平台产品：需要同时覆盖 App + 桌面端 + Web

• 🔥 混合技能团队：包含技术和非技术人员，需要降低参与门槛

📂 开源地址：AutoGenesis on GitHub（MIT License，欢迎 Star / Fork / PR）

📧 技术交流：autogenesis@microsoft.com

本文所有代码片段均来自 AutoGenesis 开源仓库，数据来自微软 Edge QA 团队真实业务验证。

Made with ❤️ by Microsoft Edge QA Team