配置管理工程师面试题目.docx

配置管理工程师面试题目.docx

《配置管理工程师面试题目.docx》由会员分享，可在线阅读，更多相关《配置管理工程师面试题目.docx（15页珍藏版）》请在冰豆网上搜索。

配置管理工程师面试题目

1.你为什么要申请配置管理工程师这个职位

我们公司已经通过了CMMI3，我在现在的公司就是做配置管理工程师的，我熟悉配置管理，并喜爱这份工作，希望能继续从事该工作。

2.你觉得自己能否胜任这个职位

能胜任，我们公司已经通过了CMMI3，并且日常工作都是按照CMMI3的流程规范进行的，并不是为了过级而过级，是切实为了保证软件质量才过级的。

我做配置管理已经有一段时间了，不仅现有工作能够完全胜任，还非常乐于学习，如果贵公司的该职位有什么知识是我掌握的不够好的，我能在短时间内满足工作要求。

3.你觉得配置管理工程师需要掌握哪些技能

配置管理工具的使用，构建脚本的编写，对工件的理解，了解软件工程，配置管理相关知识，配置管理的工作方法。

需要掌握的技能专业技能如程序设计,配置管理,变更控制（版本风险控制）,发布管理,持续集成,配置项（包括很多,如文档,源码等）规范等;其它技能团队合作能力,与人沟通能力,配置管理威信等.

4.配置管理工程师的职责有哪些

职责包括保证工作产品的一致性、完整性、可追溯性，管理配置项，维护配置库，变更控制，发布管理。

5.配置管理能给项目带来的好处有哪些

因为配置管理保证了配置项的完整和可追溯，使团队成员可以拿到所需工件的所需版本，不会因为某个人的习惯问题，导致配置项缺失（比如东西在某人本机保存，人离职了，东西就找不到了）；

变更控制使团队每个人都了解到谁改变了哪些东西，保证了所有团队成员的信息对称；（比如需求已变化，但测试人员不知道，还按照老需求来测试，结果当然是不符合）配置管理给项目带来的最大的好处：

规范化的配置项管理可以使整个团队随时拿到需要的东西（包括备份，文件历史等）；

对变更的控制可以对整个配置库（特别是对开发项目）的发展，对产品的变更随时了解；有了配置管理的支持，更大的提高公司员工的工作效率，把公司从一个手工的，有点混乱的项目管理过程中解放出来，实现更完美的规范化。

6.作为一个配置管理工程师,哪些方面是工作的重点可能的难点会有哪些

工作重点：

当然是对配置项的规范化的这样一个过程，包括对配置管理工具的使用，对配置项的修改控制，对配置项的随时备份等。

难点：

如果一个公司以前没有配置管理这样一个

理念的话，最大的难处就是使公司内部人员熟悉并遵循配置管理这样一套理念啦。

7.什么是基线什么是labeltagbranch他们之间有什么联系和区别.

基线是一组被正式评审通过并经CCB同意发布的工作产品集合，它作为下游开展工作的基础，已基线工作产品的变更必须受控。

结合我们公司的情况，如果使用的是vss配置库，在里程碑处会建立基线，建立的同时，会为此基线打个label，相当于给这一系列的配置项集合贴了个标签，表示此集合都是xxxx1.0设计基线的成员；另外就是自动构建的时候会给参与构建的所有文件都打label，告诉此版本的文件参与了自动构建，将来有需要可以get到整个label；在svn的使用中，会用到tag和branch，

tag是里程碑处的一个copy;

tag是用来做一个milestone的，不管是不是release，都是一个可用的版本。

这里，应该是只读的。

更多的是一个显示用的，给人一个可读（readable）的标记。

branch，是用来做并行开发的，这里的并行是指和trunk进行比较。

branches：

分枝当多个人合作，可能有这样的情况出现：

John突然有个想法，跟原先的设计不太一致，可能是功能的添加或者日志格式的改进等等，总而言之，这个想法可能需要花一段时间来完成，而这个过程中，John的一些操作可能会影响Sally的工作，John从现有的状态单独出一个project的话，又不能及时得到Sally对已有代码做的修正，而且独立出来的话，John的尝试成功时，跟原来的合并也存在困难。

这时最好的实践方法是使用branches。

John建立一个自己的branch，然后在里面实验，必要的时候从Sally的trunk里取得更新，或者将自己的阶段成果汇集到trunk中。

