Common interview questions for interface testing (with answers)

Content-Type: application/x-www-form-urlencoded
Features: The data type is a dictionary, which is equivalent to submitting data through a form. The format of the data: a=1&b=2

Content-Type: multipart/form-data
Features: The message contains file upload.

Content-Type: application/json
Features: Messages are all string type

Content-Type: binary
Features: The message type is to upload files in binary mode.

3. Common request headers and what are their functions?

Accept: The data format received by the client.

X-Requested-With: Asynchronous request. Ajax asynchronous request. No refresh.

User-Agent: The type of client sending the request.

Content-Type: The message format of the requested content.

Cookie: Cookie information.

4. What is the difference between get request and post?

Both can submit data to the server and get data from the server.

the difference:

① The parameters are passed in different ways: get passes parameters through the address bar, and post passes parameters through form messages.

② The length of the parameters passed is different: the parameters of get have length restrictions, but the parameters of post do not.

③ Under normal circumstances, get is to obtain data, such as query, and post is to submit data, such as addition, deletion and modification.

④ Get only sends one tcp data message (including request header and data), and post sends two messages (1. Request header, returns ·100, 2. data, returns 200)

5. Commonly used return status codes in interface requests

1XX: Information prompt.

2XX: Success.

3XX: Redirect. (When sending a request, the request requests multiple resources of the server multiple times)

4XX: Client error.

5XX: Server error.

6. What are the similarities and differences between cookies, sessions, and tokens?

The same thing: both are used for authentication and are generated by the server.

difference:

① Cookies are stored on the client's browser. Cookies are not secure. You can analyze local cookies for cookie spoofing.

② The session is saved in the server's memory and is saved for 30 minutes by default. It is safer than cookies. The disadvantage is that the more users log in, the more server resources will be occupied. The session generally generates a sessionid (customized name), and the sessionid can be transmitted through cookies.

③ The token is stored in the server's database and is obtained through an interface or by logging in. Then all subsequent interfaces must pass the token before the request can be successful. Tokens can also be transmitted via cookies.

7. How does your company do interface testing? (Including: interface testing process, solutions and use case design)

① Obtain interface documents and be familiar with the business of single interface and link interface (interface business process), including interface address, authentication method, input parameters, output parameters, error codes, etc.

② Write interface test cases and review them

Positive example (1-2): Single interface returns success scenario, link interface business process is implemented. (functional business process);

Counterexample:

Authentication exception: empty, error, expired...

Parameter exception: null, type exception, length exception

Exception error code:

Other exceptions: interface blacklist, interface call limit. Paging (less than 0, 0, middle page, maximum page, more than maximum page);

③ Use interface testing tools or code to perform interface testing;

It is important to consider the following:

Interface association, interface parameter encryption, whether the parameters are dynamic, whether the interface parameters are signed, and whether request headers are required.

④ Implement continuous integration and output interface test reports, report bugs if there are any.

8. How to do interface testing if there is no interface document?

Method ①: You can use the Fiddler packet capture tool to capture the interface data and organize it into an interface document. If there are unclear fields, find time to focus on development verification, and then conduct interface testing.

Method ②: You can use Jmeter's proxy recording function to first record the interface request to form an interface document, and then test the interface one by one.

9. In interface testing, how to test interfaces that depend on login status?

The interface that relies on login essentially requires cookie and session to be sent successfully every time a request is sent. You need to add the cookie and sessionid when requesting.

① If you test through Postman, Postman will automatically manage it.

② If testing through Jmeter, you need to add the Cookie Manager component.

③ If the interface test is implemented through code, then a session object needs to be generated, and then the request is sent through the session object. |

10. What bugs have you found during your usual interface testing?

① General bugs: The interface is not implemented, the results are not returned according to the interface document, abnormal values (null values, special characters) are entered, the interface reports errors, and no reasonable error prompts are returned.

