2．配置管理系统是项目经理的"眼睛"，是软件测试有效实施的前提

在软件质量体系的诸多支持活动中,配置管理系统处在支持活动的中心位置,它有机地把其它支持活动结合起来,形成一个整体,相互促进,相互影响,有力地保证了质量体系的实施。建立公司配置管理系统很容易得到公司领导层的支持，几乎没人反对。更重要的是建立配置管理系统后测试人员的工作有了系统保证，测试工作的"矿藏资源"有了明确的位置，可以主动积极开展测试工作。

2.1项目管理存在的主要问题
华友公司测试部门去年刚成立时，以建立、规范和推广使用配置管理系统CVS为突破口，同时建立缺陷跟踪系统Bugzilla提高测试流程的管理水平。我做为测试负责人首先分析华友公司几个软件项目在开发管理上的现状,。

存在问题一、公司几个核心项目仍然过分分依赖少数个人的作用,没有建立起协同作战的氛围,没有科学的软件配置管理流程;技术上只重视系统和数据库、开发工具的选择,而忽视配置管理工具的选择,导致即使有些项目有配置管理的规程,也由于可操作性差而搁浅。以上种种原因导致开发过程中普遍存在如下一些问题:调查说明华友研发成员的变动的比率达到30%，几乎每周都有新加入的员工或者辞职人员，一个新成员熟悉项目的最佳途径就是通过配置管理系统阅读项目文档，甚至阅读同行代码，达到快速学习、共同提高的目的。一个辞职人员可以利用配置管理系统保留部分一段时间工作，最大程度减少对项目开发造成的损失。

存在问题二、开发管理松散。领导了解工作完成情况重视口头交流，忽视书面文档。有些部门主管无法确切得知项目的进展情况,项目经理也不知道各开发人员的具体工作,项目进展随意性很大,可"左"可"右"。"左"时按领导下达的"期限"进行,到期时,似乎一切已顺利完成,大家一阵胡弄,交差完成,反正领导看的是界面,至于里面是什么,留到施工时再说。施工时的工作因此变成了无法汇报、无法理清的无休止的维护。"右"时则项目工期无休止地延期。对我们软件工程来说,总的特点是先"左"后"右"。在领导面前表现"左",在用户面前表现"右"。有个测试人员经常利用上班时间学习英语，过了一个多月，看她依然如此，我做为项目领导进行批评教育，这名员工并不认为自己错了，她争辩，公司采取弹性工作时间，考核员工是分配的任务是否完成等理由。同时、我对她批评结果遭到她的恶意报复，她给有关领导报告新来的经理如何不懂公司业务，采取不适合公司的管理方式等，由于领导无法了解真相，使得我的工作在一段时间开展很困难，直到过去半年，这名员工辞职出国学习领导才明白发生了什么。

存在问题三、项目之间沟通不够。各个开发人员各自为政,每个项目经理都像个"地主"，编写的代码不仅风格各异,而且编码和设计脱节。每个项目组的人力资源和硬件资源成了"私有财产"，自己人员即使暂时空闲，让他从事所谓的新技术研究，也不考虑友邻项目需要他们帮助的现状。本来开发中错误在所难免,进展早一点的项目组或者人力资源强的项目组已经积累类似问题的解决经验，也不愿意分享给其它项目组。开发大量重复,留下大量难维护的代码。典型案例是有个短信项目D两年来在这个开发人员Y的研发支持下运转效益很好，但是三个月之前，开发人员Y因为待遇问题和公司领导谈判失败，提出辞职。项目D仍然在运行，但是最近移动公司规范修改、系统升级，需要修改程序，没人能看到及时更新的文档，尽管有一堆代码库，但是后来的程序员都没办法分析明白程序结构。公司领导出面请开发人员Y来协助，因为没有文档记录，Y忙于新公司的工作也不能解决修改。

存在问题四、文档与程序严重脱节。软件产品是公司的宝贵财富,代码的重用率是相当高的,如何建好知识库,用好知识库对公司优质高效开发产品,具有重大的影响。但开发人员的一句名口号是:"叫我干什么都可以,但别叫我看别人的程序"。当然,开发人员的工作态度要转变,但客观上有一个很重要的原因是:前人留下的程序既无像样的文档(即使留下了文档,其与源程序也严重脱节),开发风格又不统一,就像一堆垃圾,要开发人员到垃圾中去捡破烂,从这个角度上看,开发人员的要求是合理的。

