UAT 測試提示詞（用戶驗收測試計劃：端到端業務場景用例、參與人分工、缺陷分級、簽字標準）
業務系統上線前組織業務人員做驗收測試時用：按端到端業務流程設計正常和異常場景，排好誰在哪天測哪條流程，定清缺陷分級和通過標準，生成可直接使用的 UAT 計劃、場景表和缺陷記錄模板。
通用大模型 對話模型通用
你是一名負責驗收階段的測試經理，幫我準備用戶驗收測試（UAT）計劃。UAT 的目的是讓業務人員確認「系統能支撐我的日常工作」，不是把功能測試再做一遍。 系統與本次上線範圍：[系統與上線範圍] 涉及的業務流程：[業務流程清單] 參與部門與可投入的人員：[參與部門與人員] 測試時間窗口：[測試時間窗口] 最終簽字確認的人：[簽字確認人] 請按以下內容編寫： 1. 准入條件：開始 UAT 之前必須滿足什麼（如系統測試已完成且無阻塞缺陷、測試環境與數據就緒、參與人已完成培訓）。任一條不滿足就不開始。 2. 測試場景：按端到端業務流程設計，不按選單功能點。每條流程至少包含一個正常場景和兩個異常場景（如退貨、作廢重開、跨月沖銷、權限不足）。每個場景寫：編號、場景名、執行角色、前置數據、操作步驟要點、預期業務結果、對應的單據或報表。 3. 測試數據：需要準備哪些接近真實的數據（客戶、物料、價格、期初餘額），由誰準備、何時到位。 4. 分工與日程：業務人員執行並記錄結果，項目組只負責答疑和修復，不代替業務人員點「通過」。按天排出各流程由誰測，每天結束開 15 分鐘缺陷碰頭會。 5. 缺陷分級： - 阻塞：流程走不通，且沒有替代做法； - 嚴重：結果錯誤，或要靠大量手工才能繞過； - 一般：有不便，但有簡單的替代做法； - 建議：不影響使用的改進意見。 「這個功能和我想的不一樣」先判定是缺陷還是新需求，新需求走變更流程，不計入缺陷。 6. 通過標準：阻塞與嚴重缺陷全部關閉並經提出人複測通過；一般缺陷有明確的修復日期和臨時做法；場景執行率 100%。我有不同要求時以我為準。 7. 簽字頁：簽字人、簽字範圍、遺留問題清單及處理承諾。 約束：只針對我列出的業務流程設計場景；流程細節不清楚的寫【需業務確認】，不要自行想像業務規則。 輸出：UAT 計劃正文（按上面 7 部分）+ 測試場景表 + 缺陷記錄表模板。
高亮處換成你自己的內容：[系統與上線範圍]、[業務流程清單]、[參與部門與人員]、[測試時間窗口]、[簽字確認人]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[業務流程清單] 按業務的叫法寫，比如「採購入庫到付款」「銷售開單到收款」「月末結帳」，不要寫模組名。[參與部門與人員] 寫清每人每天能投入幾小時，業務人員通常只能半天。[簽字確認人] 提前定好，免得測完了沒人敢籤。
常見失敗與調整：
- 只測正常流程。上線後出問題的多是退貨、改單、作廢這些例外，讓模型每條流程補足異常場景。
- 項目組的人替業務點完了所有用例。UAT 的意義是業務自己確認，代測等於沒測。
- 把新需求當缺陷報，缺陷清單越滾越長、遲遲籤不了字。每條先定性，新需求走變更。
- 用「張三、測試 1」這類數據，真實價格和稅率下的問題暴露不出來。
示例輸出
示例，僅供參考（虛構：某建材經銷商的進銷存系統，UAT 共 5 個工作日）
測試場景表（節選）
| 編號 | 場景 | 執行角色 | 前置數據 | 步驟要點 | 預期業務結果 |
|---|---|---|---|---|---|
| S-01 | 正常銷售出庫 | 銷售內勤 | 客戶「虛構客戶甲」信用額度充足，瓷磚庫存 200 箱 | 開銷售單 50 箱 → 倉庫出庫 → 開票 | 庫存減為 150 箱；應收帳款增加對應金額；出庫單可打印 |
| S-02 | 部分退貨 | 銷售內勤、倉管 | 沿用 S-01 的出庫單 | 客戶退回 5 箱 → 倉庫驗收入庫 → 開紅字發票 | 庫存恢復為 155 箱；應收相應衝減；原銷售單顯示已退 5 箱 |
| S-03 | 超信用額度開單 | 銷售內勤 | 客戶剩餘額度不足 | 開單金額超出額度 | 系統攔截並提示需銷售經理審批，審批後可繼續 |
分工（節選）：第 1–2 天銷售流程（銷售內勤 2 人，每天下午）；第 3 天採購與庫存；第 4 天月末結帳（財務 1 人）；第 5 天複測與簽字。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～