AI-First Testing, 以 AI 為核心重新設計測試流程

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

Q1: 什麼是 AI-First Testing？

• A簡: 以 AI 主導「探索與設計」，由程式碼承載重複執行的重新分工測試方法。
• A詳: AI-First Testing 是從 AI 能力出發重新設計測試流程的做法。它將「需要判斷」交給人、「需要探索」交給 AI、「需要穩定重複」交給程式碼。流程分三步：用決策表收斂有價值的測試、用 AI 探索並記錄執行步驟、用生成的規格產出可重複的自動化測試程式。其核心是以 AI 提升探索效率、以 CPU 程式穩定執行，避免把 AI 硬塞進舊流程造成成本與不一致。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q4, B-Q1

Q2: AI-First 與傳統測試流程有何差異？

• A簡: 傳統聚焦人工編寫與執行；AI-First 重構分工與左移探索，降低成本與不一致。
• A詳: 傳統測試以人力設計、手動或腳本執行，瓶頸在編寫速度與維護量。AI-First 重新分工：AI 進行探索與步驟設計，程式碼承載回歸執行，決策表統一定義測試範圍，並「左移」自動化，將不確定的探索轉為一次性生成的標準測試程式。差異在於流程重塑與資源配置（Brain/GPU/CPU）平衡，而非僅以 AI 替換人力。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q14, B-Q20

Q3: 為什麼不能只把 AI 塞進舊流程？

• A簡: 會遭遇成本、效能與結果不一致的天花板，無法發揮 AI 的變革性。
• A詳: AI 作為新工具若硬套舊流程，往往出現三大問題：GPU 成本高、執行速度慢、結果不一致（同題重跑行為不同）。舊流程的瓶頸在「人力編寫慢」，AI 帶來的是「探索與生成 10x」，瓶頸轉移到規格與流程設計。唯有重構分工、左移自動化、建立高品質規格（Decision Table、Session Logs、OpenAPI）才能把不確定的探索轉為確定的程式執行。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q16, B-Q10, D-Q9

Q4: AI-First Testing 的三大步驟是什麼？

• A簡: 設定範圍、探索步驟、生成程式；對應 TestKit: GenTest、Run、GenCode。
• A詳: 三步驟：1) 用 Decision Table 從 AC 收斂測試範圍，明確條件與動作，生成 Test Cases；2) 用 AI+MCP 探索執行步驟（API 或 Web），記錄 Session Logs 與示例；3) 用 SpecKit/生成器將規格、案例與示例轉為穩定的自動化測試程式，交給 CPU 重複執行，降低 GPU/人力成本並提升一致性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q2, B-Q4, C-Q7

Q5: 什麼是驗收條件（AC, Acceptance Criteria）？

• A簡: 定義功能達成的可驗證條件，是展開決策表與測試的起點。
• A詳: AC 是功能需求完成的驗收標準，描述何時視為「成功」。在 AI-First 中，AC 是 Decision Table 的來源，將 AC 中的條件、門檻、期望行為轉為可排列組合的 Criteria/Actions/Rules。良好的 AC 可避免探索過程失焦，提升生成 Test Case 的精準度，並支援跨通道測試（API/Web）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, B-Q3, C-Q1

Q6: Decision Table（決策表）是什麼？

• A簡: 用系統化列舉條件組合與動作的表格，管理測試範圍與優先順序。
• A詳: 決策表將條件（Criteria）與動作（Actions）排列成規則（Rules），清楚列出所有組合及預期結果，便於分析覆蓋率、邊界值與優先級。在 AI-First 中，它是生成高複用 Test Case 的核心，讓 AI 能據此探索步驟並產出自動化測試。適合邏輯組合類測試，不適合效能、資安、壓力與高度狀態機測試。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q22, B-Q3, C-Q2

Q7: Test Case 在 AI-First 中如何定義？

• A簡: 保持抽象、聚焦業務意圖與期望輸出，跨 API/Web 通道可重用。
• A詳: AI-First 的 Test Case 避免操作細節，聚焦「Given/When/Then」與資料、驗證點。它由 Decision Table 展開，保留業務語義，使 AI 在探索時可匹配 API 規格或 Web 操作。抽象的 Test Case 可跨不同介面共用，減少重複維護，提高一致性與覆蓋效率。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q17, C-Q3, C-Q9

Q8: 什麼是 TestKit？為何需要它？

• A簡: 封裝 prompts、文件與工具的套件，對齊三步驟，降低操作成本。
• A詳: TestKit 是為 AI-First Testing 打包的工作套件，含指令（GenTest、API.Run/Web.Run、API.GenCode/Web.GenCode）、模板與工具。它提供標準化上下文、資源位置與 MCP 整合，確保 AI 能正確探索與生成，減少手動拼接、上下文噪音與人為錯誤，使流程可重複、可審核、可持續改進。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q4, C-Q4

Q9: TestKit 提供哪些核心指令？

• A簡: GenTest、API.Run、API.GenCode、WEB.Run、WEB.GenCode 五組指令。
• A詳: 指令映射三步驟與兩通道：1) GenTest：從 AC 生成 Decision Table 與 Test Cases；2) API.Run/WEB.Run：以 MCP 探索 API 或 Web 的實際執行步驟並記錄；3) API.GenCode/WEB.GenCode：用規格、案例、示例生成可重複執行的測試程式碼。這些指令形成閉環，確保探索成果轉化為穩定資產。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q4, B-Q1, C-Q7