存在问题五、测试工作不规范。仍然停留在"小姑娘做测试"的底水平上，传统的开发方式中,测试工作只是人们的一种主观愿望,根本无法提出具体的测试要求,加之开发人员的遮丑,测试工作往往是走一走过场,测试结果既无法考核又无法量化,当然就无法对以后的开发工作起指导作用。

存在问题六、虽然项目施工时间不长，但软件版本更新周期过短,几乎每天都修改在线运行系统，且开发人员必须亲自现场或远程登陆操作，全国十几个地点软件内容多少都有点差别，这些差别都记录在几个骨干人物的脑袋里。由于应用软件的特点,各个不同的施工点有不同的要求,开发人员要手工地保持多份不同的拷贝,即使是相同的问题,但由于在不同地方提出,由不同人解决,其做法也不同,程序的可维护性越来越差。久而久之,最后连自已都分不清楚了,代码的相互覆盖现象时有发生,且这苦水还无法倾诉,因为怕别人笑话,甚至别人问起,还得想法搪塞,可谓费尽苦心。

2.2建立配置管理系统,规范项目管理流程，建立知识库的同时节约项目费用

针对以上问题,利用自己在BeijingPrecomInc,普天润汇等公司积累的经验，建立配置管理系统CVS,CVS的全称是CurrentVersionControl.CVS是一种GNU软件包.由Intersolv公司开发，它明确的将源文件的存储和用户的工作空间独立开来,并使其有利与并行开发.这个工具属于OpenSource，,CVS可以在intenet上很方便的得到.它的源码在ftp:202.113.29.4pub1unixcvs它的说明文档在ftp:202.113.29.4doccvs.任何人可以很方便的下载.目前他的最新版本是2..10.8。不需要花钱，很快建立，重点在于使用和推广。配合项目经理共同制定相应的配置管理策略,取得了很好的成效。

2.2.1.节约费用

(1)缩短开发周期

利用CVS对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限度地共享代码。同时项目管理人员可以通过Version系统查看项目开发日志,测试人员可以根据开发日志和不同版本对软件进行测试,工程人员可以从版本控制系统上得到不同的运行版本,并且可以安装在WebServer或在Unix操作系统上命令行方式存取供外地施工人员存取最新版本,无需开发人员亲临现场。

利用CVS系统,可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。

(2)减少施工费用

利用CVS进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公司内部的Web服务器上,工程人员可以通过远程进入内部网,获取所需的最新版本。开发人员无需下现场,现场工程人员通过对方系统管理员收集反馈意见,书面提交到公司内部开发组项目经理,开发组内部讨论决定是否修改,并作出书面答复。这样做,可以同时响应多个项目点,防止开发人员分配到各个项目点、分散力量、人员不够的毛病,同时节约大量的旅差费用。

2.2.2.有利于知识库的建立

(1)代码对象库

软件代码是软件开发人员脑力劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形成的各种代码对象就像一个个零件坯一样,是快速生成系统的组成部分。长期的一个事实是:一旦某个开发人员离开工作岗位,其原来所作的代码便基本成为垃圾,无人过问。究其原因,就是没有专门对各人的有用对象进行管理,把其使用范围扩大到公司一级,进行规范化,加以说明和普及。CVS系统为开发管理提供了一个平台和仓库,有利于建立公司级的代码对象库。

(2)业务及经验库

通过CVS的注释,可形成完整的开发日志及问题集合,以文字方式伴随开发的整个过程,不依某个人的转移而消失,有利于公司积累业务经验,无论对版本整改或版本升级,都具有重要的指导作用。

2.2.3.规范管理

(1)量化工作量考核

传统的开发管理中,工作量一直是难以估量的指标,靠开发人员自已把握,随意性相当大;靠管理人员把握,主观性又太强。采用CVS管理后,开发人员每天下班前对修改的文件CheckIn,其中记述当天修改细节描述,这些描述可以作为工作量的衡量指标。

(2)规范测试

采用CVS以后,测试有了实实在在的工作,测试工作人员根据每天的修改细节描述对每一天的工作做具体的测试,对测试人员也具有可考核性,这样环环相扣,大大减少了其工作的随意性。

(3)加强协调与沟通

采用CVS后,通过VSS文档共享系统和Bugzilla缺陷跟踪系统,大大加强了项目成员之间的沟通,做到有问题及时发现、及时修改、及时通知,但又不额外增加很多的工作量。

谈项目管理和软件测试过程（一）

来源：CCW