测试条件是把需求、设计说明和业务规则拆成一组可验证的判断点。确定测试条件时，先界定被测对象与范围，再从输入、状态、边界、异常和业务规则五个来源提取候选条件，用可判定的表述写成清单，逐条核对可测性、覆盖性和可追溯性，最后评审冻结，再进入用例编写。本文给出提取来源、表述模板、六步操作流程、角色分工、一个登录场景的完整示例和完成检查表。
要点总览（TL;DR）
- 测试条件从五类来源提取：功能描述、输入数据、状态与流程、边界与异常、业务规则与约束，每条条件都要能回到具体材料。
- 可判定的条件包含前置状态、操作、预期结果三要素，一条条件只对应一个判断点，条件说明测什么、用例说明怎么测。
- 按六步执行：界定范围、按来源提取、合并去重并标优先级、可测性检查、建立需求追溯、评审冻结基线。
- 测试设计人员负责提取与维护，需求或产品人员确认业务规则，开发人员补充技术约束与异常路径，三方共同评审。
- 放行前逐项检查可判定性、来源覆盖、重复矛盾、追溯关系和评审意见状态，阻断项未解决不进入用例编写。
测试条件从哪里来：五个提取来源
测试条件应当从材料里找，而不是凭经验想。经验能帮助发现遗漏，但条件的依据必须能回到某份需求、某条规则或某个设计说明上，否则评审时无法确认它是否该测。以下五类来源覆盖了大多数业务系统的条件提取场景，可以按此顺序逐项过一遍。
| 来源 | 具体材料 | 典型条件 |
|---|---|---|
| 功能描述 | 需求文档、原型、设计说明中的功能条目与操作流程 | 某功能在给定角色下可执行，执行后产生指定结果 |
| 输入数据 | 字段取值范围、格式要求、必填与选填、字段间组合关系 | 输入合法值通过；输入超长、格式错误、必填为空被拦截 |
| 状态与流程 | 状态机、审批流、订单或工单的流转节点 | 状态A在满足条件时转为状态B；不允许的转换被拒绝 |
| 边界与异常 | 数值上下限、长度限制、并发与超时设定、失败路径 | 取最小值、最大值、越界值时的处理；依赖服务失败时的提示与回退 |
| 业务规则与约束 | 业务规则表、权限矩阵、合规与审计要求 | 无权限角色不可见某数据；操作留痕满足审计要求 |
提取时建议按来源分类记录，每条候选条件标注它出自哪份材料的哪一节。分类记录的好处是评审时能快速发现某一来源整体缺失，例如只提了功能条件却完全没有异常路径，这通常意味着提取不完整，而不是系统真的没有异常场景。
把模糊描述改写成可判定的测试条件
条件写得笼统，是用例返工的主要原因。“登录功能正常”“金额校验合理”这类描述无法判断通过还是失败，也无法据此设计步骤。可判定的条件需要包含三个要素：前置状态、操作、预期结果。前置状态说明系统处于什么条件下，操作说明触发什么动作，预期结果必须是可观察的，比如页面提示文字、数据状态变化、接口返回码或日志记录。
改写时遵循三条规则。第一，用可观察结果替代“正常”“合理”“正确”等模糊词，把预期写成具体现象。第二，一条条件只对应一个判断点，把“登录成功且记住密码生效”拆成两条，否则失败时无法定位是哪一点不满足。第三，条件与用例分层：条件描述测什么，用例描述怎么测。一条条件可以对应一条或多条用例，用例补充具体数据、步骤和操作顺序。
| 改写前 | 改写后 |
|---|---|
| 用户名密码校验正常 | 前置：账号已注册且状态为启用；操作：输入正确用户名与正确密码并提交；预期：进入首页，页面显示当前用户名 |
| 密码错误有提示 | 前置：账号已注册；操作：输入正确用户名与错误密码并提交；预期：停留在登录页，提示“用户名或密码错误”，不透露具体哪项错误 |
| 输入长度合理 | 前置：登录页已打开；操作：用户名输入框输入超过上限长度的字符并提交；预期：提交被拦截，提示长度超限，请求不发出 |
改写后的条件可以直接交给他人评审：任何人读到这条条件，都能判断系统当前表现是否满足。条件清单冻结后，用例编写者按条件补充测试数据与操作步骤，两者保持一对多或多对一的映射关系，便于后续统计覆盖情况。
确定测试条件的操作步骤
以下六步按顺序执行，每步都有明确的输入、动作、输出和完成标志。步骤之间允许小幅回退，例如可测性检查发现问题时回到提取环节补充，但整体顺序不宜打乱，否则容易出现条件清单写完了才发现范围没界定清楚的情况。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 界定被测对象与范围 | 需求清单、版本计划、系统架构说明 | 明确本次测哪个功能模块、涉及哪些上下游系统、哪些明确不测 | 范围说明，含纳入项与排除项 | 范围说明经需求方确认，排除项有书面理由 |
| 2. 按来源逐项提取候选条件 | 需求文档、原型、规则表、接口说明 | 按五个来源逐项过材料，每条候选条件记录出处 | 候选条件列表，带来源标注 | 五个来源均有覆盖或注明不适用及原因 |
| 3. 合并重复并标注优先级 | 候选条件列表 | 合并语义重复的条件，按业务影响与发生概率标注高、中、低优先级 | 去重后的条件清单初稿 | 无重复条目，每条有优先级 |
| 4. 逐条做可测性检查 | 条件清单初稿 | 检查每条条件能否构造前置状态、能否观察到预期结果，不可测的改写或拆分 | 可测的条件清单 | 每条条件均能写出至少一条可执行用例 |
| 5. 建立与需求的追溯关系 | 可测条件清单、需求条目编号 | 为每条条件标注对应需求条目，反向检查每条需求是否至少有一条条件 | 带追溯标识的条件清单 | 需求与条件双向可查，无孤立需求 |
| 6. 评审确认并冻结基线 | 带追溯标识的条件清单 | 组织需求、开发、测试共同评审，处理意见后定版 | 评审通过的条件清单基线 | 评审意见关闭，基线版本号确定并通知相关方 |
第三步的优先级标注需要说明依据。高优先级通常对应核心业务流程、资金与权限相关规则、高频操作路径；低优先级对应低频配置项和展示类细节。优先级影响后续用例编写和执行的投入顺序，标注时写清理由，评审时更容易达成一致。
第五步的追溯关系是条件清单能否长期可用的关键。条件与需求建立关联后，需求变更时能快速定位受影响的条件；在 ONES 中，测试用例支持与产品需求、研发任务关联，测试计划与迭代关联，条件清单以用例或需求下的检查项形式承载时，可以沿用这条关联链路完成追溯与变更影响分析。条件层级的独立对象是否单独管理，需按团队实际配置确认。
角色分工与各环节交付物
测试条件不是测试人员单独完成的产物。业务规则的确认、技术约束的补充、评审的通过标准，都需要不同角色参与。分工不清时常见的结果是条件清单写得很细但业务规则理解有偏差，或者异常条件缺失导致上线后暴露问题。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 测试设计人员 | 执行六步流程中的提取、合并、可测性检查与追溯标注，维护条件清单 | 候选条件列表、条件清单初稿与基线版本 |
| 需求或产品人员 | 确认业务规则、约束条件与优先级判断，澄清需求歧义 | 规则确认意见、需求条目与条件的对应确认 |
| 开发人员 | 补充技术约束、异常路径、依赖服务失败时的系统行为 | 技术约束说明、异常条件补充条目 |
| 评审参与者（需求、开发、测试共同） | 按评审标准逐条检查条件清单 | 评审意见与结论 |
评审通过标准建议明确为：每条条件可判定通过或失败；五个来源均有覆盖或注明不适用；条件与需求双向可追溯；无重复与互相矛盾的条目；高优先级条件均有对应需求依据。评审意见关闭后冻结基线，基线版本号记录在条件清单头部。
条件清单的变更维护由测试设计人员负责执行，业务规则类变更由需求或产品人员发起确认。需求变更发生时，先通过追溯关系定位受影响条件，更新后重新走评审，并在清单中记录变更原因与版本。ONES 支持自定义用例属性，可将条件编号、来源、优先级等作为属性管理，用例库中的属性支持筛选，便于按来源或优先级快速定位条目；条件清单的组织也可借助用例模块的树状结构按功能模块分层。
示例：一个登录场景的测试条件推导
以下示例为演示情景，用于说明方法如何落地，不代表任何真实系统的完整需求。原始需求描述为：“用户使用已注册的用户名和密码登录系统，连续输错密码5次后账号锁定30分钟，登录成功后进入首页。”
按五个来源提取候选条件：输入来源包括用户名与密码的格式、长度、必填；边界来源包括密码错误次数4次、5次、6次的处理，锁定时间29分钟、30分钟、31分钟的边界；状态来源包括账号启用、锁定、解锁后的状态转换；异常来源包括账号不存在、密码错误、锁定期间尝试登录；业务规则来源包括错误提示不透露具体哪项错误、锁定期间不校验密码。
| 条件编号 | 可判定条件表述 | 来源 | 优先级 | 对应用例 |
|---|---|---|---|---|
| L-01 | 前置：账号已注册且启用；操作：输入正确用户名与正确密码提交；预期：进入首页并显示当前用户名 | 功能 | 高 | TC-01 正常登录 |
| L-02 | 前置：账号已注册；操作：输入正确用户名与错误密码提交；预期：停留登录页，提示“用户名或密码错误” | 异常 | 高 | TC-02 密码错误 |
| L-03 | 前置：账号已注册；操作：输入未注册用户名提交；预期：提示与L-02一致，不暴露账号是否存在 | 业务规则 | 高 | TC-03 账号不存在 |
| L-04 | 前置：账号已连续输错4次密码；操作：第5次输入错误密码；预期：提示账号已锁定，锁定30分钟 | 边界 | 高 | TC-04 第5次错误触发锁定 |
| L-05 | 前置：账号处于锁定状态且未满30分钟；操作：输入正确密码提交；预期：拒绝登录，提示剩余锁定时间，不校验密码 | 状态 | 高 | TC-05 锁定期间登录 |
| L-06 | 前置：账号锁定已满30分钟；操作：输入正确密码提交；预期：登录成功，错误次数清零 | 状态 | 中 | TC-06 解锁后登录 |
| L-07 | 前置：登录页已打开；操作：用户名或密码为空提交；预期：提交被拦截并提示必填 | 输入 | 中 | TC-07 必填校验 |
这个示例体现的可迁移规律有三点。一是边界条件要取临界值两侧，第5次触发锁定、第4次不触发、锁定满30分钟与未满30分钟分别验证。二是业务规则类条件往往决定提示文案与信息暴露程度，需要产品人员确认后才能定稿。三是状态类条件必须写清前置状态，否则执行时无法复现。把同样的思路套到支付、审批、权限等场景，来源清单和表述规则保持不变，只是材料不同。
完成检查：条件清单是否可用
条件清单进入用例编写前，用以下检查表逐项核对。检查由测试设计人员自检，评审时由参与角色共同确认。检查表的作用是把“感觉差不多了”变成可核验的条目，减少后续返工。
| 检查项 | 核验方式 | 不通过时的处理 |
|---|---|---|
| 每条条件可判定通过或失败 | 随机抽取条件，尝试写出预期结果的具体观察点 | 改写为含前置状态、操作、预期结果三要素的表述 |
| 覆盖输入、边界、状态、异常与业务规则 | 按五个来源统计条件数量，检查是否有来源为空 | 回到材料补充提取，或注明该来源不适用的理由 |
| 无重复或互相矛盾的条件 | 按功能点分组比对语义相近条目 | 合并重复项，矛盾项提交需求方裁决 |
| 与需求建立追溯关系 | 双向检查：每条条件有需求出处，每条需求至少一条条件 | 补齐追溯标识，孤立需求补充条件或说明不测理由 |
| 变更后同步更新 | 核对需求变更记录与条件清单版本记录 | 按变更影响范围更新条件并重新评审 |
| 评审意见已关闭 | 检查评审记录中的意见状态 | 未关闭意见不得冻结基线 |
阻断项与放行条件需要事先约定。出现以下情况时，条件清单不应进入用例编写：存在无法判定通过与否的条件且未改写；核心业务规则未获需求方确认；高优先级条件缺少需求追溯；评审意见未关闭。其余问题，例如个别低优先级条件表述待优化，可以记录为遗留项并在用例编写过程中修正，不阻断整体进度。冻结基线后，条件清单的版本号、评审结论和遗留项清单一并归档，作为后续需求变更影响分析的起点。
常见问题
需求文档写得很粗，提取不出足够的测试条件怎么办？
先按五个来源逐项过一遍材料，把能提取的条件列出来，同时记录哪些来源为空。功能描述缺失时，可以从原型、接口说明和已有规则表中补；异常与边界条件缺失时，找开发人员确认技术约束和依赖服务失败时的系统行为。仍无法确认的业务规则，提交需求或产品人员澄清，把澄清结论写回条件清单并标注出处。条件清单中保留“待确认”标记，评审时集中处理，避免在提取阶段反复停顿。
条件清单和测试用例需要分开维护吗？
两者是分层关系：条件描述测什么，用例描述怎么测。分开维护的好处是需求变更时先看条件层，能快速判断影响范围，再决定改哪些用例；条件数量通常少于用例数量，评审成本也更低。如果团队规模小、需求变动不频繁，也可以把条件作为用例的前置说明或检查项承载，但需要保证每条条件仍能独立判定通过或失败。选择哪种方式取决于变更频率和评审要求，不必强求统一。
条件清单冻结后，需求变更了怎么处理？
通过追溯关系定位受影响的条件，评估变更属于新增、修改还是删除，更新条件清单后重新走评审，并记录变更原因与版本号。只影响个别低优先级条件的变更，可以记录为遗留项，在用例编写过程中同步修正；涉及核心业务规则或高优先级条件的变更，应重新冻结基线后再继续。变更记录与评审结论一并归档，作为下一次影响分析的起点。
评审时各方对优先级判断不一致，如何收敛？
把优先级判断落到依据上：核心业务流程、资金与权限相关规则、高频操作路径通常为高优先级；低频配置项和展示类细节为低优先级。评审时要求每条高优先级条件写明对应的业务影响，争议条目由需求或产品人员给出业务侧判断，测试设计人员补充发生概率和影响范围。无法当场达成一致的条目，记录分歧点并约定确认时间，不阻塞其余条目的评审。
条件清单在ONES中如何承载追溯和变更管理？
ONES 支持测试用例与产品需求、研发任务关联，测试计划与迭代关联。条件清单以用例或需求下的检查项形式承载时，可以沿用这条关联链路完成需求追溯与变更影响分析；用例属性支持自定义，可将条件编号、来源、优先级作为属性管理，用例库中的属性支持筛选，便于按来源或优先级定位条目。条件层级的独立对象是否单独管理，需按团队实际配置确认。
