Use the F12 Debugger in the browser to locate system front-end bugs

The testing partner may have used packet capture (packet capture) tools such as httpwatch, firebug, Fiddler, and Charles, but in fact there is also a simple and practical packet capture tool, that is the F12 debugger of the browser.

Httpwatch and firebug are plug-ins of the browser. They need to be downloaded separately. fiddler and Charles also need to download the installation package separately. However, the F12 debugger of the browser is a built-in debugger of all browsers, you don't need to install it. Opening it is just a good task, and it provides powerful functions. Therefore, if you are developing or testing a web system, we can first consider using this debugger to capture packets to debug the system or use it to help locate bugs in the system.

Below I have prepared several small cases to illustrate the usage of this tool and its convenience.

Not to mention nonsense. Let's first take a look at its lineup. Take Firefox as an example. Open the browser and press F12 to open the debugger, for example:

Note: For different browsers, the debugger may be slightly different in the UI, but the basic skills are similar. After mastering the usage of a browser debugger, others are also easy to use. Below we use a few small cases to illustrate the scenarios in which our testers can apply the debugger in system testing.

Scenario: how to analyze whether a bug comes from the front-end or backend When testing a web system.

First, let's take a look at the reasons for finding a bug on the website and analyzing whether it is a front-end bug or a back-end BUG:

1. in some companies, a system may be developed by both the front-end team and the back-end team. Therefore, when allocating bugs, bugs in different modules are generally assigned to the corresponding responsible team or individuals.

2. when proposing a bug, if you can provide valuable information to developers as much as possible to narrow down the positioning scope, or even if you can help locate the bug directly, developers can fix bugs more easily, thus reducing communication costs between testing and development and improving work efficiency.

3. The improvement of bugs can also reflect the high technical expertise of testers, rather than just a little bit. The personal image will also be rapidly improved in the project team. Others will think of you as a big guy, and they will look at your expression.

 

When we analyze whether a system bug comes from the front-end or back-end, the two most useful ones are the two tabs provided by the debugger, both of which record some data,One is the console and the other is the network..

 Console: Records the execution of the front-end JS and all the HTTP request information sent from the front-end to the server. If any JS error occurs, you can see it in the console, if an HTTP request sent to the background does not receive a normal response from the server, its status information can also be seen.

Network: Records all the HTTP request information sent from the front-end to the server. what data is sent for each request? Does the server normally respond to the request, what is the status code returned from the response, and what is the response data can be seen under the "network" tab.

 

After talking about this, how can we use it.

The first small case:

1) Access: http: // 39.108.136.60: 8380/ningmengban/APP/login/login.html

2) enter the Logon account (User Name/password): [email protected]/123456

3) Click Log On without any reflection (no prompt or jump)

From the page interaction view, enter the account, click Login, or log on to the system to jump to other pages of the system, or give an error message for Logon failure, but no response is returned now. This must be a bug, however, whether the bug is a front-end bug or a backend is unknown, but we can easily open the browser debugger to analyze and locate it.

Open the console and we can see that the console has a JS error, which is login. the JS script reports an error during execution. login indicates logon. Therefore, we subconsciously think that this JS script is a JS script that defines the login front-end logic, clicking the "Log on" button does not reflect any response. This bug is probably caused by an error in front-end JS execution. Cut a picture and write your own analysis.

 

To further verify your conjecture, you can also look at the "network" tab:

Conclusion: After analysis, an error is reported during the execution of the front-end login script, causing the front-end to not initiate a call to the backend login interface. No prompt is displayed when you click the login button on the page. This bug is a front-end bug. When we mention the bug, we include the two above, which contain our analysis.

 

 

Second case:

1) Access: http: // 39.108.136.60: 8380/ningmengban/APP/login/login.html

2) enter the Logon account (User Name/password): [email protected]/123456

3) Click Log On without any reflection (no prompt or jump)

From the page interaction view, enter the account, click Login, or log on to the system to jump to other pages of the system, or give an error message for Logon failure, but no response is returned now. This must be a bug, however, whether the bug is a front-end bug or a backend is unknown, but we can easily open the browser debugger to analyze and locate it.

Open the console and we can see that there is no JS error in the console, but a request is sent to the background. At this time, the problem still cannot be effectively located at the front-end or back-end, but we can cut a picture, write your own test process:

To further locate the problem, you can open the "network" tab:

Conclusion: The 404 Not found Request Path cannot be found. It may be because the frontend and backend developers have changed the interface address, or the interface address is incorrect when the frontend JS initiates a login request, therefore, this bug can be raised to the front-end developer or the backend developer. As long as the above analysis is provided, developers can modify this bug in seconds.

 

The third small case:

1) Access: http: // 39.108.136.60: 8380/ningmengban/APP/login/login.html

2) enter the Logon account (User Name/password): [email protected]/123456

3) Click Log On without any reflection (no prompt or jump)

From the page interaction view, enter the account, click Login, or log on to the system to jump to other pages of the system, or give an error message for Logon failure, but no response is returned now. This must be a bug, however, whether the bug is a front-end bug or a backend is unknown, but we can easily open the browser debugger to analyze and locate it.

Open the console and we can see that there is no JS error in the console, but a request is sent to the background. At this time, the problem still cannot be effectively located at the frontend or backend, however, you can cut a picture and write your own test process:

Continue to open the "network" tab. We can see that there is a 500 request under it. Based on the keyword eye login in the request, we conclude that this is the logon interface, and 500 indicates that it is an internal exception on the backend server, this error is generally caused by an error reported during code execution in the background. Therefore, write down our analysis and add the following to the bug:

 

Conclusion: Based on the status code 500 returned by the request, we can conclude that this bug is caused by an error when the background code is executed. The above information is provided for the bug, the developer knows to check the code of the logon interface. Therefore, the problem locating scope is reduced, ensuring that the developer can fix the bug quickly.

 

Okay. I have demonstrated three small cases to show you how to locate the bug from the front-end or back-end by using the browser debugger when encountering a bug, of course, I suggest you pay more attention to the response status codes of HTTP requests. For common HTTP codes, such as 200, 302, 404, and 500, it is best to understand them, by combining our tools, we are more confident and confident in locating and analyzing problems.

Gadgets, but they are very practical. Do you get this skill. I hope that you can apply it in your work. If you use more, you will naturally become proficient.

Use the F12 Debugger in the browser to locate system front-end bugs