测试用例编号命名的10个最佳实践：提高代码可读性和维护性

测试用例编号命名的10个最佳实践：提高代码可读性和维护性，真正要解决的并不是“编号从001还是0001开始”，而是团队能否在几个月后仍然准确回答三个问题：这个用例属于什么范围、它和哪个需求或自动化脚本有关、历史执行记录是否还能追溯。我见过不少团队把编号设计成一串看似专业的编码，最后却因为版本、优先级、执行人频繁变化而不断重编号；也见过全部使用 TC001 的团队，依靠名称、标签和系统字段把测试资产维护得很稳定。

好的编号不是信息最多，而是变化最少、引用最稳、检索成本最低。

一、先讲核心结论：编号不是描述字段，而是测试资产的稳定地址

1. 编号、名称和标签不能承担同一件事

很多编号混乱，根源不是格式不统一，而是字段职责没有分开。团队希望一个编号同时表达产品、模块、测试类型、优先级、版本、平台和执行人，于是编号越加越长；但这些信息的变化频率并不相同，最终必然导致编号失真。

我的判断标准很简单：如果一个字段在测试用例生命周期中经常变化，就不要把它写进编号；如果一个字段是稳定的命名空间，并且团队经常用它筛选，就可以考虑放进编号。这比“编号一定要有模块前缀”更可靠。

2. 最佳编号格式取决于团队的检索动作

如果测试人员主要通过平台筛选模块、版本和标签，那么简单流水号完全可以满足需求；如果团队经常在缺陷单、群聊、自动化报告和代码提交中手工引用用例，模块前缀会更有价值。换句话说，编号设计不是审美问题，而是检索路径设计。

我通常会先观察团队最常见的三种动作：第一，能否根据编号快速找到用例；第二，能否从失败报告回到测试目标；第三，编号被复制、拆分、迁移后是否仍然有效。只要这三个动作能够顺畅完成，就没有必要为了“看起来像大公司”而增加更多编码维度。

二、为什么很多团队的编号会失控

1. 从单项目的便利，演变成跨团队的歧义

项目刚开始时，TC001 看起来非常好用。测试人员数量少，所有用例都在一张表里，遇到问题时只要按序号查找即可。真正的麻烦通常在项目扩大后出现：登录、支付、订单和消息模块都可能拥有自己的 TC001；不同端的用例被复制到同一个平台后，原有编号又无法提供命名空间。

另一个常见场景是多个团队各自维护缩写。一个团队使用 AUTH 表示登录，另一个团队使用 LOGIN，第三个团队又使用 SIGNIN。这些词在业务上可能接近，但在搜索和统计中却会变成三个不同的分类，导致重复用例和漏测风险。

2. 为了连续而重编号，破坏了历史关系

有人删除 WEB-LOGIN-006 后，会把后面的 007、008 全部前移，理由是“编号不能有空缺”。这是一种典型的文档排版思维，而不是测试资产管理思维。编号空缺并不影响测试执行，但重编号会改变历史报告、缺陷记录、自动化映射和会议纪要中的指向。

如果一个缺陷单曾经引用 WEB-LOGIN-008，而你把它改成了 007，未来的人看到旧报告时很难判断这个引用是历史编号还是当前编号。编号连续只是视觉上的整齐，编号稳定才是追踪上的正确。

3. 把版本和优先级写进编号，制造“过期编号”

例如，团队把用例写成 V3-P0-LOGIN-001。版本升级后，是否要改成 V4-P0-LOGIN-001？如果优先级从P0调整为P1，是否也要改号？如果都不改，编号中的信息就是错误的；如果都改，历史记录就会断裂。

版本、优先级、执行状态、责任人和平台环境，本质上是测试管理属性，不是对象身份。它们应该由独立字段维护，并在报告或筛选条件中组合展示。

4. 编号格式看似专业，实际无法由工具稳定生成

手工维护多维编号时，最容易出现两个问题。第一，同一序号被不同人员重复占用；第二，复制用例后原编号被顺手保留。只要编号生成依赖个人记忆，规则就很难长期执行。