Q10: 什麼是 MCP（Model Context Protocol）？

• A簡: 為代理提供工具層抽象，隔離噪音并把自然語言映射到可執行操作。
• A詳: MCP 是將模型與工具對接的協定/層，提供可調用的操作與上下文約束。它能把「文字意圖」轉為「API/Web 的具體呼叫」，並在內部管理認證（如 OAuth2）、規格載入與日誌記錄。MCP 的分層可顯著降低上下文噪音、避免把整份 OpenAPI/HTML 塞進主代理，提升探索成功率與效率。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q8, D-Q2

Q11: MCP 在測試探索中的核心價值？

• A簡: 抽象 API/Web 操作，減噪、分層、記錄，可重用探索軌跡為生測規格。
• A詳: MCP 以工具封裝操作（ListOperations、CreateSession、RunStep）與上下文管理，把繁雜規格、認證與請求細節留在子層處理。主代理專注任務推理，MCP 則記錄 session logs、請求/回應，產出可供生成程式的示例。如此把不確定探索轉為確定規格，建立可審核、可復用的知識資產。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q9, C-Q4

Q12: SpecKit 是什麼？與 TestKit 有何關係？

• A簡: 以規格驅動生成程式的框架；可承接 TestKit 產物生成一致測試碼。
• A詳: SpecKit 是規格驅動開發（SDD）的工具集合，從高品質規格生成可維護的程式。TestKit 用於產出測試所需規格（案例、步驟、示例），SpecKit 則用來把這些規格「落地」為一致化、自動化測試程式碼。二者配合可提升大型團隊一致性、易維護性與與管理系統整合能力。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q14, C-Q10, D-Q10

Q13: 什麼是「左移」在 AI 自動化測試中的意義？

• A簡: 早期讓 AI 探索確定步驟，後續只用程式重複執行，降低不確定性。
• A詳: 左移指將探索與設計前置到流程早期，讓 AI 先確立正確步驟與驗證點，再一次性生成程式碼。如此便把大量回歸從 GPU/人力轉為 CPU，降低費用與波動。例如 40000 次測試改為 400 次探索 + 400 次生成 + 40000 次程式執行，將不確定轉為確定，大幅提升可預測性與效率。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q3, B-Q1, D-Q9

Q14: 為什麼讓 AI 專注「探索」而非「重複執行」？

• A簡: 探索需要推理，重複執行需一致性；程式碼更適合承載後者。
• A詳: AI 擅長理解意圖、組合步驟與試錯，適合探索；但重複執行需要可預測、一致與低成本，程式碼與 CPU 更符合。讓 AI 反覆跑測試會有速度慢、成本高、結果不一致的問題。將探索成果固化為測試程式，就能穩定回歸、擴大覆蓋、降低 GPU Token 花費與人力審查負擔。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q13, B-Q15, D-Q1

Q15: GPU/CPU/Brain 的成本差異？

• A簡: Brain>GPU>CPU；探索與判斷貴，重複執行以 CPU 最省。
• A詳: 人腦成本最高且稀缺，GPU 次之且昂貴，CPU 最便宜且穩定。AI-First 就是把「探索」交給 GPU、「判斷」交給人、「重複執行」交給 CPU。這樣配置使整體成本曲線健康，避免用昂貴資源去執行大量可程式化的回歸任務，達到效能與費用的最佳平衡。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q20, D-Q9, A-Q14

Q16: 什麼是 Context Engineering？

• A簡: 設計與控管模型上下文，降低噪音提高推理與操作成功率。
• A詳: Context Engineering 是針對代理的上下文內容設計、分層與約束。避免把整份規格或冗長 HTML 直接丟給模型，改以 MCP 工具抽象操作、提供簡化清單（ListOperations）、最小必要上下文，以防「Context Rot」。好的上下文管理讓模型專注任務，減少幻覺、提升探索效率與一致性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, D-Q2, A-Q10

Q17: 什麼是 Context Rot（上下文腐壞/雜訊）？

• A簡: 上下文混入過多無關細節，讓代理失準、慢與錯，探索失敗。
• A詳: Context Rot 指上下文含大量無關或冗長資訊，造成模型注意力分散、推理路徑錯誤、成本膨脹。解法是分層抽象（MCP 子層處理細節）、提供操作清單而非整規格、記錄示例供生成使用。如此可讓主代理聚焦測試任務，顯著提升成功率與速度。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q10, D-Q2

Q18: API 測試與 Web UI 測試的本質差異？

• A簡: API 可程式化且穩定；Web 需元素定位與可操作性，受 UI 規範影響大。
• A詳: API 測試著重規格契約與請求/回應驗證，易抽象與自動化。Web 測試需可靠定位元素、處理互動與狀態，受無障礙標記與結構影響。AI 操作 Web 常受可見性與定位困難影響，Playwright MCP 透過可存取性樹精簡頁面，提升可操作性。二者都可共用抽象 Test Case，以減少重複。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, C-Q8, D-Q3

