mcpField
M
manual-testing

manual-testing

github.com/petekp测试与质量4863 次安装4 天前更新
代码仓库

关于 manual-testing

面向编码 Agent 的手动测试技能，将代码变更整理为有针对性的验证计划，并引导用户完成需要人工判断的检查。它要求先用工具验证，再请求手动检查。

主要功能

  1. 01制定精简的验证矩阵
  2. 02手动测试前先运行自动检查
  3. 03提供具体步骤与预期结果
  4. 04检查常见故障和回归路径
  5. 05总结已验证结果与待查项

适用场景

  1. 01验证需要目视检查的 UI 变更
  2. 02自动测试通过后检查修复
  3. 03引导用户进行真实设备测试

安装

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

$npx skills add https://github.com/petekp/claude-code-setup --skill manual-testing

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

详细介绍

手动测试

通过紧凑的验证闭环完成工作：先用工具尽可能验证所有内容，然后只让用户验证那些需要人眼、人手、设备或判断的部分。

不要让用户自行编写测试计划。带着他们逐步完成。

质量标准

在让用户做任何事情之前，先明确：

  • 哪些内容发生了变化
  • 预期行为是什么
  • 哪些内容可以自动验证
  • 哪些内容仍需人工检查
  • 附近哪些行为可能受到回归影响

绝不要让用户“随便试试”或“告诉我能不能用”。请给出具体操作、指定界面或命令、预期结果，以及一组简短的常见结果选项供用户回复。

工作流

1. 制定验证矩阵

在运行任何操作之前，将变更转化为简短的验证计划。

针对每项变更的行为，记录：

  • 主要成功路径
  • 最可能的失败情况或边缘情况
  • 一项相关的回归检查
  • 验证负责人：工具或用户

使用如下简单的内部清单：

行为正常路径边缘情况／回归验证方
保存设置表单保存成功验证错误仍能正常处理工具 + 用户

矩阵应保持简洁，并聚焦于当前变更。

2. 先运行工具可验证的检查

在让用户参与之前，先完成所有自动化验证。

优先自行验证以下内容：

  • 构建、编译、类型检查、lint、测试
  • API 响应和状态码
  • 文件输出、数据库状态、日志和副作用
  • 命令行行为、退出码和生成的产物
  • 如果工具可以验证，则进行浏览器自动化、截图、DOM 文本或网络行为检查

只有在结果取决于以下方面时，才让用户参与：

  • 视觉正确性
  • 动效、时序或使用感受
  • 真实设备行为
  • 跨浏览器差异
  • 屏幕阅读器行为
  • 需要人工交互的第三方流程

如果自动化检查失败，先停止并解决问题，再请求人工验证。

3. 准备用户操作路径

做好准备，让用户能够以最少的精力完成检查。

请提供：

  • 确切的路由、URL、界面或命令
  • 所需的任何初始状态
  • 要执行的单一步骤
  • 预期结果
  • 回复内容

如果用户需要使用已运行的应用，请告知他们要打开的确切位置。如果可以安全地预先准备状态、数据或测试夹具，请自行完成。

4. 引导用户逐步完成原子化操作

以引导式步骤进行手动验证，不要一次性给出含糊的指示。

尽量一次只执行一个原子化步骤。对于简单的冒烟测试，最多将 2-3 项紧密相关的检查合并在一起。

使用以下结构：

Testing: [feature or fix]
Progress: Step N of M

Action: [exact thing to click, type, or inspect]
Expected: [what should happen]
Reply with one:
1. [expected outcome]
2. [common failure mode]
3. [second common failure mode]
4. Other

如果有结构化提问工具，请将这些回复选项转换为结构化提示。否则，用纯文本提问，并在问题中列出选项。

示例：

Testing: profile photo upload
Progress: Step 2 of 3

Action: Open `/settings/profile`, upload a PNG under 2 MB, and wait for the save state to finish.
Expected: The new avatar appears in the header and no error message is shown.
Reply with one:
1. Upload worked and the new avatar is visible
2. Upload finished but the avatar did not update
3. I saw an error message or spinner got stuck
4. Other
5. 覆盖恰当的范围

始终先测试发生变更的路径，然后检查最可能出问题的地方。

使用以下提示作为校准清单。

对于 UI 变更：

  • 检查初始渲染
  • 相关时检查加载、空白、错误、禁用和成功状态
  • 检查交互控件的键盘／焦点操作路径
  • 如果变更对布局敏感，检查移动设备或窄屏布局
  • 检查文案、间距和明显的视觉回归

对于错误修复：

  • 重现原始错误路径
  • 验证问题不再出现
  • 验证相邻路径仍能正常工作

对于 API 或后端变更：

  • 验证正常路径的响应
  • 验证无效输入或失败路径的行为
  • 验证持久化副作用或下游状态变化
  • 验证日志或错误中没有出现新的问题

对于命令行或本地工具变更：

  • 验证成功路径
  • 验证常见失败路径及退出码
  • 相关时验证输出文件、stdout／stderr 和帮助文本
6. 像调试器一样处理故障

当用户报告问题时：

  • 记录失败的具体步骤
  • 记录预期行为与实际行为
  • 留意可见的错误文本、日志或截图
  • 判断是立即停止并调查，还是仅在完成剩余检查仍有价值时继续

更改代码前，先为故障提出 2-3 个合理的假设，让下一步调试有明确依据，而不是靠猜测。

如果故障导致无法确信更改有效，请停止手动测试并转入诊断。

7. 总结验证结果及尚存疑点

最后简要总结验证情况，区分已证实的内容与仍属假设的内容。

包括：

  • 已运行的自动化检查及其结果
  • 已完成的手动步骤及其结果
  • 发现的 Bug 或回归问题
  • 尚未验证的方面
  • 建议的后续操作

指南

  • 尽量减少用户的工作，尽可能多地由 Agent 完成
  • 一次只让用户专注于一个上下文
  • 优先提供具体的回复选项，而不是开放式问题
  • 条件允许时，检查一条成功路径、一条失败路径，以及一个相关回归问题
  • 充分使用工具后再请求人工验证
  • 清晰地持续说明进展，让用户记住当前正在测试什么，以及哪些内容已经通过

评论

支持 Markdown