Method for testing accuracy of interconnection between microservices in system

Abstract

To detect a configuration error existing in a system.SOLUTION: A method to be executed by an information processing apparatus, for testing the accuracy of interconnections between microservices in a system includes: a test plan generation process which generates a test plan for processing E2E tests in parallel, based on ideal connection paths between the microservices and an E2E (end-to-end) test list; a path detection process that detects actual connection paths from a service mesh log indicating connections between the microservices; and a path comparison process that compares the actual paths with the ideal paths to identify inappropriate interconnections between containers.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present invention relates to a method for testing the correctness of interconnections between microservices in a system. [Background technology]

[0002] DevOps (Development and Operations) is an approach to software development that emphasizes collaboration and communication between development and operations teams. The goals of DevOps are to shorten development cycles, release software more frequently, and improve software quality.

[0003] To achieve these goals and ensure that the software being developed meets expected quality standards and fulfills its intended requirements, quality assurance (QA) processes help identify and resolve problems and misconfigurations in the code before it is deployed. Quality assurance (QA) processes are a critical aspect of DevOps. They help prevent costly and time-consuming rework and ensure that the software meets expected quality standards.

[0004] Additionally, the QA process helps improve the overall software development process by providing feedback to developers on how to improve their code and identifying areas where the development process can be optimized. This feedback helps to continuously improve the quality of the software and the efficiency of the development process.

[0005] However, even this feedback may not identify all possible misconfigurations within a system, and a poor QA review process can lead to significant security risks and costly and time-consuming post-deployment remediation.

[0006] There is a series of steps that allows for efficient and effective integration of QA. QA review processes are designed to identify and mitigate potential issues before they impact end users. These QA review processes include identifying the scope of the review, preparing test cases, running the tests, reporting issues, and resolving issues. In this way, the QA team can collaborate with the development and operations teams to ensure a high level of quality in software development.

[0007] As a technology related to QA, for example, Patent Document 1 discloses a technique for identifying system-level interconnections between microservices using access logs. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] US Patent Application Publication No. 2019 / 0286509 Summary of the Invention [Problem to be solved by the invention]

[0009] The method of Patent Document 1 utilizes access logs to identify system-level interconnections between microservices. However, if the system is functioning normally and error logs are not available, these methods cannot detect misconfiguration errors that may exist in the system. In this situation, security holes will occur in the system and additional costs will be incurred.

[0010] Additionally, testing methods that evaluate the entire application flow from start to finish may require parallelism to avoid the long processing times associated with sequential execution of end-to-end (E2E) tests that verify that all components behave as expected and that the application functions correctly in real-world scenarios. However, these methods may find it difficult to achieve parallelism, as logs may be polluted by the same microservices being used in parallel E2E tests.

[0011] The present invention has been made in view of the above background, and its purpose is to provide a method for testing the correctness of interconnections between microservices in a system, capable of detecting misconfigurations present in the system. [Means for solving the problem]

[0012] One of the present inventions for solving the above-mentioned problems is a method for testing the accuracy of interconnections between microservices in a system by an information processing device, in which the information processing device executes a test plan generation process for generating a test plan for parallel processing of end-to-end (E2E) tests based on ideal connection paths between microservices and an E2E test list, a route detection process for detecting actual connection paths from a service mesh log that indicates connections between microservices, and a route comparison process for identifying inappropriate interconnections between microservices by comparing the actual connection paths with the ideal connection paths. Effect of the Invention

[0013] According to the present invention it is possible to detect misconfigurations present in the system.

