如何用截图记录 QA 测试步骤

本指南介绍如何为一次 QA 测试执行收集截图证据。你将明确测试目标，记录前置条件和测试数据，编写可验证步骤，捕捉证据，判定结果，并完成执行记录。

简而言之： QA 记录会把每个计划操作与预期结果连接起来，并用本次执行的证据支持最终的通过、失败或阻塞状态。

明确一个测试目标

测试目标写明要审核的行为，以及成功条件。一份记录只聚焦一个结果，这样失败才能指向产品中的明确区域。

例如，“验证 Free 用户可以把 Action Capture Document 导出为 PNG”可以测试。“测试 Action Capture 导出”则混合多种格式、方案状态和失败路径，应拆成不同用例。

如果测试会重复执行，应分配稳定的测试用例 ID。标题之后可能被编辑，而 ID 能持续连接未来的执行、回归和缺陷报告。

记录前置条件和测试数据

前置条件让本次执行可以重复。列出产品版本、操作系统、方案或账户状态、权限、功能开关、准备好的 Document，以及第 1 步前需要的所有数据。

请使用准确测试数据，不要只写“输入有效信息”。如果数值可能暴露凭据或客户记录，应创建安全的固定样本，并说明测试人员从哪里获取。

简洁的设置可以这样写：

环境：macOS 15.5、Shotomatic 1.8.2
账户状态：Free
权限：已允许 Screen Recording
测试数据：包含三个页面的 Action Capture Document
起始画面：Document 编辑器，已选中第一页

为步骤写明预期检查点

每一步应把一个操作与测试人员必须检查的结果配对。这样不会让一长串操作把所有断言都拖到最后。

使用直接指令：

1. 打开 Export 菜单。预期：PNG 和 JPG 可用。
2. 选择 PNG。预期：打开保存对话框。
3. 选择测试文件夹并保存。预期：每页生成一个 PNG 文件。
4. 打开导出的文件。预期：页面按 Document 顺序排列，并与编辑器一致。

不要把多个交互合并到一步。如果合并步骤失败，就无法判断是哪个操作导致了结果。

在有价值的检查点捕捉证据

有效证据应证明会影响测试结论的状态。截取起始配置、取决于方案的选项、最终输出和所有意外结果。

并非每次点击都需要截图。如果测试要检查可用格式，打开菜单可能需要证据；选择普通文件夹则可能没有提供任何新信息。

测试本身沿着 UI 路径执行时，Action Capture 可以收集逐次点击序列。完成后检查页面，只保留支持测试结果的状态。Free 会话可保存 5 个步骤，并支持所有 Document 导出格式。Pro 取消步骤上限，并增加 Blur、Click Marker 和 Step Numbers。

记录实际结果，不要改写历史

实际结果应描述本次执行真正发生的情况。不要为了匹配失败而修改预期结果，也不要在没有记录偏差的情况下中途更改计划步骤。

使用以下三种明确结果之一：

• 通过： 所有必要结果都匹配；
• 失败： 至少一个必要结果不匹配；
• 阻塞： 由于前置条件或另一个缺陷，测试无法得出结论。

测试失败时，写明第一个不匹配的检查点，并链接单独的缺陷报告。缺陷报告可以包含精简后的复现路径、环境、频率和诊断证据，不必把所有内容塞进可复用测试用例。

使用这份 QA 执行记录

以下结构把可复用的测试定义与一次执行结果分开：

测试用例 ID：
目标：

环境：
前置条件：
测试数据：

步骤和预期结果：
1. 操作：
   预期：
2. 操作：
   预期：

执行日期：
测试人员：
测试构建版本：

实际结果：
状态：通过/失败/阻塞
证据：
关联缺陷：
备注或偏差：

这是一套可以复制到现有 QA 系统的文档结构。Shotomatic 不会把它作为项目模板导入。

复查证据并签署

最终复查用于确认所有证据确实属于所述执行。另一位审核者用这份记录批准发布前，应核对构建版本、账户状态、日期、页面顺序和导出结果。

删除重复截图并保护所有私密测试数据。如果文件会与测试管理系统分开存放，文件名或页面标题应关联测试用例 ID。分享记录前，再做一次最终复查和读者演练。

当审核者能看出测试内容、重复设置、比较预期和实际结果，并理解最终状态时，QA 记录才算完整。点击驱动的测试序列可以用 Action Capture 收集。如果证据始于已经观察到的问题，而不是计划测试，请使用如何在 Mac 上用分步截图记录软件缺陷。