review-testing

技能（Skill）：审查测试

目的 (Purpose)

仅审查 测试 问题的代码。不要定义范围（差异与代码库）或执行语言/框架/安全/架构分析；这些是单独的原子技能。以标准格式发出结果列表以进行聚合。重点关注测试的存在性和覆盖率、测试质量和结构、测试类型和分层、边缘情况和错误路径覆盖率以及测试可维护性。

---

核心目标（Core Objective）

首要目标：生成一个以测试为中心的结果列表，涵盖给定代码范围的测试存在性、覆盖充分性、测试质量/结构、测试类型/分层、边缘情况覆盖率和测试可维护性。

成功标准（必须满足所有要求）：

1. ✅ 仅测试范围：仅审核测试维度；未执行范围选择、语言/框架约定、安全性、性能或架构分析
2. ✅ 涵盖所有六个测试维度：在相关的情况下评估测试存在性、覆盖范围充分性、质量/结构、类型/分层、边缘情况/错误路径和可维护性
3. ✅ 符合调查结果格式：每个调查结果包括位置、类别（“cognitive-testing”）、严重性、标题、描述和可选建议
4. ✅ 标记高风险差距：未经测试或测试不充分的高风险代码路径（身份验证、支付、数据突变）被标记为“关键”或“主要”
5. ✅ 仅从代码进行分析：从代码结构和可用产品评估测试充分性，无需运行测试或生成覆盖率报告

验收测试：输出是否包含涵盖所有相关维度的测试结果列表，以及适合风险的严重性评级和提高测试覆盖率和质量的可行建议？

---

范围边界（范围边界）

本技能负责：

• 测试存在性检查（缺少关键模块、服务、公共功能的测试文件）
• 覆盖充分性分析（高风险路径覆盖：认证、支付、数据突变）
• 测试质量和结构（安排-行动-断言、有意义的断言、行为而非实现）
• 测试类型和分层（单元、集成、e2e 平衡；模拟/存根隔离）
• 边缘情况和错误路径覆盖（边界条件、无效输入、故障模式）
• 测试可维护性（DRY，不牺牲可读性、夹具组织、脆性测试检测）

本技能不负责：

• 范围选择（决定要分析哪些文件/路径）——范围由调用者提供
• 运行测试或生成覆盖率报告 - 使用“automate-tests”进行测试执行
• 特定于语言/框架的测试约定 - 使用“review-dotnet”、“review-java”、“review-go”等。
• 安全性、性能或架构审查——使用各自的原子技能
• 完整编排式审查——使用“审查代码”

转交点：发出所有测试结果后，将其移交给“审查代码”，以便在精心策划的审核中进行聚合。对于实际运行的测试，请重定向到“automate-tests”。

---

使用场景（用例）

• 精心安排的审查：当orchestrate-code-review运行范围→语言→框架→库→cognitive时用作cognitive步骤。
• 以测试为中心的审查：当用户只想评估测试运行状况和覆盖范围时（例如，在发布之前、主要重构之后或入职期间）。
• 差距分析：识别未经测试的模块、缺失的测试类型（单元/集成/e2e）或提供错误置信度的低质量测试。

何时使用：当任务包括测试审核时。范围和代码范围由调用者或用户确定。

---

行为（行为）

该技能的范围

• 分析：测试给定代码范围中的维度（调用者提供的文件或差异）。不决定范围；接受代码范围作为输入。
• 不要：执行范围选择、语言/框架约定、安全性、性能或架构审查。仅专注于测试。

审查清单（仅测试维度）

1. 测试是否存在：关键模块、服务、公共功能是否有对应的测试文件？是否存在明显的差距，关键逻辑根本没有经过测试？
2. 覆盖率充分性：测试覆盖率对于代码的风险级别是否足够？高风险路径（认证、支付、数据变异）是否经过测试？注意：如果有可用的覆盖率报告或指标，请参考它们；否则进行结构评估。
3. 测试质量和结构：测试结构是否良好（安排-执行-断言或给出-何时-然后）？测试名称是否清楚地描述了场景？断言有意义吗（不仅仅是“不抛出异常”）？测试是否验证行为而不是实现细节？
4. 测试类型和分层：是否有适当的单元、集成和端到端测试组合？单元测试是否隔离（外部依赖项的模拟/存根）？集成测试是否在需要时测试真实的交互？
5. 边缘情况和错误路径：测试是否涵盖边界条件、无效输入、空/空情况、并发场景和预期错误响应？是否明确测试了故障模式？
6. 测试可维护性：测试是否干燥而不牺牲可读性？测试装置和助手是否组织良好？测试是否脆弱（与实现紧密耦合、过度模拟或依赖执行顺序）？测试数据管理是否干净（工厂、构建器或固定装置而不是硬编码的魔法值）？

