Patent Publication Number: US-2023141619-A1

Title: Generation device, method of generation, and computer program product

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is based upon and claims the benefit of priority from Japanese Patent Application No. 2021-182566, filed on Nov. 9, 2021; the entire contents of which are incorporated herein by reference. 
     FIELD 
     Embodiments described herein relate generally to a generation device, a method of generation, and a computer program product. 
     BACKGROUND 
     In a web application programming interface (Web API), plurality of parameters are present for each path. For each of the parameters, numerous tests, such as check of upper and lower boundary values and a standard value, are carried out. Developing a test code therefore adds workload to developers in charge of testing, since merely a small change in path and parameters causes a large change and increase of the test. A test code improperly created impairs the quality of the Web API, as the final product, which is a subsequent problem to be solved. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG.  1    is an illustrative diagram of a Web API development flow according to a first embodiment; 
         FIG.  2    is a diagram that illustrates an example functional configuration of a generation device according to the first embodiment; 
         FIG.  3    is a diagram that illustrates an example test setting file according to the first embodiment; 
         FIG.  4    is a flowchart that illustrates an example method of generation according to the first embodiment; 
         FIG.  5    is a diagram that illustrates an example test setting file according to a second embodiment; 
         FIG.  6    is a flowchart that illustrates an example method of generation according to the second embodiment; and 
         FIG.  7    is a diagram that illustrates an example hardware configuration of the generation device according to the first and the second embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     According to an embodiment, a generation device includes an analysis unit, a test scenario generation unit, and a test code generation unit. The analysis unit is configured to analyze a definition file that defines a structure of web application programming interface (Web API) and generate structure analysis data of the Web API. The test scenario generation unit is configured to generate test scenario data of the Web API from a test setting file and the structure analysis data. The test setting file including a test type of the Web API and a test item depending on the test type. The test code generation unit is configured to generate test code for testing the Web API based on the test scenario data. 
     Embodiments of a generation device, a method of generation, and a computer program will now be described in detail with reference to the accompanying drawings. 
     First Embodiment 
     A development flow of a Web API of a first embodiment will now be described. 
       FIG.  1    is an illustrative diagram of a Web API development flow according to the first embodiment.  FIG.  1    illustrates an example flow for developing a Web API for a cloud system used by an air conditioner manufacturer providing infrastructure services. Typically, development of a Web API includes processes of designing the Web API, implementing the Web API, implementing test code of the Web API, and testing the Web API. After testing of the Web API, the Web API is released unless any quality issues are found. 
     Generating Web API test code requires preparation of a lot of patterns, and adds heavy workload to the developers. For example, conventional automatic test code generation systems can only generate positive tests and part of negative tests of a Web API that can be confirmed using a definition file of a Web API. 
     A generation device of the first embodiment relates to a device that automatically generates test code of a Web API used in Web API development. The generation device of the first embodiment described later can automate the process of implementing test code, leading to a considerable reduction in the time required for test code development. Furthermore, the test process can be shortened by loading the test code generated by the generation device of the first embodiment to a commercially available or free of charge tool, such as Tavern, that automatically runs a test. The above method can automate the process of creating test code, which is a large part of workload in software development, thereby reducing the workload on the test code developer. 
     Example Functional Configuration 
       FIG.  2    is a diagram that illustrates an example functional configuration of the generation device according to the first embodiment. A generation device  10  of the first embodiment includes an analysis unit  1 , a test scenario generation unit  2 , and a test code generation unit  3 . 
     The analysis unit  1  analyzes a definition file  101  that defines the structure of a Web API and generates structure analysis data  102  of the Web API. The definition file  101  includes, for example, source code of the Web API. 
     The test scenario generation unit  2  generates test scenario data  104  that indicates a test scenario for the Web API, from a test setting file  103 , which includes the test type of the Web API and test items for each test type, and the structure analysis data  102 . The test scenario data  104  is used to generate test code  105  to be actually run as a program. 
     The test code generation unit  3  generates the test code  105  for testing the Web API based on the test scenario data  104 . 
     Example Test Setting File 
       FIG.  3    is a diagram that illustrates an example of the test setting file  103  according to the first embodiment. The test setting file  103  is used to generate the test scenario data  104  to validate the function of the Web API. In the example of  FIG.  3   , parameter type information (a test type for a parameter type) relating to the parameter of the Web API is a variation of the Web API test type. 
     The parameter type &lt;integer&gt; includes test items “zero”, “max”, “min”, and “string”. The test item “zero” is an item for running a test by assigning 0 (or the null character for the string type) to the parameter. The test item “max” is an item for running a test by assigning the largest value of the parameter to the parameter. The test item “min” is an item for running a test by assigning the smallest value of the parameter to the parameter. The test item “string” is an item for running a test by assigning character string data to the parameter. 
     The parameter type &lt;string&gt; includes test items “zero”, “byte”, and “len”. The test item “zero” is an item for running a test by assigning the null character (0 for the numeric type) to the parameter. The test item “byte” is an item for running a test by assigning, for example, character string data in double byte code to the parameter. The test item “len” is an item for running a test by assigning, for example, character string data in the largest string length assignable to the parameter. 
       FIG.  3    is merely an example, and the test items for each parameter type may include items for testing any data, such as the upper limit, the lower limit, a standard value, and an abnormal value according to the parameter type. 
     Example Method of Generation 
       FIG.  4    is a flowchart that illustrates an example method of generation according to the first embodiment. The analysis unit  1  reads the definition file  101  of the Web API (Step S 1 ). The definition file  101  is created by, for example, a Web API developer. The definition file  101  is written in machine-readable format. The machine-readable format may be any of Open API, web services description language (WSDL), and simple object access protocol (SOAP). For simple explanation, the format is Open API, in this example. 
     The analysis unit  1  analyzes the definition file  101  (Open API) read at Step S 1  (Step S 2 ) and generates the structure analysis data  102  indicating the structure of the Web API. The structure analysis data  102  includes parameter information of the Web API. This structure analysis data  102  is input to the test scenario generation unit  2 . 
     The structure of the Web API includes, for example, path information of the Web API written in Open API, the manner of access for the HTTP method in each path, the parameter name (for example, combination of a path and a method), and the parameter type information (for example, the parameter type such as integer and string). 
     The test scenario generation unit  2  reads the test setting file  103  (see  FIG.  3   ) (Step S 3 ). The test setting file  103  is written in, for example, domain-specific language (DSL) as a specialized format. 
     The test scenario generation unit  2  confirms the type of parameter (parameter type) included in the Web API based on the structure analysis data  102  and the test setting file  103  (Step S 4 ). Specifically, the test scenario generation unit  2  confirms the parameter type on each combination of a path and a method, based on the parameter information of the Web API specified by the structure analysis data  102 . The test scenario generation unit  2  then matches this parameter type with the parameter type in the test setting file  103 . 
     The test scenario generation unit  2  confirms the test type (test item) of the parameter determined at Step S 4  (Step S 5 ). Specifically, on each parameter type matched at Step S 4 , the test scenario generation unit  2  obtains the test items of the parameter type from the test setting file  103 . 
     The test scenario generation unit  2  generates the test scenario data  104  based on the test items obtained by the processing of Step S 5  (Step S 6 ). For example, if the test item is “zero,” the test scenario generation unit  2  generates a test scenario for making a query to the server, by assigning a value of “0”, more specifically, 0 for the numeric type, and the null character for the string type, to the parameter value of the Web API. 
     In the last step, the test code generation unit  3  generates the test code  105  to be actually run by a test automated execution tool based on the test scenario data  104  generated by the processing of Step S 6  (Step S 7 ). 
     As explained above, the generation device  10  of the first embodiment can reduce the time required for developing the test code  105  for testing the Web API. Specifically, plurality of parameters are present in one path specific to the Web API, and the definition file  101  of the Web API is not capable of expressing various tests such as check of upper and lower boundary values and a standard value for each parameter. The test code  105  for plurality of parameters present for each combination of a path and a method of the Web API can be automatically generate by the test code generation unit  3  reading test items for each type of parameter (parameter type) included in the test setting file  103 , which is defined separately from the definition file  101 . 
     According to the first embodiment, a Web API developer only needs to create the definition file  101  of a Web API complying with the specification, in order to prepare necessary test code. This method is effective in reducing workload of the developer. More specifically, for example, this method allows the developer to easily have wider variety of test items for each parameter type of the Web API, leading to a considerable reduction in the time required for test code development. 
     Conventionally, it has been difficult to completely automatically generate test code specific to a Web API. For example, a technique that creates a template of test code from the definition file  101  for building a Web API of a workflow document, an interface document, and others, has been used. This method can reduce the workload on the developer in charge of testing. However, this method eventually requires human operation to write code, and therefore a reduction in workload is limited. There is also a technique that automatically runs a subsequent test when a test is finished, and generates new test code for the subsequent test by changing parameters and other elements. This method, however, also needs human operation to write the initial test code. 
     Second Embodiment 
     A second embodiment will now be described. In the second embodiment, description similar to that of the first embodiment will be omitted, and parts different from those of the first embodiment will be described. 
     In the second embodiment, the descriptive form of the test setting file  103  differs from that of the first embodiment. In addition to the definition file  101  of a Web API, a test setting file  103  of the second embodiment is configured to enable output of test code for authentication and authorization in the Web API, an irregular negative test, and others. 
     In the first embodiment, a test scenario that includes all tests of a value assigned to the parameter of the Web API is generated. With a structure in the second embodiment, such a test item is allowed to be added that includes some steps of the flow (in other words, until failure occurs) of, for example, authentication and authorization processing. 
     Example Test Setting File 
       FIG.  5    is a diagram that illustrates an example of the test setting file  103  according to the second embodiment. In the example of  FIG.  5   , as test types of a Web API, flow information of the Web API (a test type for a flow type) and parameter type information of the Web API (a test type for a parameter type) are included. The test setting file  103  of the second embodiment sets the test type for each combination of a Web API path and a method. 
     Flow information &lt;flow&gt; includes a path to be tested having test items in the order of “auth”, “login” and “token”. The test item “auth” is a test item for testing the patterns of success and failure of authentication processing. The test item “login” is a test item for testing the patterns of success and failure of login processing when the authentication processing succeeds. The test item “token” is a test item for testing the patterns of success and failure of token processing when the login processing succeeds. 
     The flow information &lt;flow&gt; in  FIG.  5    is an example, and the flow information may include any test item for confirming the execution sequence of a series of processing included in the flow. 
     Example Method of Generation 
       FIG.  6    is a flowchart that illustrates an example method of generation according to the second embodiment. Since the processing of Steps S 1  to S 7  is the same as the method of generation of the first embodiment (see  FIG.  4   ), explanation thereof will be omitted. The second embodiment differs from the first embodiment in the content written in the test setting file  103  in that new flow information is added, and Steps S 8  to S 10  are added to the operation flow. 
     The generation device  10  performs the same operation as in the first embodiment down to Step S 3 . The test scenario generation unit  2  determines whether to run the test of parameter information or to run the test of sequential processing (flow information) on each combination of a path and a method included in the test setting file  103  (Step S 8 ). 
     In the case of running the test of parameter information, the processing moves to Step S 4 , so that the generation device  10  performs the same processing as that of the first embodiment. 
     In the case of running the test of flow information, the test scenario generation unit  2  confirms the path to be tested of flow information included in the Web API using the structure analysis data  102  and the test setting file  103  (Step S 9 ). For example, in the example of the test setting file  103  of  FIG.  5   , the test scenario generation unit  2  acquires the path to be tested in the order of “auth”, “login”, and “token” included in the flow information &lt;flow&gt;. The test scenario generation unit  2  identifies the flow corresponding to the path to be tested from flow information of the Web API (information indicating the structure of the flow of the Web API) included in the structure analysis data  102 . 
     The test scenario generation unit  2  generates the test scenario data  104  for the path to be tested (Step S 10 ). For example, in the example of the test setting file  103  of  FIG.  5   , the test scenario generation unit  2  adds the following first through fourth test scenarios to the test scenario data  104 . 
     The first test scenario is a test scenario in which authentication processing of the test item “auth” fails. 
     The second test scenario is a scenario in which the authentication processing of the test item “auth” succeeds while the authentication processing of the test item “login” fails. 
     The third test scenario is a scenario in which the authentication processing of the test item “auth” succeeds, the test item “login” succeeds, and the test item “login” fails. 
     The fourth test scenario is a scenario in which the authentication processing of the test item “auth” succeeds, the test item “login” succeeds, and the test item “login” succeeds. 
     After the processing of Step S 10 , the processing moves to Step S 7 , and the same processing as that of the first embodiment is performed. 
     As explained above, the second embodiment is adoptable to a test in which another Web API is necessarily used in order to execute the target Web API. For example, as in the case of testing a Web API requiring authentication and authorization, testing plurality of target paths is needed according to the manner of authorization. For such a case, the second embodiment allows for sequentially running a test on each path and thus is effective in reducing the workload on the developer creating the test. This method therefore can considerably reduce the time conventionally required for test code development. 
     Example hardware configuration of the generation device  10  of the first and the second embodiments will now be described. 
     Example Hardware Configuration 
       FIG.  7    is a diagram that illustrates an example hardware configuration of the generation device  10  according to the first and the second embodiments. The generation device  10  in the first and the second embodiments includes a control device  201 , a main memory  202 , an auxiliary memory  203 , a display device  204 , an input device  205 , and a communication device  206 . The control device  201 , the main memory  202 , the auxiliary memory  203 , the display device  204 , the input device  205 , and the communication device  206  are connected via a bus  210 . 
     Some of the above units of the generation device  10  according to the first and the second embodiments may be omitted. For example, if the generation device  10  is capable of using input and display functions of an external device, the generation device  10  may include neither display device  204  nor input device  205 . 
     The control device  201  executes a computer program loaded in the main memory  202  from the auxiliary memory  203 . The main memory  202  is a memory such as a ROM and a RAM. The auxiliary memory  203  is a hard disk drive (HDD), a memory card, or similar devices. 
     The display device  204  is, for example, a liquid crystal display. The input device  205  is an interface for operating an access point  20 . The display device  204  and the input device  205  may be implemented as a touch screen or the like having display and input functions. The communication device  206  is an interface for communicating with other devices. 
     A computer program to be executed by the generation device  10  is provided as a computer program product by being recorded on a computer-readable storage medium, such as a CD-ROM, a memory card, a CD-R, and a DVD, in an installable or executable file. 
     The computer program to be executed by the generation device  10  may be stored in a computer connected to a network, such as the Internet, and provided by being downloaded via the network. The computer program to be executed by the generation device  10  may be provided via a network such as the Internet without being downloaded. 
     The computer program of the generation device  10  may be embedded in a ROM or the like and provided. 
     The computer program to be executed by the generation device  10  is configured as a module including some functions implementable by a computer program in the functional configuration of  FIG.  2    described earlier. As actual hardware, the control device  201  reads the computer program from a storage medium and executes the computer program to load each functional block onto the main memory  202 . In other words, each of the above functional blocks is generated on the main memory  202 . 
     Some of or all of the functions in  FIG.  2    may be implemented by hardware such as IC, instead of software. 
     When the functions are implemented by plurality of processors, each processor may implement one of the functions or two or more functions. 
     While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel embodiments described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the embodiments described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the inventions.