测试用例编写模板：必要字段与前置条件、步骤、预期结果写法

2026年11月6日

测试用例编写模板至少应包含用例编号、用例标题、所属模块/需求、优先级、用例类型、前置条件、操作步骤、预期结果、测试数据、实际结果与结论、备注/关联缺陷这些字段。其中编号、标题、前置条件、步骤、预期结果属于必填；优先级、类型、测试数据、备注可按团队成熟度设为选填。前置条件写“执行前系统与数据必须处于什么状态”，步骤写“谁在哪个界面做什么操作”，预期结果写“可观察、可判断的界面反馈或数据变化”，三者逐条编号、一一对应。下面先给一张可直接复制的空白表，再逐项说明字段含义、划分必填与选填，并用一条完整用例示范写法。

Table of Contents

要点总览（TL;DR）

测试用例编写模板至少包含11个字段：用例编号、用例标题、所属模块/需求、优先级、用例类型、前置条件、操作步骤、预期结果、测试数据、实际结果与结论、备注/关联缺陷。
编号、标题、前置条件、步骤、预期结果属于必填；优先级、类型、测试数据、备注可按团队成熟度设为选填，所属模块/需求建议进入共享用例库前补齐。
前置条件只写执行前必须成立的状态，步骤按“谁在哪个界面做什么”逐条编号，预期结果与步骤编号一一对应并落到可观察的界面反馈或数据变化。
模板随项目演进增删字段，调整前先小范围试用，评审后记录版本号、变更字段和生效范围，旧用例保留原字段值。
用例数量增长后，字段需要落到测试管理工具中承载，编号、所属需求、执行结论与缺陷关联可在同一条记录上闭环。

可复制空白测试用例模板

下表是可直接复制到文档或表格工具中的空白用例表。表头字段与后文说明、示例保持一致，填写时一行对应一条用例。如果团队使用在线测试管理工具，可以按这张表的字段顺序建立自定义属性，再批量导入。

用例编号	用例标题	所属模块/需求	优先级	用例类型	前置条件	操作步骤	预期结果	测试数据	实际结果与结论	备注/关联缺陷

复制时保留表头，按项目需要增加空白行即可。步骤和预期结果在单元格内用“1. 2. 3.”分行编号，编号与预期结果一一对应，便于执行时逐条勾对。

模板字段逐项说明

字段说明解决“这一格填什么、谁来填、填到什么程度算合格”。下表按填写责任角色和判断标准逐项说明，其中“对应关系”一列提示该字段与其他字段的联动要求。

字段	含义	填写责任角色	判断标准	对应关系
用例编号	用例的唯一标识，便于引用、评审和缺陷回溯	用例编写者	全库唯一，编号规则稳定，如“模块缩写-序号”	缺陷记录、测试报告中引用此编号
用例标题	一句话说明验证什么场景和结果	用例编写者	包含对象、动作和关键条件，读标题即可判断测试点	与所属模块、步骤内容一致
所属模块/需求	用例归属的功能模块或需求条目	用例编写者，需求信息由产品/需求负责人提供	能定位到具体模块或需求编号	与需求、研发任务建立关联
优先级	执行顺序与回归取舍的依据	测试负责人与用例编写者共同确定	按业务影响和失败概率分级，如高/中/低	与用例类型共同决定回归范围
用例类型	区分功能、边界、异常、兼容、性能等类别	用例编写者	取值来自团队约定的类型清单	影响测试数据与执行方式的选择
前置条件	执行前系统与数据必须处于的状态	用例编写者	只写必要状态，可由他人按描述复现	与步骤第一条衔接，不重复步骤动作
操作步骤	执行者按顺序完成的操作	用例编写者	写清谁在哪个界面做什么，逐条编号	每条步骤对应一条预期结果
预期结果	步骤执行后可观察、可判断的反馈或数据变化	用例编写者	具体到界面提示、字段值、状态变化，避免“正常”“成功”这类笼统描述	与步骤编号一一对应
测试数据	执行时使用的账号、输入值和数据集	用例编写者，数据由测试环境负责人准备	数据可获取、可重置，敏感数据脱敏	与前置条件和步骤中的输入对应
实际结果与结论	执行时观察到的结果和通过/不通过判定	用例执行者	记录与预期结果的差异，结论明确	不通过时关联缺陷编号
备注/关联缺陷	补充说明、依赖项和缺陷链接	用例编写者与执行者	写清依赖环境、特殊约定或缺陷编号	与用例编号、缺陷记录互相引用

