Test method and device based on micro-service, electronic equipment and program product
By building simulated microservices in a microservice architecture, dynamically routing transaction requests and generating predefined response results, the problem of low testing efficiency caused by unstable external interfaces is solved, testing efficiency and accuracy are improved, maintenance costs are reduced, and testing strategies are optimized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-26
- Publication Date
- 2026-04-10
AI Technical Summary
In software development, especially in the testing of financial trading systems, the instability of external interface environments or the non-reusability of transaction data can lead to low testing efficiency.
By building simulated microservices in a microservice architecture, and using configuration data tables and a registry center, transaction requests are dynamically routed to the simulated microservices, predefined response results are generated, and the results are compared with the expected results to determine the test results.
It improved testing efficiency and accuracy, reduced maintenance costs, ensured the determinism of the testing environment and software quality, achieved automated test evaluation, and optimized the overall testing strategy.
Smart Images

Figure CN121833478A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application applies to the field of testing and the field of financial technology, and in particular, relates to a micro-service-based testing method and device, an electronic device and a program product. BACKGROUND
[0002] In the process of software development, especially in the testing of financial transaction systems, frequent challenges are encountered due to unstable external interface environments or non-reusable transaction data. These external interfaces may involve third-party services, bank back-end systems or other remote resources, whose response times and results are often difficult to predict and control, especially in high-concurrency or multi-round regression testing. This uncertainty becomes a key factor restricting the efficiency and accuracy of testing.
[0003] In the prior art, to solve the above problems, the method usually adopted is to implement a mock micro-service (Mock) technology at the code level, that is, to replace the real external service with a simulated object to control its response behavior. However, the implementation of Mock often requires direct modification of project code, introducing additional classes or methods, which not only increases the development and testing manpower cost, but also may damage the original code structure, affecting the neatness of the code base and subsequent version management.
[0004] In view of the problem in the related art that the process of testing a transaction request calling an external service is low in efficiency due to unstable external services or non-reproducible transaction requests, no effective solution has been proposed so far. SUMMARY
[0005] The main purpose of the present application is to provide a micro-service-based testing method, device, electronic device and program product to at least solve the problem in the prior art that the process of testing a transaction request calling an external service is low in efficiency due to unstable external services or non-reproducible transaction requests.
[0006] To achieve the above purpose, according to one aspect of the present application, a micro-service-based testing method is provided, which comprises: upon detecting a transaction request to be tested, determining an external service to be called by the transaction request according to transaction information of the transaction request to obtain a target external service; forwarding the transaction request to a target micro-service based on a configuration data table, wherein the configuration data table stores interface information of external services, and the target micro-service is a simulated micro-service corresponding to the target external service; generating a response result based on the interface information of the external service and the transaction request through the target micro-service; and determining a test result of the transaction request according to the response result.
[0007] Furthermore, before forwarding the transaction request to the target microservice based on the configuration data table, the method further includes: collecting the interface information of the external service to be called, and generating the configuration data table based on the interface information of the external service, wherein the interface information includes at least: service code, version number, and response information; creating a simulated microservice corresponding to the external service based on the interface information of the external service; generating the identification information of the simulated microservice, and registering it in the registry center based on the identification information, so as to simulate the response result returned by the external service through the simulated microservice, wherein the registry center is a component in the microservice architecture used to maintain microservice information.
[0008] Further, after registering in the registry center based on the identification information, the method includes: adding the environment configuration file of the simulated microservice to the external service; modifying the service information of the external service in the registry center and modifying the configuration information of the external service in the configuration center, wherein the configuration center stores the configuration information of the external service; running the simulated microservice based on the environment configuration file of the simulated microservice, so that when the transaction request calling the external service is detected, the transaction request is forwarded to the simulated microservice corresponding to the external service.
[0009] Furthermore, after generating the configuration data table based on the interface information of the external service, the method further includes: determining the data processing object corresponding to the simulated microservice based on the interface information of the external service, wherein the data processing object is used to process the received data based on preset code; adding a target attribute to the configuration data table and determining the target attribute value based on the data processing object corresponding to the simulated microservice; and updating the configuration data table based on the target attribute value.
[0010] Further, generating a response result through the target microservice based on the interface information of the external service and the transaction request includes: querying the configuration data table according to the interface information of the target external service to obtain a query result, wherein the query result includes response information corresponding to the target external service; when the response information only contains static response information, generating the response result through the target microservice based on the static response information; and when the response information contains static response information and the target attribute value, generating the response result through the target microservice based on the target attribute value, the transaction request, and the static response information.
[0011] Furthermore, generating the response result through the target microservice based on the target attribute value, the transaction request, and the static response information includes: transmitting the transaction request and the static response information to the target data processing object corresponding to the target attribute value through the target microservice; and processing the transaction information of the transaction request and the static response information through the target data processing object to obtain the response result.
[0012] Further, determining the data processing object corresponding to the simulated microservice based on the interface information of the external service includes: determining input data and output data based on the interface information of the external service; determining data processing operations based on the test requirements and / or business execution logic of the transaction request; and constructing the data processing object of the simulated microservice corresponding to the external service based on the input data, the output data, and the data processing operations.
[0013] To achieve the above objectives, according to another aspect of this application, a microservice-based testing apparatus is provided. The apparatus includes: a first determining unit, configured to, upon detecting a transaction request to be tested, determine the external service that the transaction request needs to invoke based on the transaction information of the transaction request, thereby obtaining the target external service; a forwarding unit, configured to forward the transaction request to the target microservice based on a configuration data table, wherein the configuration data table stores interface information of the external service, and the target microservice is a simulated microservice corresponding to the target external service; a first generating unit, configured to generate a response result through the target microservice based on the interface information of the external service and the transaction request; and a second determining unit, configured to determine the test result of the transaction request based on the response result.
[0014] Furthermore, the apparatus further includes: a third generation unit, used to collect interface information of the external service to be called before forwarding the transaction request to the target microservice based on the configuration data table, and generate a configuration data table based on the interface information of the external service, wherein the interface information includes at least: service code, version number, and response information; a creation unit, used to create a simulated microservice corresponding to the external service based on the interface information of the external service; and a registration unit, used to generate identification information of the simulated microservice and register it in the registration center based on the identification information, so as to simulate the response result returned by the external service through the simulated microservice, wherein the registration center is a component in the microservice architecture used to maintain microservice information.
[0015] Furthermore, the apparatus further includes: an adding unit, configured to add an environment configuration file of a simulated microservice to an external service after registering in a registry center based on identification information; a modifying unit, configured to modify the service information of the external service in the registry center and the configuration information of the external service in the configuration center, wherein the configuration center stores the configuration information of the external service; and a running unit, configured to run the simulated microservice based on the environment configuration file of the simulated microservice, so that when a transaction request is detected to call an external service, the transaction request is forwarded to the simulated microservice corresponding to the external service.
[0016] Furthermore, the device further includes: a third determining unit, configured to determine the data processing object corresponding to the simulated microservice based on the interface information of the external service after generating the configuration data table based on the interface information of the external service, wherein the data processing object is used to process the received data based on preset code; a fourth determining unit, configured to add a target attribute to the configuration data table and determine the target attribute value based on the data processing object corresponding to the simulated microservice; and an updating unit, configured to update the configuration data table based on the target attribute value.
[0017] Further, the first generation unit includes: a query subunit, used to query the configuration data table based on the interface information of the target external service to obtain a query result, wherein the query result includes the response information corresponding to the target external service; a first generation subunit, used to generate a response result based on the static response information through the target microservice when the response information only contains static response information; and a second generation subunit, used to generate a response result based on the target attribute value, transaction request, and static response information through the target microservice when the response information contains both static response information and target attribute value.
[0018] Furthermore, the second generation subunit includes: a transmission module, used to transmit transaction requests and static response information to the target data processing object corresponding to the target attribute value through the target microservice; and a processing module, used to process the transaction information and static response information of the transaction request through the target data processing object to obtain a response result.
[0019] Furthermore, the third determining unit includes: a first determining subunit, used to determine input data and output data based on the interface information of the external service; a second determining subunit, used to determine data processing operations based on the test requirements of the transaction request and / or business execution logic; and a constructing subunit, used to construct a data processing object of the simulated microservice corresponding to the external service based on the input data, output data, and data processing operations.
[0020] To achieve the above objectives, according to one aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements any of the microservice-based testing methods described above, and when executed by a processor, implements the steps of the microservice-based testing methods described in various embodiments of this application.
[0021] To achieve the above objectives, according to one aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including stored computer instructions, wherein, when the computer instructions are executed by a processor, the microservice-based testing method described in any one of the above claims is implemented.
[0022] To achieve the above objectives, according to one aspect of this application, an electronic device is provided, including one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the microservice-based testing method described in any of the above.
[0023] In this embodiment, when a transaction request to be tested is detected, the external service that the transaction request needs to call is determined based on the transaction information of the transaction request, thus obtaining the target external service; the transaction request is forwarded to the target microservice based on a configuration data table, wherein the configuration data table stores the interface information of the external service, and the target microservice is a simulated microservice corresponding to the target external service; the target microservice generates a response result based on the interface information of the external service and the transaction request; and the test result of the transaction request is determined based on the response result. This solves the technical problem of low testing efficiency caused by the instability of the external service or the non-repeatability of the transaction request during the testing of a transaction request that calls an external service.
[0024] By configuring a dynamic routing mechanism for the data tables and building simulated microservices, transaction requests can be accurately forwarded to the corresponding simulated microservices during the detection phase. This achieves the technical effect of shielding against external unstable factors and ensuring the determinism of the test environment, further improving testing efficiency and reducing maintenance costs. Simultaneously, by having simulated microservices generate predefined response results based on the detailed information of transaction requests and comparing them with expected results, the test results accurately reflect the execution status of the transaction logic. This achieves the technical effect of verifying the integrity of transaction functions, ensuring software quality, realizing automated test evaluation, improving the standardization and objectivity of the testing process, and ultimately optimizing the overall testing strategy and accelerating the software development cycle. Attached Figure Description
[0025] 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:
[0026] Figure 1 This is a hardware structure block diagram of a mobile terminal for a microservice-based testing method according to an embodiment of the present invention.
[0027] Figure 2 This is a flowchart of an optional microservice-based testing method provided according to an embodiment of this application;
[0028] Figure 3 This is a flowchart illustrating an optional model-based microservice testing method provided according to an embodiment of this application;
[0029] Figure 4 This is a structural block diagram of a microservice-based testing device provided according to an embodiment of this application. Detailed Implementation
[0030] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.
[0031] 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.
[0032] 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 for the embodiments of this application 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.
[0033] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, collected data, used data, generated data, processed data, etc.) and the data (including but not limited to data used for analysis, stored data, displayed data, collected information, used information, generated information, processed information, etc.) are all 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 the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse. For example, this system has interfaces with relevant users or organizations, providing users with corresponding operation entry points for users 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.
[0034] As described in the background section, in order to solve the problem of low testing efficiency caused by the instability of external services or the non-repeatability of transaction requests during the testing of transaction requests calling external services, embodiments of this application provide a microservice-based testing method.
[0035] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.
[0036] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a microservice-based testing method according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. 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 mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.
[0037] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the microservice-based testing method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and 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 mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.
[0038] This embodiment provides a microservice-based testing method that runs on a mobile terminal, computer terminal, or similar computing device. 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. Also, 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.
[0039] Figure 2 This is a flowchart of an optional microservice-based testing method provided according to embodiments of this application. For example... Figure 2 As shown, the method includes the following steps:
[0040] Step S201: When a transaction request to be tested is detected, the external service that the transaction request needs to call is determined based on the transaction information of the transaction request, and the target external service is obtained.
[0041] In this embodiment, the execution entity of this solution is a testing system that integrates a simulated microservice component. This component, based on pre-defined configuration information in the database, calls the simulated microservice, generates corresponding simulated response results, and responds to the transaction requests to be tested, thereby supporting the establishment of a stable testing environment and functional verification.
[0042] In the transaction testing process, when a transaction request is received, the request is parsed to extract transaction information, including but not limited to the service code and version number. Subsequently, based on the extracted transaction information, a pre-configured mapping relationship is queried to identify the specific external service that the transaction request needs to call, i.e., the target external service.
[0043] Step S202: Based on the configuration data table, the transaction request is forwarded to the target microservice. The configuration data table stores the interface information of the external service, and the target microservice is a simulated microservice corresponding to the target external service.
[0044] In this embodiment, after determining the target external service that the transaction request to be tested needs to invoke, the request will no longer be sent to the actual external service address. Instead, according to the guidance in the configuration data table, the transaction request will be redirected to the target simulated microservice. Here, the target microservice specifically refers to a microservice that has been built to simulate the behavior of a specific external service. After receiving the request, the target simulated microservice obtains predefined response data and then simulates the return from the external service, completing the entire transaction request testing process. This step ensures the controllability of external service calls during the testing process, improves testing efficiency and accuracy, and avoids data risks and environmental instability factors in a real-world environment.
[0045] Step S203: Generate a response result based on the interface information and transaction request of the external service through the target microservice.
[0046] In this embodiment, after receiving a transaction request forwarded based on external service interface information, the target microservice queries a configuration data table to obtain a preset response mode based on specific parameters in the request, such as the service code and version number. The configuration data table stores response information related to the external service interface, including static or dynamic data to be returned under different service codes and version conditions. The target microservice uses this information, combined with the specific content of the transaction request, to generate a response result. The generated response result is then sent back to the system that initially issued the transaction request, simulating the real response behavior of the external service. This ensures that transaction processing in the test environment can be completed smoothly, while maintaining the accuracy of the test and the stability of the environment.
[0047] Step S204: Determine the test result of the transaction request based on the response result.
[0048] In this embodiment, the response generated by the target microservice is returned to the original system that initiated the transaction request, and the response is processed as feedback from the external service call. Based on the content of the response, the system evaluates its consistency with the expected result to determine whether the processing of the transaction request has achieved the predetermined test objective. If the response matches the expected transaction logic, the test result is considered successful, indicating that the transaction request can be executed correctly in the simulated environment. Conversely, if the response does not match the expectation, the test result is marked as a failure, indicating that further debugging is needed.
[0049] In summary, the microservice-based testing method provided in this application, upon detecting a transaction request to be tested, determines the external service that the transaction request needs to call based on the transaction information of the transaction request, thus obtaining the target external service; forwards the transaction request to the target microservice based on a configuration data table, wherein the configuration data table stores the interface information of the external service, and the target microservice is a simulated microservice corresponding to the target external service; generates a response result through the target microservice based on the interface information of the external service and the transaction request; and determines the test result of the transaction request based on the response result. This solves the problem of low testing efficiency in related technologies during the testing of transaction requests that call external services, due to the instability of the external service or the non-repeatability of the transaction request.
[0050] By configuring a dynamic routing mechanism for the data tables and building simulated microservices, transaction requests can be accurately forwarded to the corresponding simulated microservices during the detection phase. This achieves the technical effect of shielding against external unstable factors and ensuring the determinism of the test environment, further improving testing efficiency and reducing maintenance costs. Simultaneously, by having simulated microservices generate predefined response results based on the detailed information of transaction requests and comparing them with expected results, the test results accurately reflect the execution status of the transaction logic. This achieves the technical effect of verifying the integrity of transaction functions, ensuring software quality, realizing automated test evaluation, improving the standardization and objectivity of the testing process, and ultimately optimizing the overall testing strategy and accelerating the software development cycle.
[0051] Optionally, in the microservice-based testing method provided in this application embodiment, before forwarding the transaction request to the target microservice based on the configuration data table, the method further includes: collecting the interface information of the external service to be called, and generating a configuration data table based on the interface information of the external service, wherein the interface information includes at least: service code, version number, and response information; creating a simulated microservice corresponding to the external service based on the interface information of the external service; generating the identification information of the simulated microservice, and registering it in the registry center based on the identification information, so as to simulate the response result returned by the external service through the simulated microservice, wherein the registry center is a component in the microservice architecture used to maintain microservice information.
[0052] In this embodiment, to build a stable and efficient test environment that can simulate external service responses, the first step is to comprehensively collect information about the external service interfaces. This process involves identifying and recording details of all external services that may be invoked in the transaction requests to be tested. This primarily includes the service code, which is the unique identifier for the service; the version number, used to distinguish different iterations of the service; and the response information, i.e., the data structure and content that the external service should return under normal circumstances. This meticulous collection and organization ensures the high accuracy of subsequent simulated microservice design and configuration.
[0053] Then, based on the collected interface information, a configuration data table is constructed. The purpose of this configuration data table is to centrally store and manage the key attributes of all external services and their corresponding simulated response data, facilitating the simulation microservices to quickly find and apply the correct response pattern during runtime. The core of this step is ensuring that the structure of the configuration data table supports rapid retrieval and accurate matching to meet the needs of the simulated microservices in processing transaction requests in real time.
[0054] Secondly, a dedicated simulated microservice was created based on the interface information of the external service. This simulated microservice was designed for high fidelity; its main function was to receive transaction requests, parse the service code and version number, search for matching response information in the configuration data table, and then return the result according to the response format of the real service. The development process of the simulated microservice not only required logical simulation but also considered performance optimization and reliability to ensure stable performance under high-concurrency testing scenarios.
[0055] Finally, to ensure that the simulated microservices can be correctly identified and invoked by the test environment, unique identification information was generated for each, and this information was used to register them in the registry center of the microservice architecture. The registry center is a key component of the microservice architecture, responsible for maintaining information on all online microservices, including their location, status, and list of available services. By registering the simulated microservices in the registry center, the test system can dynamically discover and invoke them, replacing the original call path to external real services and achieving closed-loop execution of transaction requests in the test environment.
[0056] Through the above steps, the goal of flexibly controlling external service calls via configuration and registration mechanisms is achieved without modifying the original transaction system code, significantly enhancing the flexibility and efficiency of testing. Furthermore, since the simulated microservice responses are entirely based on predefined response information in the configuration data table, test interruptions caused by unstable external service environments or non-reusable data are avoided, ensuring the predictability and consistency of test results and greatly promoting the optimization of software development and testing processes.
[0057] Optionally, in the microservice-based testing method provided in this application embodiment, after registering in the registry center based on the identification information, the method includes: adding an environment configuration file for a simulated microservice to the external service; modifying the service information of the external service in the registry center and modifying the configuration information of the external service in the configuration center, wherein the configuration center stores the configuration information of the external service; running the simulated microservice based on the environment configuration file of the simulated microservice, so that when a transaction request is detected to call the external service, the transaction request is forwarded to the simulated microservice corresponding to the external service.
[0058] In this embodiment, to ensure the stability and efficiency of the test process and prevent it from being affected by fluctuations in the external service environment, an environment configuration file for the simulated microservice is first integrated. The addition of this file enables the transaction system to identify and load specific configurations of the simulated microservice, including key information such as the network path pointing to the simulated microservice and its service identifier. This allows the system to invoke the simulated microservice during testing, bypassing the actual invocation of external services and avoiding test failures or delays caused by the instability of external services.
[0059] Then, the service information of external services is updated in the registry center so that transaction requests calling external services can be forwarded to the simulated microservices. By modifying the service information of the transaction system, the registry center can correctly maintain the association between transaction requests and simulated microservices, ensuring that the latest information of the simulated microservices can be automatically obtained and applied when processing transaction requests.
[0060] Secondly, in addition to modifying the registry center, the configuration information of the trading system also needs to be revised in the configuration center. The configuration center is another crucial component of the microservice architecture, used to centrally store and manage the configuration parameters of all microservices. By dynamically adjusting the trading system configuration, it can, at runtime, select simulated microservices to replace calls to external service interfaces based on the current environment configuration file, rather than directly calling external services.
[0061] Finally, the simulated microservice is run based on the environment configuration file of the simulated microservice to ensure that it is in a callable state. When a transaction request to call an external service is detected in the test environment, the transaction request can be redirected to the simulated microservice according to the updated service information and configuration information. The simulated microservice then generates and returns a simulated external service response according to the preset response logic, completing the closed-loop test of the transaction request.
[0062] Through the above steps, the simulation and control of external service calls can be achieved by updating environment configuration and registration information without affecting the original code logic of the transaction system, greatly improving the flexibility and efficiency of testing. At the same time, this method avoids the increased version management complexity and maintenance costs associated with directly modifying code in traditional mock microservices, maintaining the purity and stability of the business source code and providing strong support for software testing and continuous integration.
[0063] Optionally, in the microservice-based testing method provided in this application embodiment, after generating a configuration data table based on the interface information of the external service, the method further includes: determining a data processing object corresponding to the simulated microservice based on the interface information of the external service, wherein the data processing object is used to process the received data based on preset code; adding a target attribute to the configuration data table and determining the target attribute value based on the data processing object corresponding to the simulated microservice; and updating the configuration data table based on the target attribute value.
[0064] In this embodiment, to enhance the functionality of the simulated microservice and enable it to more flexibly respond to diverse testing needs, the data processing object corresponding to the simulated microservice is first determined based on the collected external service interface information. Here, the data processing object refers to a Java object, that is, a class object that performs specific logical processing on the received transaction request data according to preset Java code. Its function is to generate response results based on preset business logic, rather than simple static simulation. This step ensures that the simulated microservice can dynamically adjust its response behavior according to different input messages, thereby covering a wider range of test cases.
[0065] Next, the developers added a target attribute to the configuration data table. This attribute is used to store and indicate the selected data processing object. The establishment of the target attribute allows the configuration data table to carry more logical decision-making information, not just static response data. Then, based on the data processing object corresponding to the simulated microservice, the developers determined the target attribute value. Setting the target attribute value essentially concretizes the logical decision-making rules in the configuration data table, ensuring that during the runtime of the simulated microservice, this attribute value can correctly identify and invoke the required data processing object, thereby achieving dynamic response generation.
[0066] Finally, based on the determined target attribute values, the configuration data table was updated. This update process not only included writing the target attribute values but may also involve revising existing static response information to ensure that the configuration data table can completely and accurately reflect all logical judgment logic and preset response modes of the external service interface. The updated configuration data table can quickly locate and apply the corresponding data processing object after receiving a transaction request, generating a response result that meets the requirements of the test scenario.
[0067] Through the above steps, the technical effect of enabling simulated microservices to generate dynamic responses has been achieved. This improvement significantly enhances the flexibility and practicality of simulated microservices, allowing them to dynamically adjust response content according to preset logical rules in complex and ever-changing testing environments, thereby more comprehensively and accurately verifying the functionality of business systems. Simultaneously, by configuring the data table update mechanism, the maintenance process of dynamic response logic is simplified, reducing the potential risks associated with code modifications and improving the stability and efficiency of the entire testing system.
[0068] Optionally, in the microservice-based testing method provided in this application embodiment, generating a response result through the target microservice based on the interface information and transaction request of the external service includes: querying a configuration data table based on the interface information of the target external service to obtain a query result, wherein the query result includes the response information corresponding to the target external service; when the response information only contains static response information, generating a response result through the target microservice based on the static response information; and when the response information contains both static response information and target attribute values, generating a response result through the target microservice based on the target attribute values, transaction request, and static response information.
[0069] In this embodiment, to accurately simulate the response behavior of the target external service in the test environment, a query operation is first performed on the configuration data table based on the interface information of the target external service. This query operation aims to extract response information related to the target external service from the configuration data table, i.e., predefined simulated response data, such as whether the account status is normal or abnormal, and preset amount thresholds for different account types. Through this query, the static response information that the simulated microservice should return can be quickly obtained, which is the basis for generating the simulated response.
[0070] Then, if the query results indicate that the target external service's response information only contains static response information, i.e., a pre-defined fixed response pattern, the target microservice will directly generate the response result based on this static response information. This means that for external services that can return a fixed-format response without complex logical judgments, the simulated microservice can immediately generate and return the preset response data to meet the basic requirements of transaction testing, simplifying the response generation process and improving simulation efficiency.
[0071] Secondly, when the response information includes target attribute values in addition to static responses—that is, when dynamic response requirements exist—the target microservice will further generate response results based on the target attribute values, the specific transaction request, and the static response information. The target attribute values are predefined data processing objects (i.e., the Java objects mentioned above) in the configuration data table. By analyzing specific fields in the transaction request and the pre-defined static response information, the target microservice can perform more complex data processing and business logic judgments, generating dynamic and personalized response results to adapt to possible variables and conditions in the test scenario, ensuring the comprehensiveness and accuracy of transaction testing.
[0072] Finally, the generated response will be returned by the target microservice to the business system or service that issued the transaction request, completing a full simulated response process. Whether it is a static or dynamic response, this process aims to provide stable and predictable external service interface behavior for transaction testing, eliminate the impact of external unstable factors on test results, and ensure the consistency and controllability of the test environment.
[0073] Through the above steps, the technical effect of effectively simulating external service calls is achieved by configuring dynamic queries of data tables and intelligent generation of response information without directly modifying the project's source code. This method not only improves the flexibility and efficiency of testing but also reduces the code intrusion and version management difficulties commonly found in traditional mock techniques. Therefore, it provides a more efficient and stable solution for the software development and testing process, promoting software quality improvement and development process optimization.
[0074] Optionally, in the microservice-based testing method provided in this application embodiment, the target microservice generates a response result based on the target attribute value, transaction request, and static response information, including: transmitting the transaction request and static response information to the target data processing object corresponding to the target attribute value through the target microservice; and processing the transaction information and static response information of the transaction request through the target data processing object to obtain the response result.
[0075] In this embodiment, to dynamically generate response results that meet specific testing requirements, the target microservice, upon receiving a transaction request, first transmits the request information along with static response information to the target data processing object associated with the target attribute value. This operation ensures that the target data processing object has all the necessary inputs, including the transaction information carried in the transaction request and the static response information about the target external service defined in the configuration data table, laying the foundation for subsequent logical processing and response generation.
[0076] Next, the target data processing object begins in-depth processing of the transaction information and static response information of the transaction request. This step involves parsing the parameters, data, and instructions contained in the transaction request, while considering preset values in the static response information, such as status codes, error messages, or standard data formats. The target data processing object uses built-in logical algorithms to perform calculations, verifications, or data transformations based on this information to construct a prototype of the response result.
[0077] Secondly, if the target attribute value indicates a higher level of dynamic response requirement, the target data processing object will adjust its processing strategy based on the specific context of the transaction request and the static response information. For example, it may need to examine a field value in the transaction request to determine whether to apply specific business rules or exception handling procedures, thereby generating differentiated response results. This dynamic processing mechanism based on target attribute values gives the target microservice greater flexibility and adaptability, enabling it to cope with changing test environments and cases.
[0078] Finally, following the above processing flow, the target data processing object generates the final response result, containing all necessary data and status information to respond to the transaction request. This response result is then returned by the target microservice to the business system or service that initiated the transaction request, completing a full, dynamically adjusted external service call simulation process. This result not only reflects the basic framework of static response information, but more importantly, it integrates the dynamic processing logic driven by the target attribute values in the configuration data table, ensuring the completeness and realism of the test cases.
[0079] Through the above steps, the technical effect of intelligently and dynamically generating customized response results through target data processing objects in a simulated microservice architecture is achieved. This method effectively improves the efficiency and accuracy of the testing system, allowing developers to easily handle complex testing requirements through configuration adjustments without modifying the code logic, while ensuring the continuity of the software development process and the stability of the codebase.
[0080] Optionally, in the microservice-based testing method provided in this application embodiment, determining the data processing object corresponding to the simulated microservice based on the interface information of the external service includes: determining input data and output data based on the interface information of the external service; determining data processing operations based on the test requirements of the transaction request and / or business execution logic; and constructing the data processing object of the simulated microservice corresponding to the external service based on the input data, output data, and data processing operations.
[0081] In this embodiment, to construct a microservice architecture capable of accurately simulating external service interactions, the specific formats of the input and output data are first defined based on the interface information of the external services. The purpose of this work is to identify the types and structures of parameters to be passed during external service calls, as well as the returned response results, thereby providing a clear reference framework for the subsequent design of data processing objects. Through detailed interface documentation or existing call logs, the structure of the input data (such as JSON, XML, etc.) and the expected output data model can be obtained.
[0082] Next, based on the testing requirements and business execution logic of the transaction requests, determine the data processing operations that the simulated microservices need to perform. The focus of this stage is on analyzing the business processes triggered by the transaction requests and identifying key processing steps, such as data validation, format conversion, and application of business rules. Simultaneously, testing requirements must be considered, such as whether specific abnormal situations need to be simulated, or whether different outputs need to be generated under different input conditions. Defining these data processing operations determines how the simulated microservices respond to transaction requests and how they generate expected output data; this is the core aspect of the simulation process.
[0083] Secondly, using the established input data format, expected output data model, and data processing operations, a data processing object for the simulated microservice corresponding to the external service is constructed. The design of the data processing object must closely align with the aforementioned defined operations, typically implemented as functions or classes in a programming language (Java). These objects contain specific algorithms for processing input data, executing business logic, and generating output data. To ensure the simulated microservice can accurately respond to various transaction requests, the data processing object must be able to flexibly execute corresponding processing flows and generate the expected output data based on the input data and preset business rules.
[0084] Finally, through testing and verification, it is confirmed that the constructed data processing object can correctly process input data and generate expected output data according to the established data processing operations, ensuring that the response behavior of the simulated microservice is consistent with the behavior of real external services or meets specific testing requirements. This verification process may involve unit testing, integration testing, and joint debugging testing with transaction requests to comprehensively evaluate the functionality and stability of the data processing object.
[0085] Through the steps described above, the technical effect of constructing data processing objects capable of accurately simulating external service interactions within a microservice architecture is achieved. This series of operations helps improve the efficiency and accuracy of software testing. Simultaneously, this method of constructing simulated microservices based on interface information and business logic avoids the risks associated with directly modifying production code, enhancing the flexibility and maintainability of the microservice architecture.
[0086] Optionally, in this embodiment, Figure 3 This is a flowchart illustrating an optional model-based microservice testing method provided according to an embodiment of this application. For example... Figure 3 As shown, a configuration data table is established in the test environment, containing the service code, version number, and predetermined return result of the external interface to be simulated. An independent mock microservice is built, configuring the routing and return information of the external interface to be simulated, and registering it with the registry center under a specific name. A service code is configured for the microservice so that it can respond to external interface calls. The microservice to be tested adds a profile configuration file to the mock microservice, and adjusts its association with the registry and configuration center so that when an external service code is called under the configuration of this profile configuration file, the request is redirected to the mock microservice. When a transaction request to call the external service interface is executed, the transaction request is received by the mock microservice, which queries the configuration table based on the service code and version number to obtain the return result, and returns the static return result as the service code's response, thus simulating the real response of the external interface.
[0087] In an optional embodiment 1, it is assumed that during the test of an account opening transaction, the trading system needs to call an external certificate management service to check if there are any available blank certificates. Specifically, the following steps are performed for this test scenario:
[0088] Step 1: Create a configuration data table in the test environment, containing the external interface service code to be simulated (such as the credential check service), its version number, and the returned result (e.g., "credentials sufficient"). Simultaneously, create a mock microservice and configure the routing and return information for the interface to be mocked.
[0089] Step 2: In the account opening microservice that needs to be tested, add the profile configuration file of the mock microservice and adjust its association with the registration and configuration center so that when the credential verification service is called in the test environment, the actual request will be redirected to the mock microservice.
[0090] Step 3: When the account opening transaction is executed, the request that would originally be sent to the external credential management service is now redirected to the mock microservice. The mock microservice queries the configuration table and returns the preset "credentials sufficient" result based on the service code and version number, thereby ensuring the smooth execution of the transaction.
[0091] Step 4: If it is necessary to verify scenarios where credentials are insufficient during the testing process, the return result of the specific credential check service code in the database configuration table can be adjusted to dynamically adapt to different testing needs.
[0092] As illustrated in Example 1, in a traditional testing environment, frequent account opening transactions can quickly deplete blank credentials, potentially causing the external credentials management service to return an "insufficient credentials" error, thus hindering the test. However, by employing the microservice-based testing method provided in this example, the account opening transaction testing process remains stable even when blank credentials are insufficient. This also reduces the need for frequent modifications to the testing environment, lowering both manpower and time costs.
[0093] In an optional embodiment 2, during the account closure transaction test, the transaction system needs to call an external account management service to check the status of the closed account. Specifically, the following steps are performed for this test scenario:
[0094] Step 1: Create a configuration data table in the test environment, which includes the service code and version number of the account management service, as well as the preset account status return results.
[0095] Step 2: In the account cancellation microservice, configure the profile of the mock microservice, adjust the relationship between the registration and configuration center, and ensure that external service calls for account cancellation transactions in the test environment will point to the mock microservice.
[0096] Step 3: When the account closure transaction is executed, the request to call the account management service is redirected to the mock microservice. The mock microservice returns the result "Account status is normal, account can be closed" based on the information in the configuration table, ensuring the smooth execution of the account closure transaction.
[0097] Step 4: Even after the account closure transaction, the account management service can still return the result of "account status is normal" due to the intervention of the mock microservice, avoiding the problem that the account status cannot be restored after the real account closure, thus supporting the reentrancy of the transaction and multiple tests.
[0098] As illustrated in Example 2, since the account status permanently changes after account closure, traditional testing methods may require manually preparing a usable closed account before each test. This not only consumes resources but also reduces testing efficiency. By adopting the microservice-based testing method provided in this example, reentrancy testing of transactions is supported through simulating account status, which not only improves the stability of the testing environment but also enhances testing efficiency and resource utilization.
[0099] These two examples clearly demonstrate the application of the microservice-based testing method provided in this embodiment in different transaction scenarios, and how to solve the problems of unstable external interfaces and non-reentrant transactions in testing by using mock microservices configured in the database.
[0100] This application also provides a microservice-based testing apparatus. It should be noted that this microservice-based testing apparatus can be used to execute the microservice-based testing method provided in this application. This apparatus is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0101] The following describes the microservice-based testing device provided in the embodiments of this application.
[0102] Figure 4 This is a structural block diagram of a microservice-based testing device provided according to an embodiment of this application. Figure 4 As shown, the device includes: a first determining unit 401, a forwarding unit 402, a first generating unit 403, and a second determining unit 404.
[0103] Specifically, the first determining unit 401 is used to determine the external service that the transaction request needs to call based on the transaction information of the transaction request when a transaction request to be tested is detected, and obtain the target external service.
[0104] Forwarding unit 402 is used to forward transaction requests to the target microservice based on the configuration data table, wherein the configuration data table stores the interface information of the external service, and the target microservice is a simulated microservice corresponding to the target external service.
[0105] The first generation unit 403 is used to generate a response result based on the interface information and transaction request of the external service by the target microservice.
[0106] The second determining unit 404 is used to determine the test result of the transaction request based on the response result.
[0107] The microservice-based testing apparatus provided in this application embodiment, through a first determining unit 401, determines the external service that the transaction request needs to call based on the transaction information of the transaction request when a transaction request to be tested is detected, thereby obtaining the target external service; a forwarding unit 402 forwards the transaction request to the target microservice based on a configuration data table, wherein the configuration data table stores the interface information of the external service, and the target microservice is a simulated microservice corresponding to the target external service; a first generating unit 403 generates a response result based on the interface information of the external service and the transaction request through the target microservice; and a second determining unit 404 determines the test result of the transaction request based on the response result. This solves the problem of low testing efficiency in the process of testing transaction requests that call external services in related technologies due to the instability of the external service or the non-repeatability of the transaction request.
[0108] By configuring a dynamic routing mechanism for the data tables and building simulated microservices, transaction requests can be accurately forwarded to the corresponding simulated microservices during the detection phase. This achieves the technical effect of shielding against external unstable factors and ensuring the determinism of the test environment, further improving testing efficiency and reducing maintenance costs. Simultaneously, by having simulated microservices generate predefined response results based on the detailed information of transaction requests and comparing them with expected results, the test results accurately reflect the execution status of the transaction logic. This achieves the technical effect of verifying the integrity of transaction functions, ensuring software quality, realizing automated test evaluation, improving the standardization and objectivity of the testing process, and ultimately optimizing the overall testing strategy and accelerating the software development cycle.
[0109] Optionally, in the microservice-based testing apparatus provided in this application embodiment, the apparatus further includes: a third generation unit, used to collect interface information of the external service to be called before forwarding the transaction request to the target microservice based on the configuration data table, and generate a configuration data table based on the interface information of the external service, wherein the interface information includes at least: service code, version number, and response information; a creation unit, used to create a simulated microservice corresponding to the external service based on the interface information of the external service; and a registration unit, used to generate identification information of the simulated microservice and register it in the registration center based on the identification information, so as to simulate the response result returned by the external service through the simulated microservice, wherein the registration center is a component in the microservice architecture used to maintain microservice information.
[0110] Optionally, in the microservice-based testing apparatus provided in this application embodiment, the apparatus further includes: an adding unit, used to add an environment configuration file of a simulated microservice to an external service after registering it in a registry center based on identification information; a modifying unit, used to modify the service information of the external service in the registry center and the configuration information of the external service in the configuration center, wherein the configuration center stores the configuration information of the external service; and a running unit, used to run the simulated microservice based on the environment configuration file of the simulated microservice, so that when a transaction request is detected to call an external service, the transaction request is forwarded to the simulated microservice corresponding to the external service.
[0111] Optionally, in the microservice-based testing apparatus provided in this application embodiment, the apparatus further includes: a third determining unit, configured to determine the data processing object corresponding to the simulated microservice based on the interface information of the external service after generating a configuration data table based on the interface information of the external service, wherein the data processing object is used to process the received data based on preset code; a fourth determining unit, configured to add a target attribute to the configuration data table and determine the target attribute value based on the data processing object corresponding to the simulated microservice; and an updating unit, configured to update the configuration data table based on the target attribute value.
[0112] Optionally, in the microservice-based testing apparatus provided in this application embodiment, the first generation unit 403 includes: a query subunit, used to query a configuration data table based on the interface information of the target external service to obtain a query result, wherein the query result includes response information corresponding to the target external service; a first generation subunit, used to generate a response result based on the static response information through the target microservice when the response information only contains static response information; and a second generation subunit, used to generate a response result based on the target attribute value, transaction request, and static response information through the target microservice when the response information contains both static response information and target attribute value.
[0113] Optionally, in the microservice-based testing apparatus provided in this application embodiment, the second generation subunit includes: a transmission module, used to transmit transaction requests and static response information to the target data processing object corresponding to the target attribute value through the target microservice; and a processing module, used to process the transaction information and static response information of the transaction request through the target data processing object to obtain a response result.
[0114] Optionally, in the microservice-based testing apparatus provided in this application embodiment, the third determining unit includes: a first determining subunit, used to determine input data and output data based on the interface information of the external service; a second determining subunit, used to determine data processing operations based on the test requirements of the transaction request and / or business execution logic; and a constructing subunit, used to construct a data processing object of the simulated microservice corresponding to the external service based on the input data, output data, and data processing operations.
[0115] The microservice-based testing device includes a processor and a memory. The first determining unit 401, forwarding unit 402, first generating unit 403, and second determining unit 404, etc., are all stored as program units in the memory. The processor executes the program units stored in the memory to implement the corresponding functions. All of the above modules are located in the same processor; or, the above modules are located in different processors in any combination.
[0116] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and testing efficiency can be improved by adjusting kernel parameters.
[0117] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.
[0118] This invention provides a computer-readable storage medium that includes a stored program, wherein the program, when running, controls the device where the computer-readable storage medium is located to execute a microservice-based testing method.
[0119] This invention provides a processor for running a program, wherein the program executes a microservice-based testing method during runtime.
[0120] This invention provides a device including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs at least the following steps: upon detecting a transaction request to be tested, determining the external service that the transaction request needs to invoke based on the transaction information of the transaction request, thus obtaining the target external service; forwarding the transaction request to the target microservice based on a configuration data table, wherein the configuration data table stores the interface information of the external service, and the target microservice is a simulated microservice corresponding to the target external service; generating a response result through the target microservice based on the interface information of the external service and the transaction request; and determining the test result of the transaction request based on the response result. The device in this document can be a server, PC, PAD, mobile phone, etc.
[0121] Optionally, before forwarding the transaction request to the target microservice based on the configuration data table, the above method further includes: collecting the interface information of the external service to be called, and generating a configuration data table based on the interface information of the external service, wherein the interface information includes at least: service code, version number, and response information; creating a simulated microservice corresponding to the external service based on the interface information of the external service; generating the identification information of the simulated microservice, and registering it in the registry center based on the identification information, so as to simulate the response result returned by the external service through the simulated microservice, wherein the registry center is a component in the microservice architecture used to maintain microservice information.
[0122] Optionally, after registering in the registry center based on the identification information, the above method includes: adding an environment configuration file for the simulated microservice to the external service; modifying the service information of the external service in the registry center and modifying the configuration information of the external service in the configuration center, wherein the configuration center stores the configuration information of the external service; running the simulated microservice based on the environment configuration file of the simulated microservice, so that when a transaction request is detected to call the external service, the transaction request is forwarded to the simulated microservice corresponding to the external service.
[0123] Optionally, after generating the configuration data table based on the interface information of the external service, the above method further includes: determining the data processing object corresponding to the simulated microservice based on the interface information of the external service, wherein the data processing object is used to process the received data based on preset code; adding a target attribute to the configuration data table and determining the target attribute value based on the data processing object corresponding to the simulated microservice; and updating the configuration data table based on the target attribute value.
[0124] Optionally, generating a response result through the target microservice based on the interface information and transaction request of the external service includes: querying the configuration data table based on the interface information of the target external service to obtain the query result, wherein the query result includes the response information corresponding to the target external service; when the response information only contains static response information, generating a response result through the target microservice based on the static response information; when the response information contains static response information and target attribute values, generating a response result through the target microservice based on the target attribute values, transaction request, and static response information.
[0125] Optionally, the target microservice generates a response result based on the target attribute value, transaction request, and static response information, including: transmitting the transaction request and static response information to the target data processing object corresponding to the target attribute value through the target microservice; and processing the transaction information and static response information of the transaction request through the target data processing object to obtain the response result.
[0126] Optionally, the data processing object corresponding to the simulated microservice is determined based on the interface information of the external service, including: determining the input data and output data based on the interface information of the external service; determining the data processing operation based on the test requirements of the transaction request and / or the business execution logic; and constructing the data processing object of the simulated microservice corresponding to the external service based on the input data, output data, and data processing operation.
[0127] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps: upon detecting a transaction request to be tested, determining the external service that the transaction request needs to call based on the transaction information of the transaction request, and obtaining the target external service; forwarding the transaction request to the target microservice based on a configuration data table, wherein the configuration data table stores the interface information of the external service, and the target microservice is a simulated microservice corresponding to the target external service; generating a response result through the target microservice based on the interface information of the external service and the transaction request; and determining the test result of the transaction request based on the response result.
[0128] Optionally, before forwarding the transaction request to the target microservice based on the configuration data table, the above method further includes: collecting the interface information of the external service to be called, and generating a configuration data table based on the interface information of the external service, wherein the interface information includes at least: service code, version number, and response information; creating a simulated microservice corresponding to the external service based on the interface information of the external service; generating the identification information of the simulated microservice, and registering it in the registry center based on the identification information, so as to simulate the response result returned by the external service through the simulated microservice, wherein the registry center is a component in the microservice architecture used to maintain microservice information.
[0129] Optionally, after registering in the registry center based on the identification information, the above method includes: adding an environment configuration file for the simulated microservice to the external service; modifying the service information of the external service in the registry center and modifying the configuration information of the external service in the configuration center, wherein the configuration center stores the configuration information of the external service; running the simulated microservice based on the environment configuration file of the simulated microservice, so that when a transaction request is detected to call the external service, the transaction request is forwarded to the simulated microservice corresponding to the external service.
[0130] Optionally, after generating the configuration data table based on the interface information of the external service, the above method further includes: determining the data processing object corresponding to the simulated microservice based on the interface information of the external service, wherein the data processing object is used to process the received data based on preset code; adding a target attribute to the configuration data table and determining the target attribute value based on the data processing object corresponding to the simulated microservice; and updating the configuration data table based on the target attribute value.
[0131] Optionally, generating a response result through the target microservice based on the interface information and transaction request of the external service includes: querying the configuration data table based on the interface information of the target external service to obtain the query result, wherein the query result includes the response information corresponding to the target external service; when the response information only contains static response information, generating a response result through the target microservice based on the static response information; when the response information contains static response information and target attribute values, generating a response result through the target microservice based on the target attribute values, transaction request, and static response information.
[0132] Optionally, the target microservice generates a response result based on the target attribute value, transaction request, and static response information, including: transmitting the transaction request and static response information to the target data processing object corresponding to the target attribute value through the target microservice; and processing the transaction information and static response information of the transaction request through the target data processing object to obtain the response result.
[0133] Optionally, the data processing object corresponding to the simulated microservice is determined based on the interface information of the external service, including: determining the input data and output data based on the interface information of the external service; determining the data processing operation based on the test requirements of the transaction request and / or the business execution logic; and constructing the data processing object of the simulated microservice corresponding to the external service based on the input data, output data, and data processing operation.
[0134] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.
[0135] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0136] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0137] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0138] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0139] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0140] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0141] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0142] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0143] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0144] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A microservice-based testing method, characterized in that, include: When a transaction request to be tested is detected, the external service that the transaction request needs to call is determined based on the transaction information of the transaction request, and the target external service is obtained; The transaction request is forwarded to the target microservice based on the configuration data table, wherein the configuration data table stores the interface information of the external service, and the target microservice is a simulated microservice corresponding to the target external service; The target microservice generates a response result based on the interface information of the external service and the transaction request. The test result of the transaction request is determined based on the response result.
2. The method according to claim 1, characterized in that, Before forwarding the transaction request to the target microservice based on the configuration data table, the method further includes: Collect the interface information of the external service to be invoked, and generate the configuration data table based on the interface information of the external service. The interface information includes at least: service code, version number, and response information. Create a simulated microservice corresponding to the external service based on the interface information of the external service; The simulated microservice generates identification information and registers it in the registry center based on the identification information, so as to simulate the response result returned by the external service through the simulated microservice. The registry center is a component in the microservice architecture used to maintain microservice information.
3. The method according to claim 2, characterized in that, After registering in the registration center based on the identification information, the method includes: Add the environment configuration file for the simulated microservice to the external service; The service information of the external service is modified in the registry center, and the configuration information of the external service is modified in the configuration center, wherein the configuration center stores the configuration information of the external service; The simulated microservice is run based on the environment configuration file of the simulated microservice, so that when the transaction request to call the external service is detected, the transaction request is forwarded to the simulated microservice corresponding to the external service.
4. The method according to claim 2, characterized in that, After generating the configuration data table based on the interface information of the external service, the method further includes: The data processing object corresponding to the simulated microservice is determined based on the interface information of the external service, wherein the data processing object is used to process the received data based on preset code; Add a target attribute to the configuration data table, and determine the target attribute value based on the data processing object corresponding to the simulated microservice; The configuration data table is updated based on the target attribute value.
5. The method according to claim 4, characterized in that, The target microservice generates a response result based on the interface information of the external service and the transaction request, including: The interface information of the target external service is used to query the configuration data table to obtain the query results, wherein the query results include the response information corresponding to the target external service; When the response information contains only static response information, the target microservice generates the response result based on the static response information. When the response information includes static response information and the target attribute value, the target microservice generates the response result based on the target attribute value, the transaction request, and the static response information.
6. The method according to claim 5, characterized in that, The target microservice generates the response result based on the target attribute value, the transaction request, and the static response information, including: The target microservice transmits the transaction request and the static response information to the target data processing object corresponding to the target attribute value. The target data processing object processes the transaction information of the transaction request and the static response information to obtain the response result.
7. The method according to claim 4, characterized in that, Based on the interface information of the external service, the data processing object corresponding to the simulated microservice is determined, including: The input and output data are determined based on the interface information of the external service. The data processing operations are determined based on the testing requirements and / or business execution logic of the transaction request; The data processing object of the simulated microservice corresponding to the external service is constructed based on the input data, the output data, and the data processing operation.
8. A microservice-based testing device, characterized in that, include: The first determining unit is used to determine the external service that the transaction request needs to call based on the transaction information of the transaction request when a transaction request to be tested is detected, and obtain the target external service. A forwarding unit is used to forward the transaction request to the target microservice based on a configuration data table, wherein the configuration data table stores interface information of external services, and the target microservice is a simulated microservice corresponding to the target external service; The first generation unit is used to generate a response result based on the interface information of the external service and the transaction request through the target microservice; The second determining unit is used to determine the test result of the transaction request based on the response result.
9. An electronic device, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including a microservice-based testing method according to any one of claims 1 to 7.
10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the microservice-based testing method according to any one of claims 1 to 7.