提交缺陷时，截图要能让他人仅凭图片和配套文字定位到同一页面、同一状态并复现问题。需要保留六类信息：界面上下文、操作路径、输入数据、报错原文、环境与版本、时间与账号角色。单张截图信息不足时，用“全景图+关键步骤图+报错细节图”组合，并附文字步骤、环境字段和日志片段。以下按采集、对应、示例和提交前检查展开。
要点总览（TL;DR）
- 缺陷截图要覆盖六类信息：界面上下文、操作路径、输入数据、报错原文、环境与版本、时间与账号角色，判断标准是他人仅凭截图和说明能定位到同一页面同一状态。
- 采集从复现前开始：先记录环境、账号与数据状态，再按入口页、关键操作页、结果页三个节点截图，报错出现时同时截界面和复制原文。
- 截图编号与复现步骤编号一一对应，图注用一句话写明该图证明什么；正文写步骤与环境字段，附件放原图和日志。
- 提交前按清单自查，环境字段缺失或步骤与截图无法对应时应退回补充，由提交人自查、评审人或模块负责人复核。
一张合格的缺陷截图要包含哪些信息
判断截图是否合格，可以用一个统一标准：一位没有参与测试的同事，能否只凭截图和配套说明，找到同一个页面、看到同一个状态、做出同一组操作。围绕这个标准，截图需要覆盖六类信息。
| 信息类别 | 截图里要看到什么 | 判断标准 |
|---|---|---|
| 界面上下文 | 完整页面或窗口，包含导航、标题、面包屑、按钮区，不只截弹窗一角 | 他人能认出这是哪个模块、哪个页面 |
| 操作路径 | 入口页与操作后的结果页，关键点击位置可见 | 他人能按图找到入口并走到同一位置 |
| 输入数据 | 表单中已填内容、查询条件、选中的选项 | 他人能用相同数据触发同一结果 |
| 报错原文 | 完整报错文本、错误码、堆栈信息，文字清晰可读 | 他人能直接复制或比对报错内容 |
| 环境与版本 | 系统名称与版本、浏览器或设备型号、页面上的版本标识 | 他人能在相同环境中尝试复现 |
| 时间与账号角色 | 操作发生的时间、当前登录角色或权限类型 | 他人能判断是否与时间窗口或权限相关 |
六类信息中，界面上下文和报错原文最容易在截图时丢失。常见情况是只截了弹窗，看不到弹窗从哪个页面弹出；或者报错文字被截断，只剩半行。遇到这类情况，补一张全景图，并把报错文本完整复制到缺陷描述中。
截图无法承载的信息，用文字步骤、日志片段或短录屏补充。涉及多步跳转、拖拽、悬浮菜单等难以用静态图表达的操作，录屏比连续截图更清楚；后台日志、接口返回、控制台报错则直接粘贴文本，避免用截图代替可复制的原文。
按步骤采集截图的顺序与做法
截图采集从复现之前开始，而不是等报错出现才打开截图工具。按下面的顺序执行，每一步都有明确的输入、动作和完成标志。
第一步：记录前置状态
输入是当前测试环境和账号。动作是记录系统与版本、浏览器或设备、网络条件、登录账号的角色与权限、测试数据的状态（如订单处于待支付、账号为新注册）。输出是一段可直接填入缺陷记录的环境与前置条件文字。完成标志是：这些字段脱离截图也能独立说明复现起点。
第二步：按关键节点截图
输入是已经确认的复现路径。动作是在三个节点各截一张：入口页，证明从哪里进入；关键操作页，证明填了什么、选了什么；结果页，证明出现了什么异常。输出是一组按顺序编号的图片。完成标志是：把这三张图连起来看，能还原操作主线。
第三步：截取报错细节
报错出现时，先截包含报错位置的完整界面，再截报错本身的清晰细节。同时把报错文本、错误码、堆栈完整复制到缺陷描述里。完成标志是：报错内容无需放大图片即可阅读，且文字版本可直接搜索和比对。
第四步：命名与编号
截图文件名或图注采用“步骤编号-信息角色”的规则，例如“步骤2-填写表单”“步骤3-提交后报错”。编号与复现步骤一一对应，避免出现“截图1”“截图2”这类无法定位的命名。完成标志是：看到任一截图编号，能立刻找到它对应的复现步骤。
第五步：处理敏感信息
截图前先确认画面中是否包含手机号、身份证号、真实姓名、内部地址、密钥等信息。需要保留数据形态时，对敏感字段做局部打码或替换为测试数据，打码范围以不影响判断问题为限；报错文本中的敏感内容同样处理。完成标志是：截图可进入缺陷记录并被多人查看，且关键信息未被遮挡。
截图与复现步骤、环境字段如何对应
截图只有嵌入缺陷记录的结构，才能被复核人快速核对。推荐的做法是正文写步骤，附件放原图与日志，两者用编号关联。
复现步骤按“1、2、3”编号，每一步后面用括号标注对应截图，例如“2. 在金额输入框填写 100000，选择优惠券后点击提交（见图2）”。截图说明用一句话写清该图证明什么，例如“图2：提交前表单已填金额与优惠券，页面无报错提示”。说明文字描述图中可见的事实，避免写“这里有问题”这类需要读者自行猜测的判断。
环境字段单独成段或填入缺陷记录的对应字段，至少包含：系统与版本、浏览器或设备、网络条件、数据状态。账号角色和时间放在前置条件中。这样安排后，复核人先读环境字段判断能否搭建同样条件，再按步骤和截图走一遍路径。
附件与正文分工明确：正文承载步骤、环境、报错文本和截图说明，附件保存原始截图、日志文件、录屏。原图放附件可以保留清晰度，正文中的说明则保证不打开附件也能理解问题主线。
在缺陷管理工具中，这些内容通常由缺陷记录的描述字段、附件区和状态流转共同承载。以 ONES Project 为例，它支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况，缺陷状态分布也可统计；ONES TestCase 支持将未通过的用例快速创建为缺陷任务，使缺陷在测试与研发之间流转。把截图编号、复现步骤和环境字段写进缺陷描述，再随附件提交，后续修复人打开记录即可按图核对。
完整示例：一条带截图的缺陷记录
以下为演示情景，用一条填好的缺陷记录展示前述方法的落地结构。
标题：订单提交页输入大额金额并选择优惠券后，点击提交提示“系统繁忙”且订单未生成
环境：测试环境 v2.4.1；Chrome 120；公司办公网络；测试账号角色为普通买家；测试订单处于待支付状态。
前置条件：账号已登录，购物车中有一件单价 100000 元的测试商品，账户内有一张满减优惠券。
复现步骤与截图：
- 进入订单提交页，确认商品与金额显示正常（见图1）。
- 在金额输入框填写 100000，选择优惠券，页面显示优惠后金额（见图2）。
- 点击“提交订单”，页面弹出“系统繁忙，请稍后重试”，订单列表无新订单（见图3）。
- 刷新页面后重复步骤2至3，问题仍出现；控制台报错文本见附件日志。
截图说明：
- 图1（全景图）：订单提交页完整界面，可见导航、商品信息、金额区域，证明操作入口与页面状态。
- 图2（关键操作图）：填写金额并选择优惠券后的表单，证明输入数据与优惠条件。
- 图3（报错细节图）：提交后的报错弹窗与页面背景，证明报错出现的位置和原文。
这条示例中，页面结构、输入数据和报错位置用截图表达；环境字段、前置条件、重复操作结果和日志用文字与附件表达。取舍原则是：能一眼看懂的界面状态用图，需要精确比对或复制的内容用文字。
提交前的截图完整性检查
提交前按清单逐项核对，每项给出通过标准，避免把不完整的记录直接推给修复人。
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 界面上下文 | 截图能看到所属页面与模块，非孤立弹窗 | 补截全景图 |
| 步骤与截图对应 | 每个复现步骤都有编号对应的截图或说明 | 补编号或补图，无法对应则退回补充 |
| 报错原文 | 报错文本完整可读，文字版本可复制 | 重新截取并粘贴原文 |
| 环境字段 | 系统版本、浏览器或设备、网络、数据状态齐全 | 缺环境字段应退回补充 |
| 敏感信息 | 手机号、身份信息等已打码或替换，关键信息未被遮挡 | 重新处理后再提交 |
阻断项有两条：环境字段缺失，以及复现步骤与截图无法对应。出现任一情况，记录应退回提交人补充，不进入修复环节。其余检查项可在评审时提出修改，但应在同一轮内完成。
责任分工上，提交人负责自查清单并保证截图与步骤一致；评审人或模块负责人负责复核环境字段、报错原文和截图说明是否足以支撑复现。复核通过后，缺陷记录进入修复流程；复核发现信息不足时，写明缺哪一项并退回。把这两道关口固定下来，截图质量就不再依赖个人习惯。
常见问题
截图里已经能看到报错，为什么还要把报错文本复制到缺陷描述里？
截图证明报错出现的位置和界面状态，文字版本则便于搜索、比对和复制。修复人排查时经常需要拿错误码或堆栈去查日志、检索代码，图片里的文字无法直接使用。两者同时保留，截图负责上下文，文本负责精确内容。
操作步骤很多、每步都截图会让附件很杂，怎么取舍？
按信息角色取舍，而不是按操作步数取舍。入口页、关键输入页、出现异常的结果页各保留一张，中间过渡性的点击可以合并或省略。多步跳转、拖拽、悬浮菜单等静态图难以表达的操作，用一段短录屏替代连续截图，并在正文步骤中注明录屏对应哪几步。
截图涉及真实用户数据，打码后会不会影响复现判断？
打码范围以不影响判断问题为限。手机号、身份证号、真实姓名等字段可以局部遮挡或替换为测试数据，保留字段长度、格式和所在位置；与问题直接相关的金额、状态、报错文本应保持可见。报错文本中的敏感内容同样处理，处理后确认关键信息未被遮挡再提交。
评审人认为截图不够完整时，应该退回还是直接补充？
取决于缺失项。环境字段缺失、复现步骤与截图无法对应属于阻断项，应退回提交人补充，因为评审人无法代替提交人还原当时的操作条件。截图说明措辞不清、图注编号不规范等可以在评审时提出修改，在同一轮内由提交人更新即可。
在缺陷管理工具里，截图和复现步骤一般放在哪里？
常见做法是正文描述字段承载复现步骤、环境字段和截图说明，附件区保存原始截图、日志和录屏。以 ONES Project 为例，它支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；ONES TestCase 支持将未通过的用例快速创建为缺陷任务。把编号和说明写进描述、原图随附件提交，修复人打开记录即可按图核对。
