写测试用例时，前置条件、步骤和预期结果最容易出现三种问题：前置条件写成背景介绍，步骤把多个动作挤在一行，预期结果只写“正常显示”。本文给出一份可直接复制的空白用例表，逐字段说明填写口径，并用一条完整示例示范这三段内容怎么写，最后说明模板如何按项目裁剪和长期维护。如果用例需要在测试管理工具中承载，可参考文中提到的ONES TestCase对字段自定义和需求关联的支持方式。
要点总览（TL;DR）
- 空白用例表保留用例编号、标题、优先级、前置条件、操作步骤、预期结果六个核心字段，测试数据、关联需求、用例类型、执行结果、备注按项目需要增删。
- 前置条件写执行前必须成立的环境、数据、权限与初始状态，每条都应能被执行人自行确认；需要提前准备的内容放前置条件，执行过程中的动作放步骤。
- 操作步骤按一次可观察的动作拆行并编号，一行只做一件事，动作具体到操作对象，步骤中引用的数据与测试数据字段保持一致。
- 预期结果与步骤编号逐条对应，写成可判定的界面、数据或状态表现，除界面检查外还要覆盖数据落库等状态变化。
- 模板按执行与追溯需要裁剪字段，字段增删和填写口径变化需升版本并记录，新项目启动、执行反复阻塞、引入测试管理工具时触发更新。
可复制空白测试用例模板
下面这张表可以直接复制到Excel、在线表格或文档中。表头分为两区：前六列是核心字段，任何一条用例都应填写；后五列是辅助字段，按项目需要保留或删除。表格下方留出若干空行即可开始填写。
| 用例编号 | 用例标题 | 优先级 | 前置条件 | 操作步骤 | 预期结果 | 测试数据 | 关联需求 | 用例类型 | 执行结果 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
表格版适合批量维护和导入工具，一行一条用例，步骤与预期结果写在同一个单元格内，用编号分行。文档版适合需要详细描述的单条用例，排布为：顶部写用例编号、标题、优先级、关联需求，中部依次写前置条件、操作步骤、预期结果三个小节，底部写测试数据与备注。两种排布承载的信息相同，选择取决于团队维护习惯和后续是否导入测试管理工具。
模板字段说明：每个字段填什么
字段说明的作用是让不同人填出的用例保持同一口径。下表逐字段给出含义与填写要求，其中步骤与预期结果的对应关系是整张表的关键约束。
| 字段 | 填写口径 | 示例 |
|---|---|---|
| 用例编号 | 项目内唯一，建议“模块缩写-序号”，创建后不再变更 | LOGIN-012 |
| 用例标题 | 用“条件+动作+对象”概括验证点，一句话说清测什么 | 使用已注册手机号与正确密码登录 |
| 优先级 | 按业务影响与使用频率定级，常用P0至P3四档 | P0 |
| 前置条件 | 执行前必须成立的环境、数据、权限与状态，缺一不可执行 | 测试环境可访问；账号已注册且状态正常 |
| 操作步骤 | 按一次可观察的动作拆行，每行只做一件事，带编号 | 1. 打开登录页 2. 输入手机号 3. 输入密码 4. 点击登录 |
| 预期结果 | 与步骤编号逐条对应，写成可判定的界面、数据或状态表现 | 2. 输入框回显完整手机号 4. 跳转首页并显示当前账号昵称 |
| 测试数据 | 步骤中引用的具体输入值，便于换数据复用 | 手机号13800000000，密码Abc12345 |
| 关联需求 | 填写需求编号或链接，用于追溯覆盖情况 | REQ-2031 |
| 用例类型 | 功能、边界、异常、权限等分类，便于筛选执行 | 功能 |
| 执行结果 | 执行时填写通过、失败、阻塞，并记录实际表现 | 通过 |
| 备注 | 记录依赖、已知缺陷或特殊说明 | 依赖短信服务可用 |
步骤与预期结果的对应关系需要单独强调：步骤写到第几步，预期结果就应覆盖到第几步的关键检查点，编号保持一致。这样执行人按编号逐条核对，失败时也能直接定位到具体动作，而不是笼统判断“结果不对”。
必填与选填：哪些字段不能空
模板字段多，不等于每条用例都要填满。必填字段保证用例可执行、可追溯；选填字段服务于特定场景，空着不影响执行。区分清楚可以避免模板被填成半成品，也避免为了填表而写无效内容。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 用例编号 | 必填 | 唯一标识，执行记录、缺陷单都靠它引用 |
| 用例标题 | 必填 | 决定用例能否被检索和评审 |
| 优先级 | 必填 | 决定回归范围和执行顺序 |
| 前置条件 | 必填 | 缺失会导致执行人自行假设环境，结果不可比 |
| 操作步骤 | 必填 | 用例的主体内容 |
| 预期结果 | 必填 | 没有可判定结果就无法判断通过与否 |
| 测试数据 | 选填 | 步骤中已写死具体值时可不单列；需要多组数据驱动时必填 |
| 关联需求 | 选填 | 有需求管理流程时填写，用于覆盖追溯 |
| 用例类型 | 选填 | 用例量大、需要按类型筛选执行时填写 |
| 执行结果 | 选填 | 设计阶段留空，执行阶段填写 |
| 备注 | 选填 | 有依赖或特殊说明时填写 |
字段为空时用统一标注区分两种情况：确认该用例不需要此字段，填“不适用”；暂时无法确定，填“待补充”并注明补充人和时间。两种标注混用会让评审无法判断是遗漏还是有意留空，因此需要在模板说明中固定下来。前置条件确实为空的情况很少，例如纯界面文案检查，此时写“无特殊前置条件，打开页面即可执行”，比留空更清楚。
前置条件、步骤与预期结果的写法示例
下面是一条完整填写的用例，以手机号登录为例。示例中的账号、密码和环境均为演示数据，实际使用时替换为项目真实信息。
| 字段 | 内容 |
|---|---|
| 用例编号 | LOGIN-012 |
| 用例标题 | 使用已注册手机号与正确密码登录 |
| 优先级 | P0 |
| 前置条件 | 1. 测试环境登录页可正常访问；2. 手机号13800000000已注册，账号状态为正常，未锁定；3. 该账号密码为Abc12345；4. 当前浏览器无该账号的登录态 |
| 操作步骤 | 1. 打开登录页；2. 在手机号输入框输入13800000000；3. 在密码输入框输入Abc12345；4. 点击“登录”按钮 |
| 预期结果 | 1. 登录页正常加载，手机号、密码输入框与登录按钮均可见；2. 手机号输入框回显13800000000；3. 密码以掩码显示，不回显明文；4. 登录成功，页面跳转至首页，右上角显示该账号昵称，账号最近登录时间更新为当前时间 |
| 测试数据 | 手机号13800000000，密码Abc12345 |
| 关联需求 | REQ-2031 |
前置条件的写法要点是覆盖四类状态：环境（哪个环境、服务是否可用）、数据（账号、订单、配置等已存在且状态正确）、权限（当前用户具备什么角色）、初始状态（登录态、缓存、开关位置）。每一条都应是执行人可自行确认的事实，写成“系统运行正常”这类无法核对的描述就失去了作用。前置条件与步骤的分界也要清楚：需要提前准备的内容放前置条件，执行过程中做的动作放步骤。
步骤的写法要点是单动作、可执行、顺序清晰。一行只写一个动作，“输入手机号和密码并点击登录”应拆成三行。动作要具体到操作对象，写“点击登录按钮”而不是“进行登录操作”。步骤中引用的数据与测试数据字段保持一致，避免同一用例出现两个手机号。步骤数量以覆盖验证点为准，不必为了完整加入与验证目标无关的导航动作。
预期结果的写法要点是可判定、与步骤对应、含数据校验。可判定指执行人能明确回答“是或否”，写“跳转首页”比写“登录成功”更可判定；与步骤对应指按编号覆盖关键动作，示例中第2、3步检查输入回显，第4步检查跳转与账号信息；含数据校验指不仅看界面，还检查状态变化，例如最近登录时间更新、登录记录写入，这类检查能发现界面正常但数据未落库的问题。对于异常用例，预期结果要写清错误提示文案、提示位置以及账号状态未被改变。
模板的调整与维护方法
模板需要随项目变化调整，但调整应有规则，否则不同项目的用例无法汇总比较。裁剪字段的原则是按执行与追溯需要取舍：核心六字段在任何项目都保留；测试数据在需要多组数据驱动或数据敏感的场景保留；关联需求在团队有需求管理流程时保留；用例类型在用例数量达到需要筛选执行的规模时保留。裁剪时同步更新字段说明，避免模板与说明脱节。
模板版本与变更记录建议在表格首行或独立说明页维护，记录版本号、变更内容、变更人和生效日期。字段增删、填写口径变化、标注约定调整都属于需要升版本的变更；仅修改示例内容不必升版本。版本号可写入用例编号规则之外的文件名或说明页，保证历史用例能对应到当时的模板版本。
评审与更新由以下情况触发：新项目启动时确认字段裁剪；需求评审发现用例覆盖不到验收点时，检查是否缺少关联需求或类型字段；执行阶段多次出现因前置条件缺失导致的阻塞时，补充前置条件必填项；团队引入测试管理工具时，按工具字段结构对齐模板。每次更新后选一条历史用例按新模板重填，验证模板可用再推广。
当用例从表格迁移到测试管理工具时，模板字段需要与工具字段对应。ONES TestCase支持自定义用例属性以适配不同业务场景，并支持测试用例与需求、任务关联，测试计划与迭代关联；用例可通过Excel批量导入，也可导出备份。按这套方式落地时，可以把模板中的关联需求、用例类型对应为自定义属性，把执行结果留在执行阶段填写，使表格模板与工具中的用例结构保持一致。
常见问题
前置条件里写了“系统运行正常”，为什么执行时还是经常卡住？
“系统运行正常”无法被逐项核对，执行人只能自行假设环境状态。前置条件应拆成可确认的事实，例如“测试环境登录页可访问”“账号13800000000已注册且未锁定”“当前浏览器无该账号登录态”。每条都能由执行人打开页面或查询数据确认，出现阻塞时也能直接定位是哪一项不成立。
一条用例的步骤很多，预期结果需要每一步都写吗？
预期结果覆盖步骤中的关键检查点即可，编号与步骤保持一致。输入类动作通常检查回显或掩码，提交类动作检查跳转、提示文案与数据变化。与验证目标无关的导航动作可以不写预期结果，但编号仍保留，避免执行人核对时错位。
异常场景的预期结果和正常场景写法有什么不同？
异常场景的预期结果要写清三件事：错误提示的具体文案与出现位置、页面停留在哪里、账号或数据状态是否被改变。例如密码错误时，应写明提示文案、输入框是否清空、账号是否计入失败次数。只写“提示错误”会让执行人无法判断提示是否符合需求。
表格模板迁移到测试管理工具时，字段怎么对应？
先确认工具支持的字段类型，再把模板字段逐一映射：用例编号、标题、优先级通常对应工具的基础属性，关联需求、用例类型可对应为自定义属性，执行结果留在执行阶段填写。ONES TestCase 支持自定义用例属性以适配不同业务场景，支持测试用例与需求、任务关联，并支持从 Excel 批量导入用例，可作为迁移时的对照参考。迁移后选几条历史用例按新结构重填，确认信息没有丢失再批量导入。
模板字段裁剪后，历史用例还能和新用例一起统计吗？
可以，前提是核心六字段在任何项目都保留，裁剪只发生在辅助字段。历史用例对应当时的模板版本，统计时以核心字段为共同口径，辅助字段按版本说明区分。若裁剪涉及核心字段或填写口径变化，需要升版本并在变更记录中注明生效日期，避免新旧用例被当作同一口径比较。
