缺陷重新打开时，需要补充能证明“原问题仍可复现”或“修复引入回归”的证据：构建与版本、环境与配置、前置数据、复现步骤、实际结果与预期结果、日志或截图录屏、复现概率与影响范围，以及本次验证与上一轮修复说明的对应关系。核心条件是证据可被他人按同样步骤独立复算，避免只写一句“还是不行”。
要点总览（TL;DR）
- 重新打开缺陷的核心证据是“可复算”：构建与版本、环境与配置、前置数据、复现步骤、实际结果与预期结果、附件证据、复现概率，缺一项都可能让修复人无法走到同样的失败现场。
- 复现概率 = 复现次数 ÷ 有效尝试次数 × 100%，有效尝试须同一构建、同一前置条件；尝试次数为 0 时标记“未验证”，不写成 0%。
- 证据充分度 = 已采集必填字段数 ÷ 必填字段总数 × 100%，它只反映记录完整程度，不反映缺陷严重程度或修复质量。
- 补齐顺序是确认构建与环境、按原步骤复现并记录尝试次数、采集附件、填写字段、提交重新打开并注明与上轮修复的差异，提交人、修复人、验证人各负其责。
- 复现概率受环境、数据和尝试次数影响，不同构建之间不可直接比较；未复现时应写“当前条件下未验证”，并保留尝试次数与差异条件。
重新打开要证明什么：评估目标与通过标准
重新打开缺陷的证据目标只有一个：证明在指定构建下，原缺陷仍可复现，或者修复动作引入了新的回归问题。这个目标决定了证据要围绕“可复算”组织，而不是围绕“表达不满”组织。提交人需要让修复人仅凭记录就能走到同样的失败现场，否则重新打开只是一次状态回退，无法推动修复。
实际操作中，重新打开通常对应三类情形，证据侧重点不同：
- 原问题未修复：在包含上轮修复的构建上，按原步骤仍得到错误结果。证据重点是构建号与上轮修复说明的对应关系，以及复现步骤与原缺陷记录的一致性。
- 修复引入新问题：原问题不再出现，但同一功能路径上出现新的错误结果。证据重点是标明“新现象与原缺陷的差异”，并附上原缺陷已消失的对照记录。
- 验证环境或数据不满足前提：复现依赖特定配置、数据状态或依赖版本，当前环境不满足。此类情形应先补齐前提条件再判断，证据中要写明差异条件，避免把环境问题记成修复无效。
证据是否通过，可按三条标准判定：第一，他人按记录中的构建、环境、前置数据和步骤操作，能得到相同的实际结果；第二，实际结果与预期结果的对照清晰，预期结果有出处（需求、用例或上一轮修复说明）；第三，记录中包含尝试次数与时间窗，使复现概率可被复算。三条同时满足，才构成一次有效的重新打开。
证据清单与数据口径：哪些字段必须补齐
重新打开时建议按固定字段补齐证据，每个字段都规定取值口径和缺失处理方式，避免不同人写出无法比对的内容。下表给出字段、口径与必填要求。
| 字段 | 取值口径 | 必填/选填 | 缺失处理 |
|---|---|---|---|
| 构建/版本号 | 填写实际验证的构建标识，与上轮修复所在构建区分 | 必填 | 无法获取时标注“未采集”并说明原因，不填猜测值 |
| 环境与配置 | 操作系统、浏览器或客户端版本、服务端环境、关键配置项 | 必填 | 部分缺失时逐项标注缺失项 |
| 前置数据 | 账号角色、数据状态、依赖服务版本等复现前提 | 必填 | 标注“未采集”，并说明是否影响复现 |
| 复现步骤 | 按顺序编号，每步一个动作，可被他人照做 | 必填 | 不允许缺失；步骤不完整视为证据不成立 |
| 实际结果 | 观察到的事实，含错误码、提示文案、异常表现 | 必填 | 不允许缺失 |
| 预期结果 | 引用需求、用例或上轮修复说明中的期望行为 | 必填 | 无出处时标注“待确认”，不自行推定 |
| 复现概率 | 复现次数÷有效尝试次数，注明时间窗 | 必填 | 尝试次数为0时标记“未验证” |
| 附件证据 | 日志片段、截图或录屏、接口返回、错误码，注明采集时间与来源 | 必填（至少一类） | 无法采集时说明原因及替代证据 |
| 影响范围 | 受影响的用户角色、功能路径、数据量级 | 选填 | 标注“未评估” |
| 与上轮修复的差异 | 本次构建、环境或数据与上轮验证条件的差异点 | 选填 | 标注“无差异”或“未比对” |
附件类证据要注明采集时间和来源，例如日志片段标明取自哪个服务、哪个时间段，截图录屏标明操作到哪一步。接口返回保留原始响应体关键字段，错误码原样记录，不做转述。口径规则上，复现概率以尝试次数为分母，并写明统计起止时间；无法复现时同样记录尝试次数和差异条件，这本身就是有价值的证据。字段缺失时统一标注“未采集”并说明原因，不用推测内容填充，避免后续比对时把推测当成事实。
复现概率与证据充分度怎么算
复现概率用于描述缺陷在当前条件下的稳定程度，公式为：复现概率 = 复现次数 ÷ 有效尝试次数 × 100%。有效尝试需满足同一构建、同一前置条件、按同一组步骤操作；更换构建或改变前置数据后的尝试不计入同一分母。例如在构建 B2 上按原步骤尝试 5 次、复现 4 次，复现概率为 80%，统计时间窗写明为某日某时段，单次尝试耗时口径一并注明。
证据充分度用于描述记录完整程度，可按必填字段覆盖率计算：证据充分度 = 已采集必填字段数 ÷ 必填字段总数 × 100%。以上表 8 项必填字段为例，采集 7 项则为 87.5%。这个指标只反映记录是否齐全，不反映缺陷严重程度，也不代表修复质量。
分母处理需要单独规定：尝试次数为 0 时不计概率，标记为“未验证”，不能写成 0%。0% 意味着尝试过且从未复现，与“没有验证”是两种不同结论，混用会误导修复判断。时间窗与单位同样要写清：统计起止时间、尝试次数、单次尝试的大致耗时，三者共同构成可复算的口径。不同构建、不同环境下的复现概率不可直接比较，需要分别记录。
重新打开的操作步骤与交接
证据补齐按固定顺序执行，可以减少来回沟通。建议步骤如下：
- 确认本次验证的构建与环境，核对是否包含上轮修复，记录构建标识。
- 按原缺陷记录的步骤复现，逐次记录尝试结果，累计尝试次数与复现次数。
- 采集附件证据，日志、截图或录屏注明采集时间与来源。
- 按字段表填写构建、环境、前置数据、步骤、实际与预期结果、复现概率。
- 提交重新打开，注明本次条件与上轮修复说明的差异，附上证据位置。
角色分工上，提交人负责复现证据与字段填写，是证据完整性的第一责任人；修复人补充上轮修复的范围与影响面，说明改了哪些模块、预期影响哪些路径，帮助判断本次现象属于未修复还是回归；验证人确认证据可被独立复算，对步骤完整性和口径一致性做最后核对。三方输入与产出可按下表交接。
| 角色 | 输入 | 产出 |
|---|---|---|
| 提交人 | 原缺陷记录、本次构建与环境 | 复现步骤、尝试次数、附件证据、字段表 |
| 修复人 | 上轮修复说明、变更范围 | 修复范围与影响面说明、差异点确认 |
| 验证人 | 提交人与修复人材料 | 可复算性确认、口径核对结论 |
状态交接上，重新打开后缺陷回到待修复状态，证据以记录内附件或链接形式随单流转，避免口头转述。证据与缺陷记录放在同一处，后续修复、复测和复盘都能追溯到同一份材料。在 ONES Project 中，缺陷可作为工作项承载，支持一键提交 Bug 至对应项目或迭代，并记录和跟踪修复情况；ONES ALM 方案把测试用例、缺陷、版本和发布关联到需求链路，出现问题时便于沿关联关系定位影响范围。团队可据此把构建号、复现步骤和附件随缺陷记录一并留存，减少证据散落在聊天工具里的情况。
一个完整例子：从“还是不行”到可复算证据
以下为演示情景，数值仅用于说明计算口径，不代表真实项目数据。某接口在构建 B2 上调用后返回错误码 5001，首次修复后再次出现。
补齐前的记录只有一句“这个问题还是不行”，修复人无法判断是原问题未修复、环境差异还是新回归，只能再次询问，来回一轮才拿到基本信息。
补齐后的记录包含：构建号 B2（含上轮修复）；环境为测试环境、指定客户端版本与配置项；前置数据为某角色账号与特定数据状态；复现步骤 4 步，按顺序编号；实际结果为调用后返回错误码 5001，预期结果为返回成功并写入记录，预期出处为对应用例；附件为服务端日志片段，注明采集时间与来源；复现概率为 5 次尝试复现 4 次，即 80%，统计时间窗为当日某时段；必填字段 8 项采集 7 项，证据充分度 87.5%，缺失项标注“未采集”及原因。
对照来看，补齐前的记录无法复算，补齐后他人可按构建、环境、前置数据和步骤走一遍，得到相同错误码，并核对 80% 的复现概率是否与自己的尝试结果一致。修复人据此可以判断问题出在修复未覆盖的路径，而不是环境偶发。
结果怎么解读：限制与常见误用
复现概率受环境、数据和尝试次数影响，不同构建之间不可直接比较。80% 与 50% 放在一起看，可能只是尝试次数和条件不同，不能据此判断哪个缺陷更严重。证据充分度高只说明记录完整，不证明缺陷严重程度或修复质量；字段齐全但步骤写错，同样无法复算。
常见误用有几类：把未复现直接判为已修复，忽略了尝试次数不足或环境差异；用单次尝试下结论，一次复现就断言必现，或一次未复现就关闭；忽略环境差异，把本地环境的结果直接套到测试环境。这些做法都会让重新打开失去判断价值。
建议做法是保留差异条件说明，无法复现时记录尝试次数与差异点，必要时补充对照环境验证，例如在同一构建的不同配置下各试若干次，分别记录结果。证据不足时，结论应写成“当前条件下未验证”或“证据不完整”，而不是“已修复”或“无法修复”。把证据、口径和结论分开表述，后续复盘才能区分是缺陷本身的问题，还是验证过程的问题。
常见问题
缺陷重新打开后，修复人认为证据不完整，应该退回还是先排查？
建议先做一次快速核对，再决定是否退回。核对的内容是：构建号是否包含上轮修复、复现步骤能否照做、实际结果与预期结果是否都有记录。如果这几项齐全，即使附件缺失或影响范围未评估，也可以先进入排查，由修复人补充上轮修复范围与影响面，提交人随后补齐附件。
如果复现步骤不完整或构建号缺失，证据无法复算，退回补充更合适。退回时写明缺哪几项、为什么影响判断，避免只回复“证据不足”。
同一缺陷在不同构建上复现概率不一样，重新打开时以哪个为准？
以本次实际验证的构建为准，并在记录中写明构建标识。不同构建的复现概率不可直接比较，因为修复内容、依赖版本和环境配置都可能不同。如果需要在多个构建上对比，应分别记录每个构建的尝试次数、复现次数和时间窗，各自计算，不合并成一个分母。
若旧构建复现、新构建未复现，这本身是有价值的对照信息，应写入“与上轮修复的差异”字段，帮助判断修复是否部分生效。
尝试次数很少时，复现概率还有参考价值吗？
有参考价值，但要连同尝试次数一起看。1 次尝试复现 1 次，概率是 100%，这个数字说明的是“本次尝试复现了”，不能推断缺陷必现。记录中应同时写明尝试次数和单次耗时，让读者自行判断样本量是否足够。
当尝试次数为 0 时，不计概率，标记为“未验证”。这与“尝试过但从未复现”的 0% 是两种不同结论，混用会误导修复判断。
证据字段都填了，为什么仍然被判为不可复算？
常见原因是字段填了但口径不对。例如复现步骤写成“打开页面点击提交”，没有编号和具体输入；实际结果写成“报错了”，没有错误码或提示文案；附件没有注明采集时间和来源，无法确认对应哪次尝试。这类记录字段齐全，但他人照做走不到同样的失败现场。
证据充分度高只说明记录完整，不证明可复算。提交前可以自查一遍：换一个人只看记录，能否按步骤得到相同的实际结果。
在 ONES 中记录这些证据，有什么现成的方式？
ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通，可一键提交 Bug 至对应的项目或迭代，并记录和跟踪修复情况。团队可以把构建号、复现步骤、实际与预期结果写在缺陷工作项的描述字段，日志、截图等附件随工作项留存，重新打开时证据与缺陷记录在同一处，后续修复、复测和复盘都能追溯。
ONES ALM 方案把测试用例、缺陷、版本和发布关联到需求链路，出现问题时便于沿关联关系定位影响范围。重新打开时是否强制填写指定字段、是否支持复现次数等量化字段，取决于团队的工作项配置，具体能力以实际开通版本为准。
