Test methods, systems, apparatuses, and electronic devices

Abstract

The application discloses a test method, system, device and electronic equipment. The method comprises the following steps: receiving a first request message initiated by a test device in a test process; comparing the first request message with a request interception rule to obtain a comparison result; converting the first request message into a second request message based on a request processing strategy in the case that the comparison result indicates that the first request message meets a matching condition; receiving response data corresponding to the second request message returned by a server, and determining a test result of the test device based on the response data. The application solves the technical problem that the automatic test method in the related art needs to modify the code of a system under test to simulate multiple test scenarios, which results in low test efficiency and invasiveness to the system under test.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and more specifically, to a testing method, system, apparatus, and electronic device. Background Technology

[0002] In the current field of software automation testing, if different test scenarios need to be simulated during the testing process, the code of the system under test must be manually modified or the server-side data must be modified. This is not only inefficient, but also highly intrusive to the system under test, increasing the complexity of environment setup. Furthermore, service changes may introduce non-test-related interference factors, reducing the reliability and repeatability of test results.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a testing method, system, apparatus, and electronic device to at least solve the technical problem that the automated testing methods used in related technologies require modification of the code of the system under test to simulate various test scenarios, resulting in low testing efficiency and intrusiveness to the system under test.

[0005] According to one aspect of the embodiments of this application, a testing method is provided, comprising: receiving a first request message initiated by a testing device during a test, wherein the first request message is used to communicate with a server to obtain test response data; comparing the first request message with a request interception rule to obtain a comparison result, wherein the request interception rule is used to describe the matching conditions of the request to be intercepted and the request processing strategy; if the comparison result indicates that the first request message meets the matching conditions, converting the first request message into a second request message based on the request processing strategy, wherein the second request message is used to simulate different test scenarios of the first request message; receiving response data returned by the server corresponding to the second request message, and determining the test result of the testing device based on the response data.

[0006] In some embodiments of this application, converting a first request message into a second request message based on a request processing strategy includes: modifying corresponding fields of the first request message based on the request processing strategy when the request processing strategy indicates that the first request message should be modified, to obtain a second request message; or, updating the forwarding behavior of the first request message based on the request processing strategy when the request processing strategy indicates that the first request message should be flow-controlled, to obtain a second request message; or, setting an identifier for the first request message when the request processing strategy indicates that the first request message should be marked, to obtain a second request message, wherein the identifier is used to characterize the test behavior semantics carried by the first request message during the test; or, updating the state of the first request message in the test lifecycle based on the matching result of the first request message and the request interception rule when the request processing strategy indicates that the first request message should be state-managed, to obtain a second request message.

[0007] In some embodiments of this application, determining the test result of the test device based on response data includes: obtaining a response processing strategy from a request interception rule that matches the first request message, wherein the response processing strategy is used to define the processing logic to be executed after receiving the response data; processing the response data based on the response processing strategy to obtain target response data; and determining the test result based on the target response data.

[0008] In some embodiments of this application, processing response data based on a response processing strategy to obtain target response data includes: modifying the fields corresponding to the response data based on the response processing strategy when the response processing strategy indicates that the response data should be modified, to obtain target response data; or, updating the forwarding behavior of the response data when the response processing strategy indicates that the response data should be subject to flow control, to obtain target response data.

[0009] In some embodiments of this application, determining the test result based on the target response data includes: extracting target data corresponding to the target field from the target response data; performing an assertion verification operation on the target data to obtain a verification result, wherein the assertion rule corresponding to the assertion verification operation is determined based on the request interception rule that matches the first request message; and determining the test result based on the verification result.

[0010] In some embodiments of this application, the first request message includes a structured request context object; comparing the first request message with request interception rules to obtain a comparison result includes: obtaining the matching condition corresponding to each request interception rule, wherein the matching condition includes at least one of the following: request protocol, request domain name, request port, request path, and request parameters; comparing the matching condition with the fields in the request context object to obtain a comparison result.

[0011] In some embodiments of this application, if the comparison result indicates that any field of the request context object does not meet the matching condition, the first request message remains unchanged and is sent to the server according to a preset forwarding strategy.

[0012] According to another aspect of the embodiments of this application, a testing system is also provided, including: a testing device, multiple proxy modules, and a server, wherein the testing device is connected to the proxy modules and is used to send a first request message to the proxy modules during the testing process, wherein the first request message is used to communicate with the server to obtain test response data; the multiple proxy modules are respectively connected to the testing device and the server, and are used to compare the first request message with request interception rules, and if the first request message meets the request interception rules, convert the first request message into a second request message based on a request processing strategy, wherein the request interception rules are used to describe the matching conditions of the request to be intercepted and the request processing strategy, and the second request message is used to simulate various different business scenarios; the server is connected to the proxy modules and is used to receive the second request message and return response data to the proxy modules, wherein the response data is used to determine the test result of the testing device.

[0013] In some embodiments of this application, each proxy module is used to receive request and response messages corresponding to a test device, and each proxy module runs in an independent execution thread.

[0014] According to another aspect of the embodiments of this application, a testing apparatus is also provided, comprising: a receiving module, configured to receive a first request message initiated by a testing device during a test, wherein the first request message is used to communicate with a server to obtain test response data; a comparison module, configured to compare the first request message with request interception rules to obtain a comparison result, wherein the request interception rules are used to describe the matching conditions of the request to be intercepted and the request processing strategy; a conversion module, configured to convert the first request message into a second request message based on the request processing strategy when the comparison result indicates that the first request message meets the matching conditions, wherein the second request message is used to simulate different test scenarios of the first request message; and a determining module, configured to receive response data returned by the server corresponding to the second request message, and determine the test result of the testing device based on the response data.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, wherein the memory is used to store program instructions; and the processor is connected to the memory and used to execute the above-described test method.

[0016] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-described test method by running the computer program.

[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the above-described test method.

[0018] In this embodiment, a dynamic network proxy interception and intelligent response simulation method is adopted. By capturing the original request messages initiated during the test in real time and dynamically identifying the target request based on the preset fine-grained matching rules, the request is transformed according to the preset processing strategy. This achieves the goal of flexibly constructing multiple test scenarios without modifying the code of the system under test. This realizes the technical effects of complete decoupling between the test logic and the system under test, programmable control of test data, and rapid switching between multiple scenarios. This solves the technical problem that the automated testing methods used in related technologies require modification of the code of the system under test to simulate multiple test scenarios, resulting in low testing efficiency and intrusiveness to the system under test. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 This is a hardware structure block diagram of a computer terminal according to a testing method of an embodiment of this application;

[0021] Figure 2 This is a flowchart of a testing method according to an embodiment of this application;

[0022] Figure 3 This is a timing diagram a of a test method according to an embodiment of this application;

[0023] Figure 4 This is a timing diagram b of a test method according to an embodiment of this application;

[0024] Figure 5 This is an architecture block diagram of a test system according to an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of the architecture of a test system according to an embodiment of this application;

[0026] Figure 7 This is a schematic diagram of a testing device according to an embodiment of this application. Detailed Implementation

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

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0030] Dynamic Network Proxy (DNP): A software proxy system that acts as an intermediary layer in network communication links, capable of intercepting, modifying, or forwarding HTTP / HTTPS requests and responses in real time. Its key feature is support for dynamic rule configuration at runtime without requiring service restarts. In this embodiment, the dynamic network proxy is deployed between the test device and the backend service to non-intrusively capture all network requests from the terminal application and dynamically modify request parameters and simulate server responses based on rules injected into the test script.

