测试用例版本化与代码协同管理：从Excel到Git的落地实践

测试用例版本化这件事，我关注了很久，真正下定决心去推动，是在一次异常惨痛的回归事故之后。某产品线一个核心模块的接口行为悄悄变了，开发认为自己改的是内部实现，不影响外部契约，就没有同步任何信息。测试人员手里那份Excel用例还停留在三周前的逻辑上，照着跑了整整两天，全部通过。上线后线上立刻报障，问题的根因恰恰就是那个被改掉的内部行为对下游产生了数据影响。复盘会上，产品经理拎着那份Excel甩到我面前问了一句话，我到现在都记得：这份用例，对应的到底是哪一版代码？那一刻我意识到，测试用例如果不做版本化、不跟代码走同一条管理链路，那它就不是资产，而是负债。

这篇文章我就围绕"测试用例版本化与代码协同管理"这个主题，把后来逐步落地的一套方法、工具选型和踩坑记录完整展开。内容适合测试工程师、测试开发、测试团队负责人，以及正在为用例管理头痛的研发管理者。如果你所在的团队还在用"用例_v3_最终版"这种命名方式，或者用例和代码散落在完全不同的两套系统里，这篇文章应该能给你一个明确的改造路径。

1. 测试用例管理的现状之痛：Excel、网盘、文档满天飞

在聊方案之前，先花点篇幅把痛点说透。因为版本化这件事，本质上不是工具问题，而是管理思路的问题。如果不理解传统模式下问题出在哪儿，就算上了Git、上了平台，也照样会走回老路。

1.1 Excel是最大的"反版本化"工具

我知道很多团队到现在依然在用Excel管理测试用例，包括一些规模不小的公司。Excel本身不是不能用，但它有一个天然缺陷：没有任何原生的版本控制机制。一个用例文件被张三打开改了十条用例，保存后关闭，李四那边再打开已经是新的内容了。更麻烦的是，如果张三和李四同时改了同一个文件，后保存的人会覆盖先保存的人的全部修改，整个过程没有任何冲突提示。

这种模式催生了大量匪夷所思的文件命名。我见过一个团队类似这样的文件列表：

• 登录模块用例_初版.xlsx
• 登录模块用例_优化版.xlsx
• 登录模块用例_最终版.xlsx
• 登录模块用例_最终版2.xlsx
• 登录模块用例_千万别用这个版本.xlsx
• 登录模块用例_真正最终版.xlsx

你说可笑不可笑？但这就是测试资产管理的真实面貌。当一份用例经历了需求变更、缺陷修复、回归调整之后，真正生效的版本是什么、谁改的、为什么这样改，完全无迹可寻。更致命的是，Excel文件是二进制格式，就算你用Git去管理，每次修改所产生的diff也没法看——只能看出文件变了，看不出到底哪些用例变了。这一点后面会专门展开。

1.2 用例与代码脱钩带来的三种典型故障

我把用例和代码脱钩的后果归纳为三种典型故障，基本覆盖了大多数团队会遇到的问题。

第一种是用例滞后于代码。需求变更、技术方案调整、接口字段变化，代码已经合入主干并进入测试环境了，用例还停留在旧逻辑。测试人员拿着旧用例去验新代码，要么大量用例失败，要么用例跟实际功能对不上，用例的执行结果完全失去参考价值。这时候测试人员只能临时靠脑子补测试点，用例库反而成了负担。

第二种是缺陷无法复现。测试发现了一个bug，提交给开发时顺手附上了用例编号。开发打开用例管理表，发现那份用例已经因为"需求调整"被改得面目全非，原来的前置条件、数据构造步骤全都不存在了。开发没法按原样复现，bug被退回，测试人员也说不清当时到底是怎么测出来的。这种情况在Excel管理模式下非常常见。

第三种是自动化用例与手动用例割裂。很多团队自动化用例放在代码仓库里，手动用例放在Excel或测试管理平台上，两者互不相通。接口字段改名了，自动化用例跟着代码改了，手动用例没人改。等到做全量回归的时候，手动用例跑出来的结果和自动化用例跑出来的结果互相矛盾，你还不知道哪个是对的。实际上它们测试的是同一个功能，只是维护方式不一样，版本自然就漂移了。

