api-blackbox-test-reporter

name	api-blackbox-test-reporter
description	接口黑盒测试报告 Skill。当用户需要根据编码前测试方案和编码后真实执行证据，评估需求覆盖率、用例执行覆盖率、接口覆盖率、边界测试覆盖率、安全测试覆盖率、编排/集成链路覆盖率、性能测试建议、兼容性结论、测试是否通过并输出测试报告时使用。

接口黑盒测试报告

目标

基于 planner 的测试方案和 executor 的真实执行证据，输出最终测试报告。没有真实请求和 DB 验证证据时，不得给出“通过”结论，只能说明证据不足或阻塞。

文件输出

本阶段必须将完整测试报告写入 Markdown 文件。默认路径为：

tests/【需求】_YYYYMMDD/测试报告.md

规则：

• 【需求】 必须与 planner 和 executor 阶段目录保持一致；如果已有 tests/【需求】_YYYYMMDD/测试方案.md 或 tests/【需求】_YYYYMMDD/执行记录.md，应复用同一目录。
• YYYYMMDD 使用执行当天日期，例如 20260428；如果前序阶段已确定日期，以既有目录为准。
• 文件名中的 /、空格、冒号、引号等不适合作为路径的字符应替换为 _。
• 写入文件后，在回复中说明文件路径、最终结论、覆盖率摘要和剩余风险。
• 无法写入文件时，必须标记为阻塞并说明原因，不得只在对话中输出完整报告后视为完成。

输入要求

尽量收集：

• 编码前测试范围、兼容性验证、测试用例、边界测试、安全测试、补充验证项、接口编排/集成链路、性能测试建议和测试数据计划。
• 编码后测试数据准备记录。
• 所有 curl 请求记录、请求参数、返回数据、是否通过和不通过原因。
• 接口编排/集成链路的步骤记录、数据提取、传递目标、是否包含非本次变更接口和步骤结果。
• db-mcp 查询或写入验证证据。
• 失败、阻塞、跳过和清理记录。

覆盖率评估

基于计划和执行证据评估：

• 需求覆盖率：已验证需求点数 / 需求点总数。
• 用例执行覆盖率：已执行用例数 / 计划用例总数。
• 接口覆盖率：已请求接口数 / 计划接口总数。
• 边界测试覆盖率：已执行边界用例数 / 计划边界用例总数。
• 安全测试覆盖率：已执行安全用例数 / 计划安全用例总数。
• 编排/集成链路覆盖率：已执行编排/集成链路数 / 计划编排/集成链路总数。
• 性能测试建议覆盖率：已评估性能风险接口或链路数 / 计划评估接口或链路总数。
• 数据场景覆盖率：已验证数据场景数 / 计划数据场景总数。
• 兼容性覆盖率：已验证兼容性检查数 / 计划兼容性检查总数。

覆盖率不能只给百分比，必须列出未覆盖项和原因。

测试结论规则

• 通过：关键用例全部通过，兼容性检查通过，没有阻塞关键路径。
• 失败：存在需求功能、接口契约、数据库状态或兼容性失败。
• 部分通过：核心路径通过，但存在非关键失败或未覆盖项。
• 阻塞：关键环境、数据、凭证或依赖缺失，无法形成有效结论。

输出格式

使用 references/report-template.md 输出报告。报告必须包含：

• 测试目标和环境。
• 编码前测试方案摘要。
• 执行证据。
• 所有接口请求的 curl 记录。
• 接口编排链路和数据传递记录。
• 性能测试评估与建议。
• 失败项。
• 覆盖率评估。
• 测试数据和清理状态。
• 兼容性说明。
• 最终总结和发布建议。
• 剩余风险。