Starting from this issue, we will do a series of special topics around "Python interface automation", and today we will do the first lecture-Automated Test Layering.
table of Contents:
1. 1.1.1 Unit automated testing
2. 1.1.2 Interface automation test
3. 1.1.3 UI automation testing
Nowadays, pyramid-shaped hierarchical testing is popular, and the testing is divided into three layers: UI testing layer, interface testing layer, and unit testing layer from top to bottom.
On the basis of traditional UI automation, implement more code-based low-level automated testing, not just end-to-end testing through the user interface.
From the point of view of black box, white box, and gray box in the test method:
Simple UI automation-gray box testing cannot achieve good coverage of requirements. Interface automation-gray box testing and unit automation-white box testing are also required.
And due to frequent changes on the demand side, the investment in the implementation of automation in the interface is relatively minimal, the implementation is the most stable, and it has high benefits.
1.1.1 Unit automated testing
Unit/module automation is directly automated testing of code logic, most of which are implemented by development, and a small number of companies will implement white box testing.
Commonly used tools include Java's Junit, testNG, Python's unittest, pytest, etc.
Driver code, stub code and mock code:
●The driver code is used to call the function under test, while the stub code and mock code are used to replace the real code called by the function under test
The logical relationship between driver code, stub code and mock code.
●Driver code (Driver) refers to the code that calls the function under test. In the process of unit testing, the driver module usually includes three steps: data preparation for calling the function under test, calling the function under test, and verifying related results.
●Stubs are temporary codes used to replace real codes. For example, an unimplemented function B is called in the internal implementation of a function A. In order to test the logic of function A, a function B needs to be simulated. The realization of this simulated function B is the so-called stub code.
In some cases, when the project structure has many levels, it can also be subdivided into:
1. Unit Testing
2. Module testing
Unit testing: testing the smallest unit of the program, generally testing classes, objects, methods, and functions;
Module testing: Testing of code with obvious functional characteristics, thinking that unit testing only involves part of this layer of testing.
1.1.2 Interface automation test
1.1.2.1 Classification of interface tests
According to the different calling methods of the system, the interfaces can be divided into three types:
1. The interface between the system and the system
2. The interface of the lower service to the upper service
3. Inside the system, the interface between services and services
Interface between system and system
It can be an interface called between different systems within a company, or an interface between different systems of different companies.
For example: third-party login interfaces provided by WeChat and Weibo, and third-party payment interfaces provided by Alipay.
The interface of the lower service to the upper service
The application layer can be considered as the UI layer function, for the web is login, registration, query, delete, etc.
The Service layer can be understood as a data processing database provided by the server, which is mainly used to store data, such as user information, product information, etc.
The interaction between the layers is through the interface, the application layer and the service mainly through the HTTP interface, the service layer and the database layer through
DAO (Data Access Object) database access, such as pymysql.
The interface between services and services within the system:
In the system, the service calls between services, mostly refers to calls between programs. The essence is the function or method of program development, providing input and participating in the return value.
1.1.2.2 The significance of interface testing
●Find problems earlier
●Shorten product development cycle
●Discover lower-level problems
Interface testing is simpler than UI testing and comprehensively covers the underlying code logic. The UI layer is called weak verification and is easily bypassed. It is difficult to find some abnormal situation handling capabilities in the backend, while interface testing is easy to verify.
1.1.3 UI automation testing
UI automation is currently the most automation done. It is the test closest to the user side in automated testing. It tries to execute black box functions and UI tests with programs or functions.
The automation tools at the UI layer are generally classified according to the platform: windows, Linux, Android, IOS, Web, WeChat applets, etc.
Currently commonly used UI automation tools can be roughly divided into different platforms:
1. Desktop Automation Tools
2. Web-side automation tools
3. App automation tools
Desktop automation tool
Desktop automation is currently implemented relatively few, and there are many tools, but there are few particularly mainstream tools commonly used: AutoIt3, pywin32, Microsoft UI Automation.
Web-side automation tools
Selenium is currently the most mainstream web automation tool. It almost perfectly supports all mainstream browsers and mainstream programming languages. It is lightweight and open source.
App automation tools
Currently the most mainstream is Appium, which supports android and ios automation, open source, and supports multiple development languages