这三种故障的根源都指向同一个问题：测试用例没有被当作一份需要版本管理、需要和代码保持同步的资产来对待。

2. 核心认知转变：测试用例就是一份与代码"同生共死"的规格说明书

如果只是把Excel换成Git仓库，但思维还是旧的，那么得到的结果不过是一个更乱的文件堆。真正的改造要从认知层面开始。

2.1 测试用例的本质：可执行的验收契约

测试用例是什么？本质上它是一份可执行的验收契约。每一组用例都描述了一件事：在什么前置条件下，对被测对象执行什么操作，应该观察到什么结果。这跟代码的关系是什么？代码是实现行为的东西，测试用例是描述行为期望的东西。两者描述的是同一个对象，只不过一个用代码语言，一个用用例步骤。

既然是同一个对象的两种描述，那么任何一种发生变化，另一种就必须同步。需求改了，代码要改，用例也要改。技术实现换了，代码要改，接口行为变了用例要改，就算用户可见行为没变，用例中涉及的前置条件、数据准备方式可能也得跟着调。所以用例跟代码根本不是两个独立的东西，它们天生就是一对孪生兄弟。

我用一个生活化的类比来解释这个关系：代码是一台机器的内部机械结构，测试用例是这台机器的使用说明书。机械结构改了却不改说明书，用户拿着旧说明书操作，轻则机器报警，重则直接损坏。版本化要解决的，就是让说明书始终保持和机器当前状态一致。

2.2 用例版本化要覆盖的三个层次

说到版本化，很多人以为就是把用例文件放进Git仓库，每次改完提交一下就算完事。这只是一层皮。真正完整的版本化应该覆盖三个层次。

第一层是用例文件本身的版本化。也就是用例文件本身纳入版本管理，每一次修改都有历史记录，可以回溯、可以对比、可以知道是谁在什么时间基于什么原因改了什么内容。这一层解决的是"第几个版本"的问题。

第二层是用例与代码的关联版本化。这是最关键也最容易被忽视的一层。用例和代码之间必须有明确的对应关系：同一份代码的某个提交，对应哪一份用例的哪个状态。说白了，当开发提交一个功能分支时，测试人员应该能在同一时间点拿到这个分支上应该被执行的用例集，而不是等代码合入了再到处找用例。

第三层是执行结果的版本化。一次测试执行产生了哪些通过、失败、阻塞、跳过结果，对应的被测代码版本是什么，用例版本是什么，执行人是谁，这些信息本身也需要留痕。否则当你面对一个线上故障时，只能说"当时测过"，但拿不出任何可追溯的证据来支撑"当时是基于哪个版本测的、测试覆盖了哪些场景"。

这三层缺一不可。只做第一层叫备份，做到前两层叫协同管理，三层全做到才算真正完成了版本化。

2.3 不是所有用例都适合进Git：先分清用例类型

有同事问过我一个问题：所有用例都要拿进Git仓库管吗？我把手写测试用例、探索性测试的思维导图、性能测试脚本也放进去？

答案是：不一定全部，但绝大部分功能性用例应该放进去。具体来说，我建议这样分类：

• 功能测试用例（包括手工执行的用例和自动化的用例）：适合纳入版本管理，与代码同分支协同。
• 接口测试用例：强烈建议纳入，接口用例跟代码的耦合度最高，字段变化、契约变更直接影响用例有效性。
• 探索性测试的测试点（checklist）：也建议纳入，但以Markdown或纯文本形式存放，不必走严格的用例模板。
• 性能测试脚本与场景配置：建议纳入，因为性能基准需要和版本对齐，否则无法做横向对比。
• 临时性、一次性测试记录：不建议纳入仓库，这类信息属于执行日志，留存案底走执行结果系统即可。

这个分类的核心判断标准只有一个：这份用例的生命周期，是不是跟代码的生命周期绑定？ 如果是，就纳入版本管理；如果是一次性的、跟版本无关的验证动作，就不需要进仓库。

3. 落地实操第一步：搭建测试用例的版本化仓库骨架

