Use the idea of the class and the reflection of Java, build a flexible, reasonable system
- Write to Java beginners
Second, several major classes in the automation test
In this envisioned automation test system, an automated test is performed, always starts from reading the test step XML configuration file, then initializing / constructing some test objects; finalizing the test step defined according to the XML configuration file / Operation, active testing! Further, the automated check will be performed according to the test case XML file given! And according to the results of the verification, a tips or statistics are given. Note that how the following sections describe a system, how should it be grasped
1. Initialize the "Test Step XML Profile"; in this part, we give a design idea for parsing and constructing test classes based on the "Test Step XML Profile" given above! The "test step XML configuration file" has been analyzed. We can see that there is such a hierarchical relationship between several elements:
Accordingly, we can design the automated test driver class as the following level: Step WebAction Validate (Abstract class) Condition
STEP This class contains a member variable of Collection Operations; all test operations, such as: geturi, we will put into the Collection after it is completed, and will be mentioned below. We also see that there are several classes that are declared as an abstract class. It is designed to abstract classes (please note that there is an abstract class, our object design begins). The reason is that this automated test driver is mainly for web, but it can be extended without excluding; In the web interaction, there can be many ways. For example: Access page (Geturi), submit form (postform), etc. If they are designed to specific classes, in addition to the previous problems, there is another problem that will be mentioned later. Now let's design the constructor of their (abstract class). We can use W
3C
The DOM API is parsed to the XML file. Friends who know the DOM API know that there is an element in it (ELEMENT). Thus, by analyzing the previous "test step XML configuration file" structure, we will realize that the element should be the focus of our consideration. Thus, we can provide a configuration function for our abstract class (such as: WebAction), in which the constructor, it will parse the Element provided to it, extract its own properties, and It contains the subtraction of the child node (NodeList) to which it is processed (such as: validate and condition). For example, starting from the construction function of STEP, it can be such: public step (ELEMENT E) {// Do something else; Nodelist Nodes = E.GETELEmentsByTagname ("Operation"); // Get Operation Node (Nodelist) We followed him, such as: Operations.addall (GetOperations ());} In the getOperations () method, we will start using Java reflections and abstract classes to construct what we need. Specific class; why do you want to construct the class we need with reflection and abstractratilas? Why not directly (if using a new operator) to generate the class we need? From the previous "test procedure XML configuration file", we can see that
If you are interested, you can check out the Struts source code! The following reference code is given: public collection getOperations () {// Here, we have assumed that you have parsed to
Summary: STEP is a specific class that may contain a lot of web interaction (Operation), there will be many different Operation existence for our envisioned automation test system; therefore, we must define Operation as abstract classes, When we find out a specific Operation in the system, we can inherit it in the Operation abstraction, such as: Geturi, Postform. Then dynamically generate specific, actual web interaction classes via the previous reflection techniques and abstract classes. Because I use XML as the carrier of my test step, so in order to fully play the role of the DOM API, we design the class constructor as a parameter! After the above analysis, we have created a Step class, and the Operation it contains; according to the above ideas, we can easily create the subclass Validate containing Operation, and the condition subclass included in Validate; It can also be constructed in accordance with the reflection and abstract configuration mentioned above! Here, I explained to Condition: The above XML file is represented as responsecontaintext, but as the system expands, we may find more Condition. So, in order to make the system, we don't have to manually modify the previous code, it is still necessary to design them into an abstract class, and use reflection techniques to generate the actually needed classes. Through the above description, everyone has initially seen the power of reflection and abstract classes. Everyone will see the benefits of using abstract classes in the execution of the automated test part.