A weak network test method, device and medium of an application program

Abstract

The embodiment of the specification discloses a kind of weak network test method, device and medium of application program, it is related to weak network test technical field, for solving the problem that current test mode is not comprehensive and reliable.The method comprises the following steps: receiving the weak network test range information of application program by VPN proxy server;Wherein, weak network test range information includes: specified application information, specified network request information, weak network scene;Based on specified application information and specified network request information, the chain network request corresponding in application program is intercepted, and the network request data packet intercepted is obtained;Based on weak network scene, the multiple network environments corresponding to network request data packet are configured, to place network request data packet in each network environment in turn for simulation, obtain the test result corresponding to each network environment;By comparing the test results corresponding to the same network request, the target test result of application program is obtained.

Description

Technical Field

[0001] This specification relates to the field of application testing technology, and in particular to a method, device and medium for weak network testing of an application. Background Technology

[0002] With the rapid development of the mobile internet, mobile application development technology has matured significantly, resulting in a plethora of applications covering all aspects of daily life. However, with the widespread use of smart devices in various scenarios, users' network environments have become increasingly complex and variable. In daily life, users may face challenges in various network environments, such as elevators and underground parking garages where network signals are weak. These environments can significantly impact application stability and user experience. To ensure that applications function properly in various network environments, developers need to conduct weak network testing to simulate extreme network conditions and evaluate application performance.

[0003] Current weak network testing methods mostly focus on testing the overall performance of an application by setting up simulated environments. Developers typically assess the stability and response speed of network requests in weak network conditions by configuring the application's network environment to simulate low bandwidth, high latency, or packet loss. However, this approach primarily sets up the network environment for the entire application and cannot individually configure weak network environments for specific network requests. For current chained requests, upstream requests may be unaffected by network issues and function normally in a network environment, while downstream requests may face challenges in weak network conditions. Current holistic testing methods struggle to set different network environments for different stages of the chained request, easily leading to a lack of comprehensive test results. Summary of the Invention

[0004] To address the aforementioned technical problems, this specification provides one or more embodiments of a method, device, and medium for testing weak networks in applications.

[0005] One or more embodiments of this specification employ the following technical solutions:

[0006] This specification provides one or more embodiments of a method for testing a weak network connection in an application, the method comprising:

[0007] The weak network test range information of the application is received through a VPN proxy server; wherein, the weak network test range information includes: specified application information, specified network request information, and weak network scenario;

[0008] Based on the specified application information and the specified network request information, the corresponding chained network requests in the application are intercepted to obtain the intercepted network request data packets;

[0009] Based on the weak network scenario, configure multiple network environments corresponding to the network request data packet, so as to place the network request data packet in each of the network environments in sequence for simulation and obtain the test results corresponding to each of the network environments;

[0010] The target test result of the application is obtained by comparing the test results corresponding to the same network request.

[0011] Optionally, in one or more embodiments of this specification, based on the specified application information and the specified network request information, the corresponding chained network requests in the application are intercepted to obtain the intercepted network request data packets, specifically including:

[0012] Based on the specified application information, determine the target application for which network requests need to be intercepted;

[0013] Based on the specified network request information, the network request characteristics of the target application are determined; wherein, the network request characteristics include: request type, request keyword, and request path;

[0014] Based on the target application and the network request characteristics, match them with the chain of network requests forwarded by the VPN proxy server;

[0015] If the matching result is determined to be a match, the chained network requests are intercepted to obtain the intercepted network request data packets.

[0016] Optionally, in one or more embodiments of this specification, receiving the weak network test range information of the application through the VPN proxy server specifically includes:

[0017] Obtain user input information to determine whether the specified test information is available based on the user input information;

[0018] If so, then based on the specified type and specified format of the specified test information, obtain the corresponding specified data;

[0019] Determine the network interface corresponding to the specified data, and filter the specified data based on the historical records of the corresponding network interface in the current test period;

