mcpField
M
manual-testing

manual-testing

github.com/petekp测试与质量1054 次安装22 周前更新
代码仓库

关于 manual-testing

manual-testing 是用于验证近期改动的测试技能,优先执行自动化检查,仅对工具无法判断的内容请求人工验证。它还指导结果处理与汇总。

主要功能

  1. 01梳理改动并确定测试行为
  2. 02判断检查能否自动化
  3. 03先运行自动化测试
  4. 04收集针对性人工验证
  5. 05汇总结果与问题

适用场景

  1. 01实现后验证代码改动
  2. 02检查构建、测试、API 和 CLI 输出
  3. 03请求工具无法执行的视觉检查

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/petekp/agent-skills --skill manual-testing

安装后在 Claude Code 中输入/manual-testing确认已加载。

详细介绍

手动测试

先通过自动化测试验证当前工作,仅在必要时才请用户验证。

核心原则

尽可能自动化。 只有 Claude 无法通过工具验证的内容,才请用户手动验证。

工作流

1. 分析当前上下文

检查近期工作,确定需要测试的内容:

  • 查看近期文件变更和对话历史
  • 确定要验证的功能、修复或变更
  • 确定可测试的行为和预期结果
2. 对每项验证步骤进行分类

对于每项待验证的内容,判断 Claude 是否能自动测试:

Claude 可以验证(自动执行):

  • 代码能否编译/构建:npm run build、cargo build、go build 等。
  • 测试是否通过:npm test、pytest、cargo test 等。
  • 代码检查/类型检查:eslint、tsc --noEmit、mypy 等。
  • API 响应:使用 curl、httpie 或脚本发送请求
  • 文件内容:读取文件、使用 grep 查找预期模式
  • CLI 工具输出:运行命令并检查输出
  • 服务能否启动:启动服务、检查错误并验证端点是否有响应
  • 数据库状态:查询数据库并检查记录是否存在
  • 日志输出:查看日志尾部内容、使用 grep 查找预期/非预期消息
  • 进程行为:检查退出代码、stdout/stderr 内容
  • 文件是否存在/权限:ls、stat、test -f
  • JSON/配置是否有效:解析并验证结构
  • 端口是否可用:lsof、netstat、curl localhost
  • Git 状态:检查差异、提交和分支状态

Claude 无法验证(请用户验证):

  • 视觉外观(颜色、布局、间距、对齐)
  • 动画和过渡效果
  • 用户体验感受(响应速度、直观程度)
  • 跨浏览器渲染
  • 移动设备上的表现
  • 与实体硬件的交互
  • 第三方服务的 UI(OAuth 流程、支付表单)
  • 使用实际屏幕阅读器进行的无障碍检查
  • 对性能的主观感受(感觉快/慢)
3. 执行自动化验证

先运行所有可自动执行的检查。务必全面:

# Example: Testing a web feature
npm run build          # Compiles?
npm run lint           # No lint errors?
npm test               # Tests pass?
npm run dev &          # Server starts?
sleep 3
curl localhost:3000/api/endpoint  # API responds correctly?

逐步报告结果。如果自动化测试失败,先停止并解决问题,再请用户验证。

4. 用户验证(仅在必要时)

对于 Claude 无法自动验证的步骤,依次提供可选择的结果:

Step N of M: [Brief description]

**Action:** [Specific instruction - what to do]

**Expected:** [What should happen if working correctly]

然后使用 AskUserQuestion,并提供预测的结果选项:

  • 将最可能的 2-4 种结果设为可选项
  • 第一项:预期/成功结果
  • 其余选项:常见失败情况
  • 系统会自动提供可填写自由文本的“其他”选项

示例:

{
  "questions": [{
    "question": "How does the button look?",
    "header": "Visual check",
    "options": [
      {"label": "Looks correct", "description": "Blue button, proper spacing, readable text"},
      {"label": "Wrong color/style", "description": "Button exists but styling is off"},
      {"label": "Layout broken", "description": "Elements overlapping or misaligned"},
      {"label": "Not visible", "description": "Button missing or hidden"}
    ],
    "multiSelect": false
  }]
}
5. 处理结果

自动化测试失败: 停止并修复后再继续。

用户报告问题: 记录问题,并询问他们是想现在调查,还是继续测试。

6. 总结

所有步骤完成后:

  • 列出自动验证的内容(注明通过/失败)
  • 列出用户验证的内容(附验证结果)
  • 总结发现的问题
  • 建议后续操作

指南

  • 尽可能并行运行自动化检查
  • 灵活开展验证——大多数内容都可以通过编程方式测试
  • 如果不确定某项能否自动化,先尝试自动化
  • 用户验证步骤应尽量精简,并聚焦于真正需要视觉或体验判断的内容

评论

支持 Markdown