Service dynamic testing method, device, computer equipment and storage medium

Abstract

The present invention discloses a service dynamic testing method, apparatus, computer equipment, and storage medium. The method comprises: obtaining test request parameters triggered by an upstream system, wherein the upstream system is the calling end of a downstream system; matching the test request parameters by calling a filter according to preset object rules to obtain matching result information, wherein the preset object rules are rules for matching the test request parameters generated based on first configuration information of the upstream system and second configuration information of the downstream system; processing the test request parameters according to the matching result information, and outputting a test result. The technical solution of the present invention avoids processing test request parameters that do not conform to the preset object rules, thereby improving the accuracy and efficiency of the service dynamic testing method.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a service dynamic testing method, device, computer equipment and storage medium. Background Art

[0002] Dubbo is a high-performance, lightweight open source Java RPC framework that provides high-performance proxy-based remote calling capabilities. Its services are granularized with interfaces, shielding developers from the underlying details of remote calls. It is a very popular microservice architecture on the Internet.

[0003] When the Dubbo service is changed, testers need to verify whether the business requirements themselves are correct and conduct overall testing in conjunction with upstream and downstream services. Usually, when developers test the business system, they modify the internal code to build a test environment for the upstream and downstream systems.

[0004] However, since writing code for the test environment requires high coding and system maintenance capabilities, and changing the code is an invasive behavior to the system, if the test environment is not designed well, it will not only fail to facilitate testing, but also cause testers to do useless work, making it difficult to improve the overall R&D work efficiency and wasting manpower costs. Summary of the Invention

[0005] The embodiments of the present invention provide a service dynamic testing method, apparatus, computer equipment and storage medium to solve the problem of low service testing efficiency when system services are changed.

[0006] A service dynamic testing method, comprising:

[0007] Obtaining test request parameters triggered by an upstream system, wherein the upstream system is the calling end of the downstream system;

[0008] Matching the test request parameters by calling a filter according to a preset object rule to obtain matching result information, wherein the preset object rule is a rule for matching the test request parameters generated according to the first configuration information of the upstream system and the second configuration information of the downstream system;

[0009] The test request parameters are processed according to the matching result information, and a test result is output.

[0010] A service dynamic testing device, comprising:

[0011] A parameter acquisition module, configured to acquire test request parameters triggered by an upstream system, wherein the upstream system is the calling end of the downstream system;

[0012] a parameter matching module, configured to match the test request parameters by calling a filter according to a preset object rule to obtain matching result information, wherein the preset object rule is a rule for matching the test request parameters generated according to the first configuration information of the upstream system and the second configuration information of the downstream system;

[0013] The parameter processing module is used to process the test request parameters according to the matching result information and output the test result.

[0014] A computer device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned service dynamic testing method when executing the computer program.

[0015] A computer-readable storage medium stores a computer program, which implements the steps of the above-mentioned service dynamic testing method when executed by a processor.

[0016] In the above-mentioned service dynamic testing method, apparatus, computer equipment, and storage medium, the server obtains test request parameters triggered by the upstream system, and matches the test request parameters by calling a filter based on the preset object rules generated for matching the test request parameters according to the first configuration information of the upstream system and the second configuration information of the downstream system. The corresponding test request parameters can be quickly found through the preset object rules, avoiding processing test request parameters that do not conform to the preset object rules, thereby improving the accuracy and efficiency of the service dynamic testing method. Based on whether the matching result information is a successful match or a failed match, the test request parameters are processed, and the first service test result and the second service test result corresponding to the matching result information are output, which can improve the processing efficiency of the test request parameters. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0018] Figure 1 This is a schematic diagram of an application environment of a service dynamic testing method according to an embodiment of the present invention;

[0019] Figure 2 This is a flow chart of a service dynamic testing method according to an embodiment of the present invention;

[0020] Figure 3is a flow chart of step S20 in the service dynamic testing method according to one embodiment of the present invention;

[0021] Figure 4 is a flow chart of step S21 in a service dynamic testing method according to an embodiment of the present invention;

[0022] Figure 5 This is a flow chart of a service dynamic testing method according to an embodiment of the present invention;

[0023] Figure 6 is a schematic diagram of a service dynamic testing device according to an embodiment of the present invention;

[0024] Figure 7 FIG. 1 is a schematic diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0025] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without inventive effort shall fall within the scope of protection of the present invention.