字段之间的核心对应关系有三组：编号与缺陷、报告互相引用；前置条件与步骤第一条衔接；步骤与预期结果逐条编号对应。填写时先写前置条件和步骤，再逐条补预期结果，最后回填测试数据，可以减少遗漏。

必填与选填的划分

必填字段的标准是“缺了它，用例无法被他人独立执行或无法被追溯”。按这个标准，编号、标题、前置条件、步骤、预期结果属于必填；优先级、类型、测试数据、备注/关联缺陷可以按团队成熟度设为选填。所属模块/需求建议在用例进入用例库时必填，用于组织和检索。

字段	建议属性	裁剪条件
用例编号	必填	任何规模团队都应保留，用于追溯
用例标题	必填	无例外
所属模块/需求	建议必填	用例量少、单人维护时可暂缓；进入共享用例库前补齐
前置条件	必填	无前置状态时填“无”，不空置
操作步骤	必填	无例外
预期结果	必填	无例外，且与步骤逐条对应
优先级	选填	用例超过一定数量、需要安排回归顺序时转为必填
用例类型	选填	需要按类型统计覆盖率或分配执行人时转为必填
测试数据	选填	数据简单可现场构造时可省略；涉及多角色、多状态数据时必填
实际结果与结论	执行时必填	设计阶段留空，执行阶段必须填写
备注/关联缺陷	选填	有依赖、特殊约定或缺陷时填写

裁剪时看三个条件：项目风险高低、用例是否跨人执行、是否需要长期回归。高风险项目或多人协作的用例库，建议把优先级和类型也设为必填；探索性较强、生命周期短的用例，可以只保留五个核心必填字段。无论怎么裁剪，步骤与预期结果的逐条对应关系都应保留。

前置条件、步骤与预期结果怎么写：完整填写示例

下面是一条已填写的登录用例，示范三者的写法与对应关系。示例为演示情景，字段取值可按实际系统调整。

字段	填写内容
用例编号	LOGIN-001
用例标题	已注册用户使用正确账号密码登录，进入工作台
所属模块/需求	账号模块 / 需求 REQ-102 登录功能
优先级	高
用例类型	功能
前置条件	1. 测试环境可访问登录页；2. 已存在状态为“正常”的账号 test_user，密码已重置为初始值；3. 该账号未被锁定
操作步骤	1. 打开登录页；2. 在账号输入框输入 test_user；3. 在密码输入框输入初始密码；4. 点击“登录”按钮
预期结果	1. 登录页正常展示账号、密码输入框和登录按钮；2. 账号输入框显示 test_user；3. 密码以掩码显示；4. 页面跳转至工作台，右上角显示当前账号名，登录记录中新增一条成功记录
测试数据	账号 test_user，密码为初始密码（测试环境专用）
实际结果与结论	执行时填写；与预期一致记“通过”，不一致记录差异并关联缺陷
备注/关联缺陷	依赖测试环境账号服务可用

这条示例体现了三个写法要点。前置条件只写执行前必须成立的状态，如账号存在、未被锁定，不写“打开登录页”这类动作。步骤按“谁在哪个界面做什么”逐条编号，颗粒度到一次点击或一次输入，避免把多个动作压进一条。预期结果与步骤编号一一对应，每条都落到可观察的界面反馈或数据变化，例如“密码以掩码显示”“登录记录新增一条成功记录”，执行者据此可以直接判断通过与否。