[0020] The specified application information, specified network request information and weak network scenario are matched based on the specified data after filtering, and the specified application information, specified network request information and weak network scenario are included in the weak network test scope;

[0021] If the specified test information is not available, then the application information of all applications, all network requests, and each weak network scenario are included in the weak network test scope.

[0022] Optionally, in one or more embodiments of this specification, determining the network interface corresponding to the specified data, and filtering the specified data based on the historical records of the corresponding network interface in the current test period, specifically includes:

[0023] Parse the specified network request information within the specified data, and match the parsed data with the network interface to determine the network interface corresponding to the specified data;

[0024] Retrieve the historical records corresponding to the network interface within the current testing period to determine the completed weak network test information of the network interface based on the historical records;

[0025] The specified data is filtered based on the completed weak network test information to obtain the filtered specified data.

[0026] Optionally, in one or more embodiments of this specification, receiving the weak network test range information of the application through the VPN proxy server specifically includes:

[0027] If the user input information is empty, then determine all applications corresponding to the VPN proxy server;

[0028] Based on the historical version testing bottlenecks and current version upgrade data of each application, obtain information on the weak network testing scope of the application;

[0029] Preferably, determining the weak network testing scope information of the application based on the historical version testing bottlenecks and current version upgrade data of each application specifically includes:

[0030] Determine whether there is historical test data for each application. If so, determine the historical version test bottleneck for each application based on the historical test data and historical test results corresponding to the current application.

[0031] The weak network test configuration information corresponding to the historical version test bottleneck is used as the first weak network test range information;

[0032] Obtain the network-related update data corresponding to the current version upgrade data, and determine the weak network test configuration information corresponding to the network-related update data as the second weak network test range information;

[0033] The first weak network test range information and the second weak network test range information are combined to obtain the weak network test range information of the application for user reference.

[0034] Optionally, in one or more embodiments of this specification, multiple network environments corresponding to the network request data packet are configured based on the weak network scenario, so that the network request data packet is sequentially placed in each of the network environments for simulation, and test results corresponding to each of the network environments are obtained, specifically including:

[0035] Obtain network environment configuration data corresponding to each of the aforementioned weak network scenarios, and configure the network environment according to the network environment configuration data to obtain multiple network environments corresponding to the network request data packet; wherein, the network environment configuration data includes: uplink and downlink latency, uplink and downlink latency jitter, uplink and downlink packet loss, uplink and downlink bandwidth limit, and specified network protocol;

[0036] The application and network environment corresponding to the network request data packet are determined, so that the test tasks of the network request data packet can be classified based on the application and the network environment respectively.

[0037] The network request data packets of various test tasks are sequentially placed in the corresponding network environments for transmission simulation in order to obtain the test results corresponding to each network environment.

[0038] Optionally, in one or more embodiments of this specification, obtaining the target test result of the application by comparing the test results corresponding to the same network request specifically includes:

[0039] Determine the test task type corresponding to the current test result, and determine the first test result of the same network request in different applications, and the second test result of the same network request in different weak network environments;

[0040] The first test results are compared pairwise, and the second test results are compared pairwise to determine the target test results of the application based on the comparison results, so as to determine the optimization strategy based on the target test results.

[0041] Optionally, in one or more embodiments of this specification, after configuring multiple network environments corresponding to the network request data packet based on the weak network scenario, the method further includes:

[0042] Obtain the request path corresponding to the network request data packet, and identify the test information of the network request data packet based on the request path; wherein, the test information includes: the interface under test and network protocol information;

[0043] The application process U ID corresponding to each network request data packet is obtained by reflection, so as to determine the application to which the network request data packet belongs based on the application process U ID;

[0044] Based on the test information, tests are conducted in multiple network environments to record the application to which the network request data packet belongs and the test data during the testing process of the network request data packet.

[0045] This specification provides one or more embodiments of a weak network testing device for an application, the device comprising:

[0046] At least one processor; and,