[0026] The service dynamic testing method provided in this application can be applied in Figure 1 In the application environment shown, the application environment includes a server, an upstream client, and a downstream client, wherein the server, the upstream client, and the downstream client are connected via a network, which can be a wired network or a wireless network. The upstream client and the downstream client specifically include but are not limited to various personal computers, laptops, smart phones, tablet computers, and portable wearable devices. The server can be implemented as an independent server or a server cluster composed of multiple servers. The server obtains the test request parameters triggered by the upstream system, and matches the test request parameters by calling a filter based on the preset object rules generated by the first configuration information of the upstream system and the second configuration information of the downstream system. The corresponding test request parameters can be quickly found through the preset object rules, avoiding the processing of test request parameters that do not meet the preset object rules, thereby improving the accuracy and efficiency of the service dynamic testing method. According to the matching result information, whether the match is successful or failed, the test request parameters are processed, and the first service test result and the second service test result corresponding to the matching result information are output, which can improve the processing efficiency of the test request parameters.

[0027] In one embodiment, if Figure 2 As shown, a service dynamic testing method is provided, which is applied in Figure 1The server in the example is used as an example to illustrate, specifically including steps S10 to S30, which are detailed as follows:

[0028] S10: Acquire test request parameters triggered by an upstream system, where the upstream system is the calling end of the downstream system.

[0029] The upstream system and the downstream system are system services in the system service framework, and the system service framework is the Dubbo service. The Dubbo service is a distributed service framework that can provide high-performance and transparent remote service call solutions. The test request parameters refer to the data parameter request issued by the upstream system to the downstream system, including data parameters and routing attributes, including those used to obtain downstream system data. The service test request parameters can be issued through an RPC request (Remote Procedure Call). The RPC request (Remote Procedure Call Protocol) is a remote call protocol that requests services from a remote computer program over the network. As an example, the test request parameters include: test request parameter A, test request parameter B, test request parameter C, test request parameter D, test request parameter E, and routing attributes from IP address a to IP address b.

[0030] S20: Match the test request parameters by calling the filter according to the preset object rule to obtain matching result information, wherein the preset object rule is a rule for matching the test request parameters generated according to the first configuration information of the upstream system and the second configuration information of the downstream system.

[0031] Among them, the preset object rules are rules for matching test request parameters generated based on the first configuration information of the upstream system and the second configuration information of the downstream system, including preset IP addresses and preset routing attributes, which are customized by the user. The first configuration information includes system information such as the system name, IP address, and port information of the upstream system. The second configuration information refers to system information including the system name, IP address, port information, test request parameters, and return parameters of the downstream system. A filter refers to a program that can filter the test request parameters generated when a system service is called. Optionally, the filter can be an RPC request filter that can match RPC requests.

[0032] Specifically, after obtaining the test request parameters triggered by the upstream system, the server uses filters to match the test request parameters according to the preset object rules, obtaining matching result information. Matching result information includes match success and match failure. If the test request parameters meet the preset object rules, the matching result information indicates a match success; if the test request parameters do not meet the preset object rules, the matching result information indicates a match failure.

[0033] As an example, when the preset routing attribute is data transmission from IP address a to IP address b, and when the routing attribute in the test request parameter is also data transmission from IP address a to IP address b, the preset object rule is met.

[0034] S30: Process the test request parameters according to the matching result information and output the test results.

[0035] The test result refers to the test data parameters corresponding to the test request parameters returned to the upstream system after processing the test request parameters. As an example, the test request parameters include: test request parameter A, test request parameter B, test request parameter C, test request parameter D, and test request parameter E. The test result includes: test parameter 1, test parameter 2, test parameter 3, test parameter 4, and test parameter 5.

[0036] The test results include a first service test result and a second service test result. The first service test result is the test data parameters corresponding to the test request parameters returned to the upstream system when the matching result information indicates a successful match. The second service test result is the test data parameters corresponding to the test request parameters returned to the upstream system when the matching result information indicates a failed match.

[0037] In this embodiment, test request parameters triggered by an upstream system are obtained, and preset object rules for matching the test request parameters are generated based on the first configuration information of the upstream system and the second configuration information of the downstream system. The test request parameters are matched by calling a filter. This allows for rapid retrieval of corresponding test request parameters through the preset object rules, avoiding processing of test request parameters that do not conform to the preset object rules, thereby improving the accuracy and efficiency of the service dynamic testing method. Based on whether the matching result information indicates a successful match or a failed match, the test request parameters are processed, and the first service test result and the second service test result corresponding to the matching result information are output, thereby improving the efficiency of processing the test request parameters.

