测试用例模板：前置条件、步骤与预期结果怎么写

写测试用例时，前置条件要交代执行前必须成立的系统状态、数据、权限和环境；操作步骤按“谁在哪个界面做什么”逐条编号，一步一个动作；预期结果与步骤编号对应，写成可观察、可判定的界面反馈、数据变化或状态流转。下面给出一份可直接复制的空白模板，逐字段说明填写口径，并用一条登录用例示范三项核心字段如何配合。

要点总览（TL;DR）

• 测试用例模板至少包含用例编号、标题、所属模块、优先级、前置条件、操作步骤、预期结果、实际结果、测试结论、备注十个字段，步骤多时用步骤子表按编号逐行对应。
• 前置条件写执行前必须成立的系统状态、测试数据、账号权限和环境配置，用陈述句，不写操作动作。
• 操作步骤一步一个动作，写清操作入口、操作对象和输入内容；预期结果与步骤编号对应，写成可观察的界面反馈、数据变化或状态流转。
• 用例编号、标题、所属模块、前置条件、操作步骤、预期结果建议设为必填，实际结果与测试结论在执行阶段填写，备注按需补充。
• 模板按项目类型裁剪字段，先在小范围试用一到两个迭代再推广，字段变更纳入版本管理，并与用例库编号规则和需求变更保持同步。

可直接复制的测试用例空白模板

下面的表格可以直接复制到 Excel、在线文档或测试管理工具中作为单条用例的填写结构。表头一行固定，每条用例占一行；如果步骤较多，可把“操作步骤”和“预期结果”拆成独立子表，按步骤编号逐行填写，主表保留用例级信息。

用例编号	用例标题	所属模块	优先级	前置条件	操作步骤	预期结果	实际结果	测试结论	备注

步骤与预期结果较多时，建议在主表下方附一张步骤子表，两列编号保持一致，执行时逐行勾对：

步骤编号	操作步骤	预期结果	实际结果	是否通过
1
2
3

复制使用时注意三点：表头文字保持统一，避免同一团队出现“预期结果”和“期望结果”两种叫法；用例编号在复制后重新分配，保证库内唯一；空白行按实际用例条数增删，不要把多条互不相关的用例塞进同一行。

模板字段说明：每个字段填什么

十个字段各自承担不同信息，填写时按下面的口径对齐，模板、说明和示例才能保持一致。

字段	填写内容	填写口径
用例编号	唯一标识	按“模块缩写-序号”编制，如 LOGIN-001，全库不重复，便于引用和缺陷关联
用例标题	一句话说明验证什么	采用“场景+条件+预期”的短句，如“正确账号密码登录成功”，避免只写“登录测试”
所属模块	功能归属	与需求或产品功能目录一致，便于按模块筛选和执行
优先级	执行顺序依据	按业务影响和发生概率分级，常用高、中、低三档，核心主流程为高
前置条件	执行前必须成立的状态	写系统状态、测试数据、账号权限、环境配置，不写操作动作
操作步骤	执行动作序列	逐条编号，一步一个动作，写清操作入口、操作对象和输入内容
预期结果	可判定的正确表现	与步骤编号对应，写界面反馈、数据变化或状态流转，能被观察和判断
实际结果	执行时的真实表现	执行后填写，与预期不一致时记录具体差异，不写“同上”
测试结论	本条用例的判定	填通过、不通过或阻塞，阻塞时在备注说明原因
备注	补充信息	记录关联需求、缺陷编号、数据清理要求或特殊说明

必填与选填：哪些字段不能空

用例进入执行和回归环节后，缺失字段会直接抬高沟通成本。建议把用例编号、标题、所属模块、前置条件、操作步骤、预期结果六项设为必填，其余四项按团队流程决定。

