DETECTION APPARATUS, TEST SYSTEM, DETECTION METHOD, AND PROGRAM

Abstract

To provide a detection apparatus etc. capable of automatically detecting error parts in parameters of a declarative model based on a result of a test executed on a system built according to the declarative model.SOLUTION: An detection apparatus comprises: an acquisition unit for acquiring a declarative model used for constructing a target system, test-related information of a test executed on the target system, and a result of the test executed on the target system; and a detection unit for detecting errors in parameters included in the declarative model based on information extracted from the test-related information according to the result of the test executed.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to a detection device that detects errors in parameters of a declarative model. [Background technology]

[0002] Declarative models are used to build a system in an execution environment. For example, the OASIS TOSCA reference implementation is a method for building a system using a declarative model (Non-Patent Document 1). OASIS is an abbreviation for Organization for the Advancement of Structured Information Standards. TOSCA is an abbreviation for Topology and Orchestration Specification for Cloud Applications.

[0003] Systems built according to declarative models may not operate correctly due to various reasons, such as errors in creating the declarative model caused by parameter errors or problems with the execution environment. Generally, systems built according to declarative models are checked manually or with test tools to see if they are built as declared and operate correctly. Checking manually or with test tools has problems such as the need to create test items and test code each time, the possibility of errors in test design and test code creation, and the need for high skill to design tests and create test code appropriately.

[0004] Patent Document 1 discloses a test code generation device that supports a declarative model. The device in Patent Document 1 extracts items that need to be implemented from test information that is preset for each component of the declarative model, and automatically generates test code for a system that is constructed according to the declarative model.

[0005] Patent Document 2 discloses a technology for tailoring design rules for individual projects in a model checking device that checks a software model based on design rules. In the technology of Patent Document 2, parameter contents set in parameter items described in a software model are checked based on parameter items and standard parameter contents defined in the design rules. In the technology of Patent Document 2, when a non-conformity occurs in the inspection, history information including design rule identification information indicating the design rule and the parameter items and parameter contents that have become non-conformity is stored in advance. In the technology of Patent Document 2, when a non-conformity occurs in the inspection, it is determined whether or not the standard parameter contents of the parameter items that have become non-conformity should be modified based on the trend of the history information. In the technology of Patent Document 2, when it is determined that modification is required, a proposal for modifying the standard parameter contents of the parameter items is created based on the trend of the history information. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2020-181509 A [Patent Document 2] JP 2020-013239 A [Non-patent literature]

[0007] [Non-Patent Document 1] TOSCA Simple Profile in YAML Version 1.2, Committee Specification 01, 19 July 2018. Summary of the Invention [Problem to be solved by the invention]

[0008] Patent Document 1 discloses a method for checking whether a system constructed according to a declarative model operates correctly. However, Patent Document 1 does not disclose any measures for operating the constructed system correctly. Normally, to operate the constructed system correctly, it is necessary to correct the parameter errors in the declarative model. In such a case, it is necessary to understand the cause of the system not operating correctly from the test results, and further understand the corresponding relationship with the cause (parameter error in the declarative model) that is causing this, and then identify the error location.

[0009] In the method of Patent Document 2, a software model is validated according to preset constraints called design rules. Therefore, in the method of Patent Document 2, parameter items and reference parameter contents that are not defined in the design rules cannot be inspected.

[0010] An object of the present disclosure is to provide a detection device etc. that can automatically detect errors in the parameters of a declarative model based on the results of executing tests on a system built in accordance with the declarative model. [Means for solving the problem]

[0011] A detection device of one embodiment of the present disclosure includes an acquisition unit that acquires a declarative model used to construct a target system, test-related information of tests performed on the target system, and execution results of the tests on the target system, and a detection unit that detects errors in parameters included in the declarative model based on information extracted from the test-related information in accordance with the execution results of the tests.

[0012] In a detection method of one embodiment of the present disclosure, a computer obtains a declarative model used to construct a target system, test-related information of tests performed on the target system, and results of the execution of the tests on the target system, and detects errors in parameters contained in the declarative model based on information extracted from the test-related information in accordance with the results of the test execution.

[0013] A program of one embodiment of the present disclosure causes a computer to perform a process of acquiring a declarative model used to construct a target system, test-related information of tests performed on the target system, and results of execution of the tests on the target system, and a process of detecting errors in parameters included in the declarative model based on information extracted from the test-related information in accordance with the results of execution of the tests. Effect of the Invention

[0014] According to the present disclosure, it is possible to provide a detection device or the like that can automatically detect errors in the parameters of a declarative model based on the results of executing tests on a system built according to the declarative model. [Brief description of the drawings]

