技能（Skill）：复习测试
目的 (Purpose)
仅审查 测试 问题的代码。不要定义范围（差异与代码库）或执行语言/框架/安全/架构分析；这些是单独的原子技能。以标准格式发出结果列表以进行聚合。重点关注测试的存在性和覆盖率、测试质量和结构、测试类型和分层、边缘情况和错误路径覆盖率以及测试可维护性。
核心目标（Core Objective）
首要目标：生成一个以测试为中心的结果列表，涵盖给定代码范围的测试存在性、覆盖充分性、测试质量/结构、测试类型/分层、边缘情况覆盖率和测试可维护性。
成功标准（必须满足所有要求）：
- ✅ 仅测试范围：仅审核测试维度；未执行范围选择、语言/框架约定、安全性、性能或架构分析
- ✅ 涵盖所有六个测试维度：在相关的情况下评估测试存在性、覆盖范围充分性、质量/结构、类型/分层、边缘情况/错误路径和可维护性
- ✅ 符合调查结果格式：每个调查结果包括位置、类别（“cognitive测试”）、严重性、标题、描述和可选建议
- ✅ 标记高风险差距：未经测试或测试不充分的高风险代码路径（身份验证、支付、数据突变）被标记为“关键”或“主要”
- ✅ 仅从代码进行分析：从代码结构和可用产品评估测试充分性，无需运行测试或生成覆盖率报告
验收测试：输出是否包含涵盖所有相关维度的测试结果列表，以及适合风险的严重性评级和提高测试覆盖率和质量的可行建议？
范围边界（范围边界）
本技能负责：
- 测试存在性检查（缺少关键模块、服务、公共功能的测试文件）
- 覆盖充分性分析（高风险路径覆盖：认证、支付、数据突变）
- 测试质量和结构（安排-行动-断言、有意义的断言、行为而非实现）
- 测试类型和分层（单元、集成、e2e 平衡；模拟/存根隔离）
- 边缘情况和错误路径覆盖（边界条件、无效输入、故障模式）
- 测试可维护性（DRY，不牺牲可读性、夹具组织、脆性测试检测）
本技能不负责：
- 范围选择（决定要分析哪些文件/路径）——范围由调用者提供
- 运行测试或生成覆盖率报告 - 使用“automate-tests”进行测试执行
- 特定于语言/框架的测试约定 - 使用“review-dotnet”、“review-java”、“review-go”等。
- 安全性、性能或架构审查——使用各自的原子技能
- 全面精心策划的审核——使用“审核代码”
转交点：发出所有测试结果后，将其移交给“审核代码”，以便在精心策划的审核中进行聚合。对于实际运行的测试，请重定向到“automate-tests”。
使用场景（用例）
- 精心安排的审查：当review-code运行范围→语言→框架→库→cognitive时用作cognitive步骤。
- 以测试为中心的审查：当用户只想评估测试运行状况和覆盖范围时（例如，在发布之前、主要重构之后或入职期间）。
- 差距分析：识别未经测试的模块、缺失的测试类型（单元/集成/e2e）或提供错误置信度的低质量测试。
何时使用：当任务包括测试审核时。范围和代码范围由调用者或用户确定。
行为（行为）
该技能的范围
- 分析：测试给定代码范围中的维度（调用者提供的文件或差异）。不决定范围；接受代码范围作为输入。
- 不要：执行范围选择、语言/框架约定、安全性、性能或架构审查。仅专注于测试。
审查清单（仅测试维度）
- 测试是否存在：关键模块、服务、公共功能是否有对应的测试文件？是否存在明显的差距，关键逻辑根本没有经过测试？
- 覆盖率充分性：测试覆盖率对于代码的风险级别是否足够？高风险路径（认证、支付、数据变异）是否经过测试？注意：如果有可用的覆盖率报告或指标，请参考它们；否则进行结构评估。
- 测试质量和结构：测试结构是否良好（安排-执行-断言或给出-何时-然后）？测试名称是否清楚地描述了场景？断言有意义吗（不仅仅是“不抛出异常”）？测试是否验证行为而不是实现细节？
- 测试类型和分层：是否有适当的单元、集成和端到端测试组合？单元测试是否隔离（外部依赖项的模拟/存根）？集成测试是否在需要时测试真实的交互？
- 边缘情况和错误路径：测试是否涵盖边界条件、无效输入、空/空情况、并发场景和预期错误响应？是否明确测试了故障模式？
- 测试可维护性：测试是否干燥而不牺牲可读性？测试装置和助手是否组织良好？测试是否脆弱（与实现紧密耦合、过度模拟或依赖执行顺序）？测试数据管理是否干净（工厂、构建器或固定装置而不是硬编码的魔法值）？
语气和参考
- 专业和技术：参考具体位置（文件：行或模块）。发出包含位置、类别、严重性、标题、描述、建议的结果。对于未经测试的高风险代码路径使用严重性“主要”或“关键”。
输入与输出 (Input & Output)
输入（输入）
- 代码范围：用户或范围技能已选择的文件或目录（或差异）。该技能不决定范围；它仅审查提供的代码以进行测试。
输出（输出）
- 以附录：输出合同中定义的格式发出零个或多个结果。
- 此技能的类别是cognitive测试。
限制（限制）
硬边界（Hard Boundaries）
- 不要执行范围选择、语言、框架、安全、性能或架构审查。保持在测试范围内。
- 不要在没有具体地点或可行建议的情况下给出结论。
- 不需要需要运行测试或生成覆盖率报告。从代码和可用产品（例如现有的覆盖文件）中分析测试充分性。对于实际运行的测试，请使用 automate-tests。
- 不要惩罚缺乏对琐碎代码（简单的 getter、常量、生成代码）的测试，除非它掩盖了真正的风险。
技能边界 (Skill Boundaries)
不要做这些（其他技能可以处理它们）：
- 不要选择或定义代码范围 - 范围由调用者或“审查代码”确定
- 不要运行或执行测试 - 使用“automate-tests”进行测试执行
- 不要执行特定于语言/框架的测试约定分析 - 使用相应的语言技能
- 不要执行安全性、性能或架构分析——使用各自的原子技能
何时停止并交接：
- 当所有测试结果发布后，将其移交给“审查代码”以在精心策划的审查中进行聚合
- 当用户需要实际运行测试时，重定向到“automate-tests”
- 当用户需要全面审查（范围+语言+cognitive）时，重定向到“审查代码”
自检（Self-Check）
核心成功标准
- 仅测试范围：仅审查测试维度；未执行范围选择、语言/框架约定、安全性、性能或架构分析
- 涵盖所有六个测试维度：在相关的情况下评估测试存在性、覆盖范围充分性、质量/结构、类型/分层、边缘情况/错误路径和可维护性
- 符合调查结果格式：每个调查结果包括位置、类别（“cognitive测试”）、严重性、标题、描述和可选建议
- 标记高风险差距：未经测试或测试不充分的高风险代码路径（身份验证、支付、数据突变）被标记为“关键”或“主要”
- 仅从代码进行分析：根据代码结构和可用产品评估测试充分性，无需运行测试或生成覆盖率报告
流程质量检查
- 是否仅审查了测试维度（没有范围/语言/安全/架构）？
- 是否涵盖相关的测试存在性、覆盖范围充分性、质量/结构、类型/分层、边缘情况和可维护性？
- 每个发现是否都包含位置、类别=cognitive测试、严重性、标题、描述和可选建议？
- 关键差距（未经测试的高风险代码）是否已明确标记并可采取行动？
验收测试
输出是否包含涵盖所有相关维度的测试结果列表，以及适合风险的严重性评级和提高测试覆盖率和质量的可行建议？
示例（示例）
示例 1：缺少关键模块的测试
- 输入：没有测试文件的支付处理模块。
- 预期：针对高风险代码缺失测试发出关键发现；建议为核心支付逻辑创建单元测试，并为网关交互创建集成测试。类别 = cognitive测试。
示例 2：测试存在但很浅
- 输入：身份验证模块有测试，但它们仅涵盖快乐路径（有效登录）并跳过无效凭据、过期令牌、速率限制和帐户锁定。
- 预期：发布边缘情况覆盖不足的重大发现；列出要添加的具体场景。类别 = cognitive测试。
边缘情况：经过充分测试的代码库
- 输入：模块具有全面的单元、集成和端到端测试，结构清晰，覆盖范围广。
- 预期：发出零结果或建议级别的结果以进行细微改进（例如测试命名一致性）。不要发明问题。
附录：输出合约
每项调查结果必须遵循标准调查结果格式：
| 元素 | 要求 | |||
|---|---|---|---|---|
| 位置 | path/to/file.ext 或模块名称（可选行或范围）。 | |||
| 类别 | “cognitive测试”。 | |||
| 严重性 | 关键 \ | 主要 \ | 次要 \ | 建议。 |
| 标题 | 简短的一行摘要。 | |||
| 描述 | 1-3 句话。 | |||
| 建议 | 具体修复或改进（可选）。 |
示例：
- **Location**: `src/payment/processor.go`
- **Category**: cognitive-testing
- **Severity**: critical
- **Title**: No tests for payment processing module
- **Description**: The payment processor handles charge, refund, and webhook verification but has no corresponding test file. This is high-risk code that directly affects revenue.
- **Suggestion**: Create `processor_test.go` with unit tests for charge/refund logic (mock gateway) and integration tests for webhook signature verification.