引言

　　随着计算机应用的广泛和深入发展．软件系统13趋大型和复杂．软件开发往往需要采用团队协作并行开发方式。在这样的规模和开发方式下．软件开发过程中参与开发的人员受到技术水平、主观思维、工作方法等因素影响。难免产生差错。团队协作开发配合不佳也很容易致使软件频繁出现故障和缺陷．软件的开发过程难以控制和管理，导致软件开发周期延长成本增加，软件质量降低．产品风险增加。这种情况下。如何保证软件质量提高软件开发效率是业内人士必须面对的问题。因此．为了保证软件质量．降低开发成本和交付后的维护成本．软件配置管理在软件工程中显得尤为重要。软件配置管理的主要任务是跟踪和控制软件过程中的变化．以使软件在开发过程中任一时间的内容和变化都可以被控制和追溯。借助一些成熟的工具来完成这些工作会有事半功倍的效果．目前被广泛应用的软件配置管理工具有：版本控制系统（如CVS，SVN等）、缺陷跟踪系统（如Bugziila。JIRA等）和测试管理系统（如TestDi．rector等）等。

　　这些系统单独看来都是很多非常成熟的软件产品．有成熟的权限管理和很高的自动化程度．但当这些系统搭建在一起使用时。它们之间却彼此孤立，各个系统间的信息无法进行共享。例如：缺陷跟踪系统无法获知修正缺陷导致的文件版本的变化，而版本控制系统也无从获知文件版本变化对应的具体缺陷．在实际的开发过程中只能依靠手动在两个系统中分别添加相应的说明以达到可以追溯的目的。

　　由于这种系统问的信息共享方式高度依赖程序员的自觉．并且依靠手动完成．所以整个开发过程的自动化程度和可靠性在系统问的结合处大大降低．成为整个系统自动化程度和可靠性的短板。对此．本文提出一种整合的软件配置管理环境的搭建方案．可以提高整个软件过程的自动化程度和可靠性，同时能极大提高管理者审核的效率。

　　1、系统构成

　　版本控制系统．缺陷跟踪系统和测试管理系统是本方案的核心软件对这些具体软件工具的选择主要考虑三个方面：软件本身功能是否能够满足需求。软件间是否能够整合，是否便于扩展和自定义。另外还需考虑经济成本。据此，本方案的核心软件选择使用完全免费的开源软件。

　　1.1 版本控制系统

　　版本控制系统选择使用开源版本控制系统Subversion（SVN）。随着系统的逐渐成熟和第三方软件的不断推陈出新，SVN已经逐步取代CVS成为版本控制系统的主流，成为当下版本控制系统的不二之选。Subversion具有以下突出的优点：

　　1）全局性的版本编号：版本号是针对整个版本仓库的而不是针对单个文件。可以很方便的根据版本号查询到与该次提交相关的所有文件。更易于提取历史版本；

　　2）目录的版本控制：准确记录每一次文件改动时整个仓库目录的结构和内容发生的改变。因此可以方便安全的对文件进行移动、删除和重命名。而不必担心文件修改历史轨迹丢失；

　　3）开源：开放源代码和丰富强大的第三方和客户端软件。同其他系统问有更好的兼容性。其他优势还包括原子性提交。优秀的对二进制和文本文件一致的存储和传输算法。更多的网络支持等等。

　　1.2 缺陷追踪系统

　　缺陷追踪系统选择使用目前最流行的开源缺陷追踪系统Bugzilla。问世12年的Bu ma在各个方面都已日臻成熟，不论是Bug生存期的控制，还是在用户管理、权限管理、统计分析以及邮件通知等各方面都具备强大的功能和可配置的灵活性。由于Subversion和Bugzilla在各自领域的影响力。二者的接13和第三方粘合软件也在不断完善。为系统间的整合提供了有力的保证。

　　1.3 测试管理系统

　　基于以上的选择和整合的初衷Testopia即测试管理系统的不二之选作为Bugzilla的测试用例扩展应运而生的Testopia，经过不断发展已经成为一款堪比TestDirector的测试管理工具。但相对estDirector昂贵的费用，免费的Testopia足以满足绝大多数的应用需求。同时Testopia作为Bugzila的组件进行安装。同Bugzilla具有先天的整合性：

　　1）Bugmla中的产品，组件，版本等信息均可在Testopia中被使用：

　　2）Testopia直接使用Bugzilla的账户。只需另外配置用户的权限即可：

　　3）Testopia用户可以将Bugzilla中的Bug和测试项目关联起来，从而实现软件工程过程的集中化管理。

　　2、未经整合的现状

　　Te8toPia是Bugzilla的扩展组件．因而可以实现缺陷追踪系统和测试管理系统的元缝结合。而Subversion和Bugzina仍然是孤立的．尽管参与开发的人员都可以使用以上系统管理各开发阶段产生的文档、代码、测试和缺陷，但仍然存在以下明显缺点：

　　安全性方面：

　　1）难以保证版本仓库中的文件被误操作，发生误操作后难以被发现。后期测试或交付用户后才发现问题往往要付出惨痛的代价：

　　2）不能保证Bug被指定的人员修正。因为版本系统的用户和缺陷追踪系统的用户是相互独立的。在没有明确权限情况下容易造成多个开发人员修正后产生新的Bug。