QA Radar

QA Radar

为你的 AI 编码 Agent 提供无需从头培养的质量洞察力。

QA Radar 会分析你的代码库并生成结构化的质量健康报告——将 git 变更频率、测试覆盖率和测试到源代码的映射结合起来，为各个模块评定风险分数。它既可作为 AI 编码 Agent（Claude Code、Cursor、Windsurf）的 MCP 服务，也可作为供开发者和 CI 流水线使用的 独立 CLI。

专为希望 AI Agent 编写有针对性测试，而非泛泛测试的开发者打造。

快速开始

Claude Code——一步完成：

/plugin marketplace add Muratkus/qaradar
/plugin install qaradar@qaradar-marketplace

然后询问你的 Agent：“我应该先测试什么？”

或者无需安装，直接运行：

uvx qaradar serve

完整安装选项 ↓

功能介绍

QA Radar 回答每位新团队成员（以及每个 AI Agent）都会提出的问题：“我应该先测试什么？”

它会扫描三个信号，并将它们综合为每个文件的风险分数：

信号	衡量内容	重要性
Git 变更频率	提交频率、变更行数、最近变更时间	频繁变更的文件容易引发回归问题
覆盖率缺口	现有报告中的行覆盖率和分支覆盖率	覆盖率低意味着存在盲区
测试映射	哪些源文件有对应的测试	没有测试就完全缺乏安全保障

输出是一份按风险等级（从高到低）排列的模块列表，并为每个评级提供易于理解的原因。

为什么不直接让 Agent 来做？

一个能够访问 bash 的强大 Agent 可以运行 git log --numstat、解析 coverage.xml，并搜索测试文件。那么，为什么还需要 MCP 服务？

考量	QA Radar 的处理方式
令牌成本	在中等规模的仓库中，运行 90 天的 git log 会产生数百 KB 的内容。QA Radar 返回约 5 KB 的结构化 JSON。
确定性	在上下文中临时计算加权风险分数并不可靠。代码可以保证结果可复现。
速度	一次工具调用即可完成，而不是依次进行 4–6 次 bash 调用，并在每次调用之间推理。
格式规范化	LCOV / Cobertura / coverage.py JSON / Go cover 配置文件的解析方式各不相同。QA Radar 会统一处理这些格式，无需 Agent 亲自处理。
约定编码	Python 使用 test_x.py，JS/TS 使用 x.test.ts，Go 使用 x_test.go，Java 使用 FooTest.java——约定只需编码一次，无需每次会话重新推断。
可移植性	同一组 MCP 工具可用于 Claude Code、Cursor 和 Windsurf，无需重新提示。

安装为 Claude Code 插件（推荐）

最快捷的方式——一条命令即可配置 MCP 服务并安装 4 个斜杠命令。无需手动编辑配置。

步骤 0——安装 uv（如果尚未安装）：

curl -LsSf https://astral.sh/uv/install.sh | sh
# or: pip install uv

uv 会按需从 PyPI 启动 qaradar，无需另行运行 pip install qaradar。

步骤 1——添加市场：

/plugin marketplace add Muratkus/qaradar

步骤 2——安装：

/plugin install qaradar@qaradar-marketplace

你将获得： 自动配置的 6 个 MCP 工具 + 5 个斜杠命令：

命令	功能
/qaradar:qa-check	完整健康报告——风险、覆盖率、未测试文件
/qaradar:qa-risky	按风险从高到低排列的文件列表及原因
/qaradar:qa-untested	未检测到测试的源文件 + 脚手架建议
/qaradar:qa-plan	优先级测试计划（串联 3 个工具）
/qaradar:qa-pr-risk	此 PR 中变更文件的风险排序

示例： 合并大型功能分支后，运行 /qaradar:qa-check 查看出现了哪些回归问题。提交 PR 前，运行 /qaradar:qa-pr-risk 查看应优先测试哪些内容。

MCP 服务（适用于 AI 编码 Agent）

设置

替代方案：手动配置 MCP（如果你不想使用插件）：

