软件测试测试过程中的配置管理[6]

        软件测试测试过程中的配置管理[6]   软件测试　

   　针对这种情况，笔者建议将不同类型的开发活动按照紧急性或类型将工作区分开来，这就涉及多个版本的并行开发，如项目 V1.0 的缺陷修复、V1.0 的新增功能版本 V1.1、新版本 V2.0。IBM Rational ClearCase 可以很好的支持这种并行开发模式。在 ClearCase 中，我们可以在项目 V1.0 的发布基线(V1.0_rel01_20071101)的基础上分别创建针对三种版本(V1.0_bugfix、V1.1、V2.0)的开发项目(见图七)。在 ClearCase 管理下，这三种版本位于不同的分支下，他们的开发是独立的，互不影响，并且版本 V1.0_bugfix 中的缺陷修复可以及时的合并到版本 V1.1 和 V2.0 中，版本 V1.1 的新增功能也可以在需要的时候合并到版本 V2.0 中。

　　图七：ClearCase 实现并行开发模式图

　　定制文件开发方式

　　在项目实际开发中，通常需要对文件进行并行开发，因此存在因为多人同时修改同一个文件而需要对文件进行合并的情况。对于大部分格式的源码，配置管理工具都提供不同程度的自动合并功能。但是对于不能合并的二进制文件或不允许合并的文本文件(例如通过第三方开发工具导出的文本文件，ClearQuest 模式文件等)，就不适合使用并行开发方式。因为这些文件或者不能合并，或者是不能通过简单的合并来实现版本的合并。对于这类文件如果处理不当，就会导致测试时使用了错误内容的版本，导致测试不通过。

　　但是，在项目实际开发中又不能因为存在这类特定类型的文件，而限制使用并行开发方式。串行开发与并行开发是矛盾的，如何解决这个问题是存在这类文件的项目在开发和测试过程中很头痛的一个问题。IBM Rational ClearCase 可以很好的解决这个问题。我们可以利用 ClearCase 提供的强大的二次开发功能，为这些不能进行合并的二进制文件或不允许合并的文件创建特定的文件类型。在执行检出操作时，判断该文件是否属于已定义的特定类型文件。如果是，则判断该文件是否已经被检出。如果已经被检出则不允许执行检出操作。通过这种方式，我们既可以保证大部分的源码可以进行并行开发，又能解决这类特定类型文件的串行开发问题。

　　明确角色与职责

　　在整个测试过程与配置管理过程中，要非常清晰项目的角色划分，及角色对应的职责，并要求相关角色人员严格履行各自的职责。某个大型已上线系统在进行升级时就有过一次因角色与职责混淆的教训。在这次升级上线手册中有“检查四个参数 A、B、C、D”这么一个步骤，测试人员在测试时发现测试环境因没有这四个参数而导致了测试失败，于是测试人员联系开发人员，得知创建这四个参数的方法，以及需要设置的参数值。然后测试人员在测试环境自行创建了这四个参数。由于正确设置了这四个参数后，此次升级测试通过。当该升级包提交运维组部署到生产环境时，运维组按照上线手册要求检查了生产环境，发现生产环境有这四个参数(但不是开发人员期望设置的值)，并且有测试组提供的测试报告，于是他们将升级包按照上线手册步骤部署到生产环境。但是上线后由于这四个参数设置了错误的值，导致系统停产 40 多分钟。

　　在这个事故中，开发人员与开发人员都有责任。测试人员未按照上线手册要求完成他的工作(只是“检查”，而不是“创建”)，这本身就是一个违规操作。另外，他没有将实际情况与上线手册的不一致向开发组提出并由开发组更新上线手册，在开发组提交更新后的上线手册后，测试组重新检查测试环境并测试。开发人员则未在上线手册写明参数具体设置的值，上线手册存在不明确信息。

　　所以在项目的各个过程，包括软件测试过程和配置管理过程中，一定需要明确各角色相应的职责及工作范围，避免类似事故的发生。

　　总结

　　配置管理贯穿于项目所有过程中，本文主要从软件测试的角度分析了测试中经常碰到的问题，阐述了软件测试和配置管理之间的密切关系。为了解决测试中存在的配置管理问题，笔者针对测试过程常见问题产生的原因，从配置管理角度给出了相应的解决方案。笔者希望通过本文，能够改变软件测试工作中不需要关注配置管理的错误思想。

原文转自：http://www.ltesting.net