[0031] Request Interception Rule (RIR): A structured configuration that defines a set of conditions for matching a specific network request and its corresponding processing behavior, including but not limited to matching dimensions such as request protocol, domain name, path, query parameters, request method, and request headers, as well as processing strategies such as request modification, response simulation, delayed injection, and assertion verification.

[0032] Request Context Object: A data carrier that encapsulates each network request in a structured manner within the proxy system. It contains complete information such as request method, URL, request headers, request body, timestamp, and source device, and is used for unified calls by the rule matching, parameter extraction, and response processing modules.

[0033] In the current software system development process, automated testing technology has been widely adopted to improve testing efficiency, coverage and reliability. In application scenarios with frequent network communication, traditional automated testing tools are often unable to flexibly intercept, modify or analyze HTTP request responses. In particular, in OTT or mobile terminal testing, there is a lack of flexible and configurable traffic control tools. Although traditional packet capture tools have certain proxy and viewing functions, they are not easy to integrate with automated scripts and lack programmability, which limits the flexible implementation of test logic.

[0034] Therefore, this application aims to solve the following technical problems faced in automated testing, especially in complex distributed environments such as mobile devices, OTT platforms, and smart terminals:

[0035] (1) Traditional proxy tools cannot dynamically configure proxy behavior in test scripts, and lack programmability and automated control capabilities;

[0036] (2) UI automated testing needs to ensure the consistency of data to avoid test failures caused by inconsistent interface data during test case development and test case testing.

[0037] (3) The testing process cannot directly extract and assert key request parameters and response content, resulting in redundant verification logic and low efficiency;

[0038] (4) Existing proxy tools are highly coupled with the testing process, which is not conducive to automated deployment and execution in continuous integration (CI / CD) scenarios;

[0039] (5) There is a lack of a unified proxy rule management and execution mechanism, which makes it difficult to adapt to the testing needs of multiple interfaces, multiple projects and multiple scenarios.

[0040] To address the aforementioned technical problems, this application provides corresponding solutions, which are detailed below.

[0041] The test method embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing a testing method is shown. Figure 1As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0042] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0043] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the test method in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned test method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0044] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0045] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0046] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0047] In the above operating environment, this application provides a test method embodiment. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0048] Figure 2 This is a flowchart of a testing method according to an embodiment of this application, the execution entity of which is a proxy module (also known as a dynamic proxy), such as... Figure 2 As shown, the method includes the following steps:

[0049] Step S202: Receive a first request message initiated by the test device during the test process, wherein the first request message is used to communicate with the server to obtain test response data.

[0050] In step S202 above, the first request message refers to the original HTTP / HTTPS network request initiated by the test device (such as OTT set-top box, smart TV, mobile terminal, etc.) to the backend server in order to obtain business data (such as video playback address, user permission information, advertising content, etc.) during the automated testing process. The request includes, but is not limited to, the request path, request method (GET / POST), request headers, and request body.

[0051] The server-side refers to the backend server system that provides business data to the test equipment, such as video-on-demand platforms, member authentication centers, and advertising engines. It should be noted that in this embodiment, the server-side role is logically decoupled. That is, the proxy module no longer relies on the server returning real data, but can replace its output with simulated responses. For example, the server should return "{vip:0, svip:0}", but the proxy module, according to the rules, can directly return "{vip:0, svip:1}", simulating SVIP privileges. This allows the test equipment to complete the permission verification process without its knowledge. This server-side virtualization mechanism frees the test from strong dependence on the real environment, significantly improving test controllability and stability.

[0052] Step S204: Compare the first request message with the request interception rules to obtain the comparison result. The request interception rules are used to describe the matching conditions of the request to be intercepted and the request processing strategy.

[0053] In step S204 above, the request interception rule is a structured configuration instruction used to precisely define a set of logical rules that trigger certain processing behaviors under what network request conditions. Its components include, but are not limited to, matching conditions and processing strategies. The matching conditions cover the request protocol (HTTP / HTTPS), domain name, port, path, request method (GET / POST), query parameters, request headers, and field values ​​in the request body. It supports various combinations of dimensions such as exact matching, prefix matching, regular expression matching, and parameter existence checks, which are not limited here. The processing strategy defines the operation to be performed after a successful match, such as modifying request parameters, replacing response content, injecting delays, returning simulated error codes, extracting field assertions, and recording access logs.

[0054] In some embodiments of this application, request interception rules can be dynamically configured by automated test scripts or test control modules before or during test execution. Each rule describes the matching conditions for a type of request to be intercepted and the corresponding processing strategy. Each rule in the request interception rule set may include the following:

[0055] (1) Request matching conditions: used to limit the scope of requests to which the rules apply, such as matching based on request protocol (scheme), request domain name (host), request port (port), request path (path), and request parameters (query). Since the request method (GET, POST) has different request parameter modes, as an example, parameter matching can be uniformly performed according to the GET style. That is, regardless of whether the actual request method is GET, POST or other (such as PUT, PATCH), when the system performs parameter matching, it will uniformly parse and match the key-value pair parameters in the request body according to the "query parameter (Query)" format of the GET request, rather than distinguishing the parameter passing method of the request method.

[0056] (2) Request processing strategy: This is used to define the operation to be performed when a rule is hit, such as request domain name modification, request path modification, request parameter modification, request header modification, request delay, and request exception return;

[0057] (3) Response processing strategy: used to define the processing logic to be executed after receiving response data, such as response header modification, partial replacement of response data, complete replacement of response data, extraction of response data field values, and assertion verification of response data field values.

[0058] It should be noted that this set of rules can be dynamically updated during system operation. New rules can be added at any time, and existing rules can be modified or removed without stopping or restarting the agent service, thus achieving highly flexible test control capabilities.

[0059] Specifically, conditions such as path, parameters, headers, and methods can be arbitrarily combined to construct highly precise matching rules. For example, to test the scenario of "4K video playback is only available to SVIP users," the rule can be set as: "Path matches / v1 / epg6 / getVodPlayUrl + request header contains Authorization=SVIP + query parameter video_id starts with '4K_'". Only when the first request message fully meets this composite condition will the proxy system trigger response replacement and return simulated data containing the "4K resolution" field; otherwise, the request is forwarded to the server normally. This mechanism ensures the accuracy of the rules, avoids test interference caused by false interception, and allows the same proxy system (i.e., the test system) to support multiple parallel test scenarios simultaneously, greatly improving the reusability of the test environment.

[0060] To quickly and accurately determine whether a rule has been matched, the first request message is compared with the request interception rule in the following way to obtain the comparison result: obtain the matching condition corresponding to each request interception rule, wherein the matching condition includes at least one of the following: request protocol, request domain name, request port, request path, and request parameters; compare the matching condition with the fields in the request context object to obtain the comparison result.

[0061] In some embodiments of this application, to facilitate rule matching and processing, each request can be abstracted into a structured request context object. Specifically, this request context object can contain the following information: the complete access path or interface identifier of the request, the protocol type and request method used by the request, the parameter information contained in the request header, and the business data carried in the request body. In this way, the request context object provides a unified data access interface for the proxy module, enabling subsequent rule judgment, parameter extraction, and response processing to be completed within this context. Furthermore, the request context object allows the proxy module to no longer rely on text parsing of the original message, but instead quickly compare rule conditions through field-level access. For example, it can directly extract requestContext.query.uuid and compare it with the preset UUID value in the rule. This structured design not only significantly improves matching efficiency but also supports advanced judgments in complex scenarios such as parameter values ​​being in the range of numbers, parameters existing but empty, and JSON path matching in the request body, significantly enhancing the flexibility and expressiveness of testing.

