The general steps of interface automation:
1. Send request
2. Analysis results
3. Verification result
Define three business-related classes
1. One is used to encapsulate HTTPclient, which is used to send requests
2. Class of parsing result xml
3. A class for comparing test results and expected values for verification
4. Classes that automatically generate reports: automatically send reports and the like
(locust's python tool)
Service level: Web server (service) Database (persistence tool - database), Cache (short-term persistence tool - cache)
Interface test:
1. Structure data
(1) Through interface construction
For example, to obtain the article information of a blog, how to structure the data? (Where did the article come from??)—Return to blog information
By adding the interface of the article, temporarily construct the data (blog article), and then check whether it is the data created by yourself when asserting—it will cause interface coupling (the relationship between two program modules is called coupling.)—and create the interface of the article Coupling (if the interface for creating articles is down, the interface for returning blog information will also be down)
The bus card recharge depends on the payment interface service of Alipay. Calling the payment interface will have a cost, so a payment interface is simulated, and all services that simulate the payment interface through the mockserver (test pile) - no matter what the input is, the return is always successful or stable
How to mock? ?
Reference Baidu
(2) Constructed through the persistence layer (better)
It means inserting data directly into the database
2. Call interface
postman/jmeter–win
CURL-linux
Paw–mac
3. Assert on the return of the interface
Through different input - judging different expectations - data-driven (input data)
assertion reference method: compare database values, code verification
4. Use case design for interface testing
Functional test cases
Business logic design
The test cases in business logic are mainly the use case design for the processing logic of the server interface. This kind of use case design is not for whether a certain function point is realized, but for the processing logic of the interface and some interdependence The verification of the business is usually carried out according to the logic flow chart of the interface. To give an example, there are two actions in the shopping system: login and order operation. These two businesses are interdependent. The order operation must be completed after the login (in the login state), otherwise the order cannot be completed. At this time we You can design such a case: place an order without logging in, and see how the server handles it.
It can be seen that there are two judgments in this block. We need to design use cases for different judgment branches to ensure that we have test case coverage for the branches involved in the flow chart. The different branches involved in the figure are:
1.abdf;
2.acg;
3.abdeg;
Correspondingly, our use case should be:
1.userInfo != null && value(userGroup) != 0;
2.userInfo == null;
3. userInfo != null && value(userGroup) == 0;
The use case design of business logic is mainly based on the logic flow chart inside the server interface, and the use case design is carried out for the judgment and branch in the flow chart. Ensure that each logic of the server interface is covered by test cases.
Exception handling:
The server interface and the client usually transmit data through HTTP requests. When sending the request, the client will carry various parameters. At this time, the server will perform different processing according to different parameters. Therefore, exception handling is mainly for the parameters in the request: such as parameter addition and default, parameter data type error, parameter carrying wrong value, parameter is empty, etc., which requires us to go according to various parameters in the interface document. Construct different parameter exceptions and check the response of the server.
In terms of performance and security
, the performance of the server is often a very important concern. In the actual test, we mainly focus on the QPS value of the interface, as well as performance indicators such as CPU and memory usage. Usually, other tools such as LoadRunner are used for performance testing. . In terms of security, some common security strategies such as request encryption, sql injection, etc. are mainly considered.
2. Interface test example
1. postman test
2. Python test
1 # coding:utf-8
2 import requests,unittest
3 class V2ETestCase(unittest.TestCase):
4 def test_ger_node_api(self):
5 python_node_id = 90
6 url = "https://www.v2ex.com/api/nodes/show.json"
7 node_name = 'python'
8 querystring = {"name":node_name}
9 res = requests.request("GET", url, params=querystring).json()
10 print res
11 self.assertEqual(res['id'],python_node_id)
12 self.assertEqual(res['name'], node_name)
13
14 if __name__=='__main__':
15 unittest.main()
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
Run on the command line (for automated testing in the future): 
the report can be generated in HTML form - add it
python as an example:
unittest-library
Requests library
Json
Dict dictionary
assert assertion
Use postman to do interface testing, choose get or post, add data to send requests, and check the returned results—then make assertions for the interface (click the code in the upper right corner, select js language, and write assertions)
When the data returned by the interface is dynamic, such as the latest comments on a website article - or the test environment problem, build an exclusive test environment without generating new data, and the interface can be tested in the same way - equivalent to dynamic data static
The question of "how to do interface testing" can be decomposed into two questions:
how to design interface test cases?
How to perform interface testing?
How to perform interface testing?
Fiddler, SOAPUI, PostMan, etc. can do semi-automatic interface automation testing;
use Robot Framework to do fully automated interface automation testing;
use code to do fully automatic interface automation testing, such as Java+testNG;
Automated interface testing + report generation idea:
In the initial testing phase of the interface, I use POSTMAN to manually test the interface. After a single interface test is passed, copy the test case to Jmeter as the basis for subsequent regular execution, and manually test all the interfaces on the interface. After that, use Jmeter+Ant+Jenkins to regularly check the daily interface and generate a test report, then write a crawler daily monitoring test report, if there is an exception, send an email to the police.
1. The daily historical report must also be kept.
2. The email notification 
Jenkins has a plug-in for email alarm and report display when a case fails~ You don’t need to write it yourself. . .
Finally, it should be the test report. It is integrated in the automated interface test. The daily interface test report is also very important. Although the test report of Jmeter is also very clear, it is not what I want. My ideal test report should have a few then two o'clock
Test pass rate
The process display of each test
The test pass rate is convenient for people who view the report to intuitively understand the results of this test.
The display of the test process needs to display the following content: test results, request address, input parameters, output results, and assertion results. And the identification of success and failure needs to be very obvious.
[A full 200 episodes] A collection of super-detailed advanced tutorials for automatic testing of Python interfaces, which truly simulates the actual combat of enterprise projects