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 条评论
还没有评论，来抢沙发～