Test method, system, device and electronic device for application

Abstract

The application discloses a kind of applied test method, system, device and electronic equipment.The present application relates to the field of software testing, which comprises the following steps: based on bytecode enhancement mechanism, injecting an agent into a target application dynamically when a deployment instruction for the target application is received;In the case where the request characteristics of the target call request sent by the agent are received, it is determined whether the target call request hits the preset simulation rule according to the request characteristics, and the agent discards the target call request and feeds back the response result indicated by the simulation rule to the business thread in the case where the target call request hits the simulation rule;In the case where the target call request does not hit the simulation rule, the target call request is released;Determine the test result of the target application based on the processing mode of the response result received by the business thread during the test process.Through the present application, the problem of low test efficiency in related art by relying on third-party services to test the application is solved.

Description

Technical Field

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

[0002] With the widespread adoption of microservices and distributed architectures, a single application typically needs to call numerous external services or third-party interfaces, such as payment gateways, push notification services, authentication and authorization interfaces, and inventory services. This architecture presents multiple challenges during the development, testing, demonstration, and fault diagnosis phases:

[0003] (1) The environment is highly uncontrollable. The third-party services that we rely on may be under development, with unstable interfaces, frequent changes, or outright unavailability; downstream services in the test environment may crash due to insufficient resources, misconfiguration, or other reasons, causing the integration test to be blocked. This phenomenon is particularly serious when collaborating across teams, where the progress of one team is often stalled because the services of another team are not ready, making it difficult to control the test duration.

[0004] (2) Complex scenarios are difficult to construct. Simulating situations where the interface returns specific exception status codes (such as 5xx server error), timeouts, or special business error codes (such as "insufficient balance") is difficult to reproduce reliably in a real environment. However, coverage of such exception scenarios is crucial to ensuring software robustness. To achieve full coverage of exception scenarios, more testing time is required.

[0005] (3) Costs and limitations associated with calling real services. Frequent calls to real third-party payment, SMS, map, and other interfaces may incur additional costs, trigger interface quota limits, or even risk control rules. In addition, a large number of automated tests consume test data each time a new order is created and a notification is sent, resulting in high cleaning costs and impacting test duration.

[0006] Therefore, relying on third-party services to test applications in related technologies results in low testing efficiency.

[0007] There is currently no effective solution to the aforementioned problems in the relevant technologies. Summary of the Invention

[0008] The main purpose of this application is to provide a testing method, system, device, and electronic device for applications, so as to solve the problem of low testing efficiency caused by relying on third-party services for application testing in related technologies.

[0009] To achieve the above objectives, according to one aspect of this application, a testing method for an application is provided. The method includes: upon receiving a deployment instruction for a target application, dynamically injecting a proxy program into the target application based on a bytecode enhancement mechanism; upon receiving request characteristics of a target invocation request sent by the proxy program, determining whether the target invocation request matches a preset simulation rule based on the request characteristics, and obtaining a judgment result, wherein during the testing process of the target application, the proxy program sends the request characteristics when it detects a business thread in the target application initiating a target invocation request, the target invocation request being used to invoke a third-party service; feeding back the judgment result to the proxy program, wherein if the target invocation request matches the simulation rule, the proxy program discards the target invocation request and feeds back the response result indicated by the simulation rule to the business thread; if the target invocation request does not match the simulation rule, the proxy program allows the target invocation request to proceed so that the third-party service generates a response result; and determining the test result of the target application based on how the business thread processes the received response result during the testing process.

[0010] Optionally, the application testing method may also include: obtaining the application registration information of the target application from the deployment instructions; determining the control module deployed on the same server as the target application based on the application registration information; sending the target instructions to the control module, wherein, upon receiving the target instructions, the control module dynamically injects the agent program into the target application based on the bytecode enhancement mechanism.

[0011] Optionally, the application's testing method also includes: during the process of dynamically injecting the agent program into the target application through the bytecode enhancement mechanism, the control module injects a parameter string into the agent program, wherein the parameter string includes at least a first parameter and a second parameter, the first parameter indicating whether the simulation function has been enabled, and the second parameter indicating the address for obtaining the simulation rules.

[0012] Optionally, the testing method for the application may also include: obtaining all enabled simulation rules corresponding to the target application from the rule database; comparing the request characteristics of the target call request with the matching conditions in the enabled simulation rules; if there is a matching condition that matches the request characteristics, the judgment result indicates that the target call request has hit the preset simulation rule; if there is no matching condition that matches the request characteristics, the judgment result indicates that the target call request has not hit the preset simulation rule.

[0013] Optionally, the testing method for the application may also include: during the testing process of the target application, if the agent detects that a business thread in the target application has initiated a target call request, it determines whether the simulation function has been enabled based on preset parameters. If the simulation function has been enabled, it sends the request characteristics corresponding to the target call request.

[0014] Optionally, the application's testing method may also include one of the following: upon receiving a simulation function shutdown command, sending a first shutdown command to the agent program, wherein the agent program updates the preset parameters upon receiving the first shutdown command; upon receiving a simulation function shutdown command, sending a second shutdown command to the control module, wherein the control module dynamically injects the target agent program into the target application based on a bytecode enhancement mechanism upon receiving the second shutdown command, and updates the preset parameters through the target agent program.

[0015] Optionally, the application's testing methods also include: upon receiving log entries uploaded by the agent program, storing the log entries, wherein if the target call request does not match the simulation rules, the agent program determines whether the log collection function has been enabled based on preset parameters; if the log collection function has been enabled, it generates log entries based on the target call request and the response results of the third-party service.

[0016] To achieve the above objectives, according to another aspect of this application, an application testing system is provided. The system includes: a proxy program, configured to, during the testing of a target application, upon detecting a target call request initiated by a business thread in the target application, send request characteristics of the target call request to a central service module, the target call request being used to invoke a third-party service; and, if the target call request matches a preset simulation rule, discard the target call request through the proxy program and feed back the response result indicated by the simulation rule to the business thread; if the target call request does not match the simulation rule, allow the target call request through the proxy program to enable the third-party service to generate a response result; a central service module, configured to, upon receiving a deployment instruction for the target application, dynamically inject the proxy program into the target application based on a bytecode enhancement mechanism; upon receiving the request characteristics sent by the proxy program, determine whether the target call request matches the preset simulation rule based on the request characteristics, obtain a determination result, and feed the determination result back to the proxy program; and determine the test result of the target application based on how the business thread processes the received response result during the testing process.

[0017] To achieve the above objectives, according to another aspect of this application, an application testing apparatus is provided. The apparatus includes: a first processing module, configured to dynamically inject a proxy program into the target application based on a bytecode enhancement mechanism upon receiving a deployment instruction for the target application; a judgment module, configured to determine whether the target call request matches a preset simulation rule based on the request characteristics received from the proxy program, and obtain a judgment result, wherein the proxy program sends the request characteristics when it detects a business thread in the target application initiating a target call request during the testing process of the target application, and the target call request is used to call a third-party service; a second processing module, configured to feed back the judgment result to the proxy program, wherein the proxy program discards the target call request and feeds back the response result indicated by the simulation rule to the business thread if the target call request matches the simulation rule; if the target call request does not match the simulation rule, it allows the target call request to proceed so that the third-party service generates a response result; and a first determining module, configured to determine the test result of the target application based on how the business thread processes the received response result during the testing process.