[0047] A memory communicatively connected to the at least one processor; wherein,

[0048] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described above.

[0049] This specification provides one or more embodiments of a non-volatile computer storage medium storing computer-executable instructions configured to perform any of the methods described above.

[0050] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

[0051] By specifying application information and network request information, the parts of the application that need to be tested for weak network conditions can be precisely located. The VPN proxy server automatically receives the test scope information, automatically intercepts chained network requests, automatically configures the network environment and performs simulated tests, and finally automatically compares the test results. The entire testing process is highly automated, improving testing efficiency. Furthermore, by intercepting and placing requests in the corresponding network environment through the VPN proxy server, it is possible to set appropriate weak network environments for different network requests from the application software, or to limit the testing to the application level, setting different network environments for different stages of a chained request, or setting network environments for the same network requests from multiple applications. This avoids the problem of traditional holistic testing methods, which can only set up the network environment for the entire application, resulting in incomplete test results. In addition, by comparing the test results of the same network request under different network environments, the performance and stability of the application under different network conditions can be more accurately evaluated, and potential problems can be identified. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0053] Figure 1 A flowchart illustrating a weak network testing method for an application provided in an embodiment of this specification;

[0054] Figure 2 A schematic diagram of the structure of a weak network testing device for an application provided in an embodiment of this specification;

[0055] Figure 3 This is a schematic diagram of the structure of a non-volatile storage medium provided in the embodiments of this specification. Detailed Implementation

[0056] This specification provides an embodiment of a method, device, and medium for testing weak networks in an application.

[0057] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0058] like Figure 1 As shown in the diagram, this specification provides a flowchart of a weak network testing method for an application. Figure 1 As can be seen, in one or more embodiments of this specification, a method for testing a weak network connection in an application includes the following process:

[0059] S101: Receive weak network test range information of the application through the VPN proxy server; wherein, the weak network test range information includes: specified application information, specified network request information, and weak network scenario.

[0060] Conducting weak network testing before software release allows for the early detection and resolution of network-related issues, preventing user churn or negative feedback due to problems after actual deployment. Therefore, to configure a weak network environment for specific network requests, relevant settings need to be preset before weak network testing. Thus, in this embodiment, a VPN proxy server can be used to receive the application's weak network testing scope information. It should be noted that the weak network testing scope information includes: specified application information, specified network request information, and weak network scenarios. Specifically, in one or more embodiments of this specification, receiving the application's weak network testing scope information through a VPN proxy server includes the following process:

[0061] First, user input is obtained to determine if specified test information is available. If so, the corresponding specified data is obtained based on the specified type and format of the test information. Then, the network interface corresponding to the specified data is determined, and the specified data is filtered based on the historical records of the corresponding network interface within the current test period. The filtered specified data is then matched with the corresponding specified application information, specified network request information, and weak network scenarios, and included in the weak network test scope. If no specified test information is available, the application information, all network requests, and each weak network scenario are obtained and included in the weak network test scope. This process allows for the acquisition of corresponding data based on the type and format of specific test information, facilitating timely interception of requests within the test scope. Furthermore, determining the network interface corresponding to the specified data and filtering it using historical records reduces unnecessary test data and improves testing efficiency. Even when the specified test information is unavailable, it can obtain all application information, network requests, and various weak network scenarios of the application, ensuring the comprehensiveness of the test and helping to discover potential problems of the application in different network environments, thereby improving the robustness and reliability of the application.

[0062] It's also important to note that the above process involves obtaining corresponding specified data based on the specified type and format of the test information. Specifically, the process can be as follows: For the specified type being "specified test application," the specified format can be to specify which applications need to undergo weak network testing by their package names. Multiple application configurations are supported, with selection and matching based on application package names. If no application is specified, all installed applications will be included in the weak network testing scope by default. For the specified type being "specified network request," one format is to match by specifying the network request path. For example, if the user enters the path "login / user / " in the configuration, all network requests containing this string in the path will be included in the weak network testing scope. Another format supports fuzzy or precise keyword matching for network requests. For example, if the user enters "login" as a keyword, all network requests containing the keyword "login" will be added to the weak network testing scope. Similarly, if no network request is specified, all network requests will be included in the weak network testing scope by default.

