制定测试用例编写规范，核心是让团队写出的用例覆盖到位、步骤清楚、预期可判定、后续好维护。做法上先盘点现有用例的常见问题，再确定统一的字段与写法规则，明确设计、评审、维护三类角色的分工，最后用一个真实需求试写并按清单验收后发布。规范正文控制在字段表、写法规则、评审检查项和示例各一份，避免写成原则文件。
要点总览（TL;DR）
- 规范正文只需覆盖四块：用例字段表、步骤与预期写法规则、设计方法选用说明、评审与维护规则，原则性描述控制在全文三分之一以内。
- 制定按五步走：抽取现有用例样本统计常见缺陷、确定强制与推荐分级、编写字段表与写法规则、选真实需求试写、评审定稿并做版本管理。
- 落地要明确四类角色：用例设计者按规范编写并自检，评审者按检查项评审，规范维护者定期修订版本，需求方与开发提供可验证的预期依据。
- 发布前用验收清单逐项核对，并设三条阻断项：无正反示例、未经真实需求试写、未明确评审责任人的规范不发布。
- 规范发布后按约定周期收集执行问题并修订版本，让规则随团队实践持续更新。
规范先定什么：字段、写法与判定标准
一份可执行的用例规范，正文只需要覆盖四块内容：用例字段、步骤与预期写法、设计方法选用、评审与维护规则。这四块分别回答“写哪些信息”“怎么写清楚”“怎么保证覆盖”“怎么保证长期可用”。篇幅上建议正文控制在三到五页，每块内容都配示例，原则性描述不超过全文的三分之一。
字段表是规范的地基。字段过多会增加填写负担，过少则无法支撑评审和追溯。下表给出一个可直接复制使用的字段结构，团队可按业务裁剪，但用例编号、操作步骤、预期结果三项建议保留为强制字段。
| 字段 | 填写要求 | 强制/推荐 |
|---|---|---|
| 用例编号 | 按“模块-序号”规则唯一编号，发布后不复用 | 强制 |
| 所属需求/特性 | 关联到具体需求条目或特性点，便于追溯覆盖 | 强制 |
| 前置条件 | 写清执行前必须满足的数据、账号、配置状态 | 强制 |
| 操作步骤 | 一步一动作，按执行顺序编号 | 强制 |
| 预期结果 | 可观察、可判定，与步骤对应 | 强制 |
| 优先级 | 按业务影响与使用频率分级，如高/中/低 | 强制 |
| 用例类型 | 功能、边界、异常、权限、兼容等 | 推荐 |
| 关联缺陷或风险 | 记录该用例对应的历史缺陷或已知风险点 | 推荐 |
写法规则要落到可检查的动作上。第一条是一步一动作：每个步骤只描述一个操作，避免“打开页面并登录后进入设置”这类复合步骤，执行失败时无法定位问题。第二条是预期结果可观察可判定：写“提示‘密码错误’，停留在登录页”，而不是“登录失败”。第三条是不依赖隐含上下文：前置条件中写清所需数据与状态，让另一位测试人员拿到用例就能独立执行。
设计方法的选用按场景决定，不必在每条用例上堆方法。输入取值范围明确的功能，用等价类划分有效与无效输入，再用边界值补充临界点；涉及多步骤业务流程的，用场景法覆盖主流程与关键分支；对象存在多种状态且状态间有转换条件的，用状态迁移梳理合法与非法转换。规范中为每种方法写一句适用条件和一个小例子即可。
制定步骤：从现状盘点走到规范发布
规范的制定按五步推进，每步都有明确的输入、动作、输出和完成标志，避免讨论停留在原则层面。
第一步：抽取现有用例样本，统计常见缺陷。输入是近几个版本的用例库，动作是随机抽取三十到五十条用例逐条检查，按“步骤含糊、预期缺失、覆盖遗漏、重复冗余”四类归因统计。输出是一份问题分布清单，完成标志是能说出团队当前最突出的两到三类问题。这一步决定了规范的重点，问题集中在预期不可判定，就把写法规则写细；问题集中在覆盖遗漏，就把设计方法选用写细。
第二步：确定规范范围与强制/推荐分级。输入是问题清单和团队现有的用例模板，动作是划定规范适用的项目与用例类型，并把每条要求标注为强制或推荐。输出是规范目录与分级表，完成标志是团队对“哪些必须遵守”没有分歧。分级的意义在于让规范可执行：强制项用于评审拦截，推荐项用于逐步改进。
第三步：编写字段表与写法规则，配正反示例。输入是分级表，动作是逐条写出字段填写要求和写法规则，每条规则配一条正确示例和一条错误示例。输出是规范正文初稿，完成标志是每条规则都能被第三人对照示例判断对错。
第四步：选一个真实需求试写。输入是初稿和一个即将进入测试的需求，动作是由两到三名测试人员各自按规范编写该需求的用例，再对比差异。输出是试写用例集和规范修订意见，完成标志是试写中暴露的字段歧义、规则不清之处已全部修订。试写是验证规范可落地的最直接方式，跳过这一步的规范往往在发布后才发现无法执行。
第五步：评审定稿、发布与版本管理。输入是修订后的规范，动作是组织测试负责人、资深测试和开发代表评审，确定版本号与生效日期，并约定修订周期。输出是发布版规范与修订记录，完成标志是规范已归档到团队可访问的位置，且下一次修订的触发条件（如季度复盘或重大问题反馈）已写明。
角色与交付物：谁写、谁审、谁维护
规范发布后无人执行，通常是因为角色和交接物没有定义。落地涉及四类角色，各自在固定时点介入并交付明确产物。
| 角色 | 主要职责 | 介入时点 | 交付物 |
|---|---|---|---|
| 用例设计者 | 按字段表与写法规则编写用例，完成自检 | 需求评审后、用例评审前 | 符合字段表的用例集 |
| 评审者（测试负责人、资深测试、开发、产品） | 按检查项评审覆盖、步骤与预期，给出修改意见 | 用例提交评审时 | 评审记录与修改意见 |
| 规范维护者 | 收集执行中的问题，定期修订规范版本 | 每季度或问题积累到阈值时 | 修订后的规范版本与变更说明 |
| 需求方与开发 | 提供可验证的预期依据，确认业务规则与异常处理 | 需求澄清与用例评审阶段 | 预期结果确认意见 |
交接关系上，设计者提交用例时同步附上自检结果，评审者据此判断是否进入正式评审；评审意见返回设计者修改后，由评审者确认关闭。规范维护者不直接修改他人用例，只维护规则本身，并把反复出现的问题转化为新的检查项。需求方与开发的介入时点要前置到用例评审之前，预期结果缺少业务依据是用例返工的主要原因之一。
规范落地需要承载字段配置、评审流转和版本留存的地方。ONES TestCase 支持自定义用例属性，可以把字段表中的强制项配置为用例属性；用例支持与产品需求、研发任务关联，便于追溯覆盖；用例库中所有用例属性都支持筛选，评审时能快速筛出缺少预期结果或未关联需求的用例。用例模块支持树状结构与拖拽排序，可按模块组织用例。评审流程与用例版本历史的具体能力，建议在选型或配置时结合实际版本核验。
示例：一条需求如何按规范写出用例
以下为演示情景，用于说明字段填写与写法规则的应用，不代表任何真实项目。需求为“用户使用手机号和密码登录，连续输错五次密码后账号锁定三十分钟”。
按字段表填写的主流程用例如下：
- 用例编号：LOGIN-001
- 所属需求：用户登录
- 前置条件：存在状态正常的测试账号，密码已设置
- 操作步骤：1. 打开登录页；2. 输入正确的手机号；3. 输入正确的密码；4. 点击登录
- 预期结果：1. 登录页正常展示；2. 手机号显示在输入框；3. 密码以掩码显示；4. 跳转至首页，页面右上角显示当前用户名
- 优先级：高
- 用例类型：功能
- 关联缺陷或风险：无
写法规则的应用体现在两处：步骤拆成四个单一动作，执行失败时能定位到具体环节；预期结果逐条对应步骤，且都是可观察的页面状态。常见错误写法是“步骤：输入账号密码登录；预期：登录成功”，这种写法无法判断失败发生在输入、校验还是跳转环节，也无法区分“登录成功”的具体表现。
设计方法的补充上，手机号与密码的输入校验用等价类和边界值：手机号位数不足、格式错误、密码长度临界值各补一条；连续输错锁定用状态迁移：输错四次后账号仍可用、第五次输错后锁定、锁定期间正确密码也无法登录、三十分钟后恢复。异常场景补充网络中断时点击登录的提示。每条补充用例同样按字段表填写，预期结果写明具体提示文案或状态变化。
完成检查：规范发布前的验收清单
规范是否达到可发布状态，用以下清单逐项核对，全部通过再发布。
- 字段表完整，每个字段有填写要求，强制与推荐已标注，无歧义表述。
- 写法规则逐条配有正反示例，第三人能对照示例判断用例是否合规。
- 设计方法选用说明了适用条件，并各有一个小例子。
- 已用一个真实需求完成试写，试写暴露的问题已修订进正文。
- 角色分工表明确了设计者、评审者、维护者、需求方与开发的职责、介入时点和交付物。
- 评审检查项可直接用于用例评审，能拦截缺预期、步骤含糊等问题。
- 规范版本号、生效日期与修订触发条件已写明，修订记录有存放位置。
设置三条阻断项：没有正反示例的规范不发布，未经真实需求试写的规范不发布，未明确评审责任人的规范不发布。这三项缺失时，规范无法被检查、无法被验证、也无法被执行，发布后大概率停留在文档层面。规范发布后按约定周期收集执行问题并修订版本，让规范随团队实践持续更新。
常见问题
团队规模小、用例量不大，还需要专门制定编写规范吗？
需要，但可以精简。小团队的规范可以只保留强制字段（用例编号、操作步骤、预期结果、前置条件）和三条写法规则，示例各配一条，正文控制在一到两页。判断是否需要规范的标准是返工情况：如果用例评审时经常出现预期不可判定、步骤无法独立执行、覆盖遗漏，就值得把规则固定下来。规范的作用是减少口头约定带来的不一致，与团队人数关系不大。
规范里的强制项和推荐项怎么划分，划分不当会有什么后果？
强制项用于评审拦截，应当只包含直接影响用例可执行性和可追溯性的要求，例如字段表中的用例编号、操作步骤、预期结果、前置条件，以及一步一动作、预期可判定这两条写法规则。推荐项用于逐步改进，例如用例类型标注、关联缺陷或风险、设计方法的完整选用。强制项过多会让评审变成形式检查，团队容易抵触；强制项过少则规范失去约束力。划分后建议在试写阶段验证一次，看强制项是否都能被第三人对照判断。
规范试写时，几名测试人员写出的用例差异很大，应该怎么处理？
差异本身就是试写的产出。把差异逐条归类：属于字段填写要求不清的，补充字段说明；属于写法规则表述模糊的，改写规则并补正反示例；属于设计方法选用不一致的，在设计方法部分写清适用条件。归类完成后修订正文，再让参与试写的人按修订版重写同一需求的部分用例，确认差异收敛。如果差异集中在业务预期本身，说明需求方与开发的介入时点需要前置到用例评审之前。
规范发布后，用例评审流于形式、检查项没人真正对照，怎么办？
先确认评审检查项是否可判定。检查项写成“覆盖是否充分”这类判断，评审者只能凭感觉；写成“每条需求至少有一条主流程用例和一条异常用例”“每条用例的预期结果与步骤逐条对应”，就能逐项核对。其次明确评审责任人和关闭规则：评审意见返回设计者修改后，由评审者确认关闭，未关闭的用例不进入执行。评审记录本身也要留存，便于后续统计高频问题并转化为新的检查项。
规范多久修订一次比较合适，修订时要注意什么？
常见做法是按季度复盘，或在执行问题积累到一定数量时触发修订，具体周期按团队节奏确定。修订时注意三点：只改规则本身，不追溯修改已发布的用例；每次修订记录版本号、生效日期和变更说明，保留历史版本；把反复出现的评审问题转化为新的检查项或写法示例，让修订有实际来源。规范维护者负责收集问题，但不宜由个人单独决定重大变更，涉及强制项调整时仍应经过评审。
