測試驗收

安全測試與弱點掃描報告範本（Security Scan Report Template） 適用標準：OWASP Testing Guide v4.2、CVSS 3.1（Common Vulnerability Scoring System）、CWE 適用階段：測試驗證階段（Testing Phase） 負責角色：AppSec 工程師、資安測試人員、QA Lead 📑 章節目錄 文件資訊 測試摘要 測試範圍與方法 弱點總覽 弱點詳細報告 合規檢核結果 修復計畫 結論與建議 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 安全測試報告 文件編號 [專案代碼]-STR-[版本號]-[日期] 版本 v[X.Y] 測試日期 [YYYY-MM-DD] ~ [YYYY-MM-DD] 測試人員 [AppSec 團隊 / 外部廠商] 審核者 [CISO / 資安主管] 資料分級 Confidential 2. 測試摘要 項目 內容 測試類型 [SAST / DAST / SCA / Penetration Test / 組合] 受測版本 [Application version / Commit hash] 測試結果總評 [✅ PASS / ⚠️ CONDITIONAL PASS / ❌ FAIL] 上線決策 [可上線 / 修復後可上線 / 不可上線] 弱點統計 嚴重度 數量 已修復 待修復 接受風險 Critical [N] [N] [N] [N] High [N] [N] [N] [N] Medium [N] [N] [N] [N] Low [N] [N] [N] [N] Info [N] — — — Total [N] [N] [N] [N] 3. 測試範圍與方法 3.1 測試範圍 項目 內容 目標系統 [系統名稱 + URL/IP] 測試範圍 [In-scope modules / endpoints] 排除範圍 [Out-of-scope，如第三方元件] 認證帳號 [測試用帳號角色清單（不含密碼）] 3.2 測試方法 測試類型 工具 版本 說明 SAST（靜態分析） [SonarQube / Checkmarx / Semgrep] [ver] 原始碼分析 DAST（動態分析） [OWASP ZAP / Burp Suite Pro] [ver] 執行期掃描 SCA（套件分析） [Snyk / OWASP Dependency-Check / Trivy] [ver] 第三方套件弱點 手動測試 [Burp Suite / Custom scripts] — 邏輯弱點 Container Scan [Trivy / Aqua] [ver] 容器映像掃描 3.3 測試依據 標準/指南 涵蓋項目 OWASP Top 10 (2021) A01~A10 OWASP API Security Top 10 (2023) 全部 OWASP ASVS v4.0.3 [Level 1 / Level 2 / Level 3] CWE Top 25 (2023) 常見弱點 4. 弱點總覽 4.1 依嚴重度分佈 嚴重度 CVSS 分數範圍 修復 SLA 數量 Critical 9.0 – 10.0 24 小時 [N] High 7.0 – 8.9 7 天 [N] Medium 4.0 – 6.9 30 天 [N] Low 0.1 – 3.9 90 天 [N] Info 0.0 視需要 [N] 4.2 依類型分佈 弱點類型（CWE） 數量 嚴重度分佈 [CWE-XXX: 弱點名稱] [N] [C:N / H:N / M:N / L:N] [CWE-XXX: 弱點名稱] [N] [C:N / H:N / M:N / L:N] 4.3 依 OWASP Top 10 分佈 OWASP Category 弱點數量 最高嚴重度 A01: Broken Access Control [N] [Critical/High/…] A02: Cryptographic Failures [N] A03: Injection [N] A04: Insecure Design [N] A05: Security Misconfiguration [N] A06: Vulnerable Components [N] A07: Auth Failures [N] A08: Software & Data Integrity [N] A09: Logging & Monitoring Failures [N] A10: SSRF [N] 5. 弱點詳細報告 VULN-[NNN]: [弱點標題] 項目 內容 弱點 ID VULN-[NNN] 嚴重度 [Critical / High / Medium / Low] CVSS 分數 [N.N] CVSS Vector [CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] CWE CWE-[NNN]: [名稱] OWASP [A01 / A02 / …] 發現工具 [SAST / DAST / Manual] 受影響元件 [模組/檔案/API endpoint] 狀態 [Open / Fixed / Accepted / False Positive] 描述： ...

