每个 QA 测试步骤都要截图吗？

QA 测试记录有两类读者：当天签字确认的审核人员，以及数月后排查回归问题的人员。两者都需要看到测试了什么、使用了什么数据，以及结果如何。两者都不需要每次点击的截图。

本文说明如何组织手动测试记录，以及在哪些位置截图能够作为证据。示例使用 Mac 上的 Temposhot 工作流程。

示例全程使用同一个测试用例：TC-142，即预发布站点上的密码重置。该测试有 4 个步骤。只记录检查点的测试记录共 5 页，记录每次点击的测试记录共 11 页。

定义一个测试目标

每个测试用例只验证一种行为。“用户可以通过有效的邮件链接重置密码”是一个测试目标。“账户设置正常”是测试计划，不是测试用例。

测试目标需要写成可以判断为真或假的句子。最终截图会显示结果是哪一种。

拆分隐含两个测试的目标

目标中含有“和”时，通常隐含两个测试。“用户可以重置密码并更改邮箱地址”在只有一部分出错时整体失败，记录中无法看出是哪一部分。应将其拆分为两个用例，各自拥有独立的 ID 和记录。

范围窄的目标也能让记录更短。TC-142 在用户使用新密码登录后结束。确认旧密码不再可用是另一个用例，即 TC-143，拥有独立的起始状态。

从用户视角编写目标

从用户视角编写的目标会指明用户能看到的结果。“用户可以通过有效的邮件链接重置密码”以一个画面结束：登录后的仪表板。“重置接口返回 200”以日志结束，此类目标不适合使用截图记录。

用例同时包含两类目标时，将用户可见的结果作为测试目标，并将日志内容作为文本附加。截图用于证明用户看到的结果，文本用于证明其背后的系统行为。

记录前置条件和测试数据

列出第一步之前必须具备的条件，以便任何人都能重复执行该测试：

项目	示例
测试用例 ID	TC-142
构建版本或版本号	被测的构建号
环境	预发布站点 URL、macOS 版本、浏览器及其版本
账户	角色和测试账户名称，不得使用真实客户账户
测试数据	测试使用的订单、文件或记录
前置条件	功能开关已开启、购物车为空、用户已退出登录

使用合成数据。测试记录会被广泛分享并长期保存。

在第一页证明前置条件

只写在文字中的前置条件，之后无法核对。记录的第一页应在屏幕上显示起始状态，例如显示预发布 URL 的已退出登录登录页。审核人员无需询问即可确认测试环境。

TC-142 的测试收件箱必须为空。如果收件箱中存在旧的重置邮件，测试人员可能打开错误的链接，记录则会显示一个并非被测对象的链接已通过。

使用明显为虚构的测试数据

合成数据应一眼就能看出是虚构的。“QA Reset 01”这样的名称和测试域名的邮箱地址，能让之后的任何读者明确知道记录中没有真实人员。看起来真实的虚构姓名，例如完整的名和姓，会让读者怀疑记录中包含客户数据。

明显的测试数据也能减少打码工作。不含个人数据的记录无需使用 Blur，免费版即可满足需求，页面也能显示完整屏幕，不会出现遮盖区域。

编写步骤和预期检查点

每个步骤包含一个操作，以及在应当能观察到结果的情况下的预期结果。

1. 打开登录页。预期： 显示“Forgot password”链接。
2. 选择 Forgot password，输入测试邮箱。预期： 显示确认信息。
3. 从测试收件箱打开重置链接。预期： 显示新密码表单。
4. 输入有效的新密码并提交。预期： 已登录，显示仪表板。

没有预期结果的步骤属于准备工作。有预期结果的步骤是检查点，截图应放在检查点上。

让每个预期结果可以被观察

“运行正常”不是可以用于判断的预期结果，因为任何截图都无法体现它。预期结果应指明一个可见的内容：提示文字、字段、数值或页面标题。“确认信息：请查收邮件中的重置链接”可以与屏幕内容逐字比对。

如果预期结果无法在屏幕上看到，例如邮件的送达时间，应将其作为文字记录在页面说明中。截图显示屏幕内容，页面说明记录具体数值。

保持步骤编号稳定

测试用例中的步骤编号和记录中的页面标题必须一致。之后编辑用例并插入步骤时，应为新步骤添加后缀，例如 2a，而不是重新编号。旧记录仍指向正确的步骤，在多个构建版本中搜索“步骤 4”的回归结果时，也能找到同一个操作。

页面标题在 Page Inspector 的 Page title 下编辑。将每个草稿标题改写为以用例和步骤 ID 开头，然后在 Description 下添加预期和实际结果两行。

区分准备步骤和检查点

TC-142 包含记录中不显示的准备工作：打开测试收件箱、复制邮箱地址、等待邮件。省略这些步骤可使记录保持在 5 页。如果准备操作失败，应将其记为 Blocked 结果并单独成页，不能悄无声息地留下空缺。

一个实用的判断方法是：用例中没有“预期”行的步骤不生成页面，有“预期”行的步骤恰好生成一页。

