回归执行与分析器

角色定位

本 Skill 是 Phase 5 子 Skill，职责：
1. 通过 Jenkins MCP 触发回归 Job 执行
2. 轮询监控构建状态直至完成
3. 获取回归报告，解析失败用例
4. 分析失败是否为本次变更引入
5. 生成结构化回归报告供上游 qa-integration-pipeline 决策

> 本 Skill 自动执行，不中断询问用户。所有交互交由上游 qa-integration-pipeline 处理。
>
> 执行方式：所有外部工具调用均通过 Jenkins MCP 标准工具（build_item、get_queue_item、get_build、jenkins_get_artifacts、jenkins_download_artifact 等）进行，不直接执行本地命令。

输入参数

执行步骤

Step 0: 知识库查询（可选）

在执行回归分析前，可查询 LLM-Wiki 知识库获取回归测试策略和历史失败分析经验：

POST http://10.190.56.84:8080/search
Content-Type: application/json

{
  "collection": "navi-guide-qa-knowledge",
  "query": "<feature> 回归测试 失败分析 历史回归问题",
  "limit": 5
}

查询时机：
- Step 4 分析失败用例前：查询同类功能的历史失败模式和分类规则
- 判断失败是否本次变更引入时：查询历史遗留问题特征和基线对比经验
- 生成回归报告前：查询回归通过率评估标准和风险判定依据

检索结果应用：
- 参考历史失败分类规则，提升失败用例分类准确性
- 借鉴历史回归问题处理经验，优化报告建议内容

Step 1: 前置校验

1. 校验参数完整性：feature、env、case_branch
2. 确认输出目录结构：<CASE_DIR>/<feature>/reports/

Step 2: 使用 build_item MCP 工具触发回归 Job

Step 2.1: 触发构建

{
  "tool": "build_item",
  "arguments": {
    "fullname": "<job_name>",
    "build_type": "build",
    "params": {
      "env": "<env>",
      "case_branch": "<case_branch>",
      "case_paths": "<case_paths>"
    }
  }
}

> job_name 默认 NG_DataCheck_FT，可通过输入参数覆盖。
> case_paths 为可选参数，用于指定新增 case 路径，若未提供则不传此参数。

Step 2.2: 获取实际构建号

build_item 返回的是 Queue Item ID，需先调用 get_queue_item 获取实际 build_number：

{
  "tool": "get_queue_item",
  "arguments": { "item_id": "<build_item返回的Queue ID>" }
}

返回示例：{"build_number": 70, "result": null, ...}

Step 2.3: 监控构建状态

{
  "tool": "get_build",
  "arguments": {
    "fullname": "<job_name>",
    "number": "<build_number>"
  }
}

轮询直至状态为 SUCCESS、FAILURE 或 UNSTABLE（最多 30 分钟）。

Step 2.4: 获取构建日志（如失败）

{
  "tool": "get_build_console_tail",
  "arguments": {
    "fullname": "<job_name>",
    "number": "<build_number>",
    "max_bytes": 50000
  }
}

Step 2.5: 执行后检查
- 构建状态为 SUCCESS / UNSTABLE → 继续 Step 3
- 构建状态为 FAILURE → 获取日志，记录错误，继续 Step 3（仍有失败用例需要分析）

Step 3: 通过 Jenkins MCP 获取回归报告

Step 3.1: 获取 artifacts 列表

{
  "tool": "jenkins_get_artifacts",
  "arguments": {
    "fullname": "<job_name>",
    "number": "<build_number>"
  }
}

Step 3.2: 下载关键回归产物

依据 artifacts 列表，下载分析所需的文件：

{
  "tool": "jenkins_download_artifact",
  "arguments": {
    "fullname": "<job_name>",
    "number": "<build_number>",
    "artifact_path": "report.json"
  }
}

需下载的文件：

> 下载后转为结构化数据，读取 report.json 作为失败分析输入。

report.json 示例结构：

{
  "total": 100,
  "passed": 95,
  "failed": 5,
  "skipped": 0,
  "failures": [
    {
      "case_id": "test_feature_XXX_001",
      "case_name": "test_s001_continuous_merge_voice",
      "error": "AssertionError: '前方连续路口' not in '...'",
      "stack_trace": "..."
    }
  ]
}

