运用类的思想和Java的反射（Reflect）技术，构建出一个灵活、合理的系统
——写给Java初学者
二、 自动化测试中的几个主要的类
在这个设想的自动化测试系统中，执行一个自动化测试的步骤（Step），总是从读取“测试步骤XML配置文件”开始，然后初始化/构造一些测试对象；最后根据XML配置文件定义的测试步骤/操作，来自动地执行测试！
并且，将根据给出的测试用例XML文件进行自动化校验！并根据校验的结果，给出提示或统计数字。
请注意，下面部分描述了对一个系统，应该如何从整体上把握它
1、 初始化“测试步骤XML配置文件”；
在这一部分，我们根据上面给出的“测试步骤XML配置文件”给出一个解析和构造测试类的设计思路！
对“测试步骤XML配置文件”作了一下分析。我们可以看到，它包含的几个元素之间有这样的层次关系：
<Step>
<Operation>
<GetURI>
<Validate>
<Success>
<Condition>
<Failure>
<Condition>
相应地，我们可以将自动化测试驱动类设计成以下层次：
Step
WebAction（抽象类）
Validate（抽象类）
Condition（抽象类）
Step这个类里包含一个类型为Collection的成员变量Operations；所有的测试操作，如：GetURI，我们将等它构造完成后放入Collection中，下面将会提到。
我们还看到，上面有几个类被声明为抽象类。将它们设计成抽象类（请注意，这里出现了抽象类，我们的对象设计开始了）的原因如下：
这个自动化测试驱动方案主要是针对Web的，但不排除以后可以对它进行扩展；同时，在Web交互方式中，可以有多种方式。比如：
访问页面（GetURI）、
提交表单（PostForm）
等；
如果将它们设计成具体类，除了前面的问题外，还有后面将要提到的另外一个问题。
现在，我们来设计一下他们（抽象类）的构造函数。
我们可以采用w3c的DOM API来对XML文件进行解析。对DOM API了解的朋友，都知道它里面有个元素（Element）。于是，通过对前面的“测试步骤XML配置文件”结构分析，我们会意识到，元素（Element）应该是我们考虑的重点。
于是，我们可以为我们的抽象类（如：WebAction）提供一个参数为Element的构造函数，在这个构造函数里，它将进行对提供给它的Element进行解析，提取属于它自己的属性，并对它所包含的子节点（NodeList）留给它的下级对象（如：Validate和Condition）去处理。
比如：从Step的构造函数开始，可以是这样的：
Public Step (Element e)
{
//做一些其他的处理；
NodeList nodes = e.getElementsByTagName("Operation");
//得到Operation节点（NodeList）后，我们接着对他进行解析，如：
operations.addAll(getOperations());
}
在getOperations()方法里，我们将开始运用Java的反射（Reflect）技术和抽象类（Abstract Class）来构造我们需要的具体类；
为什么要用反射（Reflect）和抽象类（Abstract Class）来构造我们需要的类呢？为什么不直接（如使用new操作符）生成我们需要的类呢？
从前面的“测试步骤XML配置文件”，我们可以看到，<Operation>包含<GetURI>，但是，它也可能包含其它Web交互操作，如：<PostForm>等。
我们可以设想一下，如果我们在getOperations()方法里，是对具体类（如：GetURI）进行构造，而不是通过抽象类（Abstract Class）来构造出我们需要的具体类；那么，如果我们新增加一个具体类（如：PostForm），我们就得回过头来修改我们的getOperations()方法！
这显然是不正确的设计思想！而且也不符合程序设计的基本原则！
为了顺利地利用Java的反射技术和抽象类来构造我们需要的具体类，我们可以提供一个“具体类的配置文件”。如果大家对Struts有所了解的话，也许对“具体类的配置文件”这个说法并不会感到陌生。Struts-Config.xml文件里的FormBean、Action都是使用这种“具体类的配置文件”来实现动态创建的。如果大家感兴趣的话，可以看看Struts的源码！
以下给出部分参考代码：
Public Collection getOperations ()
{
//在这里，我们假设已经通过DOM API解析到<GetURI>这个Element了；
//通过element.getTagName()得到“GetURI”；
//再通过“具体类配置文件”得到我们想要创建的类的包名和类名；
String webActionClassName = //从这里得到具体类的名字
//下面通过反射方式生成我们需要的具体类：
Class[] types = new Class[] { Element.class };
Constructor constructor = Class.forName(webActionClassName).getConstructor(types);
Object[] args = new Object[] { element };
action = (WebAction) constructor.newInstance(args);
//通过上面的代码，我们已经创建了一个我们想要的具体类（action）！
}
说明：具体关于反射技术的介绍，在这里并不作详细解释，请大家参考其他文档！
小结：Step是一个具体类，它可能包含很多的Web交互操作（Operation），对于我们这个设想的自动化测试系统，会有很多种不同的Operation存在；因此，我们必须将Operation定义为抽象类，当我们找出系统中一个具体的Operation时，我们可以将它继承于Operation抽象类，如：GetURI、PostForm。然后通过前面的反射（Reflect）技术和抽象类（Abstract Class），来动态生成具体的、实际的Web交互操作类。
因为我采用XML作为我的测试步骤的载体，所以，为了充分地发挥DOM API的作用，我们将类的构造函数设计成以Element为参数！
经过上面的分析，我们已经创建出了Step类，以及它所包含的Operation；
按照上面的思想，我们很容易创建出Operation包含的子类Validate，以及Validate包含的Condition子类；它们的构造方式我们也可以依照上面提到的反射和抽象构造出来！
在这里，我对Condition作一下解释：
上面的XML文件提到的Condition是以ResponseContainText为代表，但是，随着系统的扩大，我们可能会发现更多的Condition。所以，为了使以后扩展系统时，我们不用手动修改以前的代码，这里还是有必要将他们设计成抽象类的，并且运用反射技术来生成实际上需要的类。
通过上面的说明，大家已经初步看到反射（Reflect）和抽象类（Abstract Class）的强大作用了。
大家将在执行自动化测试部分看到使用抽象类（Abstract Class）的好处。
运用类的思想和Java的反射（Reflect）技术，构建出一个灵活、合理的系统（1）http://www.csdn.net/develop/Read_Article.asp?Id=23408
运用类的思想和Java的反射（Reflect）技术，构建出一个灵活、合理的系统（2）http://www.csdn.net/develop/Read_Article.asp?Id=23409
运用类的思想和Java的反射（Reflect）技术，构建出一个灵活、合理的系统（3）http://www.csdn.net/develop/Read_Article.asp?Id=23410
运用类的思想和Java的反射（Reflect）技术，构建出一个灵活、合理的系统（4）http://www.csdn.net/develop/Read_Article.asp?Id=23411
运用类的思想和Java的反射（Reflect）技术，构建出一个灵活、合理的系统（5）http://www.csdn.net/develop/Read_Article.asp?Id=23412
运用类的思想和Java的反射（Reflect）技术，构建出一个灵活、合理的系统（6）http://www.csdn.net/develop/Read_Article.asp?Id=23413