[0063] Furthermore, in one or more embodiments of this specification, the step of determining the network interface corresponding to the specified data in order to filter the specified data based on the historical records of the corresponding network interface in the current test period specifically includes the following process:

[0064] First, the specified network request information within the specified data is parsed, and then matched with the network interface to determine the corresponding network interface. Next, the historical records of the network interface within the current test period are retrieved to determine the completed weak network test information of the network interface. This information is then used to filter the specified data, obtaining the filtered data. This process, by parsing the specified network request information within the specified data and matching it with the network interface, accurately determines the network interface corresponding to the specified data. This matching helps to identify the test stages already performed by each subsequent network interface. Furthermore, retrieving the historical records of the network interface within the current test period fully utilizes existing test data and information, avoiding redundant testing and improving testing efficiency.

[0065] In another feasible embodiment of this specification, receiving the weak network test range information of the application through a VPN proxy server can also be achieved through the following process:

[0066] If the user input is empty, meaning the user did not select a specific test application or network request, all applications corresponding to the VPN proxy server will be identified. Then, based on the historical version test bottlenecks and current version upgrade data of each application, the weak network test range information of the application will be obtained. Preferably, determining the weak network test range information of the application based on the historical version test bottlenecks and current version upgrade data of each application specifically includes the following process:

[0067] First, determine if historical test data exists for each application. If so, determine the historical version testing bottlenecks for each application based on the historical test data and results. Then, use the weak network testing configuration information corresponding to the historical version testing bottleneck as the first weak network testing scope information. Simultaneously, obtain the network-related update data corresponding to the current version upgrade data to determine the weak network testing configuration information corresponding to the network-related update data, as the second weak network testing scope information. Summarize the first and second weak network testing scope information to obtain the application's weak network testing scope information for user reference. In the above process, when the user does not specify a test application or network request, analyzing historical test data and current version upgrade data allows for intelligent determination of the weak network testing scope, helping to improve the targeting and efficiency of testing. Specifically, by considering historical version testing bottlenecks and current version upgrade data, it ensures that the testing scope includes both previously discovered issues and new issues that may be introduced in the new version. This comprehensive testing coverage helps to discover potential network problems and improve the stability and reliability of the application. This process allows for dynamic adjustment of testing strategies based on user actions. When the user specifies a test application or network request, testing can be performed on these specific targets; when the user does not specify, all applications are tested automatically.

[0068] S102: Based on the specified application information and the specified network request information, intercept the corresponding chain of network requests in the application to obtain the intercepted network request data packets.

[0069] Chained requests request different interfaces at different stages. Therefore, in order to set up corresponding weak network environments for specific interfaces, and thus achieve the purpose of weak network testing for chained requests by setting different network environments for different stages of the chained request, the embodiments in this specification will intercept the corresponding chained network requests in the application based on specified application information and specified network request information, thereby obtaining the intercepted network request data packets that are within the scope of weak network testing and need to be tested.

[0070] Specifically, in one or more embodiments of this specification, based on specified application information and specified network request information, the corresponding chained network requests in the application are intercepted to obtain the intercepted network request data packets, specifically including the following process:

[0071] First, the target application whose network requests need to be intercepted is determined based on specified application information. Then, the network request characteristics of the target application are determined according to the specified network request information. These characteristics include request type, request keywords, and request path. Next, the target application and its network request characteristics are matched against a chain of network requests forwarded by the VPN proxy server. If a match is found, the chain of network requests is intercepted to obtain the intercepted network request data packets. It's important to note that when a network request is sent, the proxy server obtains the request headers and body. When the request is forwarded to the server, and the server responds, the proxy server obtains the corresponding response information, including the response headers and body. The request headers, body, and response headers and body obtained by the VPN proxy server together constitute the network packet information for this network request. By matching the target application and its network request characteristics against the chain of network requests forwarded by the VPN proxy server, the VPN proxy server intercepts network requests sent from the application to the target server, facilitating subsequent weak network testing of the intercepted network request database.