Q19: 為何無障礙設計（Accessibility）對 AI 測試重要？

• A簡: 提供可存取性樹與語義，讓代理可靠定位與操作，減少影像辨識成本。
• A詳: 無障礙設計提供語義標記（aria-label、role、name），形成可存取性樹，Playwright MCP 會以此精簡 HTML 與定位元素。相較影像辨識，無障礙標記更快更可靠，能讓 AI「看見」與「按下」正確元素。做好無障礙設計是讓系統 AI-friendly 的關鍵。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q13, C-Q9, D-Q3

Q20: 覆蓋率（Coverage）在 AI-First 中的意義？

• A簡: 以決策表全覽條件組合，確保重要與邊界情境都被測到。
• A詳: 覆蓋率表示測試踩過多少條件組合與情境。AI-First 用決策表列出條件/動作/規則，清楚標示邊界值、違規與混合場景，再依風險與價值排序。如此讓探索與生成聚焦在「有價值的測試」，避免無止境的案例膨脹，提升測試的投入產出比。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q6, B-Q16, C-Q1

Q21: 決策表不適合哪些測試類型？

• A簡: 效能、資安、壓力、高併發狀態機等需另用方法設計。
• A詳: 決策表擅長條件組合與邏輯驗證，但對於效能基準、滲透測試、壓力與高併發狀態切換等不適用。這些類型需用負載模型、攻防腳本、狀態機或特定框架設計。AI-First 可在非功能測試中用規格驅動（SDD）與專用工具輔助，但不依賴決策表本身。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q16, D-Q8, C-Q10

Q22: 什麼是 Session Log？為何要保存？

• A簡: 探索過程的抽象記錄與請求回應示例，是生成程式的關鍵規格。
• A詳: Session Log 記錄探索的執行步驟（Operation、Action、Context）、API/Web 請求與回應檔、摘要與建議。它是將不確定探索固化為可重用規格的核心產物，後續生成測試程式時作為「操作示例」，提高正確性、一致性與可審核性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q5, C-Q7

Q23: 什麼是 Text-to-calls？

• A簡: 用自然語言描述操作，由工具層轉譯為具體 API/Web 呼叫。
• A詳: Text-to-calls 是把「文字意圖」轉為「可執行呼叫」的機制。代理提供 operation 名稱、action 敘述與 context，MCP 以內部模型做參數對齊與 function calling，完成實際操作。它讓主代理不必塞滿上下文細節，專注於推理與流程設計。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q5, D-Q2

Q24: Vibe Testing 與 AI-First 有何關係？

• A簡: Vibe 偏即席直跑；AI-First 將其轉為探索前置與程式化回歸。
• A詳: Vibe Testing 指以代理即席執行測試，雖能快速驗證但成本高且不一致。AI-First 將 Vibe 的探索能力前置，並把探索成果固化為自動化程式，避免每次都用 AI 重跑。兩者可互補：先 vibe 探索，再 AI-First 生成回歸測試。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q14, B-Q4, C-Q5

Q25: Acceptance Criteria 與 Test Case 的關聯？

• A簡: AC 是來源，Test Case 是展開；AC 決定範圍與預期行為。
• A詳: AC 定義成功條件，是決策表與 Test Case 的起點。決策表將 AC 的條件/門檻轉為可枚舉的規則，Test Case 再以 Given/When/Then 形化，保留意圖與驗證點。良好的 AC 直接決定覆蓋率與探索效率。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q6, C-Q1

Q26: 非功能性需求（NFR）在流程中的位置？

• A簡: 不適用決策表；需以專用方法與工具，在生成與整合階段處理。
• A詳: NFR 如資安、性能、可靠性多不適合決策表表述。AI-First 可在生成階段以 SpecKit 與測試管理規範整合，採用負載工具、靜態掃描、滲透框架等。流程上與功能測試並行，但規格與方法不同。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q16, C-Q10, D-Q8

Q27: A2A（Agent-to-Agent）通訊是什麼？

• A簡: 主代理與子代理/工具以語義消息互動，協調完成任務。
• A詳: A2A 指代理間協作模式。主代理負責任務推理，子代理（如 MCP）負責具體操作。消息包含 operation、action、context，子代理回傳結果與示例。此模式提高可組合性與可維護性，是大規模流程自動化的基石。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q5, B-Q8, A-Q23

Q28: OpenAPI Spec 在 AI-First 測試中的角色？

• A簡: 操作契約來源；用於探索參考與生成測試程式的依據。
• A詳: OpenAPI 提供 API 的結構、路徑、參數與回應模型。AI-First 不把整份規格塞給主代理，而以 MCP 子層載入並解析，提供精簡操作清單與參數映射。生成階段則用規格+Session 示例提升程式碼正確性與一致性。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q9, C-Q7

Q29: SDD（Specification-Driven Development）是什麼？

• A簡: 以高品質規格驅動生成與實作，提高一致性與可維護性。
• A詳: SDD 用規格作為唯一事實源，驅動代碼生成與驗證。AI-First 產出高品質測試規格（案例、步驟、示例），搭配 SpecKit 可生成一致化測試程式並接入管理系統。適用大型團隊與長期維護情境。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q12, C-Q10, D-Q10

