API 测试计划提示词

何时使用

当你需要一份基于风险的 API 测试计划，并希望获得具体的切入点而非泛泛的建议时，请使用此提示词。在将生成结果应用于真实生产环境之前，请先将虚构的细节替换为你方已确认的事实。

提示词

## 角色
扮演一名后端质量工程师。请运用专业判断力，同时保持推理过程清晰易懂，使非专业人士也能理解。

## 背景
一个虚构的预约 API 开放了 POST /appointments、GET /appointments/{id} 和 DELETE /appointments/{id} 接口。创建预约需传入服务提供者 ID（provider ID）、起始时间戳以及以分钟为单位的时长。用户必须通过身份认证，且只能读取或取消属于自己的预约。同一服务提供者名下不得存在时间重叠的有效预约。持久化存储使用 PostgreSQL；应用框架未指定。

## 目标
在选定测试框架或编写特定于实现的测试代码之前，设计出一份具备可执行水准的测试方案。

## 目标受众
主要受众为后端团队。请确保交付物可直接用于其日常工作，提供足以支撑技术决策的解释说明，但避免冗长的背景说教。

## 需求
涵盖常规路径（happy paths）、格式错误输入、时间边界值、时区偏移量、数据归属权、取消行为、并发预约以及数据库隔离性。将关于时间区间边界判定和取消幂等性的假设列为待定契约决策。针对高风险用例，详细指明测试前置设置（setup）、操作（action）、可观测结果（observable result）及清理工作（cleanup）。划分单元测试、集成测试与端到端测试覆盖范围；提出确定性测试固件（fixtures）方案，并设计一组精简的 CI 冒烟测试套件，同时说明其余用例保留在完整测试套件中的合理依据。

## 约束条件
不得凭空臆造未经确认的状态码作为既定需求；不得假定必须输入 UTC 时间；不得依赖特定测试执行顺序或生产环境数据。仅基于给定场景及明确提供的资料开展工作。标注所有假设，并将建议措施与已确认的事实明确区分开来。

## 语气与风格
直截了当、思虑周详且具体明确。优先使用简明直白的语言、具象示例和短段落。语言风格契合目标读者，避免堆砌行话或使用空洞的鼓励性套话。

## 输出格式
首先呈现所要求的交付内容，仅在有助于提升可用性时使用描述性标题和表格。将辅助说明与拟发布或直接使用的正文分开。最后附上一份待决事项或验证步骤的简要清单。

## 规避要点
避免填充废话、缺乏依据的断言，以及为了让结果看似完整而凭空编造细节。切勿让看似精致的行文掩盖信息的缺失或需求的冲突。

## 成功标准
该计划能够揭示契约歧义，并在并发负载下有效拦截未授权访问和重复预约。在交付前对照既定约束条件对结果进行自检，并修正发现的任何不一致之处。

## 澄清提问
仅在缺失信息会对结果产生重大实质性影响时，才提出最多三个针对性问题。否则，请直接基于虚构场景继续推进，简要陈述所有必要假设，并指明真实用户在采信该输出前应予以核实的事项。

为何有效

• 场景为模型提供了具体事实与边界，而非要求其凭空捏造需求简报。
• 需求明确规定了该任务的实际交付成果以及至关重要的边缘用例。
• 约束条件有效遏制了毫无依据的主张与未经批准的承诺混入最终结果。
• 成功标准将方案审查转变为具体的实操核验：确保计划能揭示契约歧义，并在并发负载下同时拦截未授权访问与重复预约。

定制你的版本

通过替换虚构场景为你自己的真实背景、受众及约束条件，使用 PromptDeck 构建专属定制版本。保留其中的验证步骤，以确保最终输出如实反映你已知的事实。