AutoGenesis：基于 AI + MCP 的跨平臺自動化測試實踐

作者 | 熊月，Microsoft Edge QA

審校 | Kitty

項目貢獻成員：羋峮、佟玉、劉競屏、王政達、熊月
開源地址：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 格式寫測試場景（接近自然語言）

    Then I should see the tab with the title "msn.com"

第二步：讓 AI 生成測試代碼

• 方式一（推薦）：使用 BDD AI Toolkit 擴展，點擊 Scenario 上方的"Send to Copilot"按鈕

• 方式二：在 GitHub Copilot Chat 中直接調用autoGenesis-runskill，如：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 通過 WindowsUI 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 工作流，將代碼寫入控制權交還給人類。

  └── 清除緩存，輸出寫入行數

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實現了線程橋接：

    session_ready.wait()  # 主線程阻塞直到 MCP Session 就緒

步驟函數通過call_tool_sync以同步方式調用異步工具（超時 400 秒）：

            time.sleep(0.1)

4.6 BDD AI Toolkit 擴展：可選的效率增強工具

重要說明：VS Code 擴展不是必須的。AutoGenesis 提供了兩種使用方式：

1. VS Code 擴展

   ：可視化界面，一鍵操作（適合非技術人員）

2. GitHub Copilot Skill

   ：通過autoGenesis-runskill 調用

擴展的價值在于顯著降低使用門檻，將復雜操作簡化為可視化界面。

擴展提供的核心能力

① 一鍵錄制與回放

在.feature文件中，每個 Scenario 上方自動顯示兩個按鈕（CodeLens）：

• "Send to Copilot"

  ：一鍵觸發 AI 生成測試代碼

• "Run"

  ：一鍵執行測試場景

}

② 環境自動檢測與配置

Setup 管理面板提供可視化環境配置，自動檢測并解決：

• Python / Node.js 安裝狀態

• MCP Server 依賴安裝

• 配置文件生成與驗證

• 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