语气和参考

• 专业和技术：参考具体位置（文件：行或模块）。发出包含位置、类别、严重性、标题、描述、建议的结果。对于未经测试的高风险代码路径使用严重性“主要”或“关键”。

---

输入与输出 (Input & Output)

输入（输入）

• 代码范围：用户或范围技能已选择的文件或目录（或差异）。该技能不决定范围；它仅审查提供的代码以进行测试。

输出（输出）

• 以附录：输出合同中定义的格式发出零个或多个结果。
• 此技能的类别是cognitive-testing。

---

限制（限制）

硬边界（Hard Boundaries）

• 不要执行范围选择、语言、框架、安全、性能或架构审查。保持在测试范围内。
• 不要在没有具体地点或可行建议的情况下给出结论。
• 不需要需要运行测试或生成覆盖率报告。从代码和可用产品（例如现有的覆盖文件）中分析测试充分性。对于实际运行的测试，请使用 automate-tests。
• 不要惩罚缺乏对琐碎代码（简单的 getter、常量、生成代码）的测试，除非它掩盖了真正的风险。

技能边界 (Skill Boundaries)

不要做这些（其他技能可以处理它们）：

• 不要选择或定义代码范围 - 范围由调用者或“审查代码”确定
• 不要运行或执行测试 - 使用“automate-tests”进行测试执行
• 不要执行特定于语言/框架的测试约定分析 - 使用相应的语言技能
• 不要执行安全性、性能或架构分析——使用各自的原子技能

何时停止并交接：

• 当所有测试结果发布后，将其移交给“审查代码”以在精心策划的审查中进行聚合
• 当用户需要实际运行测试时，重定向到“automate-tests”
• 当用户需要全面审查（范围+语言+cognitive）时，重定向到“审查代码”

---

自检（Self-Check）

核心成功标准

• 仅测试范围：仅审查测试维度；未执行范围选择、语言/框架约定、安全性、性能或架构分析
• 涵盖所有六个测试维度：在相关的情况下评估测试存在性、覆盖范围充分性、质量/结构、类型/分层、边缘情况/错误路径和可维护性
• 符合调查结果格式：每个调查结果包括位置、类别（“cognitive-testing”）、严重性、标题、描述和可选建议
• 标记高风险差距：未经测试或测试不充分的高风险代码路径（身份验证、支付、数据突变）被标记为“关键”或“主要”
• 仅从代码进行分析：根据代码结构和可用产品评估测试充分性，无需运行测试或生成覆盖率报告

流程质量检查

• 是否仅审查了测试维度（没有范围/语言/安全/架构）？
• 是否涵盖相关的测试存在性、覆盖范围充分性、质量/结构、类型/分层、边缘情况和可维护性？
• 每个发现是否都包含位置、类别=cognitive-testing、严重性、标题、描述和可选建议？
• 关键差距（未经测试的高风险代码）是否已明确标记并可采取行动？

验收测试

输出是否包含涵盖所有相关维度的测试结果列表，以及适合风险的严重性评级和提高测试覆盖率和质量的可行建议？

---

示例（示例）

示例 1：缺少关键模块的测试

• 输入：没有测试文件的支付处理模块。
• 预期：针对高风险代码缺失测试发出关键发现；建议为核心支付逻辑创建单元测试，并为网关交互创建集成测试。类别 = cognitive-testing。

示例 2：测试存在但很浅

• 输入：身份验证模块有测试，但它们仅涵盖快乐路径（有效登录）并跳过无效凭据、过期令牌、速率限制和帐户锁定。
• 预期：发布边缘情况覆盖不足的重大发现；列出要添加的具体场景。类别 = cognitive-testing。

边缘情况：经过充分测试的代码库

• 输入：模块具有全面的单元、集成和端到端测试，结构清晰，覆盖范围广。
• 预期：发出零结果或建议级别的结果以进行细微改进（例如测试命名一致性）。不要发明问题。