Test support device, test support method, and test support system

Abstract

To make it possible to shorten a test execution time that involves switching between multiple test environments, in development work on the assumption of a micro-service architecture.SOLUTION: A test support device 100 includes: a reception unit 110 that receives a description file about multiple test environments, specifying a normal or abnormal state for each test case regarding each component that constitutes a test target; a merging unit 111 that identifies, based on commonality of the components, a merge target between the multiple test environments based on the description file, and merges the test environments; an order determination unit 112 that optimizes a switching order of the test environments based on a switching operation amount between the test environments; and a script generation unit 113 that generates a script for switching test environments and executing test cases based on each test environment and the switching order.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a test support device, a test support method, and a test support method. [Background technology]

[0002] Microservices architecture is an architecture in which applications are developed as a collection of loosely coupled microservices. When developing applications using this architecture, it is necessary to perform integration tests and system tests while building or switching between multiple test environments depending on the number of microservices and their combination patterns.

[0003] Therefore, a technology has been proposed that takes into account the test execution order to shorten the test execution time regardless of whether or not tests are skipped (see Patent Document 1). This technology focuses on the problem that, when a technique for skipping tests by selectively choosing which tests to skip is adopted to shorten the test period in a situation where the same test cases are frequently executed, it cannot be applied when skipping tests is not permitted for development reasons.

[0004] More specifically, this technology relates to a method for determining the order of test cases to be executed by a computer, the computer having an arithmetic unit that executes a predetermined arithmetic process and a storage device connected to the arithmetic unit, and the order determination method is characterized in that the arithmetic unit determines the test execution order of a software test based on the dependency relationships of nodes included in a source program to be tested given in a tree structure. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Publication No. 2022-163410 Summary of the Invention [Problem to be solved by the invention]

[0006] The above-mentioned conventional technology discloses a technique for executing tests while switching test environments in a CI / CD pipeline (CI: Continuous Integration, CD: Continuous Delivery). By applying appropriate analogy to this technology, it may be possible to execute tests involving switching test environments in integration tests and system tests of application services in a microservice architecture.

[0007] However, these conventional technologies require that the program being tested has a tree structure. However, switching between abnormal test environments requires more complex support than simply responding to the tree structure. Therefore, it is difficult to reduce test execution time by adopting conventional technologies when developing applications based on a microservice architecture.

[0008] Therefore, an object of the present invention is to provide a technology that enables shortening the execution time of tests that involve switching between multiple test environments in development work based on microservice architecture. [Means for solving the problem]

[0009] The test support device of the present invention, which solves the above-mentioned problems, is characterized by comprising: a receiving unit that receives from a terminal description files for multiple test environments, which specify the normal or abnormal states for each test case for each component that constitutes the software to be tested; a merging unit that, based on the description files, identifies combinations of the multiple test environments that, based on at least the commonality of the components, do not affect each other's execution as merger targets, and merges the test environments to be merged; an order determination unit that optimizes the test environment switching order based on the amount of switching operations between each test environment, including the merged test environment after the merger; and a script generation unit that generates scripts that are responsible for switching test environments and executing test cases corresponding to the test environments, based on each test environment, including the merged test environment, and the switching order.

[0010] In addition, the test support method of the present invention is characterized in that an information processing device receives from a terminal description files for multiple test environments, which specify the normal or abnormal states for each test case for each component that constitutes the software to be tested; based on the description files, identifies combinations of the multiple test environments that are in a relationship that does not affect each other's execution, at least based on the commonality of the components, as merger targets, and merges the test environments to be merged; optimizes the test environment switching order based on the amount of switching operation between each test environment, including the merged test environment after the merger; and generates a script that switches the test environment and executes test cases corresponding to the test environment, based on each test environment, including the merged test environment, and the switching order.

[0011] The test support system of the present invention is also characterized by including a test support device that includes: a reception unit that receives from a terminal description files for multiple test environments, which specify normal or abnormal states for each test case for each component that constitutes the software to be tested; a merging unit that, based on the description files, identifies combinations of the multiple test environments that, based on at least the commonality of the components, do not affect each other's execution as combinations to be merged, and merges the test environments to be merged; an order determination unit that optimizes the order of switching test environments based on the amount of switching operation between each test environment, including the merged test environment after the merger; and a script generation unit that generates scripts that switch test environments and execute test cases corresponding to the test environments, based on each test environment, including the merged test environment, and the switching order. [Effects of the Invention]