[0072] The network request packets intercepted during this process can be redirected to a specific weak network test environment to simulate different network conditions. By using a VPN proxy server to intercept and redirect network requests, the test conditions can be precisely controlled and the test can be repeated. Furthermore, by intercepting and capturing data, the problem that current overall testing methods cannot set different network environments for different stages of chained requests is solved.

[0073] S103: Based on the weak network scenario, configure multiple network environments corresponding to the network request data packet, so as to place the network request data packet in each of the network environments in sequence for simulation, and obtain the test results corresponding to each of the network environments.

[0074] After intercepting network request data packets based on step S102 above, this embodiment of the specification, in order to promptly identify potential problems and bottlenecks in the application under poor network conditions, configures multiple network environments corresponding to the network request data packets according to the weak network scenario. This allows the network request data to be simulated in various network environments at once, thereby obtaining test results corresponding to each network environment. In other words, by testing network request data packets under different network environments, the strengths and weaknesses of the application in network request processing can be analyzed. Furthermore, by collecting and analyzing the test results under different network environments, data support can be provided for application optimization decisions.

[0075] Specifically, in one or more embodiments of this specification, multiple network environments corresponding to network request packets are configured based on weak network scenarios, so as to place the network request packets in each network environment sequentially for simulation and obtain the test results corresponding to each network environment. The specific process includes the following:

[0076] First, network environment configuration data corresponding to each weak network scenario is obtained. Based on this data, the network environment is configured to obtain multiple network environments corresponding to the network request data packets. It should be noted that the network environment configuration data may include: uplink / downlink latency, uplink / downlink latency jitter, uplink / downlink packet loss, uplink / downlink bandwidth limits, and specified network protocols. Next, the application and network environment corresponding to the network request data packets are determined, and test tasks for the network request data packets are categorized based on both the application and the network environment. Then, the network request data packets for each type of test task are sequentially placed in their corresponding network environments for transmission simulation to obtain test results for each network environment. For example, when a device sends a request, the proxy server can intercept the network data packets and place them in a latency queue to simulate uplink latency. Specifically, the proxy server adjusts parameters such as uplink / downlink latency, packet loss, and bandwidth limits according to the preset weak network scenario configuration to simulate different network environments. The proxy server also records detailed information about network packets, including: the complete request path, protocol type (such as HTTP / HTTPS, TCP, UDP, ICMP, etc.), status information (such as request success / failure), the name of the application and packet name to which the network packet belongs, and the time and size of the request and response. This process allows for the categorization of test tasks based on the application and network environment corresponding to the network request packets. This means that targeted tests can be performed for different types of applications and network environments, ensuring the comprehensiveness and accuracy of the tests. It also facilitates subsequent analysis of test results for different applications or under different weak network conditions, enabling performance analysis of the application.

[0077] Furthermore, in one or more embodiments of this specification, after configuring multiple network environments corresponding to network request packets based on weak network scenarios, the method further includes the following process:

[0078] First, the request path corresponding to the network request data packet is obtained, and the test information of the network request data packet is identified based on the request path. This test information includes: the interface under test and network protocol information. Furthermore, the application process UID corresponding to each network request data packet can be obtained through reflection, allowing the application to which the network request data packet belongs to be determined based on the application process UID. Then, tests are performed in multiple network environments based on the test information to record the application to which the network request data packet belongs and the test data during the network request data packet testing process. In other words, during weak network testing, the proxy server records detailed network packet information for each network request, specifically including the following:

[0079] Request path and protocol type: By recording the complete path of each network request, it helps identify which interface is being tested and the network protocol used. Application information: By using reflection to obtain the UID of the application process to which each network request belongs, and then using the UID to retrieve the application's name, package name, and application icon information, this accurately identifies the application to which each request belongs. Request and response time: By recording the time of each request and response, it helps assess latency and response speed in weak network environments. Request and response size: By recording the size of requests and responses, it helps assess transmission efficiency in weak network environments.

[0080] S104: Obtain the target test result of the application by comparing the test results corresponding to the same network request.

[0081] The weak network test results obtained based on step S103 include configuration information for the weak network scenario and detailed information for each network packet. Therefore, in order to fully understand the application's performance under various network conditions and optimize the application based on the test results, this embodiment compares the test results corresponding to the same network request to obtain the target test results for the application.

[0082] Specifically, in one or more embodiments of this specification, the target test result of the application is obtained by comparing the test results corresponding to the same network request, which specifically includes the following process:

[0083] First, the test task type corresponding to the current test result is determined, thereby identifying the first test result of the same network request in different applications and the second test result of the same network request in different weak network environments. Then, the first test results are compared pairwise, and the second test results are compared pairwise again to determine the target test result for the application, allowing for the determination of optimization strategies based on the target test result. In other words, the embodiments in this specification can compare the weak network test results of the same network request in different applications to obtain the performance differences of the same network interface in different applications, thereby evaluating the application's adaptability and processing capabilities in weak network environments. Simultaneously, the test results of the same network request in different weak network scenarios can be compared to understand the impact of different network environments on network requests. For example, elevator scenarios may have a greater impact on bandwidth limitations, while underground parking garages may be more sensitive to latency and packet loss, thus obtaining the performance differences of the same network interface in different weak network environments. This comparative information from these two types of test results allows developers to comprehensively understand the application's performance under various network conditions and optimize the application based on the test results. For example, for high latency or packet loss, the request retry mechanism can be optimized or a caching strategy can be added. For bandwidth limitations, data compression or optimization of data transmission formats can be considered.

[0084] like Figure 2 As shown in the diagram, this specification provides a schematic diagram of the structure of a weak network testing device for an application. Figure 2 As can be seen, in one or more embodiments of this specification, a weak network testing device for an application includes:

[0085] At least one processor; and,

[0086] A memory communicatively connected to the at least one processor; wherein,

[0087] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described above.

[0088] like Figure 3 As shown in the diagram, this specification provides a schematic diagram of the structure of a non-volatile storage medium in an embodiment. Figure 3 As can be seen, in one or more embodiments of this specification, a non-volatile storage medium stores computer-executable instructions, which are capable of executing any of the methods described above.

[0089] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0090] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0091] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for testing a weak network connection in an application, characterized in that, The method includes: The application's weak network test range information is received through a VPN proxy server; wherein, the weak network test range information includes: specified application information, specified network request information, and weak network scenario; Based on the specified application information and the specified network request information, the corresponding chained network requests in the application are intercepted to obtain the intercepted network request data packets; Based on the weak network scenario, configure multiple network environments corresponding to the network request data packet, so as to place the network request data packet in each of the network environments in sequence for simulation and obtain the test results corresponding to each of the network environments; The target test result of the application is obtained by comparing the test results corresponding to the same network request. The process of receiving weak network test range information from the application via a VPN proxy server specifically includes: If the user input information is empty, then determine all applications corresponding to the VPN proxy server; Based on the historical version testing bottlenecks and current version upgrade data of each application, obtain information on the weak network testing scope of the application; The process of obtaining weak network testing scope information for applications based on historical version testing bottlenecks and current version upgrade data specifically includes: Determine whether there is historical test data for each application. If so, determine the historical version test bottleneck for each application based on the historical test data and historical test results corresponding to the current application. The weak network test configuration information corresponding to the historical version test bottleneck is used as the first weak network test range information; Obtain the network-related update data corresponding to the current version upgrade data, and determine the weak network test configuration information corresponding to the network-related update data as the second weak network test range information; The first weak network test range information and the second weak network test range information are combined to obtain the weak network test range information of the application for user reference.