[0018] Optionally, the first processing module further includes: a first acquisition submodule, used to acquire application registration information of the target application from the deployment instructions; a first determination submodule, used to determine the control module deployed on the same server as the target application based on the application registration information; and a sending submodule, used to send the target instructions to the control module, wherein, upon receiving the target instructions, the control module dynamically injects the agent program into the target application based on a bytecode enhancement mechanism.

[0019] Optionally, during the process of dynamically injecting the agent program into the target application through the bytecode enhancement mechanism, the control module injects a parameter string into the agent program. The parameter string includes at least a first parameter and a second parameter. The first parameter indicates whether the simulation function has been enabled, and the second parameter indicates the address for obtaining the simulation rules.

[0020] Optionally, the judgment module further includes: a second acquisition submodule, used to acquire all enabled simulation rules corresponding to the target application from the rule database; a comparison submodule, used to compare the request characteristics of the target call request with the matching conditions in the enabled simulation rules; a second determination submodule, used to determine that if there is a matching condition that matches the request characteristics, the judgment result indicates that the target call request hits the preset simulation rule; and a third determination submodule, used to determine that if there is no matching condition that matches the request characteristics, the judgment result indicates that the target call request does not hit the preset simulation rule.

[0021] Optionally, during the testing of the target application, if the agent detects that a business thread in the target application has initiated a target call request, it determines whether the simulation function has been enabled based on preset parameters. If the simulation function has been enabled, it sends the request characteristics corresponding to the target call request.

[0022] Optionally, the application's testing device further includes: a first sending module, used to send a first shutdown command to the agent program upon receiving a simulation function shutdown command, wherein the agent program updates preset parameters upon receiving the first shutdown command; and a second sending module, used to send a second shutdown command to the control module upon receiving a simulation function shutdown command, wherein the control module dynamically injects the target agent program into the target application based on a bytecode enhancement mechanism upon receiving the second shutdown command, and updates the preset parameters through the target agent program.

[0023] Optionally, the application's testing device also includes: a storage module, used to store log entries when the agent program uploads log entries, wherein the agent program determines whether the log collection function has been enabled based on preset parameters when the target call request does not match the simulation rules; and generates log entries based on the target call request and the response results of the third-party service when the log collection function has been enabled.

[0024] To achieve the above objectives, according to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, a test method for controlling the device where the computer-readable storage medium is located to execute the above-described application is provided.

[0025] To achieve the above objectives, according to another aspect of this application, an electronic device is provided, the electronic device including a memory storing an executable program; and a processor for running the program, wherein the program executes the above-described test method for the application during runtime.

[0026] To achieve the above objectives, according to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of a test method for the application described above.

[0027] In this embodiment, the proxy program is dynamically injected into the target application based on the bytecode enhancement mechanism. This facilitates the dynamic injection of additional target call request processing logic into the target application at runtime. The target application's business code does not require any imports, annotations, or configurations, nor does it depend on any specific framework. The target application does not need to be restarted, which helps reduce development costs and improve testing efficiency. Furthermore, by determining the generation method of different response results for the target call request based on whether it hits the simulation rules, it is possible to flexibly construct various exceptions and boundary scenarios, increasing the richness of the response results received by the target application. This allows for efficient verification of the correctness of the target application's business logic in the test environment, further improving testing efficiency.

[0028] Therefore, the method provided in this application achieves the goal of adaptively feeding back simulated response results to the target application during the testing process, thereby improving testing efficiency and solving the technical problem of low testing efficiency caused by relying on third-party services for application testing in related technologies. Attached Figure Description

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

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

[0031] Figure 2 This is a flowchart of the testing method for the application provided in the embodiments of this application. Figure 1 ;

[0032] Figure 3 This is a flowchart of the testing method for the application provided in the embodiments of this application. Figure 2 ;

[0033] Figure 4 This is a flowchart of the testing method for the application provided in the embodiments of this application. Figure 3 ;

[0034] Figure 5 This is a schematic diagram of the operation of a testing system for an application provided in the embodiments of this application;

[0035] Figure 6 This is a schematic diagram of a testing apparatus for an application provided according to an embodiment of this application;

[0036] Figure 7 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0037] 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.

[0038] 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.

[0039] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant regulations and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding operation entry points for them to choose to agree to or refuse automated decision results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0040] Example 1

[0041] According to an embodiment of this application, an embodiment of a testing method for an application is also provided. 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. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0042] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1A hardware block diagram of a computer terminal (or mobile device) for implementing a testing method for an application is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor (MCU) or a field-programmable gate array (FPGA), etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output (I / O) interface, a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. 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.

[0043] It should be noted that the aforementioned one or more processors 102 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 (or mobile device). 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).

[0044] 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 application testing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned application testing 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 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0045] The transmission device 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 device 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 device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

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

[0047] Under the aforementioned operating environment, this application provides the following: Figure 2 The test method for the application is shown. Figure 2 This is the flow chart of the test method applied according to Embodiment 1 of this application. Figure 1 .

[0048] Step S201: Upon receiving a deployment instruction for the target application, the agent is dynamically injected into the target application based on the bytecode enhancement mechanism.

[0049] Optionally, electronic devices, application systems, servers, and other devices can be used as the execution subject of this application. In this embodiment, the central service module is used as the execution subject to execute the above-mentioned application testing method.

[0050] In some implementations, the target application is the application to be tested. The target application can be a microservice, and it can run in the target JVM process of the target JVM (Java Virtual Machine). Depending on the actual application scenario, the type of target application may vary; for example, it could be a payment application, a social application, a shopping application, a ticketing application, etc., but this embodiment does not impose any specific limitations.

[0051] In some implementations, deployment instructions are used to instruct the deployment of an agent in the target application. The agent can be a JavaAgent (also known as a Java agent), a component that can be loaded at runtime via startup parameters or a dynamic attachment mechanism and can be used to modify bytecode during the class loading phase.

[0052] Upon receiving a deployment instruction for a target application, the central service module dynamically injects the agent program into the running target application based on a bytecode enhancement mechanism. For example, utilizing the JVM's Attach mechanism, the VirtualMachine.loadAgent() method is called while the target Java process (i.e., the process to which the target application belongs) is running, loading the agent program into the target JVM. Specifically, it is injected into the target JVM process itself, i.e., into the target application, without requiring a restart of the target application. The aforementioned JVM Attach mechanism refers to the Java Virtual Machine attachment mechanism, which allows external processes to dynamically connect to the target JVM via the Attach API and load specified agent programs onto it.

[0053] For example, the central service module can be called Mock-API, which is an independently deployed backend service that provides an API (Application Programming Interface) to the outside world, serving as the system's central hub. Its functions may include: rule storage, persistently storing simulation rules and metadata in a database; configuration query, providing a query interface for agent programs to determine whether a call hits a simulation rule and returning the corresponding response; log reception and storage, receiving real request and response logs reported by agent programs for traffic recording and one-click simulation; and command relay, whereby when a user clicks to enable or disable simulation in the front-end interface, the central service module translates the command into an HTTP (Hypertext Transfer Protocol) call to the control module on the target host. It maintains a mapping between application names and their deployment host addresses, and is either registered by the user or automatically discovered.

