KR20100070713A - Method and system for automatically testing database system based on scenario - Google Patents

Abstract

PURPOSE: A method and a system for automatically testing a database system based on a scenario is provided to simultaneously test new databases by managing a database test scenario and a verification result through a database. CONSTITUTION: A scenario database server(202) includes a scenario database(200) including database test scenarios and verification results. An automatic database test device(100) is connected to the scenario database server and the test target database to automatically test the test target database. The database test automation device includes a scenario register and a database tester.

Description

Method and system for automatically testing database system based on scenario

The present invention relates to database testing, and more particularly, to a system and method for automating testing whether a database's engine is functioning based on a scenario.

A database is a collection of data that can store and operate integrated information from multiple application systems. As information grows exponentially, the demand for a database that can store such information structurally and efficiently increases, and various databases are being developed. Newly developed databases must meet the standards for the database. In addition, as the standard is newly patched, it is also necessary to test whether the new standard is satisfied.

In the past, these tests were performed manually. The same data was entered into a validated database that had already been developed or had already been patched with a new standard and the subject database to which the newly developed or new standard was to be patched. The same questions were asked and the results were compared. In order to test one database, one validated database was required. If a problem occurred in the verified database, the test could not be performed. If there were many databases, the time and manpower were required in proportion to the number. In addition, the same data and questions used in the test remained the test operator's know-how, making it difficult to share with other test operators, and the test results were difficult to manage collectively.

In the following, the process of entering data and performing a question to test a specific function of a test subject database is referred to as a scenario written in a series of texts.

Accordingly, it is a technical object of the present invention to provide a method and system for automating the testing of a database.

In addition, another technical problem to be achieved by the present invention is to provide a system for efficiently testing a large number of developers who develop a database.

In addition, another technical problem to be achieved by the present invention is to provide a system that can be used to track performance changes, bug tracking, etc. by integrally managing the test results of the database.

In accordance with an aspect of the present invention, there is provided a method for automating database test. In the scenario registration step, a scenario for testing the test subject database and a verification result generated using a database corresponding to the scenario and verified are registered in the remote scenario database. In a database test step, the test subject database is tested using the scenario. Here, the test subject database, the verified database and the test subject database are connected via a network.

According to an example of the database test automation method, the scenario registration step may include a scenario creation step of creating the scenario; A verification result generating step of accessing the verified database, performing the scenario on the verified database, and receiving the result as a verification result; And a scenario and verification result registration step of registering the scenario and the verification result by accessing the remote scenario database. The database testing step may include: a scenario unloading step of accessing the remote scenario database and unloading the scenario and the verification result; A scenario execution step of accessing the test target database, performing the unloaded scenario on the test target database, and receiving the result as a test result; And comparing the test result with the unloaded verification result, and generating a final result by accessing and registering a final result in the remote scenario database. According to another example of the method for automating database test, the scenario registration may be performed. The step and the database test step may be executed in different database test automation devices.

According to another example of the database test automation method, the database test step may be executed independently in a plurality of database test automation devices for a plurality of test subject databases.

According to another example of the method for automating database test, the scenario may include a scenario for testing whether the database under test satisfies the SQL standard.

According to another example of the database test automation method, the scenario registration step may include a scenario creation step of creating the scenario; A verification result generating step of generating a verification result corresponding to the scenario; And a scenario and verification result registration step of registering the scenario and the verification result by accessing the remote scenario database. As the scenario registration step is repeated, a plurality of scenarios and a plurality of verification results corresponding thereto may be registered in the remote scenario database, and the database testing step may be performed by accessing the remote scenario database. A scenario selecting step of selecting a scenario to test the test target database from among the plurality of scenarios registered in the database; A scenario unloading step of unloading the selected scenario and a verification result corresponding thereto and storing them in a local storage device; A scenario execution step of accessing the test target database and performing the unloaded scenario on the test target database and receiving the result as a test result; And a final result generation step of comparing the test result with the unloaded verification result and registering the final result by accessing the remote scenario database.

According to another example of the database test automation method, the verification result generating step may include accessing the verified database, performing the scenario on the verified database, and receiving the performed result as the verification result. It may include.

According to another example of the method for automating database test, a plurality of scenarios may be selected from the plurality of scenarios in the scenario selecting step, and thus, the plurality of scenarios may be unloaded in the scenario unloading step, In the scenario performing step, the plurality of scenarios may be continuously performed on the test target database.

According to another example of the database test automation method, as the database test step is repeated, the local storage device stores a number of unloaded scenarios and a corresponding number of unloaded verification results. In this case, between the scenario selecting step and the unloading scenario, the method may further include checking whether the scenario selected in the scenario selecting step is stored in the local storage device and coincides with the scenario stored in the local storage device. Only when the scenario does not exist in the local storage device or does not match a scenario existing in the local storage device, the selected scenario and the verification result corresponding thereto may be unloaded and stored in the local storage device in the scenario unloading step. . In addition, when the scenario selected in the scenario selection step matches the scenario stored in the local storage device, the scenario execution step and the final result generation step are performed using the scenario stored in the local storage device and a verification result corresponding thereto. You can run

Provided is a computer readable medium having recorded thereon a program for executing the database test automation method on a computer according to an aspect of the present invention for achieving the above technical problem.

In accordance with an aspect of the present invention, there is provided a database test automation system. The scenario database server includes a scenario database in which scenarios for testing the database under test and corresponding verification results can be registered. At least one database test automation device for automating a test of the test target database is connected to the scenario database server and the test target database through a network, and a scenario for registering the scenarios and the verification results in the scenario database. register; And a database test unit for testing the test subject database using the scenarios.

According to an example of the database test automation system, the scenario registration unit may include: a scenario creation interface module providing an interface for creating the scenarios; A verification result generation module for generating verification results corresponding to the created scenarios; And a scenario registration module for registering the created scenarios and the verification results by accessing the scenario database. The database test unit may further include: a test scenario selection interface module configured to access the scenario database and provide an interface for selecting a scenario to test the test target database from among the scenarios registered in the scenario database; A scenario unload module for accessing the scenario database to unload the selected scenario and corresponding verification results from the scenario database; A database test module for accessing the test subject database and performing the unloaded scenario on the test subject database and receiving the result as a test result; And a comparison module for comparing the test result with the unloaded verification result to generate a final result.