在中大型组织中，我更关注平台是否能提供唯一编号、导入导出映射、变更审计和自动化关联，而不是单纯关注编号字符串是否漂亮。以 PingCode 这类面向中大型企业和100人以上组织的测试管理平台为例，团队可以把编号作为稳定标识，把需求、缺陷、版本、执行结果和自动化结果放在独立关联关系中维护；如果组织有合规要求，也可以采用私有化部署，并通过迁移能力承接原有测试资产。平台能力的价值在于减少人工维护，而不是替团队设计一串更复杂的字母。

三、测试用例编号命名的10个最佳实践

1. 先定义编号的业务目标，再决定格式

设计编号前，不要先打开表格填写模板，而应先回答几个问题：团队是否需要从编号中识别模块？是否有多个产品或多个端？是否需要在自动化报告中引用编号？是否会跨平台迁移？编号由系统生成，还是由测试人员手工填写？

如果团队只有十几个人、一个产品、一个测试库，而且平台支持模块和标签筛选，TC-0001 可能已经足够。如果团队拥有多个产品线和多个交付团队，需要在聊天工具、缺陷单和代码报告中快速区分来源，那么产品或模块前缀更有价值。

（1）建议先记录三类真实检索场景

• 测试人员从失败编号查找原始用例。
• 开发人员从缺陷单反查测试步骤和验收条件。
• 负责人按产品、模块、版本或优先级生成回归报告。

只有当某个字段在这些动作中确实能减少定位时间，才值得进入编号。否则，优先使用平台字段实现筛选。

2. 保证编号唯一，并明确谁负责生成

唯一性是编号的底线。编号不能只在当前表格中唯一，还要考虑同一产品不同项目、不同测试阶段和不同导入批次之间是否会冲突。尤其是多人协作时，人工分配“下一个编号”很容易出现并发问题。

我建议把编号生成责任交给系统，或者至少由一个明确的维护角色统一分配。复制用例时必须生成新编号，不能把原编号当成模板属性一起复制。导入历史数据时，则应先建立旧编号、新编号和来源链接的映射表。

{
"case_id": "WEB-LOGIN-F-001",

"source_case_id": "TC-1024",

"title": "正确账号密码登录成功",

"priority": "P0",

"version": "Release-2026.08",

"status": "active"

}

上面的结构体现了一个重要原则：新编号用于当前系统中的唯一识别，旧编号作为来源信息保留；版本和优先级则是独立属性，不能让它们污染编号的稳定性。

3. 只把稳定的产品、系统或模块放进前缀

常见的模块型格式是 WEB-LOGIN-001。其中 WEB 可以表示产品端，LOGIN 可以表示相对稳定的功能域，最后的序号负责区分同一范围内的不同用例。

但模块前缀也不是越细越好。组织如果每个季度都会调整领域模型，今天的“账户中心”下个月可能拆成“认证服务”和“用户资料”，那么把非常细的组织结构固化进编号，反而会增加迁移成本。

4. 控制编号长度，不要把它变成一条测试说明

我见过这样的编号：ERP-V4-SALES-ORDER-CREATE-API-REGRESSION-P1-001。它包含大量信息，但任何人真正引用它时，通常只会复制粘贴，没人能快速判断其中每段缩写是否准确。更麻烦的是，回归类型、优先级和版本都可能变化。

更稳妥的格式可以是 ERP-ORDER-API-001，再用独立字段表达“回归测试”“P1”“V4”。编号的作用是把人带到正确对象，而不是替代测试用例名称、前置条件和步骤。

如果一个编号需要团队培训半小时才能理解，说明它已经超过了可读性边界。编号的可读性不是字段数量，而是团队成员能否在第一次看到时快速猜出它的命名空间和用途。

5. 统一大小写、分隔符、序号位数和缩写字典