[0054] In some implementations, the central service module can dynamically inject a proxy program into the target application via a control module deployed on the same server as the target application. When it is necessary to inject the proxy program into the target application, the central service module can send relevant instructions to the control module, which then dynamically injects the proxy program into the target application based on a bytecode enhancement mechanism.

[0055] For example, the control module, which can be called Mock-Attach, is a resident HTTP service deployed on the same server as the target application. It runs independently of the target application process and can be packaged into an executable work package (e.g., a compressed file). The control module is responsible for receiving instructions from the central service module and actually operating the underlying JVM's Attach mechanism. This module provides a standard HTTP interface, such as "POST / attach / agent," and receives parameters including the application process name (applicationName) and the agent package path (agentJarPath). Upon receiving the instruction to inject the agent program from the central service module, the control module first executes system commands (such as "jps -l" or "ps -ef | grep java") to find the process identifier (PID) of the target JVM process. Subsequently, the control module can proactively obtain the initial configuration parameters (such as the central address and application identifier) ​​corresponding to the target application from the central service module. Then, it uses Java's Attach API to connect to the target JVM, calls the loadAgent method of the VirtualMachine instance to dynamically load the agent program, and passes the configuration parameters as strings to the agent program.

[0056] For example, the proxy program can be called a Mock-Agent. The proxy program can exist in the form of a JavaAgent toolkit. This JavaAgent-implemented client enhancement module, independent of business logic, is used to intercept HTTP calls and execute mock logic. It is dynamically injected into the target JVM through the aforementioned Attach process; specifically, it is injected into the target JVM process, i.e., into the target application. Its core operating mechanism consists of two parts: bytecode enhancement and configuration initialization. Regarding bytecode enhancement, during class loading, methods of mainstream HTTP client classes in the target application (such as OkHttp3's RealCall.execute() and Apache HttpClient's CloseableHttpClient.execute()) are instrumented to implant relevant processing logic (intercepting target call requests to determine whether the mock rules are met). In terms of configuration initialization, after receiving the parameter string from the control module, the `agentmain` method in the agent program immediately parses and sets it as a JVM system property, for example: `System.setProperty("mock.enable","true");System.setProperty("mock.center.url","http: / / mock-api.com");System.setProperty("mock.app.id", "app-demo")`. Here, `mock.enable` is the first parameter, indicating whether the simulation function is enabled. A value of `true` indicates that the simulation function is enabled, and a value of `false` indicates that the simulation function is disabled. `mock.center.url` is the second parameter, indicating the address for obtaining the simulation rules. For example, the value of `http: / / mock-api.com` is the actual address for obtaining the simulation rules. `mock.app.id` is the third parameter, indicating the application identifier of the target application into which the agent program is injected. For example, the value of `app-demo` is the application identifier of the target application. The aforementioned first parameter, second parameter, third parameter, and their corresponding values ​​can be recorded in parameter strings, so that the agent program can update JVM system properties based on the parameter strings.

[0057] Step S202: Upon receiving the request characteristics of the target call request sent by the proxy program, determine whether the target call request hits the preset simulation rules based on the request characteristics, and obtain the judgment result. In the process of testing the target application, the proxy program sends the request characteristics when it detects that the business thread in the target application initiates the target call request. The target call request is used to call a third-party service.

[0058] After dynamically injecting the proxy into the target application, the proxy will detect during the target application's testing process whether a business thread in the target application has initiated a target call request. This target call request is used to invoke a third-party service, which could be a payment gateway, SMS interface, or other service independent of the target application. Upon detecting a target call request initiated by a business thread, the proxy intercepts the request, temporarily preventing it from being sent to the corresponding third-party service. The proxy then determines the request characteristics of the target call request and sends these characteristics to the central service module.

[0059] In some implementations, request characteristics include, but are not limited to, the URL (Uniform Resource Locator) of the target invocation request, the HTTP method, request headers, query parameters, and request body summary.

[0060] In some implementations, the proxy can use the target application's own pre-initialized HTTP client instance (reusing its connection pool, timeout configuration, SSL context, etc.) to send a matching query request to the central service module, carrying the URL (Uniform resource locator), method, headers, and other information of the currently invoked third-party service.

[0061] After receiving a matching query request, the central service module can extract request features from the query request and then determine whether the target call request matches a preset simulation rule based on the request features, thus obtaining a judgment result. For example, the simulation rule includes matching conditions and the corresponding processing method when the matching conditions are matched. The processing method includes: discarding the target call request and simulating the generation of a corresponding result, or allowing the target call request to generate a response result from a third-party service. The request features of the target call request are compared with the matching conditions in the simulation rule. If a matching condition exists, the judgment result indicates that the target call request matches the preset simulation rule; otherwise, the judgment result indicates that the target call request does not match the preset simulation rule.

[0062] Step S203: The judgment result is fed back to the proxy program. If the target call request matches the simulation rule, the proxy program discards the target call request and feeds back the response result indicated by the simulation rule to the business thread. If the target call request does not match the simulation rule, the target call request is allowed so that the third-party service can generate a response result.

[0063] After determining the judgment result, the result is fed back to the proxy program. Upon receiving the judgment result, the proxy program executes the branch logic. For example, if the result is a match, a fake response result is simulated and returned to the business thread, blocking the real target call request; if the result is a miss, the target call request is allowed to continue executing the real call process, and the third-party service can feed back the real response result to the business thread.

[0064] For example, the central service module performs a matching judgment based on all enabled simulation rules. If the request characteristics match a simulation rule, it returns the judgment result and the corresponding simulated response data to the proxy program. The proxy program directly constructs the HTTP response object (i.e., the response result) corresponding to the response data in memory and returns it to the business thread, while the real network request is discarded. If the request characteristics do not match a simulation rule, the central service module returns the judgment result to the proxy program.

[0065] Step S204: Determine the test results of the target application based on how the business thread processes the received response results during the test.

[0066] In some implementations, the response received by the business thread during testing can be a response simulated by a proxy program or a response generated by a third-party service. After receiving the response, the business thread will perform subsequent processing based on it. For example, if the target call request is used to invoke a payment gateway for payment, and the response received by the business thread is "payment successful," then the processing performed by the business thread after receiving the response could be updating the order status to "paid," sending a shipping notification, etc.

[0067] Therefore, the central service module can determine the test result of the target application based on how the business thread handles the received response results during the test. For example, if the business thread handles the received response results in the same way as the expected handling method, the target application is considered normal. Conversely, if the business thread handles the received response results differently from the expected handling method, an anomaly is identified in the target application, and this can be recorded. Thus, based on how the business thread handles the received response results throughout the entire test process, the final test result is determined. For example, if no abnormal events occur, the test result is considered passed; otherwise, if abnormal events occur, the test result is considered failed.

