软件测试管理中配置驱动的开发（下）

软件测试管理中配置驱动的开发（下）

好处、成本和限制

在采用一种新方法之前，最好是评估一下它的好处和成本，以及不应该 期望从中获得什么。本节概述这三个方面。

好处

减少重复

这种技术的首要好处显然是减少了信息重复，这会提高产品的可维护性和总体质量。

不依赖于特定厂商

由于只使用基本工具来编辑 XML，就不会将自己限制于任何厂商特有的工具。有许多开放源码工具可以用来读取和编辑 XML 文件。

源代码控制

市场上的一些解决方案将它们的输出存储为专有的 XML 格式，几乎不可能对这些文件进行合并。这些 XML 文件之间的引用也会导致问题。在任何时候只让一个团队成员有权修改配置文件是一种效率很差的方法。在多用户环境中，可以用源代码控制工具（比如 CVS、Subversion 或 Clearcase）处理手工编辑的 XML 文件。

对正确的任务使用正确的工具

市场上的大多数工具致力于解决一些非常常见的需求，但是每个产品都有特殊的需求。找到与所有这些需求匹配的工具很困难，甚至是不可能的。定制的配置文件可以只包含与您的项目相关的信息。

技术独立性

一些工具使用配置文件将应用程序与底层技术隔离开。例如，Hibernate 将数据库和对象之间的关系存储在配置文件中，从而将用户与特定厂商的数据库实现隔离开。尽管这种独立性并不完美，但是技术抽象常常是有好处的，因为它有助于以后改进应用程序。

成本

建立结构

建立结构的初始成本是不能忽略不计的。即使使用正确的工具，问题还是会出现。由于有初始成本，配置驱动的开发主要适合于中型和大型项目。

构建过程的复杂性

当从配置文件生成应用程序的组件时，构建过程会变复杂。通过适当的构建自动化，这个成本可以保持在相当低的水平。

限制和折中

业务规则的复杂性

基本概念很容易映射到配置文件中，但是复杂的业务规则就完全不同了。如果应用程序中的复杂规则常常出现小的变化，那么可以创建只存储这些变化的配置文件。考虑到效率，最好是将复杂的业务规则放在代码本身中，而将重复性的概念放在配置文件中。

基础设施成本

对于小型项目，建立基础设施的成本可能比项目本身的成本还高。另外，小项目不会经常受到信息重复的损害。

示例 XML 代码

清单 1 给出一个示例 XML 文件，它代表一个资源（或用户）结构。下面列出示例 XML 代码中的几个属性：

• Class：Java 类的名称
• Extends：父 Java 类的名称
• Abstract：表示在 Java 术语中这个类是否是抽象的
• TestReady：表示代码生成器是否应该为这个类生成单元测试
• Field name：字段的 Java 变量名
• Field type：字段使用的 Java 类型
• Field label：用户界面上特定字段使用的标签
• Field min and max：字符串或数字值的最小和最大长度
• Field default：在创建对象时，应用于一个字段的默认值
• Field composite：表示字段是引用还是复合的关系
• Field valid types：表示抽象对象数组中可以包含的有效类型
• Field mandatory：表示在创建对象时这个字段是否是强制的
• Field readable：表示用户是否可以读取这个字段
• 继承的字段覆盖