For example: the purchase product interface has price parameters. When I went to test it, I changed the price of the product to -3 and the purchase was successful.

②Permission Bug:

For example: when testing the interface for modifying product information, the interface document requires that only merchants and super administrators have permission to modify it. I passed in the ID of an ordinary user or the ID of another merchant, and the modification was successful.

Note: Interface testing is to avoid bypassing front-end verification and directly accessing the back-end interface BUG.

11. How do you verify whether the results are correct during interface testing?

① Status code verification, verify that the returned status code is 200.

② Business verification:

a. The error code is 0

b. When the interface response message is relatively short and relatively fixed, the verification is completely consistent.

c. When the interface response message is relatively long and numerous, verify the core business information.

d. When the interface response message is in a very complex multi-level XML format or JSON format, obtain the most keyword business node through Xpath, JSONpath, and regular expression matching methods, and then verify it.

e. Query the database for verification or verify through other interfaces.

12. How to analyze whether a bug is front-end or back-end?

Capture the packet through the packet capture tool, and then check the request message. If there is a problem with the request message compared to the interface document, then it is a front-end problem. If there is no problem with the request message, then look at the return message. The returned data is incorrect, that is Back-end development issues.

13. How to test interfaces that rely on third-party data?

Interface association (dependency) means that the interface in the project depends on the interface of this project.

You can build a Mock service through Postman, but Postman's Mock service has a limit on the number of accesses, which can only be accessed 1,000 times a day. Interface Mock services can also be implemented through Servlet, Flask and other technologies.

14. For encrypted interfaces, how to test signed interfaces?

Encrypted interface: When calling the interface, you must first figure out the encryption method of the interface?

Such as:

① Symmetric encryption method (private key encryption): DESAES is less commonly used, and Base64 encryption method is commonly used.

② Asymmetric encryption method (dual-key encryption): RSA encryption method.

③ Only encryption but no decryption (MD5 encryption)

④ Customize encryption rules. Hybrid encryption method.

After understanding the encryption rules (signature rules), before requesting the interface, you must first encrypt (sign) the parameters accordingly and then send the request. Some single encryption methods are supported by postman and Jmeter. Postman is implemented using javascript scripts, and Jmeter is implemented using java code in beansheI.

15. Please elaborate on how interface testing and UI testing work together in testing activities?

The collaboration between UI and interface testing can be considered from the following directions:

The operation of the UI is actually to call the interface in another way. So how many parameter combinations the interface has depends on how many operations the UI use case needs to construct to call.
The data required for UI operations can be generated using interfaces
Interface testing can ensure the accuracy of data and logic. UI testing needs to consider the logical correctness of interaction and interface display.
UI testing needs to pay attention to the presentation method and user experience of the UI when the interface call is unsuccessful or the interface is abnormal.
There may be some status cache information in the UI (so you don’t need to frequently call the interface to obtain it every time), such as authentication information, etc. You need to focus on the update strategy of these caches.

16. How to deal with data dependencies on upstream and downstream interfaces during interface testing?

If a transaction needs to call two interfaces sequentially: A and B interfaces, and B relies on the response data of the A interface, then the A interface must be completed before the B interface is executed, and the specific data of the A interface must be obtained through some means for use by the B interface. .

The data dependence of the upstream and downstream interfaces is nothing more than preparing test data. There are generally three ways to obtain data:

Independent and unified test database, the data required by A and B can be obtained from the database
If B relies on the data created by A, then A must be executed to create data before each execution of B.
Dynamically obtain the return data of A through regular expressions, save it in a variable, and pass it to the B interface in a parameterized manner.

17. What is webService interface testing?

The webService interface has a complete set of protocol standards, mainly the soap protocol, which is used to transmit messages. The returned results need to be packaged in a syntax format specified by the soap protocol. Even if you only need to simply return character 1, you still need to wrap the return in a protocol. The protocol describes success or failure, the result value, etc. You can use the soapUI testing tool to simulate and test the interface.

