Introduction and basic use of Fiddler tools

1. Basic introduction to Fiddler

1 Introduction

        Fiddler is an http protocol debugging proxy tool, which can record and check all http communication between your computer and the Internet, set power off, and view all data "in and out" of Fiddler (referring to cookies, html, js, css and other files )

2. Application scenario of packet capture

• Use the packet capture tool to intercept and observe the request information of the website, and gain a deeper understanding of the website
• By using the packet capture tool to intercept and observe the request and response information of the website, it helps us locate and describe bugs
• Use the packet capture tool to intercept and modify the request information, bypass the interface restrictions, and test the function of the server

3. Download and install

Official website: https://www.telerik.com/download/fiddler

Installation: After downloading, click on the installation package, check the agreement all the way to default (the installation location can be changed by yourself)

Notice:

If such a result occurs

You need to install .net framework

Official installation address: https://dotnet.microsoft.com/en-us/download/dotnet-framework

2. Basic operation

1. Crawl request

2. Delete request

3. Filter requests

3. Common functions

1. Auxiliary positioning bug

Operating procedures:

1. Capture web pages and mobile APPs
2. Check whether the interface address is correct
3. Check response status for exceptions
4. Check the interface passing parameters
5. Check interface return data

2. Build a simulation test scenario

(1) Simulate sending requests and conduct interface tests

Application Scenario 1: It is stated in the requirements document that a certain interface restricts the same account to only request once, and the same device can only request once

Application scenario 2: There are page input restrictions, and it is necessary to simulate special situation requests (such as parameters such as special characters and spaces), and test the program processing mechanism

Operating procedures:

1. Set request method, request address, protocol
2. set request header
3. set request body
4. send request
5. view response

(2) Mock interface returns data, test program

Application scenario 1: It is necessary to verify whether the interface data can be processed normally, but the program is in the development process, and the background cannot respond to the sending request

Application scenario 2: It is necessary to verify the processing mechanism of the program for different states such as 404, 500, 502, etc.

3. Simulate weak network test

Application scenarios: Daily access to subways, buses, elevators, etc. If the app does not handle various network exceptions in a compatible manner, users may encounter problems such as app crashes, ANR, and data loss in their daily lives.

Operating procedures:

1. Turn on the speed limit switch
2. Set weak network environment
3. Use the app for operation verification

Set the speed limit: find the following code in the speed limit rule, change the number to realize the speed limit setting

if (m_SimulateModem) {
   // Delay sends by 300ms per KB uploaded.
   oSession["request-trickle-delay"] = "300";    # 发送请求速度
   // Delay receives by 150ms per KB downloaded.
   oSession["response-trickle-delay"] = "150";    # 接收响应速度
}

4. Front-end performance analysis and optimization

• A green request indicates that this is a "conditional request", and the request containing the conditional request header is displayed in green, otherwise it is displayed in black
• The hatched requests are the requests in the buffer mode, and the solid ones are the requests in the streaming mode
• Different colors of the request bar correspond to responses of different element types, which are classified according to the MIME Type of the response header. For example, light green indicates the response of image type; dark green is JavaScript; purple is CSS; others are blue
• The black vertical line indicates the moment when the browser receives the first byte of the server response
• Icons following the request bar indicate certain characteristics of the response. The floppy disk icon indicates that the response text is obtained locally; the lightning indicates that this is the response of Fiddler's "AutoResponder"; the downward arrow indicates that the response is 302; the red exclamation mark indicates that an error occurred in this request
• The red circle in front of the request indicates that the connection is newly created, and the green one indicates that it is reused

5. Modify request data