[0012] According to the present invention, it is possible to reduce the execution time of tests that involve switching between multiple test environments in development work that is based on a microservice architecture. [Brief explanation of the drawings]

[0013] [Figure 1] 1 is a diagram illustrating a network configuration including a test support device according to an embodiment of the present invention. [Figure 2] FIG. 2 is a diagram illustrating an example of a hardware configuration of a test support device according to the present embodiment. [Figure 3] FIG. 10 is an explanatory diagram showing a conceptual example of test environment merging and test environment switching order in this embodiment. [Figure 4] FIG. 1 is a diagram showing Example 1 of a test environment description format in this embodiment. [Figure 5] FIG. 10 is a diagram showing Example 2 of a test environment description format in this embodiment. [Figure 6] FIG. 2 is a diagram showing an example of the format of a test environment description file in this embodiment. [Figure 7]FIG. 10 is a diagram illustrating a first example of a determination as to whether or not a test environment can be merged in this embodiment. [Figure 8] FIG. 10 is a diagram illustrating a second example of a determination as to whether or not a test environment can be merged in this embodiment. [Figure 9] FIG. 10 is a diagram illustrating a third example of a determination as to whether or not a test environment can be merged in this embodiment. [Figure 10] FIG. 10 is a diagram illustrating a fourth example of a determination as to whether or not a test environment can be merged in this embodiment. [Figure 11] FIG. 10 is a diagram illustrating a fifth example of a determination as to whether or not a test environment can be merged in this embodiment. [Figure 12] FIG. 10 is a diagram illustrating a sixth example of a determination as to whether or not a test environment can be merged in this embodiment. [Figure 13A] FIG. 10 is a diagram illustrating a first conceptual example of a test case group in this embodiment. [Figure 13B] FIG. 10 is a diagram illustrating a first conceptual example of a test case group in this embodiment. [Figure 14] FIG. 10 is an explanatory diagram showing a conceptual example of script generation after a test environment is established in this embodiment. [Figure 15] FIG. 1 is a diagram illustrating an example of a flow of a test support method according to the present embodiment. [Figure 16] FIG. 10 is a diagram illustrating an example of a complete graph division concept in this embodiment. [Figure 17] FIG. 10 is a diagram illustrating a solution concept for the test environment switching order in this embodiment. [Figure 18] FIG. 10 is a diagram illustrating an example of a script generation flow according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0014] <Network configuration> An embodiment of the present invention will be described in detail below with reference to the drawings. Fig. 1 is a diagram showing a network configuration including a test support device 100 according to this embodiment. The test support device 100 shown in Fig. 1 is a computer that enables shortening the execution time of tests that involve switching between multiple test environments in development work based on a microservice architecture.

[0015] 1, the test support device 100 of this embodiment is communicably connected to a user terminal 200 and a test environment 5 via an appropriate network 1 such as an in-house network or the Internet. Therefore, these may be collectively referred to as a test support system 10.

[0016] The test support device 100 of this embodiment can be said to be a service device that supports the person in charge of application development using a microservice architecture in the construction or switching of a test environment. Note that the test environment corresponds to the environment in which an integration test or a system test is performed, and more specifically, is a local machine or a cluster on which multiple microservices are running.

[0017] 1, the test support device 100 in this embodiment has the following functional units: a reception unit 110, a merging unit 111, an order determination unit 112, and a script generation unit 113. Details of each of these functional units will be described later, but the various processes of the test support method of the present invention are executed by these functional units working together appropriately.

[0018] The aforementioned personnel are assumed to be testers. These testers will be responsible for performing integration tests and system tests in the development of applications and services that use the microservice architecture described above. Given the nature of this work, it is important to reduce the time required for testing. This is because, in work that revolves around agile development and CI / CD, development teams may commit to development work more frequently than once a day, making it important to provide rapid feedback of test results to the development team.

[0019] It is also possible to imagine a configuration in which the user terminal 200 or the implementation system of the test environment 5 itself has the configuration and functions of the test support device 100 of this embodiment.

[0020] On the other hand, the user terminal 200 is a terminal used by the developer or the like when exchanging information with the test support device 100. Specifically, a personal computer, a tablet terminal, a smartphone, or the like can be envisioned.