同一个测试库中同时出现 web_login_1、Web-Login-001、WEBLOGIN01，并不只是风格问题。它会影响排序、搜索、批量导入、脚本匹配和跨系统同步。规则越模糊，越容易出现“看起来差不多，系统却认为不同”的情况。

我通常建议采用大写字母、连字符和固定宽度序号，例如 WEB-LOGIN-F-001。是否使用三位还是四位序号，要根据预计规模决定，不必盲目追求四位。固定宽度的价值主要在排序一致，而不是体现项目规模。

• 大小写：统一使用大写。
• 分隔符：统一使用连字符，不混用下划线和空格。
• 序号：统一补零，例如001、002、003。
• 中文字符：编号中不建议使用，避免跨系统兼容问题。
• 缩写：建立词典，禁止同一概念随意使用多个缩写。

6. 不要把优先级、状态、执行人和临时版本固化进编号

这是最容易被忽略、却最影响长期维护的一条规则。优先级不是对象身份，而是风险判断；状态不是对象身份，而是生命周期；执行人更是一次执行记录的属性。把它们写进编号，会让测试用例在每次管理属性变化时产生“是否改号”的争议。

推荐这样设计：

7. 让编号和用例名称各自表达清楚

编号 WEB-LOGIN-F-001 只能告诉读者这是某个产品登录模块中的功能测试用例，不能告诉读者具体验证什么。真正的业务语义应该放在名称中，例如“正确账号密码登录成功”“密码错误时提示认证失败”“连续输错密码后触发锁定”。

好的名称一般包含测试对象、条件和预期行为，避免写成“登录测试1”“异常场景”“验证功能是否正常”。名称不清晰时，即使编号设计得再漂亮，维护人员仍然需要打开详情才能理解测试目标。

（1）推荐的字段组合

• 编号：WEB-LOGIN-F-001
• 名称：正确账号密码登录成功
• 优先级：P0
• 测试类型：功能测试
• 标签：登录、核心流程、回归
• 需求关联：REQ-LOGIN-001

这种组合比把所有信息压缩到编号中更容易维护。编号负责“找到谁”，名称负责“它验证什么”，标签负责“如何分类”，优先级负责“先测什么”，需求关联负责“为什么要测”。

8. 删除、拆分、合并和迁移时保持可追踪

测试用例不是静态表格，而是会经历创建、复制、修改、废弃、拆分、合并和迁移。编号规范必须覆盖这些生命周期动作，否则团队只是在定义“创建时怎么命名”，没有解决真正的维护问题。

拆分是最考验团队判断力的场景。如果原用例“登录失败场景”同时覆盖密码错误、账号不存在、账号锁定三个不同测试目标，拆分后应该保留原记录作为历史入口，再创建三个新用例，而不是偷偷把原编号改成其中一个新目标。

9. 为手工测试和自动化测试建立明确映射

自动化测试方法名与测试用例编号不是一回事，但两者必须能够互相定位。手工用例关注步骤、数据和预期结果；自动化代码关注执行逻辑、断言和环境。把完整业务描述硬塞进代码方法名，通常会导致重命名成本；完全不做映射，又无法从失败报告回到业务用例。

一种可行方式是使用测试框架标签、注解或外部映射表。例如，以下代码仅用于展示关联思想，具体写法应根据所使用的测试框架调整：

import pytest
@pytest.mark.case_id("WEB-LOGIN-F-001")

def test_login_success():

response = login(username="valid_user", password="correct_password")

assert response.status_code == 200

assert response.body["logged_in"] is True

如果一个自动化脚本覆盖多个手工用例，可以添加多个编号；如果一个手工用例被多个平台或多种数据集覆盖，则应在执行记录中区分环境，而不是为每个环境复制一套编号。

在中大型企业中，自动化关联还要考虑代码仓库、持续集成流水线、测试报告和缺陷系统之间的数据流。PingCode支持与研发协作流程衔接，也支持私有化部署和Jira平滑迁移等企业场景。对于正在做国产替代或历史测试资产迁移的组织，重点应核对编号保留、字段映射、权限审计和接口同步能力，而不是只看平台是否允许自定义前缀。

