JP2019101801A - Interface aggregation device and interface management method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To automatically set information necessary for continuously providing a service in accordance with the speed of a cycle of service development and improvement. Kind Code: A1 An API aggregation device that controls input/output of data via an API (interface) between an application and a service, wherein a service has a plurality of APIs of different types, and the API aggregation device is an arbitrary device. When a trigger to execute a test for identifying an alternative API of a target API is detected from among a plurality of APIs included in a service, a plurality of test cases are generated based on the framework information, the plurality of test cases are analyzed, Identify the test cases that can be deleted based on the analysis results, delete the specified test cases, execute the test based on the test cases, specify the alternative API based on the test execution results, register. [Selection diagram] Figure 1

Description

  The present invention relates to an API aggregation device and API management method for managing connection of applications and microservices via an API (interface).

  In recent business environments, DevOps, in which development departments and operation departments cooperate to continuously develop and improve services, are attracting attention.

  One of the DevOps is the idea of microservices. In this view, the service is divided into multiple small microservices, and each microservice is developed individually. Since the microservices to be developed are small unit systems, the cycle of microservice development and improvement can be shortened. The microservices cooperate with each other through an API to enable consistent operation as a system.

  Since the cycle of development and improvement of microservices is short, API version updates frequently occur. With frequent API version updates, API incompatibility may be lost and the entire service may not work properly.

  The technique described in Patent Document 1 is known as a means for solving API malfunction. According to Patent Document 1, "the API aggregation device 24 is connected between the application 25a of the communication system and the enablers 27a to 27d via the APIs 26a and 28a to 28d. The API aggregation device 24 is desired from the application 25a. When the request information is transmitted to the enabler 27b via the APIs 26b and 28b, in the case where the response information conforming to the contents of the request information is not sent back, the corresponding enabler 27c associated in advance with the enabler 27b of the dysfunction. “The API compatible process of returning the response information from the application 25a to the application 25a via the corresponding API 28c linked to the corresponding enabler 27c” is described.

JP, 2016-151881, A

  In the technology of Patent Document 1, it is necessary to manage the API and the corresponding API in advance in association with each other. Because DevOps frequently updates API versions, it is necessary to register APIs and corresponding APIs frequently. Therefore, it is costly to manage and may not be able to keep pace with the cycle of service development and improvement.

  In order to solve the above-mentioned problems, it is necessary to dynamically set the information necessary for continuously providing the service according to the speed of the service development and improvement cycle.

  The present invention is an apparatus for automatically setting information required to continuously provide services in accordance with the speed of service development and improvement cycles, even if API version updates occur frequently. Intended to provide a method.

  The following is a representative example of the invention disclosed in the present application. That is, an interface aggregation device that controls input / output of data via an interface between at least one application and a plurality of services, wherein each of the plurality of services has a plurality of interfaces of different types, The interface aggregation device comprises a processor, a memory connected to the processor, and a network interface connected to the processor, and framework information used to generate a test case defining test requirements, and any interface Maintaining compatibility information for managing an alternative interface compatible with the above, and detecting an execution opportunity of a test for specifying the alternative interface of the target interface among the plurality of interfaces possessed by any service In the case, a plurality of test cases are generated based on the framework information, the plurality of test cases are analyzed, and at least one test case that can be deleted is identified based on a result of the analysis, and the specified At least one test case is deleted, a test is executed based on the plurality of test cases, an alternative interface of the target interface is specified based on the execution result of the test, and an alternative interface of the target interface and the target interface Are registered in the compatible information.

  According to one aspect of the present invention, the interface aggregation device can automatically set compatibility information in accordance with the speed of the service development and improvement cycle. Problems, configurations, and effects other than those described above will be clarified by the description of the following embodiments.

