[Reading Notes] Automated Testing Framework

Below isAutomated TestingThe framework recommendations should be improved in future practices. Generally, an automated testing framework can be divided into two layers: upper layer, which manages the development, execution, and maintenance of the entire automated testing. In a large project, it plays an important role, it manages the entire automatic test, including the execution sequence of automated test cases, maintenance of test scripts, and centralized management of test cases, test reports, and test tasks. The lower layer mainly refers to the development of test scripts. It makes full use of relevant test tools to build test drivers and complete the test business logic.

I. automated test management

The execution mechanism of automated test cases generally includes the management end and the execution end. The management end sends a signal to the execution end to start executing the corresponding test tasks, so as to execute the corresponding scripts for testing, and report the test results to the management end.

1. Management end

The management end mainly completes the following tasks: the operation control decision-making system is responsible for establishing and maintaining the operation queue and controlling the operation policies and signal lights; The management end must also maintain the queue of a test task, the Start Time and status of each test task may be different. The management end controls the task based on these labels.

2. Execution end

The execution end executes the test scripts in the running Queue according to the Decision System of the Management end. The Execution System of the running control is responsible for allocating the test scripts and starting the scripts according to the specified policy.

 

Ii. automated test Script Development

1. Test drive

The test drive is the core of an automated testing framework, which determines the entire automated script design. Currently, the popular test drivers are data-driven and keyword-driven. Using different test drivers is related to the script Reuse Rate and later maintainability.

(1) data-driven

A data-driven automated testing framework means that the test driver engine obtains test data from the data source, passes the data to the test script in the form of parameters, and finally executes the test script, verify the test results and output the test results. Generally, data sources and test results are stored in, Excel files, CSV files, etc. The main advantage of data-driven is the separation of test scripts and test data. When the application function is changed, you only need to modify the scripts of this function; the person executing the test case does not need to understand the implementation of the test script, but only pays attention to the test data table and test report table. In addition, the execution of test scripts is discrete, that is, non-linear. Testers can choose to execute test cases.Database

(2) keyword-driven

The keyword-driven automated testing framework is improved on the basis of data-driven. The data source contains not only data, but also keywords. A test case consists of one or more keywords. Each keyword corresponds to a different business logic, such as logon and logout. Data Tables use keywords to search for ing tables and execute related scripts.

(3) driver Engine

The driver engine analyzes data in a data table and calls the corresponding test script based on different test data or keywords. The driver engine also needs to initialize the test environment, set global parameters, determine whether the test case is executed, and process the test report.

 

 

2. Test Script Development

Test Script Development must pass detailed and reasonable design.CodePartition, hierarchical management of script files or data files. This is conducive to the development and maintenance of automated scripts, which saves the investment cost of automated testing and allows different testers or developers to coordinate the development of scripts.

(1) script Specification

The development of test scripts should also follow the programming rules and standards, and should be planned in a unified manner. All development script personnel should code according to the unified regulations. In addition to programming specifications, the names of test cases and library functions must be considered. The project name must be added to test cases, but public library functions are not required, because public library functions are independent from projects. For example, the project m4.1 client logon test case can be named tc_m4.20.client_login. The function for reading an Excel table can be named read_excel.

 

(2) script Division

The division of test scripts, how to define common script libraries, unique script libraries of different modules, and directly build scripts for test cases. To facilitate script maintenance in the future, scripts must be effectively layered and the reuse rate of scripts is improved.

① Public class library

The public class library includes the operation methods that all modules may use. It abstracts different modules, such as the method for operating Excel tables, the read/write test report, and the driver engine.

② Specific class libraries of the module

In the module, the methods that can be shared by the module are abstracted as a public class. It can be a single logical operation, but also relatively independent. Such as client logon, console logon, and console update.

③ Test case script

The test case is designed based on the test point at the top to target specific applications. It can directly call a public class library or a specific class library of a module, that is, call a single logical operation. It is a collection of one or more logical operations, that is, a test user script. For example, in the test case of client access to resources, it calls the client logon method and resource access method.

 

(3) Test Cases

① Test case Granularity

The granularity of test cases determines the complexity of the case model and the internal complexity of each case. The complexity of each layer should be determined based on the specific circumstances of each system, and the size and number of use cases should be determined on the premise of ensuring the comprehensibility of the entire use case model as much as possible. The use case cannot be too large. Once an error occurs in the execution test case, it is difficult to locate the problem, but it cannot be too detailed. If it is too small, it is not convenient to execute.

 

② Test cases and Test suites

A large project has many functional modules and will inevitably produce a large number of test cases. How can we effectively manage these test cases? In this case, you need to create a test suite and use the test suite to set test cases for a module or function point for easy operation and management. For example, to verify only the functions of the "user management" module, you only need to execute the "user management" module suite.

 

(4) Separating scripts from HTML tags

The separation of scripts and HTML tags makes scripts independent from web pages to a certain extent. scripts do not directly process HTML tags. The script code obtains the variables with web page tag values through the HTML ing table. Web page tags include HTML tags and page content (such as text or images, which may be checkpoints that determine whether the use case is successful). When the web page tag changes, you do not need to modify the script in the range.

 

(5) Select the test cases suitable for automated testing

Before writing an automated test script, you must first determine which use cases are suitable for automated testing, because self-testing is not as intelligent as manual testing, and does not give rise to a new mindset.

Examples suitable for automated testing are:

Product Project. The new version of a product-type project is a project that is improved on the basis of the old version, but the new and old features of the project must be tested repeatedly.

Regression testing. Regression testing is the strength of automated testing. It can verify whether you have introduced new defects and whether the old ones have been modified. To some extent, automated testing tools can be called regression testing tools.

Mechanical and frequent tests. Each time you need to input the same and a large amount of data, and the running cycle in a project is relatively long.

Some interactive operations that require manual intervention should not be completed through automated testing. For example