配置管理
从某个角度来说，我一直觉得配置管理才是软件开发的最基本内容，注意这里我说的是软件开发的基本，不是测试！那么和测试有啥关系呢？
在解释这个问题前，我还是想先聊点别的，最后大家自然就知道答案了。配置管理到底是啥，简单来说就是版本控制和回溯，虽然这个概念说出来其实不太对，但是对于大多数情况来说确实就是这么回事。
在配置管理这个话题上可以说的很大，但是也可以说的很小，我觉得这么抽象的一个理论还是用个简单的例子来说明吧。
图书馆大家都应该知道，如何保证图书馆内的书被有效的借阅、订正、标记？这个和软件开发有异曲同工之妙。对于一个图书馆里面有成千上万的图书，每本书都有其独一无二的作用，等待着合适的人去阅读它，标记它，也许也会损坏它。如何知道它的历史，这就需要一个所谓的配置管理系统来记录。
图书馆管理系统
一般来说图书馆管理系统的需求包含：1.会员2.订阅归还记录3.查询和业务规范
会员：
图书馆系统需要一个能够唯一锁定会员的记录，用来确保能够通过这个会员信息找到负责人。那么当他损坏了图书之后，可以有效的追查和惩罚。
订阅和归还记录：
在图书馆系统中，当用户订阅图书的时候要首先做是否拥有可以借阅的图书，借阅锁定，出库记录的过程。在当前用户记录下就会有该书被借阅的记录，而该书也会有被用户借出的记录。按照配置管理的说法这就是标准的串行配置管理的锁定/解锁模式，同一个资源只能被一个人使用。
在归还的时候，系统会检查该书是否是被该用户借出，并且记录信息是否一致及图书是否完整，如果没有问题才进行归档，并且标记该书已经被归还。
查询和业务规范：
图书馆中需要方便别人查询一共有多少图书，那些图书比较常用，在哪里能找到这本书等信息。另外一方面图书馆都有自己的业务规范，每个用户能借几本书，哪些书能借，哪些书不能借。
通过这样的一个图书管理系统，图书会永远属于可控可追溯的过程中，一本书从进入图书馆，被借阅了几次，到最后淘汰或者损坏都被有效的记录了。
那么对于软件来说，大家有没有考虑过这个问题？每一个类可能都是一本书，每个方法可能都是书里面的一个章节，而每行代码可能都是某个章节的一句话。当一个代码被多人共同维护的时候，你怎么保证到底谁改了它并且改对了它？
从这个角度来说如果没有配置管理，软件几乎根本无法做出来的，而对于测试来说，如果一个软件都是不能稳定可控的，那么怎么能够为其提出缺陷呢？
还记得提交缺陷的时候要说明版本号么？因为版本号是通过配置管理工具打基线后锁定形成的。
配置管理概念名词
其实我是个很讨厌名词的人，但是对于配置管理的某些名词我又会觉得非常的体贴和温暖。首先最常见的名词无非是：
1.配置项
所谓配置项就是归纳在配置管理体系中的内容，大家可以简单点认为就是打了标签的一个商品放在超市里面。
2.基线
所谓的基线就是受控的一个状态体系，可以简单理解成超市打折活动，在这个活动中的所有商品都要按照这个折扣体系来计算金额，所以这些商品在这个打折活动上是一个基线。通过基线我们可以快捷方便的找到某个状态下的所有内容。
3.checkin/checkout
检入检出机制，这个概念在串行配置管理体系中用的很多（关于串行和并行的概念我们后面再说），通过Check out检出这个操作，可以将需要的配置项进行锁定，进入独占模式，只能归属于当前进行该操作的用户使用。而Check in检入操作就是将锁定的内容还给服务器，解锁这个文件的过程。通过这组操作就能让一个文件只有一个人修改，并且记录下做了什么。
4.update/commit
更新和提交，这个概念来自于并行配置管理体系。通过update可以更新本地和服务器之间的信息，而commit是将本地信息提交到服务器上的过程。
5.串行和并行配置管理/分布式配置管理
其实这个话题可以说的很大，但是我还是用最简单的概念来说一下这个问题吧。串行配置管理体系是标准的图书馆模型，对于一本书要唯一锁定模式，也就是一本书不能同时借给两个人。但是在具体的开发过程中存在这样的问题，两个人需要维护同一个代码的两部分，或者这样说一本书两个人都要看，一个人看前10章一个人看后10章，这个其实没有冲突的，但是由于书本身不能原子化分割，导致了前一个人占用了他不需要的资源，而后一个人还要等资源释放。那么并行配置管理方式就采取了冲突、解锁的模式来处理。好比是图书馆占座一样，谁都可以用这个资源，但是都是拿到了一份拷贝而已，再同步的时候就存在后使用的人需要处理先使用的人所带来的变更问题。在这里我觉得不太好说明白，只能说谁最后吃完饭，谁洗碗吧。
除了常见的串行和并行配置管理，还有个分布式配置管理的概念，虽然这里我也觉得这个名词是不是用的有点问题，但还是先用这个概念吧。
无论是你用串行还是并行模式都有一个问题，它需要一个集中式的服务器，就是你无论如何都要去图书馆那里去做点操作，而现实情况是你如果出差了或者别的情况，你是无法访问服务器的，那么你本地的变更就会缺乏受控的跟踪过程。分布式配置管理的概念就是我可以在我自身存在版本的管理体系，而也可以在有网络的情况下和服务器进行本地版本同步到服务器上的情况。
上面简单说了下常见的配置管理名词，其实这里面还有个配置基线变更流程，但是我觉得这东西到处都有，我就不想谈了，注意关键字就是基线变更后需要通过评审归档就行了。
配置管理工具
最后来简单说一下配置管理工具，基本上大家在公司里面用的应该比较统一了，如果早期的公司可能还在用ClearCase这类的工具，做C#开发的可能有一部分在用TFS或者VSS，剩下的基本上都是在用SVN或者GIT了。
其中VSS是比较典型的串行配置管理工具；SVN是比较典型的并行配置管理工具；而GIT我算它是分布式配置管理工具吧。
工具本身上手都不难，关键在于是否明白它帮你解决了什么问题。
最后再来说一下为啥配置管理会在测试的知识体系中出现，并且强调其重要性。首先无论是前面说的测试用例、缺陷、还是需求都是配置项，它们都需要合理的版本管理和回溯。许多大型企业都会由质量部（SQA）制定相应的质量过程管理，测试部也需根据测试阶段的不同，填写配置信息申请打基线。保证测试工作的产出清晰及可追溯。虽然过程管理有时显得繁琐并没有创造力，但如果被测试的开发内容没有配置管理，就无法正常的进行测试。你总不能对着一个不停在变的系统做测试吧？
对于一个测试人员来说，被测环境一定要可回溯、稳定，才能保证测试的工作不会是无效的。