每个 QA 测试步骤都要截图吗？

不需要。只在以下时刻截图：

• 起始状态： 证明前置条件已满足。
• 每个检查点： 显示预期结果或非预期结果。
• 最终结果： 显示测试目标是否达成。
• 任何失败： 结果偏离预期时的屏幕，以及失败之前的一步。

普通导航点击的截图只会增加页数，不会增加证据。它们会使记录更难审核。

使用 Temposhot 时，可以只截取检查点。打开 Action Capture（Command+3），选择 Configure，将 Mouse click capture 设置为仅截取带修饰键的点击，或设置为从不截取点击。然后在每个检查点按下 Shift+Command+2（手动截图快捷键）。选择 Start Action Capture，选择 Specific Window，运行测试，然后选择 Finish capture。Document 将打开，每个检查点对应一页。

如果需要为失败的测试记录每个步骤，请将鼠标点击设置回每次点击。每次被接受的点击都会在点击前保存窗口画面。Action Capture 指南列出了所有截图模式。

比较两种记录模式

两种模式回答的问题不同。只记录检查点的记录回答“每个检查点是否显示了预期结果”。记录每次点击的记录回答“测试人员具体做了什么”，这在测试失败时最为重要。

免费版每次 Action Capture 运行的步骤上限为 5 个。只记录检查点的 TC-142 记录，恰好可以在一次免费运行中完成：起始状态加 4 个检查点。记录每次点击的运行在第 5 步后暂停，并保留已记录的步骤。Temposhot Pro 取消了该限制。

配置仅检查点的运行

Configure Action Capture 的设置保存在 Mac 上，因此检查点的配置会保留到下一次测试。录制教程或缺陷报告前，应将其改回原设置。

Mark clicked area 同样适用于通过手动快捷键添加的步骤。在检查点记录中，标记会指向指针恰好停留的位置，可能误导审核人员，因此保持关闭。

使用快捷键运行 TC-142

1. 截取起始状态

   倒计时结束后，在已退出登录的登录页按下 Shift+Command+2。这是第 1 页。

2. 截取每个检查点

   执行每个步骤。当预期结果应显示在屏幕上时，再次按下快捷键。第 2 至 5 页是 4 个检查点。

3. 结束

   按下 Command+. 或选择 Finish capture。Document 将打开，共 5 页。

持续时间很短的检查点

有些预期结果只显示几秒，例如提交表单后的提示消息。应在消息出现时立即按下快捷键，步骤会保存该时刻的屏幕。如果消息在按键前已经消失，应重复该步骤，并保持手指放在按键上。

如果某个结果出现得太快无法捕获，应将其写入说明，并截取随后的屏幕。例如：“预期：提示 Password updated。实际：看到了提示，约 3 秒后消失，显示仪表板。”审核人员由此可知提示已被观察到，以及它未出现在页面上的原因。

跨窗口的测试

TC-142 会在浏览器与测试收件箱之间切换。当收件箱在另一个浏览器窗口中打开时，Specific Window 目标只会截取第一个窗口。对于使用多个窗口的测试，应选择 Full Screen，并在运行前关闭与测试无关的所有窗口。

检查点失败时切换模式

步骤 4 失败时，检查点记录只显示结果，不显示具体输入。应以记录每次点击的模式重新运行测试，记录通往失败的完整路径。将第二次运行附加到缺陷报告中，并保留第一份记录作为测试结果。

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

记录必须显示实际发生的情况，而不是应当发生的情况。在 Document 编辑器中：

• 每页标题应包含步骤 ID 和操作，例如“TC-142 步骤 4：提交新密码”。
• 在 Page description 中，将预期结果和实际结果分两行写明。
• 对于失败的检查点，使用 Rectangle（R）框出错误的值，并添加 Text（T）标签，内容为“Fail”。

不要裁掉审核人员需要的上下文，例如 URL 或构建标签。仅在需要去除无关窗口时使用 Framing。使用 Blur（B，Pro）对个人数据打码，且绝不能为了让结果看起来正确而修改数值。

证据的标注规则

Temposhot 中的标注是非破坏性的：矩形或标签下方的截图保持不变。这样可以保持证据完整，但导出的 PDF 读者只能看到渲染后的页面。规定标注可以做什么、不可以做什么的规则，能保证导出结果可信。

按固定格式编写说明

固定的两行格式便于在 5 页或 50 页的记录中快速浏览。第一行以“预期：”开头，写明预期结果。第二行以“实际：”开头，写明截图中显示的内容。

对于 TC-142 第 5 页，说明内容为“预期：已登录，显示仪表板。实际：横幅提示 Reset link expired，显示登录表单。”审核人员只需一眼即可对照截图确认实际结果一行。

使用此 QA 执行记录

• 测试用例 ID、测试目标、构建版本、环境、测试人员、日期。
• 前置条件和测试数据。
• 带有预期结果的步骤。
• 起始、检查点、结束及失败时的截图。
• 每个检查点的实际结果。
• 状态：Pass、Fail 或 Blocked。
• 每个失败对应的缺陷报告链接。