[0015] [Figure 1] 1 is a block diagram showing an example of connections between devices related to a detection device according to a first embodiment. FIG. [Diagram 2] FIG. 2 is a block diagram for explaining an example of a configuration of a declarative model orchestration device connected to a detection device according to the first embodiment. [Diagram 3] FIG. 2 is a diagram illustrating the first half of an example of a declarative model stored in a declarative model orchestration device connected to a detection device according to the first embodiment. [Figure 4] FIG. 11 is a diagram illustrating the latter half of an example of a declarative model stored in a declarative model orchestration device connected to a detection device according to the first embodiment. [Diagram 5] 2 is a block diagram for explaining an example of a configuration of a test code generation device connected to a detection device according to the first embodiment. FIG. [Figure 6] 3 is a diagram showing an example of a test code template stored in a test code generation device to which a detection device according to the first embodiment is connected; FIG. [Figure 7]4 is a diagram showing an example of test information stored in a test code generation device to which a detection device according to the first embodiment is connected; FIG. [Figure 8] 4 is a diagram showing an example of component information extracted by a test code generation device to which a detection device according to the first embodiment is connected; FIG. [Figure 9] 3 is a diagram showing an example of a test code generated by a test code generating device connected to a detection device according to the first embodiment; FIG. [Figure 10] 5A to 5C are diagrams illustrating an example of a test execution result acquired by the detection device according to the first embodiment. [Figure 11] 1 is a block diagram for explaining an example of a configuration of a detection device according to a first embodiment. [Figure 12] 4 is a conceptual diagram showing an example in which parameter error candidates detected by the detection device according to the first embodiment are displayed on a screen of a display device. FIG. [Figure 13] 4 is a flowchart for explaining an example of an operation of the detection device according to the first embodiment. [Figure 14] FIG. 11 is a block diagram showing an example of the configuration of a detection device according to a second embodiment. [Figure 15] FIG. 2 is a block diagram showing an example of a hardware configuration for implementing an apparatus such as a detection apparatus according to each embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] Hereinafter, the embodiments for carrying out the present invention will be described with reference to the drawings. However, the embodiments described below are limited in a manner that is technically preferable for carrying out the present invention, but the scope of the invention is not limited to the following. In addition, in all the drawings used to explain the following embodiments, the same reference numerals are used for similar parts unless otherwise specified. In addition, in the following embodiments, repeated explanations of similar configurations and operations may be omitted.

[0017] (First embodiment) First, the configuration of a detection device according to a first embodiment will be described with reference to the drawings. The detection device according to the present embodiment detects an error in a parameter included in a declarative model based on a result of executing a test on the system built according to the declarative model.

[0018] (composition) FIG. 1 is a block diagram for explaining the connection relationship of devices related to the detection device 10 of the present embodiment. FIG. 1 also illustrates a declarative model orchestration device 110, a test code generation device 120, a test code execution device 130, and an execution environment 150. The detection device 10, the test code generation device 120, and the test code execution device 130 constitute a test system 100. The test system 100 may be formed by the detection device 10 and the test code generation device 120 without including the test code execution device 130. In the following, the description of the communication functions of the detection device 10, the declarative model orchestration device 110, the test code generation device 120, the test code execution device 130, and the execution environment 150 may be omitted.

[0019] The detection device 10 is connected to the declarative model orchestration device 110, the test code generation device 120, and the test code execution device 130 via a network (not shown) such as the Internet or an intranet (FIG. 1). The detection device 10 detects an error location in a parameter of a declarative model based on information acquired from the test code execution device 130, the test code generation device 120, and the declarative model orchestration device 110. The detection of an error location in a parameter by the detection device 10 will be described in detail later.

[0020] [Declarative Model Orchestration Device] The declarative model orchestration device 110 is connected to the detection device 10, the test code generation device 120, and the execution environment 150 via a network (not shown) (FIG. 1). The declarative model orchestration device 110 interprets a declarative model of a system (also called a target system) constructed in the execution environment 150, and converts it into a processing format corresponding to the execution environment 150 in which the target system is constructed. The declarative model orchestration device 110 executes a provisioning process based on the converted processing format.

[0021] For example, the OASISTOSCA reference implementation is an example of the declarative model orchestration device 110. OASIS is an abbreviation for Organization for the Advancement of Structured Information Standards. TOSCA is an abbreviation for Topology and Orchestration Specification for Cloud Applications. For example, another example of a declarative model orchestration device 110 is the OpenStack Heat implementation.

[0022] 2 is a block diagram showing an example of a configuration of the declarative model orchestration device 110. The declarative model orchestration device 110 includes a declarative model orchestrator 111, a provisioning process execution unit 112, and a storage unit 113.

