缺陷提交检查清单模板:敏感信息处理核对项设计

缺陷提交检查清单的价值在于把“该写什么”变成逐项可勾选的核对动作,其中敏感信息处理最容易遗漏。下面这份模板按缺陷描述、复现步骤、环境信息、日志与证据、敏感信息处理五组组织,敏感信息单独成组,并给出字段说明、必填选填规则和一条完整填写示例,可直接复制到缺陷表单或团队文档中使用。




要点总览(TL;DR)


  • 清单按缺陷描述、复现步骤、环境信息、日志与证据、敏感信息处理五组组织,敏感信息单独成组,空白表格可直接复制到缺陷表单或团队文档。
  • 必填最小集合为现象描述、期望结果、复现步骤、环境版本和敏感信息处理三项结论;日志、录屏、影响范围量化按缺陷类型升级为必填。
  • 敏感信息核对项设计为提交前扫描、脱敏替换、脱敏后可用性回看、访问范围确认四步,并附手机号、证件号、令牌、客户名称、内网地址的脱敏前后对照。
  • 清单需嵌入缺陷提交表单的必填提示或提交前确认页,并保留版本记录与季度复核,避免只在文档库单独存放而流于形式。


可复制空白检查清单模板


下表为空白模板,按五组核对项排列,敏感信息处理作为独立专项组放在最后,提交前必须逐项确认。复制到缺陷表单时,可将“核对项”作为字段标签,“通过标准”作为填写提示;复制到文档时,保留整表并在“核对结果”列打勾或填写说明。


组别 核对项 必填/选填 核对方式 通过标准 填写人 核对结果
缺陷描述 现象描述 必填 阅读描述并与实际表现对照 一句话说清发生了什么,不含推测性结论 提交人
期望结果 必填 对照需求文档或业务规则 写明正确表现,可被他人理解 提交人
影响范围 选填 评估受影响用户、模块或数据 能说明影响对象与程度,无法判断时注明 提交人
复现步骤 前置条件 必填 按步骤从零走一遍 账号、数据、配置等前提写全,他人可照做 提交人
操作序列 必填 逐步编号并实际复走 每步一个动作,顺序可还原 提交人
复现频率 必填 重复操作若干次记录结果 写明如“5次中3次”,并注明尝试次数 提交人
环境信息 版本信息 必填 查看关于页或构建信息 写明产品版本号与构建号 提交人
部署方式 必填 确认环境类型 注明测试/预发/生产及部署形态 提交人
浏览器或设备 必填 记录实际使用终端 写明浏览器及版本,或设备型号与系统版本 提交人
数据条件 选填 说明触发所需数据特征 数据量、类型或特殊配置可被复现 提交人
日志与证据 日志片段 选填 截取报错前后关键行 含时间戳与错误码,已去除无关内容 提交人
截图 选填 截取问题现场 能看清报错信息与操作位置 提交人
录屏 选填 录制完整操作过程 覆盖从进入页面到问题出现 提交人
问题时间点 选填 记录发生时间 精确到分钟,便于比对服务端日志 提交人
敏感信息处理 提交前脱敏 必填 逐项扫描描述、附件与日志 口令、令牌、密钥、证件号、手机号、客户数据均已处理 提交人
脱敏后可用性 必填 用脱敏后的证据重新阅读 证据仍能支撑定位问题,关键字段保留结构特征 提交人
访问范围 必填 检查附件与日志的可见范围 仅对处理该缺陷所需人员可见,无公开链接 提交人/复核人

使用时建议保留“组别”列作为分区标识,若缺陷系统字段有限,可将“核对方式”和“通过标准”合并为填写提示,但敏感信息处理组的三项核对不建议删减。



各组核对项字段说明


模板中的每一项都对应一个可判断的填写口径,下面按组说明其含义与判断依据,保证空白表、说明和示例三处一致。


组别 核对项 含义 判断依据
缺陷描述 现象描述 实际观察到的异常表现 描述与截图、日志一致,不含“可能是缓存问题”等未验证结论
期望结果 按需求应出现的正确表现 能对应到需求条目、设计稿或业务规则
影响范围 受影响的用户、模块或数据 有明确对象;暂时无法评估时写“待评估”并说明原因
复现步骤 前置条件 复现前需具备的账号、数据与配置 他人按此准备后能进入相同起点
操作序列 从起点到问题出现的动作顺序 每步单一动作,编号连续,无跳步
复现频率 问题出现的稳定程度 记录尝试次数与出现次数,如“10次中7次”
环境信息 版本信息 出现问题的产品版本 来自关于页、构建记录或发布说明
部署方式 问题所在环境的类型 测试、预发、生产或私有化部署等,按实际填写
浏览器或设备 实际使用的客户端 浏览器名称与版本,或设备型号与系统版本
数据条件 触发问题所需的数据特征 数据量、字段类型、特殊配置等可被复现的条件
日志与证据 日志片段 与问题相关的日志行 含时间戳、错误码,已删除无关行
截图 问题现场的画面 能看清报错文案与所在页面
录屏 完整操作过程的录像 覆盖从进入页面到问题出现,无剪辑跳段
问题时间点 问题发生的具体时间 精确到分钟,便于与服务端日志对齐
敏感信息处理 提交前脱敏 对描述、附件、日志中的敏感内容做处理 账号口令、密钥令牌、个人信息、内部地址、客户数据均已掩码或替换
脱敏后可用性 脱敏后证据是否仍能支撑定位 关键字段保留长度、格式或首尾字符等结构特征
访问范围 附件与日志的可见人群 仅限处理该缺陷所需角色,无公开分享链接


