关于 test-and-fix
test-and-fix 是面向开发者和编码 Agent 的软件测试技能，按流程分析变更、制定并执行测试计划，并通过回归测试覆盖修复。
主要功能
- 01分析变更及其调用方
- 02按行为制定测试计划
- 03记录测试执行与结果
- 04最小化修复并添加回归测试
- 05报告验证缺口
适用场景
- 01测试变更后的 API 或库
- 02检查命令行参数与文件影响
- 03验证 Web UI 交互
- 04诊断并覆盖测试失败
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/test-and-fix确认已加载。
详细介绍
前言
阅读用户要求的测试范围和命令、项目说明、测试配置及相关源文件。若项目现有的交付记录或任务记录有助于明确预期行为，请使用这些记录。
确定目标：Web UI、API、命令行工具、库或其他产物。可在当前分支（包括基分支）上运行测试。编辑前检查现有更改。
阶段 1 — 分析更改内容
优先使用提供的范围。测试更改时，检查相关的已暂存、未暂存或已提交差异，并追踪其调用方和使用方。根据任务或仓库配置确定比较引用；只有在比较需要更新远程信息时才执行 fetch。
梳理受影响的行为：
- Web UI：页面、组件、交互和渲染状态。
- API：端点、身份验证、输入、响应和错误。
- CLI：参数、输入/输出、退出代码和文件影响。
- 库：公开函数、调用方、返回值和边界情况。
对于需要运行服务的测试，请从项目配置、文档或现有进程输出中查找启动命令和地址。在任务授权范围内启动所需的本地服务。只有在无法根据现有证据确定必要信息时才询问。
阶段 2 — 制定测试计划
针对每项受影响的行为，确定预期结果、测试方法和优先级。纳入相关的正常、无效输入、空值和失败情况。使用项目现有的测试命令和验证要求，并遵循 software-engineering-guidelines 中的测试策略。
根据请求和相关任务记录交叉检查计划。若计划不符，应澄清预期行为，而不是擅自更改测试范围。
阶段 3 — 执行测试
使用选定的测试执行阶段 2 中的计划。对于 Web UI 更改，在运行中的应用中检查受影响的渲染和交互。根据项目规则运行完整测试套件。
对于每项测试：
- 通过 — 说明验证了什么
- 失败 — 说明具体症状和证据
- 意外情况 — 说明任何计划外情况
阶段 4 — 修复循环
对于每项失败，先查明根本原因。如果无法根据所测试的更改和证据确定根本原因，则调用 investigate。
- 添加或更新回归测试，确保不应用修复时测试失败、应用修复后测试通过。遵循 software-engineering-guidelines 中关于时机的规定：重大或高风险更改应先编写测试；小型、局部且低风险的修复可在实现前或实现后立即添加测试。
- 进行最小限度的修复，然后重新运行失败用例和相关回归检查。
- 按照用户指示和项目惯例提交。如果未指定提交安排，则保留原有默认做法：单独提交修复，然后单独提交回归测试。先编写测试和之后再提交测试是两个独立的决定。仅暂存预期更改，保留无关工作。
每个已修复的缺陷都需要回归覆盖。明确报告验证缺口。
报告
## Test Report [feature/branch] [date]
### Summary
Tests run: N | Passed: N | Failed: N | Fixed: N (with regression tests)
### Changes tested
- [target/behavior] — [result]
### Bugs found & fixed
1. [description] — file:line — regression test: [test name]
### Issues found (not yet fixed)
1. [P0/P1/P2] [description] — blocking: [yes/no]
### Regression tests added
- [test file]: [test names]
### Recommendation
[SHIP / FIX FIRST / INVESTIGATE]
测试框架引导（如果不存在测试）
检查内置语言工具、现有脚本或小型可复现测试能否验证该行为。只有在测试框架能提供必要能力时才使用；根据任务授权，在引入之前说明依赖和设置方面的影响。
可复现检查必须实际执行相关行为，并能在未应用修复时暴露缺陷。如果验证仍受阻，应报告缺少的能力，而不是将未经验证的修复视为已完成。遵循上述提交安排；采用默认安排时，单独提交测试框架设置。