[0014] Other configurations and effects not specifically described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0015] [Figure 1] FIG. 2 is a schematic diagram showing an application server and its main functions. [Diagram 2] A diagram illustrating the main components of a Kubernetes cluster, which acts as a distributed operating system providing a multi-tenancy / multi-user environment. [Diagram 3] FIG. 1 illustrates the Kubernetes architecture including all the flow processes between different components of a Kubernetes cluster. [Figure 4] FIG. 1 illustrates a design architecture describing components, processes, and data flows between different components. [Diagram 5] FIG. 2 is a sequence diagram illustrating all the main processes of the method for detecting misconfigurations. [Figure 6] FIG. 2 is a diagram showing a hierarchy of test plans generated by the test plan generation unit. [Figure 7] 1 is a flowchart of a complete system process with test case looping operations. [Figure 8] FIG. 13 illustrates an example of input and output of a test plan generation unit. [Figure 9] 1 is a diagram illustrating input / output of a path detector and path detection processing. FIG. [Figure 10] FIG. 13 is a diagram for explaining a state in which an ideal connection path and an actual connection path are compared by a path comparison component, and is a diagram showing an example of a test case in which the ideal connection path and the actual connection path are different. [Figure 11] FIG. 13 is a diagram showing an example of a misconfiguration of a connection path including coding. [Figure 12] FIG. 13 illustrates an example of a new test plan in a loop operation when a previous test fails due to log contamination. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0017] To facilitate understanding of the present invention, a non-exhaustive list of definitions of some key terms is provided. Thus, as used in this specification, the term "microservices" refers to an application architecture that breaks down an application into various service components, as compared to traditional monolithic architectures. Similarly, in this specification, the terms "Kubernetes", "Kubernetes module", and "Kubernetes cluster" refer to an open-source container system or platform for orchestrating and automating software development, scaling, and management. The following description uses Kubernetes as the container platform, but other container orchestration and management platforms such as Openshift (trademark of Red Hat, Inc.), Docker Swarm (trademark of Docker, Inc.), Amazon ECS (trademark of Amazon Technologies, Inc.), etc. may be used instead. Additionally, the ideal connection path between microservices defines the correct path for two microservices to connect between different components of the system without bypassing security-related or other components.

[0018] FIG. 1 is a schematic diagram of an application server 100. The main components of the application server 100 are a communication module 101, a user interface module 102, and a Kubernetes module 103, which are configured to communicate with each other. Any one or more of the modules described herein are implemented using hardware (e.g., a processor or machine, etc.). For example, any module is executed by a processor configured to perform the processing described herein for that module. Furthermore, any two or more of these modules can be combined into a single module, and the functionality described herein for a single module can be subdivided among multiple modules. Furthermore, modules described herein as being implemented in a single machine, database, or device may be distributed across multiple machines, databases, or devices.

[0019] The communication module 110 receives data sent to the application server 100 and transmits data from the application server 100. For example, the communication module 110 can receive a request to use an application from a Kubernetes application programming interface (API) server via a virtual system. The request to use the application can identify a user, a client device, a tenant, or an appropriate combination thereof. The communication module 110 provides the data to the Kubernetes module 103. The route module 104, which is called by the Kubernetes module 103, determines which instance of the application to connect to the client device. The application server 100 executes an instance of the application and provides the application by communicating with the client device via a network (not shown). The tenant's data is stored in a database (not shown) via the database module 105 and the storage module 106, and the stored data is then accessed from the database.

[0020] The communication module 110 can transmit a user interface from the user interface module 102 to the client device. The user interface includes data of the application instance. The communication by the communication module 101 can be over a network. The user interface module 102 causes a user interface of the application server 100 to be displayed on a display associated with the client device. The user interface allows a user to interact with the application instance.

[0021] The application server 100 is provided with one or more Kubernetes modules 103, which include different application execution systems. All programming of the application tasks is done in the module by defining a rule set for all information processing. The routing module 104 sets up the flow of different processes with different inputs and outputs inside the Kubernetes module 103 and between different Kubernetes modules. The routing module 104 determines how data flows according to the rule set between different modules of Kubernetes.

[0022] FIG. 2 is a block diagram of a Kubernetes cluster 200 as one of such Kubernetes modules 103. The Kubernetes cluster 200 functions as a distributed operating system that provides a multitenancy / multi-user environment. The Kubernetes cluster 200 includes nodes 201A, 201B, and 201C. The Kubernetes master 205 of the Kubernetes cluster 200 receives a communication request from a client device to connect to an application hosted on the Kubernetes nodes 201A-201C. In this case, as shown in FIG. 2, the Kubernetes node 201A hosts an application instance 202 of application A, the Kubernetes node 201B hosts an application instance 203 of application B, and the Kubernetes node 201C hosts an application instance 204 of application C. This configuration indicates that from the perspective of the Kubernetes cluster 200, the system is a normal Kubernetes application. After the client device is connected to the application instance by the Kubernetes master 205, communication between the client device and the destination application instance (e.g., application instance 202 of application A) may be via the application instance.

[0023] FIG. 3 illustrates a Kubernetes architecture with all the flow processes between different components of a Kubernetes cluster used to complete a process. The entire process starts with a client request from a browser 301. This client request is received by a load balancer 302, which decides which Kubernetes cluster 200 to use to finish the process. According to that decision, the request is sent to an ingress controller 303 of the Kubernetes cluster 200, which specifies the routing rules for the incoming request. The ingress controller 303 acts as a reverse proxy / entry point in the Kubernetes cluster 316. According to the routing rules, the request sent from the client through the load balancer 302 reaches the ingress controller 303, from where it is redirected to the pod 310a / 310a via the cluster IP service 304 (ClusterIP).