Q30: 為何要跨通道共用 Test Case（API/Web）？

• A簡: 減少重複維護，提升一致性與覆蓋率，對齊業務意圖。
• A詳: 抽象的 Test Case 聚焦業務與驗證點，可被 API/Web 不同操作介面共用。如此避免維護多份相同邏輯不同界面的案例，降低文檔與生成量、提升一致性。探索與生成階段再基於通道特性產出步驟與程式碼。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q19, C-Q8, D-Q7

Q&A 類別 B: 技術原理類

Q1: AI-First Testing 整體如何運作？

• A簡: 三步驟閉環：決策表→探索→生成測試程式，資源分工 Brain/GPU/CPU。
• A詳: 技術原理說明：以 AC 為源生成 Decision Table，再展開 Test Case。用代理+MCP 探索 API/Web 步驟，留存 Session Logs（抽象過程與請求/回應示例）。最後以規格+示例生成測試程式（API/.NET+xUnit 或 Web/Playwright），交由 CPU 穩定回歸。關鍵步驟：規格化、抽象化、分層記錄。核心組件：TestKit 指令、MCP 工具、OpenAPI、Session Logs、SpecKit。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4, A-Q8, C-Q7

Q2: TestKit.GenTest 如何從 AC 生成決策表與 Test Case？

• A簡: 解析 AC 的條件與動作，系統化列舉規則並輸出案例草稿。
• A詳: 技術原理：GenTest 讀入 AC，提取 Criteria（條件）與 Actions（動作），列舉 Rules（組合）並計算預期輸出（如金額、優惠、允許）。生成格式化 Decision Table，並按重要性分類成 Test Case 檔。關鍵步驟：抽取語義→定義度量→列舉組合→計算期望。核心組件：解析模板、計算器、用例生成器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q6, C-Q1, C-Q2

Q3: 如何設計 Decision Table 的 Criteria/Actions？

• A簡: 用可枚舉的條件與可計算的動作，含邊界與違規場景。
• A詳: 技術原理：Criteria 選用可度量條件（數量、狀態），Actions 定義可驗證輸出（金額、優惠、允許）。關鍵步驟：加入邊界（最小/最大）、違規（超限）、混合場景；對齊業務計算公式（如 floor(N/2)）。核心組件：欄位標準、計算規則庫、風險分類器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q20, C-Q2, D-Q8

Q4: TestKit.API.Run 的執行流程是什麼？

• A簡: 讀規格→列操作→建 Session→RunStep 探索→記錄示例與摘要。
• A詳: 技術原理：代理先用 MCP.ListOperations 取可用操作，再用 MCP.CreateSession 建立會話與 OAuth2，接著為每步 RunStep（含 operation、action、context）。MCP 以內部模型做 function calling，記錄 request/response。關鍵步驟：減噪抽象→語義到參數映射→會話化日誌。核心組件：MCP 工具、OpenAPI 載入器、Session Recorder。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q8, C-Q5

Q5: MCP 如何抽象化 API 呼叫以降低上下文噪音？

• A簡: 暴露操作名與語義，隱藏規格細節與認證，子層轉譯執行。
• A詳: 技術原理：MCP 將繁雜規格與請求細節置於工具層，主代理只傳 operation、action、context。子層模型解析參數、執行請求、保存日誌。關鍵步驟：操作清單設計、語義到參數映射、最小必要回傳。核心組件：ListOperations、RunStep、Session 存檔器。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q16, B-Q10, D-Q2

Q6: ListOperations 如何解析 API 操作？

• A簡: 從 OpenAPI 生成精簡操作清單，保留識別與必要描述。
• A詳: 技術原理：載入 OpenAPI，抽取路徑/方法/操作名，生成帶語義描述的清單，避免把整份規格丟給主代理。關鍵步驟：規格解析→語義摘要→ID 綁定。核心組件：OpenAPI 解析器、摘要器、操作索引。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q28, C-Q4, D-Q6

Q7: CreateSession 如何建立會話並處理 OAuth2？

• A簡: 以工具層進行認證取得 token，綁定會話收納後續記錄。
• A詳: 技術原理：MCP 工具在 CreateSession 中執行 OAuth2（以 .env/secret），保存 access token 與會話上下文，之後所有 RunStep 附帶會話資訊。關鍵步驟：認證流程→token 綁定→會話目錄。核心組件：Auth 客戶端、Session 目錄、密鑰管理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q6, D-Q5, B-Q9

Q8: RunStep 如何將自然語言轉為 API 呼叫？

• A簡: 以 operation+action+context，子層模型做參數對齊並 function calling。
• A詳: 技術原理：主代理傳入 operation 與語義敘述，MCP 內部模型根據規格對齊參數，構造請求並執行，返回結果與示例檔案路徑。關鍵步驟：語義解析→參數映射→執行與記錄。核心組件：語義解析器、請求生成器、結果摘要器。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q23, B-Q5, C-Q5

Q9: Session Logs 的結構與內容包含哪些？