FIG. 2 is a diagram showing an example of the configuration of a computer system according to a first embodiment. FIG. 2 is a diagram illustrating an example of a hardware configuration of an API aggregation device according to a first embodiment. FIG. 7 is a diagram showing an example of a data structure of framework information of the first embodiment. FIG. 7 is a diagram showing an example of a data structure of compatible information of the first embodiment. FIG. 7 is a diagram showing an example of a data structure of result information of the first embodiment. FIG. 7 is a diagram showing an example of a data structure of result information of the first embodiment. It is a flowchart explaining an example of the processing performed when the API aggregation device of the first embodiment is added a new API. FIG. 7 is a diagram showing an example of a test case generated by the API aggregation device of the first embodiment. FIG. 7 is a diagram showing an example of a microservice nest of the first embodiment. 7 is a flowchart illustrating an example of test case reduction processing performed by the test case adjustment unit of the first embodiment. 5 is a flowchart illustrating an example of a test environment construction process executed by the test environment construction unit of the first embodiment. It is a flowchart explaining an example of the alternative API determination process which the alternative API determination part of Example 1 performs. It is a flowchart explaining the process performed when the API intensive apparatus of Example 1 receives a request from an application. It is a flowchart explaining the alternative API selection process which the API aggregation apparatus of Example 1 performs. FIG. 7 is a diagram showing an example of the configuration of a computer system according to a second embodiment. FIG. 7 is a diagram showing an example of the configuration of a computer system according to a second embodiment. FIG. 18 is a flowchart illustrating an example of test case reduction processing performed by the test case adjustment unit of the third embodiment; FIG. FIG. 18 is a flowchart illustrating an example of test case reduction processing performed by the test case adjustment unit of the third embodiment; FIG.

  Hereinafter, embodiments of the present invention will be described using the drawings. However, the present invention should not be construed as being limited to the description of the embodiments below. Those skilled in the art can easily understand that the specific configuration can be changed without departing from the spirit or the spirit of the present invention.

  In the configurations of the invention described below, the same or similar configurations or functions are denoted by the same reference numerals, and overlapping descriptions will be omitted.

  In the present specification and the like, the notations “first”, “second”, “third” and the like are used to identify the constituent elements, and the number or order is not necessarily limited.

  The positions, sizes, shapes, ranges, and the like of the components shown in the drawings and the like may not represent actual positions, sizes, shapes, ranges, and the like in order to facilitate understanding of the invention. Accordingly, the present invention is not limited to the position, size, shape, range, and the like disclosed in the drawings and the like.

  FIG. 1 is a diagram illustrating an example of the configuration of a computer system according to a first embodiment. FIG. 2 is a diagram illustrating an example of a hardware configuration of the API aggregation device 100 according to the first embodiment.

  The computer system comprises an API aggregation device 100, a plurality of applications 101, and a plurality of microservices 102. The application 101 runs on a computer (not shown), and the microservice 102 runs on a system (not shown) composed of one or more computers. The present invention is not limited to the types and numbers of applications 101 and microservices 102.

  The API aggregation device 100, a computer that executes the application 101, and a system that executes the microservice 102 are connected to one another via a network. The network is, for example, a wide area network (WAN) or a local area network (LAN). The connection type of the network may be either wired or wireless.

  The API aggregation device 100 provides one application 101 with at least one API 105 for connecting to the API aggregation device 100. Also, one microservice 102 provides at least one API 106 for connecting to the API aggregation device 100.

  The plurality of APIs 105 provided to one application 101 are different in version, and the plurality of APIs 106 provided by one micro service 102 are different in version. The API 105 may include a different version of API for each microservice 102. Note that the plurality of APIs 106 provided by one microservice 102 include an API for acquiring a version of the API 106.

  If the API aggregating apparatus 100 of the present embodiment detects a test execution trigger for identifying the alternative API 106 that is an API compatible with any API 106 (target API 106), the test requirement (the content of the test) Generate a test case to define. Also, the API aggregation device 100 executes a test based on the generated test case, and identifies the alternative API 106 based on the execution result. The API aggregation device 100 associates the target API 106 with the alternative API 106 and registers it in the compatibility information 121 described later.

  Further, when the API aggregation device 100 of the present embodiment receives a request for the API 106 of an arbitrary micro service 102 from the application 101, the API aggregation device 100 refers to the compatibility information 121 as necessary, and makes the request to the designated API 106 or alternative API 106. Send As a result, since a normal response can be obtained from the microservice 102, continuous service provision can be realized.

  The API aggregation device 100 has a processor 201, a memory 202, and a network interface 203 as hardware as shown in FIG. The processor 201, the memory 202, and the network interface 203 are connected to one another via an internal bus.

  The processor 201 is an arithmetic device that executes a program stored in the memory 202. The processor 201 executes processing according to a program to operate as a functional unit (module) that implements a specific function. In the following description, when processing is described with the functional unit as the subject, it indicates that the processor 201 is executing a program for realizing the functional unit.

  The memory 202 is a storage device that stores programs executed by the processor 201 and information used by the programs. The memory 202 also includes a work area temporarily used by the program.

  The network interface 203 is an interface that connects to another device via a network.

  The API aggregation device 100 may have a storage device such as a hard disk drive (HDD) and a solid state drive (SSD). Also, the API aggregation device 100 may have an interface connected to input devices such as a keyboard, a mouse, and a touch panel, and output devices such as a display and a printer.

  A management terminal (not shown) is connected to the API aggregation device 100 via the network interface 203.

  Here, programs and information stored in the memory 202 will be described. The memory 202 stores a program for realizing the reception unit 110, the transmission unit 111, the compatible operation control unit 112, the test setting unit 113, the test control unit 114, and the alternative API determination unit 115. The memory 202 also stores framework information 120, compatibility information 121, and result information 122.

  The framework information 120 is information for managing a framework that is a test case template. The details of the data structure of the framework information 120 will be described with reference to FIG. The compatible information 121 is information for managing the correspondence between the API 106 and the alternative API 106. Details of the data structure of the compatible information 121 will be described with reference to FIG. Result information 122 is information for storing a test result. Details of the data structure of the result information 122 will be described with reference to FIGS. 5A and 5B.

  The receiving unit 110 executes a process of receiving data transmitted from an external device. For example, the receiving unit 110 receives a request for the microservice 102 from the application 101, and receives a response from the microservice 102.

  The transmission unit 111 executes data transmission processing to an external device. For example, the transmission unit 111 transmits the received request to the microservice 102, and transmits the received response to the application 101.

  The compatible operation control unit 112 controls transmission of a request to a predetermined API 106. The compatible operation control unit 112 determines whether the response from the API 106 to the request is normal, and transmits the request to the alternative API 106 if the response is not normal. The compatible operation control unit 112 includes a reference unit 131 and a compatible operation unit 132.

  The reference unit 131 refers to the compatibility information 121 and specifies the alternative API 106. The compatible operation unit 132 converts the received request into a request for the alternative API 106 and outputs it.

  The test setting unit 113 generates a test case of a test for specifying the alternative API 106. In this embodiment, one test case is generated for one test. The test setting unit 113 includes a test case generation unit 141 and a calling unit 142.

  The test case generation unit 141 generates a test case based on the framework information 120. The calling unit 142 calls the test control unit 114.

  The test control unit 114 analyzes the test case and deletes the test case based on the analysis result. The test control unit 114 executes a test based on the test case, and stores the execution result in the result information 122. In addition, when it is necessary to construct a test environment for executing a test, the test control unit 114 constructs a test environment. The test control unit 114 includes a test case adjustment unit 151, a test execution unit 152, and a test environment construction unit 153.

  The test case adjustment unit 151 analyzes the test case, identifies a deletable test based on the analysis result, and deletes the identified test case. The test execution unit 152 executes a test for identifying the alternative API 106 based on the test case. The test environment construction unit 153 constructs a test environment.

  The alternative API determination unit 115 specifies the alternative API 106 based on the result information 122, and registers information on the specified alternative API 106 in the compatible information 121.

  In addition, about each function part which API aggregation device 100 has, a plurality of function parts may be put together into one function part, and one function part may be divided into a plurality of function parts for every function.

  FIG. 3 is a view showing an example of the data structure of the framework information 120 of the first embodiment.

  The framework information 120 stores an entry composed of a test type 301 and an input value type 302. The entry may include fields other than the test type 301 and the input value type 302.

  The test type 301 is a field for storing the type of test. For example, in the test type 301, values indicating types of tests such as data update, data reference, and data deletion are stored.

  The input value type 302 is a field for storing the type of the value input in the test corresponding to the test type 301. The input value type 302 stores, for example, the names of variables or items.

  The framework information 120 may include a table for managing the system configuration, the condition of the microservice 102, and the like.

  FIG. 4 is a view showing an example of the data structure of the compatibility information 121 of the first embodiment.

  The compatibility information 121 stores an entry composed of an alternative source 401 and an alternative destination 402.

  The substitution source 401 is a group of fields for specifying the API 106 as the substitution source, and includes a service name 411, an API name 412, and an API version 413.

  The service name 411 is a field for storing the name of the microservice 102 providing the API 106. In addition, as long as the information can identify the microservice 102, a value other than the name may be used.

  The API name 412 is a field for storing the name of the API 106. Note that as long as the information can identify the API 106, a value other than the name may be used.

  The API version 413 is a field for storing the version of the API 106.

  The alternative destination 402 is a group of fields for specifying the alternative API 106 of the API 106 corresponding to the alternative source 401, and includes a service name 421, an API name 422, and an API version 423. The service name 421, the API name 422, and the API version 423 are fields similar to the service name 411, the API name 412, and the API version 413.

  5A and 5B are diagrams showing an example of the data structure of the result information 122 of the first embodiment. Although the tables shown in FIG. 5 and FIG. 5B are actually one table, they are divided into two for explanation.

  The result information 122 stores an entry including an API name 501, an API version 502, an execution time 503, a test type 504, a processing result 505, an execution count 506, a success result 507, and a failure result 508.

  The API name 501 and the API version 502 are fields similar to the API name 412 and the API version 413. The test type 504 is a field similar to the test type 301.

  The execution time 503 is a field for storing the start time of the test. The end time of the test may be stored in the execution time 503.

  The processing result 505 is a field for storing the latest test execution result. The processing result 505 shown in FIG. 6A stores a status code indicating the meaning of the response.

  The number of times of execution 506 is a field group storing the number of times of execution of the test based on the test case specified by the API name 501, the API version 502, and the test type 504. The number of executions 506 includes successes 511 and failures 512. The success 511 is a field for storing the number of times the execution result is successful. The failure 512 is a field for storing the number of times the execution result is a failure.

  The success result 507 is a group of fields indicating the relationship between the predicted value and the output value when the test execution result is successful. The success result 507 includes the predicted value 513 and the result 514. The predicted value 513 is a field for storing the predicted value of the output value included in the test case. The result 514 is a field for storing the output value obtained by executing the test.

  The failure result 508 is a group of fields indicating the relationship between the predicted value and the output value when the test execution result is a failure. Failure result 508 includes predicted value 515 and result 516. The predicted value 515 and the result 516 are the same fields as the predicted value 513 and the result 514.

  FIG. 6 is a flowchart illustrating an example of processing executed when the new API 106 is added to the API aggregation device 100 according to the first embodiment. FIG. 7 is a diagram illustrating an example of a test case generated by the API aggregation device 100 according to the first embodiment. FIG. 8 is a diagram illustrating an example of nesting of the microservices 102 according to the first embodiment.

  The API aggregation device 100 receives an addition notification of the new API 106 from the management terminal (step S101). The API aggregating apparatus 100 of the present embodiment detects the reception of the notification of addition of the new API 106 as an execution trigger of a test for specifying the alternative API 106. At this time, the API aggregation device 100 calls the test setting unit 113. The addition notification includes information for specifying the microservice 102 and the API 106.

  The test case generation unit 141 of the test setting unit 113 generates a test case of a test for specifying the alternative API 106 of the new API 106 (step S102). A well-known technique may be used to generate the test case. For example, the following generation method can be considered.

  The test case generation unit 141 refers to the framework information 120 and the result information 122 and configures the combination of the micro service 102, the API 106, and the version from the execution condition, the type of test, the input value, the predicted value, etc. Generate test cases to be More specifically, the test case generation unit 141 searches for an entry whose API name 501 matches the information of the API 106 included in the addition notification. The test case generation unit 141 generates a test case by determining an execution condition, an input value, and a predicted value based on the retrieved success result 507 and the like.

  The test case generation unit 141 generates, for example, a test case list 700 as shown in FIG. The list 700 includes a plurality of entries corresponding to test cases. The entry is composed of a test content 701, an input value 702, and a determination flag 703.

  The test content 701 is a field for storing specific content of the test. The test content 701 stores information for specifying the API 106, a test type, and the like. An input value 702 is a field for storing an input value of a test.

  The determination flag 703 is a field for storing a flag indicating whether or not the reduction process of the test case of the microservice 102 nested in another microservice 102 is to be executed.

  Here, nesting indicates that other routines and data blocks are embedded in routines and data blocks. Therefore, the nesting of the microservices 102 indicates that the call of one microservice 102 includes the call of another microservice 102, as shown in FIG.

  In FIG. 8, solid lines indicate actual application execution paths. An alternate long and short dash line indicates an application execution path to be subjected to the test case. The test case generation unit 141 generates a test case of a test for comprehensively checking the compatibility of the API 106 that calls the nested microservice. However, since the number of test cases to be generated is huge, the processing cost increases if the test based on all the test cases is executed. Therefore, in the present embodiment, reduction processing is performed to reduce the number of test cases.

  The determination flag 703 stores either “present” or “absent”. "Yes" indicates that the test case reduction process is performed based on the call time and results, etc. "None" indicates that the test case reduction process is not performed based on the call time and results.

  The determination of the nesting of the microservice 102 can be made by analyzing the relationship with other test cases. In addition, when the call condition is set in advance, the determination can also be made based on the call condition.

  The call unit 142 of the test setting unit 113 calls the test control unit 114 after the test case is generated. At this time, the calling unit 142 outputs the generated test case to the test control unit 114. The above is the description of step S102.

  Next, the test case adjustment unit 151 of the test control unit 114 executes test case reduction processing (step S103). The details of the test case reduction process will be described with reference to FIG.

  Next, the test environment construction unit 153 of the test control unit 114 executes a test environment construction process (step S104). The details of the test environment construction process will be described with reference to FIG.

  Next, the test execution unit 152 of the test control unit 114 executes a test based on the generated test case (step S105). In addition, the test execution unit 152 updates the result information 122 based on the test execution result (step S106). The result information 122 is updated as follows.

  The test execution unit 152 searches for an entry corresponding to the executed test based on the combination of the API name 501, the API version 502, and the test type 504. When there is no entry corresponding to the executed test, the test execution unit 152 adds an entry and sets values in the API name 501, the API version 502, and the test type 504.

  The test execution unit 152 sets the test start time to the execution time 503 of the retrieved entry or the added entry, and stores the test execution result in the processing result 505. Also, the test execution unit 152 adds 1 to one of the success 511 and the failure 512 based on the test execution result.

  The test execution unit 152 sets a value to the success result 507 when the processing result is success, and sets a value to the failure result 508 when the processing result is failure.

  The test control unit 114 calls the alternative API determination unit 115 after the update of the result information 122 is completed. The above is the description of the process of step S106.

  The alternative API determination unit 115 executes an alternative API determination process for specifying the alternative API 106 of the new API 106 (step S107), and then ends the process. The details of the alternative API determination process will be described with reference to FIG.

  FIG. 9 is a flowchart illustrating an example of the test case reduction process performed by the test case adjustment unit 151 of the first embodiment.

  The test case adjustment unit 151 sorts the test cases in the order of execution (step S201), and starts loop processing of the test cases (step S202). Specifically, the test case adjustment unit 151 selects target test cases in order of execution.

  The test case adjustment unit 151 determines whether the target test case is a test case of the microservice 102 of the nest (Step S203). That is, it is determined whether the target test case is a deletion candidate test case.

  Specifically, the test case adjustment unit 151 determines whether the determination flag 703 of the entry corresponding to the target test case is “present”. When the determination flag 703 is “YES”, the test case adjustment unit 151 determines that the target test case is a test case of the microservice 102 in which the target test case is nested.

  If it is determined that the target test case is not a test case of the nested microservice 102, the test case adjustment unit 151 proceeds to step S209.

  When it is determined that the target test case is a test case of the nested microservice 102, the test case adjustment unit 151 has the same version and argument as the target test case, and there is a test case whose execution order is later, In addition, it is determined whether the test execution interval based on the two test cases is smaller than the first threshold (step S204).

  In the following description, a test case whose version and arguments are the same as the target test case and whose execution order is later is described as a duplicate test case. In addition, the determination condition of step S204 is described as a first deletion condition.

  The execution interval between test cases may be determined based on the execution schedule. Alternatively, the execution interval may be calculated based on the execution time 503 of the result information.

  If it is determined that the first deletion condition is not satisfied, the test case adjustment unit 151 proceeds to step S206.

  If it is determined that the first deletion condition is satisfied, the test case adjustment unit 151 deletes the duplicate test case (step S205). Thereafter, the test case adjustment unit 151 proceeds to step S206. Tests based on the target test case and the duplicate test case are likely to obtain the same output value when the execution interval is short. Therefore, if the first deletion condition is satisfied, the test case adjustment unit 151 deletes the duplicate test case.

  When there are a plurality of duplicate test cases, the test case adjustment unit 151 deletes the duplicate test cases whose execution interval is smaller than the first threshold.

  In step S206, the test case adjustment unit 151 has a probability that an output value indicating success as a result of execution of the test based on the target test case is larger than the second threshold, and the test based on the previous test case with the same contents. It is determined whether the elapsed time from the end time is smaller than the third threshold (step S206). The second threshold and the third threshold can be arbitrarily set. For example, the second threshold may be set to 0.7 and the third threshold may be set to one hour.

  In the following description, a test case in which the probability that an output value indicating success as a result of execution of a test can be obtained is greater than a second threshold is referred to as a success test case. In addition, the determination condition of step S206 is described as a second deletion condition.

  If it is determined that the second deletion condition is satisfied, the test case adjustment unit 151 deletes the target test case (step S208), and then the process proceeds to step S209. If you run a test based on a success test case that has a short elapsed time since the previous test is completed, you are likely to get an output value that indicates success. Therefore, if the second deletion condition is satisfied, the test case adjustment unit 151 deletes the successful test case.

  When it is determined that the second deletion condition is not satisfied, the test case adjustment unit 151 has a probability that an output value indicating failure as a result of execution of the test based on the target test case is larger than the fourth threshold and the previous one It is determined whether the elapsed time from the end time of the test based on the test case of the same contents is smaller than the fifth threshold (step S207). The threshold can be set arbitrarily. For example, the fourth threshold may be set to 0.85 and the fifth threshold may be set to 24 hours.

  In the following description, a test case in which the probability that an output value indicating a failure is obtained as a test execution result is larger than a fourth threshold is referred to as a failure test case. In addition, the determination condition of step S207 is described as a third deletion condition.

  If it is determined that the third deletion condition is satisfied, the test case adjustment unit 151 deletes the target test case (step S208), and then the process proceeds to step S209. If you run a test based on a failure test case where the elapsed time since the previous test is completed is short, you are likely to get an output value that indicates failure. Therefore, the test case adjustment unit 151 deletes the failure test case when the third deletion condition is satisfied.

  If it is determined that the third deletion condition is not satisfied, the test case adjustment unit 151 proceeds to step S209.

  In step S209, the test case adjustment unit 151 determines whether there is a test case to be executed after the target test case (step S209).

  If it is determined that there is a test case to be executed after the target test case, the test case adjustment unit 151 returns to step S202, selects a new target test case, and executes the same processing.

  If it is determined that there is no test case to be executed after the target test case, the test case adjustment unit 151 ends the test case reduction process.

  In this embodiment, by reducing the number of test cases based on the deletion condition as described above, it is possible to shorten the test time and reduce the computer resources used for the test. This allows the execution of tests tailored to the speed of the service development and improvement cycle.

  FIG. 10 is a flowchart illustrating an example of the test environment construction process executed by the test environment construction unit 153 of the first embodiment.

  The test environment construction unit 153 refers to the generated test case (step S301), and determines whether the test executed based on the test case is only the test of the reference system (step S302).

  Specifically, the test environment construction unit 153 determines whether the test contents 701 of all the entries registered in the list 700 are data references. If the test content 701 of all the entries registered in the list 700 is a data reference, the test environment construction unit 153 determines that the test to be executed is only the test of the reference system.

  If it is determined that the test is only the test of the reference system, the test environment construction unit 153 ends the process.

  If it is determined that the test includes a test other than the reference system, the test environment construction unit 153 constructs a test environment (step S303).

  A method of constructing a test environment may be a known technique, and therefore detailed description will be omitted. When the test environment is established, the test control unit 114 may control to execute the test of the update system and the reference system in the test environment, and the test of the update system is performed in the test environment and referred to System testing may be controlled to run in the actual system environment.

  Next, the test environment construction unit 153 determines whether the test has been completed (step S304). For example, when the test environment construction unit 153 receives a test completion notification from the test execution unit 152, the test environment construction unit 153 determines that the test is completed.

  If it is determined that the test is not completed, the test environment construction unit 153 shifts to a waiting state until the test is completed.

  If it is determined that the test is completed, the test environment construction unit 153 discards the test environment (step S305), and then ends the test environment construction process.

  FIG. 11 is a flowchart illustrating an example of the alternative API determination process performed by the alternative API determination unit 115 according to the first embodiment.

  The alternative API determination unit 115 reads the value of the entry corresponding to the executed test with reference to the result information (step S401). For example, the alternative API determination unit 115 can identify an entry whose difference between the current time and the execution time 503 is smaller than a threshold as an entry corresponding to the executed test.

  The alternative API determination unit 115 starts loop processing of the API 106 indicated by the entry (step S402).

  Specifically, the alternative API determination unit 115 selects one candidate entry from the entries corresponding to the executed test. In addition, the alternative API determination unit 115 compares the input value and the output value of the test case of the new API 106 with the input value and the output value of the test case of the API 106 corresponding to the candidate entry. In the following description, the API 106 corresponding to the candidate entry is described as a candidate API 106.

  The alternative API determination unit 115 determines whether the input value and the output value of the test case of the candidate API 106 completely match the input value and the output value of the test case of the new API 106 (step S403).

  When it is determined that the input value and the output value of the test case of the candidate API 106 completely match the input value and the output value of the test case of the new API 106, the alternative API determination unit 115 determines the alternative API 106 as the alternative API 106. The candidate API 106 is registered in the compatibility information 121 (step S404). Thereafter, the substitute API determination unit 115 proceeds to step S406.

  Specifically, the alternative API determination unit 115 adds an entry to the compatibility information 121, and sets the information of the new API 106 in the alternative source 401 of the added entry. Also, the alternative API determination unit 115 sets information of the candidate API 106 in the alternative destination 402 of the added entry.

  If it is determined that the input value and the output value of the test case of the candidate API 106 do not completely match the input value and the output value of the test case of the new API 106, the alternative API determination unit 115 determines that the alternative to the candidate API 106 is It is determined whether it is possible (step S405).

  Specifically, the alternative API determination unit 115 applies a determination rule to replace any of the input value and the output value of the test case of the new API 106 and the candidate API 106, and determines whether or not the same output value can be obtained. Do. For example, determination rules as shown in (1), (2) and (3) shown below can be considered.

  (1) When the number of arguments of the new API 106 (the number of test input values) is larger than the number of arguments of the candidate API 106, the alternative API determination unit 115 inputs Null into the added argument, and a test case of the new API 106 Get the output value of. When the acquired output value is the same as the output value of the test case of the candidate API 106, the alternative API determination unit 115 determines that substitution to the candidate API 106 is possible.

  For example, when the arguments of the candidate API 106 are int_a and string_b, and the arguments of the new API 106 are int_a, string_b, and string_c, the alternative API determination unit 115 outputs the test case output value of the new API 106 in which Null is input in string_c. It is determined whether or not the output value of the test case of the candidate API 106 matches.

  (2) When the variable of the new API 106 and the variable of the candidate API 106 are different, the alternative API determination unit 115 acquires the output value of the test case of the candidate API 106 in which the variable of the candidate API 106 is replaced with the variable of the new API 106. When the acquired output value is the same as the output value of the test case of the new API 106, the alternative API determination unit 115 determines that alternative to the candidate API 106 is possible.

  For example, when the variables of the candidate API 106 are int_a and string_b and the variables of the new API 106 are int_x and string_b, the alternative API determination unit 115 determines that the output value of the test case of the candidate API 106 in which int_a is replaced with int_x is the new API 106. It is determined whether it is the same as the output value of the test case.

  (3) When the format of the output value of the new API 106 is different, the alternative API determination unit 115 acquires the output value of the test case of the candidate API 106 obtained by converting the format of the output value of the candidate API 106 into the format of the output value of the new API 106 . When the acquired output value is the same as the output value of the test case of the new API 106, the alternative API determination unit 115 determines that alternative to the candidate API 106 is possible.

  For example, when the output values of the candidate API 106 are int_c = 2 and string_d = 100, and the output values of the new API 106 are int_c = 2 and int_d = 100, the alternative API determination unit 115 determines the value of string type to int type. It is determined whether the output value of the test case of the candidate API 106 converted into the value is the same as the output value of the test case of the new API 106.

  It is assumed that the above-described determination rule is set in advance in the alternative API determination unit 115 of this embodiment. Note that the determination rule may be input from the outside. In this case, the determination rule is stored in the memory 202, and the alternative API determination unit 115 performs the determination with reference to the determination rule.

  If it is determined that substitution to the candidate API 106 is not possible, the substitution API determination unit 115 proceeds to step S406.

  If it is determined that the candidate API 106 can be substituted, the substitute API determination unit 115 proceeds to step S404.

  In step S406, the alternative API determination unit 115 determines whether the process has been completed for all the entries acquired in step S401 (step S406).

  If it is determined in step S401 that the process has not been completed for all the acquired entries, the alternative API determination unit 115 returns to step S402, selects a new candidate entry, and executes the same process.

  If it is determined in step S401 that the process has been completed for all the acquired entries, the alternative API determination unit 115 ends the alternative API determination process.

  Next, processing of the API aggregation device 100 when a request is received from the application 101 will be described. FIG. 12 is a flowchart for explaining the process executed when the API aggregation device 100 according to the first embodiment receives a request from the application 101.

  The receiving unit 110 of the API aggregation device 100 receives a request from the application 101 (step S501). The request includes information for specifying the microservice 102, a version of the API 106, a method, header information, authentication information, and the like. The information for identifying the microservice 102 may be, for example, a URL.

  Next, the compatible operation control unit 112 of the API aggregation device 100 transmits a request to the API 106 of the designated microservice 102 via the transmission unit 111 (step S502).

  Next, the receiving unit 110 of the API aggregation device 100 receives a response from the microservice 102 (step S503). The receiving unit 110 outputs a response to the compatible operation control unit 112.

  Next, the compatible operation control unit 112 of the API aggregation device 100 determines whether the received response is a normal response (step S504).

  Specifically, compatible operation control unit 112 determines whether the received response is a normal response based on the status code included in the response.

  If it is determined that the received response is a normal response, the compatible operation control unit 112 transmits the received response to the application 101 via the transmission unit 111 (step S505). Thereafter, compatible operation control unit 112 ends the process.

  If it is determined that the received response is not a normal response, the compatible operation control unit 112 determines whether or not the alternative API 106 of the API 106 that has transmitted the request is registered in the compatible information 121 (step S506).

  Specifically, the reference unit 131 of the compatible operation control unit 112 refers to the substitution source 401 of the compatible information 121, and searches for an entry in which information matching the API 106 of the transmission destination of the request is set. If the entry exists, the reference unit 131 determines that the alternative API 106 of the API 106 that has transmitted the request is registered.

  When it is determined that the alternative API 106 of the API 106 that has sent the request is registered, the compatible operation unit 132 of the compatible operation control unit 112 transmits the request to the alternative API 106 corresponding to the alternative destination 402 of the retrieved entry ( Step S507). After the compatible operation control unit 112 receives the response from the microservice 102, the compatible operation control unit 112 proceeds to step S505.

  If it is determined that the alternative API 106 of the API 106 that has transmitted the request is not registered, the compatible operation control unit 112 instructs the test setting unit 113 to execute the alternative API selection process (step S508). The instruction includes the name and version of the API 106 that has transmitted the request. The details of the alternative API selection process will be described with reference to FIG. The API aggregating apparatus 100 according to the present embodiment detects that the alternative API 106 of the API 106 that has sent an incorrect response is not registered in the compatibility information 121 as an execution trigger of a test for specifying the alternative API 106.

  The compatible operation control unit 112 shifts to the waiting state until it receives a process end notification from the alternative API determination unit 115.

  When the reference unit 131 of the compatible operation control unit 112 receives the process end notification from the alternative API determination unit 115, the reference unit 131 determines whether or not the alternative API 106 of the API 106 that has transmitted the request is registered in the compatibility information 121 ( Step S509). The process of step S509 is the same as the process of step S506.

  If it is determined that the alternative API 106 of the API 106 that has transmitted the request is registered, the compatible operation unit 132 of the compatible operation control unit 112 proceeds to step S507.

  If it is determined that the alternative API 106 of the API 106 that has transmitted the request is not registered, the compatible operation unit 132 of the compatible operation control unit 112 transmits an error response to the application 101 (step S510). Thereafter, compatible operation control unit 112 ends the process.

  FIG. 13 is a flowchart illustrating the alternative API selection process executed by the API aggregation device 100 according to the first embodiment.

  The test setting unit 113 receives an execution instruction of the alternative API selection process from the compatible operation control unit 112 (step S601). The processing from step S602 to step S607 is the same as the processing from step S102 to step S107 described in FIG. However, processing is performed on the API 106 that has sent the request.

  According to the first embodiment, the API aggregation device 100 executes a test when adding a new API 106 or when a normal response is not obtained from the API 106, and based on the test execution result, the service is continuously updated. It is possible to automatically generate and update compatible information 121 necessary for providing. In the present embodiment, the API aggregating apparatus 100 can execute a test tailored to the speed of the service development and improvement cycle by reducing the number of test cases.

  Therefore, the API aggregation device 100 of the first embodiment can automatically generate and update the compatibility information 121 in accordance with the speed of the service development and improvement cycle.

  In the second embodiment, the configuration of the computer system is different. Specifically, the computer system has a plurality of API aggregation devices 100. Hereinafter, the second embodiment will be described focusing on the difference from the first embodiment.

  FIG. 14A and FIG. 14B are diagrams showing configuration examples of the computer system of the second embodiment. The API 105 between the application 101 and the API aggregation device 100 and the API 106 between the API aggregation device 100 and the microservice 102 are omitted for the sake of simplicity.

  The computer system of the second embodiment has a plurality of API aggregation devices 100. With such a configuration, the load of the API aggregation device 100 can be distributed according to the increase of the APIs 105 and 106 and the increase of requests. The API aggregation device 100 of the second embodiment executes the same process as the API aggregation device 100 of the first embodiment.

  The application 101 transmits a request to any of the API aggregation devices 100.

  In the case of the computer system shown in FIG. 14A, the microservice 102 accessed by the API aggregation device 100 is set in advance, and a URL or the like for accessing the microservice 102 is input to the hash function to be calculated. Allocate to the aggregation device 100. The application 101 inputs the aforementioned URL or the like to the hash function to calculate a hash value, and determines the API aggregation device 100 of the access destination based on the calculated hash value. When the API aggregation device 100 receives a request, the API aggregation device 100 transmits the request to the API 106 of the assigned microservice 102.

  The API aggregation device 100 shown in FIG. 14A holds compatibility information 121 related to the microservice 102 in charge. Note that each API aggregation device 100 transmits a copy of the compatible information 121 to at least one API aggregation device 100 in order to cope with a failure of the API aggregation device 100.

  In the case of the computer system shown in FIG. 14B, the API aggregation device 100 can access each microservice 102. The computer system illustrated in FIG. 14B has a load balancer 1300 that distributes requests to each API aggregation device 100. The application 101 sends a request to the load balancer 1300. The load balancer 1300 transfers the request to each API aggregation device 100 so that the load is distributed. The transfer method may be a round robin method or a method based on the operating rate of the processor 201.

  The API aggregation device 100 shown in FIG. 14B transmits a copy of the compatible information 121 to another API aggregation device 100 at an arbitrary timing. That is, the compatibility information 121 held by each API aggregation device 100 is managed to be synchronized.

  According to the second embodiment, an increase in the load on the API aggregation device 100 can be avoided by including a plurality of API aggregation devices 100 in the system. As a result, it is possible to suppress the deterioration in quality of service using the microservice 102 such as a delay in response of the microservice 102.

  In the third embodiment, the test case reduction process is partially different. The third embodiment will be described below focusing on the difference from the first embodiment.

  The system configuration of the third embodiment is the same as that of the first embodiment. The hardware configuration and the software configuration of the API aggregation device 100 of the third embodiment are the same as the API aggregation device 100 of the first embodiment.

  The flow of the process performed when the new API 106 of the third embodiment is added is the same as the flow of the process of the first embodiment. The flow of processing executed when a request is received from the application 101 of the third embodiment is the same as the flow of processing of the first embodiment. In the third embodiment, the test case reduction process is partially different.

  15A and 15B are flowcharts for explaining an example of the test case reduction process performed by the test case adjustment unit 151 of the third embodiment.

  The processes of step S201 to step S209 of the third embodiment are the same as the processes of the first embodiment. In the third embodiment, after the process of step S209 is performed, the test case adjustment unit 151 calculates the processing load of the API aggregation device 100 when the test case is performed (step S251).

  A known method may be used to calculate the processing load of the API aggregation device 100 when the test case is executed. For example, a method of calculating the total value of the resource amount required for each test case as the processing load of the API aggregation device 100, or a method of calculating the maximum value of the resource amount required for each test case as the processing load of the API aggregation device 100 Etc. can be considered.

  The test case adjustment unit 151 determines whether the calculated processing load is larger than a sixth threshold (step S252).

  If it is determined that the calculated processing load is equal to or less than the sixth threshold, the test case adjustment unit 151 ends the test case reduction process.

  If it is determined that the calculated processing load is larger than the sixth threshold, the test case adjustment unit 151 starts loop processing of the test case (step S253). The process of step S253 is the same as the process of step S202.

  The test case adjustment unit 151 determines whether the target test case is a test case of the microservice 102 of the nest (step S254). The process of step S254 is the same as the process of step S203.

  If it is determined that the target test case is a test case of the microservice 102 of the nest, the test case adjustment unit 151 determines that the overlapping test case exists and the test execution interval based on the two test cases is the seventh threshold. It is determined whether or not it is smaller (step S255). The seventh threshold is set to a value larger than the first threshold.

  In the following description, a condition that a duplicate test case exists and an execution interval of a test based on two test cases is smaller than a seventh threshold is described as a fourth deletion condition.

  If it is determined that the fourth deletion condition is not satisfied, the test case adjustment unit 151 proceeds to step S259.

  If it is determined that the fourth deletion condition is satisfied, the test case adjustment unit 151 deletes the duplicate test case (step S256).

  Next, the test case adjustment unit 151 calculates the processing load of the API aggregation device 100 when the test case is executed (step S257). The calculation method of the processing load of step S257 is the same as the calculation method of the processing load of step S251.

  The test case adjustment unit 151 determines whether the calculated processing load is larger than a sixth threshold (step S258). The process of step S258 is the same as step S252.

  If it is determined that the calculated processing load is larger than the sixth threshold, the test case adjustment unit 151 proceeds to step S259.

  In step S258, the test case adjustment unit 151 determines whether there is a test case to be executed after the target test case (step S259). The process of step S259 is the same as the process of step S209.

  If it is determined that the calculated processing load is equal to or less than the sixth threshold, the test case adjustment unit 151 ends the loop processing of the test case, and then ends the test case reduction processing.

  According to the third embodiment, it is possible to reduce the load on the API aggregation device 100 accompanying the execution of a test based on a test case. As a result, it is possible to suppress the deterioration in quality of service using the microservice 102 such as a delay in response of the microservice 102.

  The present invention is not limited to the embodiments described above, but includes various modifications. Further, for example, the above-described embodiments are described in detail in order to explain the present invention in an easy-to-understand manner, and the present invention is not necessarily limited to those having all the described configurations. Further, part of the configuration of each embodiment can be added to, deleted from, or replaced with another configuration.

  Further, each of the configurations, functions, processing units, processing means, etc. described above may be realized by hardware, for example, by designing part or all of them with an integrated circuit. The present invention can also be realized by a program code of software that realizes the functions of the embodiment. In this case, a storage medium storing the program code is provided to the computer, and a processor included in the computer reads the program code stored in the storage medium. In this case, the program code itself read from the storage medium implements the functions of the above-described embodiments, and the program code itself and the storage medium storing the same constitute the present invention. As a storage medium for supplying such a program code, for example, a flexible disk, a CD-ROM, a DVD-ROM, a hard disk, an SSD (Solid State Drive), an optical disk, a magneto-optical disk, a CD-R, a magnetic tape, A non-volatile memory card, ROM or the like is used.

  Further, program code for realizing the functions described in the present embodiment can be implemented by a wide range of programs or script languages such as, for example, assembler, C / C ++, perl, shell, PHP, Java (registered trademark).

  Furthermore, by distributing the program code of the software for realizing the functions of the embodiment through a network, the program code is stored in a storage means such as a hard disk or a memory of a computer or a storage medium such as a CD-RW or CD-R. A processor included in the computer may read out and execute the program code stored in the storage unit or the storage medium.

  In the above-described embodiment, the control lines and the information lines indicate what is considered necessary for the description, and not all the control lines and the information lines in the product are necessarily shown. All configurations may be connected to each other.