[0023] The declarative model orchestrator 111 converts the declarative model and the parameters used in the declarative model into data for an internal interpreter that performs execution processing. For example, the declarative model orchestrator 111 operates to convert the declarative model and the parameters used in the declarative model into a workflow having instructions corresponding to the execution environment 150 as components.

[0024] The provisioning process execution unit 112 processes the internal interpreter generated by the declarative model orchestrator 111, and performs provisioning processing of the target system for the execution environment 150. For example, the provisioning process execution unit 112 executes the workflow converted by the declarative model orchestrator 111.

[0025] The storage unit 113 stores a declarative model, components of the declarative model, and runtime parameters (hereinafter also referred to as parameters). For example, in OASIS TOSCA, the declarative model is a definition that represents an entire system configuration called a Service Template. The components are type definitions called types such as Node Type and Relationship Type. The declarative model is described based on the type definitions of the components. The components include server information of the provisioning destination and information on functions such as middleware and applications that run on the server indicated by the server information. For example, the server information is any one of a virtual server, a container, and a physical server. The parameters are values ​​specified by a user or values ​​acquired from the execution environment 150. For example, the parameters are specified in inputs of a Topology Template that is a part of a Service Template.

[0026] 3 and 4 are examples of a declarative model. FIG. 3 shows the first half of an example of a declarative model, and FIG. 4 shows the second half of an example of a declarative model. The declarative models of FIG. 3 and FIG. 4 include content quoted from Non-Patent Document 1 (TOSCA Simple Profile in YAML Version 1.2, Committee Specification 01, 19 July 2018.). In the example of the declarative model of FIG. 3 and FIG. 4, there is an error in the specification of db_user (input parameter) of Standard (interface) of wordpress (node) (second line from the bottom of FIG. 3). Detection of errors in parameters included in the declarative models of FIG. 3 and FIG. 4 will be described later.

[0027] [Execution environment] The execution environment 150 is connected to the declarative model orchestration device 110 and the test code execution device 130 via a network (not shown) (FIG. 1). The execution environment 150 is an execution environment in which an actual system runs. For example, OpenStack, AWS (Amazon Web Services), VMware, etc. are examples of the execution environment 150. The system built in the execution environment 150 according to the declarative model is tested by the test code execution device 130 using the test code generated by the test code generation device 120.

[0028] [Test Code Generator] The test code generation device 120 is connected to the detection device 10, the declarative model orchestration device 110, and the test code execution device 130 via a network (not shown) (FIG. 1). The test code generation device 120 extracts code that needs to be executed for a target system constructed according to a declarative model from test information that is preset for each component of the declarative model. The test code generation device 120 uses the extracted code to automatically generate test code for the target system.

[0029] 5 is a block diagram showing an example of a configuration of the test code generation device 120. The test code generation device 120 includes an information acquisition unit 121, a test information storage unit 122, and a test code generation unit 123.

[0030] The information acquiring unit 121 acquires information stored in the storage unit 113 of the declarative model orchestration device 110. For example, the information acquiring unit 121 acquires information related to a declarative model, components of the declarative model, and parameters.

[0031] The test information storage unit 122 stores a template of a test code for a component of a declarative model (also called a test code template) and information (also called test information) in which the component of the declarative model and a replacement rule of a parameter of the test code are associated with each other. In other words, the test information storage unit 122 stores a replacement rule of a parameter value for each test code template (hereinafter also called a template).

[0032] FIG. 6 is a diagram showing an example of a template stored in the test information storage unit 122. FIG. 6 shows a list of a plurality of test code templates (also called a template list). The template list includes the name of the template (template name) associated with the template identifier (template ID) and the source code (program) of the template. Each test code included in the template column of the template list in FIG. 6 includes a portion in which the name of a parameter (also called a parameter name) is written in the format of ":(parameter name):". The portion inside the parentheses (including the parentheses) in which the parameter name is written in the template column is replaced with a specific parameter value when the test code generation unit 123 generates a test code.

[0033] Fig. 7 is a diagram showing an example of test information stored in the test information storage unit 122. The test information is information on the correspondence between the components of a declarative model and the test code templates used for the components. In Fig. 7, a plurality of pieces of test information are described in a table format (also called a test information list). The test information in Fig. 7 includes the name of a type (type name) indicating the components of a declarative model, the name of a test (test name), a template ID, and parameters (replacement rules for parameter values), which are associated with a test identifier (test ID).