认知到位之后，接下来就是动手。这部分我给出一套可以直接照搬的目录结构和操作流程，都是经过实际项目验证的。

3.1 目录结构设计：按模块分区，与代码仓库一一对应

测试用例仓库最好是一个独立的Git仓库，我习惯叫它test-cases或qa-docs。但如果团队规模不大，也可以放在主代码仓库的tests目录下。两种方式各有优劣，后面会对比。这里先给出独立仓库的目录设计：

code复制test-cases/
├── README.md
├── .gitignore
├── docs/
│   └── test-case-writing-guide.md
├── functional/
│   ├── modules/
│   │   ├── user-auth/
│   │   │   ├── login.feature
│   │   │   ├── register.feature
│   │   │   └── password-reset.feature
│   │   ├── payment/
│   │   │   ├── checkout.feature
│   │   │   └── refund.feature
│   │   └── user-center/
│   │       ├── profile.feature
│   │       └── address.feature
│   └── regression/
│       └── smoke-tests.feature
├── api/
│   ├── auth-api.yaml
│   └── payment-api.yaml
├── data/
│   ├── test-data-common.json
│   └── sql/
│       └── setup-data.sql
└── environments/
    ├── dev.env
    ├── staging.env
    └── production.env

这个结构的思路是：按业务模块划分用例目录，跟代码仓库的模块划分保持一致。比如代码仓库里有一个user-auth模块，用例仓库里就应该有一个user-auth目录。这样在关联代码和用例时，路径天然对应，找人、找用例都快。

在functional目录下我放的是Gherkin格式的用例文件（.feature），因为这个格式既能被人阅读，又能被Cucumber这样的工具执行，是"人机共读"的最佳平衡点。如果你不想引入BDD工具链，也可以直接用Markdown写用例，区别无非是少了自动执行的便利，但版本管理和协同的逻辑完全一样。

3.2 用例文件格式选型：为什么我最终放弃了纯Excel

这里要专门说一个关键选型问题：用例文件到底用什么格式存？ 我对比过几种方案，列表如下：

我强烈不建议把Excel文件直接塞进Git。原因前面提过，二进制文件没法做逐行比较。你提交了一个xlsx文件，Git能告诉你的只是"这个文件变了"，但变在哪里、加了哪条用例、删了哪个步骤，完全看不出来。如果团队里有人偷偷改了一条用例但没有填变更说明，其他人只能干瞪眼。

Gherkin格式配合Cucumber、SpecFlow这类BDD框架，可以做到"同一份用例文件既能人工评审又能自动执行"。这意味着用例和代码之间真正打通了：代码仓库里引用的用例文件，就是测试人员评审过的那个版本，没有任何中间转换的失真环节。我在团队里推行Gherkin之后，用例评审会都变快了，因为大家看的是同一份文件，讨论的是同一个版本。

不过要说明一点：如果你们的测试人员完全没有接触过Gherkin，强行推行会有学习成本。折中做法是初期用Markdown格式，等团队熟悉了git工作流，再逐步向Gherkin迁移。

3.3 Git仓库初始化与首次用例入库

选定目录结构和文件格式之后，就是初始化仓库。我这里给出一套完整命令，你可以直接复制执行：

bash复制# 创建用例仓库目录
mkdir test-cases && cd test-cases

# 初始化Git仓库
git init

# 创建基础目录结构
mkdir -p docs functional/modules/user-auth functional/modules/payment api data/environments

# 创建并填写README，说明用例库的使用规范和目录约定
vim README.md

# 创建.gitignore，忽略敏感文件和本地临时文件
vim .gitignore

# 添加并提交首批文件
git add .
git commit -m "chore: 初始化测试用例仓库，建立目录规范和基础配置"
git branch -M main
git remote add origin git@your-git-server:qa/test-cases.git
git push -u origin main

这句commit message里，"chore"也好"docs"也好，看团队习惯，但建议遵循常规的conventional commits规范，因为后面做用例评审时会依赖commit信息来快速判断改动意图。

.gitignore文件里我建议至少包含这几项：

code复制# Excel临时文件
~$*.xlsx
*.xlsx