branch是版本树演进的一个分支，为了不影响主枝，可以作为个人的工作位置，或者某定制开发的位置，如果将来有必要将该定制合并到主枝，可以使用配置库提供的合并功能。

e.htm需求一：

有一个客户想对产品做定制，但是我们并不想修改原有的svn中trunk的代码。

方法：

用svn建立一个新的branches，从这个branche做为一个新的起点来开发svncopysvnservertrunksvnserverbranchesep-minitepTip如果你的svn中以前没有branches这个的目录，只有trunk这个，你可以用svnmkdirbranches新建个目录需求二：

产品开发已经基本完成，并且通过很严格的测试，这时候我们就想发布给客户使用，发布我们的1.0版本svncopysvnservertrunksvnservertagsrelease-1.0-m1.0released咦，这个和branches有什么区别，好像啥区别也没有？

是的，branches和tags是一样的，都是目录，只是我们不会对这个release-1.0的tag做修改了，不再提交了，如果提交那么就是branches需求三：

有一天，突然在trunk下的core中发现一个致命的bug,那么所有的branches一定也一样了，该怎么办？

svn-rmergesvnservertrunkbranchesep

其中148和149是两次修改的版本号。

8.一个构建（build）发布的过程是什么（请描述一下典型的发布一个build的流程）

构建-提交测试-修改代码-构建-提交测试直至测试通过-配置审计-建立基线-走审批流程-发布

9.releasenotes都应该包括哪些内容

一般是版本控制（臂如vss,cvs等）的说明文档，臂如标签，修改说明等。

这个格式可以自己定义，没有大标准。

项目简介、发布背景、运行测试环境、与已有版本相比的新功能特性、升级方法、已知错误和局限性、已测试的性能、工件发布列表

10.广义上的ChangeRequest（CR）都包括哪些内容

项目名称、变更原因、变更分析（影响程度、紧急程度、影响因素□范围□工作量□进度□成本□资源□质量）、申请变更的内容（是配置项变更还是基线变更）、受到影响的配置项，变更配置项的具体执行人

11.你一天的多长时间用来做build你一天的时间安排是个什么样子的

写好构建脚本后，之后系统每天自动执行自动构建。

12.简述在一个项目周期中,配置管理工程师（CM）的主要活动（工作）有哪些

以项目计划为输入，做项目的配置管理计划，计划包含采用何种配置管理工具、备份策略、目录的设置、权限如何分配、配置项的受控计划、基线的建立计划、审计计划；按照配置管理计划建立配置管理库，维护配置管理库、分配配置库权限，管理配置项（受控工件、建立基线）；进行配置审计；项目的变更控制；打部署包提交测试，进行版本发布。

维护项目的配置管理工作表，按月整理事业部配置管理月报。

大家回答的时候可以从前往后叙述,这样也不容易忘记,还显得有条理.

13.请描述一下你使用过的配置管理工具？

VSS，svn；vss采用的是锁定-修改-解锁的方式，对于多人的协同开发存在一定弊端，系统无法自动检测来自他人的修改，只能在局域网使用。

svn采用的是复制-修改-合并的策略，可以检测到他人的修改，有较好的合并功能，还可以在外网使用，对于规模不太大的团队已经够用了，在windows的环境下使用非常的方便，并且可以集成到eclipse中直接进行操作，现阶段非常适合我们公司的开发环境。

14.在安装配置方面有什么需要注意的？

他的扩展功能有哪些？

如何实现？

公司采用的是apache+svn的使用方式，windows下的安装是比较容易的，linux的话，就要注意先安装aprapr-utilberkeleydb这些

15.请问你是否亲手装过windows操作系统？

是否使用过windows2003server？

格式化硬盘该怎么样去做？

安装使用过。

我的电脑-管理里面进行操作

16.请问你是否装过linux或者unix操作系统？

请分别说出你所知道的linux和unix发行版本

自己装过redhatlinux5.2企业版linuxUbuntu（乌班图），Fedora，OpenSUSE，Debian（待宾），Mandriva，Mint，PCLinuxOS，Slackware，Gentoo，CentOS，FreeBSDarticles.htmunixAUXAIXBSDDragonFlyBSDFreeBSDGNUHP-UXIRIXLinuxLynxOSMacOSXMinixNetBSDNEXTSTEPOpenBSDQNXSCOOpenServerSolarisSystemVTru64Xenix

17.你知道配置管理中基线的含义么？

怎样把项目中某个重要的时刻冻结？