• A簡: 步驟摘要、請求/回應檔、答案與後續建議，供生成程式使用。
• A詳: 技術原理：每次 RunStep 會記錄 action、context、request/response 檔、answer（判定）、instructions（下一步建議）、summary（全局摘要）。關鍵步驟：標準化格式→檔案索引→人可讀摘要。核心組件：Logs 模板、檔案存儲、摘要器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q22, C-Q5, C-Q7

Q10: 如何管理 Context 以減少噪音並提升成功率？

• A簡: 分層抽象、最小必要、語義摘要、示例留存不直塞規格。
• A詳: 技術原理：採用 MCP 子層處理規格與認證，主代理只見操作清單與語義描述；用例示例在 Session 保存，生成時再取用。關鍵步驟：抽象 API/Web、語義到操作映射、上下文約束策略。核心組件：MCP 工具層、摘要器、規格索引。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q16, A-Q17, D-Q2

Q11: Text-to-calls 的機制與限制？

• A簡: 語義轉呼叫依賴規格與詞彙；需標準術語與清楚上下文。
• A詳: 技術原理：語義解析需對齊規格名稱、參數鍵、資料型態。若術語模糊或上下文不足，易映射錯誤。關鍵步驟：規格詞彙表、語義模板、錯誤回退。核心組件：名詞對齊器、型態校驗、錯誤處理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, D-Q1, D-Q2

Q12: Playwright MCP 的技術架構與特色？

• A簡: 基於可存取性樹生成精簡視圖，支援語義定位與操作。
• A詳: 技術原理：Playwright MCP 抽取頁面可存取性樹（role/name/label），生成精簡 YAML，供代理定位與操作元素（click、fill）。關鍵步驟：可存取性抽取→語義定位→動作執行。核心組件：AX 樹解析、定位器、動作執行器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, C-Q8, D-Q3

Q13: Accessibility 標記如何被代理使用？

• A簡: 利用 aria-*、role、name 作為語義鉤子，精準定位可操作元素。
• A詳: 技術原理：代理根據可存取性樹查找符合語義的元素；標記完整可提升定位成功率與速度。關鍵步驟：語義標記規範→可視/可操作性→一致命名。核心組件：AX 標記策略、定位規則、名稱詞彙表。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, C-Q9, D-Q3

Q14: SpecKit 生成測試程式的原理是什麼？

• A簡: 以規格為源，模板化生成一致代碼，集成管理與報告。
• A詳: 技術原理：讀取規格（OpenAPI、Test Case、Session 示例、內部規範），以模板引擎生成測試代碼與配置。關鍵步驟：規格合併→模板渲染→依賴注入與密鑰。核心組件：規格合併器、模板庫、管理集成插件。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q12, C-Q10, D-Q10

Q15: API 測試程式（.NET + xUnit）的架構如何設計？

• A簡: 客戶端封裝、測試類分案例、Arrange/Act/Assert 清晰。
• A詳: 技術原理：封裝 ShopApiClient（含 token），每個 Test Case一類，構造場景（Arrange）、執行操作（Act）、斷言結果（Assert）。關鍵步驟：依賴注入 token、請求封裝、斷言邏輯邊界。核心組件：HttpClient、模型綁定、xUnit。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q7, D-Q5, D-Q10

Q16: 覆蓋與優先級如何計算與排序？

• A簡: 基於風險、價值、邊界與違規場景排序先測重要情境。
• A詳: 技術原理：決策表標記場景類型（正常、邊界、超限、混合）、業務價值與風險分，生成優先執行清單。關鍵步驟：分類打分→分批探索→持續補齊。核心組件：風險評估器、分類器、計畫生成器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q20, C-Q5, D-Q8

Q17: 決策表到 Test Case 的映射規則？

• A簡: 每條規則轉一或多用例；保留意圖與驗證點不含操作細節。
• A詳: 技術原理：Rules→TCs：把條件值映射為測試資料、動作映射為預期輸出與斷言。關鍵步驟：Given/When/Then 模板化→資料與期望分離→通道無關。核心組件：用例模板、斷言庫、資料生成器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, C-Q3, D-Q8

Q18: 測試結果回報與摘要如何生成？

• A簡: MCP/代理在 Session 中寫摘要與建議，測試框架輸出報告。
• A詳: 技術原理：探索階段由代理在 Session Logs 填寫 answer、summary、instructions；生成階段測試框架輸出標準報告（通過/失敗、時間、訊息）。關鍵步驟：一致化格式→報告聚合→管理系統集成。核心組件：Logs 模板、Reporter、Dashboard。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q5, C-Q7, D-Q10

Q19: 如何跨通道共用 Test Case？

• A簡: 維持用例抽象，探索階段分通道生成步驟，代碼各自產出。
• A詳: 技術原理：Test Case 僅含意圖與驗證；探索分 API/Web，各自記錄示例；生成階段各自產生測試程式。關鍵步驟：用例語義標準→步驟示例分通道→代碼生成分支。核心組件：用例庫、MCP API/Web、生成器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q30, C-Q8, D-Q7

Q20: 成本估算模型（GPU 時間與 Token 成本）如何評估？

