API 测试
中文版： 本文件为 API 测试技能的中文说明。
使用时机
- 需要 API 测试计划、API 测试用例或 API 风险分析时。
- 请求涉及 REST、GraphQL、SOAP、gRPC、WebSocket 或混合 API 行为时。
工作流程
- 阅读并遵循“渐进式披露”部分列出的主提示（覆盖范围、结构、质量标准）。
- 仅添加能改变结果的项目的上下文：范围、环境、约束、风险、依赖、预期交付物。
- 如果输入不完整，返回一个可用的初稿，并明确标记假设和缺口。
- 默认使用 Markdown 格式；仅在用户要求时切换格式。
核心约束
- 根据风险/业务影响进行优先级排序——不要对所有内容一视同仁。
- 将已确认的事实与当前假设区分开来。
- 不要编造用户未提供的端点、字段、环境或根本原因。
- 保持输出的可执行性：具体的场景、清晰的优先级、清晰的后续步骤。
渐进式披露
- 在生成输出之前，阅读并遵循
prompts/api-testing.md（最低覆盖范围、输出结构、质量标准）。 - 当请求 Excel/CSV/JSON/Word 格式时：阅读
output-formats.md并遵循该格式。 - 当有现成的模板可用时：使用
output-templates/下的匹配文件。 - 如需深入了解框架/故障排除/模式说明：仅阅读
references/下的相关文件，不要加载整个目录。 - 对于格式转换或辅助检查：优先使用现有的
scripts/，而不要重新发明轮子。 - 如需评估/回归此技能：使用
evals/和 skill-up.
交付前检查清单
- 遵循了主提示中的输出结构
- 最低覆盖范围重点：范围内的端点或业务流、优先级和风险等级、正向场景、负向场景、边界场景、认证和权限检查、请求和响应验证、错误处理……（详情见主提示）
- 已覆盖最低检查清单，或解释了未覆盖的原因
- 高风险项已明确优先级
- 未编造用户未提供的细节
- 假设和缺口已标记
常见陷阱
- 当范围/上下文缺失时，不要假装完备。
- 不要将每个项都视为同等重要。
- 不要跳过假设和信息缺口。
- 不要倾泻与当前工具链无关的通用理论。