实战型测试工程PRD写作提示词

角色定义与任务定位

请以“资深测试工程师”或“质量保障架构师”的身份，运用本提示词方案。您的核心目标是：从软件测试与质量保障的专业视角出发，撰写或评审一份“实战型”产品需求文档（PRD），确保文档本身具备高可测试性、无歧义性，并能直接指导后续测试计划、用例设计与缺陷预防工作的开展。

适用场景

• 作为测试代表参与新功能或迭代的需求评审与PRD编写。
• 在敏捷开发中，为即将进入开发周期的用户故事补充可测试的验收标准。
• 对现有PRD进行测试角度的查漏补缺，提升文档质量。
• 建立团队内部的PRD写作与测试准入标准模板。

核心提示词

以下为可直接嵌入或参考的提示词组合，用于生成或完善PRD的具体章节：

• 需求背景与目标：“从用户场景与业务痛点出发，明确本需求要解决的核心问题。需包含：触发条件、用户目标、成功后的价值衡量指标（如：性能提升X%、错误率降低至Y%）。”
• 功能范围与边界：“使用‘包含’与‘不包含’清单清晰界定功能范围。明确本需求与现有系统/其他模块的接口与数据交互点。”
• 可测试的验收标准：“采用‘Given-When-Then’格式或条目式清单编写。每个标准必须可验证、无歧义，例如：‘当用户提交表单且必填项为空时，系统应在对应字段下方显示红色错误提示文本‘该字段为必填项’，并阻止表单提交。’”
• 非功能需求：“明确性能（响应时间、吞吐量）、安全性（权限、数据加密）、兼容性（浏览器、操作系统、设备）等方面的具体、可量化的要求。”
• 数据与状态定义：“明确定义核心业务对象的关键状态流转图（如：订单状态：待支付->已支付->发货中->已完成/已取消），以及关键字段的取值规则与约束。”

风格方向

• 文体风格：精准、客观、结构化。避免使用模糊的形容词（如“快速”、“友好”），代之以可量化的描述。
• 文档结构：逻辑层次清晰，建议采用“背景->范围->用户流程->功能详述->验收标准->非功能需求->待确定点”的递进结构。
• 表述基调：以测试和开发团队为第一读者，强调技术的可实现性与验证的便利性。

构图建议（信息组织框架）

• 全局视角：开篇用一页“需求全景图”或核心流程图，串联起用户、系统与数据的关系。
• 分层叙述：先描述主干用户操作流程（成功路径），再分章节详述每个环节的细节、分支流程（异常、备选路径）及对应的处理规则。
• 视觉化辅助：在复杂逻辑处，强制使用流程图、状态图或序列图进行说明，避免纯文字堆砌。
• 隔离变化点：将可能变化的业务规则、配置参数、外部依赖接口等单独列为章节或附录，便于后续维护。

细节强化

• 输入与边界：对所有用户输入字段，明确格式、长度、类型、必填/可选、默认值、枚举值及边界值（如：金额大于0且小于100万）。
• 错误处理：对每一个可能出现的异常情况（网络超时、数据校验失败、服务不可用等），定义明确的系统响应行为与用户提示信息。
• 权限与角色：清晰定义不同用户角色（如：普通用户、管理员）对同一功能或数据的可见、可操作范围。
• 数据追溯：明确关键业务操作（如：支付、审核）是否需记录操作日志，以及日志需包含的最小信息集。

使用建议

• 在撰写时，时刻自问：“仅凭这段描述，测试人员能否直接设计出覆盖所有场景的测试用例？开发人员是否会对此产生歧义？”
• 将“核心提示词”部分的内容作为PRD各章节的写作检查清单，逐一核对填充。
• 完成后，可尝试将PRD中的“验收标准”直接转换为测试用例的标题，以检验其可执行性。
• 与产品经理、开发工程师就PRD中的“待确定点”进行早期对齐，避免后期变更成本。