# 系统文件
.DS_Store
Thumbs.db

# 环境配置（可能包含敏感信息）
.env
*.local
*credentials*

这里有个重点：环境配置类文件绝对不要跟用例一起提交，尤其是涉及数据库连接串、账号密码、环境URL的文件，否则一次误提交就可能把整个测试环境的凭据暴露在仓库里。如果确实需要保存环境间的变量差异，我建议用模板文件加脱敏的方式，比如提交一份dev.env.example，里面只放变量名不放真实值。

3.4 版本策略：给用例库打上语义化版本的Tag

用例库有了commit还不够，还需要一个面向"发布"的版本策略。我的做法是：给用例库打Tag，Tag号与产品版本的迭代周期对齐。

产品每个迭代是两周，每两周打一次Tag，Tag名称就是产品版本号，比如v2.3.0。这个Tag对应的用例库快照，就是QA团队对外承诺的"这一版产品的完整测试基线"。

code复制git tag -a v2.3.0 -m "用例库基线：对应产品版本2.3.0，覆盖功能用例286条"
git push origin v2.3.0

这个做法的意义在于：当测试环境、生产环境部署了某个产品版本时，QA团队随时可以切到对应的用例库Tag，获取一份确定性的用例集合。而不是像以前那样，环境已经部署到2.3.0了，用例表还停留在2.1.0的需求上。

如果产品已经进入维护期，多版本并存，通常还要配合分支策略。比如release/2.3，这条分支维护的就是2.3.x这个版本线的所有补丁用例和回归用例。这个在下一节详细展开。

4. 与代码协同管理：分支策略、提交规范与CI联动

目录和版本策略是地基，这一节是在地基之上搭房子。测试用例要真正和代码协同起来，靠的是分支策略、提交规范和持续集成三套机制的配合。

4.1 分支策略：让用例和代码永远处在同一条时间线上

关于测试用例分支策略，我推荐一个简单可靠的模型：代码仓库每创建一个功能分支，用例仓库就在对应模块目录下创建同名的用例分支。

举例来说，开发在代码仓库创建了一个分支feature/payment-refund-optimize，专门做退款优化的需求。与此同时，测试人员在用例仓库里创建同名分支feature/payment-refund-optimize，针对这个需求设计用例。代码在功能分支上改的同时，用例也在功能分支上生长。二者合并回主干的时间点应该尽量接近：

• 开发把功能分支合入测试主干分支后，测试就可以切到用例仓库的对应分支验收用例。
• 等到功能通过测试验证，代码合入发布分支时，用例也应该合入用例仓库的release分支。

这套流程保证了用例和代码永远处于同一条时间线上。代码改了，用例一定跟着改，不存在"代码已经变了但用例还是旧版本"的漂移窗口。

对于维护期的hotfix分支也一样，代码切hotfix/xxx分支修复线上问题，用例仓库同样创建对应分支，补一条或若干条针对该问题的回归用例，代码合入，用例也合入，形成一个闭环。

4.2 提交规范：让每一次用例变更有据可查

分支有了，提交信息也要规范。用例仓库里的commit message，我要求团队遵循一个固定模板：

code复制<type>: <subject>

<description>

关联需求: #REQ-1024
关联缺陷: #BUG-1088
用例状态: 新增/修改/废弃
涉及模块: payment/refund

其中type和代码提交一样，使用feat、fix、refactor、docs这些类型。一眼看过去，仓库的变更历史就像一份审计日志：

code复制fix: 修正退款金额边界条件的预期值

- 修改“退款金额大于支付金额”场景的预期结果
- 原预期为“允许部分退款”，实际系统行为为“拒绝并提示错误”

关联缺陷: #BUG-1088
用例状态: 修改
涉及模块: payment/refund

这套规范最大的价值在于可追溯。三个月以后有人提问"为什么这条用例的预期结果是这样"，去Git仓库一查commit，写得很清楚：因为BUG-1088，系统行为变了，用例跟着调整。这在Excel时代是完全做不到的。

关于如何保证commit message不流于形式，我们还会在代码评审阶段（MR/PR）同时检查用例变更是否合理，这个在下一节讲。