Features of web service interface:

The methods and required parameters implemented in the interface are clear at a glance.
Don't worry about capitalization.
Don't worry about Chinese urlencode problem.
There is no need to declare authentication (account, password) parameters multiple times in the code.
The parameters passed can be arrays, objects, etc.

18. How to obtain the parameters of the interface?

When designing interface test cases, the e-commerce system is involved, which includes many modifications, such as products, merchants, stores, etc. Modifications to these data will involve many parameters. Such as the name of the product, the size of the product, the color of the product, etc.

So when designing and implementing the "modify" interface, how to determine which parameters to pass? Do I need to pass only the parameters I want to modify, or all parameters?

Method 1: The key is to look at the background logic implementation

For example: User has two attributes username and password.
The background logic implementation is: update User set username=? where id=xxx;
then, if you only want to update username, you can not pass password, and its value will remain unchanged.
Background logic implementation: udpate User set username=?,password=? where id=xxx;
In this case, even if you only want to update username, you need to pass the password value to the background, otherwise the password will be updated to empty.
In addition, there are some data such as id, etc. If it is not written in the sql, the database will not be updated even if the parameters of this field are passed. Therefore, when writing an interface about "modification", you need to consider how the background logic is implemented, and then confirm which parameters to pass.

Method 2: Analysis of the interface situation captured directly by the packet capture tool

If the system has been implemented and the interface logic has been determined, then we can use Fiddler and other packet capture tools to capture the request packets of the corresponding business and analyze the parameter information passed in them.

19. Why do we need to do interface testing?

Interfaces are ways to obtain and operate resources, and in most systems and products, resources are generally the core of the product. For example, the core resources of WeChat are address book relationship chains and chat records, so resources must be tested.

In addition, most of the content in the interface is data. Through data comparison, we can infer the logic of the system and product. Testing the interface is testing the logic.

Finally, the return in the interface is relatively simple. Unlike the web page, there are too many UI things in the HTML code. The UI is the most unstable and changes too fast. The interface is relatively stable, but there is less interference information in it, and it is relatively easy to make assertions. .

20. What is the most common way to transfer data through HTTP interface?

The Get method is to obtain data from the server; when doing data query, it is recommended to use the Get method; such as: product information interface, search interface, blog visitor interface, etc.

The Post method is to transmit data to the server; when adding, modifying or deleting data, it is recommended to use the Post method; such as: Weibo picture upload picture interface, login registration interface, etc.

21. What is interface testing?

Interface testing is a type of testing that tests the interfaces between system components.

The focus of interface testing is to check the exchange of data, the correctness of transmission, and the logical dependencies between interfaces.

The importance of submitting interface tests: to achieve parallel testing during the development period, reduce the depth of page-level testing, and shorten the testing cycle of the entire project.

22. Which category does the interface we test belong to?

Most interfaces refer to the HTTP interface, usually referring to the B/S architecture, which is called by the client (browser), or simulates the client (browser) calling the API interface provided by the server, and the interface completes the processing and returns a response. the process of.

Common interface types include: Webservice interface, http interface, jms interface, hessian interface, and REST interface.

23. What are the key points in writing interface test cases?

Test if each parameter type is illegal (equivalence class)
Test the illegal value range of each parameter (equivalence class)
Test the case when the parameter is empty (equivalence class)
Test the consistency of front and back definition of parameters
Test the upper and lower limits (boundary values) of each parameter
If the two requests have a strict sequence, you need to test the order reversal (parameter combination and order)
Parameter combination testing (parameter combination and order) when interface parameters have optional and required conditions

24. What are the basic steps of interface testing?

1) Get the request message data

Obtain the request message parameters through the fiddler tool or API interface document, which includes the request method (get, post, put, etc.), URL address, requested query string parameter, and requested body data.

2) Use tools to simulate request messages and send them