[0062] To address the issues of low test coverage and inability to simulate boundary conditions due to a single matching dimension failing to cover complex test scenarios, a multi-dimensional, optional, and combinable matching condition system can be designed. This system supports arbitrary combinations and allows testers to select one or more fields from "protocol," "domain name," "port," "path," and "parameters" in the rules to construct the matching logic.

[0063] Specifically, by building a rule engine, the matching conditions of each interception rule are abstracted into a programmable judgment module, forming a dynamically loadable rule set. When the system is running, it compares each field of the request context object with the matching conditions in the rule item by item to obtain the comparison result.

[0064] Step S206: If the comparison result indicates that the first request message meets the matching conditions, the first request message is converted into a second request message based on the request processing strategy, wherein the second request message is used to simulate different test scenarios of the first request message.

[0065] In step S206 above, the second request message refers to the network request that is reconstructed by the proxy system and finally sent to the backend server after the first request message is modified by the request processing strategy. It is semantically consistent with the original request (still the same business intent), but the parameters, headers, paths or content have been injected with the simulated data required for the test, thus carrying the abnormal or boundary test conditions preset by the test designer.

[0066] A request processing strategy refers to a set of specific operation instructions that the system should execute when the first request message meets the matching conditions. This strategy is used to intervene in the original request by modifying, redirecting, intercepting, delaying, or simulating responses. Its content includes, but is not limited to: modifying the request path, replacing request parameters, injecting request headers, forging request bodies, simulating network latency, forcibly returning abnormal status codes (such as 500 or 403), or directly discarding the request. This mechanism does not require modification to the terminal under test or the backend service; it can reproduce complex scenarios such as permission differences, network anomalies, and service degradation in the test environment solely through intelligent intervention at the proxy layer.

[0067] It should be noted that meeting the matching conditions means that the various attributes of the network request to be detected (i.e., the first request message) (such as URL path, request method, query parameters, request headers, request body content, etc.) completely match or conform to the logical constraints defined in the preset request interception rules, thereby triggering the processing strategy associated with the rule. In other words, meeting the conditions means that the request is a request that needs to be intercepted.

[0068] In some embodiments of this application, a second request message can be dynamically generated by directly modifying specified fields in the request context object according to the request processing strategy. For example, to verify the abnormal behavior of "non-member users misusing SVIP playback links," testers can configure the processing strategy as follows: "When the request path is / v1 / epg6 / getVodPlayUrl and uid=1001, change the access_level field in the request body from free to svip." After a successful match, the system automatically replaces access_level:"free" in the original request with access_level:"svip" and forwards it as a second request message. This method misleads the server into thinking the request comes from an SVIP user, thus returning exclusive content, and the terminal UI changes accordingly. Testers can then verify whether the UI correctly responds to permission abnormalities.

[0069] In some scenarios, the system does not need to actually forward the request to the server. Instead, it can construct a completely new request path or target through processing strategies to achieve logical isolation of the test environment. For example, the rule is set to "when the request path is / v1 / ad / show and ad_type=pre-roll, redirect the request to the local Mock address / mock / ad_pre_roll.json". In this case, the system does not forward the original request, but constructs a completely new second request message with the target address being a local static file and the content being a preset ad response. This method not only avoids dependence on the real advertising system, but also enables rapid testing without network calls, significantly improving testing efficiency. It is especially suitable for high-frequency change scenarios such as ad placements, pop-ups, and pop-up frequency.

[0070] In some embodiments of this application, the second request message can also be verified. The verification method is not limited here, so as to ensure that the second request message still has the semantic integrity that the server can legally parse while simulating an anomaly, so that the test failure is only due to the real defects of the tested system, rather than the fake error caused by proxy intervention.

[0071] In some embodiments of this application, the second request message can be determined in the following ways: when the request processing policy indicates that the first request message should be modified, the corresponding fields of the first request message are modified based on the request processing policy to obtain the second request message; or, when the request processing policy indicates that the first request message should be subject to flow control, the forwarding behavior of the first request message is updated based on the request processing policy to obtain the second request message; or, when the request processing policy indicates that the first request message should be marked, an identifier is set on the first request message to obtain the second request message, wherein the identifier is used to characterize the test behavior semantics carried by the first request message during the test; or, when the request processing policy indicates that the first request message should be subject to state management, the state of the first request message in the test lifecycle is updated based on the matching result of the first request message and the request interception rule to obtain the second request message.

[0072] Specifically, the request processing strategy includes, but is not limited to, the following execution modes:

[0073] (1) Field modification: refers to dynamically replacing or adding / deleting specific fields (such as URL path, query parameters, request headers or request body content) in the first request message to simulate different combinations of business parameters. Its purpose is to create input differences to verify the system's response logic to abnormal or boundary inputs. Specifically, data in the request domain name, request port, request path, request headers, request parameters or request body can be modified or replaced.

[0074] To address the issue that test scenarios rely on real data and cannot flexibly construct diverse combinations of input parameters, some embodiments of this application can directly replace parameter values ​​in the request context object through a field modification strategy. This method can simulate permissions without modifying user identity or server configuration, enabling efficient testing of multiple scenarios with a single account.

[0075] (2) Flow control: This refers to changing the forwarding path or execution flow of a request, such as intercepting the request, delaying the response, redirecting to a Mock address, or directly discarding the request. Its function is to simulate network environment or server-side anomalies, and to accurately reproduce abnormal communication scenarios. Specifically, requests can be redirected, delayed, or abnormally handled.

[0076] To address the issue of the inability to simulate non-functional scenarios such as network failures, service unavailability, and latency jitter, which prevents verification of system fault tolerance, some embodiments of this application employ flow control strategies to interrupt or redirect the normal request path. For example, the strategy could be set to "delay for 5 seconds before forwarding when the request path is / api / user / info" or "directly return a 504 gateway timeout when the request header contains X-Test-Mode=timeout". During processing, the system no longer forwards the original request but instead constructs a second request message simulating a response. The target address of this message is either the local mock service or a preset error code is returned. This mechanism enables the simulation of anomalies without real service dependencies, allowing the terminal to be fully tested even under extreme conditions such as no network, service downtime, and slow response.

[0077] (3) Tagging behavior: This refers to attaching a semantic identifier (such as test_tag=svip_scenario) to the request message. It does not modify the request content, but only records its test intent. Its purpose is to establish a semantic association between the test behavior and the log / report for subsequent result tracing and automated analysis. Specifically, the current request can be tagged for subsequent statistical or assertion analysis.

[0078] To address the issue of test logs being disconnected from test intent and the difficulty in locating failures, some embodiments of this application insert invisible but traceable semantic identifiers into the request context. For example, the processing strategy is to "mark the current request as test_tag=svip_video_4k_playback". The system appends this tag to the request header or context metadata and forwards it along with the request. After the test, the system automatically generates a report showing that "out of 45 requests, 32 were marked as SVIP scenarios, of which 4 had UI anomalies". This tag becomes the "DNA" of the test behavior, making the automated test results interpretable and greatly improving the efficiency of defect investigation, especially in multi-person collaborative and multi-project parallel testing environments.

