我做了個Skill，專門用來自動生成測試用例
整理版優先睇
用Skill自動生成測試用例，從需求到XMind一鍵完成
呢篇文章係由一個做測試嘅朋友寫嘅。佢話嗰日手頭有兩個版本嘅需求，加埋七八十頁，要喺五點前寫好測試用例，搞到佢好崩潰。佢覺得呢啲重複性嘅工作點解要人手工做，於是就自己整咗個工具。
呢個工具嘅核心係將需求文檔或設計稿截圖放低，就會自動生成一份可以直接導入XMind嘅測試用例文件，唔係淨係畀幾個思路，而係有前置條件、步驟、預期結果同優先級嘅完整用例。佢用咗四種測試設計方法：等價類劃分、邊界值分析、場景法同錯誤推測，按順序疊加，唔係亂咁用。仲可以從圖片讀取測試場景，生成前會自己做質量預審，唔合格就改到合格先輸出。仲有記憶功能，用耐咗會越來越識你嘅習慣。最後輸出嘅.xmind檔案可以直接用，唔使再執。
總括嚟講，呢個工具可以大幅慳時間，提高測試覆蓋率，而家已經開源，有興趣嘅人可以試下。
- 工具能將需求文檔或截圖直接轉換為完整的XMind測試用例，無需二次整理。
- 內置等價類劃分、邊界值分析、場景法、錯誤推測四種方法，按順序疊加執行。
- 支援圖片需求（如Figma截圖、流程圖），自動識別元素和分支生成用例。
- 生成前有質量預審，檢查覆蓋率、優先級分佈等六項指標，不合格則自動修正。
- 具有記憶功能，記錄用戶的歧義判斷、偏好設置，越用越精準。
generate-test-cases 開源倉庫
GitHub 倉庫，包含完整安裝和使用說明，支援自動生成測試用例
點解要做呢個工具？
呢個工具係畀逼出嚟嘅。作者當時手頭有兩個版本需求，加埋七八十頁，要喺五點前搞掂測試用例。
呢啲重複嘅愚蠢
佢覺得點解要人手工做呢啲嘢，於是決定自己整一個真正接手呢件事嘅工具，唔係半成品。
端到端生成測試用例
佢嘅目標係：掉低需求，出嚟一份可以直接導入XMind嘅完整用例。
核心能力逐個睇
工具內置四種測試設計方法，按順序疊加：
- 1 等價類劃分（EP）——劃分有效同無效區間，唔遺漏唔重疊
- 2 邊界值分析（BVA）——計算上下限同臨界點，唔靠感覺
- 3 場景法（ST）——梳理基本流、備選流、異常流，覆蓋業務主線同分支
- 4 錯誤推測（EG）——補充特殊字符、極端值、併發場景，針對高風險位
四種方法唔係隨機調用，而係有順序地疊加
另外，佢可以從圖片讀取測試場景：
- UI設計稿 -> 識別頁面元素、輸入框、按鈕、狀態文案 -> 生成表單驗證同交互用例
- 流程圖 -> 識別分支條件、步驟順序、異常路徑 -> 生成完整場景流用例
- 規則表格截圖 -> 識別枚舉值同條件組合 -> 生成等價類同邊界值用例
圖片同文字可以同時放，交叉對照，補漏場景
生成前會自檢，六項指標全部合格先輸出：
- 需求覆蓋率達95%以上
- P0佔比10-15%
- P1佔比30-40%
- 每條需求關聯至少一種測試設計方法
- 唔會憑空編造需求文檔唔存在嘅場景
- 冇語義重複嘅用例
仲有記憶功能，會記錄歧義判斷、標籤選擇、步驟粒度偏好、歷史遺漏場景，越用越識你。
記住你嘅項目同習慣
最後輸出嘅.xmind檔案結構清晰，直接打開XMind全選導入就得，唔使再執。
直接導入XMind
點樣用？三步搞掂
- 1 第一步：將需求文檔寫入 requirements/requirement.md，設計稿截圖放入 requirements/ 目錄
- 2 第二步：喺 GitHub Copilot Chat 輸入「生成測試用例」
- 3 第三步：喺兩個檢查點確認（解析結果確認、生成預覽確認），其餘自動跑完
生成完畢，test-docs/ 目錄會有個帶時間戳嘅 .xmind 檔案，打開直接用。
三步搞掂，唔使再執
邊啲人適合用？
- 用緊 GitHub Copilot，想將測試用例生成從工作清單划走
- 對測試質量有要求，唔滿足於 AI 隨手俾嘅建議清單
- 需求文檔成日係圖片形式，之前要手動轉述
- 希望團隊測試用例風格統一、優先級分佈穩定
開源地址：https://github.com/342164796/generate-test-cases
先講下嗰個令我崩潰嘅下午
老實講，呢個工具係被逼出嚟嘅。
嗰日手頭壓住兩個版本嘅需求，截止時間係下晝五點。一份文字需求，一份原型圖，加埋七八十頁，要由頭寫測試用例。
我當時嘅感受係：呢啲嘢點解要人手做？
做過測試嘅應該都明嗰種感覺——業務邏輯要反覆睇，邊界值要一個一個計，場景流要慢慢梳理，然之後仲要喺 XMind 度逐個節點敲入去。一份中等複雜嘅需求，快嘅一兩個鐘，慢嘅大半日就冇咗。
更煩嘅唔係嘥時間，而係嗰啲「重複嘅蠢事」：
上個禮拜先問過產品某個模糊需求點理解，呢個禮拜換咗個文檔，同樣嘅問題又要問多次。優先級點定？每次都靠感覺，P0 同 P1 撈埋一齊，分佈飄忽不定。某啲場景幾乎次次都漏——弱網重試、空列表狀態、文件上傳邊界值——唔係唔知，而係趕時間嘅時候就會漏。
我當時就諗，AI 成日話可以取代人，點解就冇人做一個真係搞得掂呢件事嘅工具？
唔係嗰種俾你幾個測試點嘅半成品，而係真正端到端——入需求，出返一份可以直接導入 XMind 嘅完整用例文件。
於是乎自己動手整咗。
佢做到啲乜，一句講曬
將需求文檔（或設計稿截圖）掟入去，自動吐出嚟一份可以直接導入 XMind 嘅測試用例文件。
唔係「俾你幾個思路」，唔係「參考嚇呢啲測試點」，而係帶前置條件、操作步驟、預期結果、優先級標籤嘅完整用例——打開 XMind 全選導入，攞到就用得嗰種。
核心能力，逐個講清楚
1｜四種測試設計方法，一個都唔少
講真，好多 AI 工具俾出嘅測試用例，就係將需求複述一次，加句「驗證嚇係咪正確」。呢啲唔叫測試設計，呢啲叫翻譯。
呢個工具內置咗測試領域真正喺度用嘅四種方法，按順序疊加執行：
等價類劃分（EP）——將所有輸入劃分成有效區間同無效區間，唔遺漏，唔重疊。
邊界值分析（BVA）——上限、下限、臨界點，逐個計出嚟，而唔係靠感覺「試嚇邊界」。
場景法（ST）——完整梳理基本流、備選流、異常流，業務主線同每一條分支都要覆蓋到。
錯誤推測（EG）——高風險模塊補充特殊字符、極端值、併發場景，將最容易出 BUG 嘅地方重點照顧。
四種方法唔係隨機調用，而係有順序咁疊加，最終生成嘅用例集係一個有結構、有層次嘅整體，而唔係一堆嘢堆埋一齊。
2｜會由圖片讀出測試場景
呢個能力我自己用嘅時候有啲嚇親——老實講，冇諗過效果咁好。
好多時需求根本冇文字，嚟嘅係一張 Figma 截圖、一張原型圖、或者一張畫滿箭頭嘅業務流程圖。以前遇到呢種情況，我要自己將圖先「翻譯」做文字，再去寫用例，變相多做咗一重功夫。
而家將圖片直接掟入 requirements/ 目錄就得。
工具會用多模態能力讀取圖片內容：
- UI 設計稿 → 識別頁面元素、輸入框、按鈕、狀態文案 → 生成表單驗證同交互用例
- 流程圖 → 識別分支條件、步驟順序、異常路徑 → 生成完整嘅場景流用例
- 規則表格截圖 → 識別枚舉值同條件組合 → 生成等價類同邊界值用例
圖片同文字可以同時放埋一齊，工具會交叉對照，補齊單獨靠任何一方都可能漏咗嘅場景。
3｜生成前先自檢，唔合格唔放行
呢條我覺得係令佢真正好用嘅原因。
AI 生成測試用例最令人唔放心嘅地方唔係慢，而係你唔知佢漏咗啲乜。生出一堆用例，覆蓋率其實得 60%，優先級全部堆咗喺 P2，P0 寥寥可數——呢種結果仲衰過冇，因為你仲要去檢查。
工具喺正式生成之前會行一輪質量預審，逐項核查：
- 需求覆蓋率是否達到 95% 以上
- P0 佔比是否喺合理區間（10–15%）
- P1 佔比是否達標（30–40%）
- 每條需求是否至少關聯咗一種測試設計方法
- 有冇憑空編造需求文檔入面唔存在嘅場景
- 有冇語義重複嘅用例
六項全部通過，先進入生成階段。任何一項唔達標，會先自動修正，改完再輸出。
成個過程你只需要喺兩個檢查點確認嚇，其餘全自動。
4｜有記憶，越用越明你
呢部分係我花最多時間嘅地方，亦係令佢由「用得」變成「好用」嘅關鍵。
第一次用完之後，工具會喺項目入面建立一個 .memory/ 文件夾，將呢啲嘢記低：
你做過嘅歧義判斷。 某個模糊需求你點理解，下次遇到類似描述，直接重用，唔再問你。
你嘅標籤選擇。 呢個項目係 PC 定 APP，記低咗，下次唔使再揀。
你嘅步驟粒度偏好。 你覺得步驟太細叫佢合併咗，佢記低，之後風格保持一致。
歷史漏咗嘅場景。 邊類場景之前經常遺漏，今次自動補返。
用咗幾次之後，生成質量會明顯好過第一次。唔係因為模型升級咗，而係因為佢記低咗你嘅項目同你嘅習慣。
5｜輸出直接用得，唔使二次整理
生成嘅文件係 .xmind 格式，結構嚴格跟 XMind 導入規範組織：
項目名做根節點，下面按功能模塊分層。每條用例包含：前置條件、操作步驟、預期結果、優先級標籤。同一模塊下嘅用例按功能區域歸類，唔會出現「每個功能點單獨開一個目錄」搞到目錄爆炸嘅問題。
打開 XMind，全選導入，一份結構清晰嘅測試用例樹就喺眼前。
點用，真係得三步
第一步： 將需求文檔寫入 requirements/requirement.md，設計稿截圖放入 requirements/ 目錄。
第二步： 喺 GitHub Copilot Chat 輸入：
第三步： 喺兩個檢查點確認嚇（解析結果確認、生成預覽確認），其餘全自動跑完。
生成完畢，test-docs/ 目錄下會出現一個帶時間標記嘅 .xmind 文件，打開直接用。
適合咩人用
如果你符合以下描述入面嘅任何一條，呢個工具值得試嚇：
- 用緊 GitHub Copilot，想將測試用例生成呢件事由工作清單劃走
- 對測試質量有要求，唔滿足於 AI 隨便掟出嚟嘅「建議清單」
- 需求文檔經常以圖片形式落嚟，之前焗住要手動轉述再寫用例
- 希望團隊測試用例風格統一、優先級分佈穩定，而唔係每個人各自寫
開源地址
項目已開源，歡迎 Star、Fork、提 Issue：
https://github.com/342164796/generate-test-cases
README 入面有完整嘅安裝同使用說明，克隆落嚟五分鐘就可以行得起。
先說說那個讓我崩潰的下午
說實話，這個工具是被逼出來的。
那天手裏壓着兩個版本的需求，截止時間是下午五點。一份文字需求，一份原型圖，加起來七八十頁，從頭寫測試用例。
我當時的感受是：這玩意兒憑什麼要人手工做？
做過測試的應該都懂那種感覺——業務邏輯要反覆看，邊界值要一個個算，場景流要慢慢梳理，然後還得在 XMind 裏一個節點一個節點地敲進去。一份中等複雜的需求，快的一兩小時，慢的大半天就沒了。
更煩的不是耗時，是那些"重複的愚蠢"：
上週剛問過產品某個模糊需求怎麼理解，這周換了個文檔，同樣的問題又得問一遍。優先級怎麼定？每次都靠感覺，P0 和 P1 混在一起，分佈飄忽不定。某些場景幾乎每次都忘——弱網重試、空列表狀態、文件上傳邊界值——不是不知道，就是在趕時間的時候會漏。
我當時就想，AI 整天說能替代人了，怎麼就沒人做一個真的能接手這件事的工具？
不是那種給你列幾個測試點的半成品，而是真正端到端——進來需求，出來一份可以直接導入 XMind 的完整用例文件。
於是自己動手做了。
它能做什麼，一句話說清楚
把需求文檔（或設計稿截圖）丟進去，自動吐出一份可以直接導入 XMind 的測試用例文件。
不是"給你幾個思路"，不是"參考一下這些測試點"，而是帶前置條件、操作步驟、預期結果、優先級標籤的完整用例——打開 XMind 全選導入，拿到就能用的那種。
核心能力，一個個說清楚
1｜四種測試設計方法，一個都不少
講真，很多 AI 工具給出的測試用例，就是把需求複述一遍，加個"驗證一下是否正確"。這不叫測試設計，這叫翻譯。
這個工具內置了測試領域真正在用的四種方法，按順序疊加執行：
等價類劃分（EP）——把所有輸入劃分成有效區間和無效區間，不遺漏，不重疊。
邊界值分析（BVA）——上限、下限、臨界點，一個個算出來，而不是靠感覺"試試邊界"。
場景法（ST）——完整梳理基本流、備選流、異常流，業務主線和每一條分支都要覆蓋到。
錯誤推測（EG）——高風險模塊補充特殊字符、極端值、併發場景，把最容易出 BUG 的地方重點照顧。
四種方法不是隨機調用，而是有順序地疊加，最終生成的用例集是一個有結構、有層次的整體，而不是一堆東西堆在一起。
2｜會從圖片裏讀出測試場景
這個能力我自己用的時候有點驚到——說實話，沒想到效果這麼好。
很多時候需求根本沒有文字，來的就是一張 Figma 截圖、一張原型圖、或者一張畫滿箭頭的業務流程圖。以前遇到這種情況，我得自己先把圖"翻譯"成文字，再去寫用例，相當於多做了一遍工。
現在把圖片直接扔進 requirements/ 目錄就行了。
工具會用多模態能力讀取圖片內容：
- UI 設計稿 → 識別頁面元素、輸入框、按鈕、狀態文案 → 生成表單驗證和交互用例
- 流程圖 → 識別分支條件、步驟順序、異常路徑 → 生成完整的場景流用例
- 規則表格截圖 → 識別枚舉值和條件組合 → 生成等價類和邊界值用例
圖片和文字可以同時放進去，工具會交叉對照，補全單獨依賴任何一方都可能漏掉的場景。
3｜生成前先自檢，不合格不放行
這條我覺得是讓它真正好用的原因。
AI 生成測試用例最讓人不放心的地方不是慢，而是你不知道它漏了什麼。生出來一堆用例，覆蓋率其實只有 60%，優先級全堆在 P2，P0 寥寥無幾——這種結果比沒有還煩人，因為你還得去檢查。
工具在正式生成之前會跑一輪質量預審，逐項核查：
- 需求覆蓋率是否達到 95% 以上
- P0 佔比是否在合理區間（10–15%）
- P1 佔比是否達標（30–40%）
- 每條需求是否至少關聯了一種測試設計方法
- 有沒有憑空編造需求文檔裏不存在的場景
- 有沒有語義重複的用例
六項全過，才進入生成階段。任何一項不達標，先自動修正，改完再輸出。
整個過程你只需要在兩個檢查點確認一下，其餘全自動。
4｜有記憶，越用越懂你
這部分是我花時間最多的地方，也是讓它從"能用"變成"好用"的關鍵。
第一次用完之後，工具會在項目裏創建一個 .memory/ 文件夾，把這些東西記下來：
你做過的歧義判斷。 某個模糊需求你怎麼理解的，下次遇到類似描述，直接複用，不再問你。
你的標籤選擇。 這個項目是 PC 端還是 APP 端，記住了，下次不用重選。
你的步驟粒度偏好。 你覺得步驟太細讓它合併了，它記住，後續風格保持一致。
歷史漏掉的場景。 哪類場景之前經常遺漏，這次自動補進去。
用了幾次之後，生成質量會明顯比第一次好。不是因為模型升級了，而是因為它記住了你的項目和你的習慣。
5｜輸出直接能用，不用二次整理
生成的文件是 .xmind 格式，結構嚴格按照 XMind 導入規範組織：
項目名作為根節點，下面按功能模塊分層。每條用例包含：前置條件、操作步驟、預期結果、優先級標籤。同一模塊下的用例按功能區域歸類，不會出現"每個功能點單獨建一個目錄"導致目錄爆炸的問題。
打開 XMind，全選導入，一份結構清晰的測試用例樹就在眼前了。
怎麼用，真的只要三步
第一步： 把需求文檔寫進 requirements/requirement.md，設計稿截圖放進 requirements/ 目錄。
第二步： 在 GitHub Copilot Chat 裏輸入：
第三步： 在兩個檢查點確認一下（解析結果確認、生成預覽確認），其餘全自動跑完。
生成完畢，test-docs/ 目錄下會出現一個帶時間戳的 .xmind 文件，打開直接用。
適合什麼人用
如果你符合以下描述中的任意一條，這個工具值得試試：
- 在用 GitHub Copilot，想把測試用例生成這件事從工作清單裏劃掉
- 對測試質量有要求，不滿足於 AI 隨手甩出來的"建議清單"
- 需求文檔經常以圖片形式下發，之前不得不手動轉述再寫用例
- 希望團隊測試用例風格統一、優先級分佈穩定，而不是每個人各寫各的
開源地址
項目已開源，歡迎 Star、Fork、提 Issue：
https://github.com/342164796/generate-test-cases
README 裏有完整的安裝和使用說明，克隆下來五分鐘就能跑起來。