必填与选填的划分


必填项的最小集合是:现象描述、复现步骤(前置条件、操作序列、复现频率)、环境版本,以及敏感信息处理三项结论。这组信息决定缺陷能否被接手处理;日志、录屏、影响范围量化属于增强项,按缺陷类型和排查需要补充。


核对项 默认属性 调整条件
现象描述、期望结果 必填 无例外
前置条件、操作序列、复现频率 必填 偶发问题无法稳定复现时,复现频率改为必填并记录尝试次数
版本信息、部署方式、浏览器或设备 必填 纯服务端问题可省略浏览器项,但需注明调用方式
影响范围 选填 涉及资金、权限或客户数据时升为必填
日志片段 选填 接口报错、页面白屏等无明确提示的问题升为必填
截图、录屏 选填 界面错位、交互异常类问题至少提供截图
敏感信息处理三项 必填 无例外;缺陷不含敏感内容时在核对结果中注明“已确认无敏感信息”

按缺陷类型调整时,可遵循一条简单规则:问题越难从文字还原现场,证据类必填项越多。必填项缺失时,不建议直接退回,可由提交人补充或在缺陷记录中标注“待补充”并指定补充时限,敏感信息处理结论缺失的缺陷应先暂停流转,确认无泄露风险后再继续处理。



敏感信息处理核对项的设计方法


敏感信息核对项要设计成能判断、能留痕的条目,关键是让提交人做一次扫描、一次替换、一次可用性回看和一次范围确认,而不是笼统写“注意脱敏”。


提交前扫描。逐项检查缺陷描述、复现步骤、附件和日志中是否出现:账号口令、访问令牌与密钥、身份证号、手机号、客户名称与业务数据、内部服务地址。扫描时按“文本—截图—日志文件”三类载体分别过一遍,截图和日志最容易被忽略。


脱敏方式。掩码适合证件号、手机号,保留首尾字符;替换适合客户名称、内部地址,用占位符如“客户A”“内网地址X”代替;截取适合日志,只保留报错前后若干行。三种方式的目标一致:去掉可识别信息,保留复现所需的结构特征。


脱敏后可用性核对。替换完成后重新阅读证据,确认还能看出字段长度、格式、错误码和调用顺序。若脱敏导致无法定位,应调整掩码粒度,而不是恢复原文。


访问范围核对。确认附件和日志仅对处理该缺陷的角色可见,检查是否存在公开分享链接、是否被转发到群聊或外部工单。


敏感内容 脱敏前示例 脱敏后示例 保留的可复现信息
手机号 13812345678 138****5678 位数与号段格式
身份证号 110101199001011234 110101********1234 长度与校验位位置
访问令牌 Bearer eyJhbGciOiJIUzI1NiJ9… Bearer eyJhbGci***(已截断) 令牌前缀与认证方式
客户名称 某某科技有限公司 客户A 客户类型与数据归属关系
内部地址 http://10.20.30.40:8080/api http://内网地址X/api 接口路径与端口结构


完整填写示例


以下是一条包含敏感信息的缺陷记录按模板逐项填写的结果,字段与空白模板一一对应,可作为团队填写参照。


组别 核对项 填写内容 核对结果
缺陷描述 现象描述 客户列表页导出按钮点击后无响应,页面无报错提示 通过
期望结果 点击导出后生成Excel文件并开始下载 通过
影响范围 客户管理模块导出功能,影响使用该功能的运营人员 通过
复现步骤 前置条件 使用运营账号登录测试环境,客户列表中存在超过500条记录 通过
操作序列 1. 进入客户管理页;2. 不筛选直接点击“导出”;3. 观察页面反应 通过
复现频率 尝试5次,5次均无响应 通过
环境信息 版本信息 产品版本 3.8.2,构建号 20240612 通过
部署方式 测试环境,私有化部署 通过
浏览器或设备 Chrome 125,Windows 11 通过
数据条件 客户记录约800条,含手机号与证件号字段 通过
日志与证据 日志片段 14:32:07 ERROR export-service timeout after 30000ms,已截取前后5行 通过
截图 导出按钮点击后页面截图,已对客户信息列打码 通过
录屏 未提供,文字与日志已可定位 不适用
问题时间点 2024-06-18 14:32 通过
敏感信息处理 提交前脱敏 截图中的手机号掩码为138****5678,证件号掩码为110101********1234,客户名称替换为“客户A”,日志中的内网地址替换为“内网地址X” 通过
脱敏后可用性 日志保留错误码与超时时间,截图保留字段格式,仍可判断为导出服务超时 通过
访问范围 附件仅缺陷处理人与测试负责人可见,未生成公开链接 通过