[0079] (4) Status Management: This refers to dynamically updating the status of a request in the test lifecycle (such as "triggered", "asserted", "retried", "ignored") based on the matching results of the request and the rules. Its function is to realize context awareness and intelligent scheduling of the test process and support complex test orchestration. Specifically, it can record the number of times a request is hit or request characteristic information.

[0080] To address the issues of duplicate request processing, assertion conflicts, and resource contention leading to unreliable test results in concurrent testing, some embodiments of this application establish a lifecycle state machine for each request. When a request first matches a rule, the system sets its state to "triggered." After the assertion module completes verification, the state is updated to "asserted." If the request arrives again due to a network retry, the system recognizes its state as "asserted" and skips processing directly, avoiding duplicate verification. For example, in testing the "repeated ad playback" scenario, if the same request is retried three times, the system only performs an assertion on the first request, marking the remaining three as "processed" to prevent false positives. This mechanism enables the proxy system to have "memory capabilities" and "context awareness," ensuring the rigor and logical consistency of the testing process.

[0081] It should be noted that multiple request processing strategies can be preset for the same request. Since these strategies operate at different levels—for example, field modifications affect content, flow control affects the path, tagging affects metadata, and state management affects the lifecycle—a lack of a unified scheduling mechanism can easily lead to confusion. Therefore, explicit execution priorities can be assigned to request processing strategies (e.g., flow control > field modification > tagging > state management), and these strategies can be executed sequentially by a unified scheduler. When processing a request, the system calls strategy modules according to priority. Each strategy module can only operate based on the output of the previous stage, and direct modification of the underlying structure across layers is prohibited. For example:

[0082] (1) First, execute flow control: if the request is dropped, all subsequent strategies will terminate;

[0083] (2) If not discarded, perform field modification: modify parameters;

[0084] (3) Re-execute the tag: Add test_tag to the modified request;

[0085] (4) Finally, perform status management: update the status to "processed".

[0086] In some embodiments of this application, if the comparison result indicates that any field of the request context object does not meet the matching condition, the first request message remains unchanged and is sent to the server according to a preset forwarding strategy.

[0087] Step S208: Receive the response data returned by the server corresponding to the second request message, and determine the test result of the test device based on the response data.

[0088] In step S208 above, the response data refers to the original response content returned by the server via the network after receiving the second request message, including but not limited to structured or unstructured data such as HTTP status codes, response headers, and response bodies. The test result is a quantifiable and traceable judgment conclusion generated based on the semantic comparison between the response data and the preset test intent. Its content may include, for example, whether the assertion passed (e.g., "svip field is 1"), whether the key field exists (e.g., "ad slot not returned"), whether the response time exceeded the limit, whether the status code is compliant, and whether the data structure is complete.

[0089] In some embodiments of this application, the original response stream returned by the server can be intercepted at the proxy layer, and the entire content of the HTTP response can be captured completely. Regardless of whether the response is JSON, XML, binary stream or encrypted data, the system decodes it through a standard protocol parser and restores it to a structured response context object.

[0090] Furthermore, a built-in response assertion engine can be implemented in the proxy layer to directly bind test expectations to request interception rules. For example, assertion conditions can be configured synchronously when defining rules: "When a playback request is matched, data.vip in the response body must be 1, and data.play_url must contain '4K'". After the response data is returned, the system automatically performs assertion checks without the need for test script intervention. The assertion result (success / failure) is automatically associated with the request tag (such as test_tag=svip_4k) and a structured test report is generated.

[0091] It should be noted that the system also supports multi-dimensional assertions, including but not limited to:

[0092] Structural assertions: Verify whether JSON fields exist and whether the nesting level is correct;

[0093] Value assertions: validate parameter values ​​as specified strings, numeric ranges, or regular expression matches;

[0094] Timeliness assertion: Verify that the response time is less than 500ms to prevent performance degradation;

[0095] Missing assertion: Verifies that the ad field should not appear; used for verification in ad-free scenarios.

[0096] In some embodiments of this application, the test result of the test device can be determined based on the response data in the following manner: obtaining a response processing strategy from a request interception rule that matches the first request message, wherein the response processing strategy is used to define the processing logic to be executed after the response data is received; processing the response data based on the response processing strategy to obtain target response data; and determining the test result based on the target response data.

[0097] A response processing strategy refers to a set of post-processing instructions defined in the request interception rules, specifically targeting server-side response data. It is used to perform operations such as modification, extraction, assertion, logging, or forwarding control on the response content after the proxy system receives the response. Unlike request processing strategies, which operate before the request is sent, response processing strategies focus on the response after it is returned. The target response data refers to the response data processed by the response processing strategy.

[0098] Specifically, response processing strategies can be defined and managed uniformly as a component of request interception rules. Each rule includes not only when to intercept a request (matching conditions) but also what to do after receiving a response (response processing strategy). After the system matches the first request, it automatically loads the response processing strategy bound to it, forming a control chain for the complete request-response lifecycle.

[0099] To enable proactive intervention in server responses, response data can be processed based on response processing strategies to obtain target response data in the following ways: if the response processing strategy instructs modification of the response data, modify the corresponding fields of the response data based on the response processing strategy to obtain target response data; or, if the response processing strategy instructs flow control of the response data, update the forwarding behavior of the response data to obtain target response data.

[0100] Specifically, the response handling strategy includes, but is not limited to, the following execution modes:

[0101] (1) Field Modification: This refers to dynamically replacing, adding, deleting, or formatting specific fields (such as numbers, strings, and nested objects in JSON) in the response content according to preset logic after receiving the server response. It reshapes the semantics of the response without changing the business logic and is used to verify the behavior of the system under different data conditions. Specifically, the response header, response body, and data in the response body can be modified or replaced.

[0102] To address the issues of uncontrollable test environment data and the inability to manually construct business states, which lead to test cases relying on real databases or backend configurations, resulting in low execution efficiency and poor stability, some embodiments of this application allow the system to automatically parse the structured content of the response upon arrival and precisely modify field values ​​according to policy instructions.

[0103] (2) Process control: This refers to adjusting the transmission path, processing order, or delivery method of the response, including: intercepting the response and not forwarding it, delaying the response return, replacing it with a local mock response, forcing the return of an error status code, or discarding the response to trigger an abnormal process. It simulates abnormal environments such as network anomalies, service unavailability, or data corruption to test the fault tolerance and robustness of the system. Specifically, it can delay response data and handle abnormal returns.

[0104] It should be noted that multiple response processing strategies can be preset for the same response data. Based on this, all response processing strategies can be incorporated into a unified scheduling framework and assigned explicit execution priorities and execution phases.

[0105] Priority definition: such as flow control > field modification > assertion record. That is, if a conflict exists, the system will first execute flow control instructions such as "whether to intercept" and "whether to replace", then execute field modification, and finally perform assertion, to ensure that "control takes precedence over content modification".

[0106] Execution chain isolation: The execution result of each strategy serves as the input for the next strategy, forming a "pipeline" processing chain. For example: Initial response enters → Flow control module determines: Should interception be performed? If yes, return directly to Mock and terminate subsequent processing; if no, continue → Field modification module: Replace fields in the original response → Assertion module: Perform validation based on the modified target response.

[0107] In some embodiments of this application, the test result can be determined based on the target response data in the following manner: extracting the target data corresponding to the target field from the target response data; performing an assertion verification operation on the target data to obtain the verification result, wherein the assertion rule corresponding to the assertion verification operation is determined based on the request interception rule that matches the first request message; and determining the test result based on the verification result.