将以下内容添加到 Claude Code MCP 配置中（用户级配置位于 ~/.claude/mcp.json，项目级配置位于项目根目录中的 .mcp.json）：

{
  "mcpServers": {
    "qaradar": {
      "command": "uvx",
      "args": ["qaradar", "serve"]
    }
  }
}

或者手动启动：

uvx qaradar serve

示例提示词

连接后，向 Agent 提问：

"在这个代码库中，我应该先测试什么？" "目前哪些文件的风险最高？" "列出上个月改动最频繁的文件。" "哪些源文件完全没有测试？" "我修改的哪些文件有风险？" ← 感知差异

可用的 MCP 工具

工具	Agent 使用时机
qaradar_healthcheck	全面了解代码库质量
qaradar_risky_modules	确定优先测试内容；找出风险最高的文件
qaradar_churn	检测热点；找出容易出现回归问题的位置
qaradar_coverage_gaps	查找覆盖率低的文件；找出测试盲区
qaradar_untested_files	查找没有对应测试文件的源文件
qaradar_pr_risk	确定此 PR 中哪些变更文件需要关注
qaradar_should_run	完成工作后，确定 QA Radar 是否应该重新分析，以及分析差异还是整个代码库

感知差异：此 PR 中有什么风险？

qaradar_pr_risk 只对基础引用与 HEAD 之间发生变更的文件进行评分，而不是整个代码库。它使用全代码库归一化来校准风险分数，因此不会仅仅因为 Agent 知道的唯一变更文件只有一个，就把 PR 中有 2 次提交的文件错误地标记为 CRITICAL。

向 Agent 提问：

"我修改的哪些文件有风险？" "我修改的文件中，有没有缺少测试的？" "打开此 PR 前，我应该检查什么？"

或者从 CLI 运行：

# Diff against main — shows only changed files
qaradar analyze . --base main

# Diff against a specific ref
qaradar analyze . --base origin/main --days 60

qaradar_pr_risk 会从 GITHUB_BASE_REF（在 GitHub Actions 中自动设置）自动检测基础分支，否则会回退到 main/master。显式传入 base_ref 可覆盖此设置。

CLI

# Full health check on current directory
qaradar analyze

# Analyze a specific repo with 180 days of history
qaradar analyze /path/to/repo --days 180

# Output as JSON (for piping to other tools)
qaradar analyze --json-output

# Show top 10 risky modules only
qaradar analyze --top 10

# Diff-aware: score only files changed since main
qaradar analyze . --base main

安装

pip install qaradar

也可以不安装直接运行：

uvx qaradar serve

从源码安装（用于开发）：

git clone https://github.com/Muratkus/qaradar.git
cd qaradar
pip install -e .

语言支持

所有语言支持都集中在一个注册表中——qaradar/analyzers/languages.py——因此添加一种语言只需添加一个条目（扩展名、测试命名约定、测试函数计数器），由变更频率分析和测试映射共同使用。

第 1 级——一流支持，经过测试

