analyzing-test-failures

分析测试失败

类型： 纯推理——不调用系统，不编写代码。

功能： 解析测试失败或 Code Analyzer 违规信息，并用通俗语言进行说明，然后针对每项失败的测试，提供具体且按优先级排列的改进建议——包括每项修复应针对测试还是生产代码。绝不向用户暴露原始 JSON、堆栈跟踪或 API 错误正文。

---

前置条件

如果需要自行获取失败信息，而不是直接接收，请先加载 checking-devops-prerequisites，然后使用 polling-test-results 获取执行结果。如果信息已在上下文中，则无需前置条件——这属于纯推理。

---

输入

• 由 polling-test-results 技能提供的 JSON 失败信息，或直接从测试运行或 Code Analyzer 执行结果粘贴到上下文中的信息。每项失败的测试具体需要：
  • 测试方法名称
  • 失败消息（断言错误或异常文本）
  • 失败类别（断言失败、未处理异常、超时、编译错误）

---

空组织／无数据的情况

如果信息中没有失败或违规，请明确说明（例如：“提供的执行结果中未发现失败。”），然后停止。没有失败或违规时，切勿捏造失败、违规或改进建议。

---

推理步骤

1. 确定失败类别：

   类别	说明
   断言失败	测试断言失败（预期值与实际值不匹配）
   异常	抛出了未处理的异常
   Code Analyzer 违规	违反了静态分析规则（例如 ApexCRUDViolation、ApexSharingViolations）
   超时	测试超出执行时间限制
   编译错误	类未能编译

2. 对每项失败，提取信息并转述为通俗语言：

   • 出错的文件和类名称
   • 方法名称
   • 行号
   • 以通俗语言说明违反了什么规则或断言
   • 建议的修复方向（不编写代码）

3. 如果失败不止一项，按类别对其分组。

---

输出格式

Test failure summary:

<N> failure(s) found:

1. [<Category>] `<ClassName>.cls` — `<methodName>()` at line <N>
   What happened: <plain-language description>
   Rule violated: <ruleName or assertion description>
   Fix direction: <plain-language suggestion>

2. [<Category>] `<ClassName2>.cls` — `<methodName2>()` at line <N>
   ...

---

Code Analyzer 违规

对于违规，始终包含：

• 用通俗语言说明规则名称（例如，“ApexCRUDViolation” → “执行 SOQL 查询前未检查对象级权限”）
• 确切的行号
• 修复方向（例如，“在查询前添加 Schema.sObjectType.Account.isAccessible() 检查”）

---

通俗语言规则

切勿在输出中粘贴原始堆栈跟踪、JSON 信息或 Salesforce 内部错误代码。始终将其转述为文件名、方法、行号和通俗说明。

---

提出改进建议

仅在测试执行完毕且存在失败后调用本节，不要针对静态源代码调用。失败消息是首要依据——它说明了测试预期与实际发生的情况，可直接帮助判断测试需要如何改进。

1 — 阅读每条失败消息

针对执行结果中的每项失败测试，提取：

• 测试方法名称
• 失败消息（断言错误或异常消息）
• 失败类别（断言失败、未处理异常、超时、编译错误）

2 — 推断测试未处理的情况

根据失败消息推断根本原因模式：

失败模式	改进建议
NullPointerException	测试未处理空值输入 — 添加空值检查，或设置测试数据以确保数据存在
Assertion failed: expected X but was Y	断言中的预期值有误，或测试数据设置未能生成正确状态
List has no rows for assignment	测试查询了不存在的数据 — 测试设置不完整
System.LimitException: Too many SOQL queries	测试触及了 governor 限制 — 被测代码或测试设置执行了过多查询
Insufficient access rights on cross-reference id	测试用户缺少所需权限 — 测试需要以具有适当配置文件或权限集的用户身份运行
DML currently not allowed	测试在从不允许执行 DML 的上下文调用的方法中执行了 DML
Code Analyzer 违规消息	生产代码违反了特定规则 — 测试揭示了这个问题，但应在生产代码中修复，而不是修改测试

3 — 给出可执行的建议

对于每项失败，请用通俗的语言说明：

• 该失败揭示了测试未处理的情况
• 具体需要添加或更改什么，才能使测试更稳健
• 修复应在测试中进行（断言、设置、权限），还是在生产代码中进行（测试正确，但被测代码存在问题）

不要重写测试。只说明需要更改什么以及原因。

改进建议的输出格式

Test improvement suggestions based on execution results:

`<testMethodName>()` — [Assertion Failure / Exception / etc.]
Failure: "<failure message>"
What this reveals: <plain-language explanation>
Suggestion: <specific, actionable recommendation>
Fix location: Test | Production code

`<testMethodName2>()` — [NullPointerException]
Failure: "Attempt to de-reference a null object"
What this reveals: The test is calling the method without setting up the required input data
Suggestion: Add test data setup for <object/field> before calling the method
Fix location: Test

Overall: <N> improvement(s) across <M> failed test(s).

修复测试还是修复生产代码

标记为修复位置：生产代码的建议，表示测试揭示了代码缺陷 — 测试逻辑本身是合理的。这些问题不应以测试质量为由阻碍套件晋级；应将其作为生产缺陷单独跟踪。

标记为修复位置：测试的建议，表示测试需要加强 — 缺少设置、断言错误，或对边缘情况的覆盖不足（空值输入、大批量记录、混合权限上下文、governor 限制边界）。

---

相关技能

• polling-test-results — 获取传递给此技能的失败负载。
• creating-fix-work-item — 根据分析输出创建受跟踪的修复事项，或在用户决定采取行动后，将已批准的改进建议作为工作事项进行跟踪。