1. 基本信息
| 项目 | 内容 |
|---|---|
| 名称 | ln-23-test-suite-auditor（合集仓库 levnikolaevich/claude-code-skills 内的子技能） |
| 作者/维护者 | levnikolaevich |
| 来源链接 | https://github.com/levnikolaevich/claude-code-skills/tree/master/plugins/codebase-audit-suite/skills/ln-23-test-suite-auditor |
| 许可证 | MIT（GitHub API 实测） |
| GitHub Stars | 522（GitHub API 实测，数字属整个合集仓库，不代表本技能自身热度，详见第 6 章） |
| Forks | 74（GitHub API 实测） |
| 最新版本 | v2026.07.12（2026-07-13 发布，将仓库重构为当前“18 个独立技能”架构的起点） |
| 安装方式 | 插件市场一条命令安装所在的 codebase-audit-suite 套件 |
2. 功能介绍与亮点
ln-23-test-suite-auditor 是一个纯只读的测试组合审计工具：不新增、不修改任何测试代码，只对已存在的测试套件做信任度评估，判断它到底能不能发现真正重要的缺陷。
核心方法论：把测试价值和“能不能跑”分开看。流程分五阶段：① 建立测试全景（识别测试框架、运行器、CI 配置，执行最小代表性测试子集记录通过/失败/跳过情况）；② 审计产品价值与覆盖（把资金、鉴权、数据完整性等关键行为逐一映射到能真正检测对应缺陷的判定依据，而不是仅凭行覆盖率；识别只是重复验证语言/框架/数据库本身行为、未验证仓库自有逻辑的“空转”测试）；③ 审计隔离性与确定性（检查共享数据库/文件系统/全局状态导致的测试间污染，用固定种子/打乱顺序/并行等手段定位 flaky 测试的真实成因）；④ 审计结构与维护成本（找出孤儿测试、失效套件、重复夹具，检查断言强度，标记只做真值判断或仅靠快照的弱判定测试）；⑤ 验证发现并产出报告，将每条发现归类为 KEEP/ADD/UPDATE/DELETE/MERGE 五种处置动作之一。
主要亮点：证据先于结论（覆盖率只是“执行过”的证据，不是“证明过”的证据，每条关键行为都要求有能检测对应缺陷的独立判定依据）；flaky 测试的系统化定位（用最小可区分实验矩阵——单独跑、套件内跑、固定种子重跑、打乱顺序、并行——而非凭经验猜测）；删除/合并有门槛（明文要求“删除建议必须证明有另一个同等或更优信任度的测试覆盖同一行为”，不能因为某条指标数值低就直接建议删除关键回归测试）；结构化输出契约（信心摘要表 + 按 P0-P3 分级的发现列表 + 遗留风险清单）。
3. 适用场景
所属分类：工程效率与代码质量
适合团队对已有测试套件的信心存疑时使用——例如接手一个测试数量不少但说不清“到底测了什么”的项目、怀疑某些测试是摆设或经常无故失败、或想在重构前先弄清楚现有测试到底能不能兜底。它不负责设计新的测试策略，也不负责把测试写出来，而是聚焦在“这些已经存在的测试，到底值不值得信任”这一个环节。
4. 跨 Agent 兼容性
- Claude Code：原生支持——插件市场一条命令安装。
- Codex：原生支持——该插件套件配备独立的
.codex-plugin/plugin.json清单。 - OpenClaw：未验证——现有材料未提及。
- Hermes Agent：未验证——现有材料未提及。
5. 推荐理由
测试数量多不等于测试可信，这个技能把“我们的测试到底靠不靠谱”从一句凭感觉的判断变成一套可复现的审计流程：用独立判定依据筛掉只是重复验证框架行为的空转测试，用最小实验矩阵系统定位 flaky 测试的真实病因而非直接删除或加 retry 掩盖，用“必须证明等价覆盖”的门槛防止误删仅存的关键回归防护。全程只读、不修改测试代码,输出可直接用于排优先级的处置动作列表。
6. 评分
| 维度 | 分数 | 说明 |
|---|---|---|
| 受欢迎程度 | 6 | 所属合集仓库 522 Stars / 74 Forks（GitHub API 实测，数字属整个合集，不代表本技能自身热度）；该子目录当前架构下已有 4 次提交，含一条针对性修复“strengthen test action reviews”（2026-07-19）；GitHub Issue 搜索确认目前尚无专门针对本技能的独立第三方反馈 |
| 可用性 | 8 | 插件市场一条命令即可安装所在套件；SKILL.md 文档结构完整（逐项检查清单、工具路由表、输出格式规范齐全），最近一次提交为 2026-07-19；不涉及任何付费依赖或外部账号 |
| 安全性 | 9 | 见下方检查清单，全部通过且无写操作 |
安全检查清单： ① 权限范围——仅通过仓库已定义的测试命令收集通过/失败证据，SKILL.md 明文声明“只运行安全的测试与诊断命令，不改写快照、不更新 golden 文件、不重新生成夹具、审计期间不接受变更后的输出”，无文件写入或部署类操作； ② 联网外发——仅在核实测试框架/运行器官方语义时查阅官方文档，不外发用户数据； ③ 凭据处理——不需要任何 API Key 或凭据； ④ 可疑指令——全文核验未发现提示注入或混淆代码迹象； ⑤ 作者信誉——单一独立开发者持续维护，未见刷星或 SEO 操纵措辞； ⑥ License——MIT，明确； ⑦ 最近维护——9 天前有提交，仓库整体处于活跃迭代期。
7. 跟同类 Skills 相比的优势
| 对比对象 | 定位 | 与本技能的差异 |
|---|---|---|
| levnikolaevich 出品的 ln-41-test-strategy-planner | 在动手写测试前，产出一份该测什么、测到什么级别的风险驱动计划 | 面向“还不存在的测试”，输出是计划文档；本技能面向“已经存在的测试”，输出是信任度审计结果与处置建议，两者是前后接续但不重叠的环节 |
| Addy Osmani 出品的 test-driven-development | 把红-绿-重构循环固化为编码时的默认工作方式，测试与实现代码同步产生 | 关注的是“如何写”这一开发习惯；本技能关注“已经写出来的测试是否值得信任”，可用于审计任何历史遗留代码库，不要求测试是按 TDD 方式产生的 |
| Trail of Bits 出品的 property-based-testing | 教你判断某个函数是否该写属性测试，并给出多语言生成路径 | 是单一测试技术的写作指南，产出新测试代码；本技能不产出新测试，只对已有测试套件做只读的价值与可信度评估 |
8. 用户评价
该技能目前在第三方平台尚无具名用户评价。
9. 其他补充
安装 ln-23 所在的 codebase-audit-suite 插件会一并装上四个姊妹审计技能：ln-21-documentation-auditor（文档审计）、ln-22-codebase-auditor（横切代码库健康审计）、ln-24-architecture-auditor（架构审计）、ln-25-persistence-auditor（持久层审计），各自可独立触发,互不依赖。
10. 安装使用方式
- 在 Claude Code 或 Codex 中执行：
/plugin marketplace add levnikolaevich/claude-code-skills - 再执行：
/plugin install codebase-audit-suite@levnikolaevich-skills-marketplace - 安装后无需重启，在对话中直接描述“帮我审计一下这个项目的测试套件靠不靠谱”等类似意图即可触发，无需额外配置。
11. 注意事项
- 这是一个纯审计工具，不会新增或修改测试代码——发现问题后仍需人工或配合其他技能（如 ln-42-acceptance-test-builder）落地整改。
- 该仓库历史上经历过多次整体架构调整，当前架构自 2026 年 7 月中旬起保持稳定，但仍处于活跃迭代期，子技能路径未来可能变动。
- 安装命令会一并引入同套件内的另外四个审计技能，如只需要本技能可留意仓库是否提供更细粒度的安装方式。
- SKILL.md 未使用
allowed-tools字段做技术级工具限制，只读边界依赖指令层面约束而非强制沙箱，用户可留意。