来自生产环境的缺陷截图和日志，往往夹带真实用户手机号、账号、令牌或内网地址。提交前把这些信息识别出来并做不可逆遮蔽，既能保留复现所需的错误码、堆栈和时间线，也能避免敏感数据随缺陷记录扩散。下面按“列清单—做遮蔽—定角色—看示例—过检查”的顺序，给出一套可以直接执行的脱敏流程。
要点总览（TL;DR）
- 提交前把附件脱敏当作固定关卡：先按清单识别截图与日志中的账号、手机号、身份证号、令牌、密钥和内网地址，再遮蔽，最后复核。
- 遮蔽遵循不可逆优先、保留复现信息的原则：截图裁剪后打码或用不透明色块覆盖，日志按字段替换或删除，时间戳、错误码、堆栈和请求路径原样保留。
- 提交人负责识别与遮蔽并填写脱敏记录，复核人由非提交人担任，按清单二次检查通过后才允许提交。
- 出现未处理的账号、手机号、令牌或内部地址，或遮蔽可被还原时，必须阻断提交并返工重做。
- 脱敏记录与附件一并留存，团队可将检查表固化为缺陷提交模板中的必填项，让脱敏成为流程中的固定环节。
先列清单：截图和日志里要识别哪些敏感信息
识别阶段的目标是把“可能敏感”的位置全部找出来并登记，暂不处理。建议先按字段名和关键词做批量扫描，再逐张截图、逐段日志人工核对上下文。关键词扫描负责覆盖，人工核对负责判断：同一个数字串在订单号里可以保留，在手机号字段里就必须遮蔽。
截图类附件常见命中项如下：
| 类别 | 典型内容 | 常见位置 |
|---|---|---|
| 账号与身份 | 用户名、登录账号、真实姓名、身份证号 | 页面右上角、个人中心、表单回显 |
| 联系方式 | 手机号、邮箱、收货地址 | 订单详情、用户列表、弹窗提示 |
| 系统信息 | 内部系统地址、域名、内网 IP、主机名 | 浏览器地址栏、报错弹窗、调试面板 |
| 业务标识 | 工单编号、客户标识、合同号 | 列表页、详情页标题、面包屑 |
日志类附件常见命中项包括：访问令牌与 API Key、Cookie 与 Session ID、密码及各类密钥、数据库连接串、内网 IP 与主机名，以及请求参数中携带的个人信息。日志的关键词扫描可以围绕 token、password、secret、cookie、session、phone、mobile、idcard、ip、host、jdbc 等字段名展开，命中后回到原始上下文确认该值是否真实敏感。
识别结果要落到一张脱敏记录表上，表头建议包含：附件名称、命中位置（页码或行号）、信息类型、原始值摘要（只记类型和位数，不抄全文）、处理方式、处理人。这张表既是复核依据，也是后续追溯的凭证。
操作步骤：从识别到遮蔽的完整流程
遮蔽阶段遵循两条原则：敏感字段做不可逆处理，复现所需信息尽量保留。打码和色块覆盖要确认无法通过调亮、去色或还原图层读回原文；日志字段用替换或删除处理，但时间戳、错误码、异常堆栈、请求路径这些定位问题所需的内容应原样保留。
第一步：准备输入。收集原始截图、日志文件和复现步骤说明，确认三者对应同一次问题现象。先复制一份工作副本，原始文件留在受控位置，避免处理过程中误改原件。
第二步：处理截图。先裁剪与问题无关的区域，例如整块侧边栏、无关的列表行，减少暴露面；再对剩余敏感字段打码或用不透明色块覆盖。覆盖完成后放大检查边缘，确认底层文字没有从色块边缘或半透明区域透出。完成标志是：截图中只剩复现所需的界面状态和报错信息。
第三步：处理日志。按字段逐条替换或删除敏感值，例如把令牌替换为 token=***、把手机号替换为 138****0000 这类不可还原的占位形式。保留时间戳、日志级别、错误码、堆栈和请求路径。完成标志是：用关键词再扫一遍处理后的文件，无命中，且日志仍能支撑开发定位问题。
第四步：产出交付物。输出脱敏后的附件和填写完整的脱敏记录，两者一并挂到缺陷记录上。完成标志是：附件能正常打开、内容清晰可读、复现信息完整、敏感字段全部处理并有记录可查。
角色与交付物：谁识别、谁遮蔽、谁复核
脱敏要形成提交人与复核人分离的机制，避免同一个人既处理又验收。角色不必对应专职岗位，但职责必须明确到人。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 提交人 | 按清单识别截图与日志中的敏感信息，完成裁剪、打码、字段替换，填写脱敏记录 | 脱敏后的附件、脱敏记录 |
| 复核人 | 对照清单二次检查附件与记录，确认遮蔽不可还原、复现信息完整 | 复核结论（通过或退回及原因） |
| 缺陷记录管理者 | 约定附件规范、留存要求与复核节奏，处理遗漏后的返工 | 附件规范说明、复核记录留存 |
复核人应由非提交人担任，可以是同组测试同事或缺陷记录管理者指定的人员。复核不通过时，缺陷退回提交人返工，返工后重新走一遍复核，不跳步提交。
在缺陷记录系统中，这套分工可以借助工作项状态和附件管理落地。例如在 ONES Project 中提交缺陷时，附件与描述一并记录在缺陷工作项上，支持一键提交 Bug 至对应项目或迭代并跟踪修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。团队可以把“已脱敏待复核”“复核通过”设为缺陷流转中的检查节点，让脱敏记录随缺陷一起留存。附件是否支持自动脱敏或按角色限制查看，需按实际部署版本向厂商确认。
示例：一条含真实用户数据的缺陷附件如何脱敏
以下为演示情景，用于说明处理过程，不涉及真实用户数据。
情景：测试人员在预发布环境复现支付失败问题，截图中订单详情页显示了用户手机号 138****0000 和内网地址 10.20.30.40，日志中请求头带有 Authorization: Bearer eyJ... 令牌，同时包含错误码 PAY_5003 和一段异常堆栈。
逐步处理：
- 裁剪截图，去掉左侧导航和底部无关列表，只保留订单状态区与报错弹窗。
- 对手机号打码为
138****0000，对内网地址用不透明色块覆盖，放大确认无透出。 - 日志中将令牌整段替换为
Authorization: Bearer ***，保留请求时间、错误码PAY_5003、堆栈和请求路径。 - 用关键词对处理后的日志再扫一遍，确认无残留令牌或地址。
脱敏记录填写示例：附件“order-error.png”，命中位置为订单详情区，类型为手机号与内网地址，处理方式为打码与色块覆盖；附件“pay-service.log”，命中位置为第 12 行请求头，类型为访问令牌，处理方式为整段替换。处理人与复核人分别签字。
提交说明写法：“附件已脱敏，手机号与内网地址已遮蔽，令牌已替换；保留错误码 PAY_5003 与完整堆栈，复现步骤见描述。”这样开发拿到附件即可定位，无需再向提交人索要原始数据。
完成检查：提交前的核对项与阻断条件
提交前由复核人按清单逐项勾选，全部通过才允许提交。检查表建议包含以下条目：
| 检查项 | 通过标准 |
|---|---|
| 敏感字段处理 | 截图与日志中的账号、手机号、身份证号、令牌、密钥、内网地址均已处理 |
| 遮蔽不可还原 | 打码与色块覆盖无法通过调亮、去色或图层还原读回原文 |
| 复现信息保留 | 时间戳、错误码、堆栈、请求路径完整，可支撑定位 |
| 附件可用 | 脱敏后的图片和日志能正常打开、内容清晰 |
| 记录完整 | 脱敏记录已填写，复核结论已签字留存 |
出现以下情况必须阻断提交：附件中仍存在未处理的账号、手机号、身份证号、令牌、密钥或内部地址；遮蔽可被还原；脱敏记录缺失或与附件不符。阻断后由提交人返工，重新处理并更新记录，再交复核人复查，复查通过前缺陷不进入研发处理环节。
复核签字与脱敏记录应随缺陷记录一并留存，便于后续审计和同类问题复盘。团队可以把这份检查表固化为缺陷提交模板中的必填项，让脱敏从个人习惯变成流程中的固定关卡。
常见问题
日志里同一个数字串，怎么判断是订单号还是手机号？
关键词扫描只能圈出候选位置，最终判断要回到上下文。看字段名和相邻内容：出现在 phone、mobile、contact 等字段后的数字串按手机号处理；出现在订单号、流水号字段且与用户身份无关联的，可以保留。拿不准时按敏感处理，并在脱敏记录中注明判断依据，方便复核人复查。
遮蔽后开发说信息不够、无法定位问题，怎么办？
先确认保留项是否齐全：时间戳、日志级别、错误码、异常堆栈、请求路径这些定位要素应原样保留，遮蔽只针对身份与凭证类字段。如果开发仍需要具体值，可由提交人在受控环境下单独提供，或补充复现步骤说明，避免把原始敏感数据重新挂回缺陷记录。遮蔽范围与复现需求的平衡，应在复核环节由提交人和复核人共同确认。
团队人少，提交人和复核人可以是同一个人吗？
不建议。同一人既处理又验收，容易漏看自己已经看惯的内容。人少时可以请同组同事交叉复核，或由缺陷记录管理者定期抽查。关键是复核动作真实发生并留下结论，角色名称和专职岗位可以灵活安排。
脱敏记录需要保存多久，保存在哪里？
脱敏记录应随缺陷记录一并留存，保存期限按团队的数据管理要求和审计需要确定。放在缺陷工作项的附件或描述中，可以让复核结论和处理过程与缺陷同生命周期，后续复盘同类问题时也能直接查到当时的处理方式。
ONES 能否自动识别或遮蔽缺陷附件中的敏感信息？
现有官方资料说明了 ONES Project 的缺陷提交与跟踪能力，以及 ONES TestCase 中未通过用例快速创建缺陷任务的流程，未提及附件自动脱敏或敏感信息识别功能。团队可以把脱敏检查设为缺陷流转中的检查节点，让脱敏记录随缺陷留存；附件是否支持自动脱敏或按角色限制查看，需按实际部署版本向厂商确认。