[0034] For example, according to the correspondence in FIG. 7, for a component with a type name of "tosca.nodes.DBMS.MySQL", templates with template IDs 1 to 4 among the templates in FIG. 6 are used. The parameter column stores information on the name and value of the parameter to be replaced. The parameter value can be specified not only as a fixed value but also as a parameter value at run time. For example, in the example in FIG. 7, the property for the component to be linked is described as "prop", and the requirements for the component to be linked are described as "req". Descriptions such as "prop" and "req" indicate that the information acquisition unit 121 acquires a value from the declarative model orchestration device 110. For example, the description "prop.port" indicates that the value specified in the "port" property of the component is acquired at run time. Note that the description for acquiring a parameter value at run time is not limited to "prop" or "req". The description for acquiring a parameter value at run time can be a description according to the type of the declarative model orchestration device 110.

[0035] The test code generation unit 123 acquires the information acquired from the storage unit 113 of the declarative model orchestration device 110 by the information acquisition unit 121 and the information stored in the test information storage unit 122. For example, the test code generation unit 123 acquires the information in the following procedure.

[0036] The test code generation unit 123 acquires a template of a test code for a component of a declarative model. Specifically, the test code generation unit 123 reads out a template of a test code for testing the component from the test information storage unit 122 based on information of the component of the declarative model. The test code generation unit 123 acquires a parameter value of a parameter included in the template of the test code for the component of the declarative model. Specifically, the test code generation unit 123 acquires a parameter value based on an acquisition rule of a parameter value for each template of the test code stored in the test information storage unit 122. The acquisition rule of the parameter value includes a case where the parameter value is specified as a fixed value (constant) and a case where an instruction is given to acquire a parameter value from the declarative model orchestration device 110. The test code generation unit 123 may also acquire a parameter value from the execution environment 150. The test code generation unit 123 acquires a test code for the component of the declarative model by applying the acquired parameter value to the template.

[0037] The test code generation unit 123 extracts components of a declarative model from the declarative model (e.g., FIG. 3 and FIG. 4) stored in the declarative model orchestration device 110. The components include server information of the provisioning destination and information on the functions of middleware and applications that operate on the server indicated by the server information.

[0038] Fig. 8 is a diagram showing an example of information (also called component information) related to components extracted by the test code generation unit 123. In the example of Fig. 8, component information related to a plurality of components is compiled in a table format (also called a component table). The component information of each row in the component table of Fig. 8 includes an identifier (ID: Identifier) ​​of the component (node), the name of the component (node) extracted from the declarative model, the name of the type (type name) of the component (node), and server information on which the component (node) is provisioned.

[0039] For example, in the declarative model examples of FIG. 3 and FIG. 4, the test code generation unit 123 extracts each label included under the label "node_templates" (line 17 from the bottom in FIG. 3) as the name of a node. In the declarative model examples of FIG. 3 and FIG. 4, "wordpress" (line 16 from the bottom in FIG. 3), "apache" (line 1 from the top in FIG. 4), "web_server" (line 7 from the top in FIG. 4), "wordpress_db" (line 11 from the top in FIG. 4), "mysql" (line 11 from the bottom in FIG. 4), and "db_server" (line 4 from the bottom in FIG. 4) are extracted. The test code generation unit 123 writes the names of the extracted nodes in the node column of the component table of FIG. 8. In addition, the test code generation unit 123 extracts the name of the type (component) indicated by "type:···" for each node from the declarative model (FIG. 3 and FIG. 4). The test code generation unit 123 writes the name of the extracted type in the type column of the component table of FIG. 8. Furthermore, the test code generation unit 123 detects the description of "host:..." for each node from the declarative model (FIGS. 3 and 4), and follows the nodes included in the detected description to extract the name of the server (server information). For example, the test code generation unit 123 detects the description of "host:apache" (10th line from the bottom in FIG. 3) of "wordpress", follows "appache" (first line from the top in FIG. 4), and detects the description of "host:web_server" (sixth line from the top in FIG. 4). Furthermore, when following "web_server" (seventh line from the top in FIG. 4), there is no description of "host:...", so the test code generation unit 123 detects a server named "web_server" as a server corresponding to "wordpress". The test code generation unit 123 writes the detected server name (server information) in the server column of the component table in FIG. 8. Similarly, for nodes other than "wordpress" (apache, wordpress_db, myspl), the test code generation unit 123 detects the names of the servers (web_server, db_server, db_server) corresponding to each node.Test code generation unit 123 writes the detected server name (server information) in the server column of the component table of Fig. 8. On the other hand, for the "web_server" and "db_server" nodes, there is no description of "host:...", so the server name is not detected. For the nodes (web_server, db_server) for which the server name was not detected, test code generation unit 123 writes the symbol "-" in the server column of the component table of Fig. 8.

[0040] Based on the acquired information, the test code generation unit 123 generates test code for a system (target system) constructed according to a declarative model. For example, the test code generation unit 123 generates test code using a method described in Patent Document 1 (JP Patent Publication No. 2020-181509). Details of the method of generating test code by the test code generation unit 123 will not be described.

