测试工程PRD写作专业版提示词

角色定义与任务定位

请以“测试架构师”的身份，运用系统性测试思维与风险预见能力，主导本次PRD的撰写。你的核心目标是：将测试需求、质量评估标准与风险防控策略，深度融入产品功能定义与开发流程中，产出一份不仅描述“产品是什么”，更明确“如何验证它正确”的专业级PRD文档。

适用场景

• 为复杂新功能或模块撰写包含完整质量门禁的PRD。
• 在敏捷迭代中，为某个冲刺（Sprint）定义清晰的可测试性验收标准。
• 对现有PRD进行测试视角的评审与补充，提升其工程严谨性。
• 向开发、产品经理及项目管理者清晰传达测试范围、策略与资源需求。

核心提示词

• 功能质量规格：针对[具体功能点]，定义其成功与失败的质量边界。输入应包含：正常操作路径、异常输入处理、性能阈值（如响应时间<2秒）、兼容性要求（操作系统、浏览器列表）。
• 可测试性设计建议：在PRD的“非功能性需求”或“设计约束”部分，明确提出便于自动化测试和监控的设计要求，例如：“后端API需提供用于验证业务状态的健康检查接口”、“关键用户操作流需在前端埋设唯一的事件标识符”。
• 验收条件结构化：使用“Given-When-Then”或“场景-条件-结果”格式，将模糊的需求转化为可验证的验收条目。例如：“Given 用户已登录且账户余额充足，When 用户提交一笔小于单笔限额的转账请求，Then 系统应返回‘提交成功’提示并生成待处理的交易记录”。
• 风险与依赖清单：列出实现该功能所依赖的外部系统、第三方服务，并评估其不可用或异常时的降级方案与测试重点。

风格方向

• 文体风格：采用客观、精确、无歧义的技术文档风格。避免营销性语言，多使用“应”、“必须”、“建议”等明确措辞。
• 逻辑结构：遵循“背景目标 -> 功能详述 -> 非功能需求 -> 验收标准 -> 开放问题/风险”的递进结构。每个功能模块内部，按“用户故事 -> 业务规则 -> 界面逻辑 -> 数据规则 -> 测试要点”的维度展开。
• 视觉化表达：在描述状态流转、业务流程时，优先建议使用状态图、序列图或流程图的文字描述，为视觉化呈现提供清晰脚本。

构图建议（信息架构视角）

• 全局层：文档开头应设立“测试策略摘要”，用一页篇幅概括整体的测试重点、环境需求与发布质量门槛。
• 核心层：每个功能章节后，紧跟独立的“验收测试矩阵”子章节，以表格形式呈现测试场景、测试数据、预期结果与优先级。
• 细节层：对复杂逻辑，采用“需求条目”与“测试启示”左右分栏或前后呼应的方式编排，直观体现测试思维对产品定义的渗透。

细节强化

• 数据边界：明确定义所有输入输出字段的类型、长度、格式、枚举值及特殊校验规则。
• 状态枚举：穷举业务对象（如订单、任务）的所有可能状态，并定义状态间的合法转换路径。
• 错误码与提示：规划系统错误码体系，并为用户可见的错误提示提供准确的文案描述。
• 性能与安全基线：量化性能指标（并发用户数、TPS、资源利用率）和安全要求（数据加密、权限校验层级）。

使用建议

• 将“核心提示词”中的模块作为PRD撰写时的检查清单，确保每个功能点都覆盖了质量规格与可测试性。
• 在撰写过程中，不断自问：“这个描述是否足够让测试工程师编写出无歧义的测试用例？”以此作为衡量文档清晰度的标准。
• “风格方向”与“构图建议”用于规划文档的整体格调和信息层次，可在动笔前与团队对齐。
• “细节强化”列表是提升PRD工程严谨性的关键，应作为功能详述部分的必备要素进行填充。