上周五下午六点，团队里一个测试组长跑来找我，表情有点崩溃。

“哥，又到写周报的时候了。JIRA里拉了300多条Bug，CI流水线跑了5天，覆盖率报告有十几份，Git提交记录几百条。我得把这些数据一条条复制粘贴到PPT里，再编一段‘本周质量总结’。每次写完都八点多了。”

我问他：“你写周报花了多少时间？”

他说：“两个多小时。关键是，写完了也没人认真看。老板翻两页，问一句‘这周有没有风险’，就结束了。”

我说：“那你有没有想过，让 Agent 替你把数据先整理好？”

他愣了一下：“周报也能自动写？”

我说：“不是自动写，是自动‘整理’。你负责判断，它负责干活。”

一、质量周报为什么这么烦？

先说说质量周报的真实痛点。

一个测试团队的质量周报，数据来源至少有五六个：JIRA/TAPD的缺陷数据、CI流水线的执行结果、覆盖率报告、Git提交记录、线上监控告警、性能测试数据。

每个数据源都在不同的系统里，格式不一样，口径不一样。 JIRA里Bug按严重等级分，CI里用例按模块分，覆盖率报告按文件分。你要把这些数据“翻译”成统一的口径，才能写进周报。

更麻烦的是，周报不是“数据罗列”，是“趋势分析” 。老板想看的不是“这周提了50个Bug”，而是“这周Bug比上周多了20%，主要集中在新上线的支付模块，原因是需求变更频繁”。

数据罗列谁都会，趋势分析才费脑子。

而 Agent Skills 能做的，就是把“数据罗列”这部分自动化，把“趋势分析”留给人。

二、核心思路：三个 Skill 串起周报流水线

我重构后的质量周报流程，核心是三个 Skill：

Skill ①：数据聚合——从各个系统拉数据，统一格式

Skill ②：趋势分析——对比历史数据，识别异常波动

Skill ③：周报生成——按模板输出结构化报告

每个 Skill 单独可用，串起来就是一条从数据到报告的自动化流水线。

三、Skill ①：数据聚合——把散落的数据“归一”

这个 Skill 的核心任务是：把不同系统的数据拉下来，统一成一份结构化的 JSON。

SKILL.md 设计

---
name: quality-data-collector
description: 从JIRA、GitLab CI、覆盖率报告、Git提交记录中采集质量数据，统一输出为结构化JSON。当用户提到“采集质量数据”“拉取周报数据”“汇总测试结果”时触发。
when_to_use: 需要生成本周质量报告时，先运行此Skill采集数据。
allowed-tools: Bash, Read, Write
---

正文写清楚数据源和采集逻辑：

## 任务
从以下数据源采集本周质量数据，输出统一格式的JSON文件。

## 数据源
1. JIRA/TAPD：本周新增Bug、已修复Bug、未修复Bug，按严重等级分组
2. GitLab CI：本周流水线执行次数、成功率、平均执行时长
3. 覆盖率报告：本周覆盖率变化、未覆盖模块列表
4. Git提交：本周提交次数、涉及模块、代码变更行数

## 执行步骤
### 步骤1：调用脚本拉取数据
运行 `scripts/collect_data.py`，脚本会调用各系统API，输出 `raw_data.json`。

### 步骤2：数据清洗与归一
- 统一Bug严重等级：P0/P1/P2/P3
- 统一模块命名：将各系统中的模块名映射到标准模块名
- 统一时间口径：按本周一至本周日统计

### 步骤3：输出结构化数据
输出 `weekly_data.json`，包含：
- 缺陷统计：新增/修复/未修复，按等级和模块分组
- 流水线统计：执行次数、成功率、平均耗时
- 覆盖率变化：整体覆盖率、模块覆盖率、变化趋势
- 代码变更：提交次数、涉及模块、变更行数

## 注意事项
- API调用失败时重试3次，仍失败则记录到 `errors.log`
- 数据缺失时标注“数据缺失”，不要臆造
- 所有时间戳统一为北京时间

配套脚本

scripts/collect_data.py 负责实际的数据拉取。核心逻辑：

import requests
import json
from datetime import datetime, timedelta

def collect_jira_data():
    """从JIRA拉取本周Bug数据"""
    start_date = (datetime.now() - timedelta(days=7)).strftime("%Y-%m-%d")
    # 调用JIRA API，拉取本周新增和修复的Bug
    # 返回结构化数据
    pass

def collect_ci_data():
    """从GitLab CI拉取本周流水线数据"""
    # 调用GitLab API，拉取本周流水线执行记录
    pass

def collect_coverage_data():
    """解析覆盖率报告"""
    # 读取coverage.xml，提取覆盖率数据
    pass

def main():
    data = {
        "jira": collect_jira_data(),
        "ci": collect_ci_data(),
        "coverage": collect_coverage_data(),
    }
    with open("raw_data.json", "w") as f:
        json.dump(data, f, ensure_ascii=False, indent=2)

if __name__ == "__main__":
    main()

这个 Skill 的价值在于：把“人工从五个系统里复制粘贴”变成了“一条命令拉取所有数据”。

四、Skill ②：趋势分析——从“数据”到“洞察”