• 必填的理由：编号保证可追溯；标题和模块决定能否被检索和分组；前置条件、步骤、预期结果构成用例的可执行主体，缺任何一项，执行人都需要回头找人确认。
• 优先级：建议必填。它决定冒烟和回归时的执行顺序，缺失会导致关键路径被漏测；若团队统一按模块默认优先级，可在模板中预置默认值。
• 实际结果与测试结论：设计阶段可留空，执行阶段必须填写。留空意味着这条用例没有被真正执行过，回归统计时无法区分“未执行”和“通过”。
• 备注：选填。适用于记录关联需求编号、依赖的其他用例、测试数据清理方式等，没有补充信息时留空即可。

字段缺失的影响在回归阶段最明显：前置条件缺失，换人执行时环境准备反复试错；预期结果缺失，执行人只能凭经验判断对错，结论不可复核；编号缺失，缺陷单无法准确指向对应用例。团队可以在模板中把必填项标星，并在评审时逐项检查。

前置条件、步骤与预期结果的写法规范

这三项决定用例能否被另一个人独立执行。共同原则是：前置条件写“已经是什么样”，步骤写“做了什么”，预期结果写“应该看到什么”，三者不混写。

前置条件：写状态、数据、权限、环境

前置条件描述执行开始前系统应处于的状态，用陈述句，不出现操作动词。可以从四个维度检查：系统状态（如已登录、购物车非空）、测试数据（如已存在一个待审核订单）、账号权限（如使用具备审批权限的账号）、环境配置（如测试环境已开启短信模拟）。

操作步骤：一步一动作，含入口与对象

每一步只写一个动作，按“在哪个界面—对哪个对象—做什么操作—输入什么”组织。涉及输入的步骤写明具体数据，涉及跳转的步骤写明目标页面。避免把“打开页面并输入账号密码后点击登录”压成一步，执行人无法判断中途哪一环出错。

预期结果：可观察、可判定、与步骤对应

预期结果要写成执行人能直接比对的现象：页面提示文字、字段值变化、列表新增记录、状态从待审核变为已审核、收到通知等。避免“正常显示”“功能可用”这类无法判定的表述。步骤与预期结果按编号一一对应；一个步骤产生多个可观察结果时，在同一编号下分行列出。

字段	反例	改法
前置条件	先登录系统，再进入订单页	已使用具备订单查看权限的账号登录；系统中存在至少一条待审核订单
操作步骤	打开订单页输入条件查询并审核	1. 进入“订单管理-待审核”页；2. 在订单号输入框输入“DD2024001”；3. 点击“查询”；4. 点击目标订单行的“审核”按钮
预期结果	查询正常，审核成功	步骤3：列表仅显示订单号 DD2024001 的记录，共1条；步骤4：页面提示“审核成功”，该订单状态变为“已审核”，从待审核列表移除

完整填写示例：一条登录用例

以下为演示情景，用于说明各字段如何协同填写，数据为虚构。步骤子表与主表编号对应，执行时按行核对。

字段	填写内容
用例编号	LOGIN-001
用例标题	已注册用户使用正确账号密码登录成功
所属模块	用户中心-登录
优先级	高
前置条件	测试环境可访问登录页；已存在账号 test_user01，密码为初始密码且账号状态为正常；该账号未处于锁定状态
操作步骤	见下方步骤子表
预期结果	见下方步骤子表，与步骤编号对应
实际结果	执行后填写
测试结论	执行后填写
备注	关联需求 REQ-1024；执行后清理登录日志

步骤编号	操作步骤	预期结果
1	在浏览器打开登录页	登录页正常加载，显示账号输入框、密码输入框和“登录”按钮
2	在账号输入框输入 test_user01	输入框显示 test_user01，无报错提示
3	在密码输入框输入正确密码	密码以掩码形式显示
4	点击“登录”按钮	页面跳转至工作台首页，右上角显示当前账号 test_user01；登录日志新增一条成功记录

这条示例体现了三项字段的对应关系：前置条件交代了账号存在且状态正常，步骤2和步骤3的输入才有意义；步骤4的预期结果同时包含界面跳转、账号显示和数据记录三类可观察现象，执行人不需要额外询问就能判定通过与否。

模板的调整与维护方法