[0038] In one embodiment, in step S20, the method for generating a preset object rule includes:

[0039] The second configuration information is changed to obtain downstream system change information, and a preset object rule is generated according to the first configuration information and the downstream system change information.

[0040] The downstream system change information refers to the system information obtained after the IP address in the second configuration information is changed.

[0041] Specifically, the server replaces the IP address in the second configuration information according to the preset IP address, obtains the downstream system change information, and forms the preset object rule according to the first configuration information of the upstream system and the downstream system change information.

[0042] Specifically, the server first copies the first configuration information and the second configuration information, and replaces the IP address in the copied second configuration information with a preset IP address to obtain downstream system change information. The preset IP address can be a user-defined IP address or a randomly generated IP address by the server. In this example, the server forms a preset object rule based on the first configuration information, the downstream system change information including the preset IP address, and the routing attributes for data transmission from the upstream system's IP address to the preset IP address.

[0043] As an example, in one application scenario, the system name A, IP address B, port information C, test request parameters, and return parameters of the downstream system are obtained based on the second configuration information. The system name a, IP address b, and port information c of the upstream system are obtained based on the first configuration information. The IP address B in the second configuration information is replaced with the preset IP address D to obtain the changed IP address D. The server forms a preset object rule based on the downstream changed system information: system name A, changed IP address D, port information C, test request parameters, and return parameters, and the first configuration information: system name a, IP address b, and port information c: IP address b, changed IP address D, and routing attributes from IP address b to changed IP address D.

[0044] In this embodiment, the server replaces the IP address in the second configuration information based on the preset IP address to obtain downstream system change information. Based on the first configuration information of the upstream system and the downstream system change information, a preset object rule is formed. The server can filter test request parameters based on the preset IP address in the preset object rule, quickly finding test request parameters that correspond to the preset object rule, avoiding processing test request parameters that do not conform to the preset object rule, and improving the accuracy and efficiency of the service dynamic testing method.

[0045] In one embodiment, if Figure 3 As shown, in step S20, matching the test request parameters by calling a filter according to a preset object rule includes:

[0046] S21: Obtain a configuration parameter template, encapsulate the configuration parameter template, and obtain a baffle service.

[0047] The configuration parameter template refers to a template used to replace the data generated during the system service call process. The baffle service refers to a service used to simulate the system service call object.

[0048] Specifically, a configuration parameter template is obtained. The configuration parameter template is obtained based on the data return parameters in the second configuration information. The data return parameters are the data obtained from the downstream system after the upstream system sends a test request parameter to the downstream system. In this example, the server obtains the fixed parameter information and variable parameter information in the data return parameters by parsing the data return parameters. Fixed parameter information is: the data parameter information that remains unchanged in the data returned by the downstream system each time. Variable parameter information is: the data parameter information that changes dynamically in the data returned by the downstream system each time. Based on the fixed parameter information and variable parameter information in the data return parameters, the configuration parameter template is obtained. The data return parameters can be dynamically generated through the configuration parameter template and the variable parameter information in each system call.

[0049] For example, in one application scenario, the server obtains the data return parameters in the second configuration information as follows: parameter 1, parameter 2, parameter C, parameter D, and parameter E.

[0050] Parse the parameters returned by the above data to obtain fixed parameter information: parameter 1 and parameter 2; obtain variable parameter information: parameter C, parameter D, parameter E. Based on the above fixed parameter information and variable parameter information, obtain the configuration parameter template: fixed parameter 1, fixed parameter 2, variable parameter C, variable parameter D, variable parameter E.

[0051] In this example, the server encapsulates the configuration parameter template to obtain the baffle service, publishes the baffle service, and registers it with the private registry.

[0052] Specifically, the baffle service is a test environment built using computer programming languages, primarily used to simulate and test system services. The private registry can store system configuration information, including a list of services available to downstream systems. It also maintains connections with both upstream and downstream systems, allowing it to monitor service changes in downstream systems and forward the latest service list to upstream systems. Furthermore, the private registry only allows access to system services that meet pre-defined criteria.

[0053] Specifically, the server encapsulates the created configuration parameter template through the open source code in the Dubbo service to obtain the baffle service. Furthermore, the obtained baffle service is published so that the baffle service can respond to the test request parameters and make calls to the downstream system. At the same time, the baffle service is registered with a private registration center. Furthermore, the private registration center can be the Zookeeper registration center in the Dubbo service. Among them, the Zookeeper registration center is an open source distributed application coordination service that provides functions including configuration maintenance, domain name services, distributed synchronization, group services, etc. According to the preset object rules, the system services that meet the preset object rules are registered with the Zookeeper registration center to achieve the purpose of isolating the system services and the baffle services from the test environment in the Dubbo service platform.

