软件测试管理中配置驱动的开发(上)

发表于:2010-04-19来源:作者:点击数: 标签:软件测试管理开发驱动
软件测试管理中配置驱动的开发(上) 代码重复随时会产生麻烦,有些人可能对代码做了修改,但是忘了将修改应用于重复的源代码。产生的混乱可大可小,但是无论程度如何,重复都是麻烦的来源。在本文中,IBM 开发人员 Steve McDuff 建议使用配置驱动的开发来解

软件测试管理中配置驱动的开发(上)

代码重复随时会产生麻烦,有些人可能对代码做了修改,但是忘了将修改应用于重复的源代码。产生的混乱可大可小,但是无论程度如何,重复都是麻烦的来源。在本文中,IBM 开发人员 Steve McDuff 建议使用配置驱动的开发来解决这个问题。

配置驱动的开发和模型驱动的开发之间的差异是,前者并不限制于代码的模型,比如类、字段和关系。配置驱动的开发(Configuration-driven development,CCD)包含应用程序中可以配置的所有内容。例如,如果体系结构指出某些业务规则必须一致地应用于整个应用程序,那么可以使用配置文件来配置和应用这些规则。

在本文中,我将介绍配置驱动的开发,并解释它如何解决代码重复和修改问题。

代码重复和修改

假设您正在开发的应用程序由以下组件组成:

1.一个数据库

2.带 Web 服务 API 的中间件服务器

3.带基于 Web 的用户界面的中间件服务器

4.使用中间件 API 的胖客户机

图 1. 一个简单的参数

在 图 1 中可以看到,一个简单的参数(比如字符串的长度)将会影响所有四个组件。它还会影响下面的用户文档和单元测试领域:

用户文档:

  • 胖客户机
  • 基于 Web 的用户界面
  • Web 服务 API

单元测试领域:

  • 数据库
  • Web 服务 API
  • 基于 Web 的用户界面
  • 胖客户机

图 2 说明了 图 1 所示的简单参数的总体影响。

图 2. 依赖性过多

真是让人吃惊,像字符串长度这么简单的东西竟然不只在四个位置上重复,而是在十个不同的位置出现。字符串长度参数只是一个例子;许多类型的业务规则对于典型的应用程序都有类似的影响。一些规则是几乎任何应用程序中都有的,比如字符串长度和数字的最小/最大值。其他规则专门用来满足特定应用程序的需要。应用程序是否使用签出/签入机制保持一致性?关于信息的这些规则是否从客户机和服务器获得?所有这些因素合在一起,即使是最简单的代码修改也很容易导致大混乱。

传统的解决方案

信息重复不是一个新问题,而且已经有许多工具和技术用来防止这个问题。在本节中,我将讨论对信息重复最常用的一些解决方案。

开发过程

一些开发团队将冗余信息修改纳入严格的开发过程中,以此解决信息重复问题。这个解决方案很繁琐,因为它需要监督和复查,但它是有效的。

设计良好的代码

设计良好的代码再加上对常量的重用,可以减轻代码重复问题。当应用程序的所有部分都用同一种语言编写时,代码驱动解决方案的效果最好。

模型驱动的工具

模型驱动的开发的概念是以配置的形式读取应用程序模型。模型驱动的最大优点是,它们使与对象及其关系相关的繁琐任务自动化。下面是一些流行的模型驱动开发工具:

  • Eclipse Modeling Framework(EMF):它存储类的布局和字段。它为应用程序生成 Java 类、网络接口,甚至还包括数据库映射。通过生成对象,EMF 使编写常用方法的繁琐部分自动化,比如获得器、设置器、相等、复制、克隆、串行化等等。EMF 使用可以存储许多对象定义的配置文件。在多用户环境中,合并这些文件可能导致一些问题。EMF 只能处理应用程序的对象、它们的关系和方法。对于处理定制的业务规则,它没有提供任何帮助。
  • UML2:它通过类关系、字段和逻辑的图表描述和说明应用程序。UML 的优点是它与语言无关。在完成逻辑设计之后,从理论上说,可以用任何语言生成对象。
  • Ruby on Rails:它从数据库模式中提取模型的配置。然后生成处理业务逻辑、基于 Web 的用户界面和单元测试所需的构架。生产效率的提高主要是由于数据库模式的修改会在代码中传播。

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