这条示例说明:敏感信息处理组不是附加说明,而是与复现步骤同等重要的核对环节;脱敏记录写清“改了什么、保留了什么”,后续处理人才能既放心查看证据,又不丢失定位线索。



清单的调整与维护方法


清单需要随项目阶段、合规要求和缺陷类型变化而调整,维护动作集中在新增触发、定期复核、版本记录和落地位置四个方面。


  • 新增核对项的触发条件:出现新的敏感数据类型(如新增生物识别信息采集)、发生一次信息泄露事件、缺陷反复因同一字段缺失被退回,或接入新的外部系统时,评估是否新增核对项。
  • 定期复核:建议每季度复核一次敏感信息条目,对照当前适用的个人信息保护与数据安全要求,确认脱敏方式和访问范围规则仍然适用;复核人由测试负责人与安全或合规接口人共同担任。
  • 版本记录与通知:每次修改保留版本号、修改日期、修改人和变更说明,通过团队公告或缺陷模板更新说明通知提交人,避免新旧版本混用。
  • 落地位置:清单应嵌入缺陷提交表单的必填提示或提交前确认页,使提交人在填写时即完成核对;仅在文档库单独存放容易流于形式。

版本 日期 修改人 变更说明
V1.0 2024-06-01 测试组 初版,五组核对项与敏感信息专项组
V1.1 2024-09-15 测试组、安全接口人 敏感信息组新增访问范围核对,补充脱敏对照示例
V1.2 待定 — 按季度复核结果更新

当团队在缺陷管理工具中记录缺陷时,可将清单中的核对项映射为缺陷工作项的字段或提交前检查项,把脱敏后的附件直接挂在缺陷记录下,并按角色控制可见范围。例如在ONES中,缺陷可作为工作项类型配置描述、复现步骤、环境等字段,附件与日志随记录保存,配合成员权限控制访问范围,使清单核对结果和证据留在同一条记录中,便于后续处理与回溯。



常见问题


缺陷不含任何敏感信息时,敏感信息处理组还需要填写吗?


需要填写,但内容可以简化。三项核对仍保留,在核对结果中注明“已确认无敏感信息”,并简要说明扫描范围,例如已检查描述、截图和日志。这样做的目的是留下核对痕迹:后续若发现附件中实际含有客户数据,可以回溯当时是否漏检。若缺陷涉及客户数据、账号或内部地址,则必须逐项写明脱敏方式和保留的可复现信息。


偶发问题无法稳定复现,复现步骤和复现频率怎么填?


偶发问题仍要写清前置条件和操作序列,复现频率改为必填,记录尝试次数与出现次数,例如“10次中2次”,并注明出现时的共同条件,如特定数据量、特定时段或特定账号。若暂时无法归纳条件,在影响范围中写“待评估”并说明原因,同时把日志和问题时间点升级为必填,便于后续与服务端日志比对。不建议因为无法稳定复现就跳过复现步骤。


脱敏后证据无法支撑定位,应该恢复原文还是调整脱敏粒度?


应调整脱敏粒度,不恢复原文。常见做法是保留字段长度、格式、首尾字符和错误码,只替换可识别部分;日志可只截取报错前后若干行,用占位符替代内网地址和客户名称。若调整后仍无法定位,可请处理人在受控范围内查看原始证据,并在缺陷记录中注明查看人和时间,而不是把原文直接写进缺陷描述或公开附件。


清单嵌入缺陷提交表单后,必填项缺失该如何处理?


按缺失类型区分处理。现象描述、复现步骤、环境版本缺失时,可由提交人补充或在记录中标注“待补充”并指定补充时限,避免缺陷长期停留在信息不全状态。敏感信息处理结论缺失时,应先暂停流转,确认无泄露风险后再继续处理。团队可在表单中把关键核对项设为提交前确认,减少事后退回。


清单多久复核一次,复核时重点看什么?


建议每季度复核一次,由测试负责人与安全或合规接口人共同进行。复核重点包括:敏感信息条目是否覆盖当前实际出现的数据类型,脱敏方式和访问范围规则是否仍适用,必填与选填的划分是否与近期缺陷退回原因一致。每次修改保留版本号、日期、修改人和变更说明,并通知提交人,避免新旧版本混用。

animation hi
animation dot left
animation dot right
animation dot right bottom
avatar circle
WeChat QR Code
长按将二维码保存为图片

售前电话

400-188-1518

文章配图预览