Test Workflow

Test Workflow Skill

Overview

本 Skill 用于处理通用测试任务。

它的目标不是机械补几个简单 case，而是让 Agent 在任何项目、任何语言、任何框架里，面对测试任务时都按稳定流程思考：先理解要验证的业务行为，再判断测试层级，再设计覆盖重点，最后给出真实结果、测试缺口和剩余风险。

它的职责是：

• 根据需求、bug、task、spec、plan 或代码变更识别需要验证的行为
• 判断应优先使用哪种测试层级
• 从正常路径、异常路径、边界路径和回归风险推导测试场景
• 结合当前仓库已有测试风格与规则落地测试
• 输出结构化测试结论，而不是只给零散 case 或模糊表态

本 Skill 不绑定具体项目、具体目录结构、具体语言、具体测试框架、具体 mock 工具或具体运行命令。

Trigger Conditions

以下场景优先触发本 Skill：

• 用户要求 test
• 用户要求 testing
• 用户要求 write tests
• 用户要求 add tests
• 用户要求 fix tests
• 用户要求 unit test
• 用户要求 integration test
• 用户要求 api test
• 用户要求 contract test
• 用户要求 e2e test
• 用户要求 regression test
• 用户要求分析 test coverage
• 用户要求补充测试验收
• 用户要求根据需求、spec、plan、task 或 bug 修复补测试
• 当前任务已经进入测试、验证、验收阶段

以下场景通常不需要单独触发本 Skill：

• 纯文档修改
• 纯注释修改
• 纯格式整理且无行为变化
• 只要求解释代码而不涉及测试设计、测试实现或测试结论

Core Goals

测试不是为了追求数量，而是为了验证：

• 业务行为是否成立
• 关键边界是否被正确处理
• 异常路径是否被正确拦截
• 这次改动是否引入回归风险
• 现有实现是否需要更高层级的验证才能证明正确

执行测试任务时，优先回答以下问题：

1. 要验证什么行为？
2. 哪些路径最容易出错？
3. 哪些边界条件必须覆盖？
4. 这次改动可能影响哪些旧逻辑？
5. 应该使用哪种测试层级完成验证？

Hard Rules

• 不要因为“先补几个简单 case”更快，就只覆盖 happy path。
• 不要在没有依据的情况下声称“无需测试”。如果确实没有行为变化，或用户明确要求跳过测试，必须说明依据和风险。
• 优先选择能够直接证明目标行为的最低充分测试层级；当低层级不足以证明正确性时，再向更高层级扩展。
• 如果仓库中已经存在测试写法、命名习惯、目录结构或测试工具约定，优先保持一致。
• 如果测试所需的环境、输入、鉴权、测试数据、外部依赖或预期契约不完整，必须停下来请求补充，不能编造。
• 日志打印、临时脚本、无断言代码、手工点击结果或“看起来没报错”都不能代替测试结论。
• 完成测试任务后，必须明确说明：新增了什么测试、覆盖了什么场景、用了什么测试层级、还有哪些未覆盖风险、如何运行或复现。

Test Level Decision

单元测试

适用于：

• 纯业务逻辑
• 工具函数或工具模块
• 领域服务或规则计算
• 条件分支较多的函数
• 不依赖外部系统即可稳定验证的行为

集成测试

适用于：

• 涉及数据库、缓存、文件系统、消息系统或其他基础设施
• 涉及多个模块协作
• 需要验证框架配置、依赖装配或真实集成边界
• 仅靠依赖替身不足以证明行为正确

API / Contract 测试

适用于：

• 需要验证接口入参与出参
• 需要验证鉴权、错误码、状态码、错误信息或兼容性
• 需要验证分页、排序、过滤、协议字段语义
• 需要验证接口契约，而不只是内部实现

端到端测试

适用于：

• 需要验证完整业务流程
• 涉及多个系统、多个页面、多个服务或多个步骤联动
• 只有从用户视角或完整链路视角才能证明正确性

回归测试

回归测试不是独立层级，而是一种目标，可叠加在任意层级上。

优先考虑回归测试的场景：

• bug 修复
• 历史功能改造
• 公共方法修改
• 共享模块修改
• 影响范围不明确的重构

决策原则

• 先选能够直接证明目标行为的主测试层级。
• 当单一层级不足以覆盖风险时，可以组合测试，但必须说明主次和原因。
• 不要因为“更容易写”就默认选某种测试。
• 不要说“都测一下”却不给优先级和可执行内容。

Workflow

1. 建立上下文

• 阅读当前需求、bug 描述、spec、plan、task、代码 diff 或用户补充说明。
• 识别本次改动对应的核心业务行为。
• 识别影响范围，例如：模块、服务、接口、数据流、任务流、页面流、后台作业、共享库或公共函数。
• 查找当前改动附近已有测试，理解项目现有测试风格。
• 如果仓库存在架构文档、测试规则、语言规则、框架规则或任务文档，只读取当前任务命中的最小必要范围。
• 基于当前改动先拆出“功能点 -> 测试场景 -> 预期结果”的初始清单，作为后续执行和结果回填的骨架。

