name: test-plan-generator description: 根據 PRD、需求說明、使用者故事、介面說明或釋出範圍，生成結構化測試計劃、測試策略、範圍、排期、風險、准入準出和評審清單。適用於測試計劃、測試方案、迴歸計劃、驗收測試、QA plan、test strategy 等場景。

測試計劃生成 Skill

觸發場景

當用戶提出以下需求時使用本 Skill： - “幫我寫測試計劃 / 測試方案 / QA plan / test plan” - “根據 PRD 生成測試計劃” - “這個版本怎麼測 / 迴歸怎麼安排 / 驗收測試怎麼做” - “給介面/功能/小程式/App/後臺系統做測試策略” - “上線前測試範圍、風險、准入準出怎麼定”

能力定位

擅長做

• 將 PRD、使用者故事、介面說明、迭代範圍轉成可執行測試計劃。
• 輸出測試目標、範圍、非範圍、策略、環境、資料、資源排期、風險、准入準出、待確認項。
• 按風險優先順序安排冒煙、功能、迴歸、相容、效能、安全、驗收測試。
• 在資訊不完整時生成假設、待確認問題和降級版計劃。

謹慎做

• 對缺少需求、排期、人員、環境的資料，不強行給確定結論，必須標註假設。
• 對金融、醫療、支付、安全等高風險系統，必須提示需要專業測試負責人複核。
• 對效能、安全、合規測試，只給計劃和檢查方向，不替代專項測試報告。

不能做

• 不能承諾“零缺陷”“一定可上線”。
• 不能憑空編造已評審、已通過、已修復等事實。
• 不能輸出含真實賬號、手機號、身份證、金鑰、生產資料的測試資料。

輸入路由

工作流程

1. 澄清背景：識別專案、版本、目標使用者、上線時間、輸入材料和關鍵約束。
2. 拆解範圍：列出測試範圍、非測試範圍、優先順序和影響面。
3. 選擇策略：按風險選擇冒煙、功能、迴歸、介面、相容、效能、安全、驗收等策略。
4. 設計資源排期：列階段、起止時間、人天/工時、角色、負責人、依賴、交付物和緩衝。
5. 識別風險：輸出風險等級、觸發訊號、緩解措施、應急/回滾方案、負責人和是否阻塞上線。
6. 定義准入準出：給出可驗證、量化的進入測試與退出測試標準。
7. 生成待確認項：按優先順序、阻塞屬性、預設假設和未確認處理策略列問題。
8. 自檢交付：用評審清單檢查覆蓋範圍、風險、排期、資源、准入準出和隱私合規。

標準輸出結構

1. 背景與目標

• 專案/版本：

  7w4.net收錄了海量優質技能外掛。

• 輸入依據：PRD / 使用者故事 / 介面說明 / 釋出清單 / 口述需求
• 測試目標：
• 關鍵約束：上線時間、人員、環境、依賴系統
• 重要假設：

2. 測試範圍

3. 非測試範圍

4. 測試策略

5. 環境、資料與依賴

6. 資源與排期

資源不足時優先順序裁剪：P0 核心鏈路 > 上線阻塞風險 > 高頻路徑 > 歷史高發缺陷 > 低頻擴充套件場景。

7. 風險與應對

8. 准入與準出標準

准入示例 - 需求評審完成，核心驗收標準明確。 - 測試環境可用，關鍵依賴聯調完成。 - 主流程冒煙通過率 100%。 - 測試賬號、測試資料、許可權和配置準備完成且已脫敏。

準出示例 - P0 缺陷為 0。 - P1 缺陷全部關閉，或有書面豁免和風險接受人。 - 核心用例通過率 100%，整體用例通過率達到約定閾值。 - 效能/安全/相容等釋出要求達標，或風險已被業務/技術負責人接受。 - 上線驗證項、監控項和回滾預案完成。

9. 缺失資訊與待確認項

10. 交付物清單

11. 評審檢查表

• 範圍與非範圍是否明確。
• 高風險、高價值、高頻路徑是否覆蓋。
• 資源排期是否含人天、依賴、緩衝和完成標準。
• 風險是否含觸發訊號、應急方案、負責人和上線阻塞判斷。
• 准入準出是否量化、可驗證。
• 測試資料是否脫敏，是否避免生產敏感資訊。
• 待確認項是否有優先順序、阻塞屬性和截止時間。

降級與錯誤處理

• 輸入不足：先輸出“基於當前資訊的輕量測試計劃”，並列出至少 5 個待確認問題。
• 範圍衝突：分別列出使用者給定範圍、推斷範圍和需確認範圍。
• 時間不足：說明裁剪原則，優先保障核心鏈路、阻塞風險和高頻迴歸。
• 缺少人員：給出最低可執行方案和風險提示。
• 存在敏感資料：先脫敏再引用，如 {使用者手機號}、{生產賬號}。

質量驗收標準

交付的測試計劃必須滿足： - 至少包含目標、範圍、策略、環境資料、資源排期、風險、准入準出、待確認項。 - 每個核心模組至少有測試點、優先順序和驗收依據。 - 風險表至少包含風險等級、緩解措施、負責人、是否阻塞上線。 - 排期表至少包含起止時間、人天/工時、角色、依賴、輸出、完成標準。 - 准入準出至少有 3 條可量化或可驗證標準。 - 明確標註假設，不編造未提供的資訊。

FAQ

1. 沒有 PRD 能生成嗎？ 可以，但必須輸出輕量版計劃和待確認問題。
2. 能直接寫測試用例嗎？ 可以先生成測試計劃，再按模組繼續生成測試用例。
3. 能用於敏捷迭代嗎？ 可以，按 Sprint 目標、使用者故事和 DoD 生成迭代測試計劃。
4. 能用於介面測試嗎？ 可以，重點覆蓋欄位、鑑權、異常、冪等、限流和效能。
5. 能用於上線前回歸嗎？ 可以，按變更影響面、核心鏈路、歷史缺陷和冒煙路徑組織。
6. 能保證沒有缺陷嗎？ 不能，只能通過風險策略提升覆蓋質量。

反模式

• 只列測試點，不給範圍、風險、排期和准入準出。
• 未標註假設，直接把不確定資訊寫成事實。
• 用“全部測試通過”替代量化標準。
• 忽略環境、資料、依賴和人員約束。
• 使用真實生產敏感資料作為測試資料。

references

• references/test-plan-template.md：完整測試計劃模板。
• references/risk-strategy.md：風險識別方法與風險表字段規範。
• references/risk-and-strategy.md：常見風險庫與測試策略選擇示例。
• references/review-checklist.md：評審檢查清單。
• references/faq.md：常見問題。
• references/anti-patterns.md：反模式。
• references/trace-self-check.md：TRACE 自檢記錄。

這個 Skill 質量較好，結構規範、邏輯清晰。最大的優點是覆蓋場景全面，從需求文件到一句話需求都能處理；輸出模板標準化，包含範圍、風險、排期、准入準出等完整要素；降級機制合理，資訊不足時也能給出有價值的結果。不足之處是缺少使用示例，新手難以快速判斷效果；另外部分指導內容可以更詳細。總體而言，這是一個成熟度較高、可以直接用於實際工作的 Skill。