Summary of automated testing framework

At present, the common automated testing frameworks mainly include 3 Kind of ： Data driven framework 、 Keyword driven framework and hybrid framework .

 

1、 Data driven framework （Data Driven Framework）

    Data driven applications with fixed business logic are most suitable for testing , Only the test data will change . Usually, the test data will be configured in external files or database in .

 

2、 Keyword driven framework （Keyword Driven Framework）

    Keyword driven as the name suggests , It provides a series of general keywords , The user can implement a single operation by calling these keywords and entering some parameters , such as , Open the browser 、 Open a web page 、 Click on a link, etc , Then organize these keywords to form a complete test process .

 

3、 Hybrid frame （Hybrid Framework）

    Hybrid framework is to integrate data-driven and keyword driven , It has the advantages of both . Unlike the keyword framework , This framework usually provides some keywords for specific applications , For example, login. 、 Logout, etc . Then based on the complete test process , Apply another layer of data-driven , This makes test logic and test data more flexible and configurable .

 

One 、 Automated test management

    The execution mechanism of automated test cases generally includes management end and execution end , The management end sends a signal to inform the execution end to start executing the corresponding test task , So as to execute the corresponding script for testing , And report the test results to the management side .

 

1． The management end

    The management side mainly completes the following tasks ： Decision system of operation control , Be responsible for establishing and maintaining the operation queue , Control operation strategy and signal lamp ; At the management end, a queue of test tasks must also be maintained , The start time of each test task may be different , The state is also different , The management side controls it according to these signs .

 

2． Execution end

    The executive end is based on the decision-making system of the management end , To execute the test script in the run queue , The execution system of operation control , Responsible for allocating test scripts , And starting the script according to the specified policy is also the function of the execution end .

 

Two 、 Automated test script development

1． Test drive

Test drive is the core of an automated testing framework , It determines the entire automated script design . Currently, the more popular test drivers are data-driven and Keyword Driven , Use different test drivers , Related to script reuse , And later maintainability .

 

 

（１） Data driven

Data driven automated testing framework refers to the test driven engine to obtain test data from data sources , Then pass the data to the test script in the form of parameters , Finally, execute the test script , Verify test results , And output the test results . General data sources and test results are stored in 、Excel file 、Csv Documents, etc. . The main advantages of data-driven are ： Separation of test script and test data , When the application function changes , Just modify the script of this function ; The person who executes the test case does not need to know the implementation of the test script , Only pay attention to the test data table and test report table . And the execution of the test script is discrete , That is, nonlinear , Testers can selectively execute test cases .

 

（２） Keyword Driven

Keyword driven automated testing framework is improved on the basis of data-driven , Data sources contain more than data , And keywords , A test case is composed of one or several keywords . Each keyword corresponds to a different business logic , for example , Sign in 、 Write off, etc . Data table through keywords , Lookup mapping table , Execute relevant scripts .

 

（３） Drive engine

The driving engine is to analyze the data of the data table , Call the corresponding test script according to different test data or keywords . The driver engine also needs to complete some test environment initialization 、 Global parameter setting 、 Whether the test case is executed , And the processing of test reports .

 

2． Test script development

　　 Test script development must pass detailed 、 Reasonable design , Divide the script code , Hierarchical management of script files or data files . This is conducive to the development and maintenance of automated scripts , So as to save the investment cost of automated testing , It also allows different testers or developers to coordinate the development script .

 

（１） Script specification

　　 The development of test script should also follow the rules and standards of programming , It should be planned uniformly , All script developers code according to unified regulations . In addition to the specification of programming itself , Also consider the naming of test cases and library function names , The test case needs to be added with the project name , But public library functions don't need , Because public library functions are project independent . for example , project M4.1 The client login test case can be named ：TC_M4.1_client_login; Read excel The function of the table can be named ：read_excel.

 

（２） Script partition

Division of test script , How to define a common script library , Script libraries unique to different modules , And scripts that directly build test cases . In order to facilitate the maintenance of scripts in the future , Scripts must be effectively layered , meanwhile , It improves the reuse rate of scripts .

 

① Public class library

The common class library includes all modules and user's operation methods , It abstracts different modules , Such as operation excel The method of table 、 Read and write the test report 、 Drive engine, etc .

② Module specific class libraries

Abstract the methods that can be shared and used for the module inside the module , As a public class . It can be a single logical operation , Also relatively independent . For example, the client login operation 、 Console login operation 、 Console update operation .

③ Test case scripts

Test cases are at the top , It is designed according to the test points , For specific applications . It can directly call methods of public class libraries or module specific class libraries , That is, call a single logical operation . It is a collection of single or multiple logical operations , That is, a test user script . such as , Test cases for accessing resources on the client , It calls the client login method and the resource access method .

 

（３） The test case

① Test case granularity

The granularity of test cases determines the complexity of use case model level , It also determines the internal complexity of each use case . We should grasp the complexity of each level according to the specific situation of each system , Determine the size and number of use cases on the premise of ensuring the comprehensibility of the whole use case model as much as possible . Use cases cannot be too large , In this way, once there is an error in executing the test case , It's not good for positioning ; But not too detailed , Too small is not convenient to implement .

②  Test cases and test suites

A large project has many functional modules , There will inevitably be a large number of test cases , How can we effectively manage these test cases ？ This requires creating test suites , Test cases for testing a module or function point are collected through the test suite , Convenient for operation and management . for example , Just verify “ User management ” Module function , Only need to execute “ User management ” Module kit is ok .

 

（４） Script vs html Mark separation

Script vs html Tag separation makes the script independent of WEB page , Scripts are not handled directly html Mark , The script code passes html Mapping table get endowed WEB Variables of page tag values .WEB Page tags include html Tags and page content （ Text or pictures, etc , These may be checkpoints to judge whether the use case is successful ）, When WEB After the page tag is changed , There is no need to modify the script in the scope .

 

（5） Choose the use case suitable for automated testing

Before writing automated test scripts , First, determine which use cases are suitable for automated testing , Because automated testing is not like manual testing , It can't be so intelligent , There is no divergent thinking .

Generally, the use cases suitable for automated testing are ：

Product type project . Product based projects , The new version is an improvement on the old version , Items with little function , But the new and old functions of the project must be tested repeatedly .

regression testing . Regression testing is the strength of automated testing , It can be a good way to verify whether you have introduced new defects , Whether the old defects have been corrected . To some extent, automated testing tools can be called regression testing tools .

Mechanical and frequent testing . You need to enter the same... Each time 、 A lot of data , And it takes a long time to run in a project .

Some are more interactive , Operations requiring manual intervention , Don't expect to complete it through automated testing . for example , The user to use DKEY Sign in