4.3 CI联动：用例执行跟代码提交绑定

这是"协同管理"的临门一脚。如果用例只是放在Git仓库里但执行时还要人工去找、去手动导入用例管理系统，那这个协同就缺了最后一段。

CI联动的逻辑是：代码触发构建和部署，部署完成后自动从用例仓库拉取与当前分支匹配的用例集，执行后把结果回填到测试管理系统。整个过程用一条流水线串起来，不需要测试人员手工干预。

我以GitLab CI为例，给出一个简化版的运行流程：

yaml复制stages:
  - build
  - test

# 代码构建阶段
build-job:
  stage: build
  script:
    - echo "构建代码..."
    - ./gradlew build
  only:
    - merge_requests

# 测试执行阶段
test-job:
  stage: test
  script:
    - echo "拉取测试用例..."
    - git clone -b $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME --single-branch git@qa:test-cases.git
    - echo "执行API测试用例..."
    - run-api-tests --config environments/staging.env --test-dir api/
    - echo "执行功能测试用例..."
    - run-bdd-tests --test-dir functional/
  artifacts:
    paths:
      - test-reports/
  only:
    - merge_requests

这个配置的关键是那一行git clone -b $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME，它让CI拉取的是与当前MR同名的用例分支，而不是默认分支。这就是"协同"的落地形式：代码分支配代码，用例分支配用例。

只要这个配置起来了，开发提交一个MR，CI自动跑到最后一关"测试"，用的就是当前分支上的最新用例。开发改的接口字段，测试用例也在同一个MR分支上同步修改过，执行结果就是有效的。

4.4 需求与用例双向追溯：从需求ID到用例ID的关联

协同管理还有一个容易被忽略的环节：需求、代码、用例之间的双向追溯。

我在用例的Gherkin文件头部约定了一个元信息区，用@标签关联需求ID：

gherkin复制@REQ-1024 @payment
Feature: 退款优化
  作为支付模块的使用者
  我需要申请退款
  以便在交易失败时获得资金返还

  Background:
    Given 用户已经完成一笔成功的支付交易

  Scenario: 退款金额不超过支付金额
    When 用户提交退款申请
    And 退款金额等于支付金额
    Then 系统应返回退款成功

这样每一组用例都能直接对应到一个需求ID。在代码仓库层面，commit message里也会带上需求ID。三条线通过ID串联起来：

• 需求ID（REQ-1024）在需求管理系统里能找到完整的需求描述。
• 代码仓库里搜REQ-1024，能找到所有相关提交和MR。
• 测试用例仓库里搜REQ-1024，能找到所有针对该需求的用例。

任何一个环节的变更，都可以通过ID反查出另外两个环节的对应状态。这是给审计、对接、故障复盘提供的最后一块拼图。

5. 从个人习惯到团队规范：把用例评审和内建质量意识焊进流程

推行测试用例版本化，技术层面的坑都容易填，最难的是改人的习惯。很多人已经习惯了Excel里随手改、随手存的自由，突然要他们走Git流程，第一反应就是：麻烦。所以这一节讲流程设计，如何让版本化变成团队的自然行为，而不是额外负担。

5.1 把用例评审嵌入Merge Request流程

以前团队的做法是：每周开一次用例评审会，测试人员把Excel投到屏幕上，一张张过。这种方式有两个问题：一是评审时间严重滞后于用例编写时间，等评审时写的人可能已经忘了当时的上下文；二是Excel展示的用例和最终执行的用例可能不是同一个版本，评审改完之后，实际上线执行的还是改动前的。

我把用例评审改成了"伴随式评审"：测试人员在用例仓库创建功能分支、写完用例后，直接发起一个Merge Request，把测试组长和被测模块的开发拉进来评审。评审内容和代码评审一样，直接在GitLab的MR界面里逐行评论、讨论、修改。

这样做的好处非常直接：

• 用例评审的时间点从"用例全部写完"提前到"用例每写一部分就可以评"，反馈更及时。
• 开发直接参与用例评审，能提前发现测试人员对需求理解的偏差，而不是等测试执行时才发现用例设计错了。
• 所有评审意见都留在MR的讨论记录里，可追溯。以前开会评审的结论，散落在会议纪要里，没人再翻，现在全部进了MR历史。

