用途
analyzing-test-failures 是一个纯推理技能，用于解析测试失败或 Code Analyzer 违规的载荷，并输出通俗语言的解释与改进建议。它不进行系统调用，也不编写代码。
主要能力
- 解析测试失败或 Code Analyzer 违规的 JSON 载荷，生成通俗语言说明。
- 针对每个失败测试给出具体、按优先级排序的改进建议，并标明修复属于测试还是生产代码。
- 从不向用户暴露原始 JSON、堆栈跟踪或 API 错误体。
使用方式
前置条件
如果需要自行获取失败载荷而非直接接收，应先加载 checking-devops-prerequisites，再使用 polling-test-results 获取执行结果。如果载荷已在上下文中，则无需前置条件——这是纯推理。
输入
由 polling-test-results 技能提供的 JSON 失败载荷，或直接从测试运行或 Code Analyzer 执行粘贴到上下文中的载荷。每个失败测试具体需要：
- 测试方法名
- 失败消息（断言错误或异常文本）
- 失败类别（断言失败、未处理异常、超时、编译错误）
空组织/无数据情况
如果载荷中没有失败或违规，应清楚报告（例如“No failures found in the provided execution results.”）并停止。当不存在失败、违规或改进建议时，不得编造。
推理步骤
- 确定失败类别：
| 类别 | 描述 |
|---|---|
| 断言失败 | 测试断言失败（期望值与实际值不匹配） |
| 异常 | 抛出了未处理的异常 |
| Code Analyzer 违规 | 违反了静态分析规则（例如 ApexCRUDViolation、ApexSharingViolations） |
| 超时 | 测试超出执行时间限制 |
| 编译错误 | 类编译失败 |
- 对每个失败，提取并翻译为通俗语言：
- 涉及的文件和类名
- 方法名
- 行号
- 违反的规则或断言，用通俗语言描述
- 建议的修复方向（不编写代码）
- 如果存在多个失败，按类别分组。
输出格式
测试失败摘要：
<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” → “A SOQL query was made without checking object-level permissions first”）
- 确切的行号
- 修复方向（例如“Add a Schema.sObjectType.Account.isAccessible() check before the query”）
通俗语言规则：
绝不将原始堆栈跟踪、JSON 载荷或内部 Salesforce 错误代码粘贴到输出中。始终翻译为文件名、方法、行号和通俗描述。
提出改进建议
在测试执行完成且存在失败后调用此部分，而不是针对静态源代码。失败消息是主要信号——它描述测试期望什么与实际发生了什么，直接说明测试需要更好地处理什么。
- 阅读每个失败消息
对执行结果中的每个失败测试，提取：
- 测试方法名
- 失败消息（断言错误或异常消息）
- 失败类别（断言失败、未处理异常、超时、编译错误）
- 推断测试未处理的内容
根据失败消息推理，识别根本原因模式：
| 失败模式 | 改进建议 |
|---|---|
| NullPointerException | 测试未处理空输入——添加空检查或确保数据存在的测试设置 |
| Assertion failed: expected X but was Y | 断言中的期望值错误，或测试数据设置未产生正确状态 |
| List has no rows for assignment | 测试查询的数据不存在——测试设置不完整 |
| System.LimitException: Too many SOQL queries | 测试触及调控器限制——被测代码或测试设置进行了过多查询 |
| Insufficient access rights on cross-reference id | 测试用户缺少所需权限——测试需要以具有适当配置文件/权限集的用户运行 |
| DML currently not allowed | 测试在从不允许的上下文调用的方法中执行 DML |
| Code Analyzer violation message | 生产代码违反了特定规则——测试暴露了它，但修复在生产代码中，而非测试中 |
- 生成可操作的建议
对每个失败，用通俗语言描述：
- 失败揭示了测试未处理什么
- 具体应添加或更改什么以使测试健壮
- 修复是在测试中（断言、设置、权限）还是在生产代码中（测试正确但被测代码有问题）
不要重写测试。只描述需要更改什么以及为什么。
改进建议的输出格式：
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).
测试修复与生产代码修复
标记为 Fix location: Production code 的建议表示测试暴露的代码缺陷——测试逻辑本身是合理的。这些不应以测试质量为由阻止套件推广；应作为生产缺陷单独跟踪。
标记为 Fix location: Test 的建议表示测试需要加固——缺少设置、断言错误、边缘情况覆盖不足（空输入、批量记录量、混合权限上下文、调控器限制边界）。
适用场景
- 测试执行完成后存在失败，需要通俗语言解释与改进建议。
- 需要解析 Code Analyzer 违规载荷并给出修复方向。
- 需要区分修复应落在测试代码还是生产代码。
限制
- 纯推理，不进行系统调用，不编写代码。
- 不重写测试，只描述需要更改什么以及为什么。
- 不暴露原始 JSON、堆栈跟踪或 API 错误体。
- 无失败或违规时不得编造。
相关技能
- polling-test-results — 获取输入到此技能的失败载荷。
- creating-fix-work-item — 用于从分析输出创建跟踪的修复项，或在用户决定采取行动后将批准的改进建议作为工作项跟踪。