TWI611291B - Computer program product for automatically generating software test data and method thereof - Google Patents

Description

Computer program product for automatically generating software test data and method thereof

The invention relates to an automation software testing technical solution, in particular to an automatic software testing technical solution capable of providing suitable testing data according to the marking of the testing program.

The development of current information systems requires analysis, design, implementation, testing, integration testing, and introduction to the line. In order to ensure the normal operation of the information system, the program to be tested is disassembled into at least one independent function module during development, and each function module is verified separately during the development process to reduce subsequent removal. The complexity of the mistake.

Please refer to FIG. 1 , which is a schematic diagram of a conventional software testing system. When the system is running, firstly, each function module 11 to be tested in the program 1 is provided with one or more sets of test programs 2 according to the complexity of the program or the situation to be simulated. When the test program 2 is executed, each test data required for the test must be separately prepared, and the data is written into the database 3 (S101), and after the test data is written, the function module 11 to be tested is called (S102). The test data in the database 3 is accessed to perform a test operation (S103). After the test is completed, the test program will access the database to verify whether the results of the aforementioned test data are in line with expectations (S104).

After the first functional module test operation is completed, the test data inside the database has been changed, so it is impossible to ensure whether the next function module can be tested normally. In addition, when the test environment (such as test system or database type) has changed, the former The system described will not work properly.

In summary, how to provide a technical solution that can solve the dilemma of the conventional automation software test is a technical problem that needs to be solved in the field.

In order to solve the problems disclosed above, an object of the present invention is to provide an automated software testing technical solution.

To achieve the above object, the present invention provides a computer program product for automatically generating software test data. The aforementioned computer program product for automatically generating software test data is used to drive a test program to test a program to be tested including at least one function module. The aforementioned computer program product includes a test engine and a data generation engine. The test engine is based on the labeling of the test program to initialize and set the test data corresponding to each function module when each function module is tested. The data generation engine connected to the test engine is based on the annotation, the data generation policy profile, and the database description file to automatically generate the test data required for the program to be tested.

To achieve the above object, the present invention proposes a method for automatically generating software test data. The method is for driving a test program to test a program to be tested that includes at least one functional module. The foregoing method includes the following steps: First, according to the labeling of the test program, the test data corresponding to each function module is initialized and set when each function module is tested. Then, according to the annotation, the data generation strategy profile, and the database description file, the test data required for the program to be tested is automatically generated.

In summary, the computer program product and method for automatically generating software test data of the present invention reconfigure test data by accessing the mark on the program to be tested to ensure that each function module can be saved during the test. Take the correct test data for testing.

1‧‧‧testing program

11‧‧‧ function module

2‧‧‧Testing program

3‧‧‧Database

4‧‧‧Computer program products for automated generation of software test data

41‧‧‧Test Engine

42‧‧‧Data Generation Engine

43‧‧‧Data dictionary module

44‧‧‧ Data Generation Strategy Module

Figure 1 is a schematic diagram of a system of the prior art.

2 is a schematic diagram of an automated software testing system of the present invention.

3 is a flow chart of a method for automatically generating software test data according to an embodiment of the present invention.

FIG. 4 is a schematic diagram showing the operation flow of the computer program product for automatically generating software test data according to the present invention.

The specific embodiments are described below to illustrate the embodiments of the invention, but are not intended to limit the scope of the invention.

Please refer to FIG. 2 , which is a schematic diagram of the automated software testing system of the present invention. The system includes a program to be tested 1, a test program 2, a database 3, and a computer program product 4 for automatically generating software test data in the present case. The foregoing test program 1 includes at least one function module 11, and the computer program product 4 for automatically generating software test data further includes a test engine 41, a data generation engine 42, a data dictionary module 43, and a data generation strategy. Module 44. The aforementioned data generation engine 42 is connected to the test engine 41, the data dictionary, and the data generation policy module 44.

The foregoing test program 2 is provided with an annotation, so that when the test engine 41 is in operation, the test engine 41 can use the Aspect Oriented Programming (AOP) method to access the annotation on the test program 2. And the database 3 is initialized according to the content of the label (for example, data clearing, data restoration, or data reconstruction).

Next, the test engine 41 transmits the information captured by the label to the data generation engine 42. When the data generation engine 42 receives the information, the data generation engine 42 also refers to the system's data generation strategy module 44 and The data dictionary module 43 is used to automatically generate various test data required. The foregoing data generation policy module 44 includes a data generation policy profile that can provide settings for the user. The foregoing data dictionary module 43 includes a database structure description file, and the foregoing database structure description file selects a field including each table, a field attribute, a field data type, a field restriction condition, and a field question. Relevance and other information, in order to make the computer program product 4 used to automatically generate software test data in this case also has the characteristics of cross-database 3, so the database structure description file contains a plurality of database 3 types to provide cross-database 3 operation. Therefore, when transplanted to different database 3 systems, the aforementioned system can still operate normally without additional modifications and adjustments.