[0108] Specifically, to facilitate testers in obtaining key data from requests and responses, the system encapsulates each request and its corresponding response data into a unified data context object during the proxy processing, and exposes it externally through structured fields. After the proxy module completes request forwarding and receives the response data, the system automatically parses the response content. For different data formats, the system has built-in multiple parsing strategies to convert the response content into structured data that can be used by test logic.

[0109] Furthermore, after parsing is complete, the system allows test rules or test scripts to extract target fields from request parameters, request bodies, or response data according to preset paths or field names, for subsequent assertion verification or data recording.

[0110] Furthermore, based on parameter extraction, the system also supports assertion verification operations on the extraction results. It should be noted that assertion rules can be defined by testers during the automated test case writing phase and associated with specific request matching rules. During assertion verification, the system automatically records the execution result of each assertion, including whether the assertion succeeded or failed. This recorded information can be used for subsequent test report generation, statistical analysis, or issue tracking.

[0111] Furthermore, the system also supports configuring handling strategies after assertion failures. For example, in some testing scenarios, testers can set the system to immediately terminate the current test process when an assertion failure is detected, thereby avoiding the continued execution of invalid test steps; in other scenarios, they can also choose to continue executing subsequent test steps and summarize assertion failure information in a unified manner.

[0112] Through steps S202 to S208 above, a dynamic network proxy interception and intelligent response simulation method is adopted. By capturing the original request messages initiated during the test in real time and dynamically identifying the target request based on preset fine-grained matching rules, the request is transformed according to the preset processing strategy. This achieves the goal of flexibly constructing multiple test scenarios without modifying the code of the system under test. This achieves the technical effects of complete decoupling of test logic and system under test, programmable control of test data, and rapid switching between multiple scenarios. It also solves the technical problem that the automated testing methods used in related technologies require modification of the code of the system under test to simulate multiple test scenarios, resulting in low testing efficiency and intrusiveness to the system under test.

[0113] Figure 3 This is a timing diagram a of a test method according to an embodiment of this application, as shown in Figure a. Figure 3 The diagram illustrates the interaction flow between test device 302, agent module 304, and server 306. Specifically:

[0114] S302: Test device 302 sends a first request message to agent module 304.

[0115] In some embodiments of this application, this step relies on the network configuration of the test device to force all its HTTP / HTTPS traffic to be directed to a locally running proxy module. The proxy module listens on a specified port and receives raw requests from the test device through the operating system network stack. This process is completely transparent to the application under test and does not require modification of the application code or embedding of the SDK, thus achieving non-intrusive traffic capture.

[0116] S304: The proxy module 304 modifies the first request message (second request message) or forwards the first request message to the server as is according to the request interception rules 306.

[0117] In some embodiments of this application, the system performs structured parsing on the received request, extracting elements such as protocol, domain name, path, request method, query parameters, and request body, and compares them one by one with a pre-loaded set of request interception rules. If a rule is matched, the original request is rewritten in a structured manner according to the modification instructions defined in the rule (such as modifying the Host, rewriting the Path, replacing parameters, adding a Header, etc.) to generate a second request message; if no rule is matched, the original request is directly passed through to ensure that the normal process is not disturbed.

[0118] S306: Server 306 returns a response message to proxy module 304.

[0119] In some embodiments of this application, after receiving a request that has been modified or passed through a proxy, the server processes it normally according to its business logic and returns the original HTTP response. This response is generated by a real backend system and contains a real HTTP status code, response headers, and response body content, ensuring the authenticity of the business environment.

[0120] S308: The proxy module 304 modifies the response data or forwards the response data to the test device 302 as is according to the request interception rules.

[0121] In some embodiments of this application, after receiving the server response, the system intelligently intervenes in the response content according to the response processing strategy bound in the interception rules matching the original request. The strategy may include: extracting and validating response fields, modifying response headers, replacing response body content, injecting delays, forging error codes, or directly discarding the response. If the strategy indicates that modification is required, the system performs structured editing of the response to generate target response data; if no intervention is needed, the original response remains unchanged, and regardless of whether it is modified, the response is forwarded to the test device, completing the entire interaction loop. Furthermore, the entire process can be executed asynchronously in an independent thread, ensuring that the main test process is not blocked and supporting parallel response processing in high-concurrency scenarios.

[0122] Figure 4 This is a timing diagram b of a test method according to an embodiment of this application, such as... Figure 4 As shown, in some embodiments of this application, the testing method includes the following steps:

[0123] S402: The automated testing system 400 controls the testing equipment 402 to execute test cases through an open-source framework.

[0124] In some embodiments of this application, the automated testing system calls a general open-source testing framework (such as Appium, Pytest, Playwright, etc.) to drive the testing device to start specified test cases and synchronously initialize the test context through a remote control protocol or device management interface.

[0125] S404: Test device 402 sends data to proxy module 404 by configuring an HTTP proxy.

[0126] In some embodiments of this application, based on the network stack configuration of the test device, the automated testing system can statically or dynamically modify the device's system-level or application-level HTTP proxy settings before the test starts, directing all outbound network requests to the locally running proxy module. It should be noted that this configuration does not require modification of the application code; it is completed solely through system APIs or device management commands, ensuring that all application-layer communication is relayed through the proxy module, achieving full traffic interception and transparent monitoring.

[0127] S406: The proxy module 404 modifies or forwards data to the server as is based on the configuration 406.

[0128] In some embodiments of this application, after receiving a request from the test device, the proxy module performs real-time matching of the request's protocol, path, parameters, headers, and other characteristics according to pre-loaded request interception rules bound to the current test scenario. If a match is successful, a new request is constructed according to the modification logic defined in the rules (such as parameter replacement, domain redirection, and header injection); if no matching rule exists, the original request is directly passed through to ensure that the request received by the server conforms to the test intent while maintaining the authenticity of the business logic.

[0129] S408: Server 406 returns response data to proxy module 404 based on proxy request.

[0130] In some embodiments of this application, after receiving a request modified or passed through a proxy, the server processes it according to its own business logic and returns a standard HTTP response, including a status code, response headers, and response body content. It should be noted that S406 and S408 can be referenced... Figure 2 and Figure 3 Specific implementation examples of the corresponding content will not be described in detail here.

[0131] S410: Agent module 404 responds with data to test device 402 according to the rules.

[0132] In some embodiments of this application, the system performs structured analysis on the response returned by the server based on the response processing strategy associated with the original request, and performs operations such as field extraction, value assertion, content replacement, delayed injection, and abnormal status code forgery. The strategy can trigger dynamic modification of the response content to generate target response data, or it can choose to forward it as is.

[0133] S412: Test equipment 402 returns test result data to automated test system 400.

[0134] In some embodiments of this application, after completing the business process, the test device sends the execution results (such as UI status, element matching results, and operation success indicators) back to the automated testing system through the framework's built-in test report mechanism or log output interface. These results are generated by the test case's own assertion logic or UI detection mechanism and are independent of the response verification results from the proxy module. Upon receiving the results, the automated testing system combines the local execution results with the response assertion conclusions reported by the proxy module to form a complete test evaluation report.

[0135] Figure 5 This is a testing system according to an embodiment of this application, such as... Figure 5 As shown, the system includes a test device 502, multiple agent modules 504, and a server 506, wherein:

[0136] Test device 502 is connected to the agent module and is used to send a first request message to the agent module during the test. The first request message is used to communicate with the server to obtain test response data.