2. The weak network testing method for an application according to claim 1, characterized in that, Based on the specified application information and the specified network request information, the corresponding chained network requests in the application are intercepted to obtain the intercepted network request data packets, specifically including: Based on the specified application information, determine the target application for which network requests need to be intercepted; Based on the specified network request information, the network request characteristics of the target application are determined; wherein, the network request characteristics include: request type, request keyword, and request path; Based on the target application and the network request characteristics, match them with the chain of network requests forwarded by the VPN proxy server; If the matching result is determined to be a match, the chained network requests are intercepted to obtain the intercepted network request data packets.

3. The method for weak network testing of an application according to claim 1, characterized in that, The process of receiving weak network test range information from the application via a VPN proxy server specifically includes: Obtain user input information to determine whether the specified test information is available based on the user input information; If so, then based on the specified type and specified format of the specified test information, obtain the corresponding specified data; Determine the network interface corresponding to the specified data, and filter the specified data based on the historical records of the corresponding network interface in the current test period; The specified application information, specified network request information and weak network scenario are matched with the specified data after filtering, and the specified application information, specified network request information and weak network scenario are included in the weak network test scope; If the specified test information is not available, then the application information of all applications, all network requests, and each weak network scenario are included in the weak network test scope.

4. The weak network testing method for an application according to claim 3, characterized in that, Determine the network interface corresponding to the specified data, and filter the specified data based on the historical records of the corresponding network interface within the current test period, specifically including: Parse the specified network request information within the specified data, and match the parsed data with the network interface to determine the network interface corresponding to the specified data; Retrieve the historical records corresponding to the network interface within the current testing period to determine the completed weak network test information of the network interface based on the historical records; The specified data is filtered based on the completed weak network test information to obtain the filtered specified data.

5. The weak network testing method for an application according to claim 1, characterized in that, Based on the weak network scenario, configure multiple network environments corresponding to the network request data packets, and sequentially place the network request data packets in each of the network environments for simulation to obtain test results corresponding to each network environment, specifically including: Obtain network environment configuration data corresponding to each of the aforementioned weak network scenarios, and configure the network environment according to the network environment configuration data to obtain multiple network environments corresponding to the network request data packet; wherein, the network environment configuration data includes: uplink and downlink latency, uplink and downlink latency jitter, uplink and downlink packet loss, uplink and downlink bandwidth limits, and specified network protocols; The application and network environment corresponding to the network request data packet are determined, so that the test tasks of the network request data packet are classified based on the application and the network environment respectively; The network request data packets of various test tasks are sequentially placed in the corresponding network environments for transmission simulation in order to obtain the test results corresponding to each network environment.

6. The weak network testing method for an application according to claim 5, characterized in that, The step of obtaining the target test result of the application by comparing the test results corresponding to the same network request specifically includes: Determine the test task type corresponding to the current test result, and determine the first test result of the same network request in different applications, and the second test result of the same network request in different weak network environments; The first test results are compared pairwise, and the second test results are compared pairwise to determine the target test results of the application based on the comparison results, so as to determine the optimization strategy based on the target test results.

7. The weak network testing method for an application according to claim 1, characterized in that, After configuring multiple network environments corresponding to the network request data packet based on the weak network scenario, the method further includes: Obtain the request path corresponding to the network request data packet, and identify the test information of the network request data packet based on the request path; wherein, the test information includes: the interface under test and the network protocol information; The application process UID corresponding to each network request data packet is obtained by reflection, so as to determine the application to which the network request data packet belongs based on the application process UID; Based on the test information, tests are conducted in multiple network environments to record the application to which the network request data packet belongs and the test data during the testing process of the network request data packet.

8. A weak network testing device for an application, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in any one of claims 1-7.

9. A non-volatile storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are capable of performing the method described in any one of claims 1-7.

Images