效能測試報告範本（Performance Test Report Template） 適用標準：ISO/IEC/IEEE 29119-3:2021（測試文件）、RFC 2544（Benchmarking） 適用階段：測試驗證階段（Testing Phase） 負責角色：效能測試工程師、QA Lead、SRE 📑 章節目錄 文件資訊 測試摘要 測試環境 測試場景與配置 測試結果 效能瓶頸分析 與 NFR 目標對照 建議與改善方案 結論與決策建議 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 效能測試報告 文件編號 [專案代碼]-PTR-[版本號]-[日期] 版本 v[X.Y] 測試日期 [YYYY-MM-DD] ~ [YYYY-MM-DD] 測試工具 [JMeter / k6 / Locust / Gatling] 測試人員 [姓名] 審核者 [QA Lead / SA] 2. 測試摘要 項目 內容 測試類型 [負載測試 / 壓力測試 / 耐久測試 / 容量測試] 測試目的 [驗證系統在預期負載下的回應時間與吞吐量] 測試範圍 [被測試的模組/API/頁面] 測試結果總評 [✅ PASS / ⚠️ CONDITIONAL PASS / ❌ FAIL] 關鍵發現 [一句話總結] 3. 測試環境 3.1 系統架構 元件 規格 數量 備註 Application Server [CPU/Memory/Instance Type] [N] Database Server [CPU/Memory/Type] [N] Cache [Type/Memory] [N] Load Balancer [Type] [N] 3.2 環境差異說明 項目 測試環境 生產環境 比例 App 節點數 [N] [M] 1:[ratio] DB 規格 [spec] [spec] 1:[ratio] 資料量 [N] rows [M] rows (est.) 1:[ratio] ⚠️ 注意：測試結果需依環境比例換算評估生產環境表現 ...