According to another example of the database test automation system, the at least one database test automation device may further include a verified database connected through the network, wherein the verification result generation module is connected to the verified database. The created at least some scenarios may be performed on the verified database and received results as the at least some verification results.

Details and improvements of the invention are disclosed in the dependent claims.

The database test automation method and system of the present invention provides a method and system capable of automatically performing a test of a test subject database. In addition, by managing a scenario for testing a database to be tested and corresponding verification results as a database, it is possible to efficiently test new databases developed by each of a plurality of test operators simultaneously. In addition, by storing the test results of the database under development in the database, it can be used for tracking performance changes, bug tracking, and the like.

Embodiments of the present invention are provided for the purpose of more fully illustrating the present invention to those skilled in the art, and the following embodiments may be modified in various other forms, the scope of the present invention Should not be construed as limited to the following examples.

Hereinafter, with reference to the accompanying drawings, it will be described in detail an embodiment of the present invention. For ease and clarity of description, the structure or size of each component in the drawings is exaggerated, and the same reference numerals are used for the same components in the drawings, and duplicate descriptions of parts that are not related to the description or the same components are omitted. On the other hand, the terms used are only used for the purpose of illustrating the present invention, not intended to limit the meaning or the scope of the invention described in the claims.

1 is a conceptual diagram schematically illustrating a database test automation system according to various embodiments of the present disclosure.

Referring to FIG. 1, the test automation apparatus 100, the scenario database server 202, the test subject database 300, and the verified database 400 each include a network adapter (not shown), and use the network adapter. Can be connected to the network 10. The network 10 may be at least one of a wired or wireless communication network, for example, a communication network (LAN), a broadband communication network (WAN), a public switched telephone network (PSTN), a packet switching network (PSDN), an asymmetric digital subscriber line (ADSL), a synthesis It may include at least one of a communication network (ISDN), code division multiple access (CDMA) and Ethernet (ETHERNET). In addition, the scenario database server 202, the test subject database 300, and the verified database 400 may not be connected to each other, and may be connected only to the test automation device 100.

The scenario database server 202 may include a scenario database 200, which may be stored in, for example, Oracle, MS-SQL, Informix, where scenarios, validation results and final results may be stored. It can be a general purpose database such as

The test object database 300 may be included in a test object database server (not shown) having a network adapter and connected to the network 10. The test target database 300 is a test database newly developed by a developer and may not provide all of the standardized functions, or may be a database that provides existing standardized functions but has not yet been applied to the new standardization. . The test target database 300 may be directly connected to the test automation device 100.

The verified database 400 may be included in a verified database server (not shown) and connected to the network 10. The verified database 400 may be a general-purpose database such as Oracle, MS-SQL, or Informix that provides all current standardized functions. The verified database 400 may be a database reflecting the new standardization.

The test automation device 100 may include a computer-readable recording medium having a computer recorded thereon a program for executing a data test automation method according to various embodiments of the present invention. Computers that can be driven include, for example, personal computers (PCs), laptops (laptops), PDAs, large computers, workstations, servers, or specialty computers. The test automation device 100 may access the scenario database 200, the test subject database 300, and the verified database 400 to perform functions such as inputting, outputting, deleting, modifying, moving, and editing data. It may include a database interface unit (not shown).

Although the test automation device 100 configured solely in FIG. 1 is shown, a plurality of test automation devices 100 are connected to the network 10 to provide a scenario database 200, a test subject database 300, and a verified database. 400 may be connected, and may perform the same function independently and operate simultaneously. In addition, although the test subject database 300 is shown as being configured alone, a plurality of test subject databases 300 may be connected to the network 10 so that testing may be performed by one or more test automation devices 100. have. Accordingly, a plurality of test automation devices 100 may be connected to the network 10, and a plurality of test target databases 200 may be connected to each of the plurality of test automation devices 100, thereby providing a plurality of tests. Testing against the subject database 200 may be performed simultaneously by multiple test automation devices 100.

Details of the test automation device 100 will be described below with reference to FIG. 2.

FIG. 2 is a block diagram exemplarily illustrating a function of a database test automation device of a database test automation system according to an exemplary embodiment of the present invention.

Referring to FIG. 1 along with FIG. 1, the data test automation device 100 may include a network adapter 160, a database interface unit 130, a local storage device 140, a user interface 150, and a scenario registration unit 110. And a database test unit 120.

The database test automation device 100 is connected to the network 10 through the network adapter 160, and the scenario database 200, the test subject database 300, and the verified database 400 are connected to the network 10 through the network 10. Can be connected. For example, if the network 10 is a LAN-based wired network, the network adapter may be a LAN card.

The database interface unit 130 includes a scenario database 200, a test target database 300, and a variety of modules 111-115 and 121-126 included in the scenario register 110 and the database test unit 120. Access to the verified database 400, it is possible to perform their respective functions. As illustrated in FIG. 2, the database interface unit 130 may be configured as a single integrated interface unit, or may be configured as a plurality of individual interface units that may be connected to the databases 200, 300, and 400, respectively.

The local storage device 140 can be used to store information such as scenarios used in the database test automation device 100. The local storage device 140 may be a hard disk mounted in the database test automation device 100 or may be a nonvolatile storage device such as a floppy disk and a flash memory. The local storage device 140 may store the scenario and the verification results corresponding thereto in the form of a file.

Scenarios represent a set of logical test sets that test operators have written to test specific features of the database under test. For example, the scenario may be a scenario for testing whether the test target database 100 satisfies an SQL standard. For example, a scenario may include an SQL statement (eg, DROP) for removing an existing database stored in the test target database, an SQL statement (eg CREATE) for creating a new database in the test target database, and input data into the new database. SQL statement (for example, INSERT), and SQL statement (for example, SELECT) for retrieving data to be selected from the new database.

Verified results refer to the correct results of performing the scenario. For example, in a scenario for testing a function for obtaining the maximum value (eg, MAX), 5, 2, and 0.9 are inputted data, and then the function for obtaining the maximum value, i.e., 5 is a verified result. These verified results will vary depending on the scenario, i.e. the data being input and the function or function to be tested changes. Further, for example, in a scenario of testing a plurality of functions or functions, the verified result may be the plurality.

