测试用例是描述一次验证目的、前置条件、操作步骤、输入数据和预期结果的文档单元，用来判断某个功能或规则是否符合预期。本文围绕定义、组成字段与概念边界展开，帮助读者看懂一条用例怎么写，并分清它与测试脚本、测试计划、缺陷记录的区别。
要点总览（TL;DR）
- 测试用例是描述验证目的、前置条件、操作步骤、输入数据和预期结果的文档单元，用来判断某个功能或规则是否符合预期。
- 用例本身包含验证条件、预期结果和优先级；测试脚本代码与跨项目用例资产复用机制属于其他层次，不写进单条用例。
- 用例编号、标题、前置条件、步骤、测试数据、预期结果和优先级共同构成一条完整用例，等价类、边界值、决策表决定验证条件如何展开。
- 用例回答“验证什么、怎么验证、结果应是什么”，脚本回答“如何自动执行”，计划回答“本轮测什么、谁执行、何时完成”，缺陷记录回答“发现了什么问题”。
- 判断用例质量看四点：换人执行结论一致、预期结果可观察、前置条件足以复现、规则变化后只需局部修改。
测试用例的准确定义
测试用例（Test Case）是对一次具体验证活动的书面描述：在什么条件下，按什么步骤操作，输入什么数据，应当得到什么结果。它的价值在于把“这个功能对不对”这种模糊判断，转化为可执行、可复核的验证单元——不同的人按同一条用例操作，应当得出同一结论。
一条完整的测试用例通常包含五个核心要素：
- 验证目的：这条用例要证明或证伪什么，例如“验证密码错误时登录被拒绝并给出提示”。
- 前置条件：执行前系统与数据需要处于什么状态，例如“已存在一个状态正常的测试账号”。
- 操作步骤：按顺序执行的动作，每一步指向明确的界面元素或接口行为。
- 输入数据：步骤中使用的具体取值，例如账号、密码、表单字段内容。
- 预期结果：可观察、可判定的输出，例如页面提示文案、跳转目标、数据状态变化。
理解用例还要区分两个相邻概念。测试点是用一句话概括的待验证事项，例如“登录密码校验”，它还没有展开成可执行步骤；测试场景描述一段用户业务过程，例如“用户从登录到下单”，通常由多条用例共同覆盖。用例处在比测试点更具体、比测试场景更细的层级：一个测试点可以拆成若干条用例，一个测试场景则由多条用例组合支撑。
“可执行、可复核”是用例的两个基本属性。可执行意味着步骤与数据足够具体，测试人员不需要临场猜测；可复核意味着预期结果写得足够明确，评审者和其他执行者能判断实际结果是否符合。缺少其中任何一项，这条用例就更接近一条备忘笔记，难以承担验证职责。
测试用例包括什么、不包括什么
划清边界有助于避免把不同层次的内容混进同一条用例。属于用例本身的内容，是围绕一次验证所必需的设计信息：由等价类、边界值、决策表等设计方法推导出的验证条件，明确的预期结果，以及用于安排执行顺序的优先级。优先级通常按业务影响和失败风险划分，例如核心主流程为高优先级，异常分支和兼容性检查可以靠后。
不属于单条用例的内容主要有两类。第一类是测试脚本的代码实现：脚本是用来自动执行用例的程序，包含元素定位、断言写法、等待策略等工程细节，这些内容随技术栈变化，不应写进用例正文。第二类是跨项目的用例资产复用机制，例如用例库的分层分类、跨团队共享、版本继承等组织方式，它们管理的是“一批用例如何被沉淀和调用”，而单条用例只回答“这一次怎么验证”。
用例库与用例本身也是不同层次的概念。用例库是存放、分类和检索用例的集合，强调组织结构和可查找性；用例是库中的最小验证单元，强调内容完整和判定明确。一条用例写得好不好，看的是要素是否齐全、预期是否可判定；一个用例库建得好不好，看的是分类是否清晰、能否快速定位到需要的用例。两者评价口径不同，不能互相替代。
可以用一张清单快速判断某段内容该不该放进用例：
| 内容 | 是否属于用例 | 说明 |
|---|---|---|
| 验证条件与预期结果 | 属于 | 用例的核心，必须明确可判定 |
| 前置条件与测试数据 | 属于 | 保证执行可重复 |
| 优先级 | 属于 | 用于安排执行顺序 |
| 自动化脚本代码 | 不属于 | 属于脚本实现，随技术栈变化 |
| 跨项目复用与共享规则 | 不属于 | 属于用例资产管理机制 |
| 缺陷的现象与修复记录 | 不属于 | 属于缺陷记录，见后文辨析 |
一条用例由哪些部分组成
用例的字段设计服务于两个目标：让执行者知道怎么做，让复核者知道怎么判。常见字段及其作用如下：
| 字段 | 作用 | 写法要点 |
|---|---|---|
| 用例编号 | 唯一标识，便于引用与追踪 | 按模块或功能段编排，保持稳定 |
| 标题 | 一句话说明验证什么 | 包含对象与条件，避免“测试登录”这类笼统表述 |
| 前置条件 | 交代执行起点 | 只写影响结果的状态，不写无关背景 |
| 操作步骤 | 按序描述动作 | 每步一个动作，指向明确对象 |
| 测试数据 | 给出具体输入取值 | 与设计方法对应，覆盖有效与无效取值 |
| 预期结果 | 给出可判定的输出 | 写观察到的现象，不写操作动作 |
| 优先级 | 安排执行顺序 | 按业务影响与失败风险分级 |
设计方法直接决定用例内容如何展开。等价类划分把输入域分成若干等价组，每组取一个代表值，从而用少量用例覆盖大量取值；边界值分析针对取值区间的端点及其邻近值设计用例，因为错误常集中出现在边界；决策表把多个条件组合与对应动作列成表格，适合业务规则由多个条件共同决定的场景，例如不同会员等级叠加不同优惠时的价格计算。三种方法产出的都是验证条件，最终要落成具体的步骤、数据和预期结果。
预期结果的判定口径需要特别注意。好的预期结果描述可观察的事实，例如“页面停留在登录页，提示‘密码错误’，账号未被锁定”；含糊的写法如“登录失败”会让执行者自行解释，导致同一用例在不同人手里得出不同结论。当结果涉及多个观察点时，应逐条列出，避免遗漏。
当用例数量增长后，编写、评审和状态流转需要依托管理工具承载。以 ONES 为例，其测试管理支持编写测试用例、组织用例库，并允许自定义用例属性以适配不同业务场景；用例模块支持树状结构组织与拖拽排序，用例库中的属性可筛选，便于按模块或条件定位用例；用例可与需求、任务关联，测试计划与迭代关联，使“需求—用例—执行”的链路保持可追溯。对于已有大量存量用例的团队，还支持从 Excel 批量导入并在线管理，以及导出备份。这些能力承接的是用例从编写到组织、再到与需求和计划衔接的管理动作，用例内容本身仍由设计方法决定。
测试用例与测试脚本、测试计划有什么区别
用例、脚本、计划、缺陷记录处在测试工作的不同环节，混用会造成职责不清。下面的对照按“回答什么问题”这一统一口径展开：
| 概念 | 回答的问题 | 主要产物 | 变化频率 |
|---|---|---|---|
| 测试用例 | 验证什么、怎么验证、结果应是什么 | 步骤、数据、预期结果 | 随需求与规则变化而更新 |
| 测试脚本 | 如何由程序自动执行这条验证 | 可运行的代码与断言 | 随界面结构、接口和技术栈变化 |
| 测试计划 | 本轮测什么范围、谁执行、何时完成 | 范围、排期、人员与资源安排 | 随迭代节奏调整 |
| 缺陷记录 | 发现了什么问题、如何修复与验证 | 现象描述、严重程度、修复状态 | 随问题处理进展变化 |
用例与脚本是描述与实现的分工。用例用自然语言写清验证逻辑，脚本把同一逻辑翻译成代码。一条用例可以对应零个、一个或多个脚本；脚本重构时用例内容通常不变，这正是把两者分开记录的意义。把元素定位、等待时长写进用例，会让用例随技术细节频繁失效。
用例与计划是单元与整体的区别。用例是单条验证单元，计划是对一轮测试的整体安排，包括范围取舍、环境准备、人员分工和进度。计划引用用例，但不重复用例内容；用例不描述排期，也不承担资源协调职责。
用例与缺陷记录的区别在于目的。用例在设计阶段就写好了预期结果，用于主动验证；缺陷记录在执行之后产生，描述实际结果与预期的偏差及处理过程。执行一条用例可能发现零个或多个缺陷，缺陷修复后通常回到原用例复测，两者通过用例编号建立关联，但记录内容各自独立。
一个具体例子与常见误解
下面以登录密码校验为例，演示一条完整用例的写法（演示情景，仅用于说明格式）：
- 用例编号：LOGIN-003
- 标题：已注册账号输入错误密码时登录被拒绝并提示
- 前置条件：存在状态正常的测试账号 test_user，密码为正确值；账号当前未处于锁定状态
- 步骤：1. 打开登录页；2. 在账号框输入 test_user；3. 在密码框输入错误密码 Wrong@123；4. 点击“登录”
- 测试数据：账号 test_user；密码 Wrong@123（与正确密码仅一位不同，属于有效格式内的错误取值）
- 预期结果：页面停留在登录页；显示提示“账号或密码错误”；账号未被锁定；连续错误次数计数加一
- 优先级：高
这条用例体现了几个要点：标题同时包含对象与条件；前置条件只写影响结果的状态；测试数据给出了具体取值而非“输入错误密码”；预期结果逐条列出可观察现象，包括容易被忽略的计数变化。
常见误解有三类。第一，“步骤越细越好”。步骤应细到可重复执行，但把每个鼠标移动都写进去会稀释重点，通常以“一个动作指向一个明确对象”为度。第二，“预期结果写成操作描述”。例如把预期写成“点击登录后检查是否报错”，这是动作而非结果，应改为“显示提示‘账号或密码错误’”。第三，“用例等于脚本”。用例是验证逻辑的书面表达，脚本是它的自动化实现，二者可以互相参照，但不能相互替代。
判断用例质量可以用几个可核验的问题：换一个人执行能否得到相同结论；预期结果是否每条都可观察；前置条件是否足以支撑复现；需求规则变化后，这条用例是否只需局部修改。维护上，当业务规则调整时，应同步更新受影响的用例并保留变更痕迹，避免用例库中同时存在新旧两套判定口径。用例数量并非越多越好，覆盖关键规则与高风险分支、保持每条用例判定明确，比堆叠重复用例更有价值。
常见问题
一条测试用例的步骤写到什么程度算合适？
以“换一个人照着做能复现”为判断标准。每一步指向一个明确的操作对象，例如“在密码框输入 Wrong@123”，让执行者不需要临场猜测界面位置或数据取值。步骤过粗会导致不同人操作路径不一致，过细到记录每次鼠标移动则会稀释验证重点，也不便于维护。
如果某一步依赖前一步产生的数据或状态，应在前置条件或步骤中写清这个依赖，避免执行者自行补全。
需求规则变更后，已有用例应该怎么处理？
先定位受影响的用例范围，再同步修改步骤、测试数据和预期结果，并保留变更痕迹。重点是避免用例库中同时存在新旧两套判定口径，否则执行者按不同版本操作会得出互相矛盾的结论。
规则变更往往同时影响多条用例，可以按需求或功能模块建立关联，变更时集中排查。用例数量不必随规则增加而无限扩张，覆盖关键规则与高风险分支即可。
手工用例和自动化脚本需要分开维护吗？
建议分开记录。用例用自然语言写清验证逻辑和预期结果，脚本负责把同一逻辑翻译成可运行代码，包含元素定位、断言写法和等待策略。界面结构或技术栈变化时，通常只需调整脚本，用例内容保持稳定。
一条用例可以对应零个、一个或多个脚本。把工程细节写进用例，会让用例随技术细节频繁失效，也增加评审时的理解成本。
用例评审主要看什么？
评审围绕可执行性和可判定性展开：标题是否说清验证对象与条件；前置条件是否足以支撑复现；步骤是否每步一个动作；测试数据是否给出具体取值；预期结果是否逐条可观察。还要检查用例是否覆盖了需求中的关键规则和高风险分支，以及是否存在重复或互相矛盾的用例。
评审意见应落到具体字段上，便于编写者直接修改，而不是停留在“写得不够细”这类笼统评价。
用例数量越多，测试覆盖就越充分吗？
覆盖充分与否取决于关键规则和高风险分支是否被验证，与用例条数没有直接对应关系。等价类划分和边界值分析的作用，正是用较少的代表性取值覆盖较大的输入空间；决策表则把多条件组合梳理清楚，避免遗漏组合分支。
堆叠重复用例会增加执行和维护成本，规则变化时还要同步修改更多条目。保持每条用例判定明确、覆盖有依据，比单纯追求数量更有价值。