[0021] <Hardware configuration> 2 shows the hardware configuration of the test support device 100 of this embodiment. The test support device 100 includes a storage device 101, a memory 103, a calculation device 104, and a communication device 105.

[0022] The storage device 101 is configured with an appropriate nonvolatile storage element such as a solid state drive (SSD), a hard disk drive (HDD), or various storage media. Note that various storage media can be used, such as a compact disk (CD), a DVD, or a magnetic tape.

[0023] The memory 103 is configured with volatile storage elements such as a random access memory (RAM), a dynamic random access memory (DRAM), and a static memory (SRAM).

[0024] The arithmetic device 104 is a processor that executes the program 102 stored in the storage device 101 by reading it into the memory 103, thereby controlling the device itself and performing various judgments, calculations, and control processes. As a specific implementation form of the arithmetic device, for example, a device such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or a DSP (Digital Signal Processor) can be appropriately adopted.

[0025] The communication device 105 is assumed to be a communication chip or interface card compatible with various network protocols, which is connected to the network 1 and handles communication processing with the user terminal 200 and the test environment 5. The type of network 1 may be the Internet, a LAN (Local Area Network), or a public line network such as a mobile phone or a satellite line, as appropriate.

[0026] It is preferable that the test support device 100 further includes input devices such as a keyboard and a mouse that directly accept key input or voice input from appropriate users such as administrators, and output devices such as a display and a speaker that display processed data.

[0027] In addition to a program 102 for implementing functions required for the test support device of this embodiment, at least storage units 125 to 130 for various information are stored in the storage device 101. However, details of each of these storage units 125 to 130 will be described later. In addition, for example, function blocks of a general CI / CD pipeline are stored in a callable manner in the storage device 101 or in an external device on the network 1.

[0028] A CI / CD pipeline consists of a workflow that manages a series of jobs from application development, testing, and deployment. It is assumed that this workflow is predefined in a specific configuration file. The script generation process, which will be described later, is also assumed to be automated by calling a template set prepared in advance by the pipeline service according to the content and setting parameters for generation.

[0029] <Concept of merging test environments and optimizing the switching order> Next, a description will be given of the basic concept of test environment merging and switching order optimization executed by the test support device 100 of this embodiment. Fig. 3 shows an example of the concept of test environment merging and test environment switching order optimization in this embodiment.

[0030] In the test support device 100 of this embodiment, the reception unit 110 acquires a test environment description file 1252 from the terminal 200. This test environment description file 1252 is created on the terminal 200 by, for example, a person in charge of development or testing writing to a template test environment description format 1251. Examples of this test environment description format 1251 are shown in FIGS. 4 and 5.

[0031] In the example shown in Figure 4, values are set for each item related to abnormal states, such as "stopped," "sluggish processing," and "stub replacement," for each test case. In the example shown in Figure 5, test environments are referred to as groups, and the test cases to be executed for each group and the microservices in abnormal states, such as stopped, are described. In any case, this format is merely an example and is not particularly limited. In this embodiment, the format shown in Figure 6 is assumed, in which the person in charge sets actual values in the format shown in Figure 5.

[0032] 5, the test environment description file 1252 describes that the "normal services" among the microservices are "A001," "B003," ..., and the "abnormal services" replaced with stubs are the target "C001" and the stub is "Z006," "stop" is "D001," "thread count reduction" target is "E003" and the "number of threads" is "1," and "timeout" target is "F001," and the test cases to be executed for this test environment are those from start "001" to end "030" and those from start "201" to end "230." In other words, the test environment description file 1252 describes the normal / abnormal states of each component (corresponding to a microservice) that constitutes the test environment 5, as well as the test cases to be executed for the test environment 5.

[0033] If the test environment description file 1252 describing these normal and abnormal environments is shown in the form of a microservice architecture, it becomes the test environments 5 "before merger and order optimization" in Figure 3. In the example of Figure 3, four test environments 5 are assumed. Furthermore, these test environments 5 are composed of a "normal test environment" and "abnormal test environments (1)" to "abnormal test environments (3)."