Scenarios can be changed by multiple test operators, and verification results can be changed accordingly. The changed scenarios and verification results may be regarded as the latest version stored in the scenario database 200, and the scenarios and verification results stored in the local storage device 140 need to be upgraded to the latest version if they are not the latest version.

The user interface 140 provides test operators to create scenarios, manage scenarios and verification results stored in the scenario database 200, select scenarios to test the test subject database 300, and display final results. Can be. For example, the user interface 140 may include input / output devices such as a keyboard, a mouse, a monitor, and the like.

The database test automation method can be divided into two steps. One step is to create a new scenario, generate verification results for that scenario, and register the created scenario and the generated verification results in the database. Another step is to select a scenario to be used for the test from the database in which the scenario and the verification result are registered, obtain a test result of performing the scenario, and generate a final result by comparing with the verification result.

The scenario register 110 may be provided to execute the step of registering the new scenario and the verification result corresponding thereto in the scenario database 110.

The scenario creation interface module 111 may provide an interface for a test operator to newly create a scenario for testing the test subject database 100 through the user interface 150. The scenario creation interface module 111 may load text created by a text creation program such as a notepad of a window, and may provide an editor for creating scenario text.

Scenario verification module 112 may be provided to verify the grammatical error of the written scenario. For example, if there are grammatical errors, such as typos or using undefined variables, you can report these errors to the scenario author for correction.

The verification result generation module 113 may be provided to generate a verification result corresponding to the scenario created by the scenario creation interface module 111 or the scenario verified by the scenario verification module 112. As described above, the verification result is the correct result corresponding to the scenario, and this verification result can be manually input by the scenario creator. However, if the data used for the scenario is huge, the test operator cannot manually generate verification results of the scenario. In this case, the test operator may perform the scenario against the verified database 400 and regard the result of the test as the verification result. To this end, the verification result generation module 113 may access the verified database 400 through the database interface unit 130 and perform a scenario for generating a verification result. The execution result will be output, and the verification result can be generated by receiving the execution result as the verification result. As new standards are enacted, verification results may change even if the scenario has not changed. In this case, the test operator can generate verification results in the same manner as above.

The scenario registration module 114 may be provided to register the verification result generated by the verification result generating module 113 and the scenario corresponding thereto in the scenario database 200. The scenario registration module 114 may access the scenario database 200 through the database interface 130. To identify each scenario, the test operator can register with a scenario ID that links the scenario and the verification results. In addition, when a scenario is registered, the ID and access authority of the scenario creator may also be registered by the test operator. As exemplarily shown in FIG. 3, the scenario database 200 may have a scenario table 210 and a verification result table 220, and the scenario and verification results may be stored in the respective tables 210 and 220. have. The scenario database 200 will be described later in detail with reference to FIG. 3.

The scenario management interface module 115 provides a test operator to perform tasks such as input, output, change, deletion, copy, move, etc., of a scenario and a verification result registered in the scenario database 200 through the user interface 150. Can be. For example, scenarios can be organized hierarchically, and the scenario management interface module 115 can be used to change the hierarchy level or change the hierarchy where the scenario is located. Alternatively, the scenario management interface module 115 may be used to delete or edit a specific scenario.

The scenario register 110 may optionally include the above-described modules 111-115, or a part thereof. The modules 111-115 are functionally divided, and some of the above-described modules 111-115 may be integrated into one module.

The database test unit 120 may be provided to test the test target database 300 using the scenario and the verification result registered in the scenario database 200 by the scenario registration unit 110.

Although not shown in FIG. 2, when a plurality of test subject databases 300 are connected to the network 10, a test subject database selection interface module (not shown) for selecting a test subject database 300 to test is provided. Can be provided. The test operator may select the test subject database 300 through the test subject database selection interface module, and select and test a plurality of test subject databases 300 as necessary. The test object database selection interface module may display the test object databases 300 that are currently connected to the test operator. The test operator may select the test target database 300 to test by viewing the list of the test target databases 300 displayed, and in some cases, may select the plurality of test target databases 300.

The database selection interface module 121 may provide an interface for the test operator to select a scenario to test the test subject database 300 among scenarios registered in the scenario database 200 through the user interface 150. The database selection interface module 121 may access the scenario database 200 through the database interface 130. All scenarios registered in the scenario database 200 may be displayed to the test operator, and the test operator may select a scenario to test the test subject database 300. There may be a plurality of scenarios that can be selected. For example, when a scenario is hierarchically configured, when a scenario of a higher layer is selected, all the scenarios which are subordinate to this may be selected. In this case, the plurality of selected scenarios may be continuously performed on the test subject database 300.

The database selection interface module 121 may provide an interface for the test operator to select among scenarios stored in the local storage device 140. When a particular function is implemented in a database, the test automation device 100 will have to repeatedly perform a scenario for testing the function to test whether the function is implemented. In this case, the database selection interface module 121 may store the data in the local storage device 140 and select it therefrom without accessing the remotely located scenario database 200 each time.

The scenario access authentication module 122 may be provided to authenticate whether to allow access to scenarios registered in the scenario database 200. In some cases, scenarios need to be kept secret, so scenario creators have access rights such that only the scenario creator can access the scenario later, or only some groups allowed by the scenario creator. Can be given. The scenario access authentication module 122 may access the scenario database 200 through the database interface unit 130 and receive scenario access permission data to determine whether the current user can execute the scenario. Although not shown in FIG. 3, a login process may be added to identify the test operator.

The scenario unload module 123 may be provided to locally unload the scenario selected by the scenario selection interface module 121 and its verification result. The scenario unload module 123 may access the scenario database 200 through the database interface 130 and locally unload the selected scenario and its verification result. The unloaded scenario can be saved to a local storage device in file format.

The scenario synchronization module 124 may be provided to synchronize the scenario and the verification result registered in the scenario database 200 to the local storage device 140. The scenario unloaded by the scenario unload module 123 and the verification result may be stored in the local storage device 140. When operating the database test automation system, the scenario and the verification result registered in the scenario database 200 may be changed by another operator, accordingly, the scenario and the verification result registered in the scenario database 200 are local storage devices. It may not match the scenario and the verification result stored in 140. The scenario synchronization module 124 may be required to match the verification results with scenarios that do not match each other.