[0068] In this embodiment, the proxy program is dynamically injected into the target application based on the bytecode enhancement mechanism. This facilitates the dynamic injection of additional target call request processing logic into the target application at runtime. The target application's business code does not require any imports, annotations, or configurations, nor does it depend on any specific framework. The target application does not need to be restarted, which helps reduce development costs and improve testing efficiency. Furthermore, by determining the generation method of different response results for the target call request based on whether it hits the simulation rules, it is possible to flexibly construct various exceptions and boundary scenarios, increasing the richness of the response results received by the target application. This allows for efficient verification of the correctness of the target application's business logic in the test environment, further improving testing efficiency.

[0069] Therefore, the method provided in this application achieves the goal of adaptively feeding back simulated response results to the target application during the testing process, thereby improving testing efficiency and solving the technical problem of low testing efficiency caused by relying on third-party services for application testing in related technologies.

[0070] Optionally, in the application testing method provided in this application embodiment, before determining whether the target call request hits the preset simulation rule based on the request characteristics and obtaining the determination result, the method further includes: upon receiving a deployment instruction for the target application, obtaining the application registration information of the target application from the deployment instruction; determining the control module deployed on the same server as the target application based on the application registration information; and sending the target instruction to the control module, wherein, upon receiving the target instruction, the control module dynamically injects the proxy program into the target application based on the bytecode enhancement mechanism.

[0071] In some implementations, the application registration information is the metadata of the target application in the system. The application registration information may include the process identifier (such as process name or process ID PID) of the target JVM process to which the target application belongs, the host address (IP address or domain name) of the server where the target application is located, and port information.

[0072] After determining the application registration information, the control module deployed on the same server as the target application is identified based on this information. For example, the control module deployed on that server can be located using the obtained server address of the target application.

[0073] After identifying the control module, a target instruction is sent to it, instructing the control module to dynamically inject the agent program into the target application. Upon receiving the target instruction, the control module dynamically injects the agent program into the target application based on a bytecode enhancement mechanism.

[0074] In some implementations, the management module receives deployment instructions from users (e.g., testers) and then sends the deployment instructions to the central service module.

[0075] For example, the management module can be called Mock-UI. This module is a web application that provides a visual user interface, accessible through a browser. Its main functions include: application management, displaying a list of Java applications connected to the system (e.g., the target application), showing the application name, host, and simulation function activation status; rule management, providing an interface to create, query, modify, and delete simulation rules, with rule content including matching conditions (e.g., request URL, HTTP method, request headers, query parameters), returned data (e.g., judgment results, fixed text JSON / XML text, or responses generated by dynamic scripts), and activation status; a global switch, providing a button to enable or disable the entire application's simulation function with one click; and log viewing, displaying real interface call logs collected and reported by the agent program, and supporting one-click generation of simulation rules. All operations of the management module are completed by sending HTTP API requests to the central service module.

[0076] For example, taking the "Order Service" interface simulated by testers in the pre-production environment as an example to illustrate the deployment steps performed before testing the target application:

[0077] Step 1: Environment Deployment and Preparation;

[0078] First, deploy the front-end resources of mock-api.jar (the central service module's toolkit) and mock-ui (the management module's toolkit) to a central server, start the back-end services, and configure the database. On each application server in the pre-production environment (e.g., the server where the application is deployed), run mock-attach.jar (the control module's toolkit) as a service and ensure it starts automatically on boot. Upload mock-agent.jar (the agent program's toolkit) to a fixed path on the target server (i.e., the server where the target application belongs), such as " / opt / agents / mock-agent.jar". Applications that need to connect do not require any modifications and can run normally.

[0079] Step 2: Configure the mock rules on the Mock-UI;

[0080] Testers log into Mock-UI via a browser. On the application management page, they register an "order service" (assuming the process is displayed as "order-service") and associate it with its host address. Then, they go to rule management and create a new rule:

[0081] (1) Simulation rules;

[0082] Application: order-service;

[0083] Matching criteria: The URL matches the regular expression "^https: / / payment-api.com / v1 / pay / .+", the HTTP method is POST, and the request body contains the characteristic keyword;

[0084] Returned data: Status code 200, response body {"status": "success", "transaction_id": "mock_123456"};

[0085] Enabled status: Enabled.

[0086] Once the rules are saved, they will not take effect immediately. They can be activated via a global switch.

[0087] Step 3: Dynamically enable the Mock function;

[0088] The tester locates the application "order-service" in the application list and clicks the "Enable Mock" button. Mock-UI sends a request to Mock-API: "PATCH / api / applications / order-service" with the body {"status":"ENABLED"}. Upon receiving the request, Mock-API updates the application status in its database to enabled and, based on the application registration information, finds that order-service is deployed on the host pre-prod-host-01. Subsequently, Mock-API constructs an HTTP POST request and sends it to "http: / / pre-prod-host-01:9090 / attach / agent", with the request body containing:

[0089] {

[0090] "applicationName": "order-service",

[0091] "agentJarPath": " / opt / agents / mock-agent.jar"

[0092] }

[0093] The Mock-Attach service running on pre-prod-host-01 receives the request. It executes the "jps -l" command and finds "2541 order-service.jar" in the output, confirming that the PID is 2541. Next, the Mock-Attach service actively queries the Mock-API to obtain the application's pre-configured initial parameters, receiving the string: "centerUrl=http: / / mock-api.company.com&enable=true&appId=order-service-prod".

[0094] The Mock-Attach service uses the Java Attach API to connect to the virtual machine with PID 2541, constructs a VirtualMachine instance, and calls:

[0095] vm.loadAgent(" / opt / agents / mock-agent.jar", "centerUrl=http: / / mock-api.company.com&enable=true&appId=order-service-prod");

[0096] The Mock-Agent is loaded into the process where the application resides in the virtual machine, and then the connection is disconnected.

[0097] After Mock-Agent is loaded, its agentmain method is executed, parsing the parameter string and setting system properties using key-value pairs. The core code is as follows:

[0098] System.setProperty("mock.enable", "true");

[0099] System.setProperty("mock.center.url", "http: / / mock-api.company.com");

[0100] System.setProperty("mock.app.id", "order-service-prod").

[0101] Simultaneously, based on the bytecode enhancement mechanism, the bytecode converter registered within the Agent begins to retransform subsequently loaded classes and already loaded HTTP client classes, inserting relevant logic before the OkHttp3's RealCall.execute() method (i.e., intercepting the target call request to determine whether it matches the preset simulation rules), thereby injecting the Mock-Agent into the application "order-service". At this point, the order service does not need to be restarted, and the simulation functionality has been fully injected.

[0102] In some implementations, by leveraging a highly service-oriented control module, the underlying JVM operations are encapsulated as HTTP services, enabling one-click activation or disabling of simulation rules, all without requiring an application restart. This helps resolve the issue of local proxy tools requiring manual configuration and the need to refresh or restart after rule updates, thus improving testing efficiency.

[0103] It should be noted that since the JVM's Attach mechanism requires local process privileges, by injecting the proxy program using a control module deployed on the same server as the target application, effective processing of the proxy program can be achieved, thereby improving the reliability of application testing.