从 Document 中使用 Export PDF 导出，以附加到测试管理工具中；或使用 More export formats 中的 PNG 页面，以嵌入证据。文件命名应包含用例 ID 和构建版本，例如 TC-142_build-2026-08-27.pdf。导出指南列出了所有格式。要比较不同构建版本中同一屏幕的两张截图，可使用浏览器工具 Compare Images，它在本地高亮显示差异。

测试记录的 PDF 设置

默认的 Export PDF 设置适用于大多数记录：A4、横向、封面页、显示步骤编号和页码，且说明位于图片之前。封面页显示文档标题和步骤数，因此“TC-142 build 2026-08-27 Fail”这样的标题会将结果显示在第一页。自定义 PDF 设置需要 Temposhot Pro。

使用 Pro 的团队如果在美国信纸上打印，可将 Paper size 切换为 Letter。将 Image quality 设为 Small file，可使 50 页的回归记录保持足够小，便于附件大小受限的工具使用。

根据证据设置状态

每种状态需要不同的证据。审核人员若发现某个状态与页面不匹配，应将记录退回。

按用例和构建版本整理记录

记录之后通常按用例 ID 和构建版本查找，很少只按日期查找。每个用例建立一个文件夹，每个构建版本建立一个子文件夹，这样回归搜索可以比较同一用例在不同构建版本中的结果。

Document 导出的图片文件以页面标题命名。标题以步骤 ID 开头，因此生成的文件名会按步骤顺序排列，并且可以在不同构建版本之间对应。

比较不同构建版本的检查点

TC-142 在 2026-08-27 的构建版本中失败，在 2026-09-03 的构建版本中通过。此时应在 Compare Images 中打开两个步骤 4 的 PNG 文件。滑块或像素差异视图可以显示只有横幅发生变化，还是布局也发生了移动。两份记录都应保留，失败的记录用于记录这次回归。

审核证据并签字确认

审核人员无需运行测试，即可确认三件事：前置条件已满足，每个检查点显示了规定的结果，最终状态与截图一致。如果审核人员需要猜测，说明记录中需要增加检查点。

Temposhot 将 Document 存储在本地，不提供签字确认流程。应将导出的文件附加到记录审批的测试管理工具或工单中。

审核人员的检查顺序

审核人员可以按固定顺序阅读，在几分钟内检查 5 页的记录。首先，将封面标题和第 1 页与前置条件比对：构建版本、URL 以及已退出登录的状态。其次，逐个阅读检查点页面，并将“实际”一行与截图比对。

第三，确认封面上的状态与页面一致。封面标记为 Pass，但第 5 页出现红色错误横幅，应退回给测试人员。封面标记为 Fail 却没有关联的缺陷报告，同样应退回。

Blocked 不等于 Fail

测试因与被测行为无关的原因而无法到达某个检查点时，状态应为 Blocked。在 TC-142 中，预发布环境故障导致重置邮件无法送达，从而阻断了步骤 3。记录显示起始状态和最后能够到达的屏幕，并在说明中写明原因。

将 Blocked 测试标记为 Fail 会使失败率看起来更高，并将缺陷派发给错误的团队。将其标记为 Pass 则会掩盖缺口。应将 Blocked 作为独立状态保留，待阻断因素消除后重新执行该用例。

从失败的检查点到重新测试

失败的测试会经过固定的路径。在每个阶段，原始记录都保持不变。

测试会话的键盘操作流程

在一次会话中运行 10 至 20 个用例的测试人员，最好全程使用键盘。下列按键涵盖录制和首轮编辑。

Mac 上的记录保留

Document 保存在录制它的 Mac 上，原始会话则保存在 Capture History 中，直到达到保留上限。默认上限为 30 个会话，可在 Settings > History 中于 1 至 500 之间调整。在繁忙的测试周期内，几天即可超过 30 个会话，因此每个用例完成后应将记录导出到测试管理工具中。

常见问题

截图是否足以作为测试证据？

对于手动 UI 测试，截图是核心证据。当失败无法在屏幕上看到时，应将日志、控制台输出或网络数据以文本形式补充。参见截图证据。

自动化测试是否也应生成截图？

自动化测试套件通常在失败时截图。如需在不同构建版本之间自动比较截图，参见视觉回归测试。

如何报告 QA 中发现的失败？

应编写单独的缺陷报告，并关联到测试用例。参见如何用分步截图记录缺陷。

测试记录应有多少页？

起始状态一页，每个检查点一页，失败情况一页。TC-142 有 4 个检查点，因此通过的记录共 5 页。

检查点页面能否显示指针？

可以。在 Configure Action Capture 中开启 Show cursor in shortcut captures。指针位置与结果无关时应保持关闭。

将点击转化为清晰的分步指南

Action Capture 根据运行方式，通过快捷键记录检查点，或记录每次点击。下载 Temposhot，并将下一份测试记录以有序的 PDF 附加使用。