JP2013077124A - Software test case generation device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a test case for increasing defect detection efficiency.SOLUTION: A software test case generation device for generating a test case of the factor coverage test of a software test, and for generating the list of the factor coverage test includes: a storage part for storing the generated test case; a test execution history storage part for storing an execution history of the software test following the generated test case; a determination reference storage part for storing determination conditions of an attention required standard of a factor and standard whose test should be selectively executed; an attention required standard combination analysis part for determining a combination of the attention required factor and standard in accordance with the determination conditions of the attention required standard; an attention required standard combination storage part for storing an attention required standard combination as the combination of the factor and standard determined as the attention required standard; and an effective test case generation part for generating an efficient test case on the basis of the execution history of the software test and the attention required standard combination.

Description

  The present invention relates to a software test case generation apparatus.

  As background art of this technical field, there is Japanese Patent No. 2882687 (Patent Document 1). This publication states that "in a method for generating a minimum number of test cases for testing a software system with software having multiple data fields that can take multiple values, Entering values and user-defined constraints, defining multiple tables containing relevant field values, and using user-specified values for the degree of interaction between the fields, said field Generating a test case table for each of the table of values, defining a plurality of tables of non-interacting field values, and merging the test case table into a single test case table And merging the non-interactive field table with the single test case table. Method "which is characterized in that there was example has been described (see claim 1).

  As another background art, there is JP 2008-129661 A (Patent Document 2). This publication states that “the information processing apparatus associates a first correction identifier that specifies past corrections with a first function identifier that specifies a function included in the program that has been corrected by past corrections. A storage unit that stores a history table, an acquisition unit that acquires a second function identifier that specifies a function included in a program that has been corrected in a new correction, and a first in the correction history table read from the storage unit For each of the modified identifiers, the number of function identifiers that match among the one or more first function identifiers associated with the first modified identifier and the obtained one or more second function identifiers is obtained and matched. And a priority determination unit that determines the priority of the test case for testing the modification specified by the first modification identifier based on the number of function identifiers ”(see summary).

Japanese Patent No. 2882687 JP 2008-129661 A

  Patent Document 1 described above describes a test case automatic generation method for improving the efficiency of software exhaustive testing. However, in the test case automatic generation method described in Patent Document 1, the importance of each generated test case is not known.

  In such a test case automatic generation method disclosed in Patent Document 1, for example, in a software development project, the number of man-hours required for testing is limited, and it is not possible to execute all the generated comprehensive tests. There is. In this case, the test case to be executed is selected at random within the range allowed by the man-hour, and only the defect detection effect equivalent to the random test can be obtained.

  Patent Document 2 describes a method for determining the priority of a test case in a software regression test. However, the method for determining the priority of the test case described in Patent Document 2 requires that the test for which the priority is determined is executed at least once in the past.

  Such a method for determining the priority of a test case cannot determine the priority of a test case when it is necessary to execute a test on a new target. For example, when developing new software or renovating existing software in a software development project, it is necessary to test a newly or additionally developed part of the software. Since the group has not yet been executed, the priority cannot be determined.

  An object of the present invention is to provide a test case for improving defect detection efficiency when a new test case needs to be generated but only a limited number of test cases can be executed.

  In order to solve the above-described problems, an embodiment of the present invention provides a test case for improving defect detection efficiency when only a limited number of test cases can be executed. For example, it provides a test case group in which inputs that should be executed with priority on inspection are focused on, and a test case in which execution priority is given to each group.

  In one embodiment of the present invention, test priorities are also provided for newly constructed test cases.

  More specifically, a typical example of the invention disclosed in the present application is as follows. That is, an input unit to which a factor and a level of a software test are input, a factor / level storage unit that stores the input factor and level, and a test case of a factor coverage test are generated based on the stored factor and level. A software test case generation device comprising: a comprehensive test case generation unit; a list generation unit that generates a list of the generated factor coverage tests; and an output unit that outputs the generated list of tests. A storage unit for storing the test case, a test execution history storage unit for storing the execution history of the software test according to the generated test case, Judgment criteria storage unit for storing judgment conditions, and combinations of factors and levels requiring attention according to the judgment conditions for the levels requiring attention A caution level combination analysis unit for determination, a caution level combination storage unit for storing a caution level combination that is a combination of factors and levels determined as caution levels, an execution history of the software test, and the caution level combinations And an effective test case generation unit that generates an efficient test case.

  According to an embodiment of the present invention, a test case for improving defect detection efficiency can be provided.