The scenario synchronization module 124 may be connected to the scenario access authentication module 122 to compare the information registered in the scenario database 200 and the information stored in the local storage device 140 with respect to the selected scenario. Next, the operation may be performed using the scenario and the verification result stored in the local storage device 140. If there is a difference as a result of the comparison, the scenario synchronization module 124 may unload to the local storage using the scenario unload module 123.

Although the scenario unload module 123 and the scenario synchronization module 124 are shown as separate modules in FIG. 2, the scenario unload module 123 and the scenario synchronization module 124 may be integrated into one module. A module (not shown) in which the scenario unload module 123 and the scenario synchronization module 124 are integrated into one is searched for the scenario selected by the scenario selection interface module 121 and whether the same scenario exists in the local storage device 140. When there is the same scenario and the verification result, the scenario and the verification result may be retrieved from the local storage device 140. If the scenario and the verification result do not exist or are different from each other, the integration module may access the scenario database 200 to unload the scenario and the verification result.

The database test module 125 may be provided to perform a scenario unloaded by the scenario unload module 123 on the test target database 300 to obtain a test result. The database test module 125 may access the test subject database 300 through the database interface 130. Thereafter, the scenario may be performed on the test target database 300 and the result of the test may be received as a test result. This may be provided to the comparison module 126.

The comparison module 126 may be provided to compare the test results provided by the database test module 125 with the verification results unloaded by the scenario unload module 123. When the test result and the verification result are the same, since the test target database 300 has normally performed the function to be tested by the scenario, the comparison module 126 transmits a signal indicating success to the database interface unit 130. Register in the scenario database 200 through. On the contrary, if the test result and the verification result do not match, it means that the test target database 300 has not normally performed the function. Thus, the comparison module 126 scenarios the test result with a signal indicating failure. It can be registered in the database 200. If the test result is too long, the comparison module 126 may register only the part that differs from the verification result in the scenario database 200.

The database test unit 120 may optionally include the above-described modules 121-126 or a part thereof. The modules 121-126 are functionally divided, and some of the above-described modules 121-126 may be integrated into one module.

The database test automation device 100 shown in FIG. 2 is exemplary and may be composed of modules, functions, or elements that perform the same or similar functions. Also, it should be noted that the connection relations shown in FIG. 2 are exemplary and may be connected differently from those shown.

3 exemplarily illustrates a scenario database and tables stored therein that may be used in a database test automation system according to an embodiment of the present invention. Tables of the scenario database 200 may be changed according to the actual operating environment and the test target.

Scenario table 210 may be provided for storing scenarios. As illustrated in FIG. 3, the scenario table 210 may include a scenario ID 211 and a scenario 212 field. The scenario ID 211 is a number for identifying the scenario and the same number may not exist. Scenario 212 stores the actual scenario. As described above, scenario 212 may consist of SQL statements, and may include, for example, a syntax for creating a database, entering data, and performing a specific function on the data. In addition to this, information such as a scenario name, a scenario version, and the like may be included.

The scenario authentication table 240 may be provided to store attributes such as an operator or a group that can access the scenario. As shown in FIG. 3, the scenario authentication table 240 may include a scenario ID 241, a generator 242, and an access right 243 field. The scenario authentication table 240 may be connected to the scenario 212 field of the scenario table 210 by the scenario ID 241. In addition to the fields 241, 242, and 243, the scenario authentication table 240 may include information such as a scenario creation date, a scenario recent change date, and a scenario recent user.

The scenario hierarchy table 250 may be provided for easy test performance by grouping scenarios. The capabilities and capabilities of the database can be grouped, and test operators need to run a series of grouped scenarios in sequence. In addition, scenarios must be displayed for the test operator to select a scenario. If scenarios are displayed hierarchically, such as Windows Explorer, the test operator can easily select scenarios.

To this end, as shown in FIG. 3, the scenario hierarchy table 250 may include a scenario ID 251, a hierarchy level 252, a folder / file 253, and a higher scenario ID 254 field. The hierarchical level 252 represents the hierarchical level where the scenario is located, for example, viewing the root as 0, the scenario located at the root 1, and the scenario included in the folder located at the root 2. The folder / file 253 means whether the scenario is a folder or a file. The scenario may be a folder containing sub-scenarios. If the lower scenarios are scenarios for testing similar functionality, they can be grouped and represented as contained in the upper scenario folder. The upper scenario ID 254 is a field for identifying the upper scenario.

The verification result table 220 may be provided to store the normal result of performing the scenario. As shown in FIG. 3, the verification result table 220 may include a scenario ID 221 and a verification result 222 field. The verification result table 220 may be connected to the scenario 212 field of the scenario table 210 through the scenario ID 221. The verification result 222 field may store the correct result of performing the scenario 212 corresponding to the scenario ID 221. If scenario 212 includes one test, the result corresponding to scenario 212 may be one, or if scenario 212 includes several tests, the result corresponding to scenario 212 may also be There can be several. To this end, a lower ID (not shown) field may be included in the verification result table 220 for distinguishing several tests included in one scenario, and the verification result 222 field may be a normal result of a test corresponding to the lower ID. Can be stored.

The final result table 230 may be provided to store the final result of comparing the result of performing the scenario with the verification result against the test target database. As shown in FIG. 3, the test subject database ID 231, the test date and time 232, the scenario ID 233, the success / failure 234, and the test result 235 may be included in the final result table 230. have.

The test subject database ID 231 is a field for identifying the database subject to the test that performed the scenario. The test date and time 232 is a field for storing the date and time of the test, and may be used for performance change trends or bug tracking of the corresponding database. The scenario ID 233 is a field for identifying a scenario in which a test is performed. Success / failure 234 is a field for recording whether or not the test result that performed the scenario coincided with the verification result. The test result 235 is a field for storing the test result 235 in case of failure, and only a part different from the verification result may be stored. In addition to the fields 231-235 described above, information such as a test performer and a database test automation device ID which performed the test may be additionally stored in the final result table 230.

For example, if one scenario includes multiple subtests and the validation result table 220 includes a sub ID field, the final result table 230 also includes a sub ID (not shown) field, each The test results corresponding to the subtests of the test should be stored.

The tables 210, 220, 230, 240, 250 described above are exemplary, and some of them may be integrated into one table or separated into two or more tables. In addition to the above-described tables 210, 220, 230, 240, and 250, the scenario database 200 may include a table for a test operator, a table for a test operator group, and the like.

4 is a flowchart schematically illustrating a method for automating database test using the database test automation system described above.

Referring to FIG. 4, a method for automating a database test includes registering a scenario for testing a test target database and a corresponding verification result in a remote scenario database (S402) and the test target using the scenario. The step of testing the database can be largely divided (S404).

5 and 6 are exemplary flowcharts specifically describing the database test automation method of FIG. 4. 5 is a flowchart illustrating a process of registering a scenario, and FIG. 6 is a flowchart illustrating a process of testing a database. Note that this order is exemplary and one or more steps may be added, or some steps may be omitted or incorporated into one step.

Referring to FIG. 5 together with FIGS. 1 to 3, the test operator may create a scenario in step S502. The test operator may write scenario text using the user interface 150 of the database test automation device 100. The scenario creation interface module 111 may recognize the created scenario text as a scenario.

The scenario created in step S504 can be verified. This step can be done in scenario verification module 112.

In operation S506, the verification result may be generated. The verification result generation module 113 may generate the verification result by performing the created scenario on the verified database 400 and receiving the result as the verification result. To describe the step S506 in detail, the verification result generation module 113 receives the scenario created in the step S502. Thereafter, the verification result generation module 113 accesses the verified database 400 through the database interface 130. Thereafter, the verification result generation module 113 performs the scenario against the verified database 400 and receives the result. The result of performing the scenario may be regarded as the verification result.

In operation S508, the scenario and the verification result may be registered in the scenario database 200. To describe the step S508 in detail, the scenario registration module 114 receives the scenario created in step S502 and the verification result generated in step S506. Thereafter, the scenario registration module 114 accesses the scenario database 400 through the database interface 130. Thereafter, the scenario registration module 114 assigns the scenario ID corresponding to the scenario and the verification result and registers the scenario table 210 and the verification result table 220 of FIG. 3 together with the scenario ID. The scenario registration module 114 registers information including scenario creator information in the scenario authentication table 240 and the scenario hierarchy table 250.

As the steps S502 to S508 are repeated, a plurality of scenario information and verification result information corresponding thereto will be registered in the scenario database 200. In addition, there may be an error in the scenario and the verification result, or the scenario and the verification result may need to be changed as a new standard is applied. In this case, the test operator may perform basic database operations such as modifying, moving, or deleting a scenario through the scenario management interface module 115.

Note that this operation can be performed in a plurality of database test automation device (100). For example, the first, fourth and fifth scenarios and the verification results may be generated in the first database test automation device 100, and the second and third scenarios and the verification results may be generated in the second database test automation device 100. Can be generated. In addition, the scenario and the verification result generated in the first database test automation device 100 may be modified in the second database test automation device 100.

Referring now to FIG. 6 in conjunction with FIGS. 1 to 3, in step S602, the test operator may select a scenario to test the test subject database 300. The scenario selection interface module 121 accesses the scenario database 200 through the database interface 130 and displays a list of scenarios stored in the scenario table 210 of the scenario database 200 on the display screen. The scenario selection interface module 121 may layer and display the scenario selection interface module 250 using the scenario hierarchy table 250. In order for the test operator to know the purpose of the scenario or the function to be tested, the scenario selection interface module 121 may display the name of the scenario or a brief summary. The test operator can select the scenario to test from the displayed scenario list. A plurality of scenarios may be selected, in which case the plurality of scenarios will be performed on the test target database 300 continuously.

In step S604, it may be determined whether the test operator has the authority to access the scenario. The scenario access authentication module 122 may access the scenario database 200 and check whether the current test operator has access to the selected scenario through the scenario authentication table 240 of the scenario database 200. . If the check result has access, the scenario access authentication module 122 provides the selected scenario list to at least one of the scenario unload module 123 and the scenario synchronization module 124.

In step S606, synchronization may be performed for the selected scenario. The scenario synchronization module 124 checks whether the information stored in the scenario database 200 and the information stored in the local storage device 140 match with respect to the selected scenario, and if so, the scenario synchronization module 124 matches the selected scenario from the local storage device 140. Corresponding verification results may be provided to the database test module 125 and the comparison module 126, respectively. The scenario synchronization module 124 may compare the data size, changed date and time, version information, etc. of both scenarios to check for a match. However, if there is a mismatch, the scenario synchronization module 124 may provide the scenario unload module 123 with a list of scenarios that do not match.

In operation S608, the database test automation device 100 may unload the selected scenario. The scenario unload module 123 may access the scenario database 200 to unload the selected scenario and a verification result corresponding thereto. In addition, the scenario unload module 123 may store the unloaded scenario and the verification result in the local storage device 140. The scenario unload module 123 may provide the unloaded scenario and verification results to the database test module 125 and the comparison module 126, respectively.

In operation S610, the database test automation device 100 may perform the unloaded scenario on the test target database 300. The database test module 125 connects to the test subject database 300 through the database interface 130. Thereafter, the unloaded scenario can be performed. The execution result may be displayed.

In step S612, the database test module 125 may receive the performance result as a test result. Thereafter, the test result may be provided to the comparison module 126 and disconnected from the test subject database 300.

In step S614, the comparison module 126 may compare the verification result provided in step S606 or S608 with the test result provided in step S612. Both the test result and the verification result may be formed of a character string or may be execution time depending on a function or performance to be tested.

In operation S616, the comparison module 126 may register the comparison result as the final result in the scenario database 200. The result of the comparison may include a signal indicating success or failure, and may also include a string and a position of a difference part in case of failure. The comparison module 126 connects to the scenario database 200, and displays the signal, the string, and the position together with the final result table of the scenario database 200 together with the date and time of the test and the test subject database ID. 230).

Here, in order to make the invention easy to understand, it has been described as testing on a single test subject database 300 in a single database test automation device 100, but the test operators in a plurality of database test automation devices 100 The tests can be performed simultaneously and independently of each other. In addition, each of the plurality of database test automation devices 100 may perform a test on the plurality of test target databases 300.

In addition, although the steps S602 to S616 are represented as independent steps, they may be integrally performed at the same time. For example, the step of synchronizing the scenario (S606) and the step of unloading the scenario and the verification result (S608) may be performed in combination. In addition, in order to reduce the total test execution time, the database test automation device 100 unloads a scenario from the scenario database 200 and performs the test result on the test target database 300, while performing a verification result corresponding to the scenario in the scenario database ( 200) can be unloaded.

7 illustrates an example operation of a database test automation system according to an embodiment of the present invention. This embodiment is illustrative and does not depict overlapping descriptions or components for ease of understanding.

Referring to FIG. 7, four database test automation devices 710a-d, a scenario database 720, and four test subject databases 730a-d and a validated database 740 connect to the network 701. It is.

For example, a scenario may be created in the first database test automation device 710a among the four database test automation devices 710a-d and registered in the scenario database 720. The fourth database test automation device 710d uses the plurality of scenarios 721a-c and the plurality of verification results 722a-c registered in the scenario database 720. ) Can be tested. At the same time, the second database test automation device 710b registers the new scenario and the corresponding verification result in the scenario database 720, and then uses the scenario and the verification result to display two or more test target databases 730a, c, d) may be tested. In addition, at the same time, the third database test automation device 710c unloads the plurality of scenarios 721a-c and the plurality of verification results 722a-c registered in the scenario database 720 to be modified or edited. You can also update to a new version.

As described above, the present database test automation system 700 can be connected to each other based on the network 701 and, at the same time, can independently test the test target databases 730a-d, and systematically examine the test results. Can manage

8 diagrammatically illustrates the data flow in the database test automation system 700 of FIG. 7 described above. In the present embodiment, the first database test automation device 710a registers a new scenario and a corresponding verification result in the scenario database 720, and the fourth database test automation device 710d is registered in the scenario database 720. The third test subject database 730c is being tested using multiple registered scenarios 721a-c and multiple validation results 722a-c. This embodiment is illustrative.

First, an operation of registering a scenario and a verification result corresponding thereto by the first database test automation apparatus 710a in the scenario database 720 will be described first. A new scenario may be created in the database test automation device 710a. In order to generate the verification result corresponding to this new scenario, the database test automation device 710a may perform the scenario on the verified database 740 and receive the verification result. Thereafter, the database test automation device 710a may register the scenario and the verification result in the scenario database 720.

Next, the step of testing the third test subject database 730c by the fourth database test automation apparatus 710d using the scenarios and verification results registered in the scenario database 720 will be described. The fourth database test automation device 710d may unload the scenario to test the third test subject database 730c and the verification result corresponding thereto from the scenario database 720. Thereafter, the unloaded scenario is performed on the third test target database 730c, and a test result that is a result of performing the scenario is received. Thereafter, the unloaded verification result is compared with the test result to generate a final result, and the final result is registered in the scenario database 720.

In the above description, the step in which the first database test automation device 710a registers the scenario and corresponding verification results in the scenario database 720 is registered in the scenario database 720 by the fourth database test automation device 710d. Although shown prior to the step of testing the third test subject database 730c using the scenarios and verification results, those skilled in the art will appreciate that the order may be reversed or even proceed simultaneously. . Those skilled in the art will also understand that the database test automation devices 710a-d may be replaced with each other as a device performing the same function as each other.

9 and 10 are diagrams for describing the data flow of FIG. 8 in more detail. 9 illustrates a step in which the first database test automation device 710a registers a scenario and a corresponding verification result in the scenario database 720. FIG. 10 illustrates a scenario in which the fourth database test automation device 710d is scenario. Testing the third test subject database 730c using the scenarios and verification results registered in the database 720.

9 and 10, only some components are shown for ease of understanding. In addition, although components may actually be implemented by reading or writing data stored in main memory such as a memory, in FIGS. 9 and 10, the data between components of the database test automation apparatus 710a-d may be implemented. Note that it is shown as being transmitted and received.

The thick solid line means that data is actually transmitted and received through the network. The thin solid line means the data flow between each module in the database test automation device 710a, d, where the data is not actually transmitted or received, but may be implemented by reading and writing data stored in the memory. The dashed line means that the data is not actually sent or received, but it does carry out the scenario and receive the result.

Also, although the first database test automation device 710a, the scenario database 720, and the verified database 740 are connected to the network, the network is omitted for ease of understanding.

Referring to FIG. 9, the first database test automation device 710a includes a scenario creation interface module 711, a verification result generation module 712, and a scenario and verification result registration module 713. In addition, a plurality of scenarios, a plurality of verification results, and a plurality of final results are registered in the scenario database 720.

First, a new scenario may be created by the scenario generator in the scenario creation interface module 711.

Thereafter, the verification result generation module 712 may receive the new scenario created by the scenario creation interface module 711. Thereafter, the verification result generation module 712 may perform the scenario on the verified database 740 and receive the execution result as a verification result.

Thereafter, the scenario and verification result registration module 713 may receive the newly created scenario from the scenario creation interface module 711 and may also receive the newly generated verification result from the verification result generation module 712. Thereafter, the scenario and verification result registration module 713 may register the scenario and the verification result in the scenario database 720.

Referring to FIG. 10, the fourth database test automation device 710d may include a test target database selection interface module 714, a scenario selection interface module 715, a scenario unload module 716, a scenario execution module 717, and a final result. It includes a registration module and also includes a local storage 719 that can store scenarios and verification results. The local storage device 719 stores a plurality of scenarios and a plurality of verification results. In addition, a plurality of scenarios, a plurality of verification results, and a plurality of final results are registered in the scenario database 720. A plurality of test subject databases 730a-d are connected to a network (not shown). In the present embodiment, an embodiment in which a test is performed on the third test target database 730c among the plurality of test target databases 730a-d will be described.

First, using the test subject database selection interface module 714, the test operator may select a test subject database from which to perform a test among a plurality of test subject databases 730a-d. The test subject database selection interface module 714 may display to the test operator a list of test subject databases 730a-d that are connected to a network (not shown) or to which the third test subject database 730c can connect. . The test operator may select the test subject database 730c to test through the list of connectable test subject databases 730a-d displayed. In this embodiment, the third test subject database 730c will be described as selected. However, a plurality of test subject databases 730a-d may be selected. The test object database selection interface module 714 may provide the scenario execution module 717 with information of the test object database selected from the test operator.

Although not shown in FIG. 10, the fourth database test automation device 710d may include a login module (not shown) for identifying a test operator. Before the test operator selects the test target databases 730a-d to perform the test, the test operator may be identified by using a fourth database test automation device 710d after logging in. Using the test operator information identified through the login process, the test subject database selection interface module 714 may display only a list of test subject databases 730a-d accessible to the test operator.

Thereafter, the test operator may select a scenario to be performed on the third test subject database 730c using the scenario selection interface module 715. The scenario selection interface module 715 may receive a list of scenarios registered in the scenario database 720 from the scenario database 720 and display the list of scenarios to the test operator. When the test operator information is identified through the login process, the scenario selection interface module 715 may display only a list of scenarios to which the test operator has access. The test operator may select a scenario to be performed on the third test subject database 730c through the list of displayed scenarios. As mentioned above, multiple scenarios may be selected. The scenario selection interface module 715 may provide the selected scenario information to the scenario unload module 716.

The scenario unload module 716 can then receive the selected scenario information from the scenario selection interface module 715. The scenario unload module 716 may search whether the scenario exists in the local storage device 719 according to the received scenario information. If present, the scenario unloading module 716 may check whether the corresponding scenario stored in the local storage device 719 matches the corresponding scenario registered in the scenario database 720. As a result of the check, when the scenarios coincide with each other, and the corresponding verification results also coincide with each other, as indicated by a dashed-dotted line, the scenario unloading module 716 displays scenario information indicating that the scenario exists in the local storage device 719. The verification result information may be provided to the scenario execution module 717, and the final result registration module 718 may provide verification result information indicating that the verification result corresponding to the scenario exists in the local storage device 719.

If the scenario does not exist in the local storage device 719 or even if it does exist, the scenario stored in the local storage device 719 and the corresponding scenario registered in the scenario database 720 do not match each other. The module 716 may unload a corresponding scenario registered in the scenario database 720 and a verification result corresponding thereto. Thereafter, the scenario unloading module 716 may provide the unloaded scenario and the verification result to the scenario execution module 717 and the final result registration module 718, respectively, as indicated by the solid line. The verification result may be stored in the local storage device 719.