[0024] The cluster IP service 304 has its own IP address 305 and port number 306, and handles requests from clients and also handles requests to be forwarded from one pod to another pod 310a / 310b in the Kubernetes cluster 316. Also, the cluster IP service 304 is generated across multiple nodes, thereby creating a single service in the Kubernetes cluster 316, so that it can receive requests from any port and forward them to any port on the pod. Each pod 310a / 310b has its own IP address 311a, 311b, which changes frequently. The pod 310a / 310b contains multiple containers 312a / 312b / 314a / 314b that run all processes according to a rule set. These containers 312a / 312b / 314a / 314b have their own port numbers 313a / 315a / 313b / 315b. Each of these pods is part of a node 307a / 307b and further has its own IP address 308a / 308b and port number 309a / 309b for communication.

[0025] Figure 4 is a diagram of the system design architecture showing the complete flow of a request through all the components of the system.

[0026] Generally, requests received from users via web application instances 416 are sent to the Kubernetes container platform 417 and processed based on an appropriate set of rules. The Kubernetes container platform 417 generates access logs 414 that are used to check if the system is functioning properly. These access logs are sent to a system checker 405 that monitors the access logs and performs system status checks. If the system checker 405 detects any problem in the system from the access logs 414, the problem is indicated in the graphical user interface (GUI) 401 through an error log 402. Thus, if the system is not functioning properly, it is identified by the system checker 405.

[0027] However, if the system is functioning properly and even if there is some misconfiguration, it can be detected by comparing the connection paths between the microservices for each request. In that case, the developer provides ideal connection path data 415 between the microservices in YAML file format 410 for each request from the user. The connection path data 415 is used as one input by the test plan generator 419. The test plan generator 419 also gets a list of test cases of E2E test 422 as another input. Using these two inputs, the test plan generator 419 generates a test plan 420, which enables parallel execution of multiple test cases. Note that the file format of the test case in the ideal connection path is the same as the file format of the test case in the actual connection path. In addition, in this embodiment, the format of the input file of the connection path is YAML, but the file format is not particularly limited to this, and any file format may be used as long as it is a data serialization language format such as YAML, JSON, CSV, XML file, etc.

[0028] The test plan 420 has multiple groups of test cases that are executed in parallel, and within those groups, the test cases are executed sequentially. This grouping is done to improve the overall performance of the E2E test and to avoid polluting the service mesh logs. The generated test plan 420 is then sent to the E2E test process 421, where some test cases pass and some test cases fail. Based on the test results 423, the list of failed test cases is sent to the test plan generator 419 for further processing. Note that a service mesh is a dedicated networking infrastructure layer responsible for managing and monitoring the communication between different microservices in an application. Service mesh logs are a record of application connections and requests that pass through proxies (such as sidecar proxies and gateways) in the service mesh.

[0029] Service mesh log data 413 is generated for all test cases that pass. The path detection unit 412 uses the service mesh log data 413 to analyze the service mesh log data 413 and generate an actual connection path YAML file 411. The ideal connection path YAML file 410 and the actual connection path YAML file 411 are then sent as input to the path comparison component 409. The path comparison component 409 compares the two files and checks for incorrect interconnections present in the system. If the path comparison component 409 detects an incorrect connection path between microservices, this is displayed on the GUI 401 as a list of incorrect connection paths 403. Based on the list, security risks 404 (present in a system that appears to function correctly without any error logs) are displayed to the user.

[0030] FIG. 5 is a sequence diagram illustrating the complete process flow of the system. The process starts when a user makes a request to the system, and a list of related test cases is generated based on the request. In step S1, the test plan generator 419 generates a test scenario plan using the ideal connection path of the test case. In step S2, the E2E test tool 503 executes the E2E test using the test scenario plan generated in step S1. In step S3, the E2E test results are classified into a pass test scenario group and a fail test scenario group. The failed test scenario group is used in the next loop operation, and the passed test scenario group is used to generate a service mesh log 506 for the next step. In step S4, the path detector 504 generates an actual connection path using the service mesh log, and sends the actual connection path to the path comparison component 409. In step S5, the path comparison component 409 compares the ideal connection path and the actual connection path, and generates a comparison result. At this point, the user can decide whether to execute the next loop operation, since the failure may be caused by a problem other than a path problem. When the user starts the next loop operation, the test plan generator 419 uses the failed test scenario group to generate a new test plan 507. Then, the process from step S2 is repeated.