当用例数量增长、需要多人协作执行时，字段最终要落到测试管理工具中承载。ONES 测试管理支持编写测试用例、组织用例库，并可自定义用例属性以适配不同业务场景；用例可与产品需求、研发任务关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转。若团队已有 Excel 用例表，也支持从 Excel 批量导入后在线管理，并按用例属性筛选查找。这样模板中的编号、所属需求、实际结果与缺陷关联就能在同一条记录上闭环。

模板的调整与维护方法

模板不是一次定稿就长期不变。字段增删应跟着项目变化走，并通过评审和版本记录保证团队用的是同一版模板。以下规则清单可作为维护依据。

字段增删的触发条件：出现同类问题反复漏测时，考虑增加字段，例如多次因环境差异导致误判，可增加“环境/设备”字段；字段长期空置且无人使用，考虑删除或并入备注。新增字段先在小范围试用一轮迭代，再推广。
字段合并与拆分：步骤与预期结果分列导致对应关系难读时，可改为“步骤-预期结果”成对的两列表；测试数据简单时并入前置条件，复杂时独立成列。
模板评审：字段调整由测试负责人发起，邀请用例编写者和执行者参加，重点确认新字段是否有人填、填了是否被使用。评审结论记录变更原因和生效范围。
版本记录：每次调整记录版本号、变更字段、生效日期和适用范围，旧用例保留原字段值，避免历史记录失真。
与用例库的关系边界：模板规定单条用例的字段结构；用例库负责分类组织、检索和复用。跨项目复用、用例库分层建设属于另一项工作，本文不展开，模板调整时只需保证字段能被用例库识别和筛选。
执行反馈回流：每轮测试结束后收集执行者意见，把“填写耗时但判断价值低”的字段列为下次评审的候选调整项。

维护的目标是让模板始终服务于执行和追溯：必填字段保证用例可被独立执行，选填字段按风险逐步补齐，版本记录让字段变化有据可查。按这套规则，团队可以在项目早期用精简模板快速起步，在用例库扩大后逐步增加优先级、类型和关联字段。

常见问题

用例标题和操作步骤有什么区别，标题写多长合适？

标题回答“这条用例验证什么”，步骤回答“怎么验证”。标题用一句话包含对象、动作和关键条件，例如“已注册用户使用正确账号密码登录，进入工作台”，读标题就能判断测试点；步骤则逐条写清在哪个界面做什么操作。标题控制在能区分同类用例的长度即可，具体输入值、点击顺序放在步骤里，避免标题变成步骤摘要。

前置条件里能不能写操作动作，比如“打开登录页”？

前置条件描述执行前系统与数据必须处于的状态，例如账号已存在、未被锁定、测试环境可访问；“打开登录页”属于执行动作，应放进步骤第一条。这样划分的好处是，他人拿到用例后能先核对环境是否满足，再按步骤执行。如果确实没有前置状态，填“无”，不要空置，空置会让执行者无法判断是遗漏还是不需要。

一条用例包含多个步骤时，预期结果必须每条步骤都写吗？

建议逐条对应。步骤与预期结果按相同编号一一对应，执行者每完成一步就能判断该步是否通过，出现失败时也能定位到具体环节。如果多个步骤共享一个最终结果，可以在对应步骤后写明中间可观察的反馈，最后一步写最终状态。把多个动作压进一条步骤、只写一个笼统的最终结果，会增加失败定位的难度。

团队刚开始建用例库，字段能不能先精简？

可以。项目早期或探索性较强的用例，可先保留编号、标题、前置条件、步骤、预期结果五个核心必填字段，优先级、类型、测试数据、备注暂设为选填。当用例数量增长、需要安排回归顺序或按类型统计覆盖率时，再把优先级和类型转为必填；涉及多角色、多状态数据时补上测试数据。无论怎么精简，步骤与预期结果的逐条对应关系都应保留。