100 API aggregation device 101 application 102 micro service 105, 106 API
110 Reception unit 111 Transmission unit 112 Compatible operation control unit 113 Test setting unit 114 Test control unit 115 Alternative API determination unit 120 Framework information 121 Compatibility information 122 Result information 131 Reference unit 132 Compatible operation unit 141 Test case generation unit 142 Call unit 151 Test case adjustment unit 152 Test execution unit 153 Test environment construction unit 201 Processor 202 Memory 203 Network interface 1300 Load balancer

Claims (14)

An interface aggregation device for controlling input and output of data via an interface between at least one application and a plurality of services, comprising:
Each of the plurality of services has a plurality of interfaces of different types;
The interface aggregation device
A processor, a memory connected to the processor, and a network interface connected to the processor;
Holds framework information used to generate test cases that define test requirements, and compatibility information to manage alternate interfaces compatible with any interface,
When a trigger for executing a test for identifying the alternative interface of the target interface is detected among the plurality of interfaces of any service, a plurality of test cases are generated based on the framework information,
Analyzing the plurality of test cases, identifying at least one test case that can be deleted based on a result of the analysis, and deleting the at least one test case identified;
Execute a test based on the plurality of test cases,
Identifying an alternate interface of the target interface based on the execution result of the test;
An interface aggregation device, which registers data corresponding to the target interface and an alternative interface of the target interface in the compatible information. The interface aggregation device according to claim 1, wherein
Manage the history of test execution results based on test cases,
Based on the result of the analysis, a test case of deletion candidate is identified among the plurality of test cases,
There is a duplicate test case having the same contents as the deletion candidate test case and having a later execution order, and a test execution interval based on the deletion candidate test case and the duplicate test case is smaller than a first threshold If, execute the first deletion process to delete the duplicate test case,
The probability that an output value indicating success is obtained as the execution result of the test based on the test case for deletion candidate is larger than the second threshold, and the test based on the test case having the same contents as the previous test case for deletion candidate is executed If the elapsed time since the second test is less than the third threshold, the second delete process is executed to delete the test case of the delete candidate,
The probability that an output value indicating failure is obtained as the execution result of the test based on the deletion candidate test case is larger than the fourth threshold, and the test based on the test case having the same contents as the previous deletion candidate test case is executed An interface aggregation device that executes a third deletion process of deleting the test case of the deletion candidate if the elapsed time since being executed is less than a fifth threshold. The interface aggregation device according to claim 2, wherein
The test case contains input values,
The interface aggregation device holds determination rules used to specify the alternative interface,
The plurality of test cases include a first test case for the target interface and a second test case for the first interface,
Acquiring a first output value by executing a test based on the first test case,
Acquiring a second output value by executing a test based on the second test case,
Comparing the input value and the first output value of the first test case with the input value and the second output value of the second test case,
When the input value and the second output value of the second test case match the input value and the first output value of the first test case, the compatibility information includes the first interface as an alternative interface of the target interface. Register
When the input value of the second test case and the second output value are partially different from the input value of the first test case and the first output value, the second output value may be changed by applying the determination rule. It is determined whether or not it matches the first output value,
When it is determined that the second output value matches the first output value by applying the determination rule, the first interface is registered in the compatibility information as an alternative interface of the target interface. Interface aggregation device. The interface aggregation device according to claim 2, wherein
Execution of the test when at least one of receiving a notification of adding a new interface, and when the alternative interface of the interface which has not responded normally to the request from the application is not registered in the compatibility information An interface aggregation device characterized by being detected as a trigger. The interface aggregation device according to claim 2, wherein
The request is sent to the second interface when a request for the second interface of any service is received from the application.
Receiving a response via the second interface,
Determining whether the received response is a normal response;
An interface aggregation device characterized by referring to the compatibility information and transmitting a request to an alternative interface of the second interface when it is determined that the received response is not a normal response. The interface aggregation device according to claim 2, wherein
Calculating processing loads when the plurality of test cases are executed after the first deletion process, the second deletion process, and the third deletion process are executed;
If the processing load is larger than a fourth threshold, a test case of the deletion candidate is identified;
If the duplicate test case exists and the test execution interval based on the delete candidate test case and the duplicate test case is smaller than a sixth threshold, the fourth delete process for deleting the duplicate test case is executed.
The interface aggregation device, wherein the sixth threshold is larger than the first threshold. The interface aggregation device according to claim 2, wherein
It is determined whether all the test cases are test cases for executing a reference system test for reading out values,
If it is determined that the at least one test case is not a test case for executing the test of the reference system, a test environment is generated,
An interface aggregation device that executes a test based on the plurality of test cases on the test environment. An interface management method executed by an interface aggregation device for controlling input and output of data via an interface between at least one application and a plurality of services, comprising:
Each of the plurality of services has a plurality of interfaces of different types;
The interface aggregation device
A processor, a memory connected to the processor, and a network interface connected to the processor;
Holds framework information used to generate test cases that define test requirements, and compatibility information to manage alternate interfaces compatible with any interface,
The interface management method is
When the interface aggregation device detects an execution trigger of a test for identifying the alternative interface of the target interface among the plurality of interfaces possessed by any service, a plurality of test cases are displayed based on the framework information. The first step to generate
The interface aggregation device analyzes the plurality of test cases, identifies at least one test case that can be deleted based on a result of the analysis, and deletes the specified at least one test case. Step and
A third step of the interface aggregation device executing a test based on the plurality of test cases;
A fourth step of the interface aggregating apparatus specifying an alternative interface of the target interface based on the execution result of the test;
A fifth step of the interface aggregation device registering, in the compatibility information, data in which the target interface and an alternative interface of the target interface are associated with each other. The interface management method according to claim 8, wherein
The interface aggregation device manages a history of test execution results based on test cases,
The second step is
The interface aggregation device specifies a test case of a deletion candidate from among the plurality of test cases based on the result of the analysis;
There is a duplicate test case having the same contents as the deletion candidate test case and having a later execution order, and a test execution interval based on the deletion candidate test case and the duplicate test case is smaller than a first threshold And executing a first deletion process to delete the duplicate test case.
The probability that an output value indicating success is obtained as the execution result of the test based on the test case for deletion candidate is larger than the second threshold, and the test based on the test case having the same contents as the previous test case for deletion candidate is executed Executing a second deletion process for deleting the test case of the deletion candidate if the elapsed time since the execution is less than a third threshold;
The probability that an output value indicating failure is obtained as the execution result of the test based on the deletion candidate test case is larger than the fourth threshold, and the test based on the test case having the same contents as the previous deletion candidate test case is executed And D. performing a third deletion process of deleting the test case of the deletion candidate if the elapsed time after the execution is less than a fifth threshold. The interface management method according to claim 9, wherein
The test case contains input values,
The interface aggregation device holds determination rules used to specify the alternative interface,
The plurality of test cases include a first test case for the target interface and a second test case for the first interface,
The fourth step is
Obtaining the first output value by executing the test based on the first test case, the interface aggregation device;
Acquiring the second output value by the interface aggregation device executing a test based on the second test case;
The interface aggregation device compares the input value and the first output value of the first test case with the input value and the second output value of the second test case;
When the input value and the second output value of the second test case match the input value and the first output value of the first test case, the interface aggregation device substitutes the compatibility information for the target interface. Registering the first interface as an interface;
When the input value and the second output value of the second test case are partially different from the input value and the first output value of the first test case, the interface aggregation device applies the determination rule to apply the determination rule. Determining whether a second output value matches the first output value;
When it is determined that the second output value matches the first output value by applying the determination rule, the interface aggregation device uses the first interface as an alternative interface of the target interface to the compatibility information. And D. registering the interface. The interface management method according to claim 9, wherein
In the first step, when the interface aggregation device receives a notification of addition of a new interface, and the alternative interface of the interface that has made a non-normal response to the request from the application is registered in the compatibility information. An interface management method comprising: detecting at least one of the cases where there is no case as an execution trigger of the test. The interface management method according to claim 9, wherein
The interface aggregation device transmitting the request to the second interface when receiving a request for the second interface included in any service from the application;
The interface aggregation device receiving a response via the second interface;
The interface aggregation device determining whether the received response is a normal response;
And, if it is determined that the received response is not a normal response, the interface aggregation device refers to the compatible information and transmits a request to an alternative interface of the second interface. Interface management method. The interface management method according to claim 9, wherein
Calculating the processing load when the plurality of test cases are executed after the interface aggregation device executes the first deletion process, the second deletion process, and the third deletion process;
If the processing load is larger than a fourth threshold, the interface aggregation device specifies the test case of the deletion candidate;
The interface aggregating apparatus deletes the duplicate test case if the duplicate test case exists and the test execution interval based on the deletion candidate test case and the duplicate test case is smaller than a sixth threshold. Performing the deletion process;
The interface management method, wherein the sixth threshold is larger than the first threshold. The interface management method according to claim 9, wherein
The third step is
Determining whether the interface aggregation device is a test case for executing a test of a reference system for reading out all the test cases;
The interface aggregating apparatus generates a test environment if it is determined that the at least one test case is not a test case for performing a test of the reference system;
The interface aggregating apparatus executes a test based on the plurality of test cases on the test environment.

Images