[0054] S22: According to the preset object rules and the baffle service, a filter is used to match the test request parameters to obtain matching result information.

[0055] A filter is a program used to filter test request parameters. Specifically, the preset object rule includes a preset IP address and preset routing attributes, which can filter RPC requests from upstream systems. The preset routing attributes can be user-defined. For example, if the preset routing attributes specify data transmission from IP address b to the changed IP address D, and the routing attributes in the RPC request also specify data transmission from IP address b to the changed IP address D, then the preset object rule is met.

[0056] Furthermore, the matching result information includes a match success and a match failure. When the routing attributes in the test request parameters are consistent with the preset routing attributes in the preset object rule, and the specific parameters in the test request parameters include the fixed parameter information in the configuration parameter template, the matching result information is a match success; when the specific parameters in the test request parameters do not contain the fixed parameter information in the configuration parameter template, the matching result information is a match failure.

[0057] For example, in one application scenario, the routing attributes in an RPC request are consistent with the preset routing attributes in a preset object rule, and the test request parameters in the RPC request include: parameter 1, parameter 2, parameter c, parameter d, and parameter e. The configuration parameter template includes: fixed parameter 1, fixed parameter 2, variable parameter C, variable parameter D, and variable parameter E. If the test request parameters include parameters A and B in the fixed parameter information, then the match result for the test request parameters in the RPC request is a successful match.

[0058] In one application scenario, the test request parameters in an RPC request include: parameter a, parameter b, parameter c, parameter d, and parameter e. The configuration parameter template includes: fixed parameter 1, fixed parameter 2, variable parameter C, variable parameter D, and variable parameter E. If the test request parameters do not contain any of the fixed parameter information, the matching result for the test request parameters in the RPC request is a match failure.

[0059] In this embodiment, system configuration information is obtained, and the system configuration information includes first configuration information and second configuration information, so that the upstream system and downstream system can be reconfigured through the first configuration information and the second configuration information, which is the basis for performing baffle service on the downstream system; the second configuration information is changed to obtain downstream system change information, and preset object rules are generated based on the first configuration information and the downstream system change information. The preset object rules can perform preliminary filtering on the test request parameters of the upstream system, thereby improving the accuracy and efficiency of the service dynamic testing method. A configuration parameter template is obtained, and the configuration parameter template is encapsulated to obtain a baffle service. The baffle service encapsulated by the configuration parameter template can process data through the baffle service to obtain service test results; the test request parameters triggered by the upstream system are obtained, and the test request parameters include test request parameters; according to the preset object rules and the configuration parameter template, a filter is used to match the test request parameters to obtain matching result information. By filtering the test request parameters, the accuracy and efficiency of the service dynamic testing method are improved.

[0060] In one embodiment, in step S30, processing the test request parameters using the baffle service according to the matching result information includes:

[0061] If the matching result information indicates a successful match, the configuration parameter template is replaced based on the test request parameters, the target test parameters are obtained, and the target test parameters are tested using the baffle service to obtain a first service test result.

[0062] The first service test result is the test data returned from the baffle service. The target test parameter refers to the object of the data test performed by the baffle service according to the user-defined test standard.

[0063] Specifically, when the filter matches the test request parameters successfully, the test request parameters are forwarded to the baffle service, and the baffle service responds, specifically by parameterizing the data provided by the downstream system obtained in real time through the Groovy language, and replacing the variable parameters in the configuration parameter template to obtain the target test parameters. Furthermore, the server instructs the baffle service to test the target test parameters according to the user-defined test standards to obtain the first service test results. Exemplarily, according to the test request parameters in the RPC request, the data 1, data 2, data c, data d, and data e provided by the downstream system are parameterized through the Groovy language to obtain parameter 1, parameter 2, parameter c, parameter d, and parameter e. The configuration parameter template in the baffle service: fixed parameter 1, fixed parameter 2, variable parameter C, variable parameter D, variable parameter E, is replaced. The target test parameters are: parameter 1, parameter 2, parameter c, parameter d, and parameter e. The server instructs the baffle service to test the target test parameters: parameter 1, parameter 2, parameter c, parameter d, parameter e according to the user-defined test standard, and obtains the first service test result: parameter 1, parameter 2, parameter c, parameter d, parameter e.