[0031] FIG. 6 illustrates the test hierarchy used to generate a test scenario plan in step S1 of the sequence diagram in FIG. 5. The test scenario plan mainly has different test scenario groups (TSG) 601. Each test scenario group (TSG) 601 is composed of a set of multiple test scenarios (TS) 602, which in turn is a set of multiple test cases (TC) 603. During the test process, each test scenario group 601 is executed one by one. In contrast, the test scenarios 602 of any test scenario group 601 can be executed in parallel because each test scenario 602 has a different microservice 604. This ensures that there is no log pollution between the test scenarios 602. The test cases 603 of each test scenario 602 are executed in sequence. Log pollution in a service mesh refers to the phenomenon in which the records of a microservice in one test case are mixed with the records of the same microservice in another test case, making it impossible to track the actual connections, for example, when the same microservice is used simultaneously in different test cases of related test scenarios in a particular test scenario group.

[0032] FIG. 7 is a flow chart of the complete system process with looping operations for test plan generation of test cases.

[0033] When a user makes a request to an application, a list of test cases is created based on the request. A developer first prepares ideal connection paths for all test cases used during operation. In step S701, the test plan generator 419 receives as input a list of test cases of a current request by a user and an ideal connection path for each of these test cases. In step S702, the test plan generator 419 checks the microservices used in all test cases and creates a list of microservices for each test scenario. Considering the microservices used in the test scenarios, the test plan generator 419 creates a set of test scenarios that do not have the same microservices and are grouped into test scenario groups. Such test scenarios can be executed in parallel without the risk of polluting the service mesh logs.

[0034] In S703, the test plan generation unit 419 determines the execution order of the test scenario groups in which the test scenarios are executed in parallel. Then, the E2E test tool 503 executes the E2E test according to the test plan. If a test fails in any of the test cases of a particular test scenario group, the test scenario group is considered to be a failed test scenario group, and all test cases and test scenarios related to the test scenario group are considered to have failed. The reason is that if one test case in a test scenario group fails, the failed test case may use a microservice different from the microservice specified in the ideal connection path YAML file, which may cause log pollution. Therefore, in step S704, the test scenario group in which all test cases pass is separated from the test scenario group containing the failed test cases, and the failed test scenario group is used in the next loop operation.

[0035] In step S705, the user decides whether to execute the loop operation as a new test plan. If the test case fails due to the presence of a microservice different from that specified in the ideal connection path YAML file, in step S706, the new test plan including the failed test scenario group itself is divided into a test scenario group of the failed test case and a test case scenario group of the remaining test cases. On the other hand, if the test case fails due to a problem in the system and does not fail due to a microservice different from that specified in the ideal connection path YAML file, the developer needs to change the source code, so the loop operation is not continued.

[0036] In step S707, the path detection unit 412 generates service mesh log data for the test scenario group that passed, and uses the generated mesh log data to collect the service mesh log data of each test and extract communication information of the microservices. In step S708, the path detection unit 412 identifies interconnections between microservices and generates an actual connection path YAML file. In step S709, the path comparison component 409 compares the ideal connection path with the actual connection path to detect erroneous interconnections between microservices.

[0037] FIG. 8 illustrates the test plan generation process with examples of input and output data. The test plan generator 419 uses two inputs: a list of test cases 801 related to user requests and an ideal connection path YAML file 802 for each test case. Input 1 in FIG. 8 is an example of a list of test cases 801 in an E2E test process. It has multiple test scenarios such as general test and login test, and includes various test cases such as TC1a, TC1b, etc. Each test case uses different microservices. For example, TC1a uses microservices MS1, MS3, and MS4. From input 2, which is the ideal connection path 801, the related microservices for various test cases are identified. Based on the microservices of each test case, a list of microservices related to the test scenario is generated. For example, TS1 uses microservices MS1, MS3, and MS4. Based on this information, a test scenario group is generated that includes various test scenarios that use various microservices. For example, TSG1 803 includes TS1, TS3, TS7, and TS9.

[0038] All these test scenarios have different microservices. Therefore, all these test scenarios can be processed in parallel. However, in each test scenario, related test cases are executed in order. After generating the test scenario groups, the test plan generation unit 419 determines the order of test processing. For example, in the test plan shown by the reference numeral 804, TSG1 is executed first, TSG2 is executed next, and TSG3 is executed last.