语言	测试检测	覆盖率
Python	test_x.py、x_test.py	coverage.py JSON + XML
JavaScript / TypeScript	x.test.*、x.spec.*、x-test.*（React Native）	LCOV、Jest/Istanbul JSON
Go	x_test.go	Go 覆盖率配置文件（cover.out）
Swift	XTests.swift（XCTest func test…）	Cobertura / LCOV
Kotlin	XTest.kt（@Test）	Cobertura / LCOV
Dart / Flutter	x_test.dart（test(、testWidgets(）	LCOV（coverage/lcov.info）
Objective-C	XTests.m / .mm（XCTest - (void)test…）	Cobertura / LCOV

第 2 级——尽力支持，基于命名约定

Java、Ruby、Rust——通过命名约定检测测试。如果生成了 Cobertura XML 或 LCOV 格式的覆盖率数据，则可读取。

覆盖率解析由格式驱动，因此支持的生态系统范围比特定于语言的测试映射检测更广。

单体代码库： 会自动发现 packages/*/coverage 和 apps/*/coverage 下的 Istanbul/Jest 报告，并将绝对路径和相对于包的覆盖率路径规范化为相对于代码库的路径，以便与变更频率和测试映射信号正确关联。

支持的覆盖率格式

格式	工具
coverage.py JSON	Python coverage run + coverage json
Istanbul / Jest JSON	coverage-final.json、coverage-summary.json（Jest/Vitest/nyc）
Cobertura XML	Python、Java/Gradle、.NET（Coverlet）
LCOV	JS/TS、Flutter/Dart、C/C++、Rust（grcov）
Go 覆盖率配置文件	go test -coverprofile=cover.out

输出示例

╭──────────────── QA Radar Health Report ─────────────────╮
│ Repository: /home/user/my-service                       │
│ Source files: 47  Test files: 23  Ratio: 0.49           │
│ Avg coverage: 62.3%  Tested: 31  Untested: 16          │
╰─────────────────────────────────────────────────────────╯

  CRITICAL risk modules: 3
  HIGH risk modules: 7

┌─────────────────────────────────────────────────────────┐
│ Risky Modules                                           │
├──────────────────────┬──────────┬───────┬───────────────┤
│ File                 │ Risk     │ Score │ Reasons       │
├──────────────────────┼──────────┼───────┼───────────────┤
│ src/payments/core.py │ CRITICAL │  0.87 │ High churn:   │
│                      │          │       │ 34 commits;   │
│                      │          │       │ No tests      │
│ src/auth/tokens.py   │ CRITICAL │  0.82 │ Low coverage: │
│                      │          │       │ 12.3%; Active │
│                      │          │       │ recently      │
└──────────────────────┴──────────┴───────┴───────────────┘

跨运行跟踪

默认情况下，QA Radar 不保存状态。启用持久化后，即可跨多次运行跟踪一个代码仓库， 并进行增量重新分析（每天／每周，或每 N 次差异后，或 Agent 完成工作后）。

qaradar analyze . --save      # record a snapshot to .qaradar/state.json (gitignore it)
qaradar should-run .          # exit 0 if a re-run is warranted, 1 if not — prints JSON
qaradar status .              # last run, commits/days since, current decision + risk delta

should-run 是一个门控机制，而非调度器——请将其接入你现有的工具：

# cron / CI / git hook: only do expensive work when criteria are met
qaradar should-run . && qaradar analyze . --save

它会报告 scope: "full"（间隔已到）或 scope: "diff"（更改的文件数已达到要求）， 这样调用 qaradar_should_run MCP 工具的 Agent 就知道是否应继续调用 qaradar_healthcheck 或 qaradar_pr_risk。每个代码仓库的状态都存放在一个 .qaradar/state.json 文件中， 因此，“代码仓库集合”只需在你自己的基础设施中遍历各个代码仓库即可。

在 qaradar.toml 中调整条件：

[schedule]
interval_days = 7        # re-run the full healthcheck at least weekly
min_changed_files = 25   # ...or sooner, once this many files have changed

--save 还会报告相对于上次运行的变化——哪些文件新近变得有风险、哪些风险加剧、哪些情况有所改善或已解决。

路线图

• v0.1.2 — Claude Code 插件 + 斜杠命令
• v0.2.0 — 配置文件（qaradar.toml）、Tier 2 语言验证、加固
• v0.3.0 — 感知差异的模式：qaradar_pr_risk + --base CLI 标志
• v0.4.0 — 移动端／单体仓库语言覆盖（Swift、Kotlin、Obj-C、Dart、React Native、Jest）；运行持久化 + 重新运行条件（should-run、--save、qaradar_should_run）
• v0.5.0 — 基于 CI 历史记录检测不稳定测试（解析 JUnit XML）

理念

QA Radar 建立在三个信念之上：

1. 瓶颈已经转移。 AI 让编写测试变得容易。真正困难的是知道哪些测试至关重要。
2. 质量是一片景观，而不是一个数字。 单一的覆盖率百分比会掩盖一切。风险因模块、信号和时间范围而异。
3. Agent 需要上下文。 不了解代码仓库脆弱区域的 AI 编码助手只会编写通用测试。为它提供质量全景，它就能编写有针对性的测试。

许可证

MIT