测试用例编写从测试分析开始：先把需求拆成可验证的测试点，再选用等价类、边界值、决策表等方法设计用例，按统一字段写成可执行条目，经评审定稿后分类维护。本文按这一路径给出步骤、字段规范、角色分工、完整示例和评审检查清单，帮助团队把用例写成可执行、可追溯、可维护的资产。
要点总览（TL;DR）
- 测试用例编写从测试分析开始：先把需求拆成可验证的测试点，再按等价类、边界值、决策表等方法展开为具体用例。
- 一条用例至少包含编号、标题、模块、优先级、前置条件、步骤和预期结果，标题写清条件与结果，预期结果要能直接判断通过与否。
- 用例初稿完成后安排正式评审，重点查覆盖度、可执行性、一致性和可维护性，问题关闭后形成基线。
- 定稿后按模块、优先级、类型分类，需求变更时更新对应用例，废弃用例标记保留，每次定稿登记版本与变更说明。
- 收尾前用完成检查表核对覆盖度、字段完整性、评审状态和维护责任，四项都满足再进入测试计划。
测试用例编写的核心步骤
用例编写是一项有输入、有产出的设计工作。把流程拆成四步，每一步都有明确的完成标志，可以避免“拿到需求就写步骤”导致的覆盖遗漏和返工。
第一步：测试分析与测试点拆解
输入是需求文档、原型、接口说明和业务规则。动作是逐条阅读需求，识别功能点、输入项、业务规则、状态流转和异常分支，把每条需求拆成若干“可被验证的测试点”。测试点用一句话描述要验证什么，例如“手机号为空时提交被拒绝”。输出是一份测试点清单，每个测试点标注来源需求编号。完成标志是需求中的每条规则都能在清单中找到对应测试点，且没有无法追溯到需求的测试点。
第二步：选择设计方法
测试点确定后，按输入和规则的形态选择方法，把测试点展开为具体用例：
- 等价类划分：输入有取值范围或类型限制时，把输入划分为有效等价类和无效等价类，每类取代表值。适用于输入框、参数校验类需求。
- 边界值分析：输入有明确上下限时，取边界值及其两侧的值，如长度限制 1–20 位，取 0、1、20、21 四个值。等价类通常与边界值配合使用。
- 决策表：多个条件组合决定不同结果时，列出条件桩与动作桩，逐列覆盖条件组合。适用于优惠规则、权限判断、审批分支等业务逻辑。
- 场景法：业务流程有主流程和分支流程时，按基本流与备选流设计端到端用例。
- 状态迁移：对象有明确状态和迁移条件时，覆盖合法迁移与非法迁移。
输出是每个测试点对应的用例设计说明，注明所用方法和覆盖的取值。完成标志是每个测试点至少有一种方法支撑，且方法选择能解释清楚。
第三步：按统一字段编写用例
输入是测试点清单和设计说明。动作是按团队统一的字段结构逐条填写用例，字段要求见下一节。输出是一批格式一致的用例条目。完成标志是每条用例都能被未参与设计的人独立执行。
第四步：用例评审与定稿
输入是用例初稿。动作是组织评审，检查覆盖度、可执行性和一致性，记录问题并修改。输出是评审通过的用例基线。完成标志是评审问题全部关闭，用例状态标记为已定稿。评审的具体检查项在第五节展开。
用例字段与编写规范
字段统一是用例可执行、可评审的前提。下表给出一套常用字段结构，团队可在此基础上增删，但必填项应保持一致。
| 字段 | 必填 | 填写要求 |
|---|---|---|
| 用例编号 | 是 | 按“模块缩写-序号”规则生成，全局唯一，定稿后不随意变更 |
| 用例标题 | 是 | 一句话说明验证什么，采用“条件+动作+结果”结构，如“手机号为空时提交订单提示必填” |
| 所属模块 | 是 | 对应功能模块或需求编号，便于分类检索 |
| 优先级 | 是 | 按业务影响和发生概率分级，如 P0 核心主流程、P1 重要分支、P2 一般场景、P3 边缘场景 |
| 前置条件 | 是 | 执行前必须满足的环境、数据和账号状态，写具体，如“已登录普通用户，购物车有 1 件库存充足商品” |
| 操作步骤 | 是 | 按顺序编号，每步一个动作，包含具体输入值，不写“进行相关操作”这类模糊描述 |
| 预期结果 | 是 | 与步骤对应，写可观察、可判断的结果，如页面提示文案、数据变化、接口返回码 |
| 用例类型 | 否 | 功能、接口、兼容性、性能等，用于分类统计 |
| 关联需求 | 否 | 需求编号或链接，用于追溯 |
| 备注 | 否 | 测试数据说明、依赖环境、已知限制等 |
标题与步骤的写法直接影响执行效率。标题应让读者不看步骤就知道验证点，避免“测试登录功能”这类无法判断范围的写法。步骤要写到操作层面，输入值直接给出，例如“在手机号输入框输入 13800000000”，而不是“输入合法手机号”。
预期结果必须可验证。判断标准是执行人能否仅凭描述得出“通过或不通过”的结论。“系统正常处理”不可验证，“页面跳转至订单确认页，订单金额显示 99.00 元”可验证。涉及数据变化时，写明在哪个页面或接口观察什么字段。
必填字段缺失的用例不进入评审。选填字段按项目需要填写，但同一项目内口径应一致，避免同一字段在不同用例中含义不同。
角色分工与交付物
用例从分析到维护涉及多个角色，职责不清容易出现“需求理解偏差无人纠正、评审走过场”的问题。下表给出常见分工，团队规模较小时可一人兼多角，但评审环节建议保留独立视角。
| 环节 | 主要负责角色 | 参与角色 | 交付物 |
|---|---|---|---|
| 测试分析 | 测试设计者 | 产品经理、开发 | 测试点清单，标注需求来源 |
| 用例编写 | 测试设计者 | — | 用例初稿 |
| 用例评审 | 测试负责人组织 | 产品经理、开发、其他测试人员 | 评审记录与问题清单 |
| 定稿与入库 | 测试设计者 | 测试负责人确认 | 评审通过的用例基线 |
| 维护更新 | 用例归属模块的测试设计者 | 产品经理提供变更信息 | 更新后的用例与变更记录 |
产品经理在分析与评审环节的职责是确认业务规则理解正确、补充需求中未写明的约束；开发人员的职责是确认技术实现相关的边界和异常分支，例如接口对特殊字符的处理。测试负责人的职责是组织评审、把控通过标准、确认用例基线。交接的关键节点有两个：测试点清单确认后进入编写，评审问题关闭后进入定稿。
当用例需要与需求、研发任务保持对应关系时，可以把用例挂在需求条目下管理。ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，用例状态和需求变更可以在同一流程中查看，减少靠表格手工同步的环节。
编写示例：一个功能模块的用例
以下为演示情景，用于说明从测试点到完整用例的编写过程，不代表真实项目数据。
示例需求：用户提交订单时填写收货手机号，手机号为 11 位数字，必填；格式错误时提示“请输入正确的手机号”，为空时提示“手机号不能为空”；格式正确时进入支付页。
测试点拆解：①手机号为空提交；②手机号位数不足或超出；③手机号含非数字字符；④手机号格式正确提交成功；⑤提示文案与需求一致。
方法选择：测试点①②③④用等价类与边界值，输入长度取 0、10、11、12 位；测试点⑤随各用例的预期结果一并验证。
用例条目示例：
| 字段 | 用例 1 | 用例 2 | 用例 3 |
|---|---|---|---|
| 用例编号 | ORDER-001 | ORDER-002 | ORDER-003 |
| 标题 | 手机号为空时提交订单提示必填 | 手机号为 10 位时提交订单提示格式错误 | 手机号为 11 位数字时提交订单进入支付页 |
| 优先级 | P1 | P1 | P0 |
| 前置条件 | 已登录用户，购物车有 1 件库存充足商品，进入订单确认页 | 同左 | 同左 |
| 操作步骤 | 1. 手机号输入框留空；2. 点击“提交订单” | 1. 手机号输入框输入 1380000000；2. 点击“提交订单” | 1. 手机号输入框输入 13800000000；2. 点击“提交订单” |
| 预期结果 | 页面提示“手机号不能为空”，停留在订单确认页，不生成订单 | 页面提示“请输入正确的手机号”，停留在订单确认页，不生成订单 | 跳转至支付页，订单列表新增 1 条待支付订单，金额与购物车一致 |
| 关联需求 | REQ-ORDER-012 | REQ-ORDER-012 | REQ-ORDER-012 |
这组用例体现了几个要点：标题直接说明条件和结果；步骤给出具体输入值；预期结果包含提示文案、页面状态和数据变化，执行人可独立判断通过与否；优先级按主流程与异常分支区分。按同样方式补齐 12 位、含字母、含空格等用例，即可覆盖该测试点的全部等价类与边界。
用例评审与质量检查
评审的目的不是走形式签字，而是在用例进入执行前发现覆盖遗漏和不可执行的描述。建议在用例初稿完成后、进入测试计划前安排一次正式评审；需求变更后新增的用例，可在小范围内做增量评审。
评审方式上，小批量用例适合会议逐条过，大批量用例可先由评审人按检查清单预审并标注问题，再集中讨论分歧项。评审记录应保留问题、责任人和关闭状态。
| 检查维度 | 检查项 | 不通过的表现 |
|---|---|---|
| 覆盖度 | 每条需求规则都有对应用例；有效与无效等价类均有覆盖；边界值取到上下限及两侧；业务规则组合用决策表核对无遗漏 | 只写正向用例，异常分支缺失；边界值只取中间值 |
| 可执行性 | 前置条件具体；步骤含输入值；预期结果可观察、可判断 | 出现“正常操作”“结果正确”等无法判断的描述 |
| 一致性 | 字段填写完整；编号规则统一；同类场景的写法口径一致 | 同一字段在不同用例中含义不同；必填项空缺 |
| 可维护性 | 用例与需求关联；单条用例只验证一个主要测试点；步骤不依赖其他用例的执行结果 | 一条用例串联多个不相关验证点，失败后无法定位 |
通过标准建议设为：覆盖度检查无遗漏项，可执行性问题全部关闭，必填字段完整，评审记录中的问题状态为已关闭。出现以下情况应返工：核心业务规则缺少用例、预期结果无法判断、用例之间前置条件冲突。返工后由原评审人复核，复核通过方可定稿。
用例分类、维护与版本管理
用例定稿后进入长期使用阶段，分类和维护规则决定了它能否被快速找到并持续可用。
分类规则：按模块建立层级目录，与产品功能结构对应；在模块内按优先级标注 P0–P3，便于按测试计划选取；按用例类型（功能、接口、兼容性等）打标签，支持跨模块筛选。分类维度不宜过多，两到三个维度即可，避免维护成本超过收益。ONES TestCase 的用例模块支持树状结构与拖拽排序，可用于按模块分层组织用例；用例属性支持自定义，便于按团队口径补充分类字段。
需求变更时的更新：需求评审通过后，由用例归属模块的测试设计者判断影响范围，更新对应用例的前置条件、步骤或预期结果，并补充新增规则的用例。失效用例标记为废弃而非直接删除，保留追溯依据。更新完成后在评审记录中登记变更原因和影响用例编号。
版本与历史记录：每次定稿形成一次基线，基线包含用例编号、版本号和变更说明。执行阶段发现的用例问题，回到用例库修改并记录，避免只改执行记录不改用例。团队使用工具管理时，应确认工具是否提供用例变更历史；若现有工具不记录版本，可用变更登记表补充，登记字段包括用例编号、变更日期、变更人、变更内容和原因。
用例数量较大时，导入导出能力影响维护效率。ONES TestCase 支持从 Excel 批量导入用例并在线管理，也支持导出与本地备份，适合在迁移存量用例或定期归档时使用；导入前需按模板整理数据。跨项目的用例资产复用不在本文范围，需要时另行规划用例库的共享机制。
完成检查
用例编写工作收尾前，按以下清单逐项核对，全部满足即可认为本批用例达到交付标准。
| 检查项 | 核对方法 | 通过标准 |
|---|---|---|
| 覆盖度达标 | 对照测试点清单和需求规则逐条核对 | 每条需求规则至少一条用例；有效、无效等价类与边界值均有覆盖；决策表组合无遗漏 |
| 字段完整 | 按字段表检查必填项 | 编号、标题、模块、优先级、前置条件、步骤、预期结果无空缺 |
| 可执行 | 抽取部分用例由未参与编写的人试执行 | 执行人能独立判断通过与否，无需口头补充说明 |
| 评审通过 | 查看评审记录 | 问题全部关闭，用例状态为已定稿，基线已登记 |
| 维护责任落实 | 确认每个模块的用例归属人 | 模块有明确负责人；变更登记方式已约定；废弃用例已标记 |
核对中发现覆盖缺口或字段缺失，回到对应步骤补充后重新核对；评审未通过的批次不进入测试计划。完成检查的结果建议随用例基线一并记录，便于后续追溯本批用例的编写质量。
常见问题
需求文档写得不细，测试点拆不全怎么办？
先按已有需求拆出能确认的测试点，把不确定的地方整理成问题清单，在测试分析阶段与产品经理逐条确认，重点问清业务规则的边界、异常分支和状态流转条件。确认结果补进测试点清单并标注需求来源。需求本身缺失的约束，不要用猜测填进用例，先记录为待确认项，等需求补充后再展开对应用例。
用例评审要所有人都参加吗，人少的时候怎么安排？
评审的价值在于引入独立视角，不必所有角色全程参加。常规做法是测试负责人组织，产品经理确认业务规则，开发确认技术边界和异常分支，其他测试人员检查覆盖度和可执行性。团队规模小时可以一人兼多角，但建议至少保留一名未参与编写的测试人员做交叉检查。用例批量较大时，先由评审人按检查清单预审标注问题，再集中讨论分歧项，比逐条开会更省时间。
用例定稿后需求又变了，旧用例怎么处理？
需求变更确认后，由该模块的用例负责人判断影响范围：受影响的用例更新前置条件、步骤或预期结果，新增规则补充新用例，完全失效的用例标记为废弃而不是直接删除，保留追溯依据。更新完成后登记变更原因和涉及的用例编号。执行阶段发现用例本身有问题，回到用例库修改，避免只改执行记录不改用例，否则下一轮执行还会踩同一个坑。
用例数量很多，怎么保证维护不失控？
控制分类维度是关键，按模块建层级目录，再叠加优先级和用例类型两个维度即可，维度越多维护成本越高。每条用例只验证一个主要测试点，步骤不依赖其他用例的执行结果，这样单条变更的影响范围可控。定期清理长期未执行且已废弃的用例，保留基线记录。存量用例迁移或归档时，可以借助批量导入导出能力减少手工整理，导入前按模板统一字段口径。
怎么判断一批用例已经可以交付执行？
看四个条件：需求规则逐条有对应用例，有效与无效等价类、边界值都覆盖到；必填字段无空缺；评审问题全部关闭且用例状态为已定稿；每个模块有明确的维护负责人和变更登记方式。可以抽取部分用例交给未参与编写的人试执行，执行人能独立判断通过与否，说明可执行性达标。四项都满足再进入测试计划，有缺口就回到对应步骤补充后重新核对。