[0064] Furthermore, the preset object rule includes a preset routing attribute. If the matching result information indicates a successful match, the configuration parameter template is replaced with the test request parameter in the test request parameter to obtain the target test parameter, including:

[0065] If the matching result information is a successful match, the filter is used to filter the test request parameters based on the preset routing attributes. If the test request parameters are not filtered by the filter, the test request parameters in the test request parameters are replaced with the configuration parameter template to obtain the target test parameters.

[0066] Specifically, the server adopts the filter to filter and detect the test request parameters based on the preset routing attributes, which specifically includes the following steps: the filter can match the test request parameters according to the preset routing attributes in the preset object rules, and perform filtering and detection based on the matching results; after filtering and detecting the test request parameters based on the preset routing attributes, the test request parameters in the test request parameters are filtered based on the configuration parameter template.

[0067] As an example, the test request parameters include test request parameters, which include the IP address of the upstream system, the IP address of the downstream system, and the routing attributes of the service call process. In this example, the filter can match the test request parameters according to the preset routing attributes in the preset object rule, and perform filtering detection based on the matching results, specifically including: when the IP address and routing attributes in the test request parameters are inconsistent with the preset IP address and preset routing attributes in the preset object rule, instructing the filter to filter the test request parameters.

[0068] For example, in the simulation object template, the upstream system IP address is "Changed IP Address D," and the downstream system IP address is "IP Address B." Data is transmitted from IP Address B to "Changed IP Address D" based on user-defined routing attributes. The test request parameters in the RPC request include "IP Address B," "IP Address B," and "Data transmission from IP Address B to IP Address B." The RPC request is then validated by a filter. Because the IP address does not match the preset routing attributes, the RPC request is filtered.

[0069] As an example, filtering the test request parameters in the test request parameters based on the configuration parameter template specifically includes: when the test request parameter does not exist in the fixed parameter information in the configuration parameter template, instructing the filter to filter the test request parameter.

[0070] In one application scenario, the test request parameters in an RPC request include: parameter a, parameter b, parameter c, parameter d, and parameter e. The configuration parameter template includes: fixed parameter 1, fixed parameter 2, variable parameter C, variable parameter D, and variable parameter E. If the test request parameters do not contain any of the fixed parameter information, the RPC request is filtered.

[0071] If the test request parameters are not filtered by the filter, that is, they meet the requirements of the preset object rules and the configuration parameter template, then the configuration parameter template is replaced with the test request parameters in the test request parameters according to the configuration parameter template to obtain the target test parameters. Furthermore, the first service test result is obtained based on the target test parameters, and the first service test result is dynamically returned through the baffle service to implement dynamic testing of the service.

[0072] For example, in one application scenario, the routing attributes in the RPC request are consistent with the preset routing attributes in the preset object rule, and the test request parameters in the RPC request include: parameter 1, parameter 2, parameter c, parameter d, and parameter e. A configuration parameter template includes: fixed parameter 1, fixed parameter 2, variable parameter C, variable parameter D, and variable parameter E. The test request parameters include parameters A and B in the fixed parameter information. Therefore, if the test request parameters in the RPC request meet the requirements of the configuration parameter template, the configuration parameter template is replaced to obtain the target test parameters: fixed parameter 1, fixed parameter 2, parameter c, parameter d, and parameter e.

[0073] It should be noted that if the test request parameters are filtered by the filter, the test request parameters will not be processed.

[0074] In this embodiment, if the match result information indicates a successful match, the RPC request is forwarded to the baffle service through a filter. Based on the test request parameters and the configuration parameter template in the RPC request, the configuration parameter template is replaced using the Groovy language to obtain the first service test result. By filtering and detecting the test request parameters, interference from invalid test request parameters is avoided, improving the reliability of service testing.

[0075] In one embodiment, in step S30, the process of processing the test request parameters using the baffle service according to the matching result information to obtain the service test result further includes:

[0076] If the matching result information is a match failure, the original routing attributes of the downstream system are updated according to the second configuration information to obtain the changed routing attributes, and the baffle service is used to forward the test request parameters to the downstream system corresponding to the changed routing attributes to obtain the second service test result.

[0077] The original routing attributes refer to the routing attributes of the upstream system calling the downstream system. The modified routing attributes refer to the data transmission from the upstream system to the baffle service and then to the downstream system. The second service test result is the data return parameter fed back by the modified routing attributes from the downstream system.