10. 把编号规则写成可执行的团队规范

一份真正有用的规范，不应只写“编号要简洁、统一、唯一”，而应明确谁生成、如何复制、如何废弃、如何迁移，以及出现例外时谁批准。新人看完规范后，应该能独立创建一条合格用例，而不是还要询问“这个模块到底用哪个缩写”。

建议规范至少包含以下内容：

• 编号格式及各字段含义。
• 产品、模块和测试类型的缩写字典。
• 大小写、分隔符和序号位数要求。
• 自动编号或人工编号的责任边界。
• 复制、拆分、合并、删除和废弃规则。
• 编号与需求、缺陷、自动化脚本的关联方式。
• 跨项目、跨平台迁移时的映射办法。
• 示例、反例和异常处理流程。

规范上线后，还要抽查执行结果。最有效的检查通常不是人工逐条阅读，而是利用平台规则识别重复编号、非法字符、缺少模块字段和无需求关联用例。规范只有进入工具校验和评审流程，才不会停留在文档里。

四、三种可直接落地的编号格式

1. 简单流水号：适合小团队和单一测试库

推荐格式为 TC-0001 或 TC-00001。它的最大优势是稳定、容易生成、几乎不会因模块调整而失效。对于产品规模不大、团队成员较少、平台筛选能力较强的团队，我通常会优先推荐这种方案。

它的短板也很明显：仅凭编号无法知道所属模块。因此，使用简单流水号时，必须把模块、测试类型、标签和需求关联维护好。如果团队仍然使用表格，就至少应增加“产品”“模块”“测试类型”“需求编号”和“状态”列，不能只保留编号与名称。

2. 模块型编号：适合单产品、多模块团队

推荐格式为 WEB-LOGIN-001。其中产品或端前缀用于划分命名空间，模块前缀用于降低人工检索成本，序号用于区分同一模块中的用例。

这种方案通常是可读性和稳定性的折中点。它比纯流水号更适合缺陷沟通和回归报告，又没有把版本、优先级等高变化字段写进去。缺点是模块字典需要治理，模块重命名或重新拆分时，要保留旧模块的映射关系。

3. 多维型编号：适合多产品、多团队和强审计组织

推荐格式为 APP-PAY-API-001，表示产品端、业务模块和测试类型。它适合团队经常在跨产品报告、自动化结果和缺陷沟通中手工识别范围的场景。

多维型编号不适合一开始就全量使用。很多团队在项目只有几十条用例时，就提前设计产品、领域、模块、类型、平台、版本和优先级七个字段，结果编号规则比测试内容本身更难学。多维型编号的前提，是组织真的有稳定的命名空间和明确的字段维护责任。

五、最容易混淆的四个概念与专业判断

1. 编号越有语义，是否就一定越好

不一定。语义越多，人工阅读越方便，但变化风险和规则学习成本也越高。编号的语义价值只有在团队确实需要人工识别时才成立；如果平台已经提供模块树、筛选器和全文搜索，多余的语义反而会变成重复维护。

我的建议是先从一个稳定维度开始。单产品团队可以先使用模块前缀，多产品团队再增加产品前缀，只有在测试类型经常被人工区分时，才考虑增加类型缩写。每增加一个字段，都应回答“它能减少哪一种真实的检索动作”。

2. 编号有空缺，是否说明管理不规范

不说明。空缺可能代表用例已经废弃、合并或迁移，是测试资产生命周期留下的正常痕迹。真正需要关注的是：空缺是否有记录、废弃原因是否可查、新编号是否被错误复用。

如果管理者要求编号必须连续，建议先说明重编号带来的风险，再提供替代方案：在报表中显示连续的行号，在平台中保留稳定的测试用例编号。行号可以变化，编号不应随意变化。

3. 测试类型是否应该写进编号

测试类型包括功能、接口、性能、安全、兼容性等。是否加入，取决于团队是否需要在不打开详情的情况下快速区分类型。如果平台已有“测试类型”字段，通常不必重复写入；如果自动化报告和缺陷沟通经常脱离平台流转，加入类型前缀可能更有帮助。

