软件测试之配置管理
一、软件配置管理原理
配置管理的常用术语有四个：配置，配置项，基线，版本标识
1、配置和配置管理的概念
配置：配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性，因此，“配置”包括了最终组成软件产品所有的文档，软件版本，变更文档，软件运行的支持数据，相对于硬件类配置，软件产品的”配置“包括更多的内容并具有易变性。
配置管理：配置管理就是通过对在软件生命周期的不同的时间点上所产生的文件进行标识，并对这些被标识的文件的更改进行系统控制，从而达到保证软件产品的完整性和可溯性。
2、配置项的概念
为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待，一个系统包括的配置项的数目是一个与设计密切相关的问题。
3、基线的概念
在配置管理系统中，基线就是配置项在其生命周期的不同时间点上通过评审而进入正式受控的一种状态，而这个过程被称为“基线化”，每一个基线都是其下一步开发的基准。所以基线具有以下属性。
（1）通过正式的评审过程建立。
（2）基线存在于配置库中，基线的变更由变更控制委员会（CCB-Change Control Border）控制。
（3）基线是进一步开发和修改的基准。
4、版本和版本标识
版本：版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变，版本以版本号进行标识。
版本号：命名规则为了维护软件项目，我们提出了对版本进行管理控制的要求，而对于用户来说，版本直接体现在版本号的命名上。
1、版本号的三种命名方式：
版本号由二到四个部分组成。主版本号和子版本号是必须要有的，修正版本号和编译版本号可以自己选择
（1）GNU风格的版本号命名格式
-
主版本号 . 子版本号 [ .修正版本号 [ .编译版本号] ] -
例如： 5.0.0 build-1234 主版本号 子版本号 修正版本号 编译版本号
（2）Windows风格的版本号命名格式
-
主版本号 . 子版本号 [ 修正版本号 [ .编译版本号] ] -
例如： 1.12 主版本号 子版本号 修正版本号
（3）. Net Framework风格的版本号命名格式
主版本号 . 子版本号 [ .编译版本号 [.修正版本号 ] ]
2、版本号的管理策略
（1）项目初版本时，版本号可以为0.1或0.1.0，当然也可以为1.0或者1.0.0。
（2）当项目在进行局部修改或者bug修正时，主版本号和子版本号都不变，修正版本号加1。
（3）当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加1，修正版本号复位为0（可以被忽略掉）。
（4）当项目进行了重大修改或者局部修改累积较多，而导致项目整体发生全局变化时，主版本号加1。
（5）编译版本号一般是编译器在编译的时候自动生成的，我们只定义其格式，并不进行人为控制。
5、配置库
配置管理活动需要在特定的数据库中完成，这个特定的数据库被称为软件配置库。
将软件配置项汇聚在一起，形成了配置库。
从广义上来讲，软件配置库可以包括开发库，受控库和产品库，从狭义上讲，软件配置库专指受控库。
6、主干和分支
分支的原因：
-
（1）团队协作的本质是分头工作并且相互配合。
- （2）分支可实现并行工作，多头前进，最后汇合，减少等待和阻塞。
- （3）分支可保证团队人员之间适当隔离，不可长期隔离。
- （4）分支也可保证团队人员之间适当共享。
7、版本控制（Subversion工具）
配置管理伴随着软件开发的历史逐步发展，产生的主要原因是管理难度的加大。
-
（1）软件复杂度增加。
- （2）参与协同作业的人员增加。
- （3）工作方式更加国际化。
所以软件配置流程引入配置管理员CMO（Configuration Management Officer）用于管理变更控制。
工具的出现帮助配置管理员自动化处理，工具应具备如下特性：
（1）维护文件库。
（2）创建和存放文件的多个版本。
（3）提供锁定的机制。
（4）标识一组文件的版本。
（5）从配置库中提取、找回文件的版本。
下面我们就来介绍关于版本控制的软件工具。
8、版本管理软件--（Subversion工具）
（1）Subversion（简称SVN）的概念
Subversion（简称SVN）是近年来崛起的版本管理软件，它是一个通用系统，可以管理任何类型的文件集。Subversion的版本可以通过网络访问，从而使用户可以在不同的电脑上进行操作，从某种程度上来说，允许用户在各自的空间里修改和管理同一组数据可以促进团队协作。
（2）SVN基本结构
SVN服务器分为Windows和Linux版本，有两种运行方式：独立的SVN服务器和借助Apache。
SVN的版本库（Repository），也叫项目仓库，就是位于服务器统一管理和储存数据的地方，对Repository最常用的操作就是签入（commit/check-in）和签出（check-out），就像出库和出库一样。
（3）悲观锁VSS（串行）和乐观锁SVN（并行）
悲观锁：
VSS是基于“锁定-编辑-解锁”模式的，这个模式，有一个弊端，就是当其他人在编辑相关文件的时候，此单元处于锁定状态，其他人如果想编辑这个单元文件的话，只能处于等待状态，
乐观锁：
-
SVN是基于“修改-冲突-合并”的一个模式，也就是说多个人可以同时签出一个单元文件，编辑然后提交，如果多个人都修改了同一文件的某一行的话，就会发生冲突，手工解决冲突。
（4）SVN的应用。
SVN中常用的提交、签出、更新命令是什么？
-
提交：commit； -
签出：checkout； -
更新：update。
*在SVN的配置管理模式下，如果两个人同时修改同一个文件的同一行，遇到了冲突可以如何解决？
Merge合并。
两人访问同一服务器：checkout 到本地 。 A先提交 。
B修改提交，提交时会提示out of date ,需要update ；update之后修改文件内容，删除不需要的内容，保存。
*在SVN的配置管理模式下，两个人各自修改了不同的行。
-
两人访问同一服务器：checkout 到本地 。 A先提交 。 -
提交之后会出现一个新的版本，这时B需要update，然后修改提交。
二、软件配置管理组织
1、配置管理角色介绍
（1）项目经理（PM项目负责人）
-
*制定项目的配置计划。 -
*制定CMO。 -
*建立项目的CCB。 -
*保证为项目提供合适的配置管理工具。
（2）配置管理员（CMO）、
*建立和管理配置项
*保存变更申请。
*基线化配置项。
*生成并发布配置状态发布表。
*将基线化的文档和计划分发给所有相关人员。
*管理配置库的访问权限。
*增加/删除配置项（仅在收到已获批准的请求时）。
*备份/恢复和归档配置库。
*想项目成员提供配置管理工具使用的指导。
（3）软件开发工程师（SWE）
*开发工程师将自己创建的与开发相关的配置项（比如需求规格说明书、概要设计、详细设计、代码等配置项）加入配置库中。
*开发工程师根据变更请求，对配置项进行check-out、修改、check-in的操作。比如测试人员在提交bug之后，开发人员应该在CMO授权之后，对相应的配置项（源文件）check-out、修改、check-in。
（4）软件测试工程师（STE）
*测试工程师将自己创建的与测试相关的配置项（比如软件测试计划、软件测试方案、软件测试用例、软件测试日报、软件测试报告等）加入配置库中。
*测试工程师根据变更请求，对测试相关的配置项进行check-out、修改、check-in操作。
*获取被测试的已发布的软件版本。
（5）质量保证人员（QA）
*基线审计。
*评审并批准配置管理计划。
*验证配置库的备份。
（6）变更控制委员会（CCB）
*评估和批准对配置项的更改。
*确保批准后的更改的实施。
三、配置管理的过程
根据IEEE的定义，配置管理的五大活动是指：
1、配置计划。
2、配置标识。
3、配置控制。
4、配置状态发布。
5、配置审计。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