[0078] Specifically, when the filter's matching result for the test request parameters indicates a match failure, the preset routing attributes are updated based on the IP address in the second configuration information to obtain a modified routing attribute; and based on the modified routing attribute, a second service test result of the downstream system is obtained. For example, when the filter's matching result for the RPC request indicates a match failure, the downstream system IP address is B, the baffle service IP address is the modified IP address D, and the upstream system IP address is b, the modified routing attribute is to transmit data from IP address b, to the modified IP address D, and then to IP address B, and the second service test result is obtained from the downstream system.

[0079] In this embodiment, if the matching result information indicates a match failure, the original routing attributes are updated according to the second configuration information to obtain modified routing attributes. The second service test result of the downstream system is then obtained through the baffle service. By setting routing attributes and publishing the baffle service, there is no code intrusion into the system service, ensuring higher reliability for system service testing. Furthermore, by filtering RPC requests, costs are reduced and efficiency is improved.

[0080] In one embodiment, if Figure 4 As shown, in S21, the method for obtaining the first configuration information of the upstream system and the second configuration information of the downstream system includes:

[0081] S211: Obtaining the Facade package generated when the upstream system calls the downstream system from the system service framework. The Facade package is data information generated when the downstream system calls the upstream system in the system service framework.

[0082] Specifically, the Facade package generated by a historical service call is the data generated when a downstream system in the system service framework calls an upstream system. This package includes the system name, IP address, port information, test request parameters, and return parameters. Because the Facade package is directly exposed in the system service framework, it can be directly obtained from the framework.

[0083] S212: Parse the Facade package to obtain first configuration information of the upstream system and second configuration information of the downstream system.

[0084] Specifically, after obtaining the Facade package, the Facade package is parsed to obtain the first configuration information and the second configuration information in the Facade package. For example, the system name, IP address, port information, test request parameters, and return parameters of the upstream system are obtained; and the system name, IP address, port information, test request parameters, and return parameters of the downstream system are obtained.

[0085] For example, the Facade package generated when the upstream system calls the downstream system is obtained from the Dubbo system service, and the system name A, IP address B, port information C, test request parameters, and return parameters of the downstream system (i.e., user system service) are parsed from the Facade package; the system name a, IP address b, and port information c of the upstream system (i.e., order system service) are obtained.

[0086] In this embodiment, a facade package generated by historical service calls is first obtained from the system service framework. The facade package is then parsed to obtain first and second configuration information. By setting the first and second configuration information in the form of a facade package, the service information of the system under test can be managed, thereby improving the reliability of the system service information.

[0087] In one embodiment, if Figure 5 As shown, after S21, after receiving the baffle service, including:

[0088] S2101: Obtain a baffle release request, where the baffle release request includes baffle information corresponding to the baffle service, and the baffle information includes a change routing attribute corresponding to the downstream system.

[0089] Optionally, the baffle release request can be obtained by triggering the baffle release request via a trigger button or trigger link on the client display interface, or by inputting a baffle release instruction on the client. Preferably, the baffle release request can be obtained by triggering the baffle release request via a trigger button or trigger link on the client display interface, facilitating test management of the baffle service. The baffle release request includes baffle information corresponding to the baffle service, and the baffle information includes change routing attributes corresponding to the downstream system. Using the change routing attributes corresponding to the downstream system, simulation testing of the test object using the baffle service is implemented.

[0090] S2102: Based on the baffle publishing request, when the baffle publishing request meets the preset object rules, the baffle service and the changed routing attributes are uploaded to the private registration center.

[0091] Specifically, based on the baffle release request, when the change routing attributes corresponding to the downstream system in the baffle release request meet the preset object rules, the baffle service and change routing attributes corresponding to the downstream system will be uploaded to the private registration center, and the private registration center will be instructed to publish the baffle service to the corresponding system service, so that the corresponding system service can interact with data through the baffle service.

[0092] For example, after obtaining the baffle publishing request, the changed routing attribute in the baffle publishing request is IP address b to the changed IP address D for data transmission at both ends, which is consistent with the preset routing attribute IP address b to the changed IP address D of the preset object rule. Then, the baffle service and the changed routing attribute are sent to the Zookeeper registration center, and the Zookeeper registration center publishes the baffle service corresponding to the changed IP address D so that the baffle service can receive the corresponding system service RPC request.

[0093] It should be noted that when a baffle closing request is received, it can be understood that the baffle closing request can be obtained by triggering a baffle release request through a trigger button or trigger link on the client display interface. The baffle service and change routing attributes in the private registration are cleared to implement the management of the baffle service.