The scenario execution module 717 then optionally receives scenario information from the scenario unload module 716 (as in the case of a dashed line) to read the scenario from the local storage 719, or (solid line As may be the case, a scenario may be received from the scenario unload module 716. In addition, the scenario execution module 717 may receive the test target database information to perform the test from the test target database selection interface module 714 to determine the test target database 730c. The scenario execution module 717 may then perform the scenario on the third test subject database 730c determined to perform the test. The scenario execution module 717 may receive a test result that is a result of performing the scenario. The scenario execution module 717 may provide the received test result to the final result registration module 718.

The final result registration module 718 can then receive the test results from the scenario execution module 717. The final result registration module 718 optionally receives the verification result information from the scenario unloading module 716 (as in the case of a dashed line) to read the verification result from the local storage device 719, or (solid line As may be the case, a verification result may be received from the scenario unload module 716. Thereafter, the final result registration module 718 may compare the test result with the verification result and generate a final result including success or failure. The final result registration module 718 may display the final result to the test operator and may also register the final result in the scenario database 720.

Those skilled in the art may additionally include various illustrative logic blocks, configurations, circuits, and steps described in connection with the embodiments disclosed herein in electronic hardware, computer software, or both. It will be appreciated that it can be implemented as a combination of. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, configurations, modules, circuits, and steps have been described above generally in terms of their functionality. Whether these functions are implemented in hardware or software depends on the specific application and design constraints imposed on the overall system. Those skilled in the art may implement the above described functionality in different ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The methods or steps described in connection with the embodiments disclosed herein may be implemented directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in RAM memory, flash memory, ROM memory, PROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. have. An exemplary storage medium is coupled to the processor such that the processor can read information from and write information to the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a wireless device or user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a wireless device or user terminal.

The previous description of the disclosed embodiments can be provided to those skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art to which the invention pertains, and the generic principles defined herein may be modified in other embodiments without departing from the scope or spirit of the invention. Can be applied. Thus, the invention is intended not to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features as defined by the following claims.

1 is a conceptual diagram schematically showing a database test automation system according to an embodiment of the present invention.

FIG. 2 is a block diagram exemplarily illustrating a function of a database test automation device of a database test automation system according to an exemplary embodiment of the present invention.

3 is a diagram illustrating a scenario database of a database test automation system according to an embodiment of the present invention.

4 is a flowchart schematically illustrating a method for automating database test according to an embodiment of the present invention.

FIG. 5 is a flowchart illustrating an example of registering a scenario and a verification result in the database test automation method of FIG. 4.

FIG. 6 is a flowchart illustrating an example of testing a test target database in the database test automation method of FIG. 4.

FIG. 7 exemplarily illustrates a network connection diagram in which a database test automation system according to an exemplary embodiment of the present invention is operated.

FIG. 8 is a data flowchart exemplarily illustrating a flow of data being transmitted and received in the network connection diagram of FIG. 7.

9 exemplarily illustrates in detail the step of registering a scenario and a verification result in the data flow chart of FIG. 8.

FIG. 10 exemplarily illustrates the step of testing the database in the data flow diagram of FIG. 8.

Claims (23)

A scenario for testing a test subject database, and a scenario and verification result registration step of registering a verification result corresponding to the scenario and a verification result generated using the verified database in a remote scenario database; And And a database test step of testing the test subject database using the scenario, wherein the test subject database, the verified database and the test subject database are connected via a network. The method of claim 1, The scenario registration step may include a scenario creation step of creating the scenario; A verification result generating step of accessing the verified database, performing the scenario on the verified database, and receiving the result as a verification result; And a scenario and verification result registration step of registering the scenario and the verification result by accessing the remote scenario database. The database testing step may include: a scenario unloading step of accessing the remote scenario database and unloading the scenario and the verification result; A scenario execution step of accessing the test target database, performing the unloaded scenario on the test target database, and receiving the result as a test result; And a final result generation step of comparing the test result with the unloaded verification result and registering a final result by accessing the remote scenario database. The method of claim 2, Verifying the scenario created in the scenario creation step between the scenario creation step and the verification result generation step. The method of claim 2, In the final result generation step, i) when the test result and the unloaded verification result are the same, a test date and time, an identification number of the database to be tested, and information indicating success are added to the remote scenario database together with the final result. And ii) if the test result and the unloaded verification result are not the same, different from the test date and time, the identification number of the database to be tested, information indicating failure, and the test result and the unloaded verification result. And a portion is registered in the remote scenario database. The method of claim 4, wherein And displaying the final results according to the test date and time, for the test subject database that can be identified by the identification number. The method of claim 1, Wherein the scenario registration step is executed in a first database test automation device, and the database test step can be executed in a second database test automation device. The method of claim 1, The database test step may be executed simultaneously for different test subject databases, and may be executed simultaneously in different database test automation devices. The method of claim 1, And said scenario comprises a scenario for testing whether said test subject database satisfies an SQL standard. The method of claim 1, The scenario may be selected from an SQL statement for removing an existing database stored in the test subject database, an SQL statement for creating a new database in the test subject database, an SQL statement for inputting data into the new database, and the new database. A method for automating database testing, comprising: an SQL statement for retrieving data or a combination thereof. The method of claim 1, The scenario registration step may include a scenario creation step of creating the scenario; A verification result generating step of generating a verification result corresponding to the scenario; And a scenario and a verification result registration step of registering the scenario and the verification result by accessing the remote scenario database, and repeating the scenario registration step, the remote scenario database includes a plurality of scenarios and corresponding scenarios. Multiple verification results are registered, The database testing step may include: a scenario selecting step of accessing the remote scenario database and selecting a scenario to test the test target database from among the plurality of scenarios registered in the remote scenario database; A scenario unloading step of unloading the selected scenario and a verification result corresponding thereto and storing them in a local storage device; A scenario execution step of accessing the test target database and performing the unloaded scenario on the test target database and receiving the result as a test result; And a final result generation step of comparing the test result with the unloaded verification result and registering a final result by accessing the remote scenario database. The method of claim 10, The generating of the verification result includes accessing the verified database, performing the scenario on the verified database, and receiving the performed result as the verification result. The method of claim 10, In the scenario selecting step, a plurality of scenarios are selected from the plurality of scenarios, the plurality of scenarios are unloaded in the scenario unloading step, and the plurality of scenarios are continuously performed on the test target database in the scenario performing step. Database test automation method, characterized in that the. The method of claim 10, In the scenario and verification result registration step, the scenario and the verification result are registered in the remote scenario database together with the access right information corresponding to the scenario, and between the scenario selection step and the unloading scenario step, the selected scenario And authenticating whether or not there is an access right for the selected scenario by using the access right information corresponding to the method. The method of claim 10, As the database test step is repeated, the local storage device stores a plurality of unloaded scenarios and a plurality of unloaded verification results corresponding thereto, Checking whether the scenario selected in the scenario selecting step is stored in the local storage device and coincides with the scenario stored in the local storage device between the scenario selecting step and the scenario unloading step. Only when the scenario does not exist in the storage device or does not coincide with the scenario existing in the local storage device, in the scenario unloading step, the selected scenario and the verification result corresponding thereto are unloaded and stored in the local storage device. Automation method. The method of claim 14, If the scenario selected in the scenario selection step matches the scenario stored in the local storage device, executing the scenario execution step and the final result generation step by using the scenario stored in the local storage device and a verification result corresponding thereto. Database test automation method, characterized in that. A computer-readable medium having recorded thereon a program for causing the computer to execute the method for automating the database test according to any one of claims 1 to 15. A scenario database server including scenarios for testing a test subject database and a scenario database in which corresponding verification results can be registered; And At least one database test automation device connected to the scenario database server and the test target database through a network to automate a test of the test target database, wherein the database test automation device includes the scenarios and the verification. A scenario register for registering results in the scenario database; And a database tester for testing the test subject database using the scenarios. The method of claim 17, The scenario registration unit may include a scenario creation interface module that provides an interface for creating the scenarios; A verification result generation module for generating verification results corresponding to the created scenarios; And a scenario registration module for registering the created scenarios and the verification results by accessing the scenario database. The database test unit may include: a test scenario selection interface module configured to access the scenario database and provide an interface for selecting a scenario to test the test target database from among the scenarios registered in the scenario database; A scenario unload module for accessing the scenario database to unload the selected scenario and corresponding verification results from the scenario database; A database test module for accessing the test subject database and performing the unloaded scenario on the test subject database and receiving the result as a test result; And a comparison module for comparing the test result with the unloaded verification result to generate a final result. The method of claim 17, And a verified database coupled with the at least one database test automation device via the network, wherein the verification result generation module accesses the verified database and displays the created at least some scenarios for the verified database. And perform and receive the results as the at least some verification results. The method of claim 17, The scenario registration unit is an interface for accessing the scenario database and performing input, output, change, deletion, copying, moving, or a combination thereof on the scenarios registered in the scenario database and the verification results corresponding thereto. Database test automation system further comprises a scenario management interface module for providing a. The method of claim 17, Scenarios registered in the scenario database are hierarchically configured, and as the scenario of the upper layer is selected, scenarios of the lower layer dependent on the scenario of the upper layer are performed on the test target database. Automation system. The method of claim 17, The database test automation device may further include a local storage device for storing the unloaded scenario and a verification result corresponding thereto, and selecting the scenario to test the database to be tested, the verification result corresponding to the selected scenario. And a scenario synchronization module for synchronizing said local storage with respect to said scenario database. The method of claim 17, A plurality of database test automation devices are connected to the scenario database server, and each of the plurality of database test automation devices tests the plurality of test target databases using the scenario database server. .

Images