基线是一组被正式评审通过并经CCB同意发布的工作产品集合，它作为下游开展工作的基础，已基线工作产品的变更必须受控。

18.你一般会把哪些东西纳入版本控制？

项目的重要工作产品，过程性的文档就不需要版本控制了。

19.怎样可以保证团队中每个人都知道谁改变了哪些东西？

通过变更控制，每次变更结束都会邮件通知涉众，并且维护该项目的配置管理工作表，记录此次变更，在工件重新受控提交时会在注释中简要记录。

可以通过变更控制，变更活动关联的配置项清单和配置工具的日志信息。

20.Tag和Branch的区别是什么？

在什么情况下该使用tag，什么时候用branch？

Tag是标签，Branch是分支。

当项目里程碑到达了或项目发版的时候需要对项目的重要工作产品打一条Tag.当项目发版后主分支需要做新版本，而又有上线后的BUG需要上紧急版本修复时需以项目发版时创建的Tag为基准创建一条Branch来修改上线后的紧急BUG。

branches和tags是一样的，都是目录，只是我们不会对这个release-1.0的tag做修改了，不再提交了，如果提交那么就是branchestag，是用来做一个milestone的，不管是不是release，都是一个可用的版本。

这里，应该是只读的。

更多的是一个显示用的，给人一个可读（readable）的标记。

branch，是用来做并行开发的，这里的并行是指和trunk进行比较。

21.你用什么工具管理项目中所有数字信息的状态？

你最喜欢哪种工具？

cvs的tag什么时候使用tagtag的功能就像是给你的工程的某个时刻建立了一个快照。

添加了tag后，不论你最源文件做了任何修改，只要发现你的修改发生了错误，或者是如果有人宣称在某个版本里有个bug，但你在当前工作的副本中是找不到那个bug，都可以根据tag重新rollback回去，或checkout出那个快照。

tag给开发人员带了这样的便利，因此在任何重要的开发阶段，都应该打上tag。

一般性的，在下面的情况都应该考虑给你的工程简历一份快照（tag）：

完成了某个重要的功能

在每一个milestone在去掉某个存在功能之前在测试开始之前在你对源文件做重大修改之前新建分支（branch，下文会详细谈到）的时候很并分支之前当然了，这些都是一般性的建议。

其实我感觉是只要你觉得做的修改可能会有副作用的时候，就应该打上tag。

22.怎样管理技术文档——如产品架构文档——的变化？

首先对确定后的技术文档打好基线，之后就要对基线后的技术文档进行变更控制，变更前要进行变更影响分析，变更时候要关联对应的变更活动，文档好写好变更记录。

23.如果客户想要对一款已经发布的产品做出变动，你怎么处理？

作为定制需求在配置库做一个branch，相对于主枝做并行开发，最后综合评估所做修改是否要纳入产品主枝。

24.版本管理和发布管理有什么差异？

版本管理是软件配置管理的基础，它管理并保护开发者的软件资源。

它的主要功能有：

（1）集中管理档案，安全授权机制：

档案集中地存放在服务器上，经系统管理员授权给各个用户。

用户通过checkin和checkout的方式访问服务器上的文件，XX的用户则无法访问服务器上的文件。

（2）软件版本升级管理：

每次登入时，在服务器上都会生成新的版本，任何版本都可以随时检出编辑。

（3）加锁功能：

在文件更新时保护文件，避免不同的用户更改同一文件时发生冲突。

（4）提供不同版本源程序的比较。

版本控制系统用于保存编写开发应用程序时的文档的各个修订版（revision）。

版本控制也称作RevisionControlSystem（RCS）发布管理是对发布流程的控制，只有通过测试经过审批的版本才能够正式发布，未经测试的版本如果发布，存在质量隐患。

25.对文本文件的变化和二进制文件的变化进行管理，这二者有什么不同？

对于svn文本和二进制文件的管理是一样的，采用统一的二进制差异算法cvs对于文本进行差异化的存储，对二进制文件采用独立的冗余的存储。

26.同时处理多个变更请求，或是同时进行增量开发和维护，这种事情你怎么看待？

27.除了你使用过的软件配置管理工具，还了解哪些工具？

请说出这些工具的区别。