• A簡: 比較直接 AI 重跑 vs 探索+生成+CPU 回歸的總成本。
• A詳: 技術原理：直接 AI 重跑每次數分鐘/Token 成本高、年累計巨大；左移後 400 次探索+400 次生成+40000 次 CPU 執行，將不確定換成確定，大幅降費與提速。關鍵步驟：測試量體估算→執行頻次→資源單價。核心組件：Cost 模型、執行計畫、資源配置。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q15, D-Q9, C-Q7

Q&A 類別 C: 實作應用類（10題）

Q1: 如何準備 AC 並用 TestKit.GenTest 生成 Decision Table？

• A簡: 撰寫清晰 AC，執行 GenTest，審核表格的條件、動作與規則。
• A詳: 具體步驟：1) 撰寫 AC（條件、門檻、期望）；2) 在代理輸入 /testkit.gentest，附上商業敘述與限制（如限購≤10）；3) 檢視生成的 Decision Table，修正 Criteria/Actions 為可枚舉與可計算；4) 核對規則的期望值（含邊界、違規與混合）；5) 存檔 decision-table.md。注意事項：避免僅用 Y/N，加入數值與公式；標示允許/拒絕與計算明細。最佳實踐：附上計價公式與示例，利於後續生成。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q6, B-Q2

Q2: 如何審核與修正 Decision Table 的品質？

• A簡: 檢查條件可枚舉、動作可計算、邊界與違規場景完備。
• A詳: 具體步驟：1) 確認 Criteria 可度量（如商品數量）；2) Actions 可計算（總金額、優惠、允許）；3) 覆蓋最小/最大邊界（1、10、>10）；4) 驗證示例數值與公式（如 floor(N/2)）；5) 標記重要性與風險排序；6) 修正誤解（如「每組第二件六折」而非「第二件之後全六折」）。注意事項：避免泛化條件；保留期望輸出。最佳實踐：雙人審核與示例檢算。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, A-Q20, D-Q8

Q3: 如何用 TestKit 生成所有 Test Case 檔案？

• A簡: 依決策表展開用例模板，導出目錄結構與案例明細。
• A詳: 具體步驟：1) 確認 decision-table.md；2) 執行 TestKit.GenTest 的用例導出功能；3) 生成 /tests/…/tc-XX-*.md，含 Given/When/Then、資料與斷言；4) 附上 API 呼叫建議序列；5) 整理覆蓋率報告。注意事項：用例抽象，不含通道細節；命名一致易追蹤。最佳實踐：為每案附重要性與風險。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, B-Q17, C-Q1

Q4: 如何配置 MCP 以探索 API Test Steps？

• A簡: 安裝工具層、提供 OpenAPI 與密鑰，啟用 ListOperations/Session/RunStep。
• A詳: 具體步驟：1) 安裝 MCP（自製或套件）；2) 提供 OpenAPI 來源與 .env（OAuth2 client/secret）；3) 在代理執行 QuickStart，檢視操作指南；4) 呼叫 ListOperations 確認操作清單；5) CreateSession 綁定 token 與 session 目錄；6) RunStep 逐步探索。注意事項：避免把規格直接塞主代理；日誌目錄持久化。最佳實踐：命名 operation 與語義一致。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q6, B-Q7

Q5: 如何以 TestKit.API.Run 執行 R1-R6 並記錄 Session？

• A簡: 指定用例範圍，逐步 RunStep，保存 request/response 與摘要。
• A詳: 具體步驟：1) /testkit.api.run「執行：R1-R6」；2) 代理讀操作清單並設計步驟；3) 每步 RunStep（如 CreateCart、EstimatePrice、CreateCheckout）；4) MCP 保存 request/response（txt/json）、logs（md）；5) 代理填寫 answer/summary。注意事項：與預期不符要標注，供後續生成斷言。最佳實踐：每案對齊 Given/When/Then。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q22, B-Q9, D-Q4

Q6: 如何設定 OAuth2 access token 給測試程式？

• A簡: 用 .env 或環境變數注入，客戶端啟動時讀取注入 Header。
• A詳: 具體步驟：1) 在本機或 CI 設定 ACCESS_TOKEN=…；2) 客戶端讀取 Environment.GetEnvironmentVariable；3) 在 HttpClient DefaultRequestHeaders.Authorization = Bearer token；4) 測試執行前檢查 token 存在。注意事項：避免硬編碼；密鑰管理使用秘密存儲。最佳實踐：CI 用 Vault/Secret Manager。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q7, D-Q5, C-Q7

Q7: 如何用 .NET + xUnit 生成並執行 API 測試程式碼？

• A簡: 以 Session 示例設計 Arrange/Act/Assert，封裝客戶端並跑 dotnet test。
• A詳: 具體步驟：1) 生成專案：dotnet new xunit；2) 封裝 ShopApiClient（讀 token、路徑方法）；3) 按用例生成測試類（Arrange 建立資料、Act 呼叫 API、Assert 斷言金額/優惠/允許）；4) 執行 dotnet test，檢視報告。注意事項：斷言邊界與違規行為；日誌輸出便於診斷。最佳實踐：分層設計與依賴注入。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, D-Q10, A-Q14

Q8: 如何用 Playwright MCP 執行 Web 測試並記錄？

