缺陷证据收集的目标，是让另一个没有参与操作的人能依据记录独立复现问题，并判断实际结果是否符合预期。证据不足时，缺陷容易在“无法复现”和“理解不一致”之间反复流转。本文按采集内容、采集步骤、留存关联、角色分工、完整示例和提交前检查六个部分展开，适用于测试、开发或业务人员提交缺陷记录的场景。
要点总览（TL;DR）
- 缺陷证据收集的目标是让他人能独立复现并判断问题，证据按缺陷类型取舍，不必一律全收。
- 采集按四步执行：确认复现条件与前置数据、按序记录步骤与结果、同步抓取日志截图录屏并命名、整理成证据包。
- 证据留存要统一命名与存放位置，原始文件与脱敏副本分开管理，并在缺陷描述中标注附件与步骤的对应关系。
- 提交前由提交人自检、复核人复核，完整性、一致性、可复现性、可追溯性和脱敏合规任一项不通过即阻断提交。
- 缺陷记录、附件留存与流转可在缺陷管理工具中承载，ONES Project 与 ONES TestCase 提供缺陷跟踪与用例转缺陷的衔接能力。
缺陷证据收集要采集哪些内容
证据采集先回答一个问题：这条缺陷需要证明什么。复现类缺陷要证明操作路径能稳定触发异常；数据类缺陷要证明特定输入产生了错误输出；界面类缺陷要证明显示结果与设计或预期不符。围绕证明目标选择证据，比把所有材料一次性堆进缺陷记录更有效。
常用证据可以分为六类，每类都有明确的采集时点和来源：
| 证据类型 | 适用缺陷 | 采集时点 | 来源 |
|---|---|---|---|
| 复现步骤 | 所有可操作触发的缺陷 | 首次复现时同步记录 | 操作人按实际点击和输入顺序整理 |
| 预期结果与实际结果 | 所有缺陷 | 复现完成后立即填写 | 需求文档、设计稿、接口约定与现场观察 |
| 环境信息 | 与环境相关的缺陷 | 复现前确认并记录 | 测试环境、设备型号、系统版本、浏览器或客户端版本、账号角色 |
| 日志 | 接口报错、后台异常、性能问题 | 异常发生后尽快导出，避免日志滚动覆盖 | 服务端日志、客户端日志、浏览器控制台 |
| 截图或录屏 | 界面显示、交互异常、偶现问题 | 异常出现时当场截取 | 操作人设备录屏或截图工具 |
| 数据样本 | 数据计算、导入导出、报表类缺陷 | 复现前后各保留一份 | 测试数据文件、请求与响应报文、数据库查询结果 |
按缺陷类型取舍证据，能减少无效材料。界面文案错误通常一张截图加环境信息即可；支付金额计算错误则需要输入数据、请求报文、返回结果和日志共同支撑；偶现的页面卡顿需要录屏加时间点，便于对照日志定位。判断标准是：缺少这类证据，处理人是否还能独立判断问题存在并开始定位。如果答案是否定的，就应补齐。
采集时点同样重要。日志和现场截图具有时效性，异常发生后拖延采集，可能因日志滚动、页面刷新或数据被覆盖而丢失关键信息。复现步骤则应在首次成功复现时记录，避免凭记忆补写导致顺序偏差。
按步骤完成一次证据采集
把采集拆成四步执行，每步都有输入、动作和输出，完成后即可形成可提交的证据包。
第一步：确认复现条件与前置数据
输入是待验证的功能点和测试数据。动作包括确认账号角色与权限、准备前置数据、记录环境版本，并先按正常路径操作一遍确认基线行为。输出是一份复现条件说明，包含环境、账号、数据准备方式和起始页面。完成标志是：换一个人按这份说明操作，能到达相同的起始状态。
第二步：按顺序记录操作步骤与实际结果
输入是确认好的复现条件。动作是逐步执行操作，每完成一个关键动作就记录一次，写清点击了哪个入口、输入了什么内容、选择了哪个选项。遇到异常时，立即记录实际结果，并与预期结果对照写明差异。输出是编号化的复现步骤和结果对照。完成标志是：步骤中不出现“然后正常操作”这类省略表达，每一步都能被独立执行。
第三步：同步抓取日志、截图或录屏并命名
输入是异常发生时的现场。动作是在不刷新页面、不重启服务的前提下导出日志，截取包含关键信息的画面，偶现问题优先录屏并记录异常出现的时间点。文件按统一规则命名，例如“缺陷编号_证据类型_采集时间”。输出是一组已命名的原始证据文件。完成标志是：每个文件都能对应到复现步骤中的具体环节。
第四步：整理成可提交的证据包
输入是前两步形成的文字记录和第三步形成的文件。动作是按“问题摘要—复现条件—复现步骤—预期与实际结果—证据附件—影响范围”的顺序组织内容，检查附件是否齐全、描述与文件是否一致。输出是一份结构完整的缺陷证据包。完成标志是：处理人只阅读这份证据包，就能判断问题是否存在并开始定位。
证据如何留存、命名与关联缺陷
证据采集完成后，留存方式决定了它能否被追溯。统一命名和存放位置是基础。建议命名包含缺陷编号、证据类型和采集时间三个要素，例如“BUG-1024_服务端日志_20250612-1430”。同一缺陷的多份证据使用相同前缀，便于检索和批量归档。存放位置应固定在缺陷记录本身或团队约定的证据目录中，避免散落在个人聊天记录和本地桌面。
原始文件与脱敏副本需要分开管理。原始日志、报文和数据样本保留完整内容，供定位使用；对外流转或跨团队查看时，使用脱敏后的副本，遮盖账号、手机号、身份证号等敏感字段。脱敏处理应保留足以复现问题的结构信息，例如保留请求参数名而遮盖具体值。哪些证据需要脱敏，取决于数据敏感程度和查看范围，涉及个人信息或生产数据时应先脱敏再共享。
证据与缺陷记录的关联方式有两种常见做法：一是将文件直接作为缺陷附件上传，并在描述中标注每个附件对应的步骤编号；二是在缺陷记录中填写证据存放路径或链接，附件作为补充。前者适合证据量少、需要随缺陷一起流转的场景，后者适合日志体积较大或需要长期归档的场景。无论采用哪种方式，缺陷描述中都应写明“第几步对应哪个附件”，避免处理人逐个打开猜测。
保留期限和访问权限应随缺陷生命周期设定。缺陷关闭后，证据通常需要保留一段时间以支持复盘和回归对照，具体期限可按团队质量管理和审计要求确定。访问权限方面，证据包应让缺陷处理链路上的角色可读，对包含敏感数据的原始文件限制范围。使用缺陷管理工具承载时，可在缺陷记录中统一存放附件和描述，并借助项目权限控制查看范围；ONES Project 支持缺陷跟踪管理，可将 Bug 提交至对应项目或迭代并记录修复情况，ONES TestCase 支持为不同用户组配置权限，缺陷附件的具体权限范围需按实际配置确认。
角色分工与交付物
证据从采集到使用涉及三类角色。提交人负责发现问题和采集证据，复核人负责在提交前检查证据质量，处理人负责依据证据定位和修复。角色可以由不同人承担，也可以在小团队中合并，但复核动作应与采集动作分开，避免提交人自检自过。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 提交人 | 复现问题、采集证据、按规范整理证据包 | 复现步骤、结果对照、日志与截图、数据样本 | 证据包整理完成后提交复核 |
| 复核人 | 检查证据完整性、一致性和可复现性 | 复核记录、退回意见或通过确认 | 提交人提交后、缺陷流转给处理人前 |
| 处理人 | 依据证据定位问题，必要时反馈补充需求 | 定位结论、补充证据请求、修复记录 | 接收缺陷后、修复完成时 |
交接时点需要明确。提交人完成证据包后交给复核人，复核人确认通过后缺陷才进入处理环节；处理人在定位过程中发现证据不足，应说明缺少哪类信息并退回提交人补充，而不是自行猜测复现。争议证据的升级路径可以设为：复核人与提交人对证据是否充分存在分歧时，由测试负责人或项目质量负责人裁定；处理人认为无法复现时，提交人补充录屏或日志后再次提交，仍无法复现的，记录双方结论并标注复现条件差异。
在工具中承载这套分工时，缺陷记录本身可以作为交接载体。ONES TestCase 中未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转；ONES Project 支持一键提交 Bug 至对应项目或迭代。提交人将证据作为附件和描述写入缺陷记录，复核人在流转前完成检查，处理人接收后在同一记录中反馈定位结论，交接过程留有记录。
示例：一个可复现缺陷的证据包
以下为演示情景，用于说明证据包的组织方式，不对应真实系统。
缺陷场景：某订单列表页面在筛选“已发货”状态并翻至第二页时，列表重复显示第一页的最后一条订单。预期结果是第二页只显示未在前一页出现的订单。
证据包按以下结构组织：
- 问题摘要：订单列表筛选已发货状态后翻页，第二页出现重复记录。
- 复现条件：测试环境，账号角色为运营管理员，前置数据为已发货订单不少于25条，浏览器版本已记录。
- 复现步骤：登录后进入订单列表；选择“已发货”筛选；记录第一页最后一条订单编号；点击第二页；观察列表首条记录。
- 预期与实际结果：预期第二页不包含第一页已出现的订单；实际第二页首条与第一页末条订单编号相同。
- 证据附件：第一页截图、第二页截图、两次请求的响应报文、对应时间点的服务端日志。
- 影响范围：影响运营人员核对已发货订单数量，可能导致重复统计。
证据与描述的对应关系体现在命名和标注上。截图命名为“BUG-1024_第一页截图_20250612-1015”和“BUG-1024_第二页截图_20250612-1016”，响应报文命名为“BUG-1024_响应报文_20250612-1016”，日志命名为“BUG-1024_服务端日志_20250612-1017”。描述中在复现步骤第四步标注“见第二页截图与响应报文”，处理人可直接定位到翻页请求的返回内容。留存做法上，原始报文和日志完整保留，截图中如包含用户手机号则做遮盖处理后再上传。
提交前的完成检查
提交前由提交人自检、复核人复核，按以下清单逐项核对。每项都有明确的通过标准，未通过的项目应作为阻断项处理，补齐后再提交。
| 检查维度 | 检查项 | 通过标准 |
|---|---|---|
| 完整性 | 复现步骤、预期与实际结果、环境信息是否齐全 | 六类证据中与本次缺陷相关的类型均已提供，无空缺字段 |
| 完整性 | 附件是否与描述中提到的证据一一对应 | 描述中每个“见附件”的标注都能找到对应文件 |
| 一致性 | 描述中的实际结果与截图、日志内容是否一致 | 文字描述的现象能在附件中找到对应画面或记录 |
| 一致性 | 环境信息与日志中的版本、时间是否吻合 | 日志时间与采集时间在同一操作窗口内 |
| 可复现性 | 他人按步骤能否到达相同状态 | 复核人按步骤操作一次，能观察到相同现象或相同报错 |
| 可追溯性 | 文件命名与存放位置是否符合团队规则 | 文件名包含缺陷编号、证据类型和采集时间，存放位置统一 |
| 合规性 | 敏感数据是否已脱敏 | 对外共享的副本中不包含未遮盖的个人信息或生产数据 |
阻断项包括：缺少复现步骤、实际结果与附件矛盾、日志时间与操作时间明显不符、敏感数据未脱敏。出现任一阻断项时，缺陷不进入处理环节。复核人通过后，在缺陷记录中留下复核结论和复核时间；缺陷关闭时确认证据附件仍可访问，完成归档。ONES Project 支持统计缺陷状态分布，可用于复盘阶段查看缺陷流转情况，统计口径以实际配置为准。
常见问题
偶现缺陷抓不到日志和录屏，证据该怎么补？
偶现缺陷优先保证现场信息不丢失。异常出现时先录屏并记下大致时间点，再在不刷新页面、不重启服务的前提下导出日志，按时间窗口截取相关片段。若当场未能采集，可在缺陷记录中写明已尝试的复现次数、复现条件和观察到的现象，并标注“待补充日志”。
处理人接收后，可约定下一次出现时的采集动作，例如开启更详细的日志级别或安排值守观察。证据不足时如实记录，比用推测填补更利于后续定位。
证据中包含用户手机号、订单号等敏感信息，还能直接上传吗？
涉及个人信息或生产数据时，先脱敏再共享。做法是保留足以复现问题的结构信息，例如保留请求参数名而遮盖具体值，遮盖手机号中间位、身份证号和真实姓名。原始文件完整保留在受限位置供定位使用，对外流转和跨团队查看使用脱敏副本。
脱敏范围取决于数据敏感程度和查看范围。缺陷处理链路上的角色需要看到的信息应保留，超出定位需要的内容可以遮盖。
复核人和提交人是同一个人时，检查还有意义吗？
小团队中角色可以合并，但复核动作建议与采集动作分开执行，至少间隔一段时间或换一个检查视角。提交人自检容易顺着自己的思路核对，漏掉“步骤省略”“附件与描述不符”这类问题。
如果确实无人可分，可以按提交前检查清单逐项打勾，并请处理人在接收时反馈证据是否足够。处理人提出补充需求时，说明缺少哪类信息，由提交人补齐后重新流转。
处理人认为无法复现，证据包该怎么处理？
先核对复现条件是否一致，包括环境版本、账号角色、前置数据和操作顺序。提交人可补充录屏或日志后再次提交，重点标注异常出现的时间点和对应操作步骤。
仍无法复现时，记录双方结论并标注复现条件差异，例如“提交人环境可复现、处理人环境未复现，差异为客户端版本”。这条记录本身也是后续排查的线索，不建议直接关闭了事。
缺陷关闭后，证据附件要保留多久？
保留期限按团队质量管理和审计要求确定，常见做法是缺陷关闭后保留一段时间以支持复盘和回归对照。涉及合同、合规或对外交付的项目，期限可能更长。
归档时确认附件仍可访问，并检查存放位置是否符合团队规则。使用缺陷管理工具承载时，可在缺陷记录中统一存放附件，借助项目权限控制查看范围；ONES Project 支持缺陷跟踪管理，可将 Bug 提交至对应项目或迭代并记录修复情况，具体保留策略与权限范围需按实际配置确认。