[0041] Fig. 9 is a diagram showing an example of test code generated by the test code generating device 120. Fig. 9 shows an example of test code for wordpress (node) provisioned in web_server (server).

[0042] [Test code execution device] The test code execution device 130 is connected to the detection device 10, the test code generation device 120, and the execution environment 150 via a network (not shown) (FIG. 1). The test code execution device 130 interprets the test code generated by the test code generation device 120 and executes tests on a target system constructed according to a declarative model. For example, Serverspec and Infrataster are examples of the test code execution device 130.

[0043] Fig. 10 is a diagram showing an example of the execution result of a test by the test code execution device 130. The execution result of the test in Fig. 10 includes an identifier (test code ID) of the test code whose execution result was NG, the execution result of the test (NG: No Good), the test ID, the name of the node (node ​​name) on which the test was executed, and server information (server) including the node on which the test was executed. The execution result of the test by the test code execution device 130 is acquired by the detection device 10.

[0044] [Detection device] Fig. 11 is a block diagram for explaining an example of the configuration of the detection device 10. The detection device 10 has an acquisition unit 11 and a detection unit 12. Fig. 11 also illustrates a declarative model orchestration device 110, a test code generation device 120, and a test code execution device 130, which are connected to the acquisition unit 11 of the detection device 10.

[0045] The acquiring unit 11 acquires test execution results from the test code executing device 130. For example, the acquiring unit 11 acquires test execution results that are NG (No Good) from the test code executing device 130. The acquiring unit 11 also acquires test-related information from the test code generating device 120. The test-related information includes component information (FIG. 8), test information (FIG. 7), and templates (FIG. 6). The acquiring unit 11 also acquires declarative models from the declarative model orchestration device 110.

[0046] The detection unit 12 extracts a replacement rule for a parameter of the test code from the test-related information according to the test execution result, and detects an error in a parameter included in the declarative model based on the extracted replacement rule for the parameter.

[0047] For example, the detection unit 12 extracts the component information of the row with ID1 from the component information table of Fig. 8 based on the node name (wordpress) and server information (web_server) included in the test execution result (Fig. 10) of Fig. 10. Next, the detection unit 12 extracts the test information of the row with test ID 9 from the test information list of Fig. 7 based on the test ID (9) included in the execution result (Fig. 10). Next, the detection unit 12 extracts the test code template of the row with template ID 6 from the list of test code templates of Fig. 6 based on the template ID (6) included in the test information of the row with test ID 9 extracted from the test information list of Fig. 7.

[0048] For example, the detection unit 12 detects a node specified in req.database_endpoint of wordpress (node) from the declarative model as an error candidate based on the test-related information extracted in the above procedure and the parameter replacement rule of the test code (parameter column in FIG. 7). For example, the detection unit 12 detects the properties (name, user, password) of wordpress_db (node) as an error candidate (lines 14 to 16 from the top in FIG. 4). In addition, the detection unit 12 detects input parameters (wp_db_name, wp_db_user, wp_db_password) corresponding to the detected properties as error candidates (lines 5, 7, and 9 from the top in FIG. 3). Furthermore, the detection unit 12 detects a portion where the detected input parameter is used as an error candidate. That is, the detection unit 12 detects the input parameters (db_name, db_user, db_password) of the interface of wordpress (node) as error candidates (lines 1 to 3 from the bottom in FIG. 3).

[0049] For example, information on parameter error candidates of the declarative model detected by the detection unit 12 is displayed on the screen of a display device (not shown). For example, the parameter error candidates are highlighted on the screen of the display device 170. For example, if the parameter error candidates are displayed on the screen of the display device 170 in a color different from other parts, surrounded by a frame, or blinking, it becomes easier to detect the parameter error candidates from among the information on the declarative model. A user who visually recognizes the information displayed on the screen of the display device can detect parameter errors in the declarative model based on that information.

[0050] FIG. 12 is a conceptual diagram showing an example of displaying parameter error candidates of the declarative model detected by the detection unit 12 on the screen of the display device 170. In the example of FIG. 12, parameter error candidates (db_name, db_user, db_password in the first to third lines from the bottom) detected from the declarative model (FIGS. 3 and 4) are shown in a display format (bold) different from the other parts. Also, in FIG. 12, an erroneously specified input parameter (name in the second line from the bottom) is shown in italics. A user who visually checks the screen of the display device 170 can recognize that the parameter error candidates are included in the parts with different display formats (db_name, db_user, db_password). For example, the user can detect an erroneously specified input parameter (name) based on the recognized parameter error candidates.

