软件配置管理—软件测试核心技术(7)

发表于:2020-8-25 10:58

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:51testing教研组    来源:51Testing软件测试网原创

  第5章 软件配置管理
  为了使软件测试工程师在测试执行活动时需要获取相应版本的被测软件,需要通过配置管理来保证版本不会出现混乱。配置管理是整个软件研发中很重要的一个辅助活动。
  5.1 初级软件配置管理
  5.1.1 软件配置管理发展史
  很多年以前,很多软件产品通常由一个人开发,因而很少需要进行软件配置管理。随着软件产品在规模和复杂度方面的增长,个人已经很难适应开发的要求。由坐在一起的两三个人组成的软件团队尚且比较易于管理,但是开发团队很快就扩展到几十甚至几百个开发人员,他们还可能分布在不同的地点,这时候,管理的难度就加大了。
  在早期,软件配置管理流程用于管理变更。通常情况下,这些流程通过手工的方式执行。一个或多个配置管理员负责控制什么人能够访问源代码。为了修改文件,需要经历以下几个步骤。
  (1)开发人员A需要填写书面的表单,然后提交给配置管理员。在这张表单里面,记录了需要修改的文件、修改的原因。
  (2)配置管理员确认表单上记录的需要修改的文件当前未被其他人修改后,将文件的一份副本交给开发人员,然后记录开发人员A在何时取走文件副本。
  (3)如果需要修改的文件处于修改状态,即另外一位开发人员B正在修改这几个文件,配置管理员会通知开发人员B尽快修改文件。开发人员B修改完毕后,并且将修改后的文件提交给配置管理员归档后,继续执行步骤(2)的相关操作。
  (4)开发人员在完成修改之后,将结果提交给配置管理员,配置管理员将修改后的文件归档到配置库中。
  如果我们把存放代码、文档的库理解为仓库,那么配置库管理员就是仓库保管员了。
  不久之后,配置管理工具被开发出来,用于帮助配置管理员自动化处理其工作任务。通常,一种操作系统平台上有一种主要的工具,这些工具拥有下列基本的版本控制特性。
  ●维护文件库。
  ●创建和存放文件的多个版本。
  ●提供锁定的机制(避免同一文件在同一时间被多人修改,保证修改的顺序性)。
  ●标识一组文件的版本。
  ●从配置库中提取/找回文件的版本。
  早期的SCM(Software Configuration Management,软件配置管理)工具提供了上述基本的版本控制能力,并且将库管理员的一些手工SCM任务自动化,开发人员能够在没有配置管理员介入的情况下检出需要的文件。当文件被检出后,其他开发人员将不能修改该文件。完成变更内容之后,开发人员将文件检入,由于修改了文件,文件的版本自动升级,升级到新的版本号。检入/检出的工作模式至今没有发生变化。
  一个广泛应用的SCM工具是源代码控制系统(Source Code Control System,SCCS),该工具由贝尔实验室在20世纪70年代早期开发;另外一种与SCCS类似的SCM工具是由Walter Tichy在普渡大学开发的版本控制系统(Revision Control System,RCS)。RCS和SCCS成为UNIX平台上的主流配置管理工具。此时,大多数主机系统使用它们自己的SCM工具。例如,配置管理系统(Configuration Management System,CMS)曾经是美国DEC(Digital Equipment Corporation)的VAX/VMS操作系统的一个组成部分。
  这些早期的版本控制工具通常用标签(label)或标记(mark)来标识一组文件中每个文件的特定版本。这就是所谓的配置,它用来标识整个产品的一个特定版本。
  这些工具大大地提升了原有手工方式的工作效率,它们提供了经典的SCM能力,用于标识被开发的软件项目的各个文件,控制对这些文件的变更,提供审计信息用于记录何人在何时修改了什么文件。
  从上面的文字描述中分析,我们可以得到如下定义。
  ●配置:在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此,配置包括最终组成软件产品所有的相关文档、软件版本、变更文档、软件运行的支持数据。相对于硬件类配置,软件产品的配置包括更多的内容并具有易变性。
  ●配置管理:通过对软件生命周期中不同的时间点上所产生的文件进行标识,并对这些标识的文件的更改进行系统控制,从而达到保证软件产品的完整性和可溯性的过程。
  ●版本:表示一个配置项具有一组定义的功能的一种标识。随着功能的增加、修改或删除,配置项的版本随之演变。版本以版本号进行标识。
  ●版本号:为了维护软件项目,我们提出了对版本进行管理控制的要求。对于用户来说,版本直接体现在版本号的命名上。
  那么如何对版本号进行命名呢?版本控制比较普遍的3种命名格式如下。
  ●GNU风格的版本号命名格式:Major_Version_Number.Minor_Version_Number [.Revision_Number[.Build_Number]],即主版本号.次版本号[.修订版本号[.内部版本号]],如1.2.1、2.0、5.0.0 build-13124。
  ●Windows风格的版本号命名格式:Major_Version_Number.Minor_Version_Number [Revision_Number[.Build_Number]],即主版本号.次版本号[修订版本号[.内部版本号]],如1.21、2.0。
  ●.NET Framework风格的版本号命名格式:Major_Version_Number.Minor_ Version_ Number[.Build_Number[.Revision_Number]],即主版本号.次版本号[.内部版本号[.修订版本号]]。
  版本号由2~4部分组成,其中,主版本号和次版本号是必选的;内部版本号和修订版本号是可选的,但是如果定义了修订版本号,则内部版本号就是必选的。所有定义的部分都必须是不小于0的整数。
  应根据下面的约定使用这些部分。
  ●具有相同名称但不同主版本号的程序集不可互换。这适用于对产品的大量重写,这些重写使得无法实现向后兼容性。
  ●如果两个程序集的名称和主版本号相同,而次版本号不同,这指示显著增强,但照顾到了向后兼容性。这适用于产品的修订版或完全向后兼容的新版本。
  ●内部版本号的不同表示对相同源所做的重新编译。这适用于更改处理器、平台或编译器的情况。
  ●名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞
  程序集中只有内部版本号或修订版本号不同的后续版本被视为先前版本的修补程序更新。

查看《软件测试核心技术 从理论到实践》全部连载章节
版权声明:51Testing软件测试网获得人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号