foreword
Interface testing is now the focus of software testing interviews. Basically every company interview will ask about it. Senior sister sorts out the interview questions related to interface testing, and gives some reference answers by the way.
01
Q1: There are multiple API interfaces in an interface use case, how to pass parameters between the two APIs before and after?
That is, the dependence of the upstream and downstream interfaces, the response result a of the A interface is the request input parameter of the B interface.
One way is: get the value of a dynamically.
Another method: For example, setting parameter variables in the interface testing tools Postman and Jmeter. That is to say, after the A interface finishes running, extract the result and put it in the global variable. In this way, other interfaces can get this value. If this variable does not want to be shared globally, it can only be used by the current test suite.
02
Q2: In the process of implementing interface automation testing, if some interfaces do not return for a long time after the first call, how to ensure the smooth progress of the process and record error messages?
If an interface does not return for a long time, it will affect the overall test execution time and execution results.
So we need to set a timeout for each interface, such as 3 seconds. An interface that has not returned within 3 seconds can be identified as an exception.
Of course, it is not that an interface call times out once, it must be an exception, you need to set the failure retry (generally 3 times), if it is executed 3 times and still times out, it can be considered an exception. Many unit testing frameworks in Python can add a rerun mechanism for use case failures. In addition, you can also use the while loop to implement the repeated execution of the use case.
When an interface use case finally retries three times and still fails or times out, we need to record the problem in the system log and finally display it in the test report. But after the use case is executed, it is necessary to ensure that the remaining use cases continue to execute. If the unit test framework is not used, we need to catch the interface call timeout or error exception to ensure that the test task will not be interrupted.
To sum up, it is necessary to ensure that the execution of each interface use case will not take too long, will not cause false positives for a single failure, and can successfully record error messages to ensure that the test task is not interrupted. We need to do three things: set a timeout, add a failure rerun mechanism, record the error log, and capture the exception object if necessary.
In the automation implementation process, in addition to ensuring the normal process, it is also necessary to deal with abnormal scenarios reasonably.
03
Q3: How to test the encrypted interface?
When calling the interface, it is necessary to find out what the encryption method of the interface is.
If it is symmetric encryption, you must first obtain the symmetric key from the developer. Based on the symmetric key, you can encrypt the request data and decrypt the response message.
If it is asymmetric encryption, first obtain the server public key and private key from the development, and also know the current user's public key and private key information. In order to complete the data encryption and decryption of the interface.
04
Q4: How do you check whether the result is correct in the interface test?
1) Verify that the interface response status code is 200. This is the most basic requirement for interface testing. The response status code 200 means that the interface can receive requests and return responses.
2) Verify that the full content of the response is equal to expected. When the interface response body is relatively short and the content of the response body is fixed, you can verify whether the response content is exactly equal to the expected content.
3) Verify whether the response message contains key information. When the response content is long, it can be judged whether the response content contains some key information, which can be used as a verification point for verifying the function of the interface.
4) Verify whether the key field of the response message exists. When the response body is in XML format or JSON format, you can use XPATH or JSONPATH expressions to specify a node in it to determine whether it exists.
5) Verify that the key fields of the response message are correct. In addition to verifying whether the field exists, if the value is fixed or has certain rules, it can also verify whether its value is correct. If the value is fixed, it can be verified to be equal. If it is not fixed, regular expression matching can be considered.
6) Query the database or call other interface queries. When the information to be verified does not exist in the response content of the current test interface, other interfaces can be called for verification. For example, for an interface for adding user information, to verify that the information has indeed been added successfully, you can call the query user information interface to confirm that the user information is added successfully. Of course, in the case of obtaining the database query permission, you can also directly query the database for verification.
7) All of the above are functional verifications. In addition, from the perspective of performance, you can also verify the response time of the interface to see if it is within a reasonable range.
05
Q5: What is the difference between cookie and session?
The cookie data is stored on the customer's browser, which is not very safe. Others can analyze the locally stored cookie and cheat the cookie.
The session will be saved on the server for a certain period of time. When the number of visits increases, the performance of the server will be more occupied.
The data saved by a single cookie cannot exceed 4K. Many browsers limit a site to save up to 20 cookies. Important information such as login information can be stored as a session. Other information that needs to be saved can be placed in a cookie.
06
Q6: How to analyze whether a bug is front-end or back-end?
This situation is easy to judge. First capture the packet and look at the request message, and then look at the interface document to see if there is any problem with the request message. If there is a problem, the data sent by the front end is incorrect
; If the returned data is incorrect, that is the problem of back-end development.
07
Q7: How to design test cases for interface testing?
Interface testing generally considers changes in the form of input parameters and the business logic of the interface. Generally, the design of interface test cases adopts the methods of equivalence classes, boundary values, and scenarios.
The idea of designing test cases for interface testing is as follows: 1. Normal use cases to verify whether the interface logic is correct. According to the description of business logic, input parameters, and output values, the output value obtained under normal input conditions
2. Abnormal use cases, in order to ensure the security of data and the correctness of program logic under abnormal conditions.
The module interface test mainly includes the following aspects: 1) The authentication code token is abnormal (the authentication code is empty <no authentication code>, wrong authentication code, expired authentication code). 2) The request parameters are normal/abnormal. 3) Return result verification, database comparison
08
Q8: What are the ways of jmeter parameterization?
1) Configuration elements --- user-defined variable elements can set global variables.
2) In the function assistant dialog box, you can choose random strings, random dates, and random numbers as parameters.
3) The csv file can be used as parameterization, which can be set through the csv data set config component in the configuration component.
09
Q9: What bugs have you found during your usual interface testing?
You can find many bugs that cannot be found by operating on the page. You can modify the request parameters to break through the input limit of the front-end page.
For example:
1. For example, when an order is paid, the order amount cannot be changed on our page, but we can capture the order payment request through the packet capture tool, then modify the order amount and submit it, and then an order with an original price of 100 yuan appears. The payment was completed with 1 cent.
2. For example, on a transfer page, the restrictions made in the previous section prevent us from entering a negative number in the input box of the transfer amount, but we can modify it through the packet capture tool, and then a bug occurs that the transfer amount is a negative number.
10
Q10: How to test the interface that depends on third-party data?
1) Use the mock tool to simulate the third-party return
2) The test environment itself supports mock data, write the mock data into the json file, and the naming format is consistent with the development code. When asking about the interface, view the log and directly call the mock data.
11
Q11: Common post data submission methods?
application/x-www-form-urlencoded
multipart/form-data
application/json
text/xml
The following is the supporting information. For friends who do [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse also accompanied me through the most difficult journey. I hope it can help you too!
Software testing interview applet
The software test question bank maxed out by millions of people! ! ! Who is who knows! ! ! The most comprehensive quiz mini program on the whole network, you can use your mobile phone to do the quizzes, on the subway or on the bus, roll it up!
The following interview question sections are covered:
1. Basic theory of software testing, 2. web, app, interface function testing, 3. network, 4. database, 5. linux
6. web, app, interface automation, 7. performance testing, 8. programming basics, 9. hr interview questions, 10. open test questions, 11. security testing, 12. computer basics
method of obtaining:
