Method and system for automating API test

Abstract

A method for automating an application programming interface (API) test and a system therefor are disclosed. The method for automating an API test, according to one embodiment of the present disclosure, may comprise the steps of: receiving, from an API management platform service server, API specification information of a first API among a plurality of APIs managed by an API management system; converting the specification information into a specification sample having a data format of a (key, value) pair; and automatically generating a test case of the first API by reflecting the specification sample in a data-driven template.

Description

API Test Automation Method and System

[0001] The present disclosure relates to a method and system for automating API testing. More specifically, the present disclosure relates to a method and system for automatically generating API test cases based on API specification information, including request types, headers, parameters, and bodies.

[0002] Services are provided based on a microservice architecture. These microservices consist of multiple independent Application Programming Interfaces (APIs), each providing its own functionality. Because each API in a microservice operates independently, the number of APIs can increase. Consequently, as the number of deployed APIs increases, management burdens related to functional integrity can arise.

[0003] API management platforms are provided, providing functionality for implementing, deploying, and checking the status of multiple APIs. However, while these API management platforms can manage the implementation, source code, and deployment of individual APIs, they do not provide automated testing capabilities for each API. Consequently, quality assurance (QA) tasks for microservices rely on manual API test case creation.

[0004] Meanwhile, U.S. Patent No. 1,139,7630 discloses a configuration for improving the availability of API endpoints in a container orchestration platform. The service request handler module of the microservice API fault manager (MAFM) invokes the microservice API fault management service in response to the detection of an unresponsive microservice managed by the container orchestration platform. The API inspection module of the MAFM identifies the unresponsive API of the unresponsive microservice. The corrective action module of the MAFM determines a corrective action to correct the unresponsive state of the unresponsive API. The container platform interface module of the MAFM transmits the corrective action to the container orchestration platform. U.S. Patent No. 1,139,7630 proposes a configuration for detecting the unresponsiveness of a microservice to manage the availability of the APIs that constitute the microservice. However, from the perspective of test automation, U.S. Patent No. 1,139,7630 also fails to provide automated API testing based on API specification information.

[0005] A technical problem to be solved in some embodiments of the present disclosure is to provide a method for generating automated test cases based on API specification information and a system to which the method is applied.

[0006] Another technical challenge to be addressed in some embodiments of the present disclosure is to provide a development framework that includes methods for writing automated test cases based on API specification information.

[0007] Another technical problem to be solved in some embodiments of the present disclosure is to provide a method for writing automated test cases that is easy for non-experts to customize, and a system to which the method is applied.

[0008] Another technical problem to be solved in some embodiments of the present disclosure is to provide a method for generating an automated test case based on test automation API specification information for an API that automatically requests a test case including the pre-execution of a preceding request when the pre-execution of the preceding request is required, and a system to which the method is applied.

[0009] Another technical challenge to be addressed in some embodiments of the present disclosure is to provide an API management platform that provides an automated test case writing function for each of one or more APIs.

[0010] Another technical challenge to be addressed in some embodiments of the present disclosure is to provide an API management platform that provides a function for writing automated integrated test cases for multiple APIs.

[0011] Another technical challenge to be solved in some embodiments of the present disclosure is to provide a library that enables an API management platform to provide an automatic test case creation function for an API.

[0012] The technical problems of the present disclosure are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art of the present disclosure from the description below.

[0013] An API test automation method according to one embodiment of the present disclosure for solving the above technical problem may include a step of receiving API specification information of a first API among a plurality of APIs managed by the API (Application Programming Interface) management system from an API management platform service server, a step of converting the API specification information into an API specification sample having a (key, value) pair data format, and a step of automatically generating a test case of the first API by reflecting the API specification sample in a data-driven template.

[0014] At this time, the plurality of APIs are RESTful APIs that constitute an MSA (Micro Service Architecture) based on IPC (Inter-Process Communication), and the API specification information may include IDL (Interface Defined Language) information of a request type, a request parameter, and a request body of the first API. The API specification information of the first API may be information including (field name, data type) information as IDL schema information of the first API. At this time, the API specification sample may have a JSON format. In addition, the converting step may include a step of replacing a data type of the IDL schema information of the first API with a randomly generated value, or a step of replacing a data type of the IDL schema information of the first API with a preset virtual data sample. The above replacing step may include a step of replacing the data type of the IDL schema information of the first API with a randomly generated value at the time of performing the converting step.

[0015] The above data-driven template may be standardized using placeholders for the request host name, request path, header, parameters, and body included in the data-driven template.

[0016] The step of automatically generating a test case of the first API may include, when the request type of the first API is 'GET', a step of parsing a request path, a header, and a parameter of the API specification sample, and a step of automatically generating a test case of the first API by substituting the parsed request path, header, and parameter with a placeholder of each of the request path, header, and parameter of the data-driven template.

[0017] The step of automatically generating a test case of the first API may include, when the request type of the first API is 'POST', a step of parsing a request path, a header, and a body of the API specification sample, and a step of automatically generating a test case of the first API by substituting the parsed request path, header, and body with placeholders of the request path, header, and body of the data-driven template, respectively.

[0018] The step of automatically generating a test case of the first API may include, when the request type of the first API is 'DELETE', a step of parsing a request path, a header, and a parameter of the API specification sample, and a step of automatically generating a test case of the first API by substituting the parsed request path, header, and parameter with a placeholder of each of the request path, header, and parameter of the data-driven template.

[0019] The above data-driven template and the test case of the first API may be data written in YAML (YAML Ain't Markup Language).

[0020] The above API test automation method may further include a step of reading a test case YAML file including a YAML file describing a test case of the first API, a step of parsing the test case YAML file, a step of transmitting a request according to the parsing result, and a step of reporting an execution result for the transmitted request. In this case, the reading step, the parsing step, the transmitting step, and the reporting step may be characterized in that they are performed in response to an automatic test trigger generated after the automatically generating step.

[0021] The above API test automation method may further include a step of reading a plurality of test case YAML files including a YAML file describing test cases of the first API, a step of parsing the test case YAML files, a step of transmitting a request based on the parsing result, and a step of reporting an execution result for the transmitted request.

[0022] The step of transmitting a request according to the parsing result may include a step of determining whether a request of the target YAML file of the parsing requires prior execution of a preceding request, and a step of transmitting the preceding request before the request of the target YAML file if it is determined that the request of the target YAML file requires prior execution of the preceding request.

[0023] The step of determining whether the request of the target YAML file of the above parsing requires prior execution of a preceding request may include a step of determining whether the request of the target YAML file requires prior execution of a preceding request by using the result of dependency analysis on data included in a parameter of the request of the target YAML file, or a step of determining that the request of the target YAML file requires prior execution of a preceding request when the target YAML file includes information on the prior request of the request of the target YAML file.

[0024] According to another embodiment of the present disclosure for solving the above technical problem, an API test automation method may be performed by an API management platform service server that manages a plurality of APIs, and the API test automation method may include a step of providing a display screen for specification information of a first API among the plurality of APIs to a user terminal, wherein the display screen includes an automatic test execution button for the first API; a step of generating an automatic test report for the first API in response to a selection input of the automatic test execution button for the first API being received from the user terminal; and a step of transmitting the automatic test report to the user terminal. In this case, the step of generating the automatic test report for the first API may include a step of acquiring API specification information of the first API, a step of converting the API specification information into an API specification sample having a (key, value) pair data format, and a step of automatically generating a test case for the first API by reflecting the API specification sample in a data-driven template.

[0025] The step of providing a display screen for specification information of the first API to the user terminal may further include a step of providing a display screen for specification information of a second API among the plurality of APIs to the user terminal, and the step of generating an automatic test report for the first API may include a step of generating an automatic test report for the first API and the second API in response to receiving a selection input of an automatic test execution button for the first API and a selection input of an automatic test execution button for the second API from the user terminal. In this case, the step of generating an automatic test report for the first API and the second API may include a step of determining an API to be executed first among the first API and the second API by using a result of a dependency analysis for data included in a parameter included in an automatically generated test case of the first API.

[0026] The step of providing a display screen for specification information of the first API to the user terminal may further include a step of providing a display screen for specification information of a second API among the plurality of APIs to the user terminal, and the step of generating an automatic test report for the first API may include a step of generating an automatic test report for the first API and the second API in response to receiving a selection input of an automatic test execution button for the first API and a selection input of an automatic test execution button for the second API from the user terminal. In addition, the step of generating an automatic test report for the first API and the second API may include a step of obtaining a call graph including the first API and the second API, and a step of determining an API to be executed first among the first API and the second API using the call graph.

[0027] According to another embodiment of the present disclosure for solving the above technical problem, an API test automation system may include one or more processors and a memory for loading an API test automation program executed by the one or more processors. At this time, the API test automation program may include an instruction for receiving API specification information of a first API among a plurality of APIs managed by the API (Application Programming Interface) management system from an API management platform service server; an instruction for converting the API specification information into an API specification sample having a data format of a (key, value) pair; and an instruction for automatically generating a test case of the first API by reflecting the API specification sample in a data-driven template.

[0028] FIG. 1 is a configuration diagram of an API test automation system according to one embodiment of the present disclosure.

[0029] FIG. 2 is a diagram illustrating an execution flow of API test automation according to some embodiments of the present disclosure.

[0030] FIG. 3 is a flowchart of an API test automation method according to other embodiments of the present disclosure.

[0031] FIG. 4 is a diagram illustrating an exemplary display screen for specification information of an API that may be displayed on a user terminal according to some embodiments of the present disclosure.

[0032] FIG. 5 is a diagram illustrating an exemplary API query screen that may be displayed on a user terminal according to some embodiments of the present disclosure.

[0033] FIG. 6 is a diagram illustrating a process in which API specification information of an exemplary API is converted into an API specification sample in some embodiments of the present disclosure.

[0034] FIG. 7 is a diagram illustrating an exemplary data-driven template referenced in some embodiments of the present disclosure.

[0035] FIG. 8 is a diagram illustrating an exemplary test case generation result according to some embodiments of the present disclosure.

[0036] FIG. 9 is a hardware configuration diagram of a computing system described in some embodiments of the present disclosure.

[0037] Hereinafter, preferred embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. The advantages and features of the present invention, and methods for achieving them, will become clear with reference to the embodiments described in detail below together with the accompanying drawings. However, the technical idea of ​​the present invention is not limited to the following embodiments, but can be implemented in various different forms. The following embodiments are provided only to complete the technical idea of ​​the present invention and to fully inform those skilled in the art of the scope of the present invention, and the technical idea of ​​the present invention is defined only by the scope of the claims. In describing the present disclosure, if a detailed description of a related well-known structure or function is determined to obscure the gist of the present invention, the detailed description thereof will be omitted. Hereinafter, several embodiments of the present disclosure will be described with reference to the drawings.

[0038] Hereinafter, the configuration and operation of an API test automation system according to one embodiment of the present disclosure will be described with reference to FIG. 1. FIG. 1 is a configuration diagram of an API test automation system according to the present embodiment.

[0039] The API management platform service server (10) is a server that provides an API management platform that provides at least one service among registration, implementation, deployment, resource allocation policy establishment, and cloud-based microservice management tools for one or more APIs. The API management platform, also referred to as an API management tool, can, of course, provide various additional functions for managing APIs in addition to the exemplary functions described above.

[0040] The API test automation system (100) may be a system that provides a development framework including a plurality of methods for performing automated generation of API test cases. For example, the API test automation system (100) may be a system that executes a method called from a method other than the plurality of methods provided in the development framework among the plurality of methods included in the development framework, or a method called from a method outside the development framework, and returns the result thereof.

[0041] In some embodiments, the API management platform service server (10) may be a computing system operated by a first organization, and the API test automation system (100) may be a computing system operated by a second organization. In this case, the development framework may be a framework for developing a microservice-based online service that runs in a cloud environment provided by the second organization. In this case, the API management platform service server (10) may be a server that provides a management tool for a RESTful API that constitutes an IPC (Inter-Process Communication)-based MSA (Micro Service Architecture).

[0042] The above first institution and the above second institution may be different companies.

[0043] That is, the second institution provides an online service implemented based on a microservice architecture to a customer terminal, and the RESTful API constituting the microservice can be managed using an API management platform service server (10). At this time, the development framework for developing the RESTful API may include a plurality of methods for automatically generating test cases of the developed RESTful API, and the plurality of methods may be executed by an API test automation system (100). On the user terminal (20), a screen of an Integrated Development Environment (IDE) including the source code of each method included in the development framework or a graphic object indicating each method may be displayed.

[0044] In some embodiments, both the API management platform service server (10) and the API test automation system (100) may be computing systems operated by the second organization. In this case, the API management platform service server (10) and the API test automation system (100) may be configured with one or more cloud compute instances. That is, each of the API management platform service server (10) and the API test automation system (100) may be configured with at least some compute instances of one or more virtual machines and one or more containers.

[0045] When a first method among a plurality of methods for automatically generating the test case is called, the API test automation system (100) can receive API specification information of a first API among a plurality of APIs managed by the API (Application Programming Interface) management system from the API management platform service server. In other words, it can be understood that the first method is a method for obtaining API specification information of an API specified as a parameter of the first method.

[0046] As described above, the plurality of APIs are RESTful APIs that constitute an IPC-based MSA (Micro Service Architecture), and the API specification information may include IDL (Interface Defined Language) information of a request type, a request parameter, and a request body of the first API. That is, since the plurality of APIs are IPC-based APIs, the specification information for such IPC-based APIs may be stored in the API management platform service server (10) in the form of an IDL, and the API test automation system (100) may receive the API specification information from the API management platform service server (10).

[0047] In some embodiments, the API specification information may be composed of IDL schema information. The IDL schema information may include information expressed in the form of a pair of (field name, data type).

[0048] The API test automation system (100) can convert the API specification information into an API specification sample having a data format of (key, value) pairs when the second method among the plurality of methods for automatically generating the test case is called.

[0049] As described above, since the API specification information may include information expressed in the form of a pair of (field name, data type), the second method may include a statement that replaces the data type of the IDL schema information of the first API with a randomly generated value or a preset virtual data sample.

[0050] It should be understood that the above-mentioned pre-set virtual data sample is virtual data unrelated to the actual business data of the online service provided by the second organization. In other words, it should be understood that the API specification sample is generated in a manner that prevents the leakage of sensitive actual business data during the process of automatically generating automated test cases for the first API.

[0051] The API test automation system (100) can automatically generate a test case of the first API by reflecting the API specification sample in a data-driven template when a third method among a plurality of methods for automatically generating the test case is called. The data-driven template may be a request host name, request path, header, parameter, and body included in the data-driven template that are standardized using placeholders. The data-driven template will be described in more detail through the following embodiments.

[0052] Above, the configuration and operation of the API test automation system according to the present embodiment have been described with reference to FIG. 1. The operation method of the API test automation system described above will be understood in more detail with reference to other embodiments described below. Furthermore, the technical concepts understood through the embodiments of the API test automation system described above may be reflected in other embodiments described below, even if not specifically stated otherwise.

[0053] An API test automation method according to another embodiment of the present disclosure will be described with reference to FIGS. 2 to 8. The API test automation method according to the present embodiment may be performed by one or more computing systems. Furthermore, the API test automation method according to the present embodiment may have some operations performed by a first computing device included in the computing system, and the remaining operations performed by a second computing device included in the computing system. For example, some operations of the API test automation method according to the present embodiment may be performed by an on-premise physical server, and the remaining operations may be performed by a cloud compute instance. Hereinafter, if the performer of each operation is omitted, it will be understood that the performer is the computing system.

[0054] Before explaining the API test automation method according to this embodiment through the flowchart of Fig. 3, the method according to this embodiment will be explained with reference to Fig. 2. Fig. 2 is a diagram illustrating the execution flow of API test automation.

[0055] A computing system can provide a service (101) for generating automated test cases. The service (101) is a service that provides an application that provides a screen displayed on a user terminal (20), and may be a service that provides a management screen for an API management platform or a service that provides a unique application for API test automation.

[0056] The service (101) can call a module (102) that parses API specification information provided from the API management platform service server (10). The module (102) can call a module (103) that converts the IDL schema constituting the API specification information into a JSON (JavaScript Object Notation) format having a (key, value) pair data format. In addition, the module (103) can call a module (105) that generates a test case of the API by reflecting an API specification sample in JSON format in a data-driven template (DDT) (104).

[0057] The above-described modules (102, 103, 105) and data-driven template (DDT) (104) may be provided by a framework (106) including a plurality of methods that provide an automatic generation function of API test cases as the above-described framework. That is, the modules (102, 103, 105) may be understood to correspond to each of the plurality of methods. The plurality of methods that provide an automatic generation function of API test cases or their corresponding modules (102, 103, 105) are responsible for the test case generation stage.

[0058] In some embodiments, the framework (106) may generate test automation related triggers (107). The framework (106) may generate triggers (107) periodically, in response to a pre-specified requirement being satisfied, or in response to a user entering a command indicating test execution through a screen of the service (101).

[0059] When a trigger (107) is generated, a case reader module (108) may be called. The case reader module (108) may open and parse one or more test cases generated by a module (105) that generates test cases for the API. The case reader module (108) may call a case runner module (109). The case runner module (109) may call a test target request based on the parsing result of the test case and assert the execution result of the test target request.

[0060] In some embodiments, the case executor module may perform dependency analysis on the test target request. The dependency analysis may include an operation of discovering a request that should be executed before the test target request among the requests of an API managed by the API management platform service server (10), based on a core parameter among the parameters of the test target request. For example, a request that generates the core parameter may be determined to be a preceding request of the test target request.

[0061] Alternatively, in some embodiments, the case reader module (108) may determine a preceding request described in the test case as a result of parsing the test case. For example, if a Quality Assurance (QA) agent manually entered information about a preceding request into the test case, the case reader module (108) may automatically identify the preceding request. As will be described later, considering the possibility of adjusting the automatically generated test case by a human, the module (105) that generates the test case of the API may generate the test case in a markup language that is easy for a non-expert to read and write. The markup language may be YAML (YAML Ain't Markup Language).

[0062] Next, the report generation module (110) may be called. The report generation module (110) may generate report data indicating the call and execution results of the test target request, and transmit the generated report data to the user terminal (20).

[0063] The above-described modules (108, 109, 110) may be provided by the framework (106) including a plurality of methods that provide an automatic generation function of API test cases as the above-described framework. That is, the modules (108, 109, 110) may be understood as corresponding to each of the above-described plurality of methods. The plurality of methods that provide an execution function of API test cases or their corresponding modules (108, 109, 110) are responsible for the test case execution stage.

[0064] Next, the explanation will be given with reference to Fig. 3.

[0065] In step S100, API specification information is acquired. The API specification information is information received from the API management platform service server through an API called using an SDK provided by the API management platform service server, and may include IDL schema information of the request type, request parameters, and request body of the first API. The IDL schema information may include information in the form of (field name, data type). The exemplary IDL schema information of the first API is shown in the API specification information display screen (11) illustrated in FIG. 4. The API specification information display screen (11) may be provided by the API management platform service server to a user terminal.

[0066] In some embodiments, the API specification information display screen (11) may include an automatic test execution button (11a) for the first API. That is, in response to the button (11a) being selected by the user terminal, the operation described with reference to FIG. 3 may be performed. That is, an automatic test for the first API may be performed through coding that directly calls a method provided by the development framework, but the automatic test may also be performed in a codeless manner through an operation of selecting the button (11a).

[0067] In some other embodiments, as illustrated in FIG. 5, an API search screen (12) for searching for an API that satisfies a specific requirement among a plurality of APIs including the first API may be displayed on the user terminal. The API search screen (12) may be provided by the API management platform service server to the user terminal.

[0068] As illustrated in FIG. 5, the API search screen (12) may include a search box (12a), an automatic test execution button (12b), a search result list (12c), and a test target API check box (12d). For example, if an API provider is entered into the search box (12a), the APIs of the entered provider will be listed in the search result list (12c). Some of the multiple APIs listed in the search result list (12c) may be selected through the test target API check box (12d). If the automatic test execution button (12b) is selected, a test case is automatically generated for each selected API in order to test the selected APIs in batches, and a test scenario that sequentially executes the automatically generated test cases may also be automatically generated.

[0069] In some embodiments, when the auto test execution button (12b) is selected and multiple APIs are selected through the test target API check box (12d), the test order can be determined for the selected APIs.

[0070] For example, if API 1 and API 2 are selected, and the request of API 1 is a request that precedes the request of API 2, the test case of API 1 may be executed first and the test case of API 2 may be executed later.

[0071] The above test order can be determined using the results of dependency analysis on data included in parameters in automatically generated test cases of the first API and the results of dependency analysis on data included in parameters in automatically generated test cases of the second API. Since the dependency analysis can be performed using a widely known API dependency analysis tool, a detailed description thereof is omitted in this disclosure.

[0072] The above test order may be determined using the analysis results of the call graph including the first API and the second API. At this time, when the automatic test execution button (12b) is selected, a dialog for importing the call graph may be additionally displayed on the screen of the user terminal. The call graph is data representing the call relationship between each API. For example, according to the call graph, if a call to the second API is made after a call to the first API, the test order would be the first API, then the second API.

[0073] If the request parameters or request body of the first API have a nested structure, the schema information of the first API will have a complex structure. This complex schema information of the first API can be converted into API sample information in the form of a (key, value) pair in step S200.

[0074] In Fig. 6, an example is shown in which the schema information (102a) of the first API including information in the form of (field name, data type) is converted into API sample information (103a) in JSON format having a pair format of (key, value).

[0075] The IDL schema (102a) includes a statement (102a-1) that defines that the type of 'remainingCoupangCash' is a number. However, in order to generate a test case, a value in the form of a number needs to correspond to 'remainingCoupangCash'. Therefore, the API sample information (103a) in JSON format includes a statement (103a-1) that describes a randomly generated value of '2000' as the value of 'remainingCoupangCash'.

[0076] The IDL schema (102a) includes a syntax (102a-2) that defines that the type of 'storeId' is a 64-bit integer (int64). However, in order to generate a test case, a value in the form of a 64-bit integer must correspond to 'storeId'. Therefore, the API sample information (103a) in JSON format includes a syntax (103a-2) that describes a randomly generated integer, '123456', as the value of 'storeId'.

[0077] The IDL schema (102a) includes a statement (102a-3) that defines that the type of 'quantity' is a 32-bit integer (int32). However, in order to generate test cases, a value in the form of a 32-bit integer must correspond to 'quantity'. Therefore, the API sample information (103a) in JSON format includes a statement (103a-3) that describes a randomly generated integer '2' as the value of 'quantity'.

[0078] The IDL schema (102a) includes a statement (102a-4) that defines that the type of 'salesPrice' is a number. However, in order to generate a test case, a numeric value must be associated with 'salesPrice'. Therefore, the API sample information (103a) in JSON format includes a statement (103a-4) that describes a randomly generated integer '18000' as the value of 'salesPrice'.

[0079] Although not shown in the example of FIG. 6, the IDL schema (102a) may also define data having a string type. While such string type data may also be randomly generated, similar to the example described above, randomly generated strings may cause unintended errors. Therefore, in some embodiments, data having a specific type defined in the IDL schema (102a) may have a value of a preset virtual data sample when converted to API sample information (103a) in JSON format.

[0080] In short, in the conversion process of step S200, (field name, data type) defined through IDL schema information can be converted into (field name, value) in API sample information in JSON format, and the value can be randomly generated or a preset virtual data sample.

[0081] Let's go back to Figure 3 and explain again.

[0082] In step S300, a test case of the first API is automatically generated by reflecting the API specification sample in the data-driven template.

[0083] Fig. 7 illustrates an exemplary data-driven template. The data-driven template may be understood as standardized data using placeholders (104-1 to 104-8) for a request host name, a request path, a header, parameters, and a body. That is, in step S300, by determining a value corresponding to each placeholder of the data-driven template using each (field name, value) included in the API specification sample, a test case for the target API for test case generation can be automatically generated.

[0084] For example, the $data placeholder (104-7) of FIG. 7 is standardized parameter data, and in the test case generation step of step S300, the $data placeholder (104-7) will be replaced with syntax corresponding to the parameters of the API specification sample (103a) illustrated in FIG. 6. FIG. 8 illustrates an exemplary test case (105a) that may be generated as a result of executing step S300. As described above, both the data-driven template and the test case (105a) can be generated in YARN format.

[0085] Meanwhile, in the test case generation step of step S300, the replacement placeholder of the data-driven template may vary depending on the type of the target API.

[0086] For example, if the request type of the first API is 'GET', the request path, header, and parameters of the API specification sample are parsed, and the test case of the first API can be generated by substituting the parsed request path, header, and parameters with the placeholders of the request path, header, and parameters of the data-driven template, respectively.

[0087] For example, if the request type of the first API is 'POST', a test case of the first API can be automatically generated by parsing the request path, header, and body of the API specification sample and substituting the parsed request path, header, and body with the placeholders of the request path, header, and body of the data-driven template, respectively.

[0088] For example, if the request type of the first API is 'DELETE', a test case of the first API can be automatically generated by parsing the request path, header, and parameters of the API specification sample, and substituting the parsed request path, header, and parameters with the placeholders of the request path, header, and parameters of the data-driven template, respectively.

[0089] Next, at step S400, a test scenario for performing tests on one or more APIs can be automatically generated based on a test case template. The test case template is also written in YAML format and can be understood as a set of statements for sequentially executing test scenarios for one or more APIs. The test scenario can be opened by the execution stage modules of the framework when a trigger occurs later (S500).

[0090] When a trigger for performing an automated test occurs (S500), a YAML file describing the test cases of the API under test is read and parsed. At this time, a single test case YAML file or multiple test case YAML files may be read. For example, if the test scenario is opened and includes open statements for multiple test case YAML files, multiple test case YAML files will be read.

[0091] In some embodiments, from the parsing result of the test case YAML file, it can be determined whether there is a preceding request for the request of the API under test (S600).

[0092] Using the results of dependency analysis on data included in the parameters of a request of an API under test, it can be determined whether the request of the API under test requires the prior execution of a preceding request. For example, if the results of the dependency analysis determine that at least some of the data included in the parameters of the request of the API under test has a dependency on other data, it can be determined that the request of the API under test requires the prior execution of a preceding request.

[0093] Additionally, as a result of parsing the test case YAML file, if the test case YAML file includes information about a preceding request of the request of the API under test, it may be determined that the request of the API under test requires the prior execution of the preceding request.

[0094] If it is determined that a request of the API to be tested requires the prior execution of a preceding request, a test scenario for the preceding request can be automatically generated based on the test case template described above in step S700.

[0095] Next, at step S800, a test case for a request of the API under test may be executed, or a test scenario for the request of the API under test and its preceding request may be executed. At this time, assertions regarding the request invocation and its execution results may be recorded, and a test report including the recorded results may be automatically generated (S900).

[0096] Next, with reference to FIGS. 4 and 5, an API testing automation method according to another embodiment of the present disclosure will be described. This embodiment can be executed by an API management platform service server (hereinafter referred to as a "service server") that manages multiple APIs.

[0097] First, the service server may provide a display screen for specification information of a first API among the plurality of APIs to the user terminal. The display screen may include a button for performing an automatic test for the first API.

[0098] The service server generates an automatic test report for the first API in response to receiving a selection input for an automatic test execution button for the first API from the user terminal.

[0099] At this time, the service server obtains API specification information of the first API, converts the API specification information into an API specification sample having a (key, value) pair data format, and reflects the API specification sample in a data-driven template, thereby automatically generating a test case of the first API.

[0100] In generating the above automatic test report, the service server may perform an operation of generating an automatic test report for the first API and the second API in response to receiving a selection input of an automatic test execution button for the first API and a selection input of an automatic test execution button for the second API from the user terminal.

[0101] At this time, the service server can use the results of dependency analysis on the data included in the parameters included in the automatically generated test case of the first API to determine which API should be executed first between the first API and the second API. In addition, the service server can obtain a call graph including the first API and the second API, and use the call graph to determine which API should be executed first between the first API and the second API.

[0102] Next, the service server sends the automatic test report to the user terminal.

[0103] According to this embodiment, in providing an API management tool, it is possible to provide an automated testing function for the managed API.

[0104] The methods according to the embodiments of the present invention described so far can be performed by executing a computer program implemented as computer-readable code. The computer program can be transmitted from a first computing device to a second computing device via a network such as the Internet, installed on the second computing device, and thus used on the second computing device. Furthermore, although operations are depicted in a specific order in the drawings, it should not be understood that the operations must be performed in the specific order depicted or in a sequential order, or that all depicted operations must be performed to achieve the desired results. In certain situations, multitasking and parallel processing may be advantageous.

[0105] FIG. 9 is a hardware configuration diagram of a computing system according to some embodiments of the present disclosure. The computing system (1000) of FIG. 9 may include one or more processors (1100), a system bus (1600), a communication interface (1200), a memory (1400) for loading a computer program (1500) executed by the processor (1100), and a storage (1300) for storing the computer program (1500).

[0106] The computing system (1000) of FIG. 9 may present a hardware structure of one or more computing systems constituting the API test automation system (100) described with reference to FIG. 1, for example.

[0107] The processor (1100) controls the overall operation of each component of the computing system (1000). The processor (1100) can perform operations for at least one application or program for executing methods / operations according to various embodiments of the present disclosure. The memory (1400) stores various data, commands, and / or information. The memory (1400) can load one or more computer programs (1500) from the storage (1300) to execute methods / operations according to various embodiments of the present disclosure. The storage (1300) can non-temporarily store one or more computer programs (1500).

[0108] The computer program (1500) may include one or more instructions implementing methods / operations according to various embodiments of the present disclosure. When the computer program (1500) is loaded into the memory (1400), the processor (1100) may execute the one or more instructions to perform the methods / operations according to various embodiments of the present disclosure.

[0109] The computer program (1500) may include an instruction for receiving API specification information of a first API among a plurality of APIs managed by the API (Application Programming Interface) management system from an API management platform service server, an instruction for converting the API specification information into an API specification sample having a data format of a (key, value) pair, and an instruction for automatically generating a test case of the first API by reflecting the API specification sample in a data-driven template.

[0110] Although the embodiments of the present disclosure have been described with reference to the attached drawings, those skilled in the art will appreciate that the present disclosure can be implemented in other specific forms without changing the technical concepts or essential features thereof. Therefore, it should be understood that the embodiments described above are exemplary in all respects and not restrictive. The scope of protection of the present invention should be interpreted by the following claims, and all technical ideas within a scope equivalent thereto should be interpreted as being included within the scope of the technical ideas defined by the present disclosure.

Claims

1. In a method performed by a computing system, A step of receiving API specification information of a first API among a plurality of APIs managed by the API (Application Programming Interface) management system from an API management platform service server; A step of converting the above API specification information into an API specification sample having a data format of (key, value) pairs; and A step of automatically generating a test case of the first API by reflecting the API specification sample in a data-driven template, How to automate API testing.

2. In paragraph 1, The above multiple APIs are: It is a RESTful API that constitutes an MSA (Micro Service Architecture) based on IPC (Inter-Process Communication). The above API specification information is: Including the IDL (Interface Defined Language) information of the request type, request parameter, and request body of the first API, How to automate API testing.

3. In paragraph 2, The API specification information of the above first API is: As the IDL schema information of the above first API, information including (field name, data type) information, How to automate API testing.

4. In paragraph 3, The above API spec sample is in JSON format, The above converting steps are: A step of replacing the data type of the IDL schema information of the first API with a randomly generated value, How to automate API testing.

5. In paragraph 4, The above replacement steps are: A step of replacing the data type of the IDL schema information of the first API with a randomly generated value at the time of performing the converting step, How to automate API testing.

6. In paragraph 3, The above API spec sample is in JSON format, The above converting steps are: A step of replacing the data type of the IDL schema information of the first API with a preset virtual data sample, How to automate API testing.

7. In paragraph 1, The above data-driven template is, The request host name, request path, header, parameters and body included in the above data-driven template are standardized using placeholders. How to automate API testing.

8. In paragraph 7, The step of automatically generating a test case for the above first API is: When the request type of the first API is 'GET', a step of parsing the request path, header, and parameters of the API specification sample; and A step of automatically generating a test case of the first API by substituting the parsed request path, header and parameters with placeholders of the request path, header and parameters of the data-driven template, How to automate API testing.

9. In paragraph 7, The step of automatically generating a test case for the above first API is: When the request type of the first API is 'POST', a step of parsing the request path, header, and body of the API specification sample; and A step of automatically generating a test case of the first API by substituting the parsed request path, header and body with placeholders of the request path, header and body of the data-driven template, How to automate API testing.

10. In paragraph 7, The step of automatically generating a test case for the above first API is: When the request type of the first API is 'DELETE', a step of parsing the request path, header, and parameters of the API specification sample; and A step of automatically generating a test case of the first API by substituting the parsed request path, header and parameters with placeholders of the request path, header and parameters of the data-driven template, How to automate API testing.

11. In paragraph 1, The above data driven template and the test case of the first API are, Data written in YAML (YAML Ain't Markup Language), How to automate API testing.

12. In paragraph 11, A step of reading one test case YAML file including a YAML file describing a test case of the first API; Step of parsing the above test case YAML file; A step of transmitting a request according to the above parsing result; and Further comprising a step of reporting the execution result for the above transmitted request, How to automate API testing.

13. In paragraph 12, The above-mentioned leading step, the above-mentioned parsing step, the above-mentioned transmitting step and the above-mentioned reporting step are characterized in that they are performed in response to an automatic test trigger generated after the above-mentioned automatically generating step. How to automate API testing.

14. In paragraph 11, A step of reading a plurality of test case YAML files including a YAML file describing test cases of the first API; Step of parsing the above test case YAML file; A step of transmitting a request according to the above parsing result; and Further comprising a step of reporting the execution result for the above transmitted request, How to automate API testing.

15. In paragraph 11, The step of sending a request based on the above parsing result is: A step of determining whether a request in the YAML file to be parsed requires the prior execution of a preceding request; and If it is determined that a request of the target YAML file requires the prior execution of a preceding request, a step of transmitting the preceding request before the request of the target YAML file is included. How to automate API testing.

16. In paragraph 15, The step of determining whether the request of the YAML file to be parsed above requires the prior execution of the preceding request is: A step of determining whether a request of a target YAML file requires the prior execution of a preceding request by using the result of dependency analysis on data included in the parameters of a request of the target YAML file, How to automate API testing.

17. In paragraph 15, The step of determining whether the request of the YAML file to be parsed above requires the prior execution of the preceding request is: A step of determining that a request of the target YAML file requires prior execution of a preceding request, if the target YAML file includes information about a preceding request of the request of the target YAML file, How to automate API testing.

18. In a method performed by an API management platform service server that manages multiple APIs, A step of providing a display screen for specification information of a first API among the plurality of APIs to a user terminal, wherein the display screen includes an automatic test execution button for the first API; In response to receiving a selection input of an automatic test execution button for the first API from the user terminal, a step of generating an automatic test report for the first API; and Including a step of transmitting the above automatic test report to the user terminal, The step of generating an automatic test report for the above first API is: A step of obtaining API specification information of the first API; A step of converting the above API specification information into an API specification sample having a data format of (key, value) pairs; and A step of automatically generating a test case of the first API by reflecting the API specification sample in a data-driven template, How to automate API testing.

19. In paragraph 18, The step of providing a display screen for the specification information of the above first API to the user terminal is as follows: Including a step of further providing a display screen for specification information of a second API among the above plurality of APIs to a user terminal, The step of generating an automatic test report for the above first API is: In response to receiving a selection input of an automatic test execution button for the first API and a selection input of an automatic test execution button for the second API from the user terminal, a step of generating an automatic test report for the first API and the second API, The step of generating an automatic test report for the first API and the second API comprises: A step of determining which API should be executed first among the first API and the second API by using the results of dependency analysis on data included in parameters included in the automatically generated test case of the first API, How to automate API testing.

20. In paragraph 18, The step of providing a display screen for the specification information of the above first API to the user terminal is as follows: Including a step of further providing a display screen for specification information of a second API among the above plurality of APIs to a user terminal, The step of generating an automatic test report for the above first API is: In response to receiving a selection input of an automatic test execution button for the first API and a selection input of an automatic test execution button for the second API from the user terminal, a step of generating an automatic test report for the first API and the second API, The step of generating an automatic test report for the first API and the second API comprises: A step of obtaining a call graph including the first API and the second API; and A step of determining which API should be executed first among the first API and the second API by using the call graph, How to automate API testing.

21. In computing systems, one or more processors; and A memory that loads an API test automation program executed by one or more processors, The above API test automation program is, An instruction for receiving API specification information of a first API among a plurality of APIs managed by the API (Application Programming Interface) management system from an API management platform service server; An instruction for converting the above API specification information into an API specification sample having a data format of (key, value) pairs; and An instruction for automatically generating a test case of the first API by reflecting the above API specification sample in a data-driven template, API test automation system.

Images