配置管理的概念

配置管理是通过对在软件生命周期的不同的时间点上的软件配置进行标识，并对这些被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。 

配置项

配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。一个系统包括的配置项的数目是一个与设计密切相关的问题。

配置项分类

常见的配置项分类如下：

• 合同类文档：建议书、用户意向书、用户需求、工作任务书、合同等

• 计划类文档：包括各类项目相关计划，比如项目过程手册，项目计划，配置管理计划等。

• 工程类文档：包括需求规格文档、测试计划、测试用例等设计文档等

• 程序代码：所有开发的源代码，包括各类支持数据，二进制文件

• 第三方程序代码：有供应商提供的源代码，并接受供应商的维护

• 工具：支持软件开发、简历、维护的工具管理，比如语言开发工具，编译工具，测试工具，配置管理工具等。

• 用户文档：包括用户手册，安装指南等

• 运行环境：包含系统运行环境的相关内容，比如系统运行平台，环境设置要求等。

基线的概念

在配置管理系统中，基线就是配置项在其生命周期的不同时间点上通过评审而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的基准。基线具有以下属性： 

1、通过正式的评审过程建立。 

2、基线存在于配置库中，基线的变更由变更控制委员会（CCB-Change Control Board）控制。 

3、基线是进一步开发和修改的基准。 

版本的概念

版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。版本以版本号进行标识。 

版本的命名

以我之前接触到的华为的版本命名规范简单介绍一下，当然这个不是一个统一的标准，仅供参考。我记得当时所在的部门好像是采用VxxxRxxxCxxxBxxx的格式去命名版本号。

配置管理角色介绍

•  项目经理(PM)

•  配置管理员（CMO）

•  软件开发工程师(SDE)

•  软件测试工程师(STE)

•  质量保证人员(QA)

•  变更控制委员会（CCB)

这里的话，主要介绍一下这个CMO和CCB。

    CMO的话，可以理解为跟部分运维的工作有点类似，亦或者说是跟CI工程师的工作也有类似的地方，他们主要在公司负责给分配一些配置仓库的权限，代码发布流程中相关文档的归档等。比如每次提交发版申请的时候，就需要附带上部署包和对应的部署文档，测试报告等，归档到某个目录，一旦提交申请，开发人员就没有权限再对目录中的内容进行修改。

    相信大家在日常工作中，经常遇到过项目做到一半，需求发生变更了，导致项目延期。在小公司，一套标准的流程是很难执行下来的。很多时候往往考虑到时间成本、人力成本等，都没有采用标准的流程。但是，久而久之，也会暴露出很多因为流程不规范而引发的问题。CCB的成立，主要用来评估项目过程中的变更及范围和影响的评估。

    在项目开始时，由项目负责人根据项目的情况确定CCB，也可以根据更改请求的情况事件驱动地召集CCB会议。如有必要，可以设立不同级别的CCB，他们具有不同的授权，对不同层次的变更申请进行控制。根据修改的影响范围，CCB召开相应的评估会议，并邀请相关人员参加。一般项目里面有需求变更，肯定会有知会大家，项目级别的CCB设立可能比较少，更多的可能是QA团队的人在公司层面整体设立CCB小组，跟进各项目过程质量。

基线变更流程

为什么要了解这些配置相关的东西呢？

作为一个测试人员，尤其是作为一个刚接触这行，甚至可能还没入行的人员，除了对测试的岗位和职责划分要清楚之外，还需要了解公司的岗位划分，项目的流程等信息，对其他岗位的大致职责也要有一个简单的了解，这些岗位都有可能是你在入职之后的工作中有可能需要去打交道的，要避免到时候别人一跟你说找哪个哪个岗位的人，然后你听着一脸懵逼。初学者在求职的时候，容易被刷掉的一个点主要也是在于项目细节，通过很多旁敲侧击的提问，就可以了解到你到项目的熟悉程度，有没有真的参与过项目的测试工作。

文章来源: xiaobotester.blog.csdn.net，作者：小博测试成长之路，版权归原作者所有，如需转载，请联系作者。

原文链接：xiaobotester.blog.csdn.net/article/details/120123496