[0094] In this embodiment, a baffle release request is received via a trigger button or trigger link on the client display interface. If the baffle release request meets the preset object rules, the baffle service and the changed routing attributes are uploaded to the private registration center, and the private registration center is instructed to publish the baffle service. This allows testers to manage the baffle service in a timely manner and conduct baffle service testing on system services based on actual user needs, thereby improving applicability.

[0095] It should be understood that the order of execution of the steps in the above embodiments does not necessarily mean the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0096] In one embodiment, a service dynamic testing device is provided, which corresponds to the service dynamic testing method in the above embodiment. Figure 6 As shown, the service dynamic testing device includes: a parameter acquisition module 10, a parameter matching module 20, and a parameter processing module 30. The detailed description of each functional module is as follows:

[0097] A parameter acquisition module 10 is used to acquire test request parameters triggered by an upstream system, wherein the upstream system is the calling end of the downstream system;

[0098] a parameter matching module 20, configured to match the test request parameters by calling a filter according to a preset object rule to obtain matching result information, wherein the preset object rule is a rule for matching the test request parameters generated according to the first configuration information of the upstream system and the second configuration information of the downstream system;

[0099] The parameter processing module 30 is configured to process the test request parameters according to the matching result information and output a test result.

[0100] Furthermore, the parameter matching module 20 includes:

[0101] The information change submodule is used to change the second configuration information, obtain downstream system change information, and generate a preset object rule according to the first configuration information and the downstream system change information.

[0102] Furthermore, the parameter matching module 20 further includes:

[0103] The template acquisition submodule is used to obtain the configuration parameter template, encapsulate the configuration parameter template, and obtain the baffle service;

[0104] The filter submodule is used to match the test request parameters using filters according to preset object rules and baffle services to obtain matching result information.

[0105] Furthermore, the parameter processing module 30 includes:

[0106] The matching success submodule is used to replace the configuration parameter template based on the test request parameters when the matching result information is a successful match, obtain the target test parameters, use the baffle service to test the target test parameters, and obtain the first service test result.

[0107] Furthermore, the parameter processing module 30 further includes:

[0108] The matching failure submodule is used to update the original routing attributes of the downstream system according to the second configuration information when the matching result information is a matching failure, obtain the changed routing attributes, and use the baffle service to forward the test request parameters to the downstream system corresponding to the changed routing attributes to obtain the second service test result.

[0109] Furthermore, the parameter matching module 20 further includes:

[0110] The data acquisition submodule is used to parse the Facade package to obtain the first configuration information of the upstream system and the second configuration information of the downstream system;

[0111] The data parsing submodule is used to parse the Facade package to obtain the first configuration information of the upstream system and the second configuration information of the downstream system.

[0112] Furthermore, the parameter matching module 20 further includes:

[0113] A baffle release module is used to obtain a baffle release request, which includes baffle information corresponding to the baffle service, and the baffle information includes a change routing attribute corresponding to the downstream system;

[0114] The service upload module is used to upload the baffle service and the changed routing attributes to the private registration center based on the baffle publishing request when the baffle publishing request meets the preset object rules.

[0115] For the specific definition of the service dynamic testing device, please refer to the definition of the service dynamic testing method above, which will not be repeated here. The various modules in the above-mentioned service dynamic testing device can be implemented in whole or in part by software, hardware and their combination. The above-mentioned modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0116] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 7 As shown. The computer device includes a processor, a memory, a network interface, and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a service dynamic testing method is implemented.

[0117] In one embodiment, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the service dynamic testing method described in the above embodiment, such as steps S10 to S30, are implemented. Alternatively, when the processor executes the computer program, the functions of the modules / units of the service dynamic testing apparatus described in the above embodiment, such as modules 10 to 30, are implemented. To avoid repetition, these are not further described here.

[0118] In one embodiment, a computer-readable storage medium is provided, storing a computer program thereon. When executed by a processor, the computer program implements the service dynamic testing method in the above-described method embodiment, or when executed by a processor, the computer program implements the functions of each module / unit in the service dynamic testing device in the above-described device embodiment. To avoid repetition, the details are not repeated here.