測試報告範本（Test Report） 參照標準：ISO/IEC/IEEE 29119-3:2021（Test Completion Report） 文件用途：彙整測試執行結果，評估軟體品質，提供上線/不上線的決策依據 適用階段：測試驗證階段（Testing Phase）— Test Completion 📋 章節目錄 文件資訊 執行摘要 測試範圍 測試環境 測試執行結果 缺陷分析 覆蓋率分析 風險與未解決項目 品質評估與建議 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TR-{專案代碼}-{迭代/版本}-{序號} 文件名稱 {系統名稱} 測試報告 版本 v{主版本}.{次版本} 測試版本 {受測軟體版本號} 測試類型 單元/整合/系統/UAT/回歸/效能/安全 測試週期 {YYYY-MM-DD} ~ {YYYY-MM-DD} 撰寫者 {QA 負責人} 審核者 {PM/Tech Lead} 發佈日期 {YYYY-MM-DD} 📖 使用說明 每個重要測試里程碑（Sprint 結束、版本發佈前）產出測試報告 測試類型依實際執行的測試活動填寫，可為複合型（如「系統 + 效能」） 測試版本需明確對應 Git Tag / Build Number，確保可追溯 💡 範例 項目 內容 文件編號 TR-HRM-v2.1-001 系統名稱 人力資源管理系統 測試版本 v2.1.0-rc.1 (Build #487) 測試類型 系統測試 + 回歸測試 + 效能測試 測試週期 2026-05-01 ~ 2026-05-15 2. 執行摘要 📝 範本 2.1 整體結論 項目 結果 上線建議 ✅ 建議上線 / ⚠️ 有條件上線 / ❌ 不建議上線 品質等級 優良 / 合格 / 不合格 主要風險 {簡述主要殘餘風險} 2.2 關鍵指標概覽 指標 數值 目標 達標 測試案例通過率 {%} ≥ {%} ✅/❌ 缺陷密度（Defect/KLOC） {N} ≤ {N} ✅/❌ 嚴重缺陷（Critical/High）未解決 {N} 0 ✅/❌ 需求覆蓋率 {%} ≥ {%} ✅/❌ 程式碼覆蓋率 {%} ≥ {%} ✅/❌ 效能指標達標率 {%} 100% ✅/❌ 📖 使用說明 執行摘要是最重要的章節，決策者可能只看這部分 上線建議需有客觀數據支持，非主觀判斷 「有條件上線」需明確列出條件（如：特定功能暫不開放、需加監控） 關鍵指標的目標值應在測試計畫中事先定義 💡 範例 2.1 整體結論 項目 結果 上線建議 ⚠️ 有條件上線 品質等級 合格 主要風險 2 個 Medium 缺陷待修、大量匯出效能未達標 2.2 關鍵指標概覽 指標 數值 目標 達標 測試案例通過率 96.8% ≥ 95% ✅ 缺陷密度 2.3/KLOC ≤ 5/KLOC ✅ 嚴重缺陷未解決 0 0 ✅ 需求覆蓋率 98% ≥ 95% ✅ 程式碼覆蓋率 82% ≥ 80% ✅ 效能指標達標率 90% 100% ❌ 3. 測試範圍 📝 範本 3.1 測試項目（In Scope） 模組/功能 測試類型 優先級 執行狀態 {模組名稱} {測試類型} 高/中/低 完成/部分/未執行 3.2 排除項目（Out of Scope） 模組/功能 排除原因 {模組名稱} {原因} 📖 使用說明 明確列出本次測試涵蓋與不涵蓋的範圍 排除原因需合理（如：未修改的模組、下一版本範圍） 執行狀態若為「部分」或「未執行」，需在風險章節說明影響 💡 範例 3.1 測試項目 模組/功能 測試類型 優先級 執行狀態 員工資料管理（CRUD） 系統測試 + 回歸 高 完成 薪資計算引擎 系統測試 + 回歸 高 完成 請假/加班申請流程 系統測試 + 回歸 高 完成 報表匯出（PDF/Excel） 系統測試 + 效能 中 完成 SSO 登入整合 整合測試 高 完成 API 效能（並發） 效能測試 中 完成 3.2 排除項目 模組/功能 排除原因 行動 App v2.2 規劃範圍，本版未開發 第三方薪轉介接（銀行 API） 銀行端 UAT 環境未就緒 4. 測試環境 📝 範本 項目 規格 環境名稱 {SIT/UAT/Staging/Performance} 作業系統 {OS 版本} 應用伺服器 {Server + 版本} 資料庫 {DB + 版本} 測試資料 {描述：模擬資料量/來源} 測試工具 {工具清單} 與正式環境差異 {列出差異} 📖 使用說明 測試環境資訊確保結果可重現 必須列出與正式環境的差異（差異可能影響結果有效性） 效能測試環境應盡量接近正式規格 💡 範例 項目 規格 環境名稱 Staging (Azure AKS) 作業系統 Ubuntu 22.04 (K8s Node) 應用伺服器 .NET 8 Kestrel + Kong 3.5 資料庫 PostgreSQL 16.2 (Azure Database) 測試資料 模擬 10,000 員工、3 年歷史資料 測試工具 xUnit, Playwright, JMeter 5.6, SonarQube 與正式環境差異 節點數 3（正式 6）、資料量為正式 20% 5. 測試執行結果 📝 範本 5.1 測試案例執行統計 狀態 數量 百分比 通過（Pass） {N} {%} 失敗（Fail） {N} {%} 阻塞（Blocked） {N} {%} 未執行（Not Run） {N} {%} 總計 {N} 100% 5.2 按模組分佈 模組 總案例 通過 失敗 阻塞 通過率 {模組} {N} {N} {N} {N} {%} 5.3 效能測試結果（如適用） 場景 指標 目標 實際 達標 {場景} {指標} {目標值} {實際值} ✅/❌ 📖 使用說明 統計數據需與測試管理工具（如 Azure DevOps Test Plan）數據一致 失敗案例需逐一追蹤到缺陷 ID 阻塞案例需說明阻塞原因（環境問題？依賴未就緒？） 效能測試報告重點指標：回應時間、吞吐量、錯誤率 💡 範例 5.1 測試案例執行統計 狀態 數量 百分比 通過（Pass） 242 96.8% 失敗（Fail） 5 2.0% 阻塞（Blocked） 2 0.8% 未執行（Not Run） 1 0.4% 總計 250 100% 5.2 按模組分佈 模組 總案例 通過 失敗 阻塞 通過率 員工資料管理 65 64 1 0 98.5% 薪資計算 80 78 2 0 97.5% 請假/加班 55 54 0 1 98.2% 報表匯出 30 28 2 0 93.3% SSO 登入 20 18 0 1 90.0%* 5.3 效能測試結果 場景 指標 目標 實際 達標 登入（100 concurrent） P95 回應時間 ≤ 500ms 320ms ✅ 員工查詢（200 concurrent） P95 回應時間 ≤ 1000ms 780ms ✅ 薪資計算批次（10,000筆） 總處理時間 ≤ 5min 3.2min ✅ 報表匯出（5,000筆 Excel） 回應時間 ≤ 30s 45s ❌ API 持續壓力（1hr, 500 TPS） 錯誤率 ≤ 0.1% 0.05% ✅ 6. 缺陷分析 📝 範本 6.1 缺陷統計 嚴重度 發現 已修復 未修復 已驗證 Critical {N} {N} {N} {N} High {N} {N} {N} {N} Medium {N} {N} {N} {N} Low {N} {N} {N} {N} 總計 {N} {N} {N} {N} 6.2 缺陷明細（未解決） 缺陷 ID 嚴重度 模組 描述 狀態 處置方式 {ID} {等級} {模組} {描述} {狀態} 下版修復/暫時方案/接受 6.3 缺陷趨勢 累計發現 vs 累計解決 趨勢圖（收斂曲線） 📖 使用說明 Critical/High 未解決 = 不建議上線（除非有合理的暫時方案） 缺陷趨勢圖需呈現「收斂」趨勢（發現率下降、解決追上發現） 缺陷明細只列未解決的，已解決的在附錄提供完整清單 處置方式需經 PM/Tech Lead 核准 💡 範例 6.1 缺陷統計 嚴重度 發現 已修復 未修復 已驗證 Critical 1 1 0 1 High 3 3 0 3 Medium 8 6 2 6 Low 5 3 2 3 總計 17 13 4 13 6.2 缺陷明細（未解決） 缺陷 ID 嚴重度 模組 描述 狀態 處置方式 BUG-142 Medium 報表匯出 Excel 匯出超過 5000 筆時超時 (45s > 30s) Open v2.2 修復（分頁匯出） BUG-145 Medium 報表匯出 PDF 頁首日期格式錯誤 Open v2.1.1 Hotfix BUG-148 Low 員工管理 姓名超過 50 字元時 UI 顯示截斷 Open v2.2 修復 BUG-150 Low 薪資計算 計算說明欄位未支援多語系 Open v2.2 修復 7. 覆蓋率分析 📝 範本 7.1 需求覆蓋率 需求類型 總需求數 已覆蓋 未覆蓋 覆蓋率 功能需求（FR） {N} {N} {N} {%} 非功能需求（NFR） {N} {N} {N} {%} 安全需求（SEC） {N} {N} {N} {%} 7.2 程式碼覆蓋率 模組 行覆蓋率 分支覆蓋率 方法覆蓋率 {模組} {%} {%} {%} 📖 使用說明 需求覆蓋率：確保每個需求至少有一個測試案例覆蓋 程式碼覆蓋率：通常由 CI/CD 工具（SonarQube、Istanbul）自動產出 目標值：需求覆蓋率 ≥ 95%、行覆蓋率 ≥ 80%、分支覆蓋率 ≥ 70% 未覆蓋的需求需說明原因 💡 範例 7.1 需求覆蓋率 需求類型 總需求數 已覆蓋 未覆蓋 覆蓋率 功能需求（FR） 45 44 1* 97.8% 非功能需求（NFR） 12 12 0 100% 安全需求（SEC） 40 38 2** 95% *FR-032（行動 App 推播）排除於本版 **SEC-SESS-005、SEC-COMM-004 為建議等級，計畫 v2.2 驗證 ...

測試案例範本（Test Case Template） 參照標準：ISO/IEC/IEEE 29119-3:2021（取代 IEEE 829-2008）/ ISO/IEC/IEEE 29119-4:2021（Test Techniques） 文件用途：定義測試案例的標準格式，確保測試設計完整、可追溯、可重複執行 適用階段：測試設計與執行階段 📋 章節目錄 文件資訊 測試案例識別規範 測試案例格式定義 測試案例撰寫規範 測試案例分類 測試案例清單範本 測試案例詳細格式 測試資料規劃 測試執行紀錄 缺陷報告格式 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TC-{專案代碼}-{模組}-{序號} 文件名稱 {系統名稱} {模組名稱} 測試案例 版本 v{主版本}.{次版本} 對應測試計畫 {TP 文件編號} 對應需求 {FRD 文件編號} 撰寫者 {姓名} 審核者 {姓名} 建立日期 {YYYY-MM-DD} 📖 使用說明 測試案例文件承接測試計畫（Test Plan），為各測試項目設計具體的驗證步驟 每個功能模組可獨立一份測試案例文件，或匯整於單一文件中 文件需經 QA Lead 或測試經理審核後方可執行 💡 範例 項目 內容 文件編號 TC-HRM-LV-001 文件名稱 HRMS 假勤管理模組 測試案例 對應測試計畫 TP-HRM-001 對應需求 FRD-HRM-001 v2.1 2. 測試案例識別規範 📝 範本 2.1 編號規則 TC-{專案}-{模組}-{序號} 欄位 說明 範例 TC 固定前綴（Test Case） TC {專案} 專案代碼（2-5 字元） HRM {模組} 模組縮寫（2-5 字元） LV（Leave） {序號} 三位數流水號 001 2.2 命名規範 測試案例名稱格式：[測試類型] {功能描述} - {情境描述} ...

測試計畫範本（Test Plan） 參照標準：ISO/IEC/IEEE 29119-3:2021（取代 IEEE 829-2008） 文件用途：定義測試範圍、策略、資源、時程與風險，指導整體測試活動 適用階段：測試準備階段（Test Planning Phase） 📋 章節目錄 文件資訊 測試計畫識別 引言 測試項目 測試策略與方法 通過與失敗標準 暫停與恢復準則 測試交付物 測試環境需求 職責分工 時程與里程碑 風險與緩解措施 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TP-{專案代碼}-{序號} 文件名稱 {系統名稱} 測試計畫 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 對應 FRD {FRD 文件編號} 測試層級 {Unit / Integration / System / UAT} 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初版建立 📖 使用說明 依據 ISO/IEC/IEEE 29119-3:2021 第 7 節「Test Plan documentation」 測試計畫可依測試層級分開撰寫（如 SIT 測試計畫、UAT 測試計畫） 一個專案可有多份測試計畫，也可合併為一份主測試計畫（Master Test Plan） 💡 範例 項目 內容 文件編號 TP-HRM-001 文件名稱 人力資源管理系統 系統整合測試計畫 測試層級 System Integration Test (SIT) 對應 FRD FRD-HRM-001 v2.1 2. 測試計畫識別 📝 範本 項目 內容 專案名稱 {專案正式名稱} 受測系統 {系統名稱及版本} 測試階段 {SIT / UAT / Performance / Security} 測試期間 {起始日期} ~ {結束日期} 測試團隊 {團隊名稱} 📖 使用說明 明確識別「測什麼」、「測多久」、「誰來測」 測試期間需與專案整體時程對齊 💡 範例 項目 內容 專案名稱 人力資源管理系統建置專案 受測系統 HRMS v1.0.0 測試階段 SIT（系統整合測試） 測試期間 2026-09-01 ~ 2026-09-30 測試團隊 QA 品質保證組 3. 引言 📝 範本 3.1 測試目的 {描述本次測試活動的目標} ...

測試策略制定範本 Prompt 目標 指導 AI 制定全面的軟體測試策略，涵蓋各種測試類型和測試方法。 角色設定 你是一位資深測試架構師和品質保證專家，具備豐富的測試策略規劃經驗，熟悉各種測試方法論和自動化測試框架。 任務描述 請協助我為 {專案名稱} 制定完整的測試策略。 專案測試背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 技術棧: {填入主要技術棧} 團隊規模: {填入開發團隊人數} 專案時程: {填入專案開發週期} 品質要求: {填入品質標準要求} 測試策略要求 請按照以下結構制定測試策略： 1. 測試目標和範圍 測試目標定義 測試範圍界定 品質標準設定 風險評估分析 2. 測試類型規劃 功能測試策略 非功能測試策略 安全測試策略 相容性測試策略 3. 測試層級設計 單元測試策略 整合測試策略 系統測試策略 驗收測試策略 4. 自動化測試規劃 自動化測試範圍 工具選型評估 框架架構設計 CI/CD 整合規劃 5. 測試環境規劃 測試環境需求 資料管理策略 環境配置管理 監控和維護計畫 6. 測試執行計畫 測試階段規劃 資源分配計畫 時程安排規劃 風險應對計畫 輸出格式 # {專案名稱} 測試策略文檔 ## 1. 測試概覽 ### 1.1 測試目標 **主要目標:** - 確保系統功能符合需求規格 - 驗證系統效能達到預期標準 - 保證系統安全性和穩定性 - 提升產品品質和使用者體驗 **品質目標:** - 功能覆蓋率: ≥ 95% - 程式碼覆蓋率: ≥ 80% - 缺陷逃逸率: ≤ 5% - 自動化測試比例: ≥ 70% ### 1.2 測試範圍 #### 包含範圍 - 所有核心業務功能 - 使用者介面和用戶體驗 - API 介面和資料交換 - 系統整合和第三方服務 - 安全性和權限控制 - 效能和可擴展性 #### 排除範圍 - 第三方組件內部邏輯 - 作業系統層級功能 - 網路基礎設施 - 瀏覽器內建功能 ### 1.3 品質標準 | 品質特性 | 標準 | 測量方法 | |----------|------|----------| | 功能性 | 95% 需求符合度 | 測試案例通過率 | | 可靠性 | 99.9% 系統可用性 | 系統監控數據 | | 效能 | 響應時間 < 2秒 | 效能測試報告 | | 易用性 | 8/10 使用者滿意度 | 使用者測試回饋 | | 安全性 | 0 高風險漏洞 | 安全掃描報告 | ## 2. 測試類型策略 ### 2.1 功能測試 #### 2.1.1 單元測試 **目標:** 驗證個別程式碼單元的正確性 **覆蓋率要求:** ≥ 80% **工具:** JUnit 5, Mockito, AssertJ **責任歸屬:** 開發人員 **測試重點:** - 業務邏輯正確性 - 邊界值處理 - 異常情況處理 - 資料驗證邏輯 #### 2.1.2 整合測試 **目標:** 驗證模組間介面和資料流 **類型:** - API 整合測試 - 資料庫整合測試 - 第三方服務整合測試 **工具:** TestContainers, WireMock, REST Assured #### 2.1.3 系統測試 **目標:** 驗證完整系統功能 **測試類型:** - 端對端功能測試 - 業務流程測試 - 使用案例驗證 **工具:** Selenium WebDriver, Cucumber ### 2.2 非功能測試 #### 2.2.1 效能測試 **測試類型:** - 負載測試: 正常負載下的系統表現 - 壓力測試: 超過正常負載的系統表現 - 容量測試: 系統處理能力上限 - 耐久性測試: 長時間運行的穩定性 **效能指標:** - 響應時間: 95% 請求 < 2秒 - 吞吐量: > 1000 TPS - 並發使用者: > 5000 - 資源使用率: CPU < 80%, Memory < 85% **工具:** JMeter, Gatling, K6 #### 2.2.2 安全測試 **測試範疇:** - 身份驗證和授權測試 - 輸入驗證和 SQL 注入防護 - 跨站腳本攻擊 (XSS) 防護 - 跨站請求偽造 (CSRF) 防護 - 敏感資料保護 **工具:** OWASP ZAP, Burp Suite, SonarQube Security #### 2.2.3 相容性測試 **瀏覽器相容性:** - Chrome (最新版本及前2版) - Firefox (最新版本及前2版) - Safari (最新版本及前1版) - Edge (最新版本及前2版) **作業系統相容性:** - Windows 10/11 - macOS (最新版本及前2版) - Ubuntu LTS **裝置相容性:** - 桌面電腦 (1920x1080 以上) - 平板電腦 (768x1024) - 手機 (375x667 以上) ## 3. 測試自動化策略 ### 3.1 自動化測試金字塔 ┌─────────────────┐ │ UI Tests │ ← 少量 (10%) │ (E2E Tests) │ ├─────────────────┤ │ Integration │ ← 中等 (30%) │ Tests │ ├─────────────────┤ │ Unit Tests │ ← 大量 (60%) │ │ └─────────────────┘ ### 3.2 自動化工具選型 #### 單元測試框架 **選擇:** JUnit 5 + Mockito **理由:** - 成熟穩定的 Java 測試框架 - 豐富的斷言和模擬功能 - 良好的 IDE 整合支援 - 活躍的社群和文檔 #### 整合測試工具 **API 測試:** REST Assured **資料庫測試:** TestContainers **模擬服務:** WireMock #### UI 自動化工具 **選擇:** Selenium WebDriver + Page Object Model **輔助工具:** WebDriverManager, Extent Reports ### 3.3 CI/CD 整合 #### 持續整合流程 程式碼提交 → 靜態分析 → 單元測試 → 建置 → 整合測試 → 部署測試環境 → E2E測試 → 產生報告 ...

自動化測試範本 Prompt 目標 指導 AI 建立完整的自動化測試框架，包含各層級的自動化測試實作。 角色設定 你是一位資深自動化測試工程師，具備豐富的測試框架設計和實作經驗，熟悉各種自動化測試工具和最佳實務。 任務描述 請協助我為 {專案名稱} 建立完整的自動化測試框架和測試案例。 專案自動化背景 專案名稱: {填入專案名稱} 應用類型: {填入應用類型，如：Web應用、API服務、微服務} 技術棧: {填入技術棧，如：Spring Boot + React、.NET Core + Angular} 測試目標: {填入自動化測試目標} 現有工具: {填入現有的測試工具和框架} 自動化測試要求 請按照以下結構建立自動化測試： 1. 測試框架設計 框架架構設計 工具選型評估 專案結構規劃 配置管理設計 2. 單元測試自動化 測試類別設計 Mock 策略規劃 測試資料準備 斷言策略設計 3. 整合測試自動化 API 測試框架 資料庫測試設計 外部服務模擬 契約測試實作 4. UI 測試自動化 Page Object 模式 元素定位策略 測試資料驅動 跨瀏覽器測試 5. CI/CD 整合 測試執行策略 報告生成機制 失敗處理流程 測試結果分析 6. 維護和擴展 測試程式碼品質 框架擴展性設計 效能最佳化 文檔和培訓 輸出格式 # {專案名稱} 自動化測試框架 ## 1. 框架架構設計 ### 1.1 整體架構圖 測試執行層 ├── UI Tests (Selenium/Playwright) ├── API Tests (REST Assured/Postman) └── Unit Tests (JUnit/TestNG) | 測試工具層 ├── 測試資料管理 ├── 測試環境配置 └── 測試報告生成 | 基礎設施層 ├── CI/CD 整合 (Jenkins/GitHub Actions) ├── 測試環境管理 (Docker/K8s) └── 測試資料庫 (TestContainers) ...