Step 4: 分析失败用例

统计汇总：
- 总用例数 / 通过数 / 失败数 / 跳过数
- 失败率 = 失败数 / 总用例数

判断失败是否为本次变更引入：

对每个失败用例，执行以下判断：

1. 新增 case 失败：
   - 若 case_id 属于本次 case_paths 中的新增 case → 标记为本次变更引入

2. 存量 case 失败：
   - 若 host_baseline 提供 → 对基线服务执行同一用例验证

   • 基线也失败 → 标记为历史遗留问题（非本次引入）
   • 基线通过 → 标记为本次变更引入
   • 若 host_baseline 未提供 → 标记为待确认，需在报告中标注

3. 失败分类：
   - regression：本次变更导致存量功能异常
   - new_case_failure：新增 case 本身未通过
   - flaky：不稳定/偶现失败
   - historical：历史遗留问题

Step 5: 生成报告

5.1 regression_report.json

输出路径：<CASE_DIR>/<feature>/reports/regression_report.json

{
  "feature": "<feature>",
  "build_number": 70,
  "build_url": "...",
  "summary": {
    "total": 100,
    "passed": 95,
    "failed": 5,
    "skipped": 0,
    "pass_rate": "95.0%"
  },
  "failures": [
    {
      "case_id": "test_feature_XXX_001",
      "case_name": "test_s001_continuous_merge_voice",
      "classification": "new_case_failure",
      "is_introduced_by_this_change": true,
      "error": "AssertionError: '前方连续路口' not in '...'",
      "recommendation": "检查 case 预期值是否与目标服务响应一致"
    }
  ],
  "historical_failures": [],
  "regression_count": 0,
  "new_case_failure_count": 5
}

5.2 regression_analysis.md

输出路径：<CASE_DIR>/<feature>/reports/regression_analysis.md

# 回归测试报告 - <feature>

## 执行摘要

| 项目 | 值 |
|------|-----|
| **Jenkins Job** | <job_name> |
| **构建号** | #70 |
| **目标服务** | <env> |
| **case 分支** | <case_branch> |
| **总用例数** | 100 |
| **通过** | 95 |
| **失败** | 5 |
| **通过率** | 95.0% |

## 失败用例分析

### 本次变更引入的失败

| case_id | case_name | 分类 | 错误信息 | 建议 |
|---------|-----------|------|----------|------|
| test_feature_XXX_001 | test_s001_continuous_merge_voice | new_case_failure | AssertionError: ... | 检查 case 预期值 |

### 历史遗留失败

（无）

## 结论

- 回归通过率：95.0%
- 本次变更引入的失败：5 个（全部为新增 case 失败）
- 存量功能回归：无异常
- 建议：✅ 通过（新增 case 失败需单独修复）

Step 6: 返回结果

向 qa-integration-pipeline 返回执行摘要：

{
  "status": "success",
  "pass_rate": "95.0%",
  "total": 100,
  "passed": 95,
  "failed": 5,
  "regression_count": 0,
  "new_case_failure_count": 5,
  "report_path": "<CASE_DIR>/<feature>/reports/regression_report.json",
  "analysis_path": "<CASE_DIR>/<feature>/reports/regression_analysis.md"
}

> 若存在 regression_count > 0（存量功能被本次变更破坏），qa-integration-pipeline 应标记 Phase 5 为 failed 并询问用户是否继续。

产物清单

失败处理

与 qa-integration-pipeline 的协作

qa-integration-pipeline (Phase 5)
    └── 调用 regression-executor-and-analyzer
            ├── 使用 build_item MCP 工具触发 NG_DataCheck_FT Job
            ├── get_queue_item 获取实际构建号
            ├── get_build 轮询等待结果
            ├── 下载并解析回归报告
            ├── 分析失败用例（本次引入 / 历史遗留）
            └── 返回 pass_rate + regression_count
                    └── qa-integration-pipeline 决策：
                            - regression_count == 0 → 标记 success，继续 Phase 6
                            - regression_count > 0 → 标记 failed，询问用户是否继续