[0104] Optionally, in the application testing method provided in the embodiments of this application, during the process of dynamically injecting the agent program into the target application through the control module based on the bytecode enhancement mechanism, the control module injects a parameter string into the agent program. The parameter string includes at least a first parameter and a second parameter. The first parameter indicates whether the simulation function has been enabled, and the second parameter indicates the address for obtaining the simulation rules.

[0105] In some implementations, the control module injects a parameter string into the agent program during the process of dynamically injecting the agent program into the target application through a bytecode enhancement mechanism. This parameter string can exist in the form of key-value pairs, where the key represents the parameter and the value represents the parameter value.

[0106] In some implementations, the parameter string includes at least a first parameter and a second parameter. The first parameter is a configuration item in the parameter string used to control the simulation function switch; its value is typically a Boolean value (e.g., true or false), used to instruct the agent program whether to immediately initiate the interception logic (i.e., intercept the target call request and determine whether it matches the simulation rule). The second parameter is a configuration item in the parameter string used to specify the address of the simulation rule center; for example, its value is the access address of the central service module, which the agent program uses to query the simulation rules after loading. The simulation rules define which HTTP requests should be simulated and the data returned by the simulation.

[0107] For example, the parameter string can be represented as "centerUrl=http: / / mock-api.company.com&enable=true&appId=order-service-prod". After the agentmain method in the agent program receives the aforementioned parameter string from the control module, it immediately parses and sets it as a JVM system property, for example: System.setProperty("mock.enable", "true"); System.setProperty("mock.center.url","http: / / mock-api.com"); System.setProperty("mock.app.id","app-demo"). In this parameter string, "mock.enable" is the first parameter, used to indicate whether the simulation function is enabled. When its value is true, the simulation function is enabled; otherwise, if it is false, the simulation function is disabled. "mock.center.url" is the second parameter, used to indicate the address for obtaining the simulation rules. For example, the value of "http: / / mock-api.com" is the actual address for obtaining the simulation rules. "mock.app.id" is the third parameter, used to indicate the application identifier of the target application into which the proxy program is injected. For example, the value of "app-demo" is the application identifier of the target application.

[0108] In some implementations, the control module can determine whether the simulation function is enabled and the address for obtaining simulation rules based on JVM system properties during runtime.

[0109] It should be noted that by injecting parameter strings, the on / off switch (first parameter) and rule address (second parameter) of the simulation function can be dynamically specified according to the instructions loaded each time without modifying the proxy program code or repackaging the toolkit. This helps to prevent sensitive information (such as the central service URL) from being hardcoded in the proxy program. On the one hand, this helps to improve testing efficiency, and on the other hand, it helps to improve the security of the system.

[0110] Optionally, in the application testing method provided in this application embodiment, determining whether the target call request matches a preset simulation rule based on the request characteristics to obtain a judgment result includes: obtaining all enabled simulation rules corresponding to the target application from the rule database; comparing the request characteristics of the target call request with the matching conditions in the enabled simulation rules; if there is a matching condition that matches the request characteristics, then determining that the judgment result indicates that the target call request matches the preset simulation rule; if there is no matching condition that matches the request characteristics, then determining that the judgment result indicates that the target call request does not match the preset simulation rule.

[0111] In some implementations, a rule database is used to store simulation rules. These rules can be tagged with a status indicating whether they are enabled or disabled. Different simulation rules can be set for different applications within the rule database; that is, a correspondence can exist between simulation rules and applications. In other implementations, however, no correspondence may exist between simulation rules and applications; in other cases, the simulation rules can be generic. The central service module can retrieve all enabled simulation rules corresponding to a target application from the rule database based on the status tags.

[0112] After obtaining all enabled simulation rules corresponding to the target application, the request characteristics of the target call request are compared with the matching conditions in the enabled simulation rules. Request characteristics include, but are not limited to, the request URL (or path), HTTP method, request headers, query parameters, and key fields in the request body. Matching conditions refer to the filtering conditions defined in each simulation rule, used to determine whether the simulation rule applies to the current target call request. For example, matching conditions in a simulation rule can be URL regular expressions, HTTP method qualifiers, specific request header values, specific field values, etc. The enabled simulation rules are traversed, and the request characteristics are compared with the matching conditions in each traversed simulation rule, such as performing string matching, regular expression matching, exact matching, etc. If a matching condition exists that matches the request characteristics, the result indicates that the target call request has hit a preset simulation rule, and the simulation rule to which the matching condition belongs is determined to be the simulation rule hit by the target call request. Conversely, if no matching condition exists that matches the request characteristics, the result indicates that the target call request has not hit a preset simulation rule. In some implementations, if during the traversal process, a matching condition of a simulated rule is found to match the current request characteristics, the comparison of subsequent rules can be stopped immediately, the judgment result is determined to be a hit, and the judgment result and the simulated response data corresponding to the simulated rule are returned to the agent program, thereby improving processing efficiency.

[0113] For example, the decision-making process for the target call request described above is illustrated. A tester triggers a request to create an order in the order service application (i.e., the target application), whose internal logic calls the payment interface "https: / / payment-api.com / v1 / pay / charge". When the business thread executes the OkHttp3 request (i.e., the target call request), it is intercepted by Mock-Agent. The interceptor in Mock-Agent first obtains the system property "mock.enable", which is true, and enters the simulation processing branch. Mock-Agent obtains the OkHttpClient instance in the current thread context (this instance is created by the application and configured with a connection pool and timeout), rather than creating it itself, which ensures the consistency between the simulated query channel and the real business channel. Mock-Agent uses this client to construct an HTTP POST request to the Mock-API address "http: / / mock-api.company.com / api / match", with the request body containing the URL, method, and request header summary of the current call.

[0114] After receiving a matching request, the Mock-API queries the rule database for all enabled mock rules under the application "order-service-prod" and compares them with the characteristics of the current request. The rule "URL regular expression ^https: / / payment-api.com / v1 / pay / . + POST method" matches, so it returns a mock action instruction, including the judgment result, the matching result, and the response definition. Upon receiving the response, the Agent directly constructs a response object (i.e., the response result) using OkHttp's Response.Builder, sets the status code to 200, writes a preset JSON to the response body, and then returns this response object as the return value of the invoked execute() method to the business thread. The business logic receives a "payment successful" response and continues the subsequent process.

[0115] If, during this process, the intercepted request does not match any enabled mock rules, and the application has log collection enabled (system property "mock.log" is true), then Mock-Agent will reuse the business client to send a real request. After receiving the real response, it will asynchronously package the request and the real response and send them to the Mock-API log interface for subsequent analysis or one-click rule generation. Then, the real response will be returned to the caller (i.e., the application). If logging is not enabled, the request will be allowed directly.

[0116] In some implementations, when querying rules and reporting logs, Mock-Agent directly reuses the HTTP client already instantiated by the target application, completely adopting all network configurations of the application, including connection pool, timeout settings, SSL certificates, and proxies. This avoids version conflicts and timeout or connection failures caused by inconsistent configurations that may result from introducing a separate HTTP library, ensuring maximum consistency between the simulated traffic path and the real traffic path.

