在软件测试中，我们经常会接触到“版本控制”这个概念，很多同学会想当然的理解成“产品的版本”、发布包的版本。诚然，这些版本控制好了，有助于测试对象的清晰界定。不知道大家有没有想过“测试用例的版本控制”，在实际的工作中，大家又是如何有效的管理测试用例的版本呢？今天我们就一起来聊一聊，希望读完这篇文章，有助于大家理清思路。如何成长为测试专家，钻进去，再钻出来，你就是专家。

在测试过程中，我们经常会遇到各种概念，不能一味的依赖工具系统的名词定义，而要脱离系统，想一想，如果我们没有工具，这些工作应该是什么样，工作流应该如何组织？

        1.代码的版本管理

这是中一个十分重要的工程手段，几乎是必须的一个Process(过程)。很多作坊式的开发团队在采用软件工程的一些方法的时候，第一个要进行改进或增加的，往往就是这个过程。

在服务器端建立该项目的数据库，并保存你选定的项目源文件的第一个版本。客户端任一用户要获得某源文件的修改权利，需进行check out操作。之后客户端一般每完成一个无编译错误的版本想保存的时候，进行check in操作，将当前版本保存在服务器端上并成为最新版本（注意，不是覆盖以前的哟）。任一客户端可以方便地得到服务器上的文件的任意版本（如果有权限的话）。一般还实现了一个重要的功能是版本比较，任一客户端可以利用版本控制工具对某文件的不同版本进行版本比较，它会标记出不同版本的同名文件的不同点，可以轻易地看出版本内容的演化，这一招很常用。

很多强大的工具能有效支持我们进行代码的版本管理，如Git、SVN、Perforce、VSS等等，我从业12年以来，从最初的VSS，到P4，到SVN，到Git，工具的触类旁通，大致相同，带给了我们很多便捷。这里就不一一介绍这些工具的使用方法和优缺点了，大家可以去网上查到很多资料

        2.发布包的版本管理

传统软件生命周期中，我们经常会遇到V1.0,V1.1,V2.0等等版本，针对每个版本， 我们需要建立matrix，发布日期， 产品release note，责任人，各种角色定义， 版本的存储方式以及针对的目标客户。

随着CICD、持续集成的深入人心， 快速生成一个可以使用的高质量的产品包，对于提升企业的竞争力至关重要。而如何分类“snapshot”、“release”包，依赖于一个强大的CICD工具体系，如Jenkins、TeamCity等。

如何CI Build，如何对CI Build进行快速测试，如何挑选质量好的、某个milestone的包成release 包，这些都依赖于系统和自动化测试的快速实现。

3.测试用例的版本控制

在上图中，我们可以看到“测试管理系统”，在有些公司，使用Excel进行测试用例管理，标注成1.0，或者用SVN来管理excel，进行版本管理，这算是测试用例版本控制的初级阶段。 

我们首先来理解一下，为什么要有测试用例的版本控制？

首先产品需求是迭代的，且是会发生变化的，在随着V1.0产品发布的需求定义FeatureA 1.0，有可能在2.0产品中进行了修改，得到了 FeatureA 2.0。 那这样，我们针对FeatureA 1.0就需要进行更新维护。

而当初在针对V1.0产品测试的时候，测试是已经通过的。

如果我们这个时候无法追踪V1.0产品的测试案例的内容，就无法得到当初真实的测试状态，从而无法证明该功能当时的测试场景和测试结果。这个时候，如果，万一，真的可能哦，客户说这里发生了一个Bug，但实际上在V1.0的测试范围，需求定义和测试用例设计却都是针对当时的产品和当时的需求，我们如何证明测试案例的有效性呢？所以有效还原测试用例V1.0就变得非常有意义了。

在TestLink中，如下，当你click “Create a new version”，测试用例的版本就会升级一个，作为一个独立的用例来存储，且会有时间和作者的信息追踪。