Service integration test method and system, storage medium and equipment
Through monitoring and visualizing the call chain between services, the inter-service interaction verification problem in integrated testing under the microservice architecture is solved, and the efficiency of problem investigation is improved.
Patent Information
- Application Number
- CN202411523509.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-29
- Publication Date
- 2025-02-07
AI Technical Summary
Under the microservice architecture, traditional integration testing is difficult to effectively verify the interaction between services, resulting in inefficient problem-solving.
By listening and obtaining the request received by each called service and the response message returned by the downstream service, tracking the call chain between each service, and visually displaying the call information to quickly locate problem interfaces or methods.
It improves the efficiency of problem detection in integration testing, reduces dependence on massive logs, and simplifies the problem location process.
Smart Images

Figure CN119396729A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of software testing, and in particular relates to a service integration testing method, system, storage medium and device. Background Art
[0002] Modern complex systems are often composed of multiple services. Ensuring that these services can interact efficiently and accurately is the key to ensuring the normal operation of the entire application. Service integration testing aims to verify whether the interaction and integration between multiple services work as expected, focusing on data transfer, call order, error handling and performance between services to ensure the functionality and reliability of services in the overall system. Among them, microservice architecture is an increasingly popular way to build complex distributed systems. In the microservice architecture, large applications are divided into smaller, independent services that can be deployed, upgraded and expanded independently and communicate with each other through the network. Integration testing under the microservice architecture requires relevant verification of the communication between different methods of different services. Because when testing the microservice interface, the interface test case only verifies the internal logic of the tested interface and service, and cannot verify the interaction between other services that are upstream and downstream related to it. Even if the interface tests of service A and service B pass respectively, it does not mean that the interaction between application A and application B is normal.
[0003] In traditional integration testing, after a request is sent to application A, application A processes it and hands it over to application B. After application B processes it, it may be processed by many other applications, and finally the response message is returned to application B. After application B receives the response, it processes it and returns it to application A. If the response returned to application A is inconsistent with the expected result, the subsequent troubleshooting will be very difficult. Testers sometimes also need the help of developers to check one by one along the call sequence of the request chain to locate the root cause of the problem. Testers want to know which specific applications the integration test case has passed through during the actual execution process. The current common way is to check the logs or the changes in the final data to determine. If there is a problem with the call between applications, the relevant testers can check the logs in the corresponding application to locate the problem.
[0004] However, if the applications in integration testing are also called by other applications, it is very difficult to find content related to the target call in massive logs, so the efficiency of troubleshooting is low. Summary of the invention
[0005] In view of the shortcomings of the prior art, the present invention provides a service integration testing method, system, storage medium and device, which monitors and obtains the request received by each called service and the response message returned by the downstream service, tracks the call chain between the services, and displays the call information in a visual manner. It can quickly locate the interface or method of the problem and its corresponding cause, thereby improving the efficiency of problem troubleshooting in integration testing.
[0006] The present invention is achieved through the following technical solutions:
[0007] Deploy the integrated test environment for the service under test and collect service information;
[0008] Execute test cases, call services in the integrated environment according to the test cases, monitor and obtain the requests received by each called service and the response messages returned by the downstream services;
[0009] Generate execution details of corresponding test cases according to the service information and the request and response messages received by each called service;
[0010] Based on the execution details, a call chain is created for each test case and displayed on the front-end interface.
[0011] Optional,
[0012] The deployment of the service integration test environment to be tested and the collection of service information include:
[0013] A service monitoring component and a heartbeat component are respectively set for each service in the integrated environment;
[0014] Collect service information through the heartbeat component and send it to the control component;
[0015] The monitoring rules are set and validated by the control component, uploaded to the shared storage component, and a response message is sent to the heartbeat component;
[0016] The heartbeat component notifies the service monitoring component to download monitoring rules from the shared storage component according to the response information.
[0017] Optional,
[0018] The executing test case, calling the service in the integrated environment according to the test case, includes:
[0019] Call services in the integration environment according to test cases;
[0020] Each called service receives a request sent by an upstream service, sends the request to a preset interface and method, and forwards the request to a downstream service;
[0021] The called service processes the received request and returns a response message to the upstream service.
[0022] Optional,
[0023] Through the service monitoring component, the request received by the corresponding called service and the response message returned by the downstream service are obtained.
[0024] Optional,
[0025] The generating of execution details of the corresponding test case according to the service information and the request and response messages received by each called service includes:
[0026] Based on the service information and the request and response messages received by each called service, save them according to the test case number and transaction number;
[0027] For each test case, execution details are generated.
[0028] Optional,
[0029] Based on the execution details, a call chain is created for each test case and displayed on the front-end interface, including:
[0030] Analyze the call relationship according to the execution details and create a call chain for each test case;
[0031] The call chain is visualized in a graphical form and displayed on a front-end interface according to the execution order of the test cases.
[0032] Optional,
[0033] The deployment of the tested service integration test environment also includes:
[0034] Packing the service monitoring component, the heartbeat component and the JVM sandbox environment into a package file, and providing a remote download method for the package file;
[0035] When the POD containing the service is started, the packaged file is automatically downloaded through the remote download method;
[0036] The packaged file is automatically decompressed to a preset directory, and the service monitoring component and the heartbeat component are started.
[0037] The present invention also provides a service integration test system for implementing the above method, the system comprising:
[0038] The environment deployment module is used to deploy the integrated test environment of the tested service and collect service information;
[0039] The test execution module is used to execute test cases, call services in the integrated environment according to the test cases, monitor and obtain the requests received by each called service and the response messages returned by the downstream services;
[0040] A data storage module, used to generate execution details of corresponding test cases according to the service information and the request and response messages received by each called service;
[0041] The visualization module is used to create a call chain for each test case based on the execution details and display it on the front-end interface.
[0042] Optional,
[0043] The environment deployment module is also configured to:
[0044] A service monitoring component and a heartbeat component are respectively set for each service in the integrated environment;
[0045] Collect service information through the heartbeat component and send it to the control component;
[0046] The monitoring rules are set and validated by the control component, uploaded to the shared storage component, and a response message is sent to the heartbeat component;
[0047] The heartbeat component notifies the service monitoring component to download monitoring rules from the shared storage component according to the response information.
[0048] Optional,
[0049] The test execution module is further configured to:
[0050] Call services in the integration environment according to test cases;
[0051] Each called service receives a request sent by an upstream service, sends the request to a preset interface and method, and forwards the request to a downstream service;
[0052] The called service processes the received request and returns a response message to the upstream service.
[0053] Optional,
[0054] The system is also configured to:
[0055] Through the service monitoring component, the request received by the corresponding called service and the response message returned by the downstream service are obtained.
[0056] Optional,
[0057] The environment deployment module is also configured to:
[0058] Packing the service monitoring component, the heartbeat component and the JVM sandbox environment into a package file, and providing a remote download method for the package file;
[0059] When the POD containing the service is started, the packaged file is automatically downloaded through the remote download method;
[0060] The packaged file is automatically decompressed to a preset directory, and the service monitoring component and the heartbeat component are started.
[0061] The present invention also provides a computer-readable storage medium storing one or more programs, which, when executed, can implement the aforementioned service integration testing method.
[0062] The present invention also provides a device, comprising a processor, a communication interface, a computer-readable storage medium and a communication bus; wherein the processor, the communication interface and the computer-readable storage medium communicate with each other via the communication bus;
[0063] The processor is configured to execute a program stored in a computer-readable storage medium.
[0064] Compared with the prior art, the present invention has the following advantages:
[0065] 1. The service integration testing method proposed in the present invention tracks the call chain between services according to the request received by each called service and the response message returned by the downstream service, and displays the call information in a visual manner. It can quickly locate the interface or method of the problem and its corresponding cause, thereby improving the efficiency of troubleshooting in integration testing.
[0066] 2. Use the service monitoring component to monitor and obtain the requests received by each called service and the response messages returned by the downstream service, and generate execution details for each test case. This eliminates the need for testers to check the contents related to the target call one by one in a large number of logs, thereby improving work efficiency.
[0067] 3. By displaying the integrated service grouping and integrated test results through visual components, the relevant information of each service, as well as the request and response messages received by each service during the integration test execution, can be displayed on the front-end page. There is no need for testers and developers of all services to jointly find and locate problems, which effectively releases human resources and improves work efficiency.
[0068] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0069] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0070] Figure 1 A flow chart of a service integration testing method is shown;
[0071] Figure 2 A structural schematic block diagram of a service integration test system is shown;
[0072] Figure 3 A schematic diagram showing the main components of an embodiment of the present invention is shown;
[0073] Figure 4 A schematic diagram of the overall flow of integrated testing according to an embodiment of the present invention is shown;
[0074] Figure 5 A schematic diagram of a JVM sandbox environment according to an embodiment of the present invention is shown;
[0075] Figure 6 A schematic diagram of a visualization component of an embodiment of the present invention is shown;
[0076] Figure 7 A schematic diagram of integrated environment visualization according to an embodiment of the present invention is shown;
[0077] Figure 8 A schematic diagram of an integrated environment smoke test according to an embodiment of the present invention is shown;
[0078] Fig. 9 It is a structural schematic diagram of a device according to an embodiment of the present invention. DETAILED DESCRIPTION
[0079] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0080] See attached Figure 1 , the method of the present invention comprises:
[0081] S1. Deploy the integrated test environment for the service under test and collect service information.
[0082] Wherein, a service monitoring component and a heartbeat component are respectively set for each service in the integrated environment;
[0083] Collect service information through the heartbeat component and send it to the control component;
[0084] The monitoring rules are set and validated by the control component, uploaded to the shared storage component, and a response message is sent to the heartbeat component;
[0085] The heartbeat component notifies the service monitoring component to download monitoring rules from the shared storage component according to the response information.
[0086] S2. Execute the test case, call the service in the integrated environment according to the test case, monitor and obtain the request received by each called service and the response message returned by the downstream service;
[0087] Among them, the services in the integration environment are called according to the test cases;
[0088] Each called service receives a request sent by an upstream service, sends the request to a preset interface and method, and forwards the request to a downstream service;
[0089] The called service processes the received request and returns a response message to the upstream service.
[0090] Among them, the service monitoring component is used to obtain the request received by the corresponding called service and the response message returned by the downstream service.
[0091] S3, generating execution details of corresponding test cases according to the service information and the request and response messages received by each called service;
[0092] Wherein, based on the service information and the request and response messages received by each called service, they are saved according to the test case number and the transaction number;
[0093] For each test case, execution details are generated.
[0094] S4. Based on the execution details, a call chain is created for each test case and displayed on the front-end interface.
[0095] wherein, the call relationship is analyzed according to the execution details, and a call chain is created for each test case;
[0096] The call chain is visualized in a graphical form and displayed on a front-end interface according to the execution order of the test cases.
[0097] Wherein, the deployment of the tested service integration test environment also includes:
[0098] Packing the service monitoring component, the heartbeat component and the JVM sandbox environment into a package file, and providing a remote download method for the package file;
[0099] When the POD containing the service is started, the packaged file is automatically downloaded through the remote download method;
[0100] The packaged file is automatically decompressed to a preset directory, and the service monitoring component and the heartbeat component are started.
[0101] Specifically,
[0102] In this embodiment, the following components are mainly included:
[0103] The service monitoring component monitors the service under test according to the monitoring rules:
[0104] Monitor the requests and responses received by the service under test and send them to the MQ component: If the service under test needs to be mocked, send the request to the mock service, receive the mock response and send the response message back to the service under test; if the service under test does not need to be mocked, only send the monitored requests and responses to the MQ component;
[0105] Receive instructions from the heartbeat component to mount and uninstall the monitor;
[0106] Update monitoring rules from shared storage components;
[0107] Track the different transaction numbers generated by different services during the test to ensure that the same transaction number is used for the same test case throughout the entire integration test process.
[0108] Heartbeat component, which communicates with external control components in POD:
[0109] Report the running status and environment settings of the POD to the control component, such as IP address, application, interface, method and version;
[0110] Receive the response information returned by the control component and notify the service monitoring component to perform corresponding operations, such as updating the monitoring rules, mounting or uninstalling the monitoring, etc.
[0111] Control component, responsible for managing monitoring rules and issuing tasks:
[0112] Add, delete, modify and query monitoring rules;
[0113] Establish communication with the heartbeat component, monitor the status of services in the POD and send task instructions.
[0114] The shared storage component stores monitoring rules outside the POD. It can be a disk, database, or cache, etc., which are devices and facilities used for data storage, to ensure that the monitoring rules will not be lost due to the destruction of the POD.
[0115] Mock service component, simulates the interaction with the service under test: external system services located outside the integrated service, such as third-party interfaces, are used to receive request information sent by the service listening component in the marginal service POD in the integrated service, and give corresponding response messages.
[0116] The MQ component receives the request and response messages sent by the service monitoring components of each service in the integration test. Due to the large amount of data, it can be received asynchronously.
[0117] The data storage component saves the service information received by the control component. It can also read the request and response messages received in the MQ component and store them according to the test case ID and the transaction number generated by the service entry. The storage method can be a disk, database, cache or other equipment and facilities used for data storage.
[0118] Visualization component: reads the actual call information between services in the data storage component, organizes each service into a call chain, and displays it in a visual way on the front end. On the test case execution result page, according to the call steps, the requests and responses in and out of each service are displayed.
[0119] In this embodiment, the tested services include but are not limited to: microservices, databases, caches, and other non-microservice architecture applications. The following description will take microservices as an example.
[0120] 1. Deploy the integrated test environment for the service under test and collect service information.
[0121] Deploy the integrated test environment for the service under test and collect service information, including:
[0122] A service monitoring component and a heartbeat component are respectively set for each service in the integrated environment;
[0123] Collect service information through the heartbeat component and send it to the control component;
[0124] The monitoring rules are set and validated by the control group, uploaded to the shared storage component, and a response message is sent to the heartbeat component;
[0125] The heartbeat component notifies the service monitoring component to download monitoring rules from the shared storage component according to the response information.
[0126] In this embodiment, taking microservices as an example, the specific implementation process includes:
[0127] S101. The microservice under test is started in the POD. The service monitoring component and the heartbeat component are downloaded to the POD and automatically deployed. The heartbeat component sends heartbeat information to the control component. The heartbeat information includes: all information of the corresponding service, such as service name, interface, method name, version number and IP address.
[0128] S102, the tester sets monitoring rules and makes them effective through the control component, uploads the effective rules to the shared storage component, and sends a response message carrying instructions to the heartbeat component.
[0129] S103: The heartbeat component receives the response information sent by the control component, and notifies the service monitoring component to download the interception rules from the shared storage component.
[0130] S104: After the service monitoring component completes the download, it notifies the heartbeat component to report the readiness information to the control component. After the user performs the mounting operation, the service monitoring component sets the monitoring rules to take effect.
[0131] 2. Execute the test case to obtain the request received by each called service and the response message returned by the downstream service.
[0132] Execute test cases and call services in the entire integration environment according to the test cases, including:
[0133] Call services in the integration environment according to test cases;
[0134] Each called service receives a request sent by an upstream service, sends the request to a preset interface and method, and forwards the request to a downstream service;
[0135] The called service processes the received request and returns a response message to the upstream service.
[0136] Specifically include:
[0137] S201, execute the test case, send a test request to the first called service, the service sends the request to the preset interface and method, processes the request according to the request, and then sends the request to the downstream service;
[0138] S202, the downstream service receives and processes the request from the upstream service, and returns a response message to the upstream service;
[0139] S203. Each service completes the call according to the test case, and returns the final response result to the first called service and to the original caller.
[0140] During the test, the service monitoring component obtains the request received by the corresponding called service and the response message returned by the downstream service according to the monitoring rules, and sends it to the MQ component.
[0141] The method also includes: when the request is sent to a marginal service that needs to call an external system of the integrated environment, if the external system does not meet the test conditions, the request is mocked and a corresponding response message is returned.
[0142] For example: when receiving a request, interface 1 method 1 in service 1 performs internal processing and sends a request to service 2 interface 2 method 2; after receiving the request, service 2 processes it through internal business logic and sends a request to service n interface n method n; service n receives the request, performs internal processing, and sends the request to edge service interface n+1 method n+1 that needs to call the external system of the integrated environment: if the external system does not meet the conditions for joint testing, the service listening component sends the request to the Mock service component. The Mock service component returns the response message to the corresponding edge service according to the preset Mock matching rules. After being processed by a series of intermediate services such as service n, if everything is normal, the final response is returned to service 1, and then returned to the original caller after being processed by service 1.
[0143] In this embodiment, different services sometimes generate different transaction numbers in the process of calling services according to test cases, and the transaction numbers generated in the services are tracked through the service monitoring component. For example, for the same test case, the transaction number used by the upstream service is TEST123456. When a new transaction number APP234567 is generated by the downstream service, the transaction number APP234567 is replaced with the original upstream transaction number TEST123456 through the service monitoring component in the downstream service, so that the test case uses the same transaction number throughout the entire integration test process, simplifying the difficulty of troubleshooting.
[0144] In this embodiment, a specific TOP IC is created for each service in the MQ component. During the entire integration test process, the service monitoring component corresponding to each service pushes the received request and response messages to the TOP IC corresponding to the MQ component.
[0145] 3. Generate execution details of the test case.
[0146] Generate execution details of corresponding test cases according to the service information and the request and response messages received by each called service, including:
[0147] Based on the service information and the request and response messages received by each called service, save them according to the test case number and transaction number;
[0148] For each test case, execution details are generated.
[0149] The service information received by the control component and the request and response messages of each service received by the MQ component are saved according to the test case number and transaction number through the data storage component, and an execution detail document is generated for each test case.
[0150] In this embodiment, the data storage component reads the messages in all TOP ICs of the MQ component, and generates execution details of the corresponding test case according to the test case number and the time sequence of related messages of the same test case, combined with the service information of the corresponding service.
[0151] 4. Create a test case call chain and display it on the front-end interface.
[0152] Based on the execution details, a call chain is created for each test case and displayed on the front-end interface, including:
[0153] Analyze the call relationship according to the execution details and create a call chain for each test case;
[0154] The call chain is visualized in a graphical form and displayed on a front-end interface according to the execution order of the test cases.
[0155] Use visualization components to create a call chain for each test case based on the test case execution details and test case execution order, and display it on the front-end interface.
[0156] Analyze the call relationship based on the execution details of each test case and build a call chain. By visualizing the call chain as an image, the call relationship in the test case can be clearly presented, showing the call sequence and dependency of each service.
[0157] In this embodiment, deploying the tested service integration test environment also includes:
[0158] Packing the service monitoring component, the heartbeat component and the JVM sandbox environment into a package file, and providing a remote download method for the package file;
[0159] When the POD containing the service is started, the packaged file is automatically downloaded through the remote download method;
[0160] The packaged file is automatically decompressed to a preset directory, and the service monitoring component and the heartbeat component are started.
[0161] The service monitoring component and the heartbeat component are both running in the JVM sandbox environment. In order to adapt to the characteristics of horizontal expansion of services, and to facilitate the decoupling of the JVM sandbox environment from the service image and reduce the size of the image file, the entire JVM sandbox environment, service monitoring component and heartbeat component can be compressed into a compressed package and provided for remote download via http. When the POD is horizontally expanded and the new POD is started, the download of the JVM sandbox environment will be automatically triggered without manual operation. After the JVM sandbox environment is downloaded from the remote server to the POD, the JVM sandbox is decompressed to the directory specified in the POD, such as / tmp / , and the heartbeat component and service monitoring component are started.
[0162] In this embodiment, the service information stored in the data storage component is displayed on the front-end interface through the visualization component; the services are grouped according to the integration test requirements, and a visual call chain is formed according to the data flow direction. In this way, the stakeholders of the integration test can understand the current test environment and the corresponding relationship between the service versions in a visual way, reducing the communication cost.
[0163] The visualization component can display the integration service grouping and integration test results. The visualization component forms a test call chain based on the service applications, interfaces, methods and version information stored in the data storage component, and displays it to the relevant personnel in the integration test. At the same time, during the integration test execution, the request and response messages received by each service during the test execution, including the error information in the response, are displayed to the front-end page in chronological order and in the form of test case execution steps.
[0164] The following embodiments specifically disclose the process of performing integration testing using the method of the present invention.
[0165] 1. Deployment and visualization of integrated test environment:
[0166] Make the heartbeat component and service monitoring component, as well as the required JVM sandbox operating environment, into a zip compressed file and deploy it on the Ngi nx server, which can be downloaded through http. Set the javaagent parameter in the POD startup parameters. When the POD starts, it sends an http request to the Ngi nx server, downloads the compressed file of the JVM sandbox operating environment and automatically decompresses it to the specified directory. When the service starts, the service monitoring component and the heartbeat component will also be in operation.
[0167] After the heartbeat component is started, it executes the env command to collect the current POD information and service information, and reports it to the control component. The reported content includes software, interface, method, current version, IP address, etc. After receiving this information, the control component sends it to the data storage component and saves it to the disk, database or cache.
[0168] The visualization component displays the service information stored in the data storage component on the front-end interface. According to the different requirements of the integration test, users can combine the services to be tested by dragging and dropping to form different service groups, and form a visual call chain according to the direction of data flow. This allows all stakeholders involved in the integration test to understand the current integration test environment and the corresponding relationship between each service version, reducing communication costs.
[0169] 2. Smoke test:
[0170] Before initiating integration testing, first perform a smoke test on the entire integration environment to verify whether each service can work properly and avoid batch failures due to environmental problems during formal testing. This can improve the test case execution completion rate of integration testing, improve testing efficiency, and shorten the testing cycle.
[0171] Send a smoke test case to the top service in the integration environment. This case can come from the integration test case library and needs to be able to run through the entire call chain.
[0172] When executing smoke test cases, all related services in the entire integration environment are called in sequence. Each called service receives the request from the upstream service, forwards the request to the downstream service, and returns a response message to the upstream service after internal processing.
[0173] When a request is sent to an edge service that needs to call an external system in the integrated environment, if the external system does not meet the joint testing conditions, Mock processing is performed and the corresponding response message is returned to the edge service.
[0174] After being processed by a series of intermediate services, if everything is normal, the final response is returned to Service 1, and then returned to the original caller after being processed by Service 1.
[0175] The service monitoring component monitors and obtains the request and response messages received by each service and sends them to the MQ component.
[0176] The data storage component obtains the message from the MQ component, saves it in the time sequence of the message and the corresponding service information, and generates the execution details of the smoke test case.
[0177] When extracting data, the visualization component displays the request and response of each service on the call chain displayed on the front-end interface: if there is no error information in the response message, the node where the service is located is marked green; if there is an abnormal error in the response message, or the call times out, the node where the service is located is marked red to remind the tester that the service corresponding to the node has an abnormality. The tester can view the request received by the upstream and downstream node services of the service and the response message replied on the interface to troubleshoot the cause of the problem.
[0178] After troubleshooting, you can repeat the smoke test cases until all nodes are marked green, indicating that all services are working properly.
[0179] 3. Perform integration testing:
[0180] After smoke testing of the environment is completed and each service is verified to be running normally, integration testing is performed.
[0181] The whole process of performing integration testing is similar to that of smoke testing. The similarities are not repeated here. The differences are:
[0182] During integration testing, batch test cases are executed and services in the integration environment are called according to the test cases.
[0183] For each test case, the service monitoring component is used to track the transaction number generated in the service, and the transaction number generated by the downstream service in the same test case is replaced with the upstream transaction number to ensure that each test case uses the same transaction number during the integration test process.
[0184] Through the data storage component, the test case number, the time sequence of related messages of the same test case, and the environment information of the corresponding service are saved, and the execution details of each test case are generated.
[0185] The visualization component creates a call chain diagram for each use case on the front-end interface, showing the requests received and responses returned by each service.
[0186] The present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.
[0187] See attached Figure 2 , shows the structure of a service integration test system for implementing the above method, including an environment deployment module, a test execution module, a data storage module, and a visualization module.
[0188] The environment deployment module is used to deploy the tested service integration test environment and collect service information;
[0189] The test execution module is used to execute test cases, call services in the integrated environment according to the test cases, monitor and obtain requests received by each called service and response messages returned by downstream services;
[0190] The data storage module is used to generate execution details of corresponding test cases according to the service information and the request and response messages received by each called service;
[0191] The visualization module is used to create a call chain for each test case based on the execution details and display it on the front-end interface.
[0192] Figure 3 It is a schematic diagram of the main components of an embodiment of the present invention, including: a control component, a service monitoring component, a heartbeat component, a shared storage component, a visualization component, a data storage component, an MQ component and a Mock component.
[0193] Figure 4 This is a schematic diagram of the overall process of the integrated test of an embodiment of the present invention. Taking the microservice architecture as an example, the integrated environment includes service 1, service 2, ... service n and edge services. Each service includes a microservice, a service monitoring component and a heartbeat component: the service monitoring component monitors the microservice, and the heartbeat component notifies the service monitoring component to update the monitoring rules. Multiple services and edge services in the integrated environment are called according to test cases. When the edge service does not meet the test conditions, the corresponding service monitoring component sends a request to the Mock service outside the integrated environment and obtains a simulated response.
[0194] The control component obtains the service information reported by the heartbeat component and sends it to the data storage component for storage; uploads the monitoring rules to the shared storage component and sends instructions to the heartbeat component. The heartbeat component notifies the service monitoring component to download the monitoring rules from the shared storage according to the instructions. The MQ component receives the message sent by the service monitoring component and sends the message information to the data storage component for storage. After the data stored in the data storage component is aggregated, it is displayed through the visualization component.
[0195] Figure 5 This is a schematic diagram of the JVM sandbox environment of an embodiment of the present invention. The heartbeat component and the service monitoring component both run in the JVM sandbox environment. The entire JVM sandbox environment, the service monitoring component and the heartbeat component can be packed into a compressed package for remote download.
[0196] Figure 6 This is a schematic diagram of a visualization component according to an embodiment of the present invention, through which the integration service grouping and integration test results can be displayed.
[0197] Figure 7This is a visualization diagram of the integrated environment of an embodiment of the present invention. The integrated environment includes service 1, service 2, ... service n and edge services. Each service includes a microservice, a service monitoring component and a heartbeat component. After the heartbeat component is started, it collects current POD information and microservice information, and reports it to the control component. The reported content includes software, interface, method, current version, IP address, etc. After receiving this information, the control component sends it to the data storage component to save it to the disk, database or cache. The visualization component displays the microservice information saved in the data storage component on the front-end interface.
[0198] Figure 8 This is a schematic diagram of the smoke test of the integrated environment of an embodiment of the present invention. A smoke test case is sent to the top service in the integrated environment. All services in the entire integrated environment are called in sequence. Each called service receives a request from an upstream service, forwards the request to a downstream service, and returns a response message to the upstream service after internal processing.
[0199] When a request is sent to an edge service, if the external system does not meet the joint testing conditions, Mock processing is performed.
[0200] Send the request and corresponding message received by each service to the MQ component.
[0201] The data storage component obtains the message from the MQ component for storage and generates the execution details of the smoke test case.
[0202] The visualization component displays the request and response of each service on the call chain displayed on the front-end interface.
[0203] In addition, an embodiment of the present invention further provides a service integration testing device, including:
[0204] The environment deployment module deploys the integrated test environment of the tested service and collects service information; wherein, a service monitoring component and a heartbeat component are respectively set for each service in the integrated environment, the service information is collected through the heartbeat component and sent to the control component, the monitoring rules are set and effective through the control component, uploaded to the shared storage component, and a response information is sent to the heartbeat component, and the heartbeat component notifies the service monitoring component to download the monitoring rules from the shared storage component based on the response information.
[0205] A test execution module executes test cases, calls services in the integrated environment according to the test cases, monitors and obtains requests received by each called service and response messages returned by downstream services; wherein, services in the integrated environment are called according to the test cases, each called service receives a request sent by an upstream service, sends the request to a preset interface and method, and forwards the request to a downstream service, the called service processes the received request, and returns a response message to the upstream service; and through the service monitoring component, obtains the request received by the corresponding called service and the response message returned by the downstream service.
[0206] The data storage module generates execution details of the corresponding test case based on the service information and the request and response messages received by each called service; wherein, based on the service information and the request and response messages received by each called service, the test case number and transaction number are saved, and the execution details are generated for each test case.
[0207] A visualization module creates a call chain for each test case based on the execution details and displays it on the front-end interface; wherein the call relationship is analyzed according to the execution details, a call chain is created for each test case, the call chain is visualized in an image form, and is displayed on the front-end interface according to the execution order of the test cases.
[0208] Based on the same inventive concept, the present invention also provides a computer-readable storage medium storing one or more programs, which, when executed, can implement the aforementioned service integration testing method.
[0209] like Fig. 9 As shown, an embodiment of the present invention further provides a device, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus.
[0210] The memory is a computer-readable storage medium for storing one or more programs.
[0211] The processor is used to execute the program stored in the computer-readable storage medium.
[0212] The computer-readable storage medium may be included in the device / apparatus described in the above embodiments; or may exist independently without being assembled into the device / apparatus.
[0213] Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent substitutions for some of the technical features therein; and these modifications or substitutions do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A service integration testing method, characterized in that: include: Deploy the integrated test environment for the service under test and collect service information; Execute test cases, call services in the integrated environment according to the test cases, monitor and obtain the requests received by each called service and the response messages returned by the downstream services; Generate execution details of corresponding test cases according to the service information and the request and response messages received by each called service; Based on the execution details, a call chain is created for each test case and displayed on the front-end interface.
2. The method according to claim 1, characterized in that The deployment of the service integration test environment to be tested and the collection of service information include: A service monitoring component and a heartbeat component are respectively set for each service in the integrated environment; Collect service information through the heartbeat component and send it to the control component; The monitoring rules are set and validated by the control component, uploaded to the shared storage component, and a response message is sent to the heartbeat component; The heartbeat component notifies the service monitoring component to download monitoring rules from the shared storage component according to the response information.
3. The method according to claim 1, characterized in that The executing test case, calling the service in the integrated environment according to the test case, includes: Call services in the integration environment according to test cases; Each called service receives a request sent by an upstream service, sends the request to a preset interface and method, and forwards the request to a downstream service; The called service processes the received request and returns a response message to the upstream service.
4. The method according to claim 3, characterized in that The method further comprises: Through the service monitoring component, the request received by the corresponding called service and the response message returned by the downstream service are obtained.
5. The method according to claim 1, characterized in that The generating of execution details of the corresponding test case according to the service information and the request and response messages received by each called service includes: Based on the service information and the request and response messages received by each called service, save them according to the test case number and transaction number; For each test case, execution details are generated.
6. The method according to claim 1, characterized in that Based on the execution details, a call chain is created for each test case and displayed on the front-end interface, including: Analyze the call relationship according to the execution details and create a call chain for each test case; The call chain is visualized in a graphical form and displayed on a front-end interface according to the execution order of the test cases.
7. The method according to any one of claims 1 to 6, characterized in that: The deployment of the tested service integration test environment also includes: Packing the service monitoring component, the heartbeat component and the JVM sandbox environment into a package file, and providing a remote download method for the package file; When the POD containing the service is started, the packaged file is automatically downloaded through the remote download method; The packaged file is automatically decompressed to a preset directory, and the service monitoring component and the heartbeat component are started.
8. A service integration test system, characterized in that: The system comprises: The environment deployment module is used to deploy the integrated test environment of the tested service and collect service information; The test execution module is used to execute test cases, call services in the integrated environment according to the test cases, monitor and obtain the requests received by each called service and the response messages returned by the downstream services; A data storage module, used to generate execution details of corresponding test cases according to the service information and the request and response messages received by each called service; The visualization module is used to create a call chain for each test case based on the execution details and display it on the front-end interface.
9. The system according to claim 8, characterized in that The environment deployment module is also configured to: A service monitoring component and a heartbeat component are respectively set for each service in the integrated environment; Collect service information through the heartbeat component and send it to the control component; The monitoring rules are set and validated by the control component, uploaded to the shared storage component, and a response message is sent to the heartbeat component; The heartbeat component notifies the service monitoring component to download monitoring rules from the shared storage component according to the response information.
10. The system according to claim 8, characterized in that The test execution module is further configured to: Call services in the integration environment according to test cases; Each called service receives a request sent by an upstream service, sends the request to a preset interface and method, and forwards the request to a downstream service; The called service processes the received request and returns a response message to the upstream service.
11. The system according to claim 10, characterized in that The system is also configured to: Through the service monitoring component, the request received by the corresponding called service and the response message returned by the downstream service are obtained.
12. The system according to any one of claims 8 to 11, characterized in that: The environment deployment module is also configured to: Packing the service monitoring component, the heartbeat component and the JVM sandbox environment into a package file, and providing a remote download method for the package file; When the POD containing the service is started, the packaged file is automatically downloaded through the remote download method; The packaged file is automatically decompressed to a preset directory, and the service monitoring component and the heartbeat component are started.
13. A computer-readable storage medium storing one or more programs, characterized in that: When the one or more programs are executed, the service integration testing method described in any one of claims 1 to 7 can be implemented.
14. An electronic device comprising a processor, a communication interface, the computer-readable storage medium of claim 13, and a communication bus; wherein: The processor, the communication interface, and the computer-readable storage medium communicate electronically with each other via a communication bus; characterized in that: The processor is configured to execute a program stored in a computer-readable storage medium.