数据聚合完了，但一堆数字堆在一起，没人看得懂。这个 Skill 负责把数据变成“洞察”。

SKILL.md 设计

---
name: quality-trend-analyzer
description: 基于本周质量数据，对比历史数据，识别异常波动和风险趋势。当用户提到“分析质量趋势”“对比周数据”“识别质量风险”时触发。
when_to_use: 数据聚合完成后，运行此Skill生成趋势分析。
---

正文要求 Agent 做三件事：

## 任务
基于 `weekly_data.json` 和 `history_data.json`，分析本周质量趋势，输出洞察结论。

## 分析维度
1. **缺陷趋势**：本周Bug数量对比上周，是上升还是下降？主要增量在哪个模块？
2. **修复效率**：本周修复的Bug数量 vs 新增数量，修复率是多少？
3. **流水线健康度**：CI成功率对比上周，失败主要集中在哪些用例？
4. **覆盖率变化**：整体覆盖率是上升还是下降？哪些模块覆盖率明显下降？
5. **风险预警**：识别异常信号，例如：某模块Bug激增、覆盖率骤降、CI失败率突升。

## 输出格式
- 趋势总结：3-5条核心结论
- 风险预警：每条风险附数据支撑和建议关注点
- 对比表格：本周 vs 上周关键指标

这个 Skill 的核心价值是“对比”。 单看本周数据没意义，跟上周、上上周对比，才能看出趋势。

五、Skill ③：周报生成——按模板输出

最后一个 Skill，把趋势分析变成一份可读的周报。

SKILL.md 设计

---
name: quality-weekly-report
description: 基于质量数据和趋势分析，生成结构化质量周报。当用户提到“生成周报”“输出质量报告”“写质量总结”时触发。
when_to_use: 数据聚合和趋势分析完成后，运行此Skill生成最终周报。
---

正文定义周报模板：

## 任务
基于 `weekly_data.json` 和 `trend_analysis.json`，生成质量周报。

## 周报结构
### 一、本周概况
- 测试执行：用例总数、通过率、失败数
- 缺陷统计：新增/修复/未修复，按等级分布
- 覆盖率：整体覆盖率、变化趋势

### 二、重点风险
- 风险描述
- 数据支撑
- 建议关注点

### 三、模块质量排名
- 按缺陷密度排序
- 按覆盖率变化排序

### 四、下周计划
- 重点测试模块
- 需要补充的测试场景

## 输出格式
Markdown文档，可直接复制到飞书/钉钉/邮件。

## 注意事项
- 不要罗列所有数据，只展示关键指标
- 风险描述要具体，不要写“建议加强测试”这种空话
- 所有结论必须有数据支撑

关键原则：周报不是数据导出，是决策辅助。 老板看周报，不是想知道“这周提了多少Bug”，而是想知道“这周质量有没有风险、下周该关注什么”。

六、把三个 Skill 串起来

在 CI 里配置一个定时任务，每周五下午自动运行：

weekly-report:
  stage:report
script:
    -claude--skillquality-data-collector--outputweekly_data.json
    -claude--skillquality-trend-analyzer--inputweekly_data.json--outputtrend_analysis.json
    -claude--skillquality-weekly-report--inputweekly_data.json,trend_analysis.json--outputweekly_report.md
    -pythonscripts/send_to_feishu.pyweekly_report.md
only:
    -schedules

跑通之后，每周五下午，飞书群里自动弹出一份质量周报。测试组长只需要花10分钟审核，确认没有误判，然后转发给老板。

七、实测数据

我们团队用了两个月，数据对比：

最关键的改变不是“快了”，是“数据口径统一了”。 以前每个人写周报，口径都不一样。现在三个 Skill 固定了数据采集和分析逻辑，谁跑出来的结果都一样。

八、避坑指南

坑一：Skill 粒度拆得太细。 数据采集、趋势分析、报告生成，三个 Skill 刚好。拆成五个以上，AI 就不知道该用哪个了。

坑二：description 写得太空。 “帮助生成周报”——等于没写。要写清楚触发条件：用户提到“生成周报”“输出质量报告”时触发。

坑三：SKILL.md 超过 500 行。 详细的周报模板放到
references/weekly-template.md，SKILL.md 只留核心流程。

坑四：指望全自动，不设人工复核。 AI 趋势分析是“预判”，不是“判决”。我们永远在流程末尾设一个人工审核节点。AI 负责把数据整理好，人负责确认结论是否合理。

坑五：不做 Skill 的回归测试。 模型版本一变，Skill 行为可能漂移。用 skill-up 给 Skill 写评测用例，每次修改后跑一遍，确保输出格式和逻辑不变。

最后

质量周报不是“写给老板看的文档”，是“团队质量管理的工具”。

以前写周报，是“数据搬运工”——从五个系统里复制粘贴，拼成一份PPT。现在写周报，是“质量分析师”——审核 AI 整理好的数据，确认风险判断是否准确。

Agent Skills 把“搬运”自动化了，把“分析”留给了人。

下次又到写周报的时候，别打开 JIRA 了。让三个 Skill 跑一遍，你只需要花十分钟审核。

你不需要再当数据搬运工。你只需要当那个做判断的人。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。