• A簡: 啟動頁面、登入流程、場景操作、保存步驟與結果摘要。
• A詳: 具體步驟：1) 安裝 Playwright MCP；2) /testkit.web.run 指定用例範圍；3) 代理以 AX 樹定位元素（登入、加購物車、結帳）；4) 保存操作記錄與截圖/摘要；5) 若元素不可見，修正標記或等待策略。注意事項：啟用無障礙標記；避免影像辨識模式。最佳實踐：元素命名一致與顯性按鈕控制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, B-Q13, D-Q3

Q9: 如何設計可被 AI 操作的無障礙 Web UI？

• A簡: 用 aria/role/name 清楚標記，保證可見且可操作，避免隱藏交互。
• A詳: 具體步驟：1) 所有關鍵元素標記 role/name/aria-label；2) 按鈕在不可用狀態下隱藏或禁用（如空車不顯示結帳）；3) 一致命名與語義；4) 避免僅靠顏色/位置辨識；5) 測試 AX 樹輸出可讀性。注意事項：可見性與焦點管理。最佳實踐：事先自動檢查可存取性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, B-Q13, D-Q3

Q10: 如何將探索結果導入 SpecKit 生成一致化測試？

• A簡: 合併 OpenAPI、Test Case、Session 示例、內部規範，模板化渲染。
• A詳: 具體步驟：1) 整理規格來源（OpenAPI、decision-table、tc-*.md、session-logs）；2) 設計測試管理規範（報告、命名、配置）；3) SpecKit 合併規格並渲染模板；4) 產出測試程式與配置，接管執行與報告。注意事項：規格一致性；密鑰安全。最佳實踐：把探索示例作為黃金樣本。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q14, A-Q29, D-Q10

Q&A 類別 D: 問題解決類（10題）

Q1: 遇到 AI 測試執行結果不一致怎麼辦？

• A簡: 把探索成果固化為程式，減少重跑；用規格與斷言提升一致性。
• A詳: 症狀：同一用例多次以 AI 直接執行結果不同。原因：上下文飄移、詞彙模糊、環境變動。解法：將探索前置，保存 Session 示例，生成程式承載回歸；加強斷言與資料固定；限制上下文與工具層抽象。預防：標準化規格、減噪、版本化示例。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q14, B-Q10, C-Q7

Q2: Context window 溢出或雜訊過多如何處理？

• A簡: 分層抽象、最小必要上下文、MCP 工具化並保存示例於檔案。
• A詳: 症狀：模型回應漂移、卡頓、成本上升。原因：塞入整份規格/HTML、混入無關訊息。解法：MCP 子層處理規格與認證、ListOperations 提供清單、RunStep 以語義敘述；示例存檔不塞上下文。預防：上下文設計、術語詞彙表、模板化消息。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, B-Q5, B-Q10

Q3: Playwright 找不到按鈕/元素怎麼解？

• A簡: 補齊可存取性標記、確保可見與語義命名一致，避免隱藏交互。
• A詳: 症狀：元素定位失敗、點擊不生效。原因：無 aria/role/name、不可見、動態渲染延時。解法：補標記、顯性控制按鈕（如空車不顯示結帳）、加等待策略；驗證 AX 樹輸出。預防：可存取性檢查、命名規範、顯性狀態提示。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, B-Q12, C-Q9

Q4: 空購物車未被拒絕，如何診斷與修正？

• A簡: 以 API/Web 用例重現，核對期望與實作，補邏輯或 UI 控制。
• A詳: 症狀：空車仍可結帳。原因：API 未實作限制、Web 未禁用按鈕。解法：用 TestKit.API.Run 重現、檢視 Session；API 加檢查拒絕；Web 隱藏結帳或禁用；生成測試程式斷言拒絕行為。預防：決策表標記空車情境、通道一致策略。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q5, C-Q8, B-Q15

Q5: Access token 缺失導致 API 認證失敗怎麼辦？

• A簡: 用 .env/環境變數供 token，客戶端啟動時驗證與注入 Header。
• A詳: 症狀：401/403、請求失敗。原因：未提供或過期 token。解法：CreateSession 正確走 OAuth2、測試程式讀環境變數；在 HttpClient 加 Bearer；在前置檢查 token。預防：密鑰管理、CI 秘密託管、定期刷新。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q7, C-Q6, B-Q15

Q6: Swagger/OpenAPI 太大導致上下文溢出如何處理？

• A簡: 不直塞規格；用子層載入解析，輸出精簡操作清單。
• A詳: 症狀：模型卡頓與成本飆升。原因：整規格塞主代理。解法：MCP 解析規格，ListOperations 提供清單；主代理僅持語義與示例；生成時才讀規格與檔案。預防：分層架構與規格索引。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q10, A-Q28

Q7: 探索步驟耗時過長或卡住怎麼辦？

• A簡: 限制範圍、優先重要用例、改善上下文與工具、分批執行。
• A詳: 症狀：長時間探索、無法前進。原因：上下文噪音、用例過多、元素不可操作。解法：先跑 R1-R6 常規場景；改善無障礙標記；拆分用例批次；在 MCP 增加指引與 QuickStart。預防：優先級計畫、清晰術語、可操作性檢查。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q20, B-Q12, C-Q8

Q8: 覆蓋率不足如何補強？

