目录
这四个值的设计，是为了覆盖发布前测试可能出现的四种完整状态：
测试完成且没有阻塞问题 → 已通过 测试完成但仍有可接受的问题 → 有条件通过 测试完成但存在阻塞问题 → 未通过 本次变更不需要功能测试 → 不涉及测试
它们不是简单表示“测了/没测”，而是用来判断：当前版本是否具备上线条件。
一、已通过
含义
测试已经完成，实际结果符合预期，没有发现影响上线的问题，可以正常进入发布流程。
通常满足：
- 核心功能测试正常；
- 相关功能没有明显异常；
- 原有功能没有受到影响；
- 没有未解决的严重缺陷；
- 测试负责人同意发布。
示例：保险清单报错修复
发布内容：
修复创建保险清单时，填写特殊字符会报错的问题。
测试人员完成以下验证：
1. 正常创建保险清单：成功； 2. 输入特殊字符后创建：成功； 3. 编辑保险清单：成功； 4. 删除保险清单：成功； 5. 查询历史保险清单：正常； 6. 原有清单数据：未受影响。
没有发现其他问题，因此填写：
测试结果：已通过 测试说明： 已完成保险清单创建、编辑、删除及查询测试， 特殊字符报错问题已修复，相关功能运行正常。
能否发布
可以按正常流程继续审批和发布。
二、有条件通过
含义
主要功能已经测试通过，不存在阻止上线的严重问题，但仍有一些已知的小问题、限制条件或待处理事项。
这些问题必须满足：
- 不影响核心业务；
- 不会造成数据错误或数据丢失；
- 不存在明显安全风险；
- 有临时规避方案；
- 业务方、产品经理或项目负责人接受；
- 后续有明确处理计划。
它表示：
可以发布，但不是完全没有问题，必须带着明确条件发布。
示例一：非核心页面显示问题
发布内容：
修复保险清单创建报错。
测试结果：
- 创建保险清单已经正常；
- 编辑、提交和查询均正常；
- 但列表页面中的一个提示文字显示不完整；
- 不影响用户实际操作；
- 计划下个版本再调整。
可以填写：
测试结果：有条件通过 测试说明： 保险清单创建、编辑和提交功能测试通过。 目前发现列表页提示文字显示不完整， 不影响业务操作，计划在V1.1.7版本中修复。
示例二：浏览器兼容性存在限制
测试发现：
- Chrome、Edge浏览器测试通过；
- 老版本浏览器存在页面错位；
- 公司目前统一使用新版Chrome和Edge；
- 老版本浏览器不在支持范围内。
可以填写：
测试结果：有条件通过 测试说明： Chrome和Edge浏览器测试通过。 旧版本浏览器存在部分页面显示异常， 本次上线条件为用户使用公司规定的浏览器版本。
示例三：有已知问题，但存在规避方法
测试发现：
- 一次导出5000条以内正常；
- 超过5000条数据时导出速度较慢；
- 用户可以按日期分批导出；
- 不影响日常使用。
可以填写：
测试结果：有条件通过 测试说明： 常规数据导出功能正常。 单次超过5000条数据时处理速度较慢， 上线后暂时要求用户分批导出， 性能问题将在后续版本优化。
能否发布
可以发布，但建议增加以下记录：
遗留问题： 影响范围： 临时规避方案： 后续负责人： 计划解决时间： 业务方是否接受：
“有条件通过”不能用于掩盖严重问题。
例如下面这些情况，不能选择有条件通过：
- 核心业务偶尔保存失败；
- 可能产生错误金额；
- 可能造成数据重复或丢失；
- 存在越权访问；
- 问题原因尚未查明；
- 没有可靠的临时解决办法。
这些通常应该选择“未通过”。
三、未通过
含义
测试已经执行，但结果不符合上线要求，存在阻塞性问题，当前版本不能发布。
常见情况包括：
- 原来的Bug没有修复；
- 核心功能仍然报错；
- 修复一个问题后又产生新问题；
- 存在数据错误或数据丢失风险；
- 关键业务流程无法完成；
- 存在严重性能问题；
- 存在高风险安全问题；
- 测试结果与需求不一致。
示例一：原Bug仍然存在
发布目标：
修复创建保险清单时报错的问题。
测试时发现：
- 普通清单可以创建；
- 选择某一种保险类型时仍然报错；
- 该保险类型是业务日常使用类型。
应填写：
测试结果：未通过 测试说明： 普通保险清单创建正常， 但选择“海运保险”类型时仍然报错， 原问题未完全修复，当前版本不具备上线条件。
示例二：修复引入新问题
修复保险清单创建错误后，测试发现：
- 创建功能正常；
- 但已创建的保险清单无法编辑；
- 这是新版本引入的回归问题。
应填写：
测试结果：未通过 测试说明： 创建报错问题已修复， 但新版本导致已创建保险清单无法编辑， 属于新增阻塞性问题，建议退回开发处理。
示例三：数据计算错误
发布内容涉及保费计算，测试发现：
- 页面可以正常提交；
- 但部分订单保费计算结果错误；
- 可能直接影响业务结算。
应填写：
测试结果：未通过 测试说明： 提交功能正常，但部分订单保费计算结果不正确， 可能影响业务数据和费用结算，不允许上线。
能否发布
原则上不能发布，应退回开发重新处理。
紧急情况下也不能因为“着急”就把未通过改成有条件通过。确实必须上线时，应由负责人明确批准并记录风险，但这种情况应作为例外管理。
四、不涉及测试
含义
本次操作本身不包含需要测试人员进行功能验证的内容，因此测试结论不适用。
它不是：
没有时间测试 来不及测试 测试人员不在 申请人觉得不用测试
这些情况不能选择“不涉及测试”。
“不涉及测试”只适合确实没有功能测试对象的场景。
示例一：只更新说明文档
变更内容：
更新系统帮助中心的操作手册PDF，程序和配置均未调整。
可以填写：
测试结果：不涉及测试 测试说明： 本次仅更新用户操作手册附件， 不涉及程序、数据库及系统配置变更。
不过发布人员仍然应检查：
- 文件是否上传成功；
- 文件是否可以打开；
- 用户是否可以正常下载。
这种属于简单检查，不一定需要正式测试人员验收。
示例二：仅修改工单通知人
变更内容：
将系统发布通知邮件的抄送人从离职员工改为新的项目负责人。
如果不涉及程序代码，可以填写：
测试结果：不涉及测试 测试说明： 本次仅调整发布通知接收人员， 不涉及系统功能和业务数据变更。
但配置完成后，仍应发送一次测试通知确认。
示例三：账号停用
变更内容：
停用某位离职员工的系统账号。
可以填写：
测试结果：不涉及测试 测试说明： 本次为账号停用操作，不涉及程序发布。 操作完成后由管理员确认账号状态。
这里更合适的验证是“执行结果确认”，而不是功能测试。
示例四：证书资料补录但没有实际变更
工单只是补录历史发布资料、上传审批附件，没有对生产环境执行任何操作，也可以选择“不涉及测试”。
五、“不涉及测试”和“未测试”不能混淆
这是实际使用中最容易出现的问题。
| 实际情况 | 应选择 |
|---|---|
| 已测试，所有项目正常 | 已通过 |
| 已测试，有轻微可接受问题 | 有条件通过 |
| 已测试，有阻止上线的问题 | 未通过 |
| 本次确实没有测试对象 | 不涉及测试 |
| 因时间紧张没有测试 | 不能选“不涉及测试” |
| 测试人员尚未开始测试 | 建议增加“待测试”状态 |
| 测试正在进行 | 建议增加“测试中”状态 |
如果这个字段既用于申请阶段，也用于测试完成后的审批阶段，建议增加两个状态：
待测试 测试中 已通过 有条件通过 未通过 不涉及测试
如果只有测试人员在测试完成后才填写，那么保留原来的四个值就足够。
六、为什么需要“有条件通过”
假如只有三个选项：
已通过 未通过 不涉及测试
测试人员遇到一个不影响上线的小问题时会很难选择。
例如：
- 核心功能全部正常；
- 只有提示文字不准确；
- 不影响业务使用；
- 业务方接受下个版本再修改。
选择“已通过”，会让人误以为没有遗留问题；选择“未通过”，又会不必要地阻止上线。
所以需要“有条件通过”记录真实情况：
可以上线，但存在已知问题和附加条件。
这个状态可以避免把问题藏在备注里，也方便以后统计遗留问题。
七、建议给每个值配置填写规则
已通过
测试已完成； 核心功能正常； 不存在阻塞性问题； 允许进入发布流程。
有条件通过
主要功能测试通过； 存在非阻塞性遗留问题； 必须填写问题、影响、规避方案和解决计划； 需要产品或业务负责人确认接受。
未通过
存在阻塞性问题； 当前版本禁止发布； 必须填写未通过原因。
不涉及测试
本次变更确实没有功能测试对象； 必须填写不涉及测试的原因； 不能用来代替“未测试”。
八、结合你们工单系统的最终建议
字段名称建议由“测试是否通过”改成：
测试结论
下拉值保留：
已通过 有条件通过 未通过 不涉及测试
再增加一个“测试说明”字段，并设置填写要求：
| 测试结论 | 测试说明要求 |
|---|---|
| 已通过 | 简要填写测试范围和结果 |
| 有条件通过 | 必须填写遗留问题、影响及后续计划 |
| 未通过 | 必须填写失败项和退回原因 |
| 不涉及测试 | 必须填写为什么不需要测试 |
这样每一个选项都能留下明确依据，不会只看到一个“已通过”却不知道实际测试了什么。