[0051] (operation) Next, an example of the operation of the detection device 10 of this embodiment will be described with reference to the drawings.

[0052] In FIG. 4, first, the detection device 10 acquires the results of execution of a test on a target system constructed according to a declarative model from the test code execution device 130 (step S11).

[0053] If there is an NG execution result (Yes in step S12), the detection device 10 acquires test-related information on the components of the declarative model from the test code generation device 120 (step S13). If there is no NG execution result (No in step S12), the process according to the flowchart in FIG. 13 ends.

[0054] After step S13, the detection device 10 extracts test-related information related to the test for which the execution result is NG from the acquired test-related information (step S14).

[0055] Next, the detection device 10 acquires the declarative model from the declarative model orchestration device 110 (step S15).

[0056] Next, the detection apparatus 10 detects parameter error candidates from the declarative model based on the extracted test-related information (step S16).

[0057] As described above, the detection device of this embodiment includes an acquisition unit and a detection unit. The acquisition unit acquires a declarative model used to build a target system, test-related information of tests executed on the target system, and execution results of the tests on the target system. The detection unit detects errors in parameters included in the declarative model based on information extracted from the test-related information according to the execution results of the tests.

[0058] The detection device of this embodiment detects parameter errors included in a declarative model based on information extracted from test-related information according to test execution results. Therefore, the detection device of this embodiment can automatically detect parameter errors in a declarative model based on test execution results for a system built according to the declarative model.

[0059] In one aspect of the present embodiment, the test-related information includes component information, test information, and template information. The component information includes an identifier of a component in a declarative model, a name of the component extracted from the declarative model, a type of the component, and server information on which the component is provisioned. The test information includes an identifier of a test, a name of a type of the component, a name of a test to be executed, an identifier of a test code template used in the test, and a substitution rule for a parameter of a test code included in the test code template. The template information includes an identifier of a test code template, a name of the test code template, and a test code template. According to this aspect, an error location of a parameter of a declarative model can be automatically detected based on the test-related information including the component information, test information, and template information.

[0060] In one aspect of the present embodiment, the acquisition unit acquires test execution result information including a test execution result, a test identifier, the name of the component on which the test was executed, and server information on which the component was provisioned. The detection unit extracts test information based on the identifier of the test included in the test execution result information in which the test execution result is NG. The detection unit extracts a parameter replacement rule based on the identifier of the test code template included in the extracted test information. The detection unit detects parameter error candidates included in the declarative model based on the extracted parameter replacement rule. For example, the detection unit detects a property of the component as a parameter error candidate from the declarative model based on the parameter replacement rule. For example, the detection unit detects an input parameter corresponding to the property of the detected component as a parameter error candidate. For example, the detection unit detects an input parameter of the interface of the detected component as a parameter error candidate. According to this aspect, by tracing the test-related information according to the test execution result, it is possible to automatically detect an error location of a parameter in the declarative model.

[0061] A test system according to an aspect of the present embodiment includes a test code generating device, a test code executing device, and a detection device. The test code generating device extracts information about components of a declarative model from the declarative model, and obtains a test code template linked to the information about the components. The test code generating device obtains parameter values ​​to be applied to the test code template according to parameter replacement rules linked to the information about the components. The test code generating device applies the obtained parameter values ​​to the test code template to generate test code. The test code executing device executes the test code generated by the test code generating device on a target system constructed in an execution environment. The detection device obtains a declarative model used to construct the target system, test-related information of a test executed on the target system, and an execution result of the test on the target system. The detection device detects an error in a parameter included in the declarative model based on information extracted from the test-related information according to the execution result of the test. According to the test system according to the present aspect, an error in a parameter included in a declarative model can be detected according to the execution result of a test using a test code generated by the test code generating device.

[0062] As described above, the detection device of this embodiment can automatically detect the location of an error in the parameters of a declarative model. Therefore, according to this embodiment, even an operator who does not have the skills to understand the correspondence between the cause of a test execution result being NG and the error in the declarative model can easily identify the location of the error in the parameters of the declarative model.

[0063] For example, the detection device of this embodiment belongs to the field of cloud operation management, and can detect an error in a parameter of a declarative model when a target system constructed according to the declarative model is not constructed correctly. For example, the method of this embodiment can be applied to the field of managing cloud operations. For example, the method of this embodiment can be applied to devices that use a template provisioning function or an IaC (Infrastructure as Code) function.

[0064] Second Embodiment Next, a detection device according to a second embodiment will be described with reference to the drawings. The detection device of this embodiment has a simplified configuration of the first detection device. FIG. 14 is a block diagram showing an example of the configuration of the detection device 20 of this embodiment. The detection device 20 includes an acquisition unit 21 and a detection unit 22.

