一份可用的测试用例，需要让另一位测试人员在不询问作者的情况下独立执行，并能判断结果是否通过。本文以登录功能为演示情景，给出一条字段齐全的测试用例，逐项解释编号、标题、前置条件、测试数据、步骤与预期结果、优先级和用例类型的写法，再归纳可迁移到其他模块的规律与需要调整的边界。
要点总览（TL;DR）
- 一份可用的测试用例要让他人无需询问即可独立执行，字段至少覆盖编号、标题、关联需求、前置条件、测试数据、步骤与预期结果、优先级和用例类型。
- 标题写清“在什么条件下验证什么”，前置条件只写执行前已成立的状态，测试数据给出可直接输入的具体值，步骤与预期结果按编号一一对应。
- 示例以登录失败锁定策略为演示情景，覆盖触发锁定、锁定期间拦截、锁定解除后恢复的完整链路，可拆分为多条单一判断点的用例。
- 换到优惠券抵扣等模块时，先定判断点再写标题、状态与输入分离、步骤驱动预期、优先级服务回归，这四条规律可以直接套用。
- 探索性测试、性能与兼容性场景、用例库资产复用和自动化脚本实现需要调整字段结构或另行设计，不适合照搬本文示例。
示例目标：这份用例要示范哪些编写规范
本文选取“用户名密码登录”作为示例场景，原因是它足够常见，读者容易判断示例写得对不对，也方便把字段结构平移到查询、下单、审批等功能上。示例中的系统、账号和数据均为演示设定，不对应任何真实客户案例，也不代表经过实测验证的结果。
这条用例重点示范五项规范，读者可以逐项对照自己的用例库自查：
- 标题可验证：标题写清“在什么条件下验证什么”，读者只看标题就知道这条用例要证明哪条规则。
- 前置条件有边界：只写执行前必须成立且不由本用例步骤制造的状态，避免把操作步骤塞进前置条件。
- 步骤与预期一一对应：每一步操作后面跟一条可观察的结果，步骤编号与预期编号对齐。
- 数据具体到可执行：账号、密码、验证码等输入值直接给出，不写“输入正确账号”这类无法照做的描述。
- 优先级与类型有判断依据：优先级来自业务影响与失败概率，用例类型说明这条用例在验证什么，两者都不凭感觉填写。
对照自查时，可以先看标题和步骤能否被他人独立执行，再看预期结果是否描述系统表现而非操作动作，最后检查优先级和类型是否与关联需求的重要性一致。
完整示例：一条登录功能测试用例的填写结果
下表是一条完整填写的用例，字段按常见测试管理工具的用例模板组织。演示情景设定为：某业务系统的登录页支持用户名加密码登录，连续输错密码达到阈值后锁定账号一段时间。
| 字段 | 填写内容 |
|---|---|
| 用例编号 | TC-LOGIN-014 |
| 用例标题 | 已注册用户在密码连续错误达到5次后，使用正确密码登录时提示账号已锁定 |
| 关联需求 | REQ-LOGIN-07 登录失败锁定策略 |
| 用例类型 | 功能测试 / 异常场景 |
| 优先级 | 高 |
| 前置条件 | 1. 测试环境登录服务可用；2. 存在已注册且状态正常的账号 test_user_01，初始密码为 Passw0rd!2024；3. 该账号当前未被锁定，失败次数计数为0 |
| 测试数据 | 用户名：test_user_01；错误密码：Wrong#111；正确密码：Passw0rd!2024 |
操作步骤与预期结果按下表逐条对应，编号保持一致：
| 步骤 | 操作 | 预期结果 |
|---|---|---|
| 1 | 打开登录页，在用户名输入 test_user_01，密码输入 Wrong#111，点击“登录” | 页面提示“用户名或密码错误”，停留在登录页，账号失败次数变为1 |
| 2 | 重复步骤1共4次，累计第5次提交错误密码 | 每次均提示“用户名或密码错误”；第5次提交后提示“账号已锁定，请15分钟后重试”，登录按钮置灰 |
| 3 | 在锁定状态下，用户名输入 test_user_01，密码输入正确密码 Passw0rd!2024，点击“登录” | 页面提示“账号已锁定，请15分钟后重试”，不进入系统首页，不生成登录成功日志 |
| 4 | 等待锁定时间结束后，使用正确密码 Passw0rd!2024 再次登录 | 登录成功，跳转至系统首页，账号失败次数重置为0 |
这条用例覆盖了“触发锁定—锁定期间拦截—锁定解除后恢复”的完整链路。若团队希望一条用例只验证一个判断点，可以把它拆成“连续错误触发锁定”“锁定期间正确密码被拒绝”“锁定到期后正常登录”三条，字段结构保持不变。
逐项解释：每个字段为什么这样写
字段写法的共同标准是：让执行者不需要猜测。下面逐项说明示例中的选择理由，并给出常见错误写法与改法。
标题：写条件与判断点，不写操作过程
示例标题包含三个要素：对象（已注册用户）、条件（密码连续错误达到5次）、验证点（正确密码登录时提示锁定）。读者只看标题就能判断这条用例验证的是锁定策略，而不是登录成功路径。常见错误是写成“测试登录功能”或“输入错误密码登录”，前者范围过大，后者没有说明要验证什么结果。
前置条件与测试数据：分开写，各自有边界
前置条件描述执行前必须成立的状态，例如账号已注册、未被锁定、计数为0；测试数据描述步骤中要输入的具体值。两者混写会导致执行者分不清哪些需要提前准备、哪些在步骤中使用。示例中把初始密码放在前置条件，是因为它属于账号的初始状态；把错误密码放在测试数据，是因为它在步骤中被反复输入。常见错误是在前置条件里写“用户打开登录页并输入错误密码5次”，这已经是操作步骤，应移到步骤区。
步骤与预期结果：一条操作对一条可观察结果
步骤粒度以“一次可观察的交互”为准，点击一次登录按钮算一步，连续重复可以在一步中说明次数。预期结果要写系统表现，例如提示文案、页面停留位置、按钮状态、失败次数变化，避免写“登录失败”这种需要执行者自行解释的判断。示例第3步特意写明“不生成登录成功日志”，是为了让锁定拦截在界面之外也有可核对的依据。常见错误是多个操作合并成一步、预期结果只写“正常”或“符合预期”。
优先级与用例类型：按影响和验证目的判断
优先级取决于失败后的业务影响和发生概率。账号锁定策略失效可能导致暴力破解或用户被误锁，影响面较大，因此定为高。用例类型说明这条用例在验证什么：示例属于功能测试中的异常场景，与正常登录的成功路径用例区分开。常见错误是所有用例一律标“高”，或者类型栏留空，导致后续按类型筛选回归范围时无法使用。
正误写法对照如下：
| 字段 | 常见错误写法 | 改法 |
|---|---|---|
| 标题 | 登录功能测试 | 已注册用户在密码连续错误达到5次后，使用正确密码登录时提示账号已锁定 |
| 前置条件 | 用户输入错误密码5次 | 账号 test_user_01 已注册、状态正常、未被锁定，失败次数计数为0 |
| 测试数据 | 输入正确的用户名和密码 | 用户名：test_user_01；正确密码：Passw0rd!2024 |
| 预期结果 | 登录失败 | 提示“账号已锁定，请15分钟后重试”，停留在登录页，不进入首页 |
| 优先级 | 全部标为高 | 按业务影响与失败概率分级，锁定策略类用例定为高 |
可迁移规律：换一个模块如何套用同一套写法
把示例抽象后，可以得到四条可复用的编写规律：
- 先定判断点，再写标题：每条用例对应一个明确的通过/不通过判断，标题围绕这个判断组织。
- 状态与输入分离：前置条件管“开始前已成立什么”，测试数据管“步骤中用什么值”，两者不交叉。
- 步骤驱动预期：每增加一步操作，就补一条对应的可观察结果，编号对齐，便于执行时逐条勾选。
- 优先级服务回归：优先级要能支撑“时间不够时先跑哪些”的决策，因此与需求重要性和失败影响挂钩。
以“优惠券下单抵扣”为例，迁移后的简例可以是：标题写“订单金额满足满减门槛时，使用满100减20优惠券，应付金额减少20元”；前置条件写“存在可用优惠券且未过期、购物车中商品金额为120元”；测试数据写“优惠券码 COUPON-20、商品单价60元、数量2”；步骤1选择商品进入结算页，预期应付金额120元；步骤2输入优惠券码并应用，预期应付金额变为100元且优惠明细显示抵扣20元；步骤3提交订单，预期订单实付金额为100元。字段结构与登录示例完全一致。
评审时可以用四个检查点快速判断用例质量：标题能否独立说明验证点；前置条件是否只包含状态；每条步骤是否都有对应的预期结果；预期结果是否描述可观察的系统表现。四项都通过，这条用例基本可以被他人独立执行。
用例编写完成后，评审、状态流转和执行记录需要落到具体载体上。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；用例可组织到用例库中，并支持自定义用例属性以适配不同业务场景。用例评审通过后进入测试计划执行，未通过的用例可快速创建缺陷任务，在测试与研发团队间流转。这样，示例中的“关联需求”“优先级”“用例类型”等字段就不只是文档里的文字，而是能在流程中被筛选、跟踪和复用的信息。
适用边界：示例写法在哪些情况下需要调整
这套写法适合有明确规则、结果可判定的功能用例，例如登录、查询、下单、审批流转。遇到以下情形时需要调整，而不是照搬字段结构。
探索性测试：探索性测试依赖执行者的即时判断和临场设计，事前写死步骤与预期会限制发现问题的空间。此时可以只保留测试章程，写明探索目标、时间盒和关注区域，把详细步骤留给执行过程记录。
性能与兼容性场景：这类用例的重点是负载条件、环境组合和指标阈值，单条“操作—预期”结构不够用。需要补充并发数、持续时间、设备与浏览器矩阵、性能基线等字段，预期结果写成指标区间而非单一句子。
用例库资产复用：当同一批用例需要在多个项目或版本中重复使用时，字段设计还要考虑公共步骤的抽取和参数化，这属于用例库建设的工作，本文的示例只解决单条用例怎么写清楚。自动化脚本的实现同样不在本文范围内，示例中的步骤描述可以作为脚本设计的输入，但脚本的元素定位、断言实现需要另行设计。
判断是否需要调整的一个简单标准是：如果执行者必须依赖现场判断才能决定下一步做什么，或者通过标准无法用一句话说清，就说明这条用例不适合套用本文的固定字段结构，应改用更匹配的测试形式。
常见问题
一条测试用例只验证一个判断点，还是可以覆盖完整链路？
两种做法都有适用场景。覆盖完整链路的用例执行次数少、上下文连贯，适合验证流程性规则，例如锁定策略从触发到解除的全过程；单一判断点的用例定位问题更快，失败时能直接看出是哪条规则不满足，适合回归范围需要精细筛选的团队。
折中做法是先按链路写一条主用例，再在需要精细跟踪时拆成多条，字段结构保持不变。拆分后要保证每条用例的前置条件能独立成立，避免出现“承接上一条用例状态”的写法。
前置条件和测试数据到底怎么区分，初始账号密码算哪一个？
判断标准是这条信息在什么时候起作用。执行开始前就必须成立的状态放前置条件，例如账号已注册、未被锁定、失败次数计数为0；在步骤执行过程中被输入或使用的具体值放测试数据，例如错误密码、优惠券码、商品数量。
初始密码放在哪一侧取决于它是否在步骤中被直接使用。如果步骤里要用正确密码登录，把它写进测试数据更利于执行者照做；如果只是说明账号的初始状态，放在前置条件即可。关键是同一信息不要在两处重复且描述不一致。
预期结果写到什么程度才算可观察？
可观察指执行者不需要自行解释就能判断通过与否。提示文案、页面停留位置、按钮是否置灰、失败次数变化、是否生成日志，都属于可观察结果；“登录失败”“显示正常”“符合预期”则需要执行者自行解释，不同人可能得出不同结论。
如果界面之外还有可核对的依据，例如日志、计数、状态字段，建议一并写入预期结果，这样锁定拦截这类规则在界面和后台都能被验证。
用例写完后评审和缺陷流转怎么衔接？
评审时可以用四个检查点快速过一遍：标题能否独立说明验证点；前置条件是否只包含状态；每条步骤是否都有对应的预期结果；预期结果是否描述可观察的系统表现。四项都通过，这条用例基本可被他人独立执行。
评审通过后进入测试计划执行，执行未通过的用例需要能直接转为缺陷并带上复现步骤。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务，在测试与研发团队间流转，用例也可组织到用例库中并自定义属性。
探索性测试和性能测试也要按这套字段写吗？
不需要照搬。探索性测试依赖执行者的即时判断，事前写死步骤和预期会限制发现问题的空间，可以只保留测试章程，写明探索目标、时间盒和关注区域。性能与兼容性场景的重点是负载条件、环境组合和指标阈值，需要补充并发数、持续时间、设备与浏览器矩阵、性能基线等字段，预期结果写成指标区间。
判断标准是：如果执行者必须依赖现场判断才能决定下一步，或者通过标准无法用一句话说清，就说明这条用例不适合套用固定字段结构。