[0039] FIG. 9 illustrates how the path detector 412 identifies the actual connection path from the service mesh log data. As shown in FIG. 9, the service mesh log data 901 includes various information. In the front-end microservice, the value of upstream_cluster includes “outbound” including the domain name, whereas in the catalog microservice, the value of upstream_cluster includes “inbound”. According to this information, the path detector 419 determines the source and destination 902 of the request. Here, the front-end microservice is considered as the source and the catalog microservice is considered as the destination. Similarly, each source and destination microservice related to the request is identified from the complete access log details. Based on the information, the complete path of the request is identified, as shown in box 903. In this example, the connection path is microservice 1, microservice 2, ..., microservice 5. With such information, the path detector 412 generates actual path YAML files 904 for all test cases of the E2E test.

[0040] Figure 10 shows an example of how the path comparison component 409 compares ideal and actual connection paths. As shown in Figure 10, the input 1001 to the path comparison component 409 includes an ideal connection path YAML file 1003 provided by the developer and an actual connection path YAML file 1002 generated by the path detector. For each test case, the path comparison component 409 compares these two YAML files and detects differences, if any, between them. These differences may be due to misconfigurations in the application (which is otherwise functioning properly).

[0041] An example of this difference is shown as a dashed area 1004 that spans the actual connection path YAML file 1002 and the ideal connection path YAML file 1003. Here, in the ideal connection path, the output from MS3 is ingress, and the output from ingress is MS4. Therefore, the path goes from MS3 to MS4 via ingress. In contrast, in the actual connection path, the output from MS3 goes directly to MS4. This means that the actual connection path (connection from MS3 to MS4) bypasses ingress, which is an error. Alternatively, the user may have deployed a web application firewall (WAF) at ingress. In this case, if the connection from MS3 to MS4 bypasses ingress, the WAF security rules set at ingress will also be bypassed. This is a security hole that exists in the system due to a code misconfiguration.

[0042] Figure 11 shows an example of the above-mentioned misconfiguration, i.e., a misconfiguration of the connection path, along with the coding. In this case, microservice A connects directly to the Kubernetes service endpoint of microservice B instead of to the ingress, bypassing the ingress and the associated ingress WAF rules. As a result, the WAF rule set is not applied to the traffic between microservice A and microservice B, which creates a security risk from the perspective of the zero trust model.

[0043] It should be noted that such errors are not detected by the system checker. If a misconfiguration error occurs because a test case uses a different microservice contrary to what is specified in the ideal connection path, the error is caused by log pollution where the same microservice is used in another test case related test scenario in one test scenario group. If this kind of error occurs (i.e., there are logs generated as a result of multiple E2E tests using the same microservice at the same time), a new test plan is generated that separates the test cases that include the microservice that is different from the ideal connection path from the other test cases in the test scenario group. As a result, as shown in Figure 10, if the TC1a test case uses a different microservice than the one specified in the ideal connection path YAML file, the related test scenario TS1 of TC1a is separated from the other test scenarios of TSG1. The new test plan would then have TSG1a with TS1 and TSG1b with TS3, TS7, and TS9, as shown in block 1005.

[0044] FIG. 12 is an example of a new test plan in a loop operation when the original test fails due to log contamination. Box 1101 shows a test scenario group TSG1 that describes the related information of test cases and microservices based on the ideal connection path YAML file. As shown by the dashed line 1102, the microservices related to test case TC1b are MS1 and MS3. When the E2E test is executed according to the test plan, TC1b is considered as a failed test case because it has a different connection path from the ideal connection path YAML file. That is, in the actual connection path YAML file, the microservices related to test case TC1b are MS1, MS2, and MS3, as shown by the dashed line 1104. Due to these different microservices of test case TC1b, the related service mesh log is contaminated with TC3a and TC3b, and this service mesh log also uses microservice MS2. This is not an error caused by the source code, but an error caused by the difference between the ideal connection path and the actual connection path. To avoid this test failure in the new test plan for the loop operation, test scenario group TSG1 is split into TSG1a and TSG1b, as shown in box 1106. Test scenario group TSG1a includes test scenario TS1, while test scenario group TSG1b includes test scenarios TS3, TS7, and TS9.

[0045] The method of the present embodiment allows detection of misconfigurations in an otherwise correctly functioning system, and allows for parallel execution of multiple test cases to increase the speed of E2E test execution without risking log pollution.