It is a block diagram which shows the structural example of the software test case production | generation apparatus 100 in embodiment of this invention. It is a figure which shows an example of a function structure of the software test case production | generation apparatus 100 in embodiment of this invention. It is explanatory drawing of the example 600 of a test object and the example 700 of a factor and level in embodiment of this invention. It is explanatory drawing of an example of the factor and level data 710 of the test object example 600 written in the factor and level storage unit 150 in the embodiment of the present invention. It is explanatory drawing of the detailed structural example of the production | generation test case memory | storage part 160 in embodiment of this invention. It is explanatory drawing of an example of the 1 factor covering test case group 800 stored in the test case memory | storage part 1600 in embodiment of this invention. It is explanatory drawing of an example of the 2 factor coverage test case group 810 stored in the test case memory | storage part 1600 in embodiment of this invention. It is explanatory drawing of an example of the test execution result 610 in embodiment of this invention. It is explanatory drawing of an example of the test execution log | history 1700 stored in the test execution log | history memory | storage part 170 in embodiment of this invention. It is explanatory drawing of an example of the caution level combination table 1900 based on the 1 factor coverage test stored in the caution level combination memory | storage part 190 in embodiment of this invention. It is explanatory drawing of an example of the attention level combination table 1910 based on the 2 factor coverage test stored in the attention level combination memory | storage part 190 in embodiment of this invention. It is explanatory drawing of an example of the criterion data 1800 of the level of caution stored in the criterion storage part 180 in embodiment of this invention. It is a detailed functional block diagram of the effective test case production | generation part 130 in embodiment of this invention. It is explanatory drawing of an example of the model 13000 of the high defect detection efficiency test case comprised by the high defect detection efficiency test case production | generation part 1300 in embodiment of this invention. It is explanatory drawing of the example of the competition case A1 by the caution level combination extracted from the log | history of the 2 factor coverage test in embodiment of this invention. It is explanatory drawing of an example of the test case group 13010 by which the level was expand | deployed by the test case template 13000 in embodiment of this invention. It is explanatory drawing of an example of the high defect detection efficiency test case group 13020 produced | generated by the high defect detection efficiency test case production | generation part 1300 in embodiment of this invention. It is explanatory drawing of an example of the priority score 16010 of the test case calculated by the priority score calculation part 1301 in embodiment of this invention. It is explanatory drawing of an example of the priority 16020 of a test case provided by the priority provision part 1302 in embodiment of this invention. It is explanatory drawing of an example of the test check list | wrist 620 produced | generated by the test check list production | generation part 140 in embodiment of this invention. It is a flowchart which shows the procedure of the whole software test using the software test case production | generation apparatus 100 in embodiment of this invention. It is a flowchart which shows the detailed procedure of execution (step 503) of i factor covering test in embodiment of this invention. It is a flowchart which shows the detailed procedure of the analysis of a required level combination (step 505) in embodiment of this invention. It is a flowchart which shows the detailed procedure of the production | generation (step 506) of a test case with high defect detection efficiency in embodiment of this invention. It is a flowchart which shows the detailed procedure of provision of the priority (step 507) with respect to the test case in embodiment of this invention.

  Hereinafter, an example of a software test case generation apparatus 100 according to an embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 is a block diagram illustrating a configuration example of a software test case generation device 100 according to the present embodiment.

  The software test case generation apparatus 100 includes a CPU (Central Processing Unit) 101, a memory 102, an external storage device 103, a bus 104, an external interface 105, an input device 106, an output device 107, and a communication device 108. The CPU 101, the memory 102, and the external interface 105 are connected to each other via the bus 104. In addition, an external storage device 103, an input device 106, an output device 107, and a communication device 108 are connected to the external interface 105.

  The external storage device 103 holds a comprehensive test case generation program 110P, a caution level combination analysis program 120P, an effective test case generation program 130P, and a test checklist generation program 140P, which are processing programs executed by the CPU 101. Further, the external storage device 103 includes a factor / level storage unit 150, a generated test case storage unit 160, a test execution history storage unit 170, a determination criterion storage unit 180, and a caution level combination storage unit 190. Each of these storage units is a storage area in which data is stored.

  In the present embodiment, the example in which the software test case generation device 100 is mounted on one computer has been described. However, even if the software test case generation device 100 is mounted on a computer system including a terminal and a server, You may implement in the computer system comprised by a some computer resource.

  FIG. 2 is a diagram illustrating an example of a functional configuration of the software test case generation device 100.

  In the software test case generation apparatus 100, an exhaustive test case generation program 110P, a caution level combination analysis program 120P, an effective test case generation program 130P, and a test checklist generation program 140P are respectively executed by the CPU 101 and stored in the memory 102. The expanded test case generation unit 110, the attention level combination analysis unit 120, the effective test case generation unit 130, and the test check list generation unit 140 are expanded.

  The effective test case generation unit 130 includes a high defect detection efficiency test case generation unit 1300, a priority score calculation unit 1301, and a priority order assignment unit 1302 (see FIG. 13).

  The factor / level storage unit 150 stores factors and levels for testing the software. The factor is the type of parameter and element to be tested by the software, and the level is a value or a representative value that can be input to the factor. In the present embodiment, the factor / level information includes a test target factor name 701 and a level name 702 (see FIG. 3). The factor / level information is input via the input device 106 and the communication device 108 and stored in the factor / level storage unit 150.

  FIG. 3 is an explanatory diagram of an example 600 to be tested and an example 700 of factors / levels.

  A test target example 600 illustrated in FIG. 3 is a GUI (Graphical User Interface) displayed on the output device 107 of the software test case generation device 100. The test target example 600 is a screen that waits for input of each information of the name 601, the telephone number 602, the date of birth 603, and the address 604 from the user.

  The factor / level example 700 describes factors and levels related to the information of the name 601 in the test target example 600 described above. In the factor / level example 700, a factor name 700 (name) and a level 702 (positive value, null value, half-width, long sentence, no blank) of the factor are input.

  FIG. 4 is an explanatory diagram of an example of factor / level data 710 for the test target example 600 written in the factor / level storage unit 150.

  The factor name 711 and the level 712 of the record 713 are associated with the factor name 700 and the level 702 for the name information 601 in FIG. A record 714, a record 715, and a record 716 are examples of factors and levels for the telephone number information 602, the date of birth information 603, and the address information 604 in FIG. Hereinafter, this embodiment will be described using the example shown in FIG.

  Returning to FIG. 2, the generated test case storage unit 160 will be described. The generated test case storage unit 160 stores the test cases generated by the comprehensive test case generation unit 110 through the effective test case generation unit 130 based on the factor / level data stored in the factor / level storage unit 150.

  FIG. 5 is an explanatory diagram of a detailed configuration example of the generated test case storage unit 160.

  The generated test case storage unit 160 includes a test case storage unit 1600, a priority score storage unit 1601, and a priority order storage unit 1602. Details of data stored in the priority score storage unit 1601 and the priority order storage unit 1602 in the generated test case storage unit 160 will be described later together with the processing of the effective test case generation unit 130.

  Hereinafter, the test case storage unit 1600 that stores the test cases generated by the comprehensive test case generation unit 110 will be described.

  FIG. 6 is an explanatory diagram of an example of the one-factor-coverage test case group 800 stored in the test case storage unit 1600.

  The test case storage unit 1600 includes a test case identifier 801 and a test case 802. Record 803 shows that the test case with the test case identifier “1” has a factor “name” of “positive value”, a factor “phone number” of “positive value”, and a factor “birth date” of “birth date”. It shows that the test is executed with a combination of values having a positive value and a factor “address” level of “positive value”.

  One-factor coverage means that a test is executed at least once for the level of each factor to be tested depending on the test case group to be executed. In the example 800 of the test case group, the test case is assigned once for each level of each factor (name, phone number, date of birth, address), so that one factor is covered.

  FIG. 7 is an explanatory diagram of an example of the two-factor coverage test case group 810 stored in the test case storage unit 1600.

  The term “two-factor coverage” means that the test is executed at least once for each level of each of the two factors included in the combination of the two factors of the test target factors depending on the test case group to be executed. That is, any combination of two factors (name-phone number, name-date of birth, name-address, phone number-date of birth, phone number-address, date of birth-address) was extracted from the test case group 810. However, the combination of levels included in the two factors appears at least once. For example, in the case of a combination of name and phone number, the five levels (positive value, null value, half-width, long sentence, no blank) that the name has and the five levels possessed by the phone number (positive value, null value, full-width, small digit, Each of the 25 combinations of digits) is to be tested at least once.

  Similarly, the n-factor coverage test includes n factors included in a combination of n factors of test target factors (n is an integer not exceeding the number of factors included in the test target 600) depending on the test case group to be executed. It means that the test is performed at least once for the combination of levels.

  The coverage test case generation unit 110 generates the above-described n-factor coverage test based on the factor / level storage unit 150 and the number of factor coverages. As a specific generation means, the technique disclosed in Patent Document 1 can be used.

  Returning to FIG. 2, the test execution history storage unit 170 will be described. The test execution history storage unit 170 is based on the test checklist generated by the test checklist generation unit 140 based on the test cases stored in the test case storage unit 1600 of the generated test case storage unit 160. Store the result of the operation. The test execution result is input via the input device 106 and the communication device 108 and written to the test execution history storage unit 170.

  The test execution history includes a test case identifier 1701, test result information 1703, test countermeasure information 1704, and cause level information 1705 (see FIG. 9).

  FIG. 8 is an explanatory diagram of an example of the test execution result 610.

  The example of the test execution result 610 shown in FIG. 8 is an execution of a test case written by the user in the test checklist generated by the test checklist generation unit 140 based on the one-factor comprehensive test case group 800 shown in FIG. The result is recorded.

  The test case ID 611 is an identifier for associating with a test case stored in the test case storage unit 1600. The test case 612 describes the test case stored in the test case storage unit 1600 so that the user can easily use it. The test result 613 indicates whether or not a defect is detected as a result of executing the test case. In this example, “◯” indicates that no defect is detected, and “X” indicates that a defect is detected.

  The defect countermeasure 614 indicates whether countermeasures such as investigation of the cause and correction of the defect extracted by the test case have been completed. The cause level 615 indicates which level of which factor in the test case extracted by the test case reproduces the defect. In this example, in order to easily specify the cause level, each level No. 616, and the level No. The level is designated by 616. The cause level 615 includes, for example, a plurality of level Nos. With brackets (“[]”). By summarizing, it is possible to specify a case where a defect is reproduced by a combination of a plurality of levels. A plurality of levels and combinations of levels can be designated as the cause level 615.

  In this embodiment, the test check list generation unit 140 generates a test check list to be input in order to eliminate an error in association between user convenience and a test. However, a test tech list may be created by referring to the test case storage unit 1600 without using the test check list generation unit 140 and input to the test execution history storage unit 170.

  FIG. 9 is an explanatory diagram of an example of the test execution history 1700 stored in the test execution history storage unit 170.

  The test case identifier 1701 is information for associating with a test case stored in the test case storage unit 1600. The test case information 1702 is specific contents of the test case. In the example shown in FIG. 9, for the sake of explanation, specific test case information 1702 is included in the test execution history storage unit 170. However, if the test case storage unit 1600 is referred to by the test case identifier 1701, the test case information 1702 Information 1702 may not be included. The test result information 1703 is associated with the test result 613 (see FIG. 8). The test countermeasure information 1704 is associated with a defect countermeasure 614 (see FIG. 8). The cause level information 1705 is associated with the cause level 615 (see FIG. 8).

  Returning to FIG. 2, the caution level combination storage unit 190 will be described. The caution level combination storage unit 190 stores a caution level combination table 1900 that the caution level combination analysis unit 120 generates for each factor-coverage test case group based on the test execution history storage unit 170 and the judgment criterion storage unit 180. The

  FIG. 10 is an explanatory diagram of an example of the caution level combination table 1900 based on the one-factor coverage test stored in the caution level combination storage unit 190.

  The caution level combination table 1900 includes a combination factor 1901, a combination level 1902, a defect score 1903, and a caution level flag 1904.

  The combination factor 1901 identifies a combination of n factors in an n factor coverage test case. Since this example is intended for a one-factor coverage test, each factor is described. The combination level 1902 identifies combinations of levels that can be taken in the combination factor 1901. Since this example is intended for a one-factor coverage test, the level of each factor is described. The defect score 1903 is obtained by scoring the number of defects detected by the combination level 1902. This is the result of calculating the number of defects for the level that is a subset in the combination level 1902 and totaling the number for each combination factor. In the example shown in FIG. 10, since the one-factor coverage test is targeted, only the score of the one-factor combination defect is shown. The caution level 1904 is a flag indicating a level determined as a caution level combination.

  FIG. 11 is an explanatory diagram of an example of a caution level combination table 1910 based on the two-factor coverage test stored in the caution level combination storage unit 190.

  The combination factor 1901 is a combination of two factors, and the combination level 1902 is a combination of levels included in the two factors. Further, the defect score 1903 has a score calculated from the two-factor defect 1911 by the combination of the two levels shown in the combination level 1902 and a score calculated from the one-factor defect 1912 by each level constituting the combination level 1902. .

  Returning to FIG. 2, the criterion storage unit 180 will be described. The criterion storage unit 180 stores criteria for determining the level of caution input from the input device 106 and the communication device 108 in advance.

  FIG. 12 is an explanatory diagram of an example of the criterion data 1800 for the level of caution stored in the criterion storage unit 180.

  The determination criterion data 1800 includes a factor coverage 1801 and a determination condition 1802.

  The factor coverage 1801 is the factor coverage of the test case group targeted by the test execution history stored in the test execution history storage unit 170. The determination condition 1802 is a conditional expression and a threshold value for the attention level combination analysis unit 120 to be described later to determine the attention level based on the defect score 1903 of the combination level 1902 of the attention level combination storage unit 190. For example, if the coverage test executed immediately before and the result is recorded is a one-factor coverage test, the record 1803 is determined to have a one-factor defect score of 1 or more in the attention level combination storage unit 190 as the attention level. It shows the criterion of being.

  Returning to FIG. 2, the caution level combination analysis unit 120 will be described. The caution level combination analysis unit 120 generates a caution level combination table based on the number of factors n of the n factor comprehensive test that is currently targeted. The generated caution level combination table is stored in the caution level combination storage unit 190.

  The caution level combination analysis unit 120 reads the test execution history 1710 from the test execution history storage unit 170 and calculates a defect score 1903 for each level combination 1902 of the caution level combination table. For example, a combination of levels specified in the cause level 1705 of the test execution history 1700 (see FIG. 9) (the factor “name” level “null”, the factor “name” level “half-width”, the factor “date of birth” ”Level“ full-width ”and factor“ birth date ”level“ future ”) are counted and recorded in the defect score 1903, respectively.

  The attention level combination analysis unit 120 reads the determination criterion 1800 from the determination criterion storage unit 180, extracts the attention level combination based on the determination condition 1802, and sets the attention level combination flag 1904 of the attention level combination table 1900. . For example, in the one-factor coverage test described as the embodiment, a record 1803 having a factor coverage of one factor is selected in the criterion 1800 (see FIG. 12). According to the record 1803, the determination condition is that the score of the one-factor defect in the caution level combination table 1900 is 1 or more (one-factor defect ≧ 1). Therefore, the judgment condition scans the caution level combination table 1900, and the four records satisfying the conditions (combination factor “name” -combination level “null value”, combination factor “name” -combination level “half-width”, combination factor “ The caution level combination flag 1904 is set for "birth date" -combination level "double-byte", combination factor "birth date" -combination level "future").

  In this embodiment, the attention level combination is distinguished by the method of setting the attention level combination flag 1904. However, even if the attention level combination is distinguished by creating a table in which only the attention level combinations are extracted. Good.

  The caution level combination analysis unit 120 writes the obtained caution level combination table 1900 in the determination criterion storage unit 180.

  FIG. 13 is a detailed functional block diagram of the effective test case generation unit 130. The effective test case generation unit 130 includes a high defect detection efficiency test case generation unit 1300, a priority score calculation unit 1301, and a priority order assignment unit 1302.

  The high defect detection efficiency test case generation unit 1300 reads the caution level combination table 1900 from the caution level combination storage unit 190, and configures a two-factor coverage test using the extracted caution level combinations as new factors and levels. A high defect detection efficiency test case template 13000 is created. Note that the coverage test case generation unit 110 may constitute a two-factor coverage test. For the levels of factors for which a combination of levels of caution is not obtained, don't care (*) is assigned so that as many levels as possible are included.

  FIG. 14 is an explanatory diagram of an example of a high defect detection efficiency test case template 13000 configured by the high defect detection efficiency test case generation unit 1300.

  In the name 13001 and the date of birth 13002, two levels (“empty value” and “half-width”) of the factor “name”, which are the combination of caution levels in the caution level combination table 1900 (see FIG. 10), and the factor “birth year” A two-factor comprehensive combination of two levels (“full-width” and “future”) is described. Further, since the telephone number 13003 and the address 13004 did not have a caution level combination in the caution level combination table 1900, don't care is assigned.

  The high defect detection efficiency test case generation unit 1300 divides the test case combination when a level conflict occurs in the test case when the high defect detection efficiency test case template 13000 is created.

  FIG. 15 is an explanatory diagram of an example of a competition case A1 based on a combination of caution levels extracted from the history of the two-factor coverage test.

  Case A1 is an example of combination of “empty value—full-width” and “small digit—future” as the level of caution from the two-factor combinations “name-phone number” and “phone number-birth date”, respectively. is there. Here, when this level combination is expanded and the test case template A1-1 created is focused on, it is impossible to test two different levels of “double-byte” and “digit-small” in the factor of the telephone number. A test case is obtained. Such a case is called a competition case. Therefore, a case composed of level combinations that cannot be compatible, such as case A-2, is divided into level combinations that do not conflict, and don't care is inserted. By expanding the case A2 divided in this way to individual levels, a test case template A2-1 having no competition is obtained.

  The high defect detection efficiency test case generation unit 1300 reads the factor group level from the factor / level storage unit 150 for the factor group in which the don't care of the test case template 13000 is inserted, and uses the comprehensive test case generation unit 110. Generate a one-factor level coverage test and deploy it to the don't care section. As a result, a test case 13010 in which levels are inserted into all factor groups is obtained.

  FIG. 16 is an explanatory diagram of an example of a test case group 13010 in which levels are developed in the test case template 13000.

  The record group 13011 is a result of inserting the level of “address” of “phone number” into the record 13005 of the test case template 13000 (see FIG. 14). For example, the high defect detection efficiency test case generation unit 1300 selects the record 1305 in which the don't care is inserted from the test case template 13000. Next, the level of each factor (“phone number” and “address”) in which don't care is inserted is read from the factor / level data 710 of the factor / level storage unit 150. With respect to the read factors, a one-factor coverage test is generated using the coverage test case generation unit 110. Thereafter, each combination (5 cases) of the generated one-factor coverage test is inserted into the don't care portion of the record 1305.

  The high defect detection efficiency test case generation unit 1300 refers to the generated test case 13010 with reference to the test execution history 1700 in the test execution history storage unit 170, and the safety of the test case is confirmed by a comprehensive test performed in advance. Remove.

  For example, the record 13012 is deleted because it is a test executed with “3” of the test case identifier 1701 of the test execution history 1700. For example, the high defect detection efficiency test case generation unit 1300 includes the level of each factor (factor “name” level “half-width”, factor “phone number” level “full-width”, factor “date of birth” level “full-width”. The test execution history 1700 is searched using the factor “address” level “half-width”) as a key, and it is determined whether or not the generated test case has already been executed based on whether or not there is a matching record.

  The high defect detection efficiency test case generation unit 1300 writes the high defect detection efficiency test case group 13020 generated and removed from the existing test case into the test case storage unit 1600 of the generation test case storage unit 160.

  FIG. 17 is an explanatory diagram of an example of a high defect detection efficiency test case group 13020 generated by the high defect detection efficiency test case generation unit 1300.

  By the test case generation by the high defect detection efficiency test case generation unit 1300 described above, it becomes possible to focus on the test on the level for inspecting the function that is weak in the combination and has the potential defect. . In addition, it is possible to eliminate test cases that have been corrected and confirmed to be safe as a result of the inspection. This improves the efficiency with which defects are extracted by testing.

  Returning to FIG. 13, the priority score calculation unit 1301 will be described. The priority score calculation unit 1301 refers to the caution level combination table 1900 of the caution level combination storage unit 190, and for each test case stored in the test case storage unit 1600 of the generated test case storage unit 160, the priority score 16010 Is calculated. The calculated priority score 16010 is written in the priority score storage unit 1601.

  FIG. 18 is an explanatory diagram of an example of the test case priority score 16010 calculated by the priority score calculation unit 1301.

  A priority score 16010 is calculated for each test case stored in 1600. For example, in this embodiment, the priority score is indicated by the number of attention level combinations 16011, the first required attention level-non-caution level combination number 16012, and the first appearance level combination number 16013 as the priority score 16010. Hereinafter, each score will be described using the record 16014 as an example in the situation where the one-factor coverage test is completed.

  The caution level combination number 16011 is a score indicating how many caution level combination numbers are included in the level included in the test case. The priority score calculation unit 1301 reads the attention level combination table 1900 from the attention level combination storage unit 190 and calculates the priority score by counting the number of level combinations that match the record 16014. Since the record 16014 includes the “null value” of the name and the “full-width” of the date of birth, the score is 2.

  The number of initial required attention level-non-critical level combination 16012 indicates that the combination of the level to be tested for the first time and the normal level not selected as the level of attention is included in the level combinations included in the test case. A score indicating how many exist. In this example, since the one-factor combination has been completed, two-level combinations are targeted. The priority score calculation unit 1301 reads the caution level combination table 1900 from the caution level combination storage unit 190, classifies the levels included in the test case into the caution level and the caution level, and requires the caution level and the caution level. Calculate the combination of caution levels. It is searched whether or not the obtained caution level and caution level are included in the test execution history 1700 of the test execution history storage unit 170, and the number of caution level-non-caution level combinations that appear for the first time is calculated. To do. In record 16014, the name “null” and the phone number “positive”, the name “null” and the address “positive”, the date of birth “double-byte” and the phone number “positive”, and The “full-width” date of birth and the “positive value” of the address are targeted, and the score is 4.

  The first appearance level combination number 16013 is a score indicating how many combinations of levels are tested for the first time among the level combinations included in the test case. In this example, since the one-factor combination has been completed, two-level combinations are targeted. The priority score calculation unit 1301 searches the test execution history storage unit 170 for the test execution history 1700 for each combination of levels included in the test case, and determines whether it is the first appearance. In record 16014, the name “null” and the phone number “positive”, the name “null” and the address “positive”, the date of birth “full-width” and the phone number “positive”, the date of birth The “full-width” of the day and the “positive value” of the address, the “positive value” of the telephone number, and the “positive value” of the address are targeted, and the score is 5.

  In addition, the priority score of a present Example is an example, Comprising: It is not the meaning limited to the priority score mentioned above.

  The priority score calculation unit 1301 writes the calculated priority score 16010 in the priority score storage unit 1601 of the generated test case storage unit 160.

  Returning to FIG. 13, the priority level assigning unit 1302 will be described. The priority level assigning unit 1302 reads the priority score 16010 stored in the priority score storage unit 1601 of the generated test case storage unit 160, calculates the priority level, and calculates the calculated priority level in the test of the generated test case storage unit 160. The test case group is stored in the case storage unit 1600 and stored in the priority storage unit 1602.

  FIG. 19 is an explanatory diagram of an example of test case priority order 16020 assigned by the priority order assigning unit 1302.

  In this embodiment, the number of attention level combinations 16011, the first required attention level-non-required attention level combination number 16012, and the first appearance level combination number 16013 calculated by the priority score calculation unit 1301 and stored in the priority score storage unit 1601 are used. To calculate the priority. For example, the order of evaluation of each priority score is set as “Needs Attention Level Combination Number 16011> First Attention Required Level—Non-Attention Level Combination Number 16012> First Attach Level Combination Number 16013”. That is, in the ranking of test cases, the ranking is based on the magnitude relationship of the number of required attention level combinations 16011. In the case of the same ranking, the ranking is given by the first appearance level combination number 16013.

  Note that the prioritization method of this embodiment is merely an example, and is not intended to limit the above-described method. For example, the rank may be determined by the sum of the scores, or the rank may be determined by a weighted average of each score.

  The priority level assigning unit 1302 writes the calculated priority level 16020 in the priority level storage unit 1602.

  As described above, by calculating the priority of each test case by the priority assigning unit 1302, it is presumed that the defect detection efficiency of which test case is high within the limited test period, and the priority is tackled. Since it is clarified whether or not it should be, it is possible to improve the efficiency of defect detection particularly at the time of test start-up.

  Returning to FIG. 2, the test checklist generation unit 140 will be described. The test checklist generation unit 140 reads the test case group stored in the test case storage unit 1600 of the generated test case storage unit 160 and the priority order 16020 stored in the priority order storage unit 1602, and the test checklist 620 And output via the input device 106 and the communication device 108.

  FIG. 20 is an explanatory diagram of an example of the test check list 620 generated by the test check list generation unit 140. By assigning a priority 16020 to each test case (record 621) and sorting the test cases based on the priority 16020, it is possible to implement from a test case with a high priority.

  The test checklist 620 may be in a format that can be visually recognized by the user or in a format that can be executed by a computer.

  Next, a procedure of processing executed by the software test case generation device 100 having the configuration as described above will be described.

  FIG. 21 is a flowchart showing a procedure of the entire software test using the software test case generation device 100.

  FIG. 3 is an explanatory diagram of the test target example 600 and the factor / level example 700, and shows an example of a file input to the software test case generation apparatus 100. FIG. 8 is an example of the test execution result 610 and shows an example of a file input to the software test case generation device 100. FIG. 20 is an example of a test checklist 620 generated by the test checklist generation unit 140, and shows an example of an output file of the software test case generation device 100. The input and output to the software test case generation apparatus 100 will be mainly described with reference to FIGS. 3, 8, 20, and 21.

  In step 501, for the purpose of software testing, the developer creates factors for the test target and the levels of each factor, and inputs them to the software test case generation device 100 via the input device 106 to the communication device 108. . Factor / level input information 700 is shown as an example of factors / levels for the input data item 601 included in the test target screen 600 shown in FIG. Here, as the input information 700, a factor name 701 (name) and a level 702 (positive value, null value, half-width, long sentence, no blank) for the factor are created.

  Although description is omitted, factor names 701 and levels 702 are similarly created for other input data items (phone number 602, date of birth 603, address 604) of the test target screen 600.

  In step 502, the factor / level input information 700 is stored in the factor / level storage unit 150 as factor / level data 710.

  In step 503, the initial value of the number of coverage factors i is set to 1, and based on the factor / level data 710, the software test case generation device 100 generates an i-factor coverage test, and the developer executes the generated test. Further, the test execution result 610 is input to the software test case generation apparatus 100. The test case generated in step 503 is a test case 612 indicated by reference numeral 612 in FIG. 8, and test execution results input by the developer are input fields 613 to 615. Detailed processing in step 503 will be described later with reference to FIG.

  In step 504, the time required to execute the i + 1 factor coverage test is estimated, and it is determined whether the execution of the i + 1 factor coverage test can be completed in the remaining test period. If it is determined that all the test cases of the i + 1 factor coverage test can be executed, 1 is added to the number i of the coverage factors, and the process returns to step 503 to determine that all the test cases of the i + 1 factor coverage test are not executable. If so, the process proceeds to step 505.

  Note that the test plan time is input in advance, and the time taken to execute each test case is acquired in the test execution history, so that this determination is executed by the software test case generation device 100 in the determination of step 504. can do. Note that the user may determine whether the execution of the i + 1 factor coverage test can be completed.

  In step 505, based on the test execution result 610 input in step 503, a caution level combination table 1900 (see FIG. 10) is generated, and caution level combinations that are considered to require testing are analyzed and extracted. To do. Detailed processing in step 505 will be described later with reference to FIG.

  In step 506, based on the factor / level data 710, the test execution result 610, and the caution level combination table 1900, a high defect detection efficiency test case group 13020 (see FIG. 17), which is a test case with high defect detection efficiency. Generate. Detailed processing in step 506 will be described later with reference to FIG.

  In step 507, priority 16020 (see FIG. 19) is assigned to each test case of the high defect detection efficiency test case group 13020 based on the test execution result 610 and the caution level combination table 1900. Detailed processing in step 507 will be described later with reference to FIG.

  In step 508, based on the high defect detection efficiency test case group 13020 to which the priority 16020 is assigned, the test cases are rearranged in order of priority, and an efficient test checklist in which the priority is described in the test case is generated, and the output device 107 and the communication device 108. The test case generated and output in step 508 is the efficient test checklist 620 of FIG. The test cases are sorted according to the priority of the record 621, and the priority of each test case can be visually confirmed.

  In step 509, using the efficient test checklist 620, the user executes a test to detect a defect and implements a countermeasure against the defect.

  By using the software test case generation device 100 of the present embodiment, it is possible to provide a test case for improving defect detection efficiency in software testing.

  Next, details of the processing in step 503 will be described.

  FIG. 22 is a flowchart showing a detailed procedure for executing the i-factor coverage test.

  First, the coverage test case generation unit 110 reads the factor / level data 710 input and stored by the user from the factor / level storage unit 150 (step 5031).

  The coverage test case generation unit 110 generates an i-factor coverage test case group from the information read in Step 5031 (Step 5032).

  The coverage test case generation unit 110 writes the i-factor coverage test case group generated in step 5032 in the test case storage unit 1600 of the generation test case storage unit 160. (Step 5033).

  The test checklist generation unit 140 generates a test checklist based on the test case group written in the test case storage unit 1600 in step 5033, and outputs the test checklist via the output device 107 and the communication device 108 (step 5034).

  Thereafter, the i-factor coverage test is executed according to the test check list output in step 5034, and the execution result is entered in the test check list. When a defect is extracted by the test, it is analyzed by which level or combination of levels the defect is reproduced, the defect is corrected, and the result is entered in a check list (step 5035).

  Thereafter, the test execution result 610 created in step 5035 is input (step 5036).

  Note that the processing of steps 5035 and 5036 may be performed by the user.

  The test execution history storage unit 170 stores the test execution result 610 input by the user as a test execution history (step 5037).

  Next, details of the processing in step 505 will be described.

  FIG. 23 is a flowchart showing a detailed procedure for analyzing the level of attention combination.

  First, the caution level combination analysis unit 120 reads the factor / level data 710 from the factor / level storage unit 150, and generates an i-factor caution level combination table 1900 corresponding to the i factor comprehensive test executed immediately before. (Step 5051).

  The attention level combination analysis unit 120 reads the test execution history 1700 from the test execution history storage unit 170 (step 5052).

  The attention level combination analysis unit 120 calculates a defect score 1903 for each level combination of the attention level combination table 1900 generated in step 5051 based on the test execution history 1700 read in step 5052 and writes the defect score 1903 in the table 1900. (Step 5053).

  The attention level combination analysis unit 120 searches and reads the determination condition 1802 from the determination criterion storage unit 180 using the coverage factor degree “i-factor” of the i-factor coverage test executed immediately before as a key (step 5054).

  The caution level combination analysis unit 120 scans the caution level combination table 1900 in which the defect score 1903 is written in step 5053 based on the determination condition read in step 5054, and the level combination determined as the caution level combination. A caution level flag 1904 is set to determine a caution level combination (step 5055).

  The caution level combination analysis unit 120 writes the caution level combination table 1900 in which the caution level is determined in step 5055 to the caution level combination storage unit 190 (step 5056).

  Next, details of the processing in step 506 will be described.

  FIG. 24 is a flowchart showing a detailed procedure for generating a test case with high defect detection efficiency.

  First, the high defect detection efficiency test case generation unit 1300 of the effective test case generation unit 130 reads the caution level combination table 1900 of the number of factors i corresponding to the i factor comprehensive test executed immediately before (step 5061). .

  The high defect detection efficiency test case generation unit 1300 takes out the factor combination and the attention level combination in which the attention level combination exists from the attention level combination table 1900 read in step 5061, and the attention level combination exists. The factor combination is defined as a new factor, and the caution level combination group accompanying it is defined as a new level, and the test case template 13000 that covers the caution level combination is generated using the coverage test case generation unit 110. At this time, don't care (*) is inserted for a factor that does not have a level of caution (step 5062).

  For the test case template 13000 generated in step 5062, the high defect detection efficiency test case generation unit 1300, when the level combination is expanded into a test case, the test value of the test case template becomes incapable of test execution due to conflicting level values. The test case is divided to avoid conflict (step 5063).

  The high defect detection efficiency test case generation unit 1300 develops a level for the test case template 13000 obtained by the processing up to step 5063. For factors that include don't care, a one-factor comprehensive test case is developed. In this way, a test case group 13010 is generated (step 5064).

  The high defect detection efficiency test case generation unit 1300 refers to the test execution history 1700 of the test execution history storage unit 170 and determines whether or not there is an already executed test case in the test case group generated in step 5064. If there is an already executed test case, it is deleted from the test case group (step 5065).

  The high defect detection efficiency test case generation unit 1300 writes the high defect detection efficiency test case group 13020 obtained by the processing up to step 5065 in the test case storage unit 1600 of the generation test case storage unit 160 (step 5066).

  Next, details of the processing in step 507 will be described.

  FIG. 25 is a flowchart showing a detailed procedure for assigning priorities to test cases.

  First, the priority score calculation unit 1301 of the effective test case generation unit 130 reads a test case group from the generation test case storage unit 160 (step 5071).

  The priority score calculation unit 1301 reads out in step 5071 based on the attention level combination table 1900 stored in the attention level combination storage unit 190 and the test execution history 1700 stored in the test execution history storage unit 170. A priority score 16010 for each test case in the test case group is calculated (step 5072).

  The priority score calculation unit 1301 writes the priority score 16010 calculated in step 5072 to the priority score storage unit 1601 of the generated test case storage unit 160 (step 5073).

  Next, the priority level assigning unit 1302 of the effective test case generation unit 130 reads the priority score 16010 calculated for each test case in step 5073 from the priority score storage unit 1601 (step 5074).

  In this embodiment, the priority score calculation unit 1301 and the priority order assigning unit 1302 exchange the priority score 16010 via the priority score storage unit 1601, but the priority score calculation unit 1301 and the priority order assignment unit 1302 The priority score 16010 may be exchanged in cooperation with each other.

  The priority level assigning unit 1302 evaluates the priority score read in Step 5074 and determines the priority level 16020 of each test case (Step 5075).

  The priority level assigning unit 1302 writes the priority level 16020 determined in Step 5075 in the priority level storage unit 1602 of the generated test case storage unit 160 (Step 5076).

  The above-described embodiments are examples for explaining the present invention, and are not intended to limit the scope of the present invention to the illustrated embodiments. For example, the above-described embodiment has been described in detail for easy understanding of the present description, and is not necessarily limited to one having all the configurations described.

  The above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them, for example, with an integrated circuit. In addition, each of the above-described configurations, functions, and the like may be realized by software by a processor executing a program that realizes each function. Information such as programs, tables, and files that realize the above-described functions can be stored in a memory, a storage device such as a hard disk or SSD (Solid State Drive), or a storage medium such as an IC card, SD card, or DVD. Can be loaded from these storage media into the computer and executed by the processor.

  Further, only control lines and information lines that are considered necessary for explanation are shown, and control lines and information lines necessary for products are not always shown. In practice, it may be considered that almost all configurations are connected to each other.