[0117] It should be noted that by comparing the request characteristics with the matching conditions in the simulation rules to determine the judgment result, the judgment result can be accurately determined, thereby improving the reliability of the test.

[0118] Optionally, in the application testing method provided in this application embodiment, during the testing process of the target application, when the agent program detects that the business thread in the target application has initiated a target call request, it determines whether the simulation function has been enabled according to preset parameters. If the simulation function has been enabled, it sends the request characteristics corresponding to the target call request.

[0119] In some implementations, the agent sets the JVM system properties corresponding to the target application based on the system string passed in by the control module, and the preset parameters refer to the parameters in the JVM system properties.

[0120] In some implementations, during the testing of the target application, when the agent detects a target call request initiated by a business thread in the target application, it intercepts the target call request, reads preset parameters from the JVM system properties, and the preset parameters include at least the first and second parameters mentioned above. Based on the value of the first parameter, it determines whether the simulation function is enabled; for example, if the value of the first parameter is true, the simulation function is enabled; if the value of the first parameter is false, the simulation function is not enabled.

[0121] With the simulation function enabled, the agent extracts the request characteristics corresponding to the currently intercepted target call request, and uses the target application's initialized HTTP client instance to send a matching query request to the central service module. The matching query request uses the request characteristics as the query condition and is used to request the central service module to query whether the target call request matches the preset simulation rules.

[0122] For example, when a business thread initiates an HTTP call, the interceptor in the proxy program first reads the "mock.enable" property (i.e., the first parameter in the preset parameters). If the value is false or does not exist, the real request is executed directly. If it is true, the application uses its own pre-initialized HTTP client instance (reusing its connection pool, timeout configuration, SSL context, etc.) to send a matching query request to the central service, carrying information such as the URL, method, and headers of the current call. Finally, the simulation function can be disabled by setting "mock.enable" to false again, and all calls will resume the real connection.

[0123] It should be noted that, through the above method, the request feature is sent only when the simulation function is enabled, avoiding invalid network communication and the waste of computing resources of the central service module, which helps to improve the flexibility of the testing method of this application.

[0124] Optionally, in the application testing method provided in the embodiments of this application, the method further includes one of the following: upon receiving a simulation function shutdown instruction, sending a first shutdown instruction to the agent program, wherein the agent program updates the preset parameters upon receiving the first shutdown instruction; upon receiving a simulation function shutdown instruction, sending a second shutdown instruction to the control module, wherein the control module dynamically injects the target agent program into the target application based on a bytecode enhancement mechanism upon receiving the second shutdown instruction, and updates the preset parameters through the target agent program.

[0125] In some implementations, the mock function disable command can be issued by a user (e.g., a tester). Upon receiving the mock function disable command, the central service module can send a first disable command to the agent program. After receiving the first disable command, the agent program parses the disable signal and calls the Java API to change the value of the system property `mock.enable` from `true` to `false`, thereby immediately changing the interception logic. When subsequent business threads initiate requests, the interceptor reads `mock.enable=false` and will directly allow the request without sending a query to the central service module.

[0126] For example, after the test is completed, the tester clicks "Disable Mock" on the Mock-UI to trigger the command to disable the mock function. The Agent can periodically send heartbeats to the central service module. After receiving the command to disable the mock function, the central service module includes the latest configuration in its response. If the status of the mock function in the latest configuration is disabled, the response is determined to be the first disable command. In this case, the Agent sets "mock.enable" to false locally. In this way, all subsequent HTTP calls directly use the real link, the mock function is disabled, and there is no need to restart the service.

[0127] In some implementations, upon receiving a command to disable the simulation function, a second shutdown command is sent to the control module. Upon receiving the second shutdown command, the control module loads a dedicated target agent program for disabling the simulation function into the target application. The target agent program then modifies the value of the first parameter in the preset parameters to disable the simulation function.

[0128] For example, after the test is completed, the tester clicks "Disable Mock" on the Mock-UI to trigger the simulation function shutdown command. After receiving the simulation function shutdown command, the central service module sends a second shutdown command to Mock-Attach. Mock-Attach then calls the Attach API to load a lightweight Agent (i.e., the target agent) specifically for modifying JVM system properties, or utilizes a listening thread that has been pre-started by the Agent.

[0129] It should be noted that the above method enables the simulation function to be turned off without restarting the target application, thereby ensuring seamless switching between simulation and real call states in long-running production or pre-production environments, which helps improve testing efficiency and reliability.

[0130] Optionally, in the application testing method provided in this application embodiment, the method further includes: storing log entries when receiving log entries uploaded by the proxy program, wherein the proxy program determines whether the log collection function has been enabled based on preset parameters when the target call request does not match the simulation rules; and generating log entries based on the target call request and the response results of the third-party service when the log collection function has been enabled.

[0131] In some implementations, when a target call request does not match the mock rules, the agent determines whether log collection is enabled based on preset parameters. Preset parameters refer to parameters in the JVM system properties, which may include a fourth parameter indicating whether log collection is enabled. For example, after intercepting a target call request, the agent first determines whether the request matches the mock rules. If it does not, the agent reads the log collection configuration (e.g., `mock.log=true`) from the preset parameters to determine whether log collection is enabled.

[0132] If log collection is enabled, after the agent sends a target call request and receives a response from a third-party service, it packages the request information and response information into a single log entry. This completes the context of the actual call, providing a comprehensive data foundation for subsequent analysis, replay, or rule generation. After generating the log entry, it is sent to the central service module, which receives the data and stores the log entry in a database or log storage system.

[0133] In some embodiments, real traffic to a specific interface in the production environment can be recorded and replayed in the test environment. For example, the operation process is as follows: First, enable the "Log Collection Only" mode (mock.enable=false, but mock.log=true) for a specific application on the Mock-UI. At this time, all requests are allowed to pass normally, and the Mock-Agent reports requests and responses asynchronously. After operating for a period of time, the administrator browses the call data for a specific period on the log viewing page, selects a typical "refund interface call," and clicks "Generate Rules with One Click." The system automatically captures the request characteristics and response body of this call, generates a draft rule, which the user can fine-tune before confirming and saving. Subsequently, simulation is enabled for the application in the test environment, and the rule takes effect immediately without any code writing, completing the transformation from real traffic to simulated rules.

[0134] Figure 3 This is a flowchart of the testing method for the application provided in the embodiments of this application. Figure 2 ,according to Figure 3 An optional application process of this embodiment will be described by way of example. For example... Figure 3As shown, when the proxy program detects a target call request, it first determines whether the simulation function is enabled. If not, it directly allows the target call request and returns a real response through a third-party service. If enabled, it sends a matching query request to the central service module. Upon receiving the matching query request, the central service module determines whether the target call request matches the simulation rules. If it does, it notifies the proxy program to construct a response result and feeds it back to the business thread. If it does not match the simulation rules, the proxy program determines whether the log collection function is enabled. If the log collection function is enabled, it allows the target call request, returns a real response through a third-party service, and reports a log entry. If the log collection function is disabled, it allows the target call request, returns a real response through a third-party service, and does not report any log entries.

[0135] It should be noted that by recording real calls through the log collection function, testers do not need to manually write complex matching expressions and response data, which helps to quickly create high-fidelity simulation rules and thus improves testing efficiency.

