版本号管理策略—软件测试核心技术(8)

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

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

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

分享:
  5.1.2  版本号管理策略
  GNU风格的版本号管理策略如下。
  ●项目初版本中,版本号可以为0.1或0.1.0,也可以为1.0或1.0.0。
  ●当项目在进行了局部修改或Bug修正时,主版本号和次版本号都不变,修订版本号加1。
  ●当项目在原有的基础上增加了部分功能时,主版本号不变,次版本号加1,修订版本号重置为0,因而可以被忽略掉。
  ●当项目在进行了重大修改或局部修正累积较多而导致项目整体发生变化时,主版本号加1。
  ●内部版本号一般是编译器在编译过程中自动生成的,我们只定义其格式,并不进行人为控制。
  Windows风格的版本号管理策略如下。
  ●项目初版本中,版本号为1.0或1.00。
  ●当项目在进行了局部修改或Bug修正时,主版本号和次版本号都不变,修订版本号加1。
  ●当项目在原有的基础上增加了部分功能时,主版本号不变,次版本号加1,修订版本号重置为0,因而可以忽略掉。
  ●当项目在进行了重大修改或局部修正累积了较多而导致项目整体发生变化时,主版本号加1。
  ●内部版本号一般是编译器在编译过程中自动生成的,我们只定义其格式,并不进行人为控制。
  另外,还可以在版本号后面加入Alpha、Beta、Gamma、Current、RC(ReleaseCandidate)、Release、Stable等后缀,在这些后缀后面还可以加入1位数字的版本号。
  对于用户来说,如果某个软件的主版本号进行了升级,用户还想继续那个软件,则发行软件的公司一般要对用户收取升级费用;而如果子版本号或修订版本号发生了升级,一般来说是免费的。
  配置项版本号指组成软件的每一个配置项同样需要通过版本标识,一般配置项的版本号配置管理工具可以自行管理。
  在配置管理系统中,基线就是配置项在其生命周期的不同时间点上通过评审而进入正式受控的一种状态,而这个过程称为“基线化”。每一个基线都是其下一步开发的基准。
  5.1.3  不借助SCM工具来解决SCM问题的方法
  在没有SCM工具的情况下,开发人员会想出各种办法管理多版本的文件,这些多版本的文件组成了不断演进的软件系统。对于个人而言,经常采用文件的副本;对于小型团队而言,使用目录副本管理最新软件版本中的相关文件,这种方法称为共享副本。下面将讨论这两种不借助SCM工具来解决SCM问题的方法。
  1.使用文件副本
  假设用Perl这种脚本语言编写了一个小软件,该软件从一个特定格式的文本文件(如Excel文件)中读取数据,然后将其输出为HTML格式的文件,该软件保存在目录D:\configuration\mysystem_latest_version下。该Perl程序包括两个文件,分别是genhtml和myfunctions.pl。D:\configuration\mysystem_latest_version目录中的文件列表如图5-1所示。
图5-1D:\configuration\mysystem_latest_version目录中的文件列表
  在开发、测试该应用程序之后的几个月时间内,软件都没有出现什么问题。在2017年7月26日,你打算在genhtml脚本中做一些修改,修改该文件中的一些代码,然后增加一些其他的代码,以便更好地控制HTML文件的格式。
  如果直接修改当前的genhtml文件,你将丢失能够正常工作的前一版genhtml。因此,在着手修改之前,你需要备份前一版本。
  在没有SCM工具的情况下,解决这种问题的方法是显而易见的:将整个目录结构进行复制,存放系统的一个完整副本,根据修改的日期,创建目录mysystem_workstoday_july26_2017。然后,将目录D:\configuration\mysystem_latest_version下的文件都复制到新建的备份目录D:\configuration\mysystem_workstoday_july26_2017下面,如图5-2所示。
  修改位于D:\configuration\mysystem_latest_version目录下的相关文件,即使修改错误,导致该目录下的文件内容无法恢复到修改之前的状态,也不会有大碍。因为在目录D:\configuration\mysystem_workstoday_july26_2017下已经备份了修改之前的文件,根据需要,可以将文件恢复到以前的版本。
  同样可以使用文件副本存放文件的中间版本,如图5-3所示。
图5-2基础版本的目录和备份版本的目录
图5-3使用文件副本存放文件的中间版本
  对于个人项目而言,这种解决方案可能不错,但是在小型项目中会出现问题,并且不可能用于中型乃至大型项目。
  2.使用共享副本
  当软件系统的多个不被控制的副本位于每个开发人员的机器上时,小型团队就遇到了新的问题,即没有标准的软件版本。最初解决的方案是创建一个共同的系统目录,团队成员可以在此复制文件的新版本,这种解决方案实质上和个人开发所使用的方案类似。应用共享副本的方法,小型项目中的每个人在本机目录中创建一个或多个软件系统的副本,这种工作模式与前述个人项目相同。
  这里有一个示例,假设你在3个成员组成的团队中与Joe和Shirley一道开发了一个小型C应用程序。团队在一个共同的系统目录中存放完成的代码,因而系统至少存在4份副本,如图5-4(a)~(d)所示。当添加新特性或者做出变更时,团队成员将相应的文件复制到共同的系统目录中。当文件内容发生变更时,更新文件的过程如图5-5所示。
图5-4备份的文件结构
图5-5当文件内容发生变更时更新文件的过程
  初看起来,共享副本的方法还不错。但是,现实中,该方法会存在3方面的问题。
  ●同一文件的不同版本之间相互覆盖,会导致文件的版本丢失。
  ●在共用的代码中,从一个不适合的变更中恢复很困难甚至不可能。
  ●文件多个不受控制的副本导致很难确定文件最新版本的位置。
  当两个开发人员同时使用同一文件之上时,会发生副本覆盖问题,导致文件的版本丢失。他们都从共同的系统文件目录上获取该文件的副本,然后各自做修改。两个人相继将修改后的文件复制回共同的系统文件目录,这样后一个人修改的版本会覆盖前一个人的版本,具体过程参见图5-6。使用共享副本的方法,你没有办法获知何时发生了并行变更,也无法防范这种情形的出现。
  基本上不可能恢复对共同的文件所做的不合适的变更。因为没有办法查看项目的公共区域中发生了什么变更、谁做出的变更、何时做出的变更。
  因为应用系统的文件在各地有诸多名称各异的副本,所以很快你就无法找出文件的最新版本到底在什么位置。
  如前所述,针对共享副本方法引入的问题,最初的解决方案就是指派配置管理员,人工管理共用的系统目录。
图5-6文件内容发生变更后更新文件的过程

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

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号