为了减少"每个人偏好都不一样"带来的争论，我还做了一份《测试用例编写与评审规范》，其中评审重点包括：

5.2 变更纪律：需求变更时，用例必须同批提交

还有一个细节，我对团队有一个硬性要求：任何需求变更，没有同步更新测试用例，就不算完成。

这句话不是喊口号，而是写进了Definition of Done。在团队看板上的每个需求卡片，列了一个专门的DoD清单：

1. 功能代码已开发并提交。
2. 自动化测试脚本已更新并通过。
3. 手工测试用例已在用例仓库中同步更新。
4. 用例变更MR已通过评审合并。
5. 测试执行结果已回填。

只要第3、4条有一条没完成，需求就不能标记为"已上线"。刚开始团队会觉得这个要求苛刻，但坚持两三个迭代之后就会形成肌肉记忆。因为大家发现，等上线前再来补用例，往往要花更多时间去回忆当时的场景，远不如在开发过程中顺手就改掉来得轻松。

关于探索性测试的处理，也简单说一下。探索性测试天然是"无脚本"的，我没法强制它走用例仓库流程，但我要求探索性测试的发现必须沉淀成用例回归库。具体做法是：发现了一个新bug，验证完修复之后，需要补一条回归用例进用例仓库，防止这个问题在将来某次重构中悄悄回归。这个"验证完就沉淀"的习惯，对老项目尤其重要。

5.3 让测试执行结果和用例版本关联

执行结果的版本化，我在这部分开头提过，这里展开讲具体操作。

测试执行完之后，除了把测试报告上传到管理平台，我还会在用例仓库里打一个执行快照Tag，命名规则是testrun-<版本>-<日期>。这个Tag不标识用例内容有变化，只标识"在某个时间点，基于这个用例库版本，执行了一次测试"。测试报告本身则放到独立的测试报告目录或平台，报告文件命名带上这个Tag。

code复制test-reports/
├── testrun-v2.3.0-20240615/
│   ├── functional/
│   │   ├── login.html
│   │   └── payment.html
│   └── api/
│       └── auth-api.json

这样做的场景价值在哪里？如果半年后线上出了一个故障，产品经理问你"当时这个模块不是测过吗？测试用例是什么？执行结果是什么？"，你可以拿出一条完整证据链：用例库Tag对应的一组用例，报告目录里对应的一次执行结果。被测代码的版本有代码仓库的commit可以追溯，被测代码对应的用例版本有Tag可以追溯，测试报告有文件名和执行人信息可以追溯。三层对应，没有任何一个环节是模糊的。

6. 推行版本化过程中的真实踩坑记录

最后这部分，把我在实际推动过程中踩过的坑、以及最终总结出的解法原原本本写出来。这些坑不是从书本上看来的，都是真金白银换来的教训。

6.1 xlsx与冲突地狱：一个"最终版"引发的血案

我们团队最早是把Excel用例拿进Git管理的，当时想着"先管起来再说"。第一个月还算风平浪静，直到两个测试同事同时改了同一张"订单流程"Excel。其中一个人用老版本覆盖了新版本，回滚时又冲突，来回折腾了几个小时，最后只能靠Git的历史版本逐版恢复。

那次之后我下定决心换格式。但换格式不是简单地把Excel另存为Markdown，而是要重建用例结构。我们花了整整一天，把之前Excel里几百条用例逐条搬到.feature文件里，核对前置条件和预期结果。这个过程很痛苦，但做完之后发现之前Excel里有一堆重复的用例、过时的用例、甚至是自相矛盾的预期结果——这些问题在Excel时代完全看不到。

我的经验是：迁移格式不是一次性的文件转换，而是一次用例资产的质量盘点。想清楚这一点，迁移过程就不会觉得枯燥了。

6.2 敏感信息泄漏：差点把数据库密码推到远端