[0136] Therefore, the method provided in this application achieves the goal of adaptively feeding back simulated response results to the target application during the testing process, thereby improving testing efficiency and solving the technical problem of low testing efficiency caused by relying on third-party services for application testing in related technologies.

[0137] 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, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0138] Example 2

[0139] According to an embodiment of this application, a testing system for an application implementing the above-described application testing method is also provided, the system comprising:

[0140] The proxy program is used during the testing of the target application to send the request characteristics of the target call request to the central service module when it detects that a business thread in the target application has initiated a target call request. The target call request is used to call a third-party service. If the target call request matches the preset simulation rules, the proxy program discards the target call request and feeds back the response result indicated by the simulation rules to the business thread. If the target call request does not match the simulation rules, the proxy program allows the target call request to be allowed so that the third-party service can generate a response result.

[0141] The central service module is used to dynamically inject a proxy program into the target application based on the bytecode enhancement mechanism when a deployment instruction for the target application is received; when a request feature is received from the proxy program, it determines whether the target call request hits the preset simulation rules based on the request feature, obtains the judgment result, and feeds the judgment result back to the proxy program; and determines the test result of the target application based on how the business thread processes the received response results during the test.

[0142] In some implementations, the application's testing system may include a control module and a management module in addition to the aforementioned agent program and central service module. The functions of the agent program, central service module, control module, and management module, as well as their interaction processes, can be found in Embodiment 1, and therefore will not be repeated here.

[0143] For example, Figure 4 This is a flowchart of the testing method for the application provided in the embodiments of this application. Figure 3 ,like Figure 4 As shown, the complete interaction process from the user clicking "Enable" to the loading and activation of Mock-Agent is as follows: The user clicks the "Enable Mock" button in the Mock-UI (i.e., the management module) to trigger the activation of the simulation function. The Mock-UI sends a command to the Mock-API (i.e., the central service module) to update the application status. The Mock-API updates the application status, queries the host mapping, and sends the target command to the Mock-Attach service (i.e., the control module) on the target host. The Mock-Attach finds the process PID, obtains the configuration, and then calls the Attach API to load the Mock-Agent (i.e., the agent program), passing in the parameter string. The Mock-Agent parses the parameter string to set system properties and begins interception through bytecode enhancement. The Mock-Agent can also report the successful loading status to the management module or register a heartbeat.

[0144] For example, Figure 5 This is a schematic diagram of the operation of a testing system for an application provided in an embodiment of this application, such as... Figure 5 As shown, from a software process perspective, the above interaction process includes the following steps: deploying each module, wherein Mock-Attach and the target application reside on the same server. Figure 5The target JVM process is the process of the target application, and the business code is the business code of the target application. Simulation rules are configured through Mock-UI; Mock-UI issues an enable command; Mock-API receives the command and sends an HTTP load request (i.e., the target command) to the target host's Mock-Attach service; the Mock-Attach service interacts with the central service module to discover the process, obtain configuration, prepare parameters, and execute the Attach; Mock-Agent is loaded, initializes its configuration, and completes bytecode enhancement; the business requests (i.e., target call requests) issued by the target application's business code are intercepted by Mock-Agent. The Agent decides whether to return a simulated response or allow the request based on system attributes and query results (sending a rule matching query to Mock-API), and determines whether to log the request; when disabled, an updated configuration is issued, and the Agent switches to pass-through mode.

[0145] In this embodiment, the proxy program is dynamically injected into the target application based on the bytecode enhancement mechanism. This facilitates the dynamic injection of additional target call request processing logic into the target application at runtime. The target application's business code does not require any imports, annotations, or configurations, nor does it depend on any specific framework. The target application does not need to be restarted, which helps reduce development costs and improve testing efficiency. Furthermore, by determining the generation method of different response results for the target call request based on whether it hits the simulation rules, it is possible to flexibly construct various exceptions and boundary scenarios, increasing the richness of the response results received by the target application. This allows for efficient verification of the correctness of the target application's business logic in the test environment, further improving testing efficiency.

[0146] Therefore, the method provided in this application achieves the goal of adaptively feeding back simulated response results to the target application during the testing process, thereby improving testing efficiency and solving the technical problem of low testing efficiency caused by relying on third-party services for application testing in related technologies.

[0147] Example 3

[0148] This application also provides an application testing apparatus. It should be noted that the application testing apparatus of this application embodiment can be used to execute the application testing method provided in this application embodiment. The application testing apparatus provided in this application embodiment will be described below.

[0149] According to an embodiment of this application, an apparatus for implementing the testing method described above is also provided, such as... Figure 6 As shown, the device includes:

[0150] The first processing module 601 is used to dynamically inject the agent program into the target application based on the bytecode enhancement mechanism when a deployment instruction for the target application is received.

[0151] The judgment module 602 is used to determine whether the target call request hits the preset simulation rule based on the request characteristics when it receives the request characteristics of the target call request sent by the proxy program, and obtain the judgment result. In the test process of the target application, the proxy program sends the request characteristics when it detects that the business thread in the target application initiates the target call request. The target call request is used to call a third-party service.

[0152] The second processing module 603 is used to feed back the judgment result to the agent program. If the target call request matches the simulation rule, the agent program discards the target call request and feeds back the response result indicated by the simulation rule to the business thread. If the target call request does not match the simulation rule, the target call request is allowed to proceed so that the third-party service can generate a response result.

[0153] The first determining module 604 is used to determine the test results of the target application based on how the business thread processes the received response results during the test.

[0154] Therefore, the method provided in this application achieves the goal of adaptively feeding back simulated response results to the target application during the testing process, thereby improving testing efficiency and solving the technical problem of low testing efficiency caused by relying on third-party services for application testing in related technologies.

[0155] Optionally, in the application testing device provided in this application embodiment, the first processing module further includes: a first acquisition submodule, which, upon receiving a deployment instruction for the target application, acquires the application registration information of the target application from the deployment instruction; a first determination submodule, which determines, based on the application registration information, a control module deployed on the same server as the target application; and a sending submodule, which sends a target instruction to the control module, wherein, upon receiving the target instruction, the control module dynamically injects a proxy program into the target application based on a bytecode enhancement mechanism.

[0156] Optionally, in the testing device for the application provided in this application embodiment, the control module injects a parameter string into the agent program during the process of dynamically injecting the agent program into the target application through the bytecode enhancement mechanism. The parameter string includes at least a first parameter and a second parameter. The first parameter indicates whether the simulation function has been enabled, and the second parameter indicates the address for obtaining the simulation rules.

[0157] Optionally, in the testing device for the application provided in this application embodiment, the judgment module further includes: a second acquisition submodule, used to acquire all enabled simulation rules corresponding to the target application from the rule database; a comparison submodule, used to compare the request characteristics of the target call request with the matching conditions in the enabled simulation rules; a second determination submodule, used to determine that if there is a matching condition that matches the request characteristics, the judgment result indicates that the target call request hits the preset simulation rule; and a third determination submodule, used to determine that if there is no matching condition that matches the request characteristics, the judgment result indicates that the target call request does not hit the preset simulation rule.