100 Software Test Case Generation Device 101 CPU
102 Memory 103 External Storage Device 104 Bus 105 External Interface 106 Input Device 107 Output Device 108 Communication Device 110 Coverage Test Case Generation Unit 120 Caution Level Combination Analysis Unit 130 Effective Test Case Generation Unit 140 Test Check List Generation Unit 150 Factor / Level Storage unit 160 Generated test case storage unit 170 Test execution history storage unit 180 Determination criterion storage unit 190 Caution level combination storage unit

Claims (5)

An input unit for inputting factors and levels of a software test, a factor / level storage unit for storing the input factors and levels, and a coverage test for generating a test case of a factor coverage test based on the stored factors and levels A software test case generation device including a case generation unit, a list generation unit that generates a list of the generated factor coverage tests, and an output unit that outputs the generated list of tests,
A storage unit for storing the generated test case;
A test execution history storage unit for storing an execution history of a software test according to the generated test case;
A criterion storage unit for storing factors to be subjected to the test and the criteria for determining the level of caution, and
A caution level combination analysis unit for determining a combination of factors and levels requiring attention according to the conditions for determining the level of caution;
A caution level combination storage unit for storing a combination of caution levels that is a combination of factors and levels determined as caution levels;
An effective test case generation unit that generates an efficient test case based on the execution history of the software test and the attention level combination, and a software test case generation device.   The effective test case generation unit includes a high defect detection efficiency test case generation unit that generates a test case with high defect detection efficiency based on the execution history of the software test and the attention level combination. The software test case generation device according to claim 1.   The high defect detection efficiency test case generation unit generates a test case including at least a part of a combination of a factor and a level in which defects are found in a past test with reference to the execution history of the software test. The software test case generation device according to claim 2.   The effective test case generation unit includes a priority score calculation unit that calculates an execution priority score of a software test based on the execution history of the software test and the attention level combination, and software based on the calculated execution priority score 4. The software test case generation device according to claim 1, further comprising: a priority order assigning unit that determines a test execution order. 5.   The priority score calculation unit tests the number of caution level combinations indicating the number of caution level combinations included in a test case, a combination of a caution level to be tested for the first time and a normal level that is not a caution level. The execution priority score is calculated based on the number of first attention required level indicating the number included in a case-the number of combinations not requiring attention level and the number of first appearance level combinations indicating the number of combinations of the first tested level. The software test case generation device according to claim 4.

Images