Automated Test scripting Technology

One, linear script

Advantages of linear scripting:

1. Linear scripts do not require in-depth work or planning, just sit in front of the computer and use automated test tools to record manual test tasks.

2. Linear scripting can quickly start to automate, and test engineers need to understand the test process to do automated testing, but also to set up test engineers to begin to be interested in automation of the fastest method and technology.

3. The linear script can perform an audit trail of the actual operation.

4. Using linear scripting techniques, the user does not have to be a programmer (assuming that the script is not modified, the user does not need to care about the script itself).

5. The linear script provides a good demonstration effect.

Disadvantages of linear scripting:

1. The process is tedious: producing viable automated tests (including comparisons) takes 2 to 10 times times longer than running manual tests.

2. Everything depends on what is captured in each test.

3. Test input and comparison, as well as testing data and business are ' bundled ' in the script, not easy to modify test data and test steps.

4. Scripts cannot be shared and reused.

5. Because the linear script requires that the object being tested is relatively fixed, it is susceptible to software changes.

6. Linear script modification is expensive (high maintenance cost).

7. If there are no events that occur when the script is recorded when the script is played back, such as an unexpected error message from the network, the script can easily conflict with the software being tested, causing the entire test to fail.

Scope of application of linear scripts:

1. When the test case is used only once, there is no need to spend too much effort on the script that will be discarded, and the linear script is very handy.

2. Linear script is suitable for training or presentation, you can play back the recorded script to replace the keystroke action.

3. Linear scripts can be used for conversions. If a part of the system changes, but from the user's perspective does not affect the work of the system, you can record useful data, replace the software or hardware, and then playback the recording process can bring the new system back to its original state.

4. Linear scripts can use automatic editing to modify automated tests, and any specific modifications are done only once, so a one-time script is sufficient to meet the requirements.

5. Linear scripts can be used to set up and purge tests, set up and purge corresponding records by playing back input sequence action files or databases.

Second, structured scripts

Currently, all of the test scripts support three basic control structures as follows:

Sequential structure (that is, the preceding linear script, which executes each line of instructions sequentially).

Select structure: Make the script have a judgment function, that is, add a statement like "If,switch" to make the execution of the script jump, and execute the relevant instruction according to the judging condition.

Iterative/Looping structure: You can repeat one or more instruction sequences as needed, such as adding statements like "For,while".

Structured scripts are similar to structured programming, where scripts contain instructions for controlling the execution of scripts, either for controlling structures or for invoking structures. A structured script can be nested to invoke another script after execution is returned to the current script.

Advantages of structured scripting:

1. Structured scripts are more robust and can be handled appropriately for special situations that lead to test failures and exceptions that occur during testing.

2. A structured script can be called or used as a module by another script, just like a function.

3. Structured scripts can improve the reusability and flexibility of scripts, make the code easier to maintain, and better support automated testing.

Disadvantages of structured scripting:

1. The script becomes very complex and adds additional maintenance effort to some extent.

2. The script is also based on the recording/broadcast, so the script is still bundled with the test data and logic, that is, keyboard, mouse action representation of the input is cured in the script, test modification and customization is very complex difficulties.

Third, sharing the script

Sharing the script means that the script can be used by multiple test cases, that is, the scripting language allows a script to be called by another script, saving the time it takes to generate the script. When repetitive tasks change, you only need to modify one script. Shared scripts can either share scripts between different hosts, different systems, or share scripts between the same host and the same system. The idea of this script development is to produce a script that performs some kind of task, and the different tests repeat the task, and when the task is executed, it is only possible to invoke the script in the appropriate place.

Advantages of sharing scripts:

1. Shared scripting makes it less expensive to implement similar tests.

2. Shared scripting is less expensive to maintain than linear and structured scripts.

3. Delete the obvious duplicate code in the shared script, which makes the code more concise and understandable.

4. You can add more intelligent features in a shared script, such as the thought of waiting for a certain time to run a feature again.

Disadvantages of shared scripting:

1. You need to keep track of more scripts, documents, names, and storage. If the management is not good, it is difficult to find the appropriate script.