[0158] Optionally, in the testing device for the application provided in this application embodiment, during the testing process of the target application, when the agent program detects that the business thread in the target application has initiated a target call request, it determines whether the simulation function has been enabled according to preset parameters. If the simulation function has been enabled, it sends the request feature corresponding to the target call request.

[0159] Optionally, in the application testing device provided in the embodiments of this application, the application testing device further includes: a first sending module, used to send a first shutdown instruction to the agent program when a simulation function shutdown instruction is received, wherein the agent program updates the preset parameters when the first shutdown instruction is received; and a second sending module, used to send a second shutdown instruction to the control module when a simulation function shutdown instruction is received, wherein the control module dynamically injects the target agent program into the target application based on a bytecode enhancement mechanism when the second shutdown instruction is received, and updates the preset parameters through the target agent program.

[0160] Optionally, in the application testing device provided in the embodiments of this application, the application testing device further includes: a storage module, used to store log entries when receiving log entries uploaded by the agent program, wherein when the target call request does not match the simulation rule, the agent program determines whether the log collection function has been enabled according to preset parameters; when the log collection function has been enabled, it generates log entries based on the target call request and the response results of the third-party service.

[0161] It should be noted that the first processing module 601, the judgment module 602, the second processing module 603, and the first determination module 604 mentioned above correspond to steps S201 to S204 in Embodiment 1. The four modules and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0162] Example 4

[0163] Embodiments of this application may provide an electronic device. Figure 7 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 7 As shown, the electronic device may include: one or more ( Figure 7 (Only one is shown) processor 1002, memory 1004, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0164] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus 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, thereby implementing the above-described methods. The memory 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 may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0165] The processor can access the information and application programs stored in the memory via the transmission device to execute the steps described in the above embodiments.

[0166] Those skilled in the art will understand that Figure 7 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 7 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 7 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 7 The different configurations shown.

[0167] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0168] Example 5

[0169] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the testing method of the application provided in Embodiment 1.

[0170] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0171] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing test method steps of an application.

[0172] 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.

[0173] 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.

[0174] 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 is only a logical functional division, and in actual implementation, there may be other division methods. For example, 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 couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0175] 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 network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0176] 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.

[0177] 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 of 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.

[0178] 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 for an application, characterized in that, include: Upon receiving a deployment instruction for the target application, the agent is dynamically injected into the target application based on a bytecode enhancement mechanism; Upon receiving the request characteristics of the target call request sent by the proxy program, the proxy program determines whether the target call request hits the preset simulation rules based on the request characteristics, and obtains the determination result. In the process of testing the target application, the proxy program sends the request characteristics when it detects that the business thread in the target application initiates a target call request. The target call request is used to call a third-party service. The judgment result is fed back to the proxy program, wherein, if the target call request matches the simulation rule, the proxy program discards the target call request and feeds back the response result indicated by the simulation rule to the business thread; if the target call request does not match the simulation rule, the target call request is allowed to proceed so that the third-party service generates a response result. The test result of the target application is determined based on how the business thread processes the received response results during the test.

2. The method according to claim 1, characterized in that, Dynamically injecting the agent program into the target application based on the bytecode enhancement mechanism includes: Obtain the application registration information of the target application from the deployment instructions; Based on the application registration information, determine the control module deployed on the same server as the target application; A target instruction is sent to the control module, wherein, upon receiving the target instruction, the control module dynamically injects the agent program into the target application based on a bytecode enhancement mechanism.

3. The method according to claim 2, characterized in that, During the process of dynamically injecting the agent program into the target application through the bytecode enhancement mechanism, the control module injects a parameter string into the agent program. The parameter string includes at least a first parameter and a second parameter. The first parameter indicates whether the simulation function has been enabled, and the second parameter indicates the address for obtaining the simulation rules.

4. The method according to claim 1, characterized in that, Based on the request characteristics, determine whether the target call request matches a preset simulation rule, and obtain the determination result, including: Retrieve all enabled simulation rules corresponding to the target application from the rule database; The request characteristics of the target call request are compared with the matching conditions in the enabled simulation rules; If a matching condition exists that matches the request characteristics, then the judgment result indicates that the target call request has hit a preset simulation rule; If no matching condition exists that matches the request characteristics, then the determination result indicates that the target call request did not hit the preset simulation rule.

5. The method according to claim 1, characterized in that, During the testing of the target application, when the agent detects that a business thread in the target application has initiated a target call request, it determines whether the simulation function has been enabled based on preset parameters. If the simulation function has been enabled, it sends the request characteristics corresponding to the target call request.

6. The method according to claim 5, characterized in that, The method also includes one of the following: Upon receiving a command to disable the simulation function, a first shutdown command is sent to the agent program, wherein the agent program updates the preset parameters upon receiving the first shutdown command; Upon receiving a command to disable the simulation function, a second disable command is sent to the control module. Upon receiving the second disable command, the control module dynamically injects the target agent program into the target application based on a bytecode enhancement mechanism, and updates the preset parameters through the target agent program.

7. The method according to claim 1, characterized in that, The method further includes: Upon receiving a log entry uploaded by the agent program, the agent program stores the log entry. If the target call request does not match the simulation rule, the agent program determines whether the log collection function is enabled based on preset parameters. If the log collection function is enabled, the agent program generates the log entry based on the target call request and the response result of the third-party service.

8. A testing system for an application, characterized in that, include: A proxy program is used, during the testing process of the target application, to send the request characteristics of the target call request to the central service module when it is detected that a business thread in the target application initiates a target call request, the target call request being used to call a third-party service; And if the target call request matches a preset simulation rule, the proxy program discards the target call request and sends the response result indicated by the simulation rule back to the business thread; If the target call request does not match the simulation rule, the proxy program allows the target call request to be allowed to generate a response result from the third-party service. The central service module is used to dynamically inject the agent program into the target application based on the bytecode enhancement mechanism when a deployment instruction for the target application is received. Upon receiving the request characteristics sent by the proxy program, the system determines whether the target call request matches a preset simulation rule based on the request characteristics, obtains the determination result, and feeds the determination result back to the proxy program; based on the way the business thread processes the received response results during the test, the system determines the test result of the target application.

9. A testing device for an application, characterized in that, include: The first processing module is used to dynamically inject the agent program into the target application based on the bytecode enhancement mechanism when a deployment instruction for the target application is received. The judgment module is used to determine whether the target call request hits a preset simulation rule based on the request characteristics when it receives the request characteristics of the target call request sent by the proxy program, and obtain a judgment result. The proxy program sends the request characteristics when it detects that the business thread in the target application initiates a target call request during the testing process of the target application. The target call request is used to call a third-party service. The second processing module is used to feed back the judgment result to the proxy program, wherein, if the target call request matches the simulation rule, the proxy program discards the target call request and feeds back the response result indicated by the simulation rule to the business thread; if the target call request does not match the simulation rule, the target call request is allowed to proceed so that the third-party service generates a response result. The first determining module is used to determine the test result of the target application based on how the business thread processes the received response results during the test.

10. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, executes the test method of the application according to any one of claims 1 to 7.

Images