技能（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.

review-testing