测试准入准则是一组在测试开始前逐项判定“能否进入测试”的条件集合，通常按单元、集成、系统、验收等测试级别分别设定。每条准则要写明检查项、判定标准、证据形式、责任人和不通过时的处置方式，才能从一句原则变成可执行的评审依据。本文按字段结构、分级条件、评审步骤、角色分工、完整示例和维护机制依次展开，帮助团队制定或修订一套能落地的准入准则。
要点总览（TL;DR）
- 一条准入准则要写到换人也能独立判定通过与否，通常包含准则编号与适用级别、检查项与判定标准、证据形式、提交方与确认方、不通过处置五个字段。
- 按单元、集成、系统、验收分层设定准入条件，每个级别只核验进入该级测试所必需的前置条件，上一级结论作为下一级输入，每级保留五到八条核心准则。
- 准入评审分提报、核验、判定、跟踪四步，结论分为通过、有条件通过、退回；有条件通过的遗留项必须登记责任人与关闭时间并跟踪至关闭。
- 开发负责提交可追溯构建与自测记录，测试负责核验并维护准则版本，产品对齐需求与验收标准，项目或质量负责人审批例外与准则变更。
- 准则有效性用准入被跳过次数、退回后一次通过率、缺陷逃逸对应关系检验，按版本或季度复盘，变更留痕并通知提测方。
测试准入准则由哪些字段构成
一条准入准则写到什么颗粒度才算可执行，判断标准很简单：换一个没有参与制定的人拿着它去核验，能独立得出“通过”或“不通过”的结论。达到这个程度，一条准则通常需要五个字段：准则编号与适用测试级别、检查项与判定标准、证据形式、责任人、不通过时的处置与复检方式。缺少任何一个字段，准则都会在执行时退化成口头确认。
判定标准要尽量可量化或可核验。“代码质量良好”无法判定，“单元测试覆盖核心业务路径，覆盖率报告显示行覆盖率不低于约定阈值”可以判定。阈值由团队根据模块风险和历史数据确定，不同级别、不同模块可以取不同值，关键是写进准则并保持稳定。证据形式决定核验时看什么：构建产物、自测报告、评审记录、环境说明、缺陷清单，都要指明具体载体和存放位置，避免评审时临时找材料。
责任人字段要区分提交方与确认方。提交方负责准备证据并对内容真实性负责，确认方负责逐项核验并给出结论，两者不能是同一人。不通过处置要写明退回后需要补充什么、由谁复检、复检时限，否则退回容易变成反复拉扯。
| 字段名 | 填写要求 | 示例值 |
|---|---|---|
| 准则编号 | 按测试级别加序号，便于引用和统计 | ST-03（系统测试第3条） |
| 适用测试级别 | 单元、集成、系统、验收之一，或注明通用 | 系统测试 |
| 检查项 | 一句话描述要核验的对象 | 本轮提测范围内的需求变更已完成评审 |
| 判定标准 | 可量化或可核验的通过条件 | 变更需求均有评审记录，且结论为通过 |
| 证据形式 | 指明材料载体与存放位置 | 需求评审记录，链接附在提测单中 |
| 提交方 | 准备证据的角色 | 需求负责人 |
| 确认方 | 核验并签署结论的角色 | 测试负责人 |
| 不通过处置 | 退回补充内容、复检人、复检时限 | 补齐评审记录后由测试负责人在1个工作日内复检 |
按测试级别分层设定准入条件
不同测试级别的准入关注点差异明显，用一套条件套所有级别，要么对单元测试过重，要么对系统测试过松。分层的思路是：每个级别只核验“进入这一级测试所必需的前置条件”，上一级的通过结论和产物作为下一级的输入，而不是在每一级重复核验全部内容。
单元测试的准入重点在代码与自测：代码已完成合入、静态检查通过、开发自测用例执行完毕。集成测试关注模块之间的接口与联调准备：接口文档已确认、依赖服务可用、联调环境就绪。系统测试关注整体可测性：构建产物版本明确、部署环境符合要求、主要功能自测通过、已知缺陷有清单说明。验收测试关注需求闭环：需求与验收标准已对齐、系统测试遗留问题达到约定状态、验收环境与数据准备完成。
| 测试级别 | 核心准入关注点 | 典型证据 | 与上一级的关系 |
|---|---|---|---|
| 单元测试 | 代码合入、静态检查、开发自测完成 | 构建记录、静态检查报告、自测记录 | 无前置测试级别 |
| 集成测试 | 接口确认、依赖可用、联调环境就绪 | 接口文档、环境说明、联调计划 | 以单元测试通过为输入 |
| 系统测试 | 版本明确、环境合规、主流程自测通过、已知缺陷清单 | 构建产物、环境说明、自测报告、缺陷清单 | 以集成测试结论为输入 |
| 验收测试 | 需求与验收标准对齐、遗留问题达约定状态、验收环境就绪 | 需求确认记录、遗留问题清单、验收环境说明 | 以系统测试报告为输入 |
通用底线条件可以跨级别复用，例如“提测版本可追溯”“已知问题已登记”“提测材料齐全”。按级别增减的条件则围绕该级别的测试目标设定。控制条目数量的做法是：每个级别保留五到八条核心准则，把可以通过自动化检查的项目（如构建是否成功、静态检查是否通过）交给流水线判定，人工评审只聚焦需要判断力的条目。准则过多时，优先合并证据形式相同的条目，而不是简单删减。
从准则到执行：准入评审的操作步骤
准入评审的执行可以拆成提报、核验、判定、跟踪四个动作，每个动作都有明确的输入、输出和完成标志。流程本身不复杂，难点在于结论判定的一致性和遗留项的闭环。
- 提测方提交准入材料。输入是本轮提测范围与各级准则清单；动作是按准则逐条准备证据并提交提测申请；输出是一份材料齐全的提测单；完成标志是提测单中每条准则都附有对应证据或注明不适用理由。提交时机应在计划测试开始前留出核验时间，具体提前量按团队节奏确定。
- 测试方逐项核验。输入是提测单与证据材料；动作是按准则编号顺序逐条核对，记录每条结论与核验人；输出是核验记录；完成标志是所有条目均有“符合”“不符合”“不适用”之一的结论，没有空白项。
- 给出评审结论。全部条目符合为通过；存在不影响本轮测试启动的轻微缺项，且已登记整改责任人与期限，为有条件通过；存在影响测试开展的关键缺项，为退回。判定标准要事先写进准则，避免临场争论。
- 跟踪遗留项至关闭。有条件通过的遗留项要登记为独立事项，明确责任人与关闭时间，在测试执行过程中定期检查状态，关闭后更新评审记录。
- 关联测试执行记录。准入结论要与本轮测试计划、用例执行记录建立引用关系，使后续回溯时能从测试结果追溯到当时的准入状态。
这套流程中的提测单、核验记录和遗留项，本质上是需要状态流转和权限控制的工作项与文档。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；测试计划可分配用例执行人并多维度查看进度；未通过的用例可快速创建缺陷任务，在测试与研发团队间流转；同时支持为不同用户组、用例库和测试计划单独配置权限。团队可以把提测单作为工作项管理，把准入结论和遗留项记录在关联文档中，让评审状态与测试执行处于同一条流程上。是否设置独立的提测单类型或审批流，需要结合团队现有工作项设计确认。
角色分工与交付物
准入环节的推诿大多来自职责边界不清：开发认为材料已交，测试认为证据不足，产品认为需求早已确认。把每个角色的动作和交付物写清楚，评审时按清单对号入座，争议会明显减少。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 开发 | 提交可追溯的构建版本，完成自测，说明已知缺陷 | 构建产物与版本号、自测记录、已知缺陷清单及影响说明 |
| 测试 | 逐项核验准入材料，出具结论，维护准则版本 | 核验记录、准入结论、准则版本变更记录 |
| 产品/需求 | 确认需求范围与验收标准，配合澄清变更 | 需求确认记录、验收标准、变更评审结论 |
| 项目或质量负责人 | 审批例外放行，决定准则变更 | 例外审批记录、准则修订决定 |
开发角色的关键是“提交即可核验”：构建版本要能对应到具体代码状态，自测记录要覆盖主流程，已知缺陷要说明是否影响本轮测试。测试角色既要核验也要维护准则本身，发现某条准则长期无法判定或频繁误判时，应发起修订而不是每次临场放宽。产品角色的交付物集中在需求侧，验收标准要在提测前而非验收前才对齐。项目或质量负责人掌握两类特殊决定：例外放行和准则变更，两者都应留痕，便于后续复盘。
示例：一次系统测试准入评审
以下为演示情景，用于说明准则如何被逐项核验，不代表真实项目数据。某团队准备对订单模块的一轮迭代开展系统测试，提测方为开发负责人，确认方为测试负责人，适用系统测试级别的六条准则。
| 准则编号 | 检查项 | 证据 | 核验结论 |
|---|---|---|---|
| ST-01 | 提测版本可追溯 | 构建记录与版本号 | 符合 |
| ST-02 | 部署环境符合测试要求 | 环境说明 | 符合 |
| ST-03 | 本轮变更需求已完成评审 | 需求评审记录 | 符合 |
| ST-04 | 主流程自测通过 | 自测记录 | 符合 |
| ST-05 | 已知缺陷已登记并说明影响 | 缺陷清单 | 不符合：两条缺陷未注明是否影响主流程 |
| ST-06 | 测试数据准备完成 | 数据准备说明 | 符合 |
核验过程中，ST-05 未通过。开发负责人在当天补充了两条缺陷的影响说明，确认均只影响报表导出、不阻塞主流程测试。测试负责人复检后判定为有条件通过，遗留项登记为“补充缺陷影响说明”，责任人为开发负责人，关闭时间为次日。其余条目全部符合，评审记录中附上提测单链接与本轮测试计划编号。最终结论为有条件通过，测试按计划启动，遗留项在关闭后更新了评审记录状态。
这个示例可迁移的规律有三点：未通过项要具体到缺什么，而不是笼统退回；有条件通过的判定依据是缺项是否阻塞测试启动；遗留项必须有责任人和关闭时间，否则“有条件”会变成“无条件”。
准则落地后的检查与维护
准则写完只是开始，是否有效要靠数据检验。建议按季度或按版本节奏定期检查以下几项，形成固定的有效性检查清单：
- 准入被跳过的次数与原因：统计未经评审直接进入测试的情况，按原因归类，判断是流程约束不足还是准则过重。
- 退回后一次通过率：退回的提测单在补充材料后一次复检通过的比例，偏低说明提测方对准则理解不足，需要加强宣导或简化条目。
- 准则条目与缺陷逃逸的对应关系：分析测试后流入生产的缺陷，看是否与某条准入准则的缺失或放宽有关，据此调整条目。
- 准则版本变更记录：每次修订记录变更原因、影响范围和审批人，保证历史评审可回溯。
准则变更的触发条件通常包括：测试级别调整、流程工具变化、连续多个版本出现同类准入问题、缺陷逃逸分析指向某条准则失效。变更由测试负责人发起，项目或质量负责人审批，修订后通知所有提测方。定期复盘的时点可安排在版本回顾或季度质量会议上，参与角色包括开发、测试、产品和项目负责人，复盘输出应落到具体的准则修订或执行改进，而不是停留在讨论层面。
常见问题
团队第一次制定测试准入准则，应该从哪个测试级别开始？
建议从问题最集中的级别开始，通常是系统测试。系统测试的准入条件覆盖面广，涉及版本、环境、自测和缺陷说明，制定过程能顺带把提测材料的要求理清。先把系统测试的五到八条准则跑通一到两个版本，再向集成测试和验收测试扩展，单元测试中可自动判定的条目交给流水线。一次铺开所有级别，容易出现条目过多、无人维护的情况。
有条件通过和退回的边界怎么划，评审时经常争论怎么办？
边界应写在准则里，而不是评审时临场讨论。可操作的划分是：缺项是否阻塞本轮测试启动。缺项只影响部分非主流程场景、且有明确补充期限和责任人的，判为有条件通过；缺项导致主流程无法验证或关键证据缺失的，判为退回。制定准则时可以为每条准则标注“关键项”或“一般项”，关键项不符合直接退回，一般项可进入有条件通过。这样判定依据来自准则文本，评审时只需对照条目。
准入准则条目太多执行不下去，应该删减还是合并？
先看条目能否交给自动化判定。构建是否成功、静态检查是否通过、单元测试是否执行，这类有明确机器结论的项目放进流水线，人工评审只保留需要判断力的条目。剩余条目中，证据形式相同的可以合并成一条，例如把多份评审记录合并为“本轮变更均已完成评审并附记录”。合并优先于删减，因为直接删条目可能丢掉必要的核验点。目标是每个测试级别保留五到八条核心准则。
例外放行由谁批，批了之后还要留记录吗？
例外放行通常由项目或质量负责人审批，测试负责人不单独决定放行。审批前要明确三件事：缺的是哪条准则、放行的理由、放行后由谁在什么时间补齐。审批结论和补齐情况都应留痕，与当轮准入评审记录放在一起。例外记录本身也是后续复盘的输入：同一类例外反复出现，说明该条准则的阈值或证据要求需要修订，而不是继续逐次放行。
准入结论和测试用例执行记录需要建立关联吗？
建议建立引用关系。测试结束后回溯问题时，如果能从用例执行结果追溯到当时的准入状态，就能判断某些缺陷是否与准入放宽有关，这也是缺陷逃逸分析的依据。落地方式可以是在测试计划中注明对应的准入评审记录编号，或把准入结论作为测试计划的关联材料保存。关联的颗粒度按团队现有工具条件确定，关键是保证回溯时能找到当时的评审结论和遗留项状态。
