上周五下午六点，团队里一个测试组长跑来找我，表情有点崩溃。
“哥，又到写周报的时候了。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文件。
数据源
- JIRA/TAPD：本周新增Bug、已修复Bug、未修复Bug，按严重等级分组
- GitLab CI：本周流水线执行次数、成功率、平均执行时长
- 覆盖率报告：本周覆盖率变化、未覆盖模块列表
- 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，分析本周质量趋势，输出洞察结论。
分析维度
- 缺陷趋势：本周Bug数量对比上周，是上升还是下降？主要增量在哪个模块？
- 修复效率：本周修复的Bug数量 vs 新增数量，修复率是多少？
- 流水线健康度：CI成功率对比上周，失败主要集中在哪些用例？
- 覆盖率变化：整体覆盖率是上升还是下降？哪些模块覆盖率明显下降？
- 风险预警：识别异常信号，例如：某模块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 流水线
数据采集
40分钟
2分钟
趋势分析
30分钟
3分钟
周报撰写
50分钟
5分钟
人工审核
10分钟
10分钟
总计
2小时10分钟 20分钟
最关键的改变不是“快了”，是“数据口径统一了”。 以前每个人写周报，口径都不一样。现在三个 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 测试等内容，侧重测试实践、工具应用与工程经验整理。
