| name | api-blackbox-test-reviewer |
| description | 测试用例质量门禁 Skill。当 planner 输出测试方案后、executor 执行前，组织资深测试工程师、资深产品经理、资深软件工程师、安全工程师四个角色进行风险分级评审、业务场景拆解评审、覆盖矩阵校验、接口 x 字段语义等价类矩阵逐单元评审、场景 x 边界/异常覆盖矩阵评审、跨接口一致性评审、可执行性 preflight、需求追踪、安全建模和 Anti-Happy-Path 检测，并给出通过、有条件通过、不通过或阻塞的最终结论。 |
测试用例质量门禁
目标
在 planner 阶段输出测试方案之后、executor 阶段执行真实请求之前，对测试用例、边界测试、安全测试、数据计划、兼容性验证和接口编排链路做质量门禁。
本 Skill 不是只做文档评审，必须同时完成：
- 文档评审：四个角色分别提出专业意见。
- 结构校验：检查用例、断言、数据、清理、链路 ID、需求映射、业务场景拆解、接口 x 字段语义等价类矩阵、场景 x 边界/异常覆盖矩阵和跨接口一致性用例是否完整。
- 影响范围校验：由资深软件工程师先基于需求分析和技术方案判断测试范围是否充分，再结合代码变更和依赖关系追踪公共方法、共享组件、关联接口等扩散影响，并确认测试范围覆盖这些影响。
- 可执行性验证：检查执行环境、凭证、base URL、数据构造、依赖服务和请求示例是否具备。
- 反例驱动评审：按接口风险等级逼出异常路径、攻击路径、边界情况和非理想用户路径，避免只验证 Happy Path。
- 对抗性辩论：让编写测试方案的测试人员先陈述覆盖依据，再由资深测试工程师提出反例、遗漏场景和不合理用例质疑，最后形成补充用例或豁免依据。
评审通过或有条件通过时，executor 才能按方案执行；评审不通过时，必须回到 planner 阶段补充或修正测试方案，不得直接执行。
文件输出
本阶段必须将完整评审记录写入 Markdown 文件。默认路径为：
tests/【需求】_YYYYMMDD/测试用例评审.md
规则：
【需求】 必须与 planner 阶段目录保持一致；如果已有 tests/【需求】_YYYYMMDD/测试方案.md，应复用同一目录。YYYYMMDD 使用 planner 阶段已确定日期；没有既有目录时使用执行当天日期，例如 20260428；如果用户明确指定日期，以用户指定日期为准。- 文件名中的
/、空格、冒号、引号等不适合作为路径的字符应替换为 _。
- 写入文件后，在回复中说明文件路径、最终评审结果、必须修改项和是否允许进入 executor。
- 无法写入文件时，必须标记为阻塞并说明原因，不得只在对话中输出完整评审后视为完成。
输入要求
评审前必须尽量收集：
- planner 输出的
测试方案.md 或完整测试方案内容。
- 当前需求、接口变更说明、API 文档、关键代码或执行约束。
- 需求分析、技术方案、代码 diff、相关接口/模块路径、调用链或 GitNexus 分析结果；缺少代码或调用关系证据时，先基于需求分析和技术方案判断测试范围是否充分，再通过代码搜索或 GitNexus 等工具补充受影响逻辑、公共方法和关联接口分析。
- executor 所需的测试环境、凭证、base URL、数据库实例、数据安全边界等已知信息。
如果没有 planner 输出，应先阻塞并要求补充测试方案或回到 api-blackbox-test-planner。
评审角色
四个角色必须分别从自身专业角度独立提出意见，并完成与接口风险相匹配的职责。职责不适用时必须说明理由；对核心、写入、鉴权、敏感数据、支付/资产/权限/订单/审批等高风险接口，不能用“不适用”跳过关键异常、安全或数据一致性评审。
- 资深测试工程师：检查用例覆盖、业务场景拆解、边界条件、异常路径、可执行性、断言明确性、数据准备和清理、用例 ID 与链路 ID 是否可追踪；必须按接口 x 字段语义等价类矩阵单元和场景 x 边界/异常覆盖矩阵单元逐项评审是否有用例、数据、断言和执行可行性；对核心接口必须覆盖参数错误、状态异常、依赖失败中的至少 2 类；对低风险只读接口可降低异常路径数量，但必须说明豁免依据；必须与测试方案编写者进行结构化对抗性辩论，重点质疑遗漏业务场景、Happy Path 偏置、边界值遗漏、断言不充分和用例不可执行。
- 资深产品经理：检查需求点覆盖、业务流程完整性、用户场景、字段语义、兼容旧行为、优先级、验收口径和范围内外假设是否清晰；对账号、用户 ID、靓号、手机号、资源 ID、状态等字段必须确认业务语义等价类是否符合产品预期；对存在用户流程的接口必须回答用户误操作、回退/重复/跳步骤、历史行为兼容问题；纯技术型内部接口可说明不适用。
- 资深软件工程师：检查接口契约、状态码和错误码、数据模型副作用、幂等、并发、缓存/异步/消息队列、跨接口数据传递、逻辑类似接口一致性和技术可观测性；必须根据需求分析和技术方案评估影响点与影响范围，包括直接变更接口、调用方/消费者、数据模型、缓存、异步任务、消息、权限、安全边界、兼容性、配置和观测链路；对写接口、状态流转接口和异步接口必须评估并发冲突、幂等性、乱序请求、缓存或异步一致性风险。
- 安全工程师：检查鉴权、权限、租户隔离、IDOR、注入、XSS、批量赋值、重放、敏感信息泄露、破坏性 payload 隔离和安全测试授权；对受保护接口或用户可控输入接口必须覆盖越权/IDOR、注入 payload、认证绕过或弱鉴权中的适用项。
质量门禁模型
评审必须使用统一覆盖模型，不能只按角色主观判断。
覆盖检查矩阵
必须检查以下覆盖维度，并统计关联用例数量。覆盖矩阵用于发现遗漏，不要求所有接口在所有维度都有用例；不适用项必须说明原因。
- 正常路径。
- 异常路径。
- 边界值。
- 业务场景完整性。
- 状态流转。
- 数据一致性。
- 并发行为。
- 安全攻击面。
- 兼容性。
- 可观测性。
业务场景拆解评审
必须检查 planner 是否基于需求、技术方案、验收标准、状态机、用户角色、权限规则、数据生命周期和接口链路拆分所有业务场景。评审不能只看接口列表或用例数量；必须确认每个业务场景都有明确前置状态、主流程、分支/异常/边界点、风险等级、关联接口/链路和关联用例/矩阵。
每个业务场景至少检查：
- 是否能追溯到需求、技术方案、验收标准或业务规则。
- 是否覆盖主流程以及适用的反向路径。
- 是否列出字段边界、状态边界、权限边界、数据存在性边界和跨接口链路边界。
- 是否在
场景 x 边界/异常覆盖矩阵 中关联正常、异常、边界和权限/状态/数据变体用例。
- 是否有明确响应断言；涉及副作用时是否有 DB 断言。
- 是否存在只有 Happy Path 的场景；如果存在，豁免依据是否充分。
核心、写入、鉴权、资产、订单、审批、支付、权限和敏感数据场景，如果缺少业务场景拆解、边界值用例或反向路径用例，不得给出 通过。
需求与技术方案驱动的影响范围评估
资深软件工程师必须先基于需求分析和技术方案判断测试范围是否充分，再结合代码 diff、API 文档、调用链、配置、数据库 schema、消息/异步链路、前后端消费者和 GitNexus 分析结果追踪扩散影响。评估不能只看本次显式改动接口；如果改动公共方法、共享组件、公共校验、公共查询、缓存逻辑、权限逻辑、序列化结构、错误处理或数据模型，必须识别所有可能受影响的接口、任务、消费者和业务链路，并纳入测试验证范围。
评估必须覆盖：
- 直接变更接口、字段、状态码、错误码和响应结构。
- 被公共方法、共享组件、公共校验、公共查询、权限逻辑、缓存逻辑、序列化结构或错误处理间接影响的其他接口。
- 因当前接口行为变化而可能受影响的关联接口、逻辑类似接口、编排链路、前后置接口和跨接口一致性场景。
- 受影响调用方、客户端、前端页面、后台任务、定时任务、消息消费者和第三方集成。
- 数据模型、索引、事务、副作用、审计字段、逻辑删除、缓存和异步一致性。
- 权限、租户隔离、用户身份、安全边界和敏感数据暴露面。
- 兼容性、灰度配置、开关、历史数据和观测/告警链路。
如果上下文没有足够信息，必须先根据需求分析和技术方案给出初步影响范围，再使用代码搜索、GitNexus 或项目文档补充分析；无法分析时应标记阻塞或把缺口写入退回项。所有直接影响和扩散影响必须映射到测试用例、矩阵单元、跨接口一致性用例或编排链路；未覆盖的影响不得静默放过，必须补充用例或给出明确豁免依据。
接口 x 字段语义等价类矩阵评审
必须逐个矩阵单元评审，不能只按需求 ID、接口 ID 或测试类型粗粒度通过。
每个矩阵单元至少检查：
- 是否有明确接口、字段、字段语义和等价类。
- 是否有代表值或数据构造方式。
- 是否标明必测级别，必测/关键单元不能无故豁免。
- 是否关联到可执行用例 ID。
- 是否有响应断言；有副作用时是否有 DB 断言。
- 是否能在 executor 中记录独立执行状态和证据路径。
缺少矩阵、矩阵单元没有关联用例、关键字段等价类过粗，或把多个语义不同的取值合并成一个泛化用例时，必须退回 planner 或至少给出有条件通过的执行关注项；核心接口的必测矩阵缺失不得给 通过。
场景 x 边界/异常覆盖矩阵评审
必须逐个覆盖单元评审，不能接受“业务场景已覆盖”但没有边界值、异常路径或反向路径用例的方案。
每个覆盖单元至少检查：
- 是否有明确场景 ID、覆盖类型、输入/状态组合和边界值或反例。
- 是否标明必测级别，核心场景的边界/异常单元不能无故豁免。
- 是否关联到可执行用例 ID。
- 是否有响应断言；有副作用时是否有 DB 断言。
- 是否说明不适用或豁免依据。
缺少该矩阵、核心场景只有 Happy Path、边界值未列全、异常/权限/状态/数据变体没有用例，或把多个业务边界合并成一个泛化用例时，必须退回 planner；高风险场景不得给 通过。
跨接口一致性评审
对逻辑类似、共享字段语义或共享业务规则的接口，必须检查是否设计跨接口一致性用例。不得接受“接口 A 已测过，所以接口 B 不再测”的替代关系。
评审时必须确认：
- 是否识别了逻辑类似接口组及其差异依据。
- 是否对每个参与接口分别有请求用例和证据要求。
- 是否比较了状态码、错误码、响应字段语义、空结果语义、权限过滤和副作用。
- 差异行为是否有产品、权限或历史契约依据。
Traceability 要求
必须建立 需求 -> 用例 -> 接口 -> 断言 的追踪链：
- 每个需求点必须至少映射 1 个用例，除非明确标记范围外并说明原因。
- 每个用例必须有明确断言，断言至少包含响应断言；有数据库副作用时还必须包含 DB 断言。
- 每个接口编排链路必须能追踪到链路 ID、步骤、数据提取字段和传递目标。
可执行性 Preflight
必须检查 executor 是否能真实执行：
- base URL 或 gRPC endpoint 是否已提供或能从上下文确定。
- 鉴权 token、账号、签名密钥或其他凭证是否已提供，或是否明确标记阻塞。
- 测试数据是否可构造、可复用、可定位和可清理。
- 依赖服务、mock/stub、回调、消息队列、异步任务或第三方服务是否可用或有替代方案。
- 每个接口是否具备可执行请求示例，例如 curl、grpcurl 或足够生成请求的 method/path/header/query/body 信息。
STRIDE 安全建模
安全评审应按 STRIDE 输出覆盖。STRIDE 是威胁建模框架，不是所有接口六类全部强制命中；高风险接口必须逐项评估，低风险接口可标记不适用并说明证据。
- S - Spoofing：身份伪造、认证绕过、token 替换。
- T - Tampering：请求参数、资源 ID、金额、状态或敏感字段篡改。
- R - Repudiation：缺少审计、日志不可追踪、操作不可抵赖。
- I - Information Disclosure：敏感字段、错误堆栈、内部地址、密钥或越权数据泄露。
- D - Denial of Service：超大分页、超长输入、重复请求、批量操作或资源消耗。
- E - Elevation of Privilege：越权、IDOR、角色提升、租户隔离绕过。
涉及鉴权、用户、租户、角色、订单、资产、支付、积分、文件、审批、后台管理或敏感数据时，STRIDE 六类必须逐项评估；没有适用测试点时必须说明“不适用”的证据。普通公开只读接口可重点评估信息泄露、滥用和输入处理风险。
Anti-Happy-Path Gate
必须检测 Happy Path 偏置：
Happy Path 偏置 指测试方案主要验证正常成功路径，但对接口语义适用的关键异常、边界、安全、权限、状态、依赖失败、并发、兼容性或跨接口一致性风险缺少用例、数据或断言。正常路径用例本身是必需的；问题不是存在正常路径，而是只验证或主要依赖正常路径。- 业务场景层面也必须检测 Happy Path 偏置：任一核心业务场景只有正常路径，没有适用边界值、异常路径、权限/状态/数据变体或跨接口失败链路时，应标记为
业务场景 Happy Path 偏置。
- 核心接口、写接口、鉴权接口、用户可控输入接口至少应覆盖错误参数、权限异常、边界值中的适用项；确实不适用时必须说明理由。
- 异常用例占比建议
>= 40%，但只能作为辅助信号，不能替代风险类别覆盖判断，也不是所有低风险接口的硬门槛。异常用例包括参数错误、权限异常、状态异常、外部依赖失败、并发冲突、乱序请求、安全攻击和兼容性失败路径。
- 安全相关接口或用户可控输入接口必须至少有 1 个安全用例。
- 如果正常用例占比
> 70% 且缺少安全用例或异常路径，必须标记为 Happy Path 偏置。
- 即使异常用例占比达标，只要核心或高风险接口缺少适用的关键风险类别，例如鉴权/权限、输入校验、状态流转、数据一致性、幂等/并发、依赖失败、安全攻击面、兼容性或跨接口一致性，也必须标记为
Happy Path 偏置 或 关键风险类别覆盖不足。
- 对核心或高风险接口，Happy Path 偏置或关键风险类别覆盖不足不得给出
通过；对低风险接口，可有条件通过但必须记录豁免依据、风险和 executor 关注项。
对抗性辩论
对抗性辩论是 reviewer 阶段的结构化质量门禁，用于发现测试方案作者因熟悉主流程而遗漏的异常路径、边界值、兼容性风险和不可执行用例。辩论必须证据驱动、限时收敛，目标是提高测试方案质量，不评价个人。
辩论规则：
- 测试方案编写者先说明每个需求点、影响点和高风险接口的覆盖依据。
- 资深测试工程师以反方角色提出遗漏场景、反例输入、异常链路、数据断言缺口、不可执行风险和 Happy Path 偏置质疑。
- 每个质疑必须落到“新增用例、修改断言、补充数据/清理、补充安全/边界/兼容性用例、明确豁免依据、退回 planner”之一。
- 对核心或高风险接口，未解决的有效质疑不得给
通过；对低风险接口，可有条件通过但必须成为 executor 关注项。
- 辩论不替代四角色评审和硬性门禁；它是发现遗漏的附加质量门禁。
辩论产物必须包括：争议点、测试方案编写者答辩、资深测试工程师反驳、最终处理方式、关联新增/修改用例 ID 或豁免依据。
反例驱动问题
四个角色必须共同回答以下反例问题。问题明显不适用时可以标记不适用，但必须说明原因；核心或高风险接口不得整体跳过反例评审。
- 如果接口被恶意调用，会发生什么？
- 如果参数完全错误或类型错误，会发生什么？
- 如果请求顺序错乱、重复提交或用户连续点击 10 次，会发生什么？
- 如果前置接口失败、返回空数据或返回旧字段，会发生什么？
- 如果依赖服务超时、缓存不一致、异步任务延迟，会发生什么？
量化判定规则和输出模板
执行评审时必须读取 references/review-template.md，并严格使用其中的评分模型、Must Pass、Reject If 和输出模板。主文件只保留流程和规则摘要，完整表格与评分权重以 reference 为准。
评审结果必须给出 0-100 质量评分，评分只能辅助判断，不能覆盖硬性拒绝规则。触发 references/review-template.md 中任一 Reject If 时，最终结果必须为 不通过 或 阻塞。
评审过程
评审必须包含七个阶段：
- 影响范围评估：资深软件工程师基于需求、技术方案、代码变更和工具分析输出影响点与影响范围。
- 结构化预检：完成影响范围覆盖、覆盖矩阵、接口 x 字段语义等价类矩阵评审、跨接口一致性评审、Traceability、Preflight、STRIDE 和 Anti-Happy-Path 检测。
- 独立评审：四个角色分别列出通过项、问题项、建议项和阻塞项，并完成各自强制职责。
- 对抗性辩论：测试方案编写者说明覆盖依据，资深测试工程师提出反方质疑，形成补充用例、修改断言、豁免依据或退回项。
- 反例驱动评审：围绕异常输入、攻击路径、乱序请求、重复提交、依赖失败和非理想用户路径提出反例。
- 小组讨论博弈：合并四个角色意见，识别冲突点，讨论是否必须在执行前补充、是否可作为执行阶段风险记录、是否需要退回 planner。
- 最终一致结论：基于硬规则和评分给出小组一致意见，明确评审结果和下一步。
评审判定
最终评审结果只能为以下之一：
- 通过：未触发 Reject If，Must Pass 全部满足或有充分的不适用说明，质量评分
>= 85，关键需求、接口契约、数据计划、边界、安全、兼容性和编排链路已覆盖，executor 可执行。
- 有条件通过：未触发 Reject If，Must Pass 全部满足或有充分的不适用说明，仅存在可在 executor 阶段补证的非关键缺口，质量评分
>= 75，不阻塞真实执行；必须列出 executor 执行时需要额外关注或补证的事项。
- 不通过：存在关键遗漏、不可执行用例、缺失数据计划、缺失安全或兼容性覆盖、关键链路缺失、断言不明确，必须退回 planner 完善后重新评审。
- 阻塞：缺少 planner 输出、需求上下文、接口信息或评审所需关键输入，无法形成有效评审。
只有 通过 或 有条件通过 才允许进入 executor。不通过 或 阻塞 必须回到 planner 或补充输入后重新评审。
必须输出
使用 references/review-template.md 的完整模板输出评审记录，并写入 tests/【需求】_YYYYMMDD/测试用例评审.md。
退回 planner 要求
当最终结果为 不通过 时，必须把退回项整理成 planner 可直接执行的补充要求：
- 缺失的用例 ID 或需要新增的用例类型。
- 未覆盖的影响点和影响范围，以及每个影响点需要新增或修改的用例、矩阵单元、编排链路或断言。
- 缺失或过粗的接口 x 字段语义等价类矩阵单元，以及每个单元应关联的用例、数据和断言。
- 缺失的跨接口一致性用例，尤其是逻辑类似接口中不能被其他接口测试替代的部分。
- 需要补充的边界值、安全 payload、兼容性验证或编排链路。
- 需要明确的前置数据、清理策略、DB 断言或响应断言。
- 需要澄清的业务规则、权限边界、状态流转或历史契约。
- 对抗性辩论中未解决的有效质疑，以及对应的补充测试要求。
退回项应具体到可修改测试方案的粒度，避免只写“覆盖不足”“需要加强安全测试”等泛化意见。