git分布式开发用非常好，权限控制薄弱，对windows的支持不好，需要在linux下使用.相比svn，git代码库体积小（能小50%多，如果svn里分支用本地文件拷贝+svnadd，那么git在体积上更占优势），git工具速度很快，对合并支持非常好，探测文件重命名的做法很独特，git-svn很好用，分支很轻量级.如果不怎么理Windows平台，代码很庞大，对合并要求很高，不惮理解git的原理以及看手册，那么git是很好的选择。

cvs：

文本下载是差异的，上传是全量，不是原子性提交，如果上传过程遇到网络中断，可能会上传一部分文件，导致版本出现问题，目录未纳入版本控制，不能重命名，对于二进制的文件是采用独立的冗余的存储，建议使用svnclearcase：

没有具体使用过，看资料都说安装配置使用比较复杂。

svn项目不大，对权限控制很看重，应选择SVN

28.什么是dotnetframework？

是干什么用的？

Microsoft.NETFramework2.0版可再发行组件包将安装运行针对.NETFramework2.0版开发的应用程序时所需的.NETFramework运行库及相关文件。

29.JRE是什么的缩写？

干什么用的？

JRE是Java运行环境（JavaRuntimeEnviroment）的缩写。

它基本上就和Java虚拟机是同一个概念。

JDK是Java开发工具包（JavaDevelopmentKit）的缩写。

它是一种用于构建在Java平台上发布的应用程序、applet和组件的开发环境。

JDK包括了jre。

jre可以自动升级是其自身具有的功能。

30.是否听说或者用过cpan？

CPAN是全面Perl归档网络（ComprehensivePerlArchiveNetwork）的缩写，那是一个值常去的地方。

这里有Perl源码，容易安装到非类Unix系统的Perl例子，文档，Perl扩展部分，Perl归档信息等。

简言之，CPAN是全面的。

httpwww.cpan.org

31.一个HR的面试题“做配置管理最终的目标是什么？

实现目标的路线是怎么样的？

”

保证软件产品的配置项的一致性、完整性、可追溯性；

按计划进行基线建立，定期进行配置审计，使用配置管理工具，对评审通过已受控的配置项的变更进行控制

用友的配置管理面试题

32.Perforce与Subversion有啥区别？

perforce是商业软件svn是开源免费的

33.怎么利用分支模式支持Agile开发？

agile敏捷SoftWareProcess.asp

34.简述项目经历，描述哪个项目收获最大.......

第一个接手的项目，建立配置管理概念，学习规范的配置管理流程，学习编写脚本

35.Antbuild.xml什么情况下用到for循环？

如何写for循环？

1）1build完成之后生成了build.war包.同时这个war包要分别部署到10台不同的测试机上,简单点说copy到10个不同的目录下.然不成要我写10个copy,这样的脚本写出来,又难看,又难以维护.假如我们用for用一个properties文件来保存10个路径,并以参数形式传递给for,岂不是方便了很多.假如要copy20,30....或者更多次呢viewthread.phptid=5109

2）2我接触的arm编译器,它支持.c.cpp这样的格式,但使用这种,编译出来的东西偶尔会有问题,而且是很莫名奇妙的问题.所以研发要求逐个编译.于是乎,就变成了如下一串.arm-c1.c,2.c,3.c,4.c,5.c............如果脚本这样写,是多大的维护量.更何况项目还多,假如我们用for呢.只需要维护一个build.properties就可以了.然后可能arm的编译参数对不同的代码又不尽相同.那我们再加上ifelseif呢,将判断条件同样用properties文件管理.

VMware面试题

36.Perforce与Subversion有啥区别？

perforce是商业软件svn是开源的

37.配置管理和IT人员有何区别？

（这个问题当时让我很震惊）

配置管理员的安装维护配置管理库，分配权限这些工作IT人员也可以做，但是IT人员只是为项目提供支持环境，不关注项目质量，不关注项目的变更，不关注产品版本

38.用Perl如何过滤log信息（主要考的还是正则表达式）比如我在perl里执行了系统的某个命令，比如一个build命令，会在命令行里打印出好多过程信息，如何把这些信息保存成一个文件，谢谢！

1.perlxxx.pltmpfile

2.open（STDOUT,tmpfile）;system（build）;

39.Perl如何排序

40.表示邮件的正则表达式是什么

^w+（（-w+）（.w+））@[A-Za-z0-9]+（（.-）[A-Za-z0-9]+）.[A-Za-z0-9]+$

41.Perforce如何支持分布式开发？

42.Perforceproxy的原理是什么？

43.Perforce如何创建depot？

44.Perforce如何创建branch？