[0119] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0120] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0121] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A service dynamic testing method, characterized in that: include: Obtaining test request parameters triggered by an upstream system, wherein the upstream system is the calling end of the downstream system; Matching the test request parameters by calling a filter according to a preset object rule to obtain matching result information, wherein the preset object rule is a rule for matching the test request parameters generated according to the first configuration information of the upstream system and the second configuration information of the downstream system, including a preset IP address and a preset routing attribute; the first configuration information refers to system information including the system name, IP address, and port information of the upstream system; the second configuration information refers to system information including the system name, IP address, port information, test request parameters, and return parameters of the downstream system; Processing the test request parameters according to the matching result information and outputting the test results; The matching of the test request parameters by calling a filter according to a preset object rule includes: Obtain a configuration parameter template, encapsulate the configuration parameter template to obtain a baffle service, and register the baffle service with a private registration center, which is the Zookeeper registration center in the Dubbo service; According to the preset object rule and the baffle service, the filter is used to match the test request parameters to obtain matching result information; The processing of the test request parameters according to the matching result information includes: If the matching result information indicates a successful match, the configuration parameter template is replaced based on the test request parameters to obtain target test parameters, and the target test parameters are tested using the baffle service to obtain a first service test result; wherein, when the routing attributes in the test request parameters are consistent with the preset routing attributes in the preset object rule, and the specific parameters in the test request parameters include the fixed parameter information in the configuration parameter template, then the matching result information indicates a successful match; If the matching result information is a matching failure, the original routing attributes of the downstream system are updated according to the second configuration information to obtain the changed routing attributes, and the baffle service is used to forward the test request parameters to the downstream system corresponding to the changed routing attributes to obtain the second service test result; wherein, when the specific parameters in the test request parameters do not exist in the fixed parameter information in the configuration parameter template, the matching result information is a matching failure.

2. The service dynamic testing method according to claim 1, wherein: The method for generating the preset object rule includes: The second configuration information is changed to obtain downstream system change information, and a preset object rule is generated according to the first configuration information and the downstream system change information.

3. The service dynamic testing method according to claim 1, wherein: The method for acquiring the first configuration information of the upstream system and the second configuration information of the downstream system includes: Obtaining, from the system service framework, a Facade package generated when the upstream system calls the downstream system, wherein the Facade package is data information generated during the process of the downstream system calling the upstream system in the system service framework; The Facade package is parsed to obtain the first configuration information of the upstream system and the second configuration information of the downstream system.

4. The service dynamic testing method according to claim 1, wherein: After obtaining the baffle service, the method further includes: Obtaining a baffle publishing request, the baffle publishing request including baffle information corresponding to the baffle service, the baffle information including the changed routing attribute corresponding to the downstream system; Based on the baffle publishing request, when the baffle publishing request meets the preset object rule, the baffle service and the change routing attribute are uploaded to a private registration center.

5. A service dynamic testing device, characterized in that: The service dynamic testing device comprises: A parameter acquisition module, configured to acquire test request parameters triggered by an upstream system, wherein the upstream system is the calling end of the downstream system; a parameter matching module, configured to match the test request parameters by calling a filter according to a preset object rule to obtain matching result information, wherein the preset object rule is a rule for matching the test request parameters generated according to the first configuration information of the upstream system and the second configuration information of the downstream system, including a preset IP address and a preset routing attribute; the first configuration information refers to system information including the system name, IP address, and port information of the upstream system; the second configuration information refers to system information including the system name, IP address, port information, test request parameters, and return parameters of the downstream system; A parameter processing module, configured to process the test request parameters according to the matching result information and output a test result; The parameter matching module is further configured to obtain a configuration parameter template, encapsulate the configuration parameter template to obtain a baffle service, and register the baffle service with a private registration center, which is a Zookeeper registration center in the Dubbo service; match the test request parameters using the filter according to the preset object rule and the baffle service to obtain matching result information; The parameter processing module is also used to replace the configuration parameter template based on the test request parameters if the matching result information is a successful match, obtain the target test parameters, and use the baffle service to test the target test parameters to obtain a first service test result; wherein, when the routing attributes in the test request parameters are consistent with the preset routing attributes in the preset object rules, and the specific parameters in the test request parameters include the fixed parameter information in the configuration parameter template, the matching result information is a successful match; if the matching result information is a failed match, the original routing attributes of the downstream system are updated according to the second configuration information to obtain the changed routing attributes, and the baffle service is used to forward the test request parameters to the downstream system corresponding to the changed routing attributes to obtain a second service test result; wherein, when the specific parameters in the test request parameters do not contain the fixed parameter information in the configuration parameter template, the matching result information is a failed match.

6. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the service dynamic testing method according to any one of claims 1 to 4 is implemented.

7. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the service dynamic testing method according to any one of claims 1 to 4 is implemented.

Images