填写测试用例模板，核心是把一条用例写成可执行、可判断、可追溯的记录：标题说明测什么，前置条件和测试数据说明从什么状态开始，操作步骤写清每一步动作，预期结果对应每一步给出可观察的判断依据。下面提供一张可直接复制的空白表，并逐字段说明填写口径、必填底线和一条完整示例。
要点总览（TL;DR）
- 测试用例模板的填写核心是让一条用例可执行、可判断、可追溯：标题说明测什么，前置条件和测试数据说明起点，步骤与预期结果逐条对应。
- 空白表包含用例编号、标题、所属模块、前置条件、测试数据、操作步骤、预期结果、优先级、用例类型、关联需求、备注共11个字段，可直接复制使用。
- 必填底线为编号、标题、模块、前置条件、操作步骤、预期结果、优先级；测试数据在涉及具体输入值时必填，用例类型、关联需求、备注可选填。
- 步骤与预期结果使用同一套序号逐条对应，判断依据写成可观察的界面变化、提示文案或数据状态，避免“正常”“正确”这类无法验证的表述。
- 模板落地后按“多数用例需要且无法推导”的标准增删字段，统一命名与取值口径，并在项目启动或需求结构大改时评审更新版本。
可复制空白测试用例模板
下面这张表可以直接复制到文档或表格工具中使用。字段顺序按填写时的自然顺序排列：先标识用例，再描述条件与步骤，最后标注执行属性。复制时保留表头，按行填写即可。
| 用例编号 | 用例标题 | 所属模块 | 前置条件 | 测试数据 | 操作步骤 | 预期结果 | 优先级 | 用例类型 | 关联需求 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
如果团队使用表格工具，建议把“操作步骤”和“预期结果”设为同一行内的两列，步骤用序号分行书写，预期结果按相同序号对应，避免步骤与判断依据错位。用例数量较多时，可另建一张“步骤明细表”，以用例编号关联，主表只保留摘要信息。
每个字段该填什么：字段说明
字段的含义决定填写口径。下表逐项说明每个字段写什么、怎么写，以及容易写偏的地方。
| 字段 | 填写内容 | 填写口径与常见写法 |
|---|---|---|
| 用例编号 | 用例的唯一标识 | 建议采用“模块缩写-序号”的形式，如 LOGIN-001，便于检索和引用。编号一经分配不随意复用，用例废弃后保留编号并标注状态。 |
| 用例标题 | 一句话说明这条用例验证什么 | 写成可判断的测试点，包含对象、条件和预期方向，如“正确账号密码登录后跳转首页”。避免只写“登录测试”“登录功能”这类笼统功能名，标题本身应能让人判断通过与否。 |
| 所属模块 | 用例归属的功能或业务模块 | 与需求结构或产品功能划分保持一致，如“登录”“订单支付”。模块名统一后，后续按模块筛选和统计才有意义。 |
| 前置条件 | 执行前系统或数据必须处于的状态 | 写清必要且充分的条件，如“已存在状态正常的注册用户”“用户未登录”。与步骤无关的环境描述不必写入，避免把操作动作混进前置条件。 |
| 测试数据 | 本用例使用的具体输入值 | 给出可直接使用的值，如账号、密码、金额、文件类型。涉及边界值时写明取值依据，如“密码长度 8 位（最小允许值）”。数据较多时可引用数据表编号。 |
| 操作步骤 | 按顺序编号的动作 | 一步一个动作，写用户或系统实际执行的操作，如“1. 打开登录页；2. 输入账号与密码；3. 点击登录按钮”。步骤粒度以执行者无需猜测为准，避免把多个动作压进一步。 |
| 预期结果 | 与步骤对应的可观察判断依据 | 按步骤序号逐条对应，写界面变化、提示文案、数据状态或接口返回，如“3. 页面跳转至首页，右上角显示当前用户名”。判断依据要可观察、可核对，避免“正常”“正确”这类无法验证的表述。 |
| 优先级 | 执行顺序的重要程度 | 常用高、中、低三档。核心主流程、高频操作、涉及资金或权限的用例设为高；异常分支和边缘场景可设中或低。分档标准由团队统一，避免同一类用例在不同人手里档位不一。 |
| 用例类型 | 用例覆盖的测试意图 | 常见取值包括功能验证、边界值、异常处理、权限校验、兼容性等。类型用于统计覆盖情况，取值集合应固定，不临时新增同义项。 |
| 关联需求 | 用例对应的需求或任务标识 | 填写需求编号或标题，便于需求变更时定位受影响的用例。没有明确需求来源的探索性用例可留空并在备注说明。 |
| 备注 | 补充说明 | 记录执行注意事项、已知缺陷、依赖环境等。备注不承担核心判断信息，关键条件仍应写进前置条件或预期结果。 |
步骤与预期结果的一一对应是这张表最容易出问题的地方。推荐做法是两边使用同一套序号：步骤写 1、2、3，预期结果也写 1、2、3，某一步没有独立判断依据时写“无变化”或并入相邻步骤，不留空号。这样执行者可以逐步核对，缺陷定位也能直接指向具体步骤。
标题的写法值得单独强调。“登录测试”无法判断通过与否，“正确账号密码登录后跳转首页并显示用户名”则给出了对象、条件和预期方向。标题写清楚，评审时能快速发现遗漏，执行时也能减少对步骤的反复阅读。
必填与选填：哪些字段不能空
字段全部填写会显著增加维护成本，全部选填又会让用例无法执行。比较稳妥的做法是先固定一组必填字段作为底线，其余字段按项目阶段和用例风险按需补充。
| 字段 | 建议属性 | 缺失时的后果 |
|---|---|---|
| 用例编号 | 必填 | 无法唯一引用，缺陷、评审意见和执行记录失去锚点 |
| 用例标题 | 必填 | 无法快速判断用例意图，评审和检索效率下降 |
| 所属模块 | 必填 | 无法按功能筛选和统计覆盖情况 |
| 前置条件 | 必填 | 执行者可能从错误状态开始，结果不可复现 |
| 操作步骤 | 必填 | 用例无法执行 |
| 预期结果 | 必填 | 无法判断通过与否，用例失去验证意义 |
| 优先级 | 必填 | 测试计划排期缺少依据，高风险用例可能被延后 |
| 测试数据 | 按需必填 | 步骤涉及具体输入值时必填，纯界面检查类用例可留空 |
| 用例类型 | 选填 | 影响覆盖统计的完整性，不影响单条用例执行 |
| 关联需求 | 选填 | 需求变更时定位受影响用例变慢 |
| 备注 | 选填 | 补充信息缺失，核心内容不受影响 |
字段严格程度可以随项目阶段调整。需求刚确认、用例正在设计时，标题、前置条件、步骤和预期结果是必须写全的部分，优先级和关联需求可以稍后补齐；进入测试计划排期前，优先级必须确定；用例归档进用例库时，模块和编号需要完整且不重复。团队可以把这条规则写进模板说明，评审时按阶段核对，避免一刀切导致早期设计被字段形式拖慢。
完整填写示例：一条登录用例
下面用一条登录用例演示各字段如何配合。示例为演示情景，用于核对字段前后一致，不代表任何真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 用例编号 | LOGIN-001 |
| 用例标题 | 使用正确账号密码登录后跳转首页并显示用户名 |
| 所属模块 | 登录 |
| 前置条件 | 系统中已存在状态正常的注册用户；当前处于未登录状态；登录页可正常访问 |
| 测试数据 | 账号：demo_user；密码：Demo@1234（符合密码规则的有效值） |
| 操作步骤 | 1. 打开登录页；2. 在账号输入框输入 demo_user；3. 在密码输入框输入 Demo@1234；4. 点击“登录”按钮 |
| 预期结果 | 1. 登录页正常展示账号、密码输入框和登录按钮；2. 账号输入框显示 demo_user；3. 密码输入框以掩码形式显示输入内容；4. 登录成功，页面跳转至首页，右上角显示当前用户名 demo_user |
| 优先级 | 高 |
| 用例类型 | 功能验证 |
| 关联需求 | 用户登录需求（示例编号 REQ-LOGIN-01） |
| 备注 | 执行前确认测试账号未被锁定；若首页加载较慢，以跳转完成为判断时点 |
这条示例体现了几个填写要点。前置条件只描述开始状态，不包含操作动作；测试数据给出可直接使用的具体值，并说明其有效性依据；步骤与预期结果使用同一套序号，第 4 步的判断依据落到可观察的页面跳转和用户名显示上；备注只补充执行注意事项，没有替代核心判断信息。核对时可以反向检查：把预期结果遮住，仅凭标题、前置条件、测试数据和步骤，另一位执行者能否得到相同结果；再把步骤遮住，仅凭预期结果能否判断这条用例验证了什么。两项都成立，字段之间就是一致的。
模板的调整与维护方法
模板落地后需要随项目变化调整，否则会出现字段越加越多、填写口径各行其是的情况。调整时可以从新增字段的判断标准、命名与取值统一、评审与版本更新、以及与执行记录的衔接四个方面入手。
新增字段前先问三个问题：这个信息是否每条用例都需要，还是只对少数用例有意义；它能否从已有字段推导出来；缺失它是否会导致执行或判断出错。只有“多数用例需要且无法推导”的字段才值得进入主表，其余信息放进备注或按需扩展。例如“测试环境”在多数团队中只对部分用例有意义，放在备注或执行记录里更合适。
字段命名和取值口径需要统一维护。优先级固定为高、中、低三档并写明各档含义；用例类型维护一份固定取值清单，新增类型时同步更新说明；模块名称与需求结构对齐，避免同一功能出现多个叫法。这些约定写进模板说明文档，比口头传达更稳定。
模板本身也应纳入评审。新项目启动、需求结构发生较大调整、或连续多次评审发现同类填写问题时，是用例模板更新的合适时机。更新后保留版本号和变更说明，让已有用例知道按哪一版口径填写。模板评审可以和执行用例评审合并进行，重点检查必填字段是否齐全、步骤与预期结果是否对应、标题是否可判断。
模板还要与用例评审和执行记录衔接。评审意见需要能定位到具体用例和字段，执行结果需要能回填到用例上，缺陷需要能追溯到对应用例编号。在协作工具中承载这套字段时，可以把用例编号、标题、模块、前置条件、步骤、预期结果、优先级等设为固定属性，评审状态和执行结果作为独立状态记录。ONES TestCase 支持编写测试用例、组织用例库，并支持用例与产品需求、研发任务关联；用例属性可按业务场景自定义，用例可从 Excel 批量导入并导出备份。团队可以据此把上面这张表的字段映射到工具中，让模板口径和评审、执行记录保持在同一处，减少表格与工具两套内容不一致的情况。具体字段类型和必填约束以实际产品配置为准。
常见问题
用例标题已经写清楚了，前置条件可以简写或省略吗？
不建议省略。标题说明这条用例验证什么，前置条件说明从什么状态开始，两者承担不同信息。缺少前置条件时，执行者可能从错误状态开始操作，结果无法复现，缺陷也难以定位。写法上只保留开始状态，例如“已存在状态正常的注册用户；当前未登录”，把打开页面、输入账号这类动作留给操作步骤。
一条用例里包含多个验证点时，步骤和预期结果怎么对应？
推荐拆成多条用例，每条聚焦一个可判断的验证点，标题和预期结果都能独立判断通过与否。如果确实需要放在一条用例中，步骤与预期结果仍使用同一套序号逐条对应，某一步没有独立判断依据时写“无变化”或并入相邻步骤，不留空号。验证点过多会让缺陷定位变模糊，评审时也容易漏看。
团队用表格维护用例，和放进测试管理工具相比，字段口径怎么保持一致？
关键是让表格和工具共用一套字段定义。可以先把用例编号、标题、模块、前置条件、步骤、预期结果、优先级等固定为必填属性，再把表格中的列与工具字段一一映射。ONES TestCase 支持编写测试用例、组织用例库，用例属性可按业务场景自定义，并支持从 Excel 批量导入与导出备份，团队可据此把模板字段迁移到工具中，减少两套内容不一致的情况。具体字段类型和必填约束以实际产品配置为准。
项目早期用例还在设计中，优先级和关联需求可以先空着吗？
可以按阶段放宽。需求刚确认、用例正在设计时，标题、前置条件、步骤和预期结果是必须写全的部分；进入测试计划排期前，优先级必须确定，否则排期缺少依据；用例归档进用例库时，模块和编号需要完整且不重复。把这条分阶段规则写进模板说明，评审时按阶段核对，能避免早期设计被字段形式拖慢。
模板用了一段时间，字段越加越多，怎么判断哪些该保留？
新增字段前先确认三点：多数用例是否都需要它，它能否从已有字段推导出来，缺失它是否会导致执行或判断出错。只有“多数用例需要且无法推导”的字段才进入主表，其余信息放进备注或按需扩展。同时固定优先级档位和用例类型取值清单，模块名称与需求结构对齐，并把约定写进模板说明文档，定期在用例评审中检查执行情况。