如果使用类型前缀，必须限定词典，例如只允许 F 表示功能、API 表示接口、SEC 表示安全，而不是同时出现 FUNC、FUNCTION 和 F。

4. 用例编号是否等于需求编号

不等于。一个需求可能对应多个测试用例，一个测试用例也可能验证多个需求或业务规则。把需求编号直接作为测试用例编号，会在一对多关系出现时失去唯一性，也会让需求修改牵连测试编号。

更合理的做法是建立独立关联：

• 需求：REQ-LOGIN-001
• 测试用例：WEB-LOGIN-F-001
• 测试用例：WEB-LOGIN-F-002
• 缺陷：使用独立缺陷编号，并关联失败用例。

这样既能实现一对多追踪，也不会把需求生命周期变化传导到测试编号。

六、一个完整案例：从混乱编号改造成可维护体系

1. 原始场景：800条用例、三种来源、四套命名方式

下面是我在测试资产治理中经常遇到的典型场景：一个企业级业务系统拥有Web端、移动端和接口服务，测试用例分别来自旧表格、研发团队脚本和新建平台。旧表格使用 TC001，接口团队使用 API_LOGIN_01，移动端团队使用 APP-001，平台导入后又产生一套系统标识。

问题并不在于这些编号格式谁更“错误”，而在于它们没有统一命名空间。一次登录失败可能同时关联三个编号，开发人员需要打开多个附件确认它们是否是同一个测试目标。

2. 改造方案：保留历史入口，不追求一次性“洗白”

改造测试资产时，最忌讳直接删除旧编号。更稳妥的流程是先冻结旧编号，再为新增或有效用例分配统一编号，同时建立旧编号映射字段。这样，历史缺陷、旧报告和自动化脚本仍然可以被查到。

例如，团队可以采用以下字段：

• 当前编号：WEB-LOGIN-F-001
• 历史编号：TC001
• 测试目标：正确账号密码登录成功
• 测试类型：功能测试
• 优先级：P0
• 适用版本：当前发布版本
• 关联需求：REQ-LOGIN-001
• 来源关系：由旧用例TC001转换而来

这种做法看似多了一列，实际上减少了后续沟通。任何人拿到旧文档中的 TC001，都可以通过历史编号找到当前对象，而不是依赖某位测试负责人记忆。

3. 改造后的判断结果：不是所有用例都必须加模块前缀

经过分类后，团队发现部分通用安全检查、公共兼容性检查和基础环境检查并不属于某个单一业务模块。如果强行给它们加上业务模块前缀，反而会制造错误归属。因此，最终方案采用“产品前缀加有限模块前缀”，公共类用例使用独立分类。

这说明编号设计不能只从格式出发。真实业务边界比编号模板更重要。如果一个对象天然跨模块，就应该通过分类字段表达，而不是塞进某个并不准确的模块编号。

七、不同情况下应该怎么选

1. 如果团队只有一个产品和少量用例

建议优先使用 TC-0001。此时最大的风险不是编号不够有语义，而是团队在格式上花费过多时间，却没有维护名称、步骤和需求关联。

行动顺序可以是：

1. 先保证编号唯一且不可复用。
2. 统一用例名称结构。
3. 补充模块、优先级和版本字段。
4. 规定废弃和复制处理方式。
5. 等跨模块检索成为高频问题后，再增加前缀。

2. 如果团队正在从表格迁移到测试管理平台

不要把迁移理解为“把Excel导入系统”。真正需要处理的是历史编号、重复用例、需求关联和自动化映射。迁移前应先确定哪些字段是身份字段，哪些字段是管理字段。

如果使用 PingCode 等支持企业级测试管理的平台，可以重点核对以下能力：是否支持私有化部署、是否能承接原有需求和缺陷关系、是否支持Jira平滑迁移、是否能通过接口或标签关联自动化结果。对于组织而言，国产替代的关键不在于界面语言，而在于历史资产、权限体系和研发流程能否连续运行。

