缺陷证据收集可以按“复现—采集—标注—归档—评审”五步执行：先在最小条件下确认现象，再采集截图或录屏、日志、环境信息和数据样本，为每份证据标注时间、来源与操作步骤，归档到对应缺陷记录，最后在提交前核对他人能否据此独立复现。本文面向提交缺陷的测试、开发和业务人员，讨论如何把一条缺陷记录做扎实；严重程度判定、修复回归和服务事件受理不在本文展开。
要点总览（TL;DR）
- 缺陷证据收集按“复现—采集—标注—归档—评审”五步执行，每步都有明确输出物，交接时不依赖口头补充。
- 采集顺序固定为现象证据、过程证据、环境证据、数据证据；界面类重截图录屏，逻辑与数据类重步骤和输入输出样本，性能与兼容性类重参数与矩阵。
- 提交人负责第一手采集与标注，复现人补充验证，开发提出具体回退请求，缺陷管理员按清单把关完整性。
- 证据统一挂在缺陷工作项下，按“缺陷编号_类型_序号”命名，多次补充递增序号保留历史版本。
- 提交前核对可复现性、证据完整性、脱敏、命名关联和标注五项，无法复现且未说明偶现条件、缺过程或环境证据、含未脱敏敏感信息时应退回补充。
缺陷证据收集的核心步骤
五步流程的价值在于每一步都有明确输出物，交接时不必依赖口头补充。下面按输入、动作、输出和完成标志逐项说明。
第一步：确认最小复现条件
输入是发现缺陷时的原始场景，包括账号、页面、数据、设备、版本和操作路径。动作是逐步缩小触发范围：先按原路径重走一遍，确认现象稳定出现；再依次去掉无关步骤、替换无关数据，找到仍然能触发问题的最短路径。输出是一段可重复执行的操作序列，以及现象出现的频率，例如“每次必现”或“约三次出现一次”。完成标志是另一个人按这段序列操作，能看到相同现象。
这一步容易被跳过，直接进入截图。缺少最小复现条件时，截图只能证明“当时屏幕上出现了什么”，无法说明“怎样才会出现”，开发拿到后往往需要重新摸索。
第二步：按顺序采集证据
建议固定采集顺序，避免遗漏：
- 现象证据：截图或录屏。录屏应包含从操作起点到异常出现的完整过程，截图应保留页面关键区域和浏览器或客户端界面信息。
- 过程证据：应用日志、接口请求与响应、控制台报错、任务执行记录。日志截取异常时间点前后一段，保留时间戳和级别。
- 环境证据：应用版本、操作系统与浏览器版本、设备型号、网络环境、相关配置项、测试环境地址或标识。
- 数据证据：触发问题所用的输入值、数据样本、账号角色与权限、关联单据编号。数据量较大时提供可导入的样本文件，并说明字段含义。
输出是一组按上述类别命名的证据文件。完成标志是每类证据都能对应到复现步骤中的某一步，没有孤立存在的文件。
第三步：为每份证据添加标注
标注至少包含五项：采集时间、证据来源（哪个系统、哪个页面、哪台设备）、对应的操作步骤编号、预期结果与实际结果、关联的缺陷编号。截图和录屏可在文件名或说明中标注，日志可在关键行加注释或单独说明行号。输出是带说明的证据集合。完成标志是复现人只看标注就能理解每份证据证明什么。
第四步：归档到缺陷记录
把证据统一放入对应缺陷工作项的附件或说明区域，按“缺陷编号_证据类型_序号”的方式命名，例如“BUG-1024_录屏_01”。同一缺陷多次补充采集时保留序号递增，不覆盖旧文件。输出是一条证据齐全的缺陷记录。完成标志是缺陷记录本身即可作为交接材料，不需要再到聊天记录或本地目录中找文件。
第五步：提交前自检与评审
提交人先按后文检查清单逐项核对，再由测试或复现人按记录独立走一遍复现路径。输出是通过自检的缺陷记录和复现结论。完成标志是复现人无需询问提交人即可重现问题，或明确指出还缺哪类证据。
不同缺陷类型该收集哪些证据
截图是通用证据，但只靠截图会掩盖逻辑、数据和性能问题的关键信息。证据组合应随缺陷类型调整，下表给出常见类型的对照。
| 缺陷类型 | 核心证据 | 补充证据 | 常见遗漏 |
|---|---|---|---|
| 界面类 | 异常区域截图、完整页面截图、操作录屏 | 浏览器或客户端版本、分辨率与缩放比例、样式相关的配置 | 只截局部，缺少页面整体和触发前的正常状态 |
| 逻辑类 | 操作步骤序列、每步的页面或接口结果、预期与实际对比 | 相关业务规则说明、角色权限、状态流转记录 | 只描述最终错误结果，缺少中间步骤的状态变化 |
| 数据类 | 输入数据样本、处理后的输出、数据库或接口返回记录 | 数据来源、导入时间、关联单据、统计口径 | 只给截图中的数字，未提供可复算的原始数据 |
| 性能类 | 监控曲线或耗时记录、压测或操作参数、并发量 | 服务器资源指标、网络条件、数据量级、复现时间窗口 | 只写“很慢”，缺少耗时数值和对比基准 |
| 兼容性类 | 设备与版本矩阵、各环境下的现象截图 | 操作系统版本、浏览器内核、网络类型、安装包版本 | 只在一个环境验证，未说明其他环境的表现 |
界面类与逻辑类的采集重点
界面类缺陷优先保证“看得全”：异常区域、完整页面、触发前的正常状态各一张，配合一段从点击到异常出现的录屏。逻辑类缺陷优先保证“走得通”：把操作序列拆成编号步骤，每一步记录页面提示或接口返回，特别标注状态发生变化的那一步。
数据类缺陷的样本要求
数据类缺陷的证据核心是可复算。提供触发问题的原始输入，说明数据来源和导入方式，附上系统处理后的输出，并注明统计口径或计算规则。涉及金额、数量、比例时，给出参与计算的具体数值，便于开发核对。
性能与兼容性缺陷的参数记录
性能类缺陷需要把“慢”转化为可比较的数值：操作耗时、接口响应时间、并发用户数、数据量级、采集时间段。兼容性类缺陷需要说明测试矩阵：哪些设备或版本出现问题、哪些正常，各自的操作结果如何。证据不足时，补充采集优先于文字描述，例如提高日志级别重跑一次、缩小数据范围再试、录制完整操作序列、在第二个环境交叉验证。
角色分工与各环节交付物
证据收集通常涉及四类角色。职责边界清晰，交接时就不容易出现“以为对方会补”的空档。
| 角色 | 主要动作 | 交付物 | 交接对象 |
|---|---|---|---|
| 提交人（测试、业务或开发） | 确认最小复现条件，采集并标注证据，完成提交前自检 | 带证据和标注的缺陷记录 | 测试或复现人、缺陷管理员 |
| 测试或复现人 | 按记录独立复现，补充缺失证据，确认现象范围 | 复现结论、补充证据、影响范围说明 | 开发、缺陷管理员 |
| 开发 | 评估证据是否足以定位，证据不足时提出具体回退请求 | 回退请求（缺哪类证据、需要什么条件）或受理结论 | 提交人、测试 |
| 缺陷管理员 | 检查证据完整性与字段规范，维护缺陷记录质量 | 完整性检查结论、退回或通过记录 | 提交人、开发 |
提交人的采集与标注责任
提交人对第一手证据负责：现象出现时立即采集，避免环境变化后无法还原；按统一格式标注时间、来源、步骤和预期实际结果；提交前完成自检。提交人不负责判断缺陷的严重程度，但应如实记录影响范围和出现频率。
测试或复现人的补充验证
复现人按记录独立操作，重点确认三件事：现象是否稳定出现、影响范围有多大、是否与其他缺陷重复。发现证据缺口时直接补充采集，并在记录中注明补充时间和补充人，保持证据链条可追溯。
开发的回退请求
开发在证据不足以定位时，应提出具体请求，例如“需要异常时间点前后五分钟的服务端日志”“需要该账号的角色权限配置”“需要在数据量为十万条时复测一次耗时”。回退请求写明所需证据类型和用途，避免笼统回复“信息不足”。
缺陷管理员的完整性把关
缺陷管理员按检查清单核对证据项是否齐全、命名是否规范、敏感信息是否处理、关联关系是否正确。不满足条件的记录退回提交人补充，并在记录中写明退回原因，形成可统计的质量反馈。
一个完整的证据收集示例
以下为演示情景，用于说明各环节的产物形态。
缺陷现象
某订单管理页面在筛选“已发货”状态后，列表显示 0 条，但订单总览显示该状态有 37 条订单。提交人为测试人员，在测试环境操作时发现。
复现条件与采集到的证据
最小复现条件：使用仓库管理员角色账号，进入订单列表，选择状态“已发货”，点击查询，列表为空；切换为“全部”状态后列表正常显示。证据包括：
- 录屏一段，记录从登录到筛选结果为空的完整操作；
- 截图两张，分别为筛选结果页和订单总览页；
- 接口请求与响应记录一份，显示筛选请求返回空数组；
- 应用日志一段，覆盖请求时间点前后各三分钟；
- 环境信息：应用版本、测试环境标识、浏览器版本、账号角色；
- 数据样本：涉及的订单编号列表和状态字段导出文件。
标注内容
录屏标注“步骤 1–5，预期显示 37 条，实际 0 条”；接口记录标注请求时间、请求参数中的状态值和返回条数；日志标注关键行号，说明该时间段内无报错；数据样本标注导出时间和筛选条件。所有证据统一关联缺陷编号 BUG-1024。
归档后的缺陷记录
缺陷记录包含：标题“订单列表按已发货状态筛选结果为空”、复现步骤五条、预期与实际结果、上述附件、环境信息字段、关联的订单总览页面需求编号。附件按“BUG-1024_录屏_01”“BUG-1024_接口_01”等命名。
开发复现结果
开发按记录中的步骤和账号角色操作，在相同环境复现出列表为空的现象；结合接口返回和日志，定位到筛选参数在特定角色下未正确传递。整个过程未再向提交人索要补充材料。
证据归档与协作流程的承载方式
证据只有跟随缺陷记录流转，才能在评审、交接和后续回归中被再次使用。归档方式应满足三个条件：证据与缺陷工作项直接关联、附件有稳定的存放位置和命名规则、评审与交接时相关角色能看到同一份材料。
证据与缺陷工作项的关联
每条缺陷工作项作为证据的唯一归集点，截图、录屏、日志、数据样本作为附件或说明内容挂在记录下。缺陷与需求、测试用例、迭代建立关联，复现人从用例执行结果进入缺陷时能直接看到上下文。ONES Project 支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；ONES TestCase 支持在用例未通过时快速创建缺陷任务，使缺陷在测试与研发团队间流转。这类关联让证据不必在多个系统间搬运。
附件与日志的存放与版本
同一缺陷多次补充证据时，采用递增序号保留历史版本，不覆盖旧文件；日志文件注明采集时间段和采集人；较大的数据样本可压缩后上传，并在说明中写明解压后的字段结构。附件大小、格式与数量限制，以及证据历史版本的留存方式，需以实际使用环境的配置为准，归档前先确认。
评审与交接时的证据可见性
缺陷评审、开发受理和回归验证使用同一份缺陷记录。评审时按检查清单核对证据项，交接时以记录中的复现步骤和附件为准，回归时对照原始证据确认现象是否消失。ONES TestCase 支持为不同用户组和用例库、测试计划配置权限，团队可据此控制测试相关材料的可见范围；缺陷附件的具体权限粒度需在实际环境中确认。
提交前的完成检查
以下清单用于提交前逐项核对。任一项不通过，应先补充或修正，再提交评审。
| 检查项 | 核对内容 | 通过标准 | 不通过时的处理 |
|---|---|---|---|
| 可复现性 | 复现步骤是否完整、账号与环境是否写明、出现频率是否记录 | 他人按步骤可独立重现，或明确说明偶现条件 | 回到第一步缩小复现范围，补充操作序列 |
| 证据完整性 | 现象、过程、环境、数据四类证据是否齐全，是否与步骤对应 | 每类证据至少一项，且能对应到具体步骤 | 按缺陷类型对照表补充缺失类别 |
| 敏感信息脱敏 | 截图、日志、数据样本中是否含真实姓名、手机号、身份证号、密钥等 | 敏感字段已遮盖或替换，关键复现字段保留 | 重新采集或处理后再上传，不保留未脱敏原件 |
| 命名与关联 | 附件命名是否符合“缺陷编号_类型_序号”，是否关联需求、用例或迭代 | 命名统一，关联关系正确 | 重命名并补建关联 |
| 标注完整性 | 时间、来源、步骤编号、预期与实际结果是否齐全 | 每份证据均有说明，复现人无需追问 | 补充标注后再提交 |
阻断条件建议设为三条：无法按记录复现且未说明偶现条件；缺少过程证据或环境信息，导致开发无法定位；证据中含未脱敏的敏感信息。出现任一情况时退回补充，并在缺陷记录中写明退回原因。通过检查后，由复现人确认复现结论，缺陷记录进入受理环节。
常见问题
缺陷偶现、无法稳定复现时，证据该怎么收集？
偶现缺陷同样要留下可追溯的记录，重点从“证明必现”转为“记录出现条件”。可以这样处理：
- 记录出现的时间点、操作路径和当时的环境状态，出现一次就采集一次，多次记录后对比共同点。
- 保留异常时间点前后的完整日志，必要时临时提高日志级别再观察一段时间。
- 说明已尝试的复现次数和成功次数，例如“操作 20 次出现 3 次”，让开发了解概率。
- 在缺陷记录中标注“偶现”，并写明尚未确认的触发条件，便于后续补充。
偶现不等于证据可以不完整，环境信息和过程证据反而更重要。
证据里包含用户手机号、身份证号等敏感信息，怎么处理才不影响复现？
先脱敏再归档，同时保留复现所需的关键字段。常见做法是遮盖或替换姓名、手机号、身份证号、密钥等字段，保留数据长度、格式和关联关系；日志中的敏感字段用占位符替换，并注明替换规则。数据样本可以只保留触发问题所需的行和列。脱敏后的证据仍需能支撑复现，如果替换后现象消失，应说明脱敏方式与原始数据的差异。未脱敏的原件不随缺陷记录上传。
开发回复“信息不足”时，提交人应该补什么？
先请开发说明缺的是哪一类证据、用来判断什么，再针对性补充。常见的补充方向包括：异常时间点前后一段服务端日志、触发账号的角色与权限配置、特定数据量级下的复测结果、接口请求的完整参数与返回。补充后在缺陷记录中注明补充时间、补充人和补充内容，保持证据链可追溯。把“信息不足”转化为具体的证据清单，比反复上传截图更有效。
证据应该放在缺陷记录里，还是放在共享目录或聊天群里？
以缺陷工作项作为唯一归集点，截图、录屏、日志和数据样本作为附件或说明内容挂在记录下，共享目录和聊天记录只作为临时传递。这样评审、交接和回归时使用的是同一份材料。ONES Project 支持一键提交 Bug 至对应项目或迭代并跟踪修复情况，ONES TestCase 支持在用例未通过时快速创建缺陷任务，使缺陷在测试与研发团队间流转。附件大小、格式与数量限制，以及证据历史版本的留存方式，需以实际使用环境的配置为准。
缺陷管理员退回记录时，怎样避免变成反复拉扯？
退回时写明具体缺项和通过标准，例如“缺少异常时间点前后日志”“截图未遮盖手机号”“附件命名未按缺陷编号规则”，而不是笼统写“证据不全”。提交人补充后在同一记录中回复补充内容，管理员按同一份检查清单复核。退回原因可以按类型统计，用于发现团队在证据采集上的共性缺口，再针对性调整模板或培训。