[0137] Multiple proxy modules 504 are connected to the test equipment and the server respectively. They are used to compare the first request message with the request interception rules, and if the first request message meets the request interception rules, they convert the first request message into a second request message based on the request processing strategy. The request interception rules are used to describe the matching conditions of the request to be intercepted and the request processing strategy. The second request message is used to simulate a variety of different business scenarios.

[0138] Server 506, connected to the proxy module, is used to receive the second request message and return the response data to the proxy module. The response data is used to determine the test results of the test equipment.

[0139] In some embodiments of this application, each proxy module is used to receive request and response messages corresponding to a test device, and each proxy module runs in an independent execution thread.

[0140] To address issues such as concurrent execution of multiple test cases, mutual interference in rule configurations, and chaotic test states during automated testing, this application introduces a multi-threaded proxy isolation mechanism at the system architecture level. By instantiating the proxy service and running it in an independent thread, complete decoupling between test cases is achieved.

[0141] (1) Independent design of proxy instances.

[0142] Each test case set can correspond to an independent proxy service instance. The proxy instance is bound to an independent listening port when it starts and runs in an independent execution thread, thus forming a runtime environment isolated from the main test process. This ensures that the proxy instances used by different test cases do not share internal states with each other at runtime, including but not limited to rule configuration, request context data, parameter caching and assertion results, etc., fundamentally avoiding interference problems caused by test cases sharing proxy states.

[0143] (2) Decoupling mechanism between proxy thread and test process.

[0144] After starting, the proxy service thread runs continuously and listens for network requests from test cases, while the main test process is responsible for driving the execution of test logic, injecting configuration rules, and verifying results. The proxy thread and the main test process interact through a clear interface, rather than directly sharing execution logic. Through this decoupling mechanism, the startup, running, and termination of the proxy service will not block or affect the execution of the main test process. Test scripts can continue to execute other test steps while the proxy thread is running, thereby improving overall test execution efficiency.

[0145] (3) The advantages of isolation in concurrent testing scenarios.

[0146] In scenarios where multiple test cases are executed concurrently, different test cases may require different request interception rules, mock response configurations, or assertion logic. If multiple test cases share the same proxy service, issues such as rule overriding, parameter pollution, or false assertions can easily occur. This application's embodiment addresses this by allocating an independent proxy thread to each test case, ensuring that each test case has its own dedicated proxy environment. Each proxy instance only processes requests from its corresponding test case, and the loaded rules and processing logic only apply to the current test case, thereby guaranteeing the accuracy and repeatability of the test results.

[0147] (5) Improved assertion coverage and test reliability.

[0148] Since each proxy thread independently maintains the request context and assertion results, this application embodiment can accurately record and independently determine the assertion results of each test case when multiple test cases are executed concurrently. Even if different test cases have different assertion conditions for the same interface, they will not interfere with each other.

[0149] It should be noted that, Figure 5 The test system shown is used to perform Figures 2 to 4 The test method shown, therefore Figures 2 to 4 The relevant explanations in the test methods also apply to Figure 5 The test system shown will not be described in detail here.

[0150] Figure 6 This is a schematic diagram of the architecture of a test system according to an embodiment of this application, such as... Figure 6 The diagram illustrates the design and implementation of a multi-threaded proxy isolation mechanism. Each proxy service can include a proxy engine module, a dynamic rule management module, a data processing module (including data modification and retrieval), and a proxy thread management module. Specifically:

[0151] (1) Proxy Engine Module: It is built with a lightweight network proxy mechanism, which can capture HTTP / HTTPS communication requests initiated by the test script. As a network middle layer, the proxy engine transparently processes the requests and supports multi-threaded operation, making it suitable for integration into an automated testing framework.

[0152] In some embodiments of this application, the proxy engine module adopts a proxy listening and request takeover mechanism. The proxy service is started as an independent module. Its core implementation is as follows: the proxy module is implemented based on a general network communication mechanism, listens on a local port, and after the test device is configured with a proxy, it will send requests to a specified IP:port. The local proxy receives all request traffic from the test device and can support parsing requests based on HTTP or HTTPS protocols.

[0153] The proxy module can receive the complete request data stream, including the request address, request method, request header information, and request body content, without intruding into the system under test or the test script itself. The system uses native Socket communication or a lightweight service framework that supports HTTP protocol parsing to intercept request data packets and trigger custom processing logic.

[0154] (2) Dynamic rule management module: Provides rich configuration APIs. Test scripts can dynamically inject interception rules through methods such as set_proxy_local, set_proxy_remote, add_handle, etc. Rules support matching paths, request parameters, request headers, etc.

[0155] (3) Data processing module: Supports regular expression extraction or path parsing of fields such as URL, Body, and Query; During the response phase, it automatically mocks the response according to preset rules, judges the correctness of field values ​​and the integrity of the structure, and records the assertion results. This module uses a unified context structure to manage test data.

[0156] In some embodiments of this application, after the proxy module receives the request context object, the system iterates through the currently registered rule set in a preset order. For each rule, the system compares the request path, request parameters, and other information in the request context with the matching conditions defined in the rule. Only when the request meets the matching conditions defined in the rule will the rule be triggered. After the rule is triggered, the system hands over the current request context object and the corresponding rule to the data processing module for processing. If the request does not match any rule, the proxy module will send the request directly to the system under test according to the default forwarding strategy without interfering.

[0157] (4) Proxy Thread Management Module: Each test task can independently enable the proxy service thread to avoid state pollution during the test process. The proxy service is encapsulated as a thread class or daemon process to run, supporting the parallel startup of multiple test cases and improving test efficiency.

[0158] Through the design and implementation of the above multi-threaded proxy isolation mechanism, one-to-one isolation between proxy service instances and test cases can be achieved, avoiding shared state conflicts, supporting the concurrent execution of multiple test cases, improving the overall efficiency of automated testing, and providing a reliable operating foundation for flexible rule configuration and assertion verification.

[0159] To facilitate understanding of the above testing methods and systems, the following explanations will be provided in conjunction with some specific embodiments.

[0160] Taking automated testing of video application playback as an example, video application playback involves not only providing video stream data to user devices, but also business scenarios such as previewing, payment, resolution switching, and advertising. Different business scenarios result in different behaviors in the application. Due to differences in video content, user status, device performance, and network conditions, automated UI testing of video playback faces a variety of complex testing scenarios, such as:

[0161] Video payment involves various scenarios such as free, membership, single-view, coupon, batch unlock, cloud gathering, and SVIP, each with different UI presentation methods in the application; advertising involves pre-roll ads, intro ads, original ads, pause ads, mid-roll ads, and out-of-roll ads, with different ad displays depending on the timing and user; abnormal scenarios during video playback, such as interface request timeouts, video offline, and server-side return errors, all need to be fully tested.

[0162] Faced with such diverse business scenarios, UI automated testing requires a large amount of test data. However, due to the current environment's inability to arbitrarily change data and the inherent instability of the testing environment, the stability of automated testing is severely compromised. Even with a dedicated automated testing environment, large-scale application testing involves multiple servers. Modifying data on each server not only significantly increases the difficulty of implementing UI automated test cases but also impacts execution efficiency. Traditional solutions make it difficult for UI automated testing to cover all complex scenarios. A flexible and controllable automated testing solution is needed to simulate different testing environments. Specifically:

[0163] (1) Configure proxy services and rules.