迁移建议分两批进行：

• 第一批迁移有效且仍在回归范围内的用例，先验证编号和关联链路。
• 第二批迁移历史用例和废弃用例，保留原编号、来源和生命周期信息。

3. 如果团队拥有多个产品或多个交付团队

建议至少引入产品或系统前缀，例如 CRM-、APP-、API-。模块前缀是否加入，要看团队是否经常在平台之外引用编号。如果所有人都在统一平台中工作，产品前缀加独立模块字段可能已经足够。

这类组织还需要明确编号作用域：是整个企业全局唯一，还是每个产品库内唯一。两种方式都可以，但必须在规范中写清楚。否则，两个团队都创建 PAY-001，跨项目报告就会出现歧义。

4. 如果自动化测试占比较高

不要只设计人类可读的编号，还要考虑机器匹配。编号中应避免空格、中文和不稳定的特殊字符，自动化脚本通过标签、注解、外部映射表或接口同步关联测试用例。

我建议至少做一次“失败回溯演练”：随机挑选一条自动化失败结果，检查能否在五分钟内找到对应手工用例、需求、提交版本和责任模块。如果无法完成，问题通常不只是编号格式，还包括报告字段不完整或关联关系缺失。

5. 如果组织需要审计、合规或长期追踪

这时应优先保证编号稳定、变更可审计和历史记录可恢复。编号修改权限应受到控制，系统应保留变更人、变更时间、变更前后内容以及变更原因。

对于需要私有化部署的组织，还要把编号治理纳入权限和数据迁移方案。测试用例编号看起来只是文本字段，但它可能出现在需求、缺陷、发布记录、审计材料和自动化报告中，任何迁移都不能只验证当前页面是否显示正常。

八、编号设计中的取舍：可读性、稳定性和治理成本

1. 可读性和稳定性的取舍

简单流水号稳定性最高，但人工识别能力较弱；多维编号人工识别能力强，但任何模块重命名或测试类型调整都会带来维护成本。没有一种格式同时在所有维度达到最高分。

我的经验是，优先保证稳定性，再补足可读性。可读性可以通过名称、标签、模块字段和平台视图增强，而编号一旦变更，历史追踪关系却很难完全修复。

2. 人工可读性和机器可解析性的取舍

编号包含太多自然语言缩写时，人可能看懂，机器却难以稳定解析；编号过于简短时，机器容易处理，人又无法快速理解。解决方式不是无限增加字段，而是建立固定词典和独立字段。

例如，测试类型可以用枚举字段维护，报告中再显示“接口测试”，不必让所有脚本都依赖编号中的 API 字符串。只有在跨系统传输中确实需要自解释编号时，才保留类型前缀。

3. 统一规则和团队自治的取舍

完全统一容易变成总部制定、团队无法执行；完全自治则会导致同一概念拥有多个缩写。更好的方式是统一底层原则，允许局部配置。

• 全组织统一：大小写、分隔符、唯一性、不可复用、迁移保留。
• 产品层配置：产品前缀、模块词典和测试类型范围。
• 团队层执行：用例名称、标签和专项测试分类。

这样既能保证跨团队协作，又不会要求所有业务使用完全相同的模块名称。

4. 低成本启动和长期治理的取舍

规范不必一次设计到终局。可以先使用 TC-0001，当团队开始出现跨项目冲突时增加产品前缀；当人工识别测试类型成为高频动作时，再增加类型字段。渐进式演进比一开始设计一个包含十个字段的复杂编号更容易成功。

九、上线前的规范检查与实施步骤

1. 用一小时完成现状盘点

不要先开会争论格式。先随机抽取一批现有用例，统计编号重复、缩写不一致、名称模糊、没有需求关联和自动化无法回溯的数量。样本不需要覆盖全部用例，但必须覆盖不同模块、不同来源和不同生命周期状态。

建议至少记录以下观察结果：

