公共用例集是把多个项目、模块或产品线都会用到的测试用例，从各自用例库中抽出来集中维护的一组测试资产，核心特征是“被多处引用、由一方维护、按版本发布”。本文围绕定义、收录边界、组成机制与相邻概念展开，帮助团队准确使用这一说法。
要点总览（TL;DR）
- 公共用例集是跨项目、跨模块共享并由指定责任方集中维护的测试用例集合，核心特征是“被多处引用、由一方维护、按版本发布”。
- 收录与否看三个条件：被两个以上项目重复使用、维护责任人唯一、变更频率可控；单需求专属、一次性脚本和强依赖特定项目数据的用例留在项目库更合适。
- 一套可运行的公共用例集由用例条目、统一编号、适用条件、维护人和版本状态五类要素构成，项目侧通过引用而非复制使用，变更经评审后发布新版本并通知引用方同步。
- 公共用例集是测试用例库的子集，与研发配置基线管理对象不同，与测试用例设计分属资产组织方式与设计方法两个层次。
- 常见误解集中在三处：把所有用例合并成一个库、项目方随意改动副本、追求公共集规模越大越好；管理重点在边界与责任，不在数量。
公共用例集到底指什么
公共用例集是跨项目、跨模块共享，并由指定责任方集中维护的测试用例集合。它把重复出现的验证场景从各项目用例库中提取出来，用统一标识和统一口径管理，供多个使用方引用。这样做的直接结果是：同类场景只编写一次，各项目看到的是同一份验证标准，修改时也只需在一处完成。
公共用例集与普通测试用例库是子集关系。测试用例库覆盖一个团队或产品全部测试资产，公共用例集只占其中被多处复用的那部分。它不替代项目自有用例库，项目仍需要维护需求专属、数据专属的用例，公共用例集负责承接那些“每个项目都要验一遍”的通用场景。
在实际组织中，公共用例集常见三种存在形态：
- 独立用例库：在测试管理工具中单独建一个库，命名上体现“公共”属性，项目通过引用或关联方式使用。
- 标签或分组：仍放在统一用例库内，用“公共”“通用”等标签或目录分组标识，便于筛选和批量维护。
- 共享目录或引用关系：以目录共享或条目引用的方式挂接到各项目，项目侧看到的是同一份源条目，而非复制出的副本。
三种形态的管理强度依次提高。标签分组上手快，适合公共用例规模较小、维护人较少的阶段；独立库和引用关系更适合使用方多、变更需要评审和通知的场景。选择哪种形态，取决于复用范围和维护责任是否已经明确。
哪些用例该进公共用例集，哪些不该进
收录范围决定公共用例集能否长期可用。判断一条用例是否该进公共集，可以看三个条件：是否被两个以上项目或模块重复使用；维护责任人是否唯一；变更频率是否可控。三个条件同时满足，才适合纳入集中维护。
适合收录的典型场景包括：
- 登录与鉴权：账号密码登录、单点登录、令牌失效、权限越权校验等，几乎每个系统都要验证。
- 支付通道：支付下单、回调通知、退款、对账等流程，多个业务线共用同一通道时验证口径应当一致。
- 通用组件：日期选择、文件上传、分页查询、富文本编辑等基础组件的交互与边界行为。
- 合规校验：隐私授权、敏感信息脱敏、日志留存等监管要求对应的检查项。
不适合收录的情况同样明确：单个需求专属的验收用例，其验证目标只对该需求成立；一次性验证脚本，用完即弃，没有复用价值；强依赖特定项目数据或环境的用例，换一个项目就无法执行，放进公共集只会增加维护负担。
变更频率需要单独说明。高频变动的用例放进公共集，会带来频繁的评审和同步成本，使用方也可能因为版本不一致而产生误判。对这类用例，更稳妥的做法是先在项目内维护，等场景稳定、验证口径收敛后再迁入公共集。
公共用例集的组成与运行机制
一套可运行的公共用例集由五类要素构成，缺一项都会影响引用方能否正确使用。
| 组成要素 | 作用 | 缺失后的典型问题 |
|---|---|---|
| 用例条目 | 前置条件、步骤、预期结果的完整描述 | 引用方无法直接执行 |
| 统一编号 | 跨项目识别同一用例，便于追溯和引用 | 同一场景出现多个编号，统计口径混乱 |
| 适用条件 | 说明该用例适用的系统、环境、数据前提 | 被错误套用到不适用的项目 |
| 维护人 | 唯一责任人，负责内容准确与变更处理 | 多人可改，内容分叉无人负责 |
| 版本状态 | 标识草稿、生效、废弃等状态 | 引用方无法判断当前版本是否可用 |
引用机制的关键是“引用而非复制”。项目侧通过关联或挂接方式使用公共条目，执行记录仍归属项目自己的测试计划，但用例内容只有一份源。复制会产生多份副本，源条目更新后副本不会自动变化，时间一长各项目验证口径就会分叉，公共用例集也就失去了统一标准的意义。
更新机制通常按以下流程运行：
- 维护人发起变更，说明修改原因和影响范围。
- 相关使用方或测试负责人参与评审，确认变更不会破坏既有项目的验证结论。
- 评审通过后发布新版本，旧版本标记为历史或废弃。
- 系统或维护人通知引用方同步，引用方确认升级或继续锁定旧版本。
- 对已失效的条目执行下线处理，清理残留引用，避免项目继续引用废弃内容。
当团队把公共用例集放进测试管理工具承载时，工具需要支持用例库的结构化组织、条目级权限和变更留痕。ONES TestCase 支持编写测试用例并组织用例库，用例模块采用树状结构并可拖拽排序，同时支持为用例库单独配置权限，这些能力可以支撑公共用例集“集中维护、分权使用”的基本形态。需要说明的是，跨项目共享同一份用例、版本状态与变更评审的具体实现方式，应以团队实际使用的产品版本为准，在落地前确认引用关系是否符合预期。
公共用例集与测试用例库、资产基线的区别
三个概念容易混用，原因在于它们都涉及“集中管理”，但管理对象和管理目的不同。
| 概念 | 管理对象 | 与公共用例集的关系 |
|---|---|---|
| 测试用例库 | 团队或产品的全部测试用例 | 整体与子集：公共用例集是用例库中被多处复用的部分 |
| 研发配置基线 | 代码、文档、构建产物等研发成果 | 管理对象不同：一个管测试资产，一个管研发产物 |
| 测试用例设计 | 用例的编写方法与设计思路 | 方法与应用：设计方法决定用例怎么写，公共用例集决定用例放在哪、给谁用 |
与测试用例库的区别最直接：用例库回答“团队有哪些用例”，公共用例集回答“哪些用例被多个项目共用”。把两者等同，会导致所有用例都被贴上公共标签，维护责任反而模糊。
与研发配置基线的区别在于管理对象。配置基线锁定的是某一时点可交付的研发产物，用于版本追溯和发布控制；公共用例集锁定的是验证标准，服务于测试执行的一致性。两者都可能涉及版本和评审，但评审的内容、参与角色和失效处理方式并不相同。
与测试用例设计的区别在于层次。设计方法解决“这条用例是否覆盖了关键场景、步骤是否可执行”，公共用例集解决“这条用例放在哪里、由谁维护、哪些项目引用”。设计质量不高的用例，即使进了公共集，也只是把问题放大到更多项目。
一个具体例子与常见误解
假设某公司有三条业务线：电商、会员和内容平台，各自有独立测试团队。三条业务线都需要验证登录与权限校验，包括账号密码登录、令牌过期重新认证、普通用户访问管理接口被拒绝等场景。过去每个团队各写一套，步骤和预期结果表述不一，安全团队抽查时发现同一场景有三种判定口径。
引入公共用例集后，安全测试组作为维护人，把登录与权限校验的十二条用例整理进公共集，统一编号并标注适用条件（Web 端、移动端、开放接口分别适用哪些条目）。三个项目在各自测试计划中引用这些条目，执行记录仍归各自项目。某次安全策略调整要求令牌过期时间缩短，维护人发起变更评审，三个项目测试负责人确认影响后发布新版本，各项目同步升级。一次修改，三处生效，验证口径重新统一。
围绕这个例子，有三条常见误解需要纠正：
- 误解一：公共用例集等于把所有用例放进一个库。集中放一起只是物理位置的变化，公共用例集的核心是“被多处引用、由一方维护”。不加筛选地合并，会让维护人无法承担评审责任，使用方也难以判断哪些条目可信。
- 误解二：引用后项目方可以随意改动副本。如果项目侧改的是副本，源条目和副本就会分叉，后续源条目更新时项目方拿到的版本与自己的修改冲突。正确做法是项目侧提出变更建议，由维护人统一修改并发布，项目侧只保留执行层面的差异，例如测试数据。
- 误解三：公共用例集越多越好。公共集规模扩大，评审、通知和失效处理的成本同步上升。收录标准应回到复用次数、维护人唯一和变更可控三个条件，达不到条件的用例留在项目库中更合适。
把这三条误解对照前面的收录标准和运行机制，可以看出公共用例集的管理重点在“边界”和“责任”，而不在数量。团队在引入这一说法时，先明确谁维护、哪些项目引用、变更如何通知，再谈建库和迁移，落地会顺利得多。
常见问题
团队刚开始建公共用例集，应该先做哪一步？
先确定维护责任，再谈建库和迁移。具体做法是列出当前被两个以上项目重复验证的场景，指定一个唯一维护人，明确哪些项目会引用，然后才决定用独立用例库、标签分组还是共享目录来承载。责任和引用范围没定就先把用例搬进公共库，后续变更评审和通知容易落空，公共集很快会退化成另一个无人负责的用例库。
公共用例集里的用例被某个项目发现不适用，应该怎么处理？
先区分是适用条件没写清，还是用例本身有缺陷。如果是适用条件缺失，由维护人补充适用条件并发布新版本，让其他引用方也能看到边界；如果是用例内容有误，项目侧提出变更建议，由维护人统一修改，项目侧不直接改源条目。项目自身特有的执行差异，例如测试数据、环境参数，留在项目测试计划里记录，不写回公共条目。
公共用例集需要和项目需求、测试计划建立关联吗？
建议建立关联，否则复用关系只能靠人工记忆维护。项目在测试计划中引用公共条目后，执行结果仍归属该项目，但条目与需求的关联可以帮助判断某次需求变更会影响哪些公共用例。ONES TestCase 支持用例与产品需求、研发任务关联，测试计划与迭代关联，可以承载这种追溯关系；跨项目共享同一份用例的具体实现方式，建议在落地前按团队实际使用的产品版本确认。
公共用例集规模变大后，维护成本怎么控制？
控制成本的关键是守住收录门槛，而不是等规模膨胀后再治理。定期复核每个条目的复用次数和维护人是否仍然成立，长期无人引用或变更频繁到无法评审的条目，迁回项目库维护。同时把废弃条目的下线纳入常规流程，清理残留引用，避免项目继续引用已失效内容。规模增长本身不是目标，可维护的复用范围才是。
公共用例集和研发配置基线在评审上有什么不同？
两者都可能走评审，但评审内容和参与角色不同。公共用例集评审的是验证标准是否准确、变更会影响哪些引用项目，参与方主要是测试负责人和维护人；研发配置基线评审的是某一时点可交付的研发产物是否完整、能否发布，参与方通常包括研发、测试和发布管理角色。把两者的评审流程合并，容易出现测试口径变更被当作发布审批处理，响应速度跟不上用例维护的节奏。
