缺陷提交检查清单模板:敏感信息处理核对项设计
缺陷提交检查清单的价值在于把“该写什么”变成逐项可勾选的核对动作,其中敏感信息处理最容易遗漏。下面这份模板按缺陷描述、复现步骤、环境信息、日志与证据、敏感信息处理五组组织,敏感信息单独成组,并给出字段说明、必填选填规则和一条完整填写示例,可直接复制到缺陷表单或团队文档中使用。
Table of Contents
要点总览(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次”,并注明出现时的共同条件,如特定数据量、特定时段或特定账号。若暂时无法归纳条件,在影响范围中写“待评估”并说明原因,同时把日志和问题时间点升级为必填,便于后续与服务端日志比对。不建议因为无法稳定复现就跳过复现步骤。
脱敏后证据无法支撑定位,应该恢复原文还是调整脱敏粒度?
应调整脱敏粒度,不恢复原文。常见做法是保留字段长度、格式、首尾字符和错误码,只替换可识别部分;日志可只截取报错前后若干行,用占位符替代内网地址和客户名称。若调整后仍无法定位,可请处理人在受控范围内查看原始证据,并在缺陷记录中注明查看人和时间,而不是把原文直接写进缺陷描述或公开附件。
清单嵌入缺陷提交表单后,必填项缺失该如何处理?
按缺失类型区分处理。现象描述、复现步骤、环境版本缺失时,可由提交人补充或在记录中标注“待补充”并指定补充时限,避免缺陷长期停留在信息不全状态。敏感信息处理结论缺失时,应先暂停流转,确认无泄露风险后再继续处理。团队可在表单中把关键核对项设为提交前确认,减少事后退回。
清单多久复核一次,复核时重点看什么?
建议每季度复核一次,由测试负责人与安全或合规接口人共同进行。复核重点包括:敏感信息条目是否覆盖当前实际出现的数据类型,脱敏方式和访问范围规则是否仍适用,必填与选填的划分是否与近期缺陷退回原因一致。每次修改保留版本号、日期、修改人和变更说明,并通知提交人,避免新旧版本混用。