2. 判断是否允许跳过测试

• 检查用户是否明确表达过以下意思之一：
• 不要测试
• 跳过测试
• 本轮不用测
• 只改代码不要跑测试
• 如果用户明确要求跳过测试，则：
• 不新增测试、不运行测试、不伪造测试结果
• 输出“按用户要求跳过测试”
• 同时写明用户要求、被跳过的测试项、当前风险
• 如果当前任务有 task 文档或交付文档，需要把跳过测试及风险记录进去
• 如果用户没有明确要求跳过，则继续后续步骤。

3. 先做基础校验

• 在功能测试前，优先执行当前项目支持的最小必要基础校验。
• 基础校验可以是编译、构建、类型检查、测试收集、依赖检查、最小启动校验或其他能够尽早暴露明显问题的验证方式。
• 选择与当前改动影响范围匹配的最小执行范围。
• 输出时必须写明：
• 执行了什么命令
• 结果是否通过
• 如果没有执行，原因是什么

4. 做测试层级决策

• 识别这次改动最需要证明的是：内部逻辑、模块协作、接口契约，还是完整业务流程。
• 在单元测试、集成测试、API / Contract 测试、端到端测试之间选择主层级。
• 如有必要，补充一个次层级用于覆盖主层级无法证明的风险。
• 先给出结论，再给出依据。

5. 先拆功能维度测试清单

• 在执行具体测试前，先从业务功能角度列出本次改动要测什么。
• 至少包含：
• 功能点
• 测试场景
• 验证内容
• 预期结果
• 描述优先使用业务语言或用户能直接理解的表达。
• 不要只写方法名、类名、路由名、文件名或“成功路径”。

6. 设计覆盖重点

至少考虑以下类型，并按当前任务相关性筛选：

1. 正常流程
2. 参数为空
3. 参数非法
4. 边界值
5. 权限不足或身份不合法
6. 数据不存在
7. 重复提交或幂等性
8. 状态不允许
9. 外部依赖失败
10. 历史 bug 回归场景

如果当前任务命中以下风险，也应补充考虑：

• 并发
• 时区、时间边界
• 排序和分页稳定性
• 数据兼容性
• 配置切换
• 重试与超时
• 部分成功、部分失败

7. 编写测试

• 先参考当前项目已有测试风格，再落地实现。
• 测试用例名称要表达业务场景，不要只复述方法名。
• 推荐命名格式：
• should_xxx_when_xxx
• given_xxx_when_xxx_then_xxx
• 或当前项目已有的稳定命名方式
• 每个测试都应具备清晰的前置条件、触发动作和结果断言。
• 真实断言优先，避免只检查“没有报错”。
• 如果需要隔离外部依赖，使用当前项目已有且稳定的隔离方式，例如依赖替身、测试桩、测试容器、专用测试环境或固定测试数据。
• 如果无法自动化某个关键场景，必须说明阻塞点、替代验证方式和剩余风险。

8. 运行测试或说明无法运行的原因

• 执行与本次改动范围匹配的最小必要测试命令。
• 如果当前项目存在更小粒度的执行方式，优先小范围运行。
• 如果无法运行，必须说明：
• 缺少什么条件
• 哪些场景因此未验证
• 当前风险是什么

9. 回填测试结果

• 将每个测试场景的实际结果回填到功能维度清单中。
• 明确区分：
• 已验证并通过
• 已验证但失败
• 未验证
• 被用户要求跳过
• 如果当前任务存在 task 文档、验收文档或交付文档，需要同步写入测试结论。

Output Requirements

完成测试任务后，输出至少要说明：

• 新增了哪些测试
• 覆盖了哪些场景
• 使用了什么测试层级
• 执行了哪些命令
• 结果如何
• 是否还有未覆盖风险
• 如何运行这些测试

推荐输出结构：

1. 测试前提
2. 是否跳过测试
3. 基础校验
4. 测试层级决策与依据
5. 功能维度测试说明
6. 测试执行内容
7. 测试结果
8. 测试缺口与剩余风险

Completion Standard

只有满足以下条件，才可视为测试闭环完成：

• 已明确要验证的业务行为
• 已明确是否按用户要求跳过测试
• 若未跳过，已完成基础校验或明确记录无法执行原因
• 已对测试层级给出有依据的决策
• 已从功能维度列出测试场景，而不是只列技术名词
• 已编写并运行测试，或明确说明为什么无法运行
• 已输出测试结果、测试缺口和剩余风险

Resources

• 当前需求、bug 描述、spec、plan、task 或交付文档
• 当前代码变更与相关模块的现有测试
• 当前仓库中的架构文档、测试规则、语言规则、框架规则、CI 规则
• .agents/skills/test-workflow/references/test-checklist-template.md

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: rockychang7
• Source: rockychang7/skills
• License: MIT

Install and usage instructions live in the source repository linked above.