[0164] 1) Start the proxy service: After the automation starts, start one or more proxy services locally to listen to one or more ports, and set up the HTTP network proxy for each device under test. The local proxy service and the client form a one-to-one relationship (the local listening port is the same as the device proxy port). The proxy service will receive all request data from the device under test.

[0165] 2) Dynamically loaded rules: Dynamic rules are a set of rules for data matching and data modification. They are pre-configured during the automation process. The rules are divided into two parts: the first part is mainly used for data matching, and the second part is mainly used for data modification. The system also provides multiple modification methods. The configuration can be dynamically modified during the automation process to achieve the effect of real-time data control.

[0166] (2) Processing requests and modifying data.

[0167] 1) Data Matching: Testers have pre-written dynamic loading rules based on the requirements of the test cases. For example, they need to test the UI display of the application under different payment rules.

[0168] Matching rules: The dynamic rules have configured an interface named `getVodPlayUrl` with the request parameter `videoId=123456`. When the application clicks to start video playback, it sends a large number of requests. However, because the rules are defined, the system can accurately locate the playback authentication request data based on the configured rules. After a successful data match, subsequent data modifications and returns are made according to the rules. Matching rules are not limited to interface names and parameters; they can also include request methods, domain names, fuzzy matching, etc. This explanation only uses a single scenario.

[0169] 2) Data Modification: The test scenario verifies the different behaviors of regular users playing member-only, single-view, and SVIP videos on the terminal application. After the terminal plays the video-on-demand video, the test system has matched the requested data, and the system provides multiple ways to modify the data:

[0170] 1. Return the entire data: First, save a copy of the test data locally. During testing, the local data will be used to return the data. This can avoid automated test failures caused by configuration changes.

[0171] 2. Partial Data Modification: Assuming the core keywords for the video payment scenario are: {"vip":"0","single":"0","svip":"0"}, for the following test scenario, simply calling the dynamic rule modification method provided by the system will achieve the effect of changing the returned data in real time. The test process is briefly described as follows:

[0172] For regular members: dynamically modify data to {"vip":"1","single":"0","svip":"0"}, play on demand, and verify the UI.

[0173] Single-point pay-per-view: Dynamically modify data to {"vip":"0","single":"1","svip":"0"}, play on demand, and verify UI.

[0174] SVIP members can dynamically modify data to {"vip":"0","single":"0","svip":"1"}, play on demand, and verify the UI.

[0175] As described above, the application automation testing process has been greatly shortened, eliminating the need for a series of operations such as logging into the backend, modifying configurations, and waiting for the configurations to take effect. This improves testing efficiency and ensures the stability of automated testing. Data modification supports changes to request and response headers, domains, parameters, response bodies, and other data. Only a single scenario will be used to illustrate this here.

[0176] 3) Request Interception: In addition to modifying data, intercepted data can also be discarded, delayed, or given an abnormal status code. For example, if the API request timeout is 5 seconds, the API can be simulated to return after 5 seconds to test the video playback experience under poor network conditions.

[0177] 4) Data Validation: During testing, some scenarios may not be verifiable through UI automation. Validation can be performed by extracting key fields from requests or responses. For example, when the application switches to the system media player, the system can only play H264 streams. The terminal's authentication request sets parameter A to 0 to notify the server to return an H264 stream. UI automation can manipulate the interface but cannot perform validation. Now, by intercepting and locating the authentication request, the value of parameter A can be extracted to determine if the terminal implementation is correct.

[0178] 5) Data extraction: Data extraction can be used to assist in the verification of UI automation test results, and it can also be used for data reporting verification. For example, when playing a video, the terminal will report various playback data such as video ID, video duration, and video resolution to the server. To verify whether the reported data is normal, the video response fields can be extracted first, and then the reported data can be verified.

[0179] 6) Other: It can also perform statistics on data, such as re-login for failed data requests. Furthermore, it can also decrypt data. For example, boot configuration is usually encrypted. When it is necessary to test various configurations, the data can be encrypted and decrypted and then the configuration can be modified to simulate various test scenarios.

[0180] (3) Isolation in concurrent testing scenarios.

[0181] Compared to API automation, UI automation is slower in execution. Currently, most test cases take 30-40 seconds to execute on a single device, which cannot meet the needs of rapid project iteration. Therefore, the system must support concurrent testing. However, when executing multiple test cases concurrently, the system must ensure that requests, data, and states between different test cases do not interfere with each other to guarantee the independence and accuracy of test results. The multi-threaded proxy isolation mechanism in this application can effectively solve this problem.

[0182] 1) Decouple independent proxy instances from test case sets.

[0183] This application provides a dedicated proxy environment for each test case set in a concurrent testing environment by allocating an independent proxy service instance for each test case set. Each proxy instance runs in an independent thread and is bound to an independent listening port. For example, when executing multiple test case sets:

[0184] Test case set A uses port 9001 for request proxying;

[0185] Test case set B uses port 9002 for request proxying;

[0186] Test case set C uses port 9003 for request proxying.

[0187] By providing an independent proxy instance for each test case, the system avoids situations where multiple test cases share proxy state or configuration, thereby ensuring the isolation and reliability of the tests.

[0188] 2) Isolated request and response data.

[0189] Each proxy instance only processes the request and response data of the corresponding test case. The request parameters, response data, proxy rules and other information of different test cases are stored and processed independently, ensuring that the test results will not be distorted or incorrect due to data sharing or state overlap between test cases.

[0190] For example, when test case A simulates a payment request, the proxy service modifies information such as the amount and user ID in the request according to preset rules. This modification does not affect the request data of test cases B and C. This data isolation ensures that the test cases do not interfere with each other during concurrent execution, resulting in more accurate and controllable test results.

[0191] 3) Independent testing process and data verification execution.

[0192] Each test case is executed in an independent proxy thread, which not only ensures the isolation of request and response data, but also ensures the independence of the test process. When the verification of test case set A fails, it will only affect the execution of that test case, without interrupting or interfering with the execution of test case set B or test case set C.

[0193] Meanwhile, the system supports setting independent validation rules for each test case set, such as:

[0194] Test case A verifies whether the payment amount is correct;

[0195] Test case B verifies whether the video playback is smooth;

[0196] Test case C verifies whether the login was successful.

[0197] The verification results of each test case are recorded independently and detailed logs are provided to ensure that all verifications in the concurrent testing environment are executed as expected and that test results are fed back in a timely manner.

[0198] 4) Optimize the efficiency and stability of concurrent testing.

[0199] By binding each test case to an independent proxy thread, this application effectively avoids problems such as request contention and data conflict that may occur in traditional concurrent testing, making the testing process more efficient and stable. Each test case runs in an independent environment and is not affected by external interference, thereby improving the accuracy and reliability of the test.

[0200] 5) Supports large-scale concurrent testing scenarios.

[0201] The concurrent test isolation mechanism of this application supports the simultaneous launch of multiple test cases, adapting to large-scale testing scenarios. Each agent thread independently executes the corresponding test case and feeds back its results to the main test framework, thereby achieving efficient allocation and rapid execution of automated test tasks. This mechanism is particularly suitable for batch regression testing, performance testing, and stability testing in high-concurrency environments.