[0065] The acquisition unit 21 acquires a declarative model used to construct a target system, test-related information of tests executed on the target system, and execution results of the tests on the target system. The detection unit 22 detects errors in parameters included in the declarative model based on information extracted from the test-related information according to the execution results of the tests.

[0066] The detection device of this embodiment detects parameter errors included in a declarative model based on information extracted from test-related information according to test execution results. Therefore, the detection device of this embodiment can automatically detect parameter errors in a declarative model based on test execution results for a system built according to the declarative model.

[0067] (Hardware) Here, a hardware configuration for executing the processing of a detection device or the like (including a declarative model orchestration device, a test code generation device, and a test code execution device) according to each embodiment of the present disclosure will be described using an information processing device 90 in Fig. 15 as an example. Note that the information processing device 90 in Fig. 15 is an example of a configuration for executing the processing of a detection device or the like according to each embodiment, and does not limit the scope of the present disclosure.

[0068] As shown in Fig. 15, an information processing device 90 includes a processor 91, a main storage device 92, an auxiliary storage device 93, an input / output interface 95, and a communication interface 96. In Fig. 15, the interface is abbreviated as I / F (Interface). The processor 91, the main storage device 92, the auxiliary storage device 93, the input / output interface 95, and the communication interface 96 are connected to each other via a bus 98 so as to be able to communicate data with each other. In addition, the processor 91, the main storage device 92, the auxiliary storage device 93, and the input / output interface 95 are connected to a network such as the Internet or an intranet via the communication interface 96.

[0069] The processor 91 loads a program stored in the auxiliary storage device 93 or the like into the main storage device 92. The processor 91 executes the program loaded into the main storage device 92. In this embodiment, a software program installed in the information processing device 90 may be used. The processor 91 executes processing by the detection device or the like according to this embodiment.

[0070] The main memory device 92 has an area in which a program is loaded. The processor 91 loads a program stored in the auxiliary memory device 93 or the like in the main memory device 92. The main memory device 92 is realized by a volatile memory such as a dynamic random access memory (DRAM). Furthermore, a non-volatile memory such as a magnetoresistive random access memory (MRAM) may be configured / added to the main memory device 92.

[0071] The auxiliary storage device 93 stores various data such as programs. The auxiliary storage device 93 is realized by a local disk such as a hard disk or a flash memory. Note that it is also possible to configure the main storage device 92 to store various data and omit the auxiliary storage device 93.

[0072] The input / output interface 95 is an interface for connecting the information processing device 90 to peripheral devices based on standards and specifications. The communication interface 96 is an interface for connecting to external systems and devices through a network such as the Internet or an intranet based on standards and specifications. The input / output interface 95 and the communication interface 96 may be a common interface for connecting to external devices.

[0073] Input devices such as a keyboard, a mouse, and a touch panel may be connected to the information processing device 90 as necessary. These input devices are used to input information and settings. When a touch panel is used as an input device, the display screen of the display device may also serve as an interface for the input device. Data communication between the processor 91 and the input devices may be mediated by an input / output interface 95.

[0074] The information processing device 90 may be equipped with a display device for displaying information. When the display device is equipped, the information processing device 90 is preferably equipped with a display control device (not shown) for controlling the display of the display device. The display device may be connected to the information processing device 90 via the input / output interface 95.

[0075] The information processing device 90 may also be provided with a drive device. The drive device mediates between the processor 91 and a recording medium (program recording medium) for reading data and programs from the recording medium, writing the processing results of the information processing device 90 to the recording medium, and the like. The drive device may be connected to the information processing device 90 via an input / output interface 95.

[0076] The above is an example of a hardware configuration for enabling the detection device according to each embodiment of the present invention. The hardware configuration in FIG. 15 is an example of a hardware configuration for executing the arithmetic processing of the detection device according to each embodiment, and does not limit the scope of the present invention. In addition, a program for causing a computer to execute processing related to the detection device according to each embodiment is also included in the scope of the present invention. Furthermore, a program recording medium on which the program according to each embodiment is recorded is also included in the scope of the present invention. The recording medium can be realized, for example, by an optical recording medium such as a CD (Compact Disc) or a DVD (Digital Versatile Disc). The recording medium may be realized by a semiconductor recording medium such as a USB (Universal Serial Bus) memory or an SD (Secure Digital) card. In addition, the recording medium may be realized by a magnetic recording medium such as a flexible disk or other recording medium. When the program executed by the processor is recorded on a recording medium, the recording medium corresponds to a program recording medium.

[0077] The components of the detection device of each embodiment may be combined in any manner. Furthermore, the components of the detection device of each embodiment may be realized by software or a circuit.