2. A specific test script is still required for each test case, so maintenance costs are high.

3. Shared scripts are often targeted at some part of the test software and cannot be shared in real sense.

The writing of shared scripts requires higher programming skills and improved requirements for test engineers data-driven scripting is a widely used automated test scripting technique that stores test input data in a data file rather than continuing in the script itself. The script only holds control information, and when the test is executed, the data input is read from the file rather than from the script, so that the same script can perform different tests and separate the data from the script, but the test logic is still bundled with the script.

Iv. Data-driven scripting

Benefits of data-driven scripting:

1. At the level of data-driven scripting, automated testing can really benefit from the fact that many test cases can be automated with a small additional overhead, without the need to write more scripts.

2. In a data-driven script, the format of the data file is very easy for testers to handle, and even a number of easy-to-maintain annotations can be added to the data configuration file to increase the understanding of the data.

3. Data-driven scripting technology allows test engineers to devote more time and effort to automated testing and maintenance testing.

4. Data-driven scripting technology is very convenient for data entry and maintenance of test cases.

5. In data-driven scripts, even the desired results can be extracted from the script, making it easier to maintain the script.

6. For a set of powerful and flexible data-driven scripts, the tester does not even need to have scripting skills, but only master the data file configuration method, you can easily use the script to complete their own tests

Disadvantages of data-driven scripting:

1. A person with certain programming background knowledge should be added to the script.

2. Because the script becomes more logical and introduces more control instructions, the initial script setup time and overhead is large.

3. If the script is not standardized, later management and maintenance will bring a huge amount of work, for the test project I need more skills.

V. Keyword-driven scripting

Keyword-driven scripting is actually a logical extension of a more complex data-driven script. Data Driven foot

The limitation of this is that the navigation and operation of each test case must be the same, the logical knowledge of the test is established in the data file and the control script. The keyword-driven script transforms the data file into a description of the test case, specifying the task to perform with a series of keywords. One feature of keyword-driven scripting is that it looks more like describing what a test case does, rather than how to do it. The first four scripts are scripts for descriptive methods, and only keyword-driven scripts are descriptive methods, making them easier to understand. The descriptive approach is to build the knowledge of the software being tested in a test automation environment, where the relevant knowledge is included in the support script that understands the software being tested, but does not need to know the test case.

Three separation of core ideas

1) The separation between the interface element name and the test internal object name adds an abstraction layer between the tested application and the recorded test script, which maps all the elements on the interface to a corresponding logical object, and the changes to the interface elements will only affect the mapping table, without affecting the test.

2) Separation of the test description from the specific implementation details

Separate the specific implementation details of the test description and test. The test description only describes what the software tests do and what results are expected, regardless of how the test is performed or how the results are verified. This is done because the implementation details of the test are often closely related to a specific platform and to a specific test execution tool. This separation makes the test description insensitive to application implementation details and facilitates the testing of porting between tools and platforms.

3) Separation of scripts and data finally, you can put the test execution process

The required test data is extracted from the script, and at run time the script is then read from the data store to pre-custom data, so that the script and data can be maintained independently.

These three separate roles and independence to minimize the impact of each other. It can be seen from the keyword-driven idea that this kind of testing framework not only realizes the separation of data and script, but also realizes the separation of test logic and data, greatly improves the reusability and maintainability of the script, and thus realizes the automation of testing tools more.

Typical elements of an automated test framework based on test cases

1) Common environment

Different test cases will also use the same test environment, the test environment is encapsulated independently, in each test case flexible invocation, you can enhance the maintainability of the script.

2) Common objects

Successful framework development requires the identification of a domain-specific "hotspot" (Hot spot). So in the development process there must be a large number of identical objects (such as Windows, buttons, pages, etc.). Extracting objects to form a single, reusable, and strong individual, when the properties of an object need to be changed, you can simply modify the object's properties without having to modify the script.

3) Common methods

The method is encapsulated into a separate function, called by the parameter, as far as possible and data independent.

Automated Test scripting Technology