[0046] As described above, the method for testing the correctness of interconnections between microservices in a system of the present embodiment includes a step of generating a test plan for parallel processing of end-to-end (E2E) tests using a test plan generator. The method then generates actual connection paths from a service mesh log indicating connections between the microservices using ideal connection paths between the microservices, an E2E test list, and a path detector. The method then uses a path comparison component to compare the results of the actual connection paths and the ideal connection paths to identify improper interconnections between the microservices. The ideal connection paths for each test case are provided by a user in the form of a YAML file that specifies the microservices to be used for the E2E tests. This allows for the detection of misconfigurations present in an otherwise correctly functioning system. The method then allows for the improvement of the quality assurance (QA) review process for development and operations (DevOps).

[0047] In addition, this method tests the correctness of interconnections between microservices by comparing the ideal connection path and the actual connection path between microservices for each test case in the E2E test, allowing multiple test cases to be run in parallel, improving the efficiency of the entire process.

[0048] Also, in this method, the user provides data in the form of a YAML file regarding the ideal connection paths between microservices for each test case. These connection path data along with the list of all test cases are sent to the test plan generator. The test plan generator uses this input to analyze the microservices used in each test case in the test case list. Based on these, the test plan generator generates a test plan that contains a set of test cases that can be executed in parallel without polluting the service mesh logs for various test cases. This configuration increases the execution speed of all test cases. After creating the test plan, the E2E testing tool executes all tests accordingly and separates the successful and failed test cases. The passed test cases are used in the next part of the process, while the failed test cases are checked by the user for relevant errors, after which the E2E testing process is used in the next loop.

[0049] For the passed test cases, a service mesh log is generated, and the path detector 412 uses the generated service mesh log to generate actual connection paths between the microservices for each test case. These newly generated actual connection paths and the ideal connection paths specified by the user are sent to the path comparison component to be compared with the connection paths associated with each test case to see if the actual connection paths are different from the ideal connection paths. If they are different, it is considered a misconfiguration present in the system, but cannot be detected by E2E testing. And although the system still functions normally despite this misconfiguration, it is still a security hole in the system and needs to be fixed before the system is deployed in a production environment.

[0050] The present invention is not limited to the above-described embodiment, and can be implemented using processes and components other than those specifically described in this specification without departing from the scope of the present invention. Therefore, the above-described embodiment and modifications are merely examples, and the present invention is not limited to these contents as long as the characteristics of the present invention are not impaired. In addition, although various embodiments and modifications have been described above, the present invention is not limited to these, and other aspects that are conceivable within the scope of the technical idea of ​​the present invention are also included in the scope of the present invention. [Explanation of symbols]

[0051] 100 Application server, 409 Path comparison component, 412 Path detection unit, 415 Test plan generation unit

Claims

1. 1. A method for testing by an information processing device to verify interconnections between containers in a system, comprising: The information processing device includes: A first input is an end-to-end (E2E) test list configured with a test scenario including a plurality of E2E test cases; a test plan generation process for generating a test plan for processing a plurality of E2E tests in parallel, the test plan generation process using a predetermined ideal connection path between containers as a second input; A route detection process for detecting an actual connection route from a service mesh log indicating a connection between the containers; and a path comparison process for identifying inappropriate interconnections between containers by comparing the actual connection paths with the ideal connection paths.

2. 2. The method of claim 1 , The ideal connection path for each test case is specified with a container used for the E2E test.

3. The information processing device includes: In the test plan generation process, the ideal connection path between containers of each test case and the E2E test list are used to avoid log pollution caused by the same container being used in different E2E tests executed in parallel. The method of claim 2.

4. The information processing device, In the test plan generation process, the results of the E2E tests are collected, failed tests are separated into different test groups, and the results of the failed tests are reflected in the next E2E test to be executed, thereby creating a feedback loop consisting of successive E2E test processes. The method of claim 1.

5. The information processing device, In the path comparison process, comparing the ideal connection path with the actual connection path by checking whether there are different containers used for test cases or whether there are wrong destinations or destinations of requests; The method of claim 1.

6. The information processing device, In the test plan generation process, if log contamination occurs, the test cases of one test scenario group are split into multiple test scenario groups. The method of claim 1.

7. The information processing device, outputting a processing result of the route comparison processing, the processing result indicating connection points between the containers where a security risk may occur from the perspective of a zero trust model; The method of claim 1.

8. 2. The method of claim 1 , The ideal connection paths for each test case are output in the form of a data serialization language file that specifies the microservices to be used for the E2E tests.

9. 9. The method of claim 8, The method wherein the data serialization language file format is a YAML file.

Images