[0078] Although the present invention has been described above with reference to the embodiments, the present invention is not limited to the above-mentioned embodiments. Various modifications that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention. [Explanation of symbols]

[0079] 10. Detection Device 11 Acquisition Department 12 Detection section 110 Declarative Model Orchestration Device 111 Declarative Model Orchestrator 112 Provisioning process execution unit 113 Storage section 120 Test Code Generator 121 Information Acquisition Department 122 Test information storage unit 123 Test Code Generation Unit 130 Test code execution device 150 Execution environment

Claims

1. an acquisition means for acquiring a declarative model used to build a target system, test-related information of tests executed on the target system, and results of executing the tests on the target system; A detection means for detecting an error in a parameter included in the declarative model based on information extracted from the test-related information in response to a result of the execution of the test, The test-related information includes: component information including an identifier of the component in the declarative model, a name of the component extracted from the declarative model, a type of the component, and server information on which the component is provisioned; test information including an identifier of the test, a name of the type of the component, a name of the test to be executed, an identifier of a test code template used in the test, and a substitution rule for the parameters of the test code included in the test code template; an identifier of the test code template, a name of the test code template, and template information including the test code template; The acquisition means includes: obtaining test execution result information including a result of the execution of the test, an identifier of the test, a name of the component on which the test was executed, and information about the server on which the component is provisioned; The detection means includes: extracting the test information based on an identifier of the test included in the test execution result information of the test whose execution result is NG; extracting a replacement rule for the parameter based on an identifier of the test code template included in the extracted test information; A detection device that detects error candidates for the parameters included in the declarative model based on the extracted replacement rules for the parameters.

2. The detection means includes: The detection device according to claim 1 , further comprising: detecting a property of the component as an error candidate for the parameter from the declarative model based on a replacement rule for the parameter.

3. The detection means includes: The detection apparatus according to claim 2 , further comprising: detecting an input parameter corresponding to a property of the detected component as an error candidate of the parameter.

4. The detection means includes:

4. The detection device according to claim 2, further comprising: detecting an input parameter of an interface of the detected component as an error candidate of the parameter.

5. A detection device according to any one of claims 1 to 4, A test system comprising: a test code generation device that extracts information about components of a declarative model from the declarative model, obtains a test code template linked to the information about the components, obtains values ​​of the parameters to be applied to the test code template according to parameter replacement rules linked to the information about the components, and applies the obtained parameter values ​​to the test code template to generate test code.

6. 6. The test system according to claim 5, further comprising a test code execution device that executes the test code generated by the test code generation device on a target system built in an execution environment.

7. The computer obtaining a declarative model used to construct a target system, test-related information for tests executed on the target system, and results of executing the tests on the target system; Detecting an error in a parameter included in the declarative model based on information extracted from the test-related information in response to a result of the execution of the test; The test-related information comprises: component information including an identifier of the component in the declarative model, a name of the component extracted from the declarative model, a type of the component, and server information on which the component is provisioned; test information including an identifier of the test, a name of the type of the component, a name of the test to be executed, an identifier of a test code template used in the test, and a substitution rule for the parameters of the test code included in the test code template; an identifier of the test code template, a name of the test code template, and template information including the test code template; In the acquisition, obtaining test execution result information including a result of the execution of the test, an identifier of the test, a name of the component on which the test was executed, and information about the server on which the component is provisioned; In the detection, extracting the test information based on an identifier of the test included in the test execution result information of the test whose execution result is NG; extracting a replacement rule for the parameter based on an identifier of the test code template included in the extracted test information; A detection method for detecting error candidates for the parameters included in the declarative model based on the extracted replacement rules for the parameters.

8. obtaining a declarative model used to build a target system, test-related information for tests run on the target system, and results of running the tests on the target system; detecting an error in a parameter included in the declarative model based on information extracted from the test-related information in response to a result of the execution of the test; The test-related information includes: component information including an identifier of the component in the declarative model, a name of the component extracted from the declarative model, a type of the component, and server information on which the component is provisioned; test information including an identifier of the test, a name of the type of the component, a name of the test to be executed, an identifier of a test code template used in the test, and a substitution rule for the parameters of the test code included in the test code template; an identifier of the test code template, a name of the test code template, and template information including the test code template; The acquiring process includes: obtaining test execution result information including a result of the test execution, an identifier of the test, a name of the component on which the test was executed, and information on the server on which the component is provisioned; The detecting process includes: A process of extracting the test information based on an identifier of the test included in the test execution result information of the test whose execution result is NG; A process of extracting a replacement rule for the parameter based on an identifier of the test code template included in the extracted test information; and detecting error candidates for the parameters included in the declarative model based on the extracted replacement rules for the parameters.

Images