## 任务目标
请将测试发现整理成研发能够定位、测试能够复核的缺陷记录。可处理单个缺陷或去重后的问题清单。
以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。
## 输入信息（选填）
两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。
待核对问题：
问题证据：
## 信息不完整时
先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。
### 优先确认
- 核对每份截图、日志或接口记录的版本、终端、账号角色、组织及时间，避免合成不存在的单次事故。
- 沿现象定位需求条目、关联用例和最小操作路径，查清预期结果的来源。
- 查已有修复记录、相关变更和复测产物，区分修复声明与实际回归证据。
### 可采用的默认处理
- 先只读整理证据与复现步骤；真实操作复现仅在已授权的隔离条件内执行，未执行则标为材料复现描述。
- 严重程度与优先级依据实际业务影响给出建议，根因事实、假设和排查方向分别记录。
- 相似问题按触发条件及实际结果去重，保留原始证据入口，交付记录中的身份和凭据信息脱敏。
### 必须有依据的事项
- 需求无法确定预期行为或与现实现象对应的规则冲突时，不能把偏好直接判定为缺陷；先记录差异和影响。
- 复现需要真实支付、删除或生产写入且无可用隔离条件时，不执行该操作；继续交付最小步骤与隔离数据要求。
只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。
### 资料仍不足时的交付
- 没有运行环境时交付前置条件、最小复现步骤、预期与实际对照、已有证据和针对性排查顺序。
- 没有修复版本时交付原场景及相邻功能的复测条件，状态保持待修复或待验证，不虚报关闭。
## 执行要求
将需求、用例、复现证据和缺陷关联起来，关闭条件以约定的复测与回归要求为准。
1. 核对问题出现的版本、终端、账号角色、组织范围和时间，确定证据对应同一次操作还是不同执行。资料冲突时列出冲突，不把截图、日志和需求拼成不存在的单次事故。
2. 用最少而完整的步骤重建前置条件与操作路径，每一步写清对象、输入和动作。能实际执行时记录复现次数与结果；不能执行时标记为材料复现描述。
3. 并列写出需求支持的预期结果与已观察的实际结果，分别说明页面、接口和数据层证据。缺少规则依据时标为待确认行为，不能把个人偏好直接判为缺陷。
4. 分析受影响角色、业务流程和数据范围，按团队已有定义建议严重程度与修复优先级。把根因事实、待验证假设和排查方向分开，避免仅凭报错猜定数据库或缓存故障。
5. 对相似问题按触发条件、实际结果和可能影响合并，保留关联用例与原始证据入口。日志和截图中的身份信息、令牌与密码应在交付记录中脱敏。
6. 有修复版本时，设计原场景复测和相邻功能回归，记录实际执行证据。只有满足复现用例和约定回归条件才能建议关闭；仍有问题则说明重新打开的依据。
## 交付与验收
输出：缺陷标题、关联需求或用例、环境版本、前置条件、步骤、预期与实际、证据、影响与优先级理由、排查假设、复核条件、当前状态。修复复核记录独立保留时间和版本。
验收：第三方可按记录尝试复现；预期有依据；证据可定位且不泄露凭据；状态符合实际；没有把建议排查写成已证实根因或把未执行回归写成通过。
信息边界：缺少运行条件时明确无法复现的原因；不替研发承诺修复时间，不未经授权修改外部缺陷状态或向其他人发送消息。
### 本条完成检查
- 第三方能依据记录尝试复现，步骤、版本、对象和预期均有来源。
- 证据与判断分开，根因未证实就保留假设，敏感信息已脱敏。
- 建议关闭的缺陷具有对应修复版本的实际复测与约定回归证据，缺失部分明确列出。
按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。
## 参考资料与适用边界
参考来源（核验于 2026-09-08）：
- [CODING DevOps：测试管理](https://cloud.tencent.com/document/product/1726/96965)