Organize the parameters obtained in the first step into interface parameter tools such as jmeter, postman, soapui, etc., simulate the interface request and send the request.

3) Get response results

After using the interface testing tool to send a request, a response message will be returned to analyze whether the data in the response message meets the requirements.

4) Assertion: Determine whether the actual result is the same as expected

You can also add preset assertions in the tool. After running the interface test, it will automatically return whether the interface is implemented correctly. We can use the response status code of the response message, the response headers, or the response body data (html, json format, etc.) to make assertions.

25. What are the characteristics of the HTTP protocol?

1) HTTP is connectionless

The meaning of connectionless is to limit each connection to only process one request. After the server processes the client's request and receives the client's response, it disconnects. This method saves transmission time.

2) HTTP is media independent

This means that any type of data can be sent over HTTP as long as the client and server know how to handle the data content. Clients and servers specify the appropriate MIME-type content type to use.

3) HTTP is stateless

The HTTP protocol is a stateless protocol. Stateless means that the protocol has no memory ability for transaction processing. The lack of status means that if subsequent processing requires the previous information, it must be retransmitted, which may result in an increase in the amount of data transferred per connection. On the other hand, the server responds faster when it does not need previous information.

26. What parts does the HTTP client request message contain?

The client sends an HTTP request to the server. The request message includes the following format:

request line
Request header
blank line
Request data

27. What information does the HTTP server response message contain?

The HTTP response consists of four parts, namely:

status line
message header
blank line
Response body

28. There are multiple API interfaces in an interface use case. How to transfer parameters between the two APIs?

That is to say, the dependence of the upstream and downstream interfaces. The response result a of interface A is the request input parameter of interface B.

One method is: dynamically obtain the value of a.

Another method: For example, set parameter variables in the interface testing tools Postman and Jmeter. That is to say, after the A interface is completed, the results are extracted and placed in global variables. In this way, other interfaces can obtain this value. If this variable does not want to be shared globally, it can also be provided only to the current test suite.

29. When you implement interface automation testing, if some interfaces do not return for a long time after being called for the first time, how can you ensure that the process proceeds smoothly and error information can be recorded?

If an interface does not return for a long time, it will affect the execution time and results of the overall test.

So we need to set a timeout for each interface, such as 3 seconds. If an interface does not return for more than 3 seconds, it can be positioned as an exception.

Of course, it does not mean that an interface times out when one call is made. It must be set to retry on failure (usually 3 times). If it still times out after executing it 3 times, it can be considered an exception. Many unit testing frameworks in Python can add a rerun mechanism if a test case fails. In addition, you can also use while loops to implement repeated execution of use cases.

When an interface use case still fails or times out after three retries, we need to record the problem in the system log and eventually 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 we do not use a unit testing framework, we need to capture interface call timeout or error exceptions 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 does not take too long, does not cause false alarms after a single failure, and can successfully record error information to ensure that the test task is not interrupted. We need to do three things: set a timeout, add a failed rerun mechanism, record error logs, and capture exception objects if necessary.

During the automation implementation process, in addition to ensuring normal processes, abnormal scenarios must also be handled reasonably.

30. How to design test cases for interface testing?

Interface testing generally considers changes in input parameter forms and the business logic of the interface. Generally, equivalence classes, boundary values, and scenario methods are used to design interface test cases.

The idea of designing test cases for interface testing is as follows:

1. Normal use case, 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 is

2. Exception use cases are tests conducted to ensure the security of data and the correctness of program logic under abnormal circumstances.

Module interface testing 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 and database comparison

31. What are the ways to parameterize jmeter?

1) Configuration components---User-defined variable components can set global variables.

2) In the function assistant dialog box, you can select 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.

32. 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 restrictions on 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. Then an order with an original price of 100 yuan appears and we use 1 point. The money was paid.

2. For example, on a transfer page, the front-end has restrictions that 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 appears that the transfer amount is a negative number.