• 当前编号格式有多少种。
• 重复编号和疑似重复用例有多少条。
• 编号中包含哪些高变化字段。
• 多少条用例可以关联到明确需求。
• 多少条自动化结果可以回溯到手工用例。
• 历史废弃用例是否仍然被报告或缺陷引用。

2. 用真实场景验证候选格式

候选格式不要只拿新建用例测试，还要拿历史用例、复制用例、拆分用例、跨版本用例和自动化用例测试。很多格式在“创建第一条用例”时很漂亮，在“迁移第500条用例”时就暴露出问题。

我建议至少模拟五个动作：

1. 创建同一模块的三条新用例。
2. 复制一条用例并修改测试目标。
3. 删除中间序号的一条用例。
4. 把一个大用例拆成三个独立目标。
5. 从旧系统导入并关联自动化脚本。

如果候选规则在这五个动作中都不需要修改历史编号，才说明它具备基本的生命周期稳定性。

3. 发布一页纸规范，而不是几十页制度

初版规范应该足够短，重点写规则、示例和例外。过长的制度文件容易被忽略，尤其是测试人员在迭代周期中需要快速创建用例时，不会反复阅读复杂条款。

一页纸至少包括以下内容：

4. 建立每月一次的轻量检查

编号治理不需要每天召开专项会议，但应该定期检查。每月抽查新增、复制和废弃用例，重点看是否出现重复编号、非法字符、缺少关联和不规范缩写。

如果使用测试管理平台，可以把检查转化为视图或规则。例如，筛选编号不符合正则格式的用例，筛选没有需求关联的高优先级用例，筛选仍被自动化引用但状态为废弃的用例。这样，治理从人工记忆变成持续反馈。

十、发布前检查清单与最终建议

1. 编号规则检查清单

• 是否能保证当前作用域内唯一。
• 是否明确编号由系统生成还是人工分配。
• 是否统一大小写、分隔符和序号位数。
• 是否建立产品、模块和测试类型缩写字典。
• 是否避免把优先级、状态、执行人和临时版本写入编号。
• 是否区分编号、名称、标签、版本和需求关联。
• 是否规定复制后必须生成新编号。
• 是否规定删除后不回收、不补号。
• 是否规定拆分、合并和迁移时如何保留历史关系。
• 是否能从自动化失败结果回到测试用例。
• 是否能从测试用例回到需求和缺陷。
• 是否明确规则维护人和例外审批人。

2. 三类团队的行动建议

小团队：先采用 TC-0001，把精力放在测试名称、需求关联和废弃规则上。只有当团队经常无法从编号判断模块时，再增加模块前缀。

中型团队：采用 WEB-LOGIN-001 这类模块型编号，建立统一缩写字典，并将优先级、版本和状态独立维护。复制、拆分和迁移规则应在正式推广前完成。

大型组织：采用有限维度的多产品、多模块编号，优先使用平台自动生成和审计能力。对于私有化部署、跨平台迁移和自动化关联，要把编号映射作为数据迁移验收项，而不是上线后的补救工作。

3. 最终判断：把编号当成稳定地址，而不是动态标签

测试用例编号命名的核心，不是追求一串让人一眼看出所有信息的编码，而是建立一个稳定的测试资产地址。地址负责找到对象，名称负责解释对象，标签负责分类对象，优先级负责排序对象，需求和缺陷关联负责说明对象为什么存在。

如果只能记住一条建议，我建议记住这一条：编号中只保留稳定且高频使用的命名空间，其他信息全部交给独立字段和关联关系。这条原则能同时降低重编号风险、提高自动化回溯能力，也能让团队在更换工具、调整模块和升级版本时保留历史连续性。

下一步可以从一个真实模块开始：抽取20条现有用例，分别用简单流水号、模块型编号和多维型编号做一次生命周期演练；记录创建、复制、拆分、废弃和自动化回溯的耗时与争议点，再选择最少字段但能覆盖主要检索场景的方案。最好的编号规范，不是设计出来的，而是在真实协作、真实变更和真实追踪中验证出来的。