公共测试用例清单要支撑跨项目复用，字段通常分为四组：标识与定位、复用条件、执行要素、资产治理。本文给出一张可直接复制到表格工具的空白模板，并说明每个字段的填写口径、必填规则和一条完整填写示例，适合正在建立或整理公共用例库的测试团队使用。
要点总览（TL;DR）
- 公共测试用例清单的字段分为四组：标识与定位、复用条件、执行要素、资产治理，共15个字段，可直接复制成表格使用。
- 用例编号、标题、所属模块、用例类型、操作步骤、预期结果、评审状态、维护责任人为必填项；版本范围、前置条件、依赖环境、关联需求按触发条件必填。
- 公共清单只收录已通过评审、可跨项目复用的用例，项目专属用例留在项目库，通过引用编号关联，避免复制后口径分叉。
- 维护重点是版本范围复核、废弃归档和季度评审：功能下线或连续两个大版本未被引用的用例标记废弃并保留编号，保证历史引用可追溯。
可复制空白模板：公共测试用例清单表
下面这张表可以直接复制到 Excel、在线表格或测试管理工具的自定义字段中。表头按四组排列，复制后保留表头行，逐行填入用例即可。分组列仅用于阅读时定位，实际建表时可以保留，也可以合并进字段名。
| 分组 | 字段名 | 填写内容 |
|---|---|---|
| 标识与定位 | 用例编号 | |
| 标识与定位 | 用例标题 | |
| 标识与定位 | 所属模块/功能 | |
| 标识与定位 | 用例类型 | |
| 复用条件 | 适用产品/版本范围 | |
| 复用条件 | 前置条件 | |
| 复用条件 | 依赖环境与数据 | |
| 执行要素 | 操作步骤 | |
| 执行要素 | 预期结果 | |
| 执行要素 | 优先级 | |
| 资产治理 | 维护责任人 | |
| 资产治理 | 评审状态 | |
| 资产治理 | 最近更新日期 | |
| 资产治理 | 变更记录 | |
| 资产治理 | 关联需求/缺陷 |
空白行示例（复制时按此格式逐条填写）：
| 用例编号 | 用例标题 | 所属模块/功能 | 用例类型 | 适用产品/版本范围 | 前置条件 | 依赖环境与数据 | 操作步骤 | 预期结果 | 优先级 | 维护责任人 | 评审状态 | 最近更新日期 | 变更记录 | 关联需求/缺陷 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
公共清单只收录经过评审、可跨项目复用的用例。项目专属的用例留在项目库中，使用时通过引用公共用例编号的方式关联，避免同一用例在多处复制后各自修改、口径分叉。
字段说明：每个字段填什么、怎么填
字段说明与模板表头一一对应。填写口径按“写什么、写到什么颗粒度”来描述，常见错误列用于自查。
| 字段名 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 用例编号 | 公共库内唯一标识 | 采用“模块缩写-序号”格式，如 LOGIN-001，编号一经分配不再复用 | 删除用例后把编号让给新用例，导致历史引用指向错误对象 |
| 用例标题 | 一句话说明验证什么 | 动宾结构，包含对象和验证点，如“手机号登录：验证码错误时提示重试” | 只写“登录测试”，无法区分具体验证点 |
| 所属模块/功能 | 用例在功能结构中的位置 | 按产品功能树填写到二级或三级节点，与用例库的模块分类保持一致 | 填成项目名或迭代名，模块维度失去检索价值 |
| 用例类型 | 用例的验证性质 | 从团队约定枚举中选：功能、接口、兼容性、性能、安全、异常等 | 每人类型写法不同，筛选时出现“功能测试”“功能性”多个值 |
| 适用产品/版本范围 | 该用例在哪些产品和版本上有效 | 写产品名加版本区间，如“产品A 3.0–3.5”；跨产品通用时写“全产品” | 只写“通用”，实际只在一个产品验证过 |
| 前置条件 | 执行前必须满足的状态 | 写可检查的状态，如“账号已注册且未锁定”“开关X已开启” | 把操作步骤写进前置条件，执行时重复操作 |
| 依赖环境与数据 | 执行所需的系统环境和测试数据 | 写环境类型（测试/预发）、依赖服务、数据准备方式或数据文件位置 | 只写“测试环境”，复用时无法判断依赖哪些服务 |
| 操作步骤 | 从起点到验证点的动作序列 | 分步编号，每步一个动作，包含输入值；步骤可被不同人按同一顺序执行 | 多步合并成一段，或省略输入数据 |
| 预期结果 | 每步或最终应出现的可观察结果 | 与步骤对应，写界面提示、状态变化、数据结果等可核对内容 | 写“正常显示”“符合预期”等无法判定的表述 |
| 优先级 | 执行和回归的先后顺序 | 用 P0–P3 或高/中/低，按业务影响和失败后果定级，团队统一一套 | 所有人都填“高”，优先级失去排序作用 |
| 维护责任人 | 负责该用例准确性的角色 | 填到具体人，按模块分工；人员变动时同步移交 | 填团队名或留空，用例过期无人处理 |
| 评审状态 | 用例是否达到可复用条件 | 用“草稿/待评审/已通过/已废弃”等状态值，只有“已通过”进入公共清单 | 用自由文本写评审意见，无法筛选 |
| 最近更新日期 | 字段内容最后一次实质修改的时间 | 格式统一为 YYYY-MM-DD，修改步骤或预期结果时更新 | 只改错别字也更新，日期无法反映内容有效性 |
| 变更记录 | 关键修改的说明 | 记录日期、修改人、修改内容，如“2024-06-10 张三：版本范围扩至3.5” | 只写“已更新”，追溯时看不到改了什么 |
| 关联需求/缺陷 | 用例来源和问题追踪入口 | 填需求编号或缺陷编号，多个用逗号分隔 | 填需求标题全文，编号检索失效 |
必填与选填：哪些字段不能空
必填字段决定一条记录能否被检索、执行和追责。建议把标识、复用条件中的核心项、执行要素和治理状态列为必填，其余按使用场景设为条件必填或选填。下表为建议口径，团队可按复用范围调整。
| 档位 | 字段 | 理由或触发条件 |
|---|---|---|
| 必填 | 用例编号、用例标题、所属模块/功能、用例类型 | 缺少任一项，用例无法被定位和筛选，公共库检索失效 |
| 必填 | 操作步骤、预期结果 | 没有这两项，用例无法被执行，也不构成可复用资产 |
| 必填 | 评审状态、维护责任人 | 公共清单只收已评审用例；无责任人则过期无人处理 |
| 条件必填 | 适用产品/版本范围 | 用例跨产品复用时必填；仅单产品单版本使用时至少写产品名 |
| 条件必填 | 前置条件 | 执行依赖特定账号状态、开关或数据时必填；无依赖可写“无” |
| 条件必填 | 依赖环境与数据 | 依赖特定服务、环境或数据文件时必填 |
| 条件必填 | 关联需求/缺陷 | 用例由需求派生或用于跟踪缺陷时必填 |
| 选填 | 优先级 | 公共库统一维护时可填；由引用方在测试计划中自行定级时可不填 |
| 选填 | 最近更新日期、变更记录 | 由工具自动记录时可省略手工填写；离线表格维护时建议保留 |
字段缺失时的处理方式：必填项为空，记录停留在“草稿”状态，不进入公共清单；条件必填项在触发条件成立时为空，评审时退回补充；选填项为空不影响复用，但引用方需要在测试计划中补齐执行所需信息。评审人按同一张表核对，避免逐条口头确认。
填写示例：一条完整用例在清单中的样子
以下为演示情景，产品名和数据均为虚构，用于说明字段之间的对应关系。
| 字段名 | 示例取值 |
|---|---|
| 用例编号 | LOGIN-012 |
| 用例标题 | 手机号登录：验证码错误时提示剩余重试次数 |
| 所属模块/功能 | 账号中心 / 登录 |
| 用例类型 | 功能 |
| 适用产品/版本范围 | 产品A 3.0–3.5 |
| 前置条件 | 手机号已注册；当日错误次数未达上限 |
| 依赖环境与数据 | 测试环境；短信服务可用；测试账号 138****0001 |
| 操作步骤 | 1. 打开登录页，选择手机号登录；2. 输入已注册手机号；3. 输入错误验证码 000000；4. 点击登录 |
| 预期结果 | 页面提示“验证码错误，还可重试4次”；登录按钮恢复可点击；错误次数加1 |
| 优先级 | P1 |
| 维护责任人 | 李四（账号中心模块） |
| 评审状态 | 已通过 |
| 最近更新日期 | 2024-06-10 |
| 变更记录 | 2024-06-10 李四：版本范围由3.0–3.2扩至3.5，补充重试次数提示 |
| 关联需求/缺陷 | REQ-2087，BUG-4512 |
取值理由逐项说明：编号按模块缩写加序号分配，便于在项目库中引用；标题包含对象（手机号登录）和验证点（验证码错误提示），与预期结果呼应；模块填到二级节点，与用例库分类一致；类型选“功能”，因为验证的是登录主流程行为；版本范围写区间而非“通用”，因为3.5之后提示文案改版，旧用例需要复核；前置条件写可检查的状态，避免把“输入错误验证码”这类操作混入；依赖环境写明短信服务和测试账号，复用时能判断环境是否具备；步骤分四步且包含具体输入值，任何人按序执行都能复现；预期结果写提示文案、按钮状态和计数变化，三项都可核对；优先级 P1 因为登录失败提示影响主流程体验；责任人和评审状态保证这条记录有人负责且已通过评审；变更记录说明本次修改内容，与最近更新日期对应；关联需求与缺陷提供来源和问题追踪入口。
调整与维护：清单如何随项目演进
清单建好后，字段和记录都会随产品迭代变化。维护的重点是让“可复用”这个判断持续成立，而不是把表填满。
字段增删的判断标准
新增字段前先确认三件事：是否有筛选或统计需求、是否每行都能稳定填写、是否与现有字段重复。例如团队开始按自动化覆盖情况筛选用例，可以增加“自动化状态”字段；如果只是个别项目想记录备注，放进变更记录或项目库即可，不必扩展公共表头。删除字段时先检查引用方是否依赖该字段做筛选，确认无引用后再停用，历史数据保留在导出备份中。
适用版本范围与失效处理
产品版本升级后，责任人复核受影响的用例：行为未变的更新版本区间；行为变化的修改步骤和预期结果，并在变更记录中写明原因；功能下线的用例标记为“已废弃”，保留编号和历史内容，不再被新测试计划引用。版本范围建议写区间而非“最新版”，避免清单随版本发布被动失效。
废弃与归档规则
用例连续两个大版本未被任何测试计划引用，或对应功能已下线，由责任人发起废弃评审。废弃用例移入归档区，保留编号、标题和废弃原因，不直接删除，保证历史测试记录中的引用仍可追溯。归档区按季度清理一次，确认无追溯需求后再做最终处理。
定期评审与责任人机制
建议按季度做一次公共清单评审：责任人逐条确认用例有效性，评审人抽查新增和修改记录，统计长期未引用用例并决定废弃或保留。人员变动时，模块责任人移交需同步更新清单中的责任人字段，避免出现无人认领的记录。评审节奏可按发布频率调整，发布频繁的团队可改为每月一次。
清单落到测试管理工具中时，字段可以对应为用例属性，评审状态和责任人随用例记录一起维护。ONES 测试管理支持编写测试用例、组织用例库，并可自定义用例属性以适配不同业务场景；用例模块支持树状结构和拖拽排序，用例库中所有用例属性都支持筛选，便于按模块、类型或版本范围找到可复用用例。用例可与需求、任务关联，测试计划与迭代关联，引用公共用例后仍能回溯到需求来源。批量建库阶段可从 Excel 导入用例，需要本地备份时也支持导出。评审流程和变更历史的承载方式，建议在选型或配置时结合团队实际流程确认。
常见问题
公共用例库和项目用例库应该怎么分工，哪些用例放公共库？
判断标准是用例的复用范围。在多个项目或产品版本中都会执行、且行为口径一致的用例，评审通过后进入公共库；只服务单个项目、依赖该项目特有数据或流程的用例，留在项目库。公共库的用例被项目引用时，通过用例编号关联，项目侧补充自己的执行数据和测试计划，公共记录本身不复制。这样同一验证点只有一份维护来源，项目差异在项目层表达。
团队刚开始建公共用例库，字段可以先用简化版吗？
可以。起步阶段建议先保证必填字段完整，尤其是编号、标题、模块、步骤、预期结果、评审状态和责任人，这七项决定用例能否被检索、执行和追责。版本范围、依赖环境、关联需求等条件必填字段，可以在用例第一次跨项目复用时补齐。字段一次加太多，填写成本上升，容易出现大量空值，反而降低清单可信度。等复用场景稳定后，再按筛选和统计需求逐步扩展表头。
用例的适用版本范围怎么写，才能避免版本升级后清单大面积失效？
写明确的版本区间，例如“产品A 3.0–3.5”，避免写“最新版”或“通用”。版本发布后由模块责任人复核受影响的用例：行为未变的延长区间；行为变化的修改步骤和预期结果，并在变更记录中写明原因；功能下线的标记废弃。把版本复核放进每次发布的固定动作，清单的有效性由责任人逐条确认，而不是等引用方执行失败后才发现过期。
用例评审状态和变更记录在表格里手工维护，容易失真，有什么替代做法？
手工维护的关键是减少自由填写。评审状态使用固定枚举值（草稿、待评审、已通过、已废弃），变更记录只记日期、修改人和修改内容三项，最近更新日期由工具自动生成或按统一格式填写。如果团队已经在用测试管理工具，可以把这些字段配置成用例属性，评审状态随评审流程流转，变更历史随用例记录保存，减少人工同步。ONES 测试管理支持自定义用例属性，用例可与需求、任务关联，批量建库阶段可从 Excel 导入用例，也支持导出做本地备份；评审流程的具体承载方式建议结合团队流程在配置时确认。
废弃的公共用例直接删除还是保留？保留的话怎么管理？
建议保留并归档。历史测试计划和缺陷记录中可能仍引用该用例编号，直接删除会让这些引用失去指向。做法是把用例标记为“已废弃”，移入归档区，保留编号、标题、废弃原因和最后有效版本范围，不再被新测试计划引用。归档区按季度清理一次，确认没有追溯需求后再做最终处理。编号在整个过程中不复用，新用例分配新编号。