45.Perforce如何用命令同步一个changelist

46.Perforce命令行下如何把几个文件放到同一个changelist当中？

整理的一些面试题

47.SVN分支发布和主干发布各有哪些优缺点

48.我们公司现在没有配置管理,你打算怎么开展

1）1－－写好必要的操作手册和支持文档，把这些标准的文档发给你的上司，引起他们的注意；

2）2－－争取一个小时的时间对大家进行统一的培训，真样你就会有一个发挥的时间；

3）3－－在介绍配置管理和使用配置管理工具的时候，清楚明了，并且强调这是部门的要求，需要所有人员参与配合。

大家都可以在实施配置管理过程中得到相应的关于软件过程管理的知识，体现程序员的基本素质，适应软件组织发展的要求；4－－自己要有信心，对同事要有热情，及时报告结果。

了解公司现有流程，根据现状和不足，按照CMMI的要求起草配置管理相关的规程、指南、表单；每个配置文件写好后都邀请各角色的使用者代表参与评审；根据评审意见进行修改，直至关闭评审；提交EPG或者分管负责人进行审批；审批通过后进行试行；试行结束，将配置文件正式发布执行；在执行过程中，如果遇到新的问题，再进行持续改进。

49.以前你是怎么做配置管理的怎么样通过配置管理控制质量

50.基线的概念什么时候应该打基线基线是一组被正式评审通过并经CCB同意发布的工作产品集合，它作为下游开展工作的基础，已基线工作产品的变更必须受控。

项目计划的里程碑处需要打基线，比如需求、设计、开发、测试完成之后通常都需要建立基线。

51.如果你来建立一个SVN库存,请你画一下SVN库的结构目录.trunkbranchestagscontrolvarpromanage

52.可不可以自己对SVN做扩展SVN与其它工具的集成,如bugzilla,mantis等现阶段还没做过，如果需要，可以研究一下

53.如何关联SVN修改记录与bugzilla,mantis的BID修改项下面谈谈BugZillaVSMantis的结论；

1）界面。

BugZilla的几面几乎可以说惨不忍睹，鼎鼎大名的开源软件，界面居然是这样。

呵呵。

真想不通。

相对而言Mantis的界面则要友善的多了。

操作也相对更加人性化一点。

2）功能。

就功能来说，BugZilla的定制功能的确更强，能满足更多用户差异化的需求。

而Manits的好多设置还得通过修改代码来实现，相比麻烦了很多。

3）本地化。

Mantis本身就提供了十几国的语言可以供用户直接选择。

很不错的哦。

而BugZilla本身只有英文，网站提供的多国语言包，看起来也是Sourceforge上其他项目组完成的，更新的节奏也比英文版慢了一年半年的。

不爽的很。

4）知名度，呵呵。

这个BugZilla和Mantis没得比了。

Linux,Eclipse,NASA（美国宇航局居然也用开源的？

？

？

）...等等知名的厂商都在用。

而Manits的使用者大多都是一下不知名的小公司了。

5）安装。

平心而论BugZilla的安装确实比Mantis简单。

CheckSetup.pl替用户省了不少心。

54.做项目配置管理的时候,如果项目多,你会采用多库管理还是单库管理并说明原因

如果项目间关联性大，会互相影响，就建一个库，不是这种情况就分别建库。

不同库的代码无法合并，所以相关联的项目实现多库管理，会导致无法得到其他项目的变化，如果没有这个原因，各自建库，会使库更简单清晰便于管理。

55.tag,branch的概念

SVN基本命令tag和branch都是个目录，是一个工作copy，tag通常在里程碑处对项目的一个快照，用于显示，不做修改使用。

branch可以实现和trunk的并行开发，通常用于定制需求，或者trunk已经到了2.0版本，1.0被找到了bug，用来解决1.0的问题，或者作为个人一些不影响主枝开发的开发尝试进行的地方，还能随时从主枝获得版本最新改变，如果有必要还可以将自己的工作成果合并到主枝。

斯顿信息技术有限公司（智控美信）SCM面试题

56.介绍下你的工作经历

我现在的工作是xx的xxxx部门的配置管理工程师，负责全部门11个产品的配置管理工作，日常工作包括做各产品线的配置计划，受控评审通过的工件，在项目里程碑处建立基线，控制项目变更，维护配置管理工作表，进行配置审计，写ant脚本进行产品的自动构建，提交部署包给测试人员，