模板要在团队里长期使用，需要按项目特点裁剪字段，并建立固定的评审和更新节奏。

按项目类型增减字段

接口类项目可在步骤中增加“请求方法与入参”列，预期结果增加“响应码与返回字段”；移动端项目可增加“设备型号与系统版本”作为前置条件的一部分；探索性测试为主的团队可弱化步骤列，保留前置条件和预期结果，把操作空间留给执行人。增减字段的原则是：新增字段必须有人填写并在执行中用到，否则会在几轮之后变成空列。

评审与版本更新

新模板先在一条业务线上试用一到两个迭代，收集执行人反馈后再全团队推广。模板本身纳入版本管理，字段增删、叫法变更记录变更说明和生效时间；旧用例在下次修改时逐步对齐新模板，不做一次性批量改写，避免引入录入错误。

与用例库和需求变更同步

用例编号规则、模块划分应与用例库的组织方式一致，需求变更导致流程调整时，同步更新受影响的用例，并在备注中记录变更来源。用例编写完成后通常还要经过评审、分配执行和缺陷流转，这些环节如果散落在文档和聊天工具里，字段再规范也难以追踪。ONES 测试管理支持编写测试用例、组织用例库，并可将用例与需求、任务关联，测试计划与迭代关联；用例模块支持树状结构和拖拽排序，用例属性可自定义并支持筛选，未通过的用例可快速创建缺陷任务在测试与研发团队间流转。团队可以按本文模板确定字段口径，再把这些字段落到用例属性中，让前置条件、步骤和预期结果随需求与执行记录一起留存。

常见问题

前置条件里能不能写操作动作，比如“先登录系统”？

不建议。前置条件描述的是执行开始前系统已经处于的状态，写成“已使用具备订单查看权限的账号登录”比“先登录系统”更清楚，执行人一眼就能判断当前环境是否满足。操作动作放到步骤里，前置条件只保留状态、数据、权限和环境四类信息。如果某条用例的前置条件本身需要一系列准备操作，可以把准备过程单独写成一条准备用例，或在备注中说明准备方式。

一个步骤对应多个可观察结果时，预期结果怎么编号？

保持与步骤相同的编号，在同一编号下分行列出多个结果。例如步骤4“点击登录按钮”对应“页面跳转至工作台首页”“右上角显示当前账号”“登录日志新增一条成功记录”三条，都归在步骤4下。这样执行时按编号逐行核对，出现差异也能定位到具体是哪一步的哪个结果不符合预期，缺陷单描述会更准确。

团队用例字段不统一，模板推广时先做什么？

先统一字段名称和必填范围，再谈工具落地。常见问题是同一团队里“预期结果”和“期望结果”并存、优先级有的用数字有的用文字，导致筛选和统计失真。做法是确定一版字段口径，把必填项在模板中标注，选一条业务线试用一到两个迭代，收集执行人的实际填写反馈后再全团队推广。字段增删记录变更说明和生效时间，旧用例在下次修改时逐步对齐，不做一次性批量改写。

用例写完后要经过评审和执行，模板字段怎么和工具里的记录衔接？

模板确定的是字段口径，工具负责让这些字段随需求、执行记录和缺陷一起留存。以 ONES 为例，测试管理支持编写测试用例、组织用例库，用例属性可自定义并支持筛选，用例模块支持树状结构和拖拽排序；用例可与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务在测试与研发团队间流转。团队可以按本文模板确定字段，再把这些字段落到用例属性中，减少文档与执行记录两套口径的情况。

接口测试或移动端测试的用例，模板字段需要改吗？

按项目特点增减即可，不必推翻主表。接口类项目可在步骤子表增加“请求方法与入参”列，预期结果增加“响应码与返回字段”；移动端项目可把“设备型号与系统版本”并入前置条件。增减的原则是新增字段必须有人填写并在执行中真正用到，否则几轮之后就会变成空列。探索性测试为主的团队可以弱化步骤列，保留前置条件和预期结果，把操作空间留给执行人。