[0202] This application allows for the dynamic injection of proxy rules via API during test execution without restarting the proxy service. It supports multi-dimensional conditional matching based on URL path, request method, parameter values, etc., and can inject local simulated response data. Furthermore, request parameters are exposed to the test framework through a unified structure, facilitating subsequent assertions or analysis. It also supports value comparison, missing field detection, and data structure integrity verification of response fields during the proxy process. In addition, multiple proxy threads can run independently, ensuring no rule pollution or data interference occurs in multi-task testing scenarios. Compared to existing technologies, this application has the following significant advantages:

[0203] (1) Significantly improved testing efficiency: No need to manually set up proxies and breakpoints for packet capture; the test script can automatically configure the required interception rules and assertion logic, saving a lot of test preparation time.

[0204] (2) High degree of automation: The system can be fully embedded into existing automated testing frameworks and CI / CD processes without the need for additional graphical interfaces or manual intervention;

[0205] (3) Flexible adaptation to multiple scenarios: The configuration can be hot-updated via API, which can adapt to various scenarios such as regression testing, gray-scale verification, Mock testing, and abnormal path coverage;

[0206] (4) Fast and accurate defect location: Problems such as abnormal interface returns and errors in key fields can be captured during the testing phase, improving the efficiency of defect location;

[0207] (5) The system is highly versatile and easy to reuse: The system has no strong dependence on specific business operations, is well encapsulated, and is easy to migrate and reuse quickly among multiple products and projects within the enterprise.

[0208] Figure 7 This is a structural diagram of a testing apparatus according to an embodiment of this application, such as... Figure 7 As shown, the device includes:

[0209] The receiving module 702 is used to receive a first request message initiated by the test device during the test process, wherein the first request message is used to communicate with the server to obtain test response data;

[0210] The comparison module 704 is used to compare the first request message with the request interception rules to obtain the comparison result. The request interception rules are used to describe the matching conditions of the request to be intercepted and the request processing strategy.

[0211] The conversion module 706 is used to convert the first request message into a second request message based on the request processing strategy when the comparison result indicates that the first request message meets the matching conditions. The second request message is used to simulate different test scenarios of the first request message.

[0212] The determination module 708 is used to receive the response data returned by the server corresponding to the second request message, and determine the test result of the test device based on the response data.

[0213] It should be noted that, Figure 7 The test apparatus shown is used to perform Figure 2 The test method shown, therefore Figure 2 The relevant explanations in the test methods also apply to Figure 7 The test setup shown will not be described in detail here.

[0214] This application also provides an electronic device, which includes a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute steps that implement the test methods in various embodiments of this application.

[0215] This application also provides a non-volatile storage medium including a stored computer program, wherein the device containing the non-volatile storage medium executes the steps of the test methods in various embodiments of this application by running the computer program.

[0216] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the testing methods in various embodiments of this application.

[0217] This application also provides a computer program that, when executed by a processor, implements the steps of the testing methods in various embodiments of this application.

[0218] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0219] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0220] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0221] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0222] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0223] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0224] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A testing method, characterized in that, include: Receive a first request message initiated by the test device during the test process, wherein the first request message is used to communicate with the server to obtain test response data; The first request message is compared with the request interception rules to obtain the comparison result, wherein the request interception rules are used to describe the matching conditions of the request to be intercepted and the request processing strategy; If the comparison result indicates that the first request message meets the matching condition, the first request message is converted into a second request message based on the request processing strategy, wherein the second request message is used to simulate different test scenarios of the first request message; The system receives response data from the server corresponding to the second request message and determines the test result of the test device based on the response data.

2. The method according to claim 1, characterized in that, Based on the request processing strategy, the first request message is converted into a second request message, including: If the request processing strategy instructs that the first request message be modified, the corresponding fields of the first request message are modified based on the request processing strategy to obtain the second request message; or, When the request processing strategy instructs for flow control of the first request message, the forwarding behavior of the first request message is updated based on the request processing strategy to obtain the second request message; or, When the request processing strategy instructs that the first request message be marked, an identifier is set for the first request message to obtain the second request message, wherein the identifier is used to characterize the test behavior semantics carried by the first request message during the test; or, When the request processing strategy indicates that the first request message is subject to state management, the state of the first request message in the test lifecycle is updated based on the matching result between the first request message and the request interception rule to obtain the second request message.

3. The method according to claim 1, characterized in that, Determining the test results of the test equipment based on the response data includes: A response processing strategy is obtained from the request interception rules that match the first request message, wherein the response processing strategy is used to define the processing logic to be executed after the response data is received; The response data is processed based on the aforementioned response processing strategy to obtain the target response data; The test results are determined based on the target response data.

4. The method according to claim 3, characterized in that, The response data is processed based on the aforementioned response processing strategy to obtain target response data, including: If the response processing strategy instructs that the response data be modified, the fields corresponding to the response data are modified based on the response processing strategy to obtain the target response data; or... When the response processing strategy instructs the flow control of the response data, the forwarding behavior of the response data is updated to obtain the target response data.

5. The method according to claim 3, characterized in that, Determining the test result based on the target response data includes: Extract the target data corresponding to the target field from the target response data; An assertion verification operation is performed on the target data to obtain a verification result, wherein the assertion rule corresponding to the assertion verification operation is determined based on the request interception rule that matches the first request message; The test result is determined based on the verification result.

6. The method according to claim 1, characterized in that, The first request message includes a structured request context object; the first request message is compared with the request interception rules to obtain the comparison result, including: Obtain the matching conditions corresponding to each request interception rule, wherein the matching conditions include at least one of the following: request protocol, request domain name, request port, request path, and request parameters; The matching conditions are compared with the fields in the request context object to obtain the comparison result.

7. The method according to claim 6, characterized in that, The method further includes: if the comparison result indicates that any field of the request context object does not meet the matching condition, maintaining the first request message unchanged, and sending the first request message to the server according to a preset forwarding strategy.

8. A testing system, characterized in that, This includes testing equipment, multiple proxy modules, and a server-side component. The testing device is connected to the proxy module and is used to send a first request message to the proxy module during the testing process. The first request message is used to communicate with the server to obtain test response data. The plurality of proxy modules are respectively connected to the test device and the server, and are used to compare the first request message with the request interception rules, and if the first request message meets the request interception rules, convert the first request message into a second request message based on the request processing strategy. The request interception rules are used to describe the matching conditions of the request to be intercepted and the request processing strategy, and the second request message is used to simulate a variety of different business scenarios. The server is connected to the proxy module and is used to receive the second request message and return response data to the proxy module, wherein the response data is used to determine the test result of the test device.

9. The system according to claim 8, characterized in that, Each of the agent modules is used to receive request and response messages corresponding to a test device, and each agent module runs in an independent execution thread.

10. A testing apparatus, characterized in that, include: The receiving module is used to receive a first request message initiated by the test device during the test process, wherein the first request message is used to communicate with the server to obtain test response data; The comparison module is used to compare the first request message with the request interception rules to obtain a comparison result, wherein the request interception rules are used to describe the matching conditions of the request to be intercepted and the request processing strategy; A conversion module is used to convert the first request message into a second request message based on the request processing strategy when the comparison result indicates that the first request message meets the matching condition, wherein the second request message is used to simulate different test scenarios of the first request message; The determination module is used to receive the response data returned by the server corresponding to the second request message, and determine the test result of the test device based on the response data.

11. An electronic device, characterized in that, include: A memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the test method according to any one of claims 1 to 7.

12. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, wherein the device containing the non-volatile storage medium executes the test method according to any one of claims 1 to 7 by running the computer program.

13. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the test method according to any one of claims 1 to 7.

Images