To put it bluntly, every operation of the UI during daily functional testing is a call to one or more interfaces. The content returned by the interface (usually json on the mobile terminal) is processed by the front-end code and finally displayed on the page. The http interface is the layer interface closest to us. The data displayed on the web and mobile terminals comes from this layer. So how do we know which interfaces are triggered by each click on the successfully tested UI? Please find the answer in the scenario below.
The following scenario:
You are responsible for testing the order list function of a user on an e-commerce website. During the test process, you find that the number of orders displayed on the page is inconsistent with the number in the actual database. Please combine your usual working methods to recall how to quickly Locate whether the problem is a BUG or what is the cause of the BUG.
Here’s what I think is a more appropriate positioning method:
1. Use the Chrome browser to open the project you are testing, open the developer tools with F12, switch to the network tab, and visit the order list page, as shown below
After grabbing the interface that displays the order list, it can be seen that a total of 9 parameters were passed in this request. At this time, open the interface document provided by RD to confirm whether the parameters that need to be passed are passed correctly, or the number of parameters is consistent. If it is incorrect, , it can be judged to be a front-end bug.
Someone said what to do if there is no interface document? If you can understand the code, you can go directly to the definition or implementation of this interface. If you can't understand it, you can only ask the back-end developer to confirm it.
2. Click the Response label to copy the content in the label, and ask for a better view. Paste it into the tool for formatting json (if the return type is json) tool address: http://json.parser.online.fr/, and then check whether the number of records displayed here is consistent with that displayed on the UI. If there is any inconsistency, it can be judged to be a front-end bug.
3. If there is no problem in the previous step, please open the debug log of the system. To put it bluntly, the operation of obtaining the order finally falls to the database level, which is a conditional select query statement. We can obtain it from the log. The parameters of the select statement. This parameter is usually the 9 parameters passed when calling the interface. At this time, the sql statement generated by this interface call is captured and then executed on the database client to analyze the query conditions and execution results. Relationship, this process is the process of finding wrong parameters. Similar debug logs are as follows:
From the screenshots, we can see that there are some select statements such as: select * from model where id = ?
Summary: When you encounter problems during the testing process, don’t rush to call development. Make a preliminary judgment first, or directly Locating the cause of the bug can not only reduce some unnecessary communication, but also allow developers to go straight to the cause of the bug and improve the speed of problem solving.
2023 latest Jmeter interface testing from entry to proficiency (full set of project practical tutorials)