• A簡: 檢視決策表，加入邊界、違規與混合場景，排序優先。
• A詳: 症狀：重要情境漏測。原因：決策表不完整、未考慮邊界。解法：審核 Criteria/Actions、補最小/最大/超限、混合；用風險/價值排序；生成新用例並探索。預防：規格審核流程與雙人檢算。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q3, B-Q16, C-Q2

Q9: 測試量爆炸導致成本過高怎麼優化？

• A簡: 左移探索與生成，將回歸交給 CPU，降低 GPU Token 成本。
• A詳: 症狀：年度成本高、時間長。原因：每次靠 AI 直接跑。解法：探索一次、生成程式、回歸交 CPU；只在變更時重探索；合併用例與共用 Test Case。預防：成本模型與計畫、批次策略、規格管理。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q13, B-Q20, C-Q7

Q10: 自動化測試不穩定（Flaky）如何處理？

• A簡: 強化斷言、固定資料、封裝客戶端、改善等待與可操作性。
• A詳: 症狀：偶爾失敗。原因：環境不穩、等待不足、資料漂移。解法：封裝客戶端與重試策略；固定範例資料與 token；Web 加可存取性與顯性狀態；報告收斂分析。預防：規格驅動生成（SpecKit）、標準斷言模板、依賴隔離。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, B-Q15, C-Q10

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是 AI-First Testing？
  • A-Q2: AI-First 與傳統測試流程差異？
  • A-Q3: 為什麼不能只把 AI 塞進舊流程？
  • A-Q4: AI-First Testing 的三大步驟是什麼？
  • A-Q5: 什麼是驗收條件（AC）？
  • A-Q6: Decision Table（決策表）是什麼？
  • A-Q7: Test Case 在 AI-First 中如何定義？
  • A-Q13: 什麼是「左移」在 AI 自動化測試中的意義？
  • A-Q14: 為什麼讓 AI 專注「探索」而非「重複執行」？
  • A-Q15: GPU/CPU/Brain 的成本差異？
  • A-Q20: 覆蓋率（Coverage）在 AI-First 中的意義？
  • C-Q1: 如何準備 AC 並用 TestKit.GenTest 生成 Decision Table？
  • C-Q3: 如何用 TestKit 生成所有 Test Case 檔案？
  • D-Q1: 遇到 AI 測試執行結果不一致怎麼辦？
  • D-Q9: 測試量爆炸導致成本過高怎麼優化？
• 中級者：建議學習哪 20 題
  • A-Q8: 什麼是 TestKit？為何需要它？
  • A-Q9: TestKit 提供哪些核心指令？
  • A-Q10: 什麼是 MCP（Model Context Protocol）？
  • A-Q16: 什麼是 Context Engineering？
  • A-Q17: 什麼是 Context Rot（上下文腐壞/雜訊）？
  • A-Q18: API 測試與 Web UI 測試的本質差異？
  • A-Q19: 為何無障礙設計（Accessibility）對 AI 測試重要？
  • A-Q28: OpenAPI Spec 在 AI-First 測試中的角色？
  • B-Q1: AI-First Testing 整體如何運作？
  • B-Q2: TestKit.GenTest 如何從 AC 生成決策表與 Test Case？
  • B-Q3: 如何設計 Decision Table 的 Criteria/Actions？
  • B-Q4: TestKit.API.Run 的執行流程是什麼？
  • B-Q5: MCP 如何抽象化 API 呼叫以降低上下文噪音？
  • B-Q6: ListOperations 如何解析 API 操作？
  • B-Q7: CreateSession 如何建立會話並處理 OAuth2？
  • B-Q9: Session Logs 的結構與內容包含哪些？
  • C-Q4: 如何配置 MCP 以探索 API Test Steps？
  • C-Q5: 如何以 TestKit.API.Run 執行 R1-R6 並記錄 Session？
  • D-Q2: Context window 溢出或雜訊過多如何處理？
  • D-Q3: Playwright 找不到按鈕/元素怎麼解？
• 高級者：建議關注哪 15 題
  • B-Q8: RunStep 如何將自然語言轉為 API 呼叫？
  • B-Q10: 如何管理 Context 以減少噪音並提升成功率？
  • B-Q12: Playwright MCP 的技術架構與特色？
  • B-Q13: Accessibility 標記如何被代理使用？
  • B-Q14: SpecKit 生成測試程式的原理是什麼？
  • B-Q15: API 測試程式（.NET + xUnit）的架構如何設計？
  • B-Q16: 覆蓋與優先級如何計算與排序？
  • B-Q19: 如何跨通道共用 Test Case？
  • B-Q20: 成本估算模型（GPU 時間與 Token 成本）如何評估？
  • C-Q7: 如何用 .NET + xUnit 生成並執行 API 測試程式碼？
  • C-Q8: 如何用 Playwright MCP 執行 Web 測試並記錄？
  • C-Q10: 如何將探索結果導入 SpecKit 生成一致化測試？
  • D-Q6: Swagger/OpenAPI 太大導致上下文溢出如何處理？
  • D-Q10: 自動化測試不穩定（Flaky）如何處理？
  • A-Q29: SDD（Specification-Driven Development）是什麼？