After the data is correctly generated and the data is imported into the database 3 (S201), the test program 2 can call the function module 11 to be tested (S202) to drive the function module 11 to the database 3 to read the test. Data (S203), when the function module 11 under test is completed, the test program 2 will go to the database 3 for verification (S204), and analyze whether the result of the test data meets the expectation to determine the function mode to be tested. Group 11 is working properly.

Regardless of whether the test results of the respective function modules 11 are normal or not, when the next function module 11 performs the test, the test engine 41 re-initializes the initialization operation of the database 3 to maintain the correctness of the data at each test. The data of each function module 11 does not affect each other for the purpose of automated testing.

The foregoing test engine 41, data generation engine 42, data generation policy module 44, and data dictionary module 43 can be implemented by ASP, C/C++/C#, JAVA, Python, PHP, Perl. Such as the implementation of the programming language, but the category of the programming language is not limited to this.

Referring to FIG. 3, in another embodiment, the present invention further provides a method for automatically generating software test data, which is used to drive a test program to test a program to be tested including at least one function module, and the method includes the following step:

S301: According to the labeling of the test program, when the function modules are tested, the test data corresponding to each function module is initialized and set.

S302: According to the annotation, the data generation strategy profile, and the database description file, to automatically generate the test data required for the program to be tested.

In another embodiment, the aforementioned test program accesses the annotations through a oriented programming development technique. The aforementioned initialization settings are selected for data clearing, data recovery, or data reconstruction. The foregoing database description file selection includes field attributes, field data types, field restrictions, or inter-column associations. Further, the foregoing database 3 description file contains a plurality of database types to provide cross-database operations.

Please refer to Table 1 and Table 2. In the context of use, if there is a user data table and a department data table in the database 3, the "_department_id" in the user data table. The field is the foreign index key of the department data table; the _zip field in the department data table has the Check Constraint restriction condition, and the correct postal area code must be filled in, and the data can be written after passing the inspection.

The following is an explanation of the operation flow of the computer program product 4 for automatically generating software test data in this case. It is worth noting that the method used to automate the generation of software test data in this case also has the functions described below. If you want to develop a user management module for managing the above data table, and there are three groups in this module, namely, CreateUser, ModifyUser, and DeleteUser. The function module 11 needs to be tested. Tested by TestCreateUser, TestModifyUser test program 2 and TestDeleteUser test program 2.

In the test situation of TestCreateUser, the CreateUser function module 11 will be called first. After executing the test program 2, it is necessary to go to the database 3 to check whether a new user is correctly generated. If the correct generation occurs, the return test is correct, and vice versa. Then the passback test failed.

When the CreateUSer function module 11 is operated in the test mode of the prior art, the instruction of the INSERT INTO User(_name,_department_id)VALUES('admin,,?) is executed, since the -department_id is the external index key of the department data table. Therefore, when the CreateUser function module 11 is executed, the related data of the department data is not established, in other words, the user is generated. In the case of the data, the _department-id in the user profile cannot be filled in. In this case, the conventional technology fails to add a user, and thus the function of the CreateUser function module 11 fails to be executed.

In order to deal with the foregoing situation, the present invention utilizes the test engine 41 to improve the above disadvantages. The test flow is as shown in FIG. 4. When the TestCreateUser test program 2 is started, the test engine 41 (S401) is from the test of the TestCreateUser test program 2. The message of @TestData(table=Department, content={id=1, name=文山}) is retrieved (S402), at which time the test engine 41 transmits the data to the data generation engine 42 (S403), the data generation engine. 42 will start to analyze the related information of the department from the data dictionary module 43 (S404), and finally return the fields in the table, the attributes of the fields, and the related restrictions (S405). For example, there will be a field _id, _name, _zip, which are Primary Key, Integer type, _name is null able, _zip has Check Constraint condition, and the values that can be filled are "100, 103, 104,. .." and so on.

After obtaining the information, the data generation engine 42 then fills in the appropriate value according to the Strategy defined by the user (S406). For example, if _name is found in Zhongzheng District, _zip will return 100, _name will be filled in Beitou District, _zip will return 112, Wenshan District, _zip return 116 (S407). Therefore, at this time, the data generation engine 42 obtains the returned INSERT INTO Department (_id, _name, _zip) VALUES (1, Wenshan District, 116) according to the input of the data dictionary module 43 and the policy, and is executed by the test engine 41 ( S408).

After the test engine 41 generates the department data (S409), the database 3 will return the new success (S410), at which time the test engine 41 will return the control to the test program 2 of the TestCreateUser test program 2 (S411) to facilitate After the test of the CreateUser function module 11 (S412), the CreateUser function module 11 performs the user data addition (S413) operation. After the completion, the TestCreateUser test program 2 will go to the database 3 to verify whether the data is correct (S414). And will knot The result is reported to the test engine 41 (S415), and the unit test of the single function module 11 is completed.

Similarly, when testing the TestModifyUser test program 2, there must be a user data in the database 3 to perform the user-modified action. Therefore, the TestModifyUser test program 2 will mark a user database in the user database 3 table. The pen tag @TestData(table=User,content={id=1,name=admin}) indicates that in the user profile, the user data of id 1 and name admin is automatically generated. After the data, the ModifyUser function module 11 can modify the data (for example, the "name" field of the user with id 1 can be changed to root).

When the ModifyUser function module 11 is executed, it can be judged in the TestModifyUser test program 2 whether the user "name" with the id 1 in the database 3 is root. If it is correct, the return test is correct, otherwise the return test fails. .

Considering that the CreateUser function module 11 may fail to execute, and the data cannot be generated normally. Even if the ModifyUser function module 11 is correct, the error of the CreateUser function module 11 may cause the testModifyUser test program 2 to make a judgment error, thereby causing more The judgment of multiple test situations is wrong. Therefore, the computer program product of the present invention does not directly use the data generated in the TestCreateUser test program 2 to perform the ModifyUser function module 11 to ensure that no false positives are generated.

The difference from the CreateUser function module 11 is that after the data generation engine 42 is executed, a department data and a user data are first transmitted and executed successively to ensure that the user data can be correctly generated. In other words, the data generation engine 42 can handle any type of Constraint condition and ensure that test data can be generated correctly.

In TestDeleteUser test program 2, you need to test the program in TestDeleteUser 2 marked @TestData (table=User, count=5), this annotation indicates that 5 data is generated automatically in the user data table, at this time we can call the DeleteUser function module 11 to delete the user's action. After the execution is completed, the TestDeleteUser test program 2 determines whether the number of data in the database 3 is in accordance with expectations.

In addition, the test engine 41 also supports @TestCleanData to indicate that the database 3 is emptied, @TestBaseData indicates that the database 3 is imported into the preset data, and @TestLoadingData indicates that the stress test data is generated to facilitate the development and testing of the information system.

The detailed description of the preferred embodiments of the present invention is intended to be limited to the scope of the invention, and is not intended to limit the scope of the invention. The patent scope of this case.

1‧‧‧testing program

11‧‧‧ function module

2‧‧‧Testing program

3‧‧‧Database

4‧‧‧Computer program products for automated generation of software test data

41‧‧‧Test Engine

42‧‧‧Data Generation Engine

43‧‧‧Data dictionary module

44‧‧‧ Data Generation Strategy Module

Claims (10)

A computer program product for automatically generating software test data, providing test data to drive a test program to test a program to be tested including at least one function module, comprising: a test engine, accessing a mark of the test program, and according to the test program The labeling is used to initialize the setting corresponding to the test data of each function module when the function module is tested; the data generation strategy module provides a data generation strategy setting file; the data dictionary module provides a database description file. And a data generation engine, the test engine, the data generation strategy module, and the data dictionary module, wherein the data generation engine is automated according to the annotation, the data generation policy profile, and the database description file The test data required for the program to be tested is generated. The computer program product for automatically generating software test data as described in claim 1, wherein the test program accesses the annotation through a oriented program development technology. The computer program product for automatically generating software test data according to claim 1, wherein the initialization setting is performed for data clearing, data restoration, or data reconstruction. The computer program product for automatically generating software test data according to claim 1, wherein the database description file includes a field attribute, a field data type, a field restriction condition, or an inter-column association. The computer program product for automatically generating software test data according to claim 1, wherein the database description file file comprises a plurality of database types to provide cross-database operations. A method for automatically generating software test data, providing test data to drive a test program to test a program to be tested including at least one function module, comprising the following steps: According to the label of the test program, when the function module is tested, the test data corresponding to each function module is initialized and set; and the profile, the data generation policy profile, and the database description file are automatically generated according to the label, the data generation strategy file, and the database description file. The test data required for the program to be tested. The method for automatically generating software test data as described in claim 6, wherein the test program accesses the annotation through a oriented program development technology. The method for automatically generating software test data as described in claim 6, wherein the initial setting is performed for data clearing, data recovery, or data reconstruction. The method for automatically generating software test data as described in claim 6, wherein the database description file includes a field attribute, a field data type, a field restriction condition, or an inter-column association. The method for automatically generating software test data as described in claim 6, wherein the database description file includes a plurality of database types to provide cross-database operations.