测试质量评估未通过时，先别急着追人。把“未通过”拆成可核查的事实：哪些指标或结论不达标、对应哪些缺陷与用例、发生在哪个版本和阶段；再沿证据链定位问题引入环节，区分需求遗漏、开发缺陷、测试漏测、环境或数据问题，据此确认责任归属；最后形成带责任人和截止时间的整改项，用同一口径的用例、数据和环境复验并判定是否关闭。本文按这条处置路径展开，适用于当前版本测试结论的处置，不涉及组织级质量趋势分析与发布门禁规则设计。
要点总览（TL;DR）
- 先把“未通过”拆成可核查的症状清单：不达标项、实际值与标准差距、受影响版本与模块、暴露阶段，作为本次处置的边界。
- 原因排查按“假设—证据—结论”推进，先核对评估口径，再查测试漏测，最后沿缺陷单与提交记录回溯引入环节，避免把猜测当结论。
- 责任确认落到环节与角色，依据各环节的可核查交付物逐项写明“现象—证据—归属环节—责任角色”，与个人绩效评价保持分离。
- 整改项需包含问题描述、责任角色、措施、截止时间和验证方式；复验按受影响优先、回归兜底执行，并设置环境与数据未就绪的停止点。
- 复验通过需每个不达标项都有达标证据且回归无新增高等级缺陷；未通过则回到定位环节补充整改，同时安排用例补充、评审检查项与口径固化等预防动作。
未通过的具体表现与影响范围
处置的第一步是把“质量评估未通过”这句结论还原成一张症状清单。评估报告通常给出的是汇总判断，而整改和复验需要的是可逐项核对的事实。建议由测试负责人牵头，在评估结论发出后的一个工作日内完成清单整理，作为本次处置的边界依据。
清单至少覆盖四类信息：
- 不达标项：逐条列出未通过的指标或结论项，例如缺陷密度超出阈值、遗留缺陷中存在高等级未关闭项、用例通过率低于约定值、回归覆盖未达到计划范围。每项写明实际值、约定标准和差距。
- 影响范围：标明受影响的版本号、模块、需求范围，以及这些模块是否属于本次发布的关键路径。
- 发生阶段与时间点：区分问题是在提测、回归还是验收阶段暴露的，记录首次发现时间和评估会议时间，便于后续回溯。
- 边界说明：本次处置只针对当前版本当前结论。如果评估同时触发了发布门禁拦截，门禁的放行规则由发布审批流程处理；如果指标反映出跨版本的持续下滑，则转入研发质量度量议题，不在本次整改中一并解决。
清单完成后应发给开发、测试、产品相关角色确认，各方对“哪里不达标、影响多大”先达成一致，后续的原因排查和责任确认才有共同的事实基础。
从证据链定位问题引入环节
原因排查要按“假设—证据—结论”的方式推进，避免把第一直觉当成定论。常见的原因假设可以归为五类，每类都有对应的验证证据：
| 原因假设 | 验证证据 | 排查要点 |
|---|---|---|
| 评估口径不一致 | 评估标准文档、统计脚本、指标计算说明 | 核对本次统计口径与历史是否一致，是否存在统计范围遗漏或重复计数 |
| 测试漏测 | 用例设计与评审记录、用例执行记录、需求到用例的覆盖对照 | 检查不达标模块是否有对应用例、用例是否执行、执行结果是否被正确记录 |
| 开发缺陷 | 代码提交记录、缺陷单、构建与部署日志 | 确认缺陷是否集中在某次提交或某个构建，是否存在修复引入的新问题 |
| 需求理解偏差 | 需求文档、评审纪要、变更记录 | 确认验收标准是否明确、是否存在中途变更未同步到测试 |
| 环境或测试数据问题 | 环境配置记录、数据准备脚本、运行日志 | 确认失败用例是否集中在特定环境，数据是否满足用例前提 |
排查顺序建议先核对口径，再查漏测，最后回溯引入环节。先核对口径是因为统计错误会污染后续所有判断，成本最低；口径确认无误后，检查不达标项对应的用例覆盖与执行情况，判断问题是否在测试环节被放过；最后沿缺陷单和提交记录回溯问题最早出现在哪个环节。
每一步都要在记录中区分“假设”和“已证实结论”。例如“疑似某次重构引入回归缺陷”是假设，只有对照提交记录、复现步骤和缺陷单确认后，才能写成结论。排查结束后形成原因假设与验证证据对照表，作为责任确认的输入。
责任确认的口径与沟通方式
责任确认的对象是环节和角色，依据是各环节应交付的可核查产物。按环节定责的基本口径如下：
| 环节 | 可核查交付物 | 定责关注点 |
|---|---|---|
| 需求 | 需求文档、验收标准、评审纪要 | 验收标准是否明确、变更是否同步 |
| 设计 | 设计文档、技术评审记录 | 方案是否覆盖异常场景、评审意见是否闭环 |
| 开发 | 代码提交记录、自测记录、缺陷修复单 | 缺陷是否可归因到具体提交、修复是否验证 |
| 测试 | 用例设计、执行记录、缺陷单 | 覆盖是否充分、执行是否如实、缺陷是否跟踪到关闭 |
| 环境 | 环境配置记录、数据准备记录、运行日志 | 环境是否与约定一致、数据是否满足前提 |
定责时以S2形成的证据对照表为依据，逐项写明“问题现象—证据—归属环节—责任角色”，避免用“大家都有责任”这类模糊表述收场。责任确认的记录形式建议采用书面结论，附证据引用，由相关角色确认签字或在协作工具中留痕。
跨角色沟通时，主持人应先陈述事实清单和证据，再讨论归属，把讨论焦点保持在“哪个环节的哪个交付物缺失或失效”。出现争议时，回到证据本身核对，证据不足的项标记为待补充，不强行下结论。需要明确的是，责任确认用于改进流程和分配整改任务，与个人绩效评价是两件事；绩效评价有其独立的标准和流程，不应在质量处置会议中直接挂钩，否则容易让沟通滑向互相推诿。
整改项拆解与复验执行步骤
责任确认后，把每个已证实的问题转化为可跟踪的整改工作项。每个整改项至少包含以下字段：
- 问题描述：引用症状清单中的具体不达标项；
- 责任角色：对应S3确认的环节责任人；
- 整改措施：具体动作，例如补充用例、修复缺陷、修正统计脚本、补齐环境配置；
- 截止时间：与复验计划对齐；
- 验证方式：说明用什么用例、数据、环境来验证整改到位。
整改项进入缺陷管理或测试管理工作项中跟踪，状态从“待整改”流转到“待复验”，再由复验人确认关闭或打回。ONES 的测试管理与缺陷管理工作项可以承载这一流转：整改项作为工作项关联到对应的缺陷单和用例，复验记录与结论附在工作项中，评估会议确认的范围和标准也可以沉淀为文档，便于复验时按同一口径核对。
复验范围的确定遵循“受影响优先、回归兜底”的原则：先覆盖与不达标项直接相关的用例和缺陷修复点，再按影响范围扩展到相关模块的回归用例；涉及数据修复的，需准备与首次评估一致的数据集；环境应与评估时约定的环境一致，环境有变更的需在复验记录中说明。
复验执行按以下顺序推进，并设置停止点：
- 确认整改项全部达到“待复验”状态，环境与数据就绪，否则暂停复验，先补齐前置条件；
- 执行受影响用例和缺陷验证用例，记录实际结果；
- 执行回归范围用例，确认整改未引入新问题；
- 汇总复验数据，与评估标准逐项比对。
复验中如涉及数据清理、环境重置等破坏性操作，操作前先备份相关数据和配置，明确回退方式；操作影响共享环境时，提前通知相关方并约定时间窗口。
复验结果判定与复发预防
复验通过的判定标准应在整改开始前就与评估标准对齐：症状清单中的每个不达标项都有对应的复验证据，且证据显示已达到约定标准；受影响用例全部通过，回归范围内无新增高等级缺陷；复验使用的用例、数据、环境与首次评估口径一致，差异项有书面说明。判定结论连同证据记录一并留存，作为关闭本次处置的依据。
复验未通过时，不直接关闭整改项，而是回到S2的定位环节：先判断是整改措施未落实、复验范围不足，还是存在此前未识别的原因。根据判断结果补充整改项或扩大复验范围，重新进入复验流程。回退路径要写清楚，避免整改项在“待复验”和“待整改”之间反复流转却无人推进。
复发预防动作在复验结论确认后同步安排：
- 用例补充：针对漏测暴露的场景补充用例，并纳入回归集；
- 评审检查项：把本次暴露的需求或设计缺失转化为评审检查清单条目；
- 口径固化：将评估指标的计算口径、数据来源写入评估规范，减少下次统计分歧；
- 流程改进项：对反复出现的同类问题，形成流程改进工作项并指定跟进人。
复验结论的记录应包含判定结果、证据引用、遗留事项和预防措施清单。关闭条件为：所有整改项关闭、复验判定通过、预防措施已分配责任人。满足条件后由测试负责人确认关闭，并将结论同步给评估相关方。
常见问题
评估口径本身有争议时，责任确认应该怎么推进？
先把口径问题单独拿出来核对，而不是在定责会议上争论。核对内容包括评估标准文档、统计脚本和指标计算说明，确认统计范围是否存在遗漏或重复计数。口径确认后再进入原因排查和定责；如果口径确实需要调整，应在书面记录中说明调整依据和影响范围，并对已得出的结论做相应修正，避免用新口径追溯此前已关闭的问题。
问题跨多个环节时，责任怎么划分才不至于变成互相推诿？
按环节拆分，而不是给一个笼统的整体结论。对同一个问题，分别写明需求、设计、开发、测试、环境各环节的交付物是否缺失或失效，证据不足的项标记为待补充。沟通时主持人先陈述事实清单和证据，再讨论归属，把焦点保持在“哪个环节的哪个交付物出了问题”。责任确认用于分配整改任务和改进流程，与个人绩效评价分开处理。
复验时环境和首次评估不一致，结论还能用吗？
可以用，但需要在复验记录中说明差异及其影响。原则上复验应使用与评估时约定的环境一致；环境确有变更的，要记录变更内容、变更原因，并评估该变更是否影响不达标项的验证结论。涉及数据修复的，准备与首次评估一致的数据集；差异较大时，可对关键项在一致环境下补做验证，再给出判定。
复验未通过，整改项应该退回还是新开？
建议在原整改项上退回并补充说明，保持问题从发现到关闭的完整记录。退回时写清未通过的具体原因：是整改措施未落实、复验范围不足，还是存在此前未识别的原因。根据原因补充整改措施或扩大复验范围，再重新进入复验。若暴露出新的独立问题，则新开整改项并关联原问题，避免把不同问题混在一条记录里。
整改和复验的记录放在哪里，后续怎么查？
整改项进入缺陷管理或测试管理工作项中跟踪，状态从“待整改”流转到“待复验”，复验结论与证据附在同一工作项下，并关联对应的缺陷单和用例。评估会议确认的范围与标准可沉淀为文档，复验时按同一口径核对。ONES 的测试管理与缺陷管理工作项可以承载这类流转和记录，便于后续按版本或模块回溯处置过程。