有一个非常现实的坑，发生在我们配好.gitignore之前。当时一位测试工程师准备提交一批接口测试用例，顺手把本地的一个application.yaml配置文件也加进了提交。这个文件里有测试环境的数据库连接串和管理员账号。庆幸的是，他commit之后还没push，就被我抽查时发现了，及时拦截。

但这个事件让我意识到，只靠.gitignore是防不住人的疏忽的，还得有自动化的防护。后来我在用例仓库的CI流水线里加了一个敏感信息扫描脚本，用简单的正则匹配在push后自动扫描提交内容，一旦发现password、secret、token等关键词且不是脱敏值，就立刻拦截并通知提交人。这种做法成本不高，但能挡住绝大多数低级失误。

6.3 用例仓库膨胀：从单体仓库到模块拆分

用例入库的初期，所有模块的用例都堆在一个仓库里，一开始没什么问题，等用例规模超过两千条时，问题开始浮现：每次clone仓库越来越慢，MRIreview的范围越来越大（一次改动涉及多个模块的目录），分支变多之后，某些分支的MR长时间不合并，积累了大量冲突。

后来做了一个简单拆分：按业务域拆成三个仓库——test-cases-user、test-cases-payment、test-cases-order。每个仓库只负责对应的模块，团队里三个人各负责一个仓库的维护权。效果立竿见影：clone速度恢复，分支协作清晰，评审范围也缩小了。

如果是小团队，我的建议是：一开始就按业务域从物理上拆分出来，不要等仓库膨胀了再拆。如果早期就有一个明确的模块边界，拆分的成本几乎为零，但等用例堆到几千条再拆，光是移动文件、修正关联关系就要花很多时间。

6.4 老用例的"僵尸化"问题：版本化不等于永久保存

推行版本化一段时间之后，我遇到一个意想不到的问题：用例库里出现了一堆"僵尸用例"。这些用例如今仍然存在，也仍然会在每次回归时被执行，但它们描述的需求早已下线、功能早已重构。它们之所以还在库里，是因为没有人专门去标记废弃。

版本化恰恰会放大这个问题。以前Excel模式下，用例没人清理，顶多就是文件乱点；但在Git仓库里，僵尸用例会让所有人对用例库失去信任：这版用例描述的功能现在已经不存在了，那这份用例库还有参考价值吗？

所以我在流程里专门加了一条：功能下线或重构时，必须同时废弃对应的用例。功能下线的需求卡片，DoD清单里加了一项"用例仓库中对应的用例已标记废弃或删除"。删除时也不是直接从仓库抹掉，而是打上@deprecated标签并在feature文件头部注明废弃原因和版本。这样老功能如果要想回退，旧用例仍然可以通过历史Tag找回。

6.5 最大的坑其实是"人"：如何让团队接受新流程

说到最后，所有工具和流程的落地，最大的阻力还是人。

一开始我们团队里也有人很不理解，觉得"写用例就写用例，为什么还要学Git、还要搞分支，这不是搞乱了吗"。我当时的策略是：先不要强行全面铺开，找一个最容易见效的项目试点。选了一个接口变更频繁、缺陷率最高的模块，由我和另外一个技术好的同事先试跑，其他同事看热闹。

试跑过程中，我们把所有接口字段变化的用例同步提交记录展示在周会上，开发看到bug修复后马上能看到对应的回归用例入库，这个"快速闭环"的效果很快就打动了一批老测试。等他们发现"以前总因为用例版本对不上而扯皮的事情，现在不再发生了"，新的流程就跑起来了。整个推广花了大概两个迭代，算下来不比单纯在Excel里改用例多花时间，甚至因为少了很多来回沟通，整体效率反而提升了。

如果让我总结推动流程变革的一句话经验，那就是：别跟人讲大道理，直接做出一个大家都看得见的好处，自然有人跟你走。

最后补充一点个人实践中的小技巧：在用例仓库的README里，可以放一张"用例状态徽章"（badge），显示当前主分支上用例的总数、自动化执行通过率。挂在团队主页上，每天轻扫一眼，比任何周报都直观。另外，如果团队对BDD工具体系暂无计划，用纯Markdown管理用例也不是不行，但一定坚持"纯文本"这个大前提，这是所有版本化和协同操作能够成立的地基。