[0034] The receiving unit 110 stores this test environment description file 1252 in the test environment storage unit 125, preparing it for use by other processing units. Meanwhile, the merging unit 111 reads the above-mentioned test environment description file 1252 from the test environment storage unit 125, and executes appropriate merging processing of the test environments 5 based on the test environment description file 1252. In this case, the merging unit 111 identifies, as merge targets, combinations of multiple test environments that do not affect each other's execution, based on at least the commonality of components, i.e., microservices.

[0035] When identifying merge targets based on the commonality of the above-mentioned components, the merging unit 111 identifies a set of test environments that can be merged based on the existence and attributes of those common to the test environments among the series of microservices that make up the test environments 5. Figure 3 shows a situation in which, of the test environments 5 listed in the "Before merger and order optimization" column, the "abnormal test environment (1)" and the "abnormal test environment (2)" have been determined by the merging unit 111 to be test environments that can be merged.

[0036] One of the criteria for identifying merger targets is that a set of microservices including an abnormal microservice must have different configurations, i.e., they do not contain any common microservices. Microservice configurations that meet this criterion are shown as Case 1 in Figure 7 and Case 2 in Figure 8.

[0037] In addition, there is also a criterion that the microservices included in a set of microservices must be common across test environments, and that the microservices in question must have the same abnormal state settings across test environments. Microservice configurations that meet this criterion are shown as Case 3 in Figure 9, Case 4 in Figure 10, Case 5 in Figure 11, and Case 6 in Figure 12.

[0038] The series of microservices described above can also be thought of as microservices that have a data exchange relationship and can be arranged along the flow of data exchange. In this case, as shown in Figure 13A, it is generally assumed that a front-end microservice receives a processing request, and each microservice sequentially executes processing, providing the processing results as input to the next microservice, and the results of the terminal microservice are returned to the front-end microservice via the return path, which is the same as the outbound path. However, as shown in Figure 13B, it is also possible to assume a case where the return path is different from the outbound path.

[0039] Based on these criteria, the merging unit 111 determines whether or not to merge each of the test environment description files 1252 and identifies the test environment to be merged. In the example of Figure 3, "Abnormal test environment (1)" and "Abnormal test environment (2)" are identified as the ones to be merged, and the form in which the merging unit 111 merges them is illustrated in the line "After merger and order optimization." In the "Abnormal service" column of the merged test environment description file 1252, the microservice names listed in the "Abnormal service" column of each of the test environment description files 1252 to be merged are described in a merged form.

[0040] After the test environment merging unit 111 has thus executed the test environment merging, the order determining unit 112 determines the test environment switching order. The order determining unit 112 optimizes the switching order between each test environment, including the merged test environment (the merged "abnormal test environment (1)" and "abnormal test environment (2)" in FIG. 3) that has undergone the above-described merging. This optimization is performed based on the amount of operation involved in the switching, and details of this will be described later.

[0041] <Script generation concept> FIG. 14 shows a conceptual example of script generation after the test environment is established in this embodiment. The script generation unit 113 of the test support device 100 is assumed to be implemented by calling an existing script generation service or the like. However, a corresponding program may be pre-installed as a function of the test support device 100. The script generation unit 1113 generates a script 1301 by having the automatic generation tool 1131 read the target test environment description file 1252. The script 1301 is a so-called pipeline definition file. By executing this pipeline definition file with respect to the test environment 5, specified test cases are automatically executed in sequence, assuming the configuration and status (normal / abnormal) of each microservice described in the test environment description file 1252. In other words, a test is executed.

[0042] <Flow example: Example of test support method flow> The actual procedure of the test support method according to this embodiment will be described below with reference to the accompanying drawings. The various operations corresponding to the test support method described below are realized by a program that is read into memory or the like and executed by the test support device 100. This program is composed of code for performing the various operations described below.

[0043] 15 is a diagram showing an example of a flow of the test support method according to this embodiment. In this flow, the receiving unit 110 of the test support device 100 receives test environment description files 1252 relating to multiple test environments 5 with different settings from the terminal 200, and stores them in the test environment storage unit 125 (S10).

[0044] Next, as already mentioned, the merging unit 111 of the test support device 100, based on the test environment description file 1252 obtained from the terminal 200 for each test environment 5, identifies combinations of microservices with specific attributes (e.g., those in an abnormal state) between those test environments that do not affect each other's execution as targets for merging (S11).

[0045] The criteria for identifying the above-mentioned merger targets are: a set of microservices including a microservice in an abnormal state, but the microservices have different configurations, i.e., they do not contain any common microservices; another criterion is that the set of microservices includes a microservice that is common across test environments, but the microservice in question has the same abnormal state setting across the test environments.

[0046] Based on these criteria, the merging unit 111 determines whether or not to merge the test environment description files 1252 and identifies the test environment to be merged. The merging unit 111 merges the test environments to be merged identified in S11 above (S12). After this merging, the "Abnormal Service" column in the test environment description file 1252 is written in a merged form with the microservice names that were listed in the "Abnormal Service" column of each of the test environment description files 1252 to be merged.

[0047] After the merging unit 111 executes the test environment merging, the order determination unit 112 determines the test environment switching order (S13). In this case, the order determination unit 112 optimizes the switching order between each test environment including the merged test environment that has undergone the merging as described above. This optimization is performed based on the amount of operation involved in the switching. This optimization will be described with reference to Figs. 16 and 17.

[0048] In this case, the order determination unit 112 generates a graph connecting test environments that can be executed simultaneously with lines for each test environment, including the merged test environment (hereinafter referred to as the merged test environment) after the necessary merging in the processing up to this point. This graph may be generated in the memory 103 of the test support device 100, but graph display data may be distributed to the terminal 200 as necessary. Test environments that can be executed simultaneously can be identified based on criteria such as the type and level of computer resources used by the microservices and whether there are any issues with conflicts in the call relationships of external services and devices.

[0049] Furthermore, the order determination unit 112 identifies multiple test environments that are executed and completed in a series of steps by solving the problem of dividing the test environment into complete graphs. In this case, the order determination unit 112 identifies a part of the above-mentioned graph that is a so-called complete graph. A complete graph is a graph in which there is an edge between any two vertices, i.e., a line connecting the two vertices.

[0050] The order determination unit 112 divides the graph into a complete graph portion (FIG. 16) and solves the traveling salesman problem for the group of test environments that make up this complete graph. The traveling salesman problem is a problem of determining the most efficient order in which a salesman should visit multiple customers, i.e., the order that minimizes the route length and travel time. Therefore, the order determination unit 112 is assumed to have a solver for the traveling salesman problem stored in advance, or to be available by calling it up at any time from an external service via the network 1.

[0051] The order determination unit 112 uses a solver to solve a traveling salesman problem based on a complete graph to obtain an optimal solution for the test environment switching order. In this solution, the objective function is not the path length or travel time, but rather the switching cost (costs such as the number of steps and processing time) between each test environment. Figure 17 shows the solution concept for the test environment switching order in this embodiment. In the example of Figure 17, the normal test environment is set as the test start environment, and the test is switched to the merged test environment, normal test environment (2), normal test environment (3), in that order, and finally the test ends in the abnormal test environment (3). This identifies a path.

[0052] The script generation unit 113 of the test support device 100 generates a script for executing the test cases based on each test environment, including the merged test environment, obtained in the above-described processes and the switching order between them (S14), and then ends the process. The script generated here is stored in the generated script storage unit 130 by the script generation unit 113, and is called and executed as appropriate when a test is executed thereafter.

[0053] 18 is a diagram showing an example of a script generation flow in this embodiment. In this flow, the script generation unit 113 generates a test environment construction script for the first merged test environment in the order specified (optimized) in S13 (S20) (which may not have been the target of merging). As already mentioned, this test environment construction script is a pipeline definition file, and is generated by calling the automatic generation tool 1131 or an existing script generation service, etc.

[0054] Furthermore, the script generation unit 113 adds a test execution command to the test environment construction script generated in S20 (S21). Specifically, this process is a process of embedding the test case number indicated by the test environment description file 1252 related to the execution target into the script template.

[0055] Furthermore, the script generation unit 113 analyzes the difference between the second merged test environment and the first merged test environment to be processed according to the test environment switching order obtained in S13, and generates a test environment switching script (S22). This difference corresponds to, for example, a difference in the status of a series of microservices that make up the test environment (e.g., a change from normal to abnormal). Therefore, the switching script describes the content to change the status of the microservices so that a change corresponding to this difference is realized by switching.

[0056] Next, the script generation unit 113 adds a test execution command to the script generated in S22 (S23), and ends the process. Specifically, this process is a process of embedding the test case number indicated by the test environment description file 1252 related to the execution target into the script template.

[0057] The best mode for carrying out the present invention has been specifically described above, but the present invention is not limited to this and can be modified in various ways without departing from the spirit of the present invention.

[0058] According to this embodiment, in development work based on a microservice architecture, it is possible to reduce the execution time of tests that involve switching between multiple test environments.

[0059] The present specification makes at least the following clear: In other words, in the test support device of this embodiment, when identifying the merge target based on the commonality of the components, if there is no common part among a series of components that sequentially link together in a test case, or if there is a common part among the series of components but the common part is set to the same state across the test environments, the merging unit may identify the combination of test environments as the merge target.

[0060] This allows for accurate avoidance of combinations that include common parts in the chain of components that exchange data between test environments, i.e., the origin of influence. It also allows for accurate identification of combinations that have common parts but are in the same state, i.e., only exchange data as initially configured, as candidates for merging. Ultimately, this makes it possible to more efficiently reduce test execution time that involves switching between multiple test environments in development work based on microservice architecture.

[0061] Furthermore, in the test support method of this embodiment, when the information processing device identifies the merger target based on the commonality of the components, if there are no common parts among a series of components that are linked together sequentially in a test case, or if there are common parts among the series of components but the common parts are set to the same state across the test environments, the information processing device may identify the combination of test environments as the merger target. [Explanation of symbols]

[0062] 1 Network 5 Test environment 10 Test Support System 100 Test support equipment 101 Storage device 102 Programs 103 memory 104 Arithmetic unit 105 Communication equipment 110 Reception 111 Merger Department 112 Sequence determining part 113 Script Generation Unit 1131 Auto-generation tool 125 Test environment storage 1251 Test Environment Description Format 1252 Test environment description file 126 Test Case Storage 127 Post-merger test environment storage area 128 Switching order storage section 129 Script template storage section 130 Generation script storage section 1301 Script 200 devices

Claims

1. a receiving unit that receives from a terminal a description file relating to a plurality of test environments, which defines each normal or abnormal state for each test case for each component constituting the software to be tested; a merging unit that identifies, based on the description file, a combination of the plurality of test environments that does not affect each other's execution based on at least the commonality of the components, as a combination to be merged, and merges the test environments to be merged; an order determination unit that optimizes the order of switching between test environments based on the amount of switching operations between each test environment including the merged test environment; a script generation unit that generates a script for switching the test environment and executing test cases corresponding to the test environment based on each test environment including the merged test environment and the switching order; A test support device equipped with the above.

2. The merging unit When identifying the merger target based on the commonality of the components, if there are no common parts among a series of components that are linked together sequentially in a test case, or if there are common parts among the series of components but the common parts are set to the same state across test environments, the combination of test environments is identified as the merger target.

2. The test support device according to claim 1.

3. The information processing device A process of receiving from a terminal a description file relating to a plurality of test environments, which defines each normal or abnormal state for each test case for each component constituting the software to be tested; a process of identifying, as a merger target, a combination of the plurality of test environments that does not affect each other's execution, based on at least the commonality of the components, and merging the test environments to be merged, based on the description file; A process of optimizing the switching order of the test environments based on the switching operation amount between each test environment including the merged test environment after the merger; A process of generating a script for switching test environments and executing test cases corresponding to the test environments based on each test environment including the merged test environment and the switching order; A test support method comprising:

4. The information processing device, When identifying the merger targets based on the commonality of the components, if there are no common parts among a series of components that are linked sequentially in a test case, or if there are common parts among the series of components but the common parts are set to the same state across test environments, the combination of test environments is identified as the merger target.

4. The test support method according to claim 3.

5. a receiving unit that receives from a terminal a description file relating to a plurality of test environments, which defines each normal or abnormal state for each test case for each component constituting the software to be tested; a merging unit that identifies, based on the description file, a combination of the plurality of test environments that does not affect each other's execution based on at least the commonality of the components, as a combination to be merged, and merges the test environments to be merged; an order determination unit that optimizes the order of switching between test environments based on the amount of switching operations between each test environment including the merged test environment; a script generation unit that generates a script for switching the test environment and executing test cases corresponding to the test environment based on each test environment including the merged test environment and the switching order; A test support system comprising a test support device comprising:

Images