Software test automation is classified from different test stages, which can be divided into unit test --> interface test --> interface automation test from the lower layer to the upper layer .
Unit testing is generally done by developers themselves, but it is difficult to achieve suitable test conditions for interface automation testing. In addition to complicated manual interface testing, testers
More participation in interface testing should have a lot of room for improvement in work efficiency and personal technical ability.
From my superficial understanding, interface testing is mainly divided into two categories: code layer interface testing and Web HTTP interface testing , and code layer interface testing is more closely related.
Let's do some unit testing, and the web interface is mainly manifested in two categories:
1. The interface between the browser and the server
2. External interface (interface provided by a third party)
Web interface testing tools:
You can use postman for manual testing, and Jmeter (open source) and soupUI (open source & commercial version) are mostly used for automated testing.
Because jmeter can also do stress testing, and it is open source software, so I did a little more learning about jmeter doing interface testing.
Not much to say, let's use jmeter to run an interface to see:
1. Open jmeter
Both the open source version and the executable version can be downloaded from the Apache official website. After decompression, open the jmeter.bat file in the bin directory, and the user interface will open:
2. Add related components
2.1, Create a new thread group
2.2. Add http request
2.3, add a listener -- view the result tree
2.4. Set http request related parameters
3. Execute the test and view the results
View the test results in the monitor-view result tree
Return status code 200, indicating that the request is successful, if the request fails, it will return 400, 404, 500, etc.
4. The script is optimized and perfected
The above is a simple interface testing process, which is far from enough in actual work and needs to be further optimized
4.1, add http request default value
Generally, public information such as the server's ip and port are set in the default value of the request:
4.2 Add response assertion and assertion result listener
4.3 Add other components
When there are many test cases, it is difficult for the basic components to effectively execute the use cases. We often use: regular expression extractor, CSV DATA SET CONFIG, if conditional controller,
Control elements such as loop controllers, user-defined variables, etc.
5. Execution effect after adding a large number of test cases
5.1 Distribution of use cases
5.2 View test results
Test results can be viewed through listeners such as viewing the result tree, aggregated reports, and table viewing results
