JP2003099283A - Test priority derivation support method for software system, test case designing support method, and its support program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a test case designing support method for a software system which can test important functions preferentially and selectively. SOLUTION: The test case designing support method has a specifications item characteristic value setting process of setting characteristic values based upon evaluation viewpoints of the system by specifications items extracted from specifications of the software system, a test strategy generating process of generating test strategies defining which of the evaluation viewpoints importance is attached to, a test strategy selecting process of selecting a test strategy to be applied to a test of the software system among the generated test strategies, a test priority deriving process of deriving test priority for determining specifications items to be tested preferentially according to the set characteristic values and the selected test strategy, and a test case designing process of designing a test case according to the test priority.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a test technique and a verification technique for improving the reliability of a software system, and a method and a program for supporting the design of a test case for efficiently performing these tests and verifications. Regarding

[0002]

2. Description of the Related Art Conventionally, software testing technology has been widely used to guarantee the reliability of software systems. In software testing technology, what kind of test case is used for the software to be tested is important, and the reliability and quality of the software guaranteed by the test greatly differ depending on whether the test case is good or bad.

The test case needs to be designed so as to comprehensively test the functions of the target software, but recent software systems have become large-scale and complicated, so that all the functions are comprehensively tested. Requires a huge number of man-hours to digest a huge number of test cases. On the other hand, there is a limit to the development period that can be devoted to software system development, so it is almost impossible to do everything in a limited time. Therefore, prioritize the parts to be tested according to criteria such as reliability and importance,
It is necessary to design a sufficient number of efficient test cases by changing the level of detail of the test cases depending on the priority.

What is important here is a method for determining the priority of the test. For this, Japanese Patent Laid-Open No.
-212387 gazette measures the quality of the module which comprises a program by the fixed metric,
There is a technique for determining the debug order of modules in combination with a criterion that is the importance of metrics.

This prior art focuses on measuring the quality of the program module from the internal structure of the program in order to determine the debug order. However, in software testing, it is necessary to design a test case from the system specification regardless of the structure of the program and test whether the system is operating as described in the specification. Also, from the aspect of shortening the system development period, it is desirable to design test cases from system specifications in parallel with program development. However, in the related art, the quality cannot be measured until the completion of the program, so that it is difficult to apply it to software testing for designing test cases from specifications.

Further, in the prior art, the setting of the judgment criteria for deciding which metric to emphasize is left to the judgment of the programmer. However, in large-scale and complex software system testing, efficient testing is realized unless these judgment criteria are intentionally set as a test strategy depending on the characteristics of the system under test, the test environment, and the resources to be tested. Is difficult

[0007]

As described above, in the conventional technology, the debug priority is determined based on the program structure, and the characteristics of the system are determined by the materials that can be judged from the initial stage of development such as the system specifications. It is difficult to judge and prioritize tests. Furthermore, in order to determine the test priority in testing large-scale and complex software systems, it is important to set the weighting of which metric is important as a test strategy based on the characteristics of the system. In the conventional technology, the programmer is left to make the judgment regarding the setting of the test strategy.

Therefore, in the present invention, in order to efficiently design a test case in software testing, by using a material such as a system specification that can be judged from an early stage of development, the characteristics of the system can be achieved without waiting for the completion of the program. And provide a means to select an appropriate test strategy for the system, so that the test priority for determining whether the function is important for quality or not is more suitable for the system characteristics and test environment. Methods and programs that support the design of test cases so that important functions can be selected according to the environment and situation surrounding the test and priority and focus can be tested. Is.

[0009]

In order to solve the above problems, according to the present invention, a specification item characteristic for setting a characteristic value based on an evaluation viewpoint of the system for each specification item extracted from a specification of a software system. A value setting step and a test strategy creating step that creates a test strategy that defines which of the evaluation viewpoints should be emphasized, and a test strategy that is applied to the testing of the software system among the created test strategies is selected. And a test priority derivation step of deriving a test priority for determining the specification item for preferentially executing the test from the set characteristic value and the selected test strategy. Provided is a test priority derivation support method and a support program therefor.

Further, according to the present invention, the specification item characteristic value setting step of setting the characteristic value based on the evaluation viewpoint of the system for each specification item extracted from the specification of the software system, and the evaluation viewpoint can be selected. A test strategy creating step of creating a test strategy that defines whether to emphasize, a test strategy selecting step of selecting a test strategy to be applied to a test of the software system among the created test strategies, and the set characteristic A test priority derivation step of deriving a test priority for determining the specification item to execute the test preferentially from a value and the selected test strategy, and designing a test case based on the test priority A test case design support method and a support program therefor are provided.

According to the present invention described above, the characteristics of the system can be expressed without waiting for the completion of the program by using the metrics such as the system specification which can be judged from the early stage of the development, and the test strategy suitable for the system can be expressed. By providing a means for selecting, it has become possible to derive the test priority for judging whether the function is important for quality or not, as one that more reflects the characteristics of the system and the test environment. As a result, it is possible to design test cases to realize efficient software testing by selecting important functions according to the environment and situation surrounding the test and testing those functions with priority and priority. Became.

[0012]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiments of the present invention will be described in detail below with reference to the drawings.

FIG. 1 is a block diagram showing the overall flow of the present invention. In the figure, 3 is a specification item characteristic value setting unit, 5 is a test strategy creation unit, 7 is a test strategy selection unit, 9 is a test priority derivation unit, 11 is a test strategy evaluation unit, 16 is a test case design unit, and 18 is Test execution
A result output unit, 21 is a test result verification unit.

According to the present invention, the specifications are based on the specification item list 1 extracted from the system specifications of the software system product to be tested and the evaluation viewpoint database 2 prepared to express the characteristics of the software system. Using the item characteristic value setting unit 3, a specification item list 4 with characteristic values representing the characteristics of the software system is created.

Next, the test strategy creation unit 5 is used based on the evaluation viewpoint database 2 to create a test strategy for setting which evaluation viewpoint and how much emphasis should be placed on the test. Register with.

The test strategy selection unit 7 selects an arbitrary test strategy from the test strategy database 6 and outputs it to the test priority derivation unit 9. The test priority derivation unit 9 creates a specification item list 10 with test priority indicating which specification item is to be preferentially tested based on the given test strategy and the specification item list 4 with characteristic value. .

The test strategy evaluation unit 11 inputs the specification item list 10 with test priority and the past defect data 12 and simulates the defect detection tendency obtained by applying the selected test strategy to select the selected test. Determine if the strategy is suitable for the software system under test. If necessary, multiple test strategies are sequentially selected to simulate the defect detection tendency, and a test strategy and a list of specification items with test priorities that are considered to be optimal are selected for test case design.

Next, a list of specification items 10 with test priorities selected for test case design, and a test resource 1 including resources and schedules used for testing.
3. Using the test case design unit 16 based on the similar test cases 14 generated in the past, and the test case design procedure 15 for replenishing the insufficient test cases and deleting the excessive test cases. , Create a test case 17 that is optimal for the software to be tested. The defect information found as a result of the test execution by the test case 17 is output as the test result 19 by using the test execution / result output unit 18. In a normal test,
Tests are repeatedly executed as development / debugging progresses. All test results for the software currently being tested are the defect data 2 for the current test.
Registered as 0.

The test result verification unit 21 verifies the applied test strategy again by using the defect data 20 of the current test target and the applied specification item list 10 with test priority as an input, and stores it in the test strategy evaluation unit. Compared with the list of specification items with test priority according to the test strategy of
If necessary, change the applicable test strategy and re-test. In this way, the optimal test strategy is always selected so that the most effective test case is generated.

The functions of the above-mentioned parts will be described in detail below. Each function may be realized by software using a computer. <Creation of specification item list with characteristic values> In the specification item characteristic value setting section, the specification item list extracted from the system specifications and the evaluation viewpoint database for expressing the characteristics of the system are input, and the specification item list with characteristic values is input. To create. In order to express the characteristics of the system from various viewpoints,
It is possible to give a characteristic value to each specification item constituting the software system based on a plurality of evaluation points of view. This makes it possible to evaluate the software system on a specification item basis from multiple viewpoints.

Generally, the system specifications describe the functions realized by the software system as specification items. The specification item list obtained by extracting the list of these items as a list is input to the specification item characteristic value setting unit. On the other hand, the evaluation viewpoint is prepared in order to evaluate the system from various viewpoints and express its characteristics, and there are some that can be evaluated early in system development based on the contents of the system specifications and development information at the design stage. Mainly selected and stored in the evaluation viewpoint database. FIG. 2 shows an example considered as an evaluation viewpoint. Here, the evaluation viewpoints are arranged and shown for each classification such as program quality.

These specification item list and evaluation viewpoint database are input to the specification item characteristic value setting section, and parameters based on the evaluation viewpoint for each specification item are specified as the specification item characteristic value, so that the characteristic value Generate a specification item list. The specific procedure is shown in FIG.

First, the evaluation viewpoint and the specification item list are read (S1, S2), and the evaluation viewpoint to be set is selected from the list (S3). Then, the specification item is searched from the specification item list (S4), and the characteristic value evaluated from the selected evaluation viewpoint is input to the searched specification item (S5). This operation is repeated until the specification item search is completed (S6). Next, the input specification item characteristic value is normalized (S
7). The characteristic value of a specification item is generally given as a relative evaluation by comparison between specification items. Therefore, when characteristic values are given to all specification items for each evaluation viewpoint, normalization is performed so that the characteristic values fall within the range of 1 to 10, for example, and criteria between evaluation viewpoints are set. In this way, it is confirmed whether or not the characteristic values have been given to the specification items for all necessary evaluation viewpoints (S8), and a specification item list with characteristic values is created (S9).

An example of the specification item list with characteristic values is shown in FIG. Here, the specification items consist of large items and middle items,
Here, for each item related to "File" and "Edit", the selected "Defect criticality level" and "Function usage frequency"
Characteristic values are given for each evaluation point of "complexity". <Creation of Test Strategy> The test strategy creation section creates a test strategy that indicates which evaluation viewpoint and how much the test should be performed when the test is executed. The test strategy indicates how much to evaluate the characteristic value from which evaluation point, and to what extent the characteristic value given to the specification item in order to express the characteristics of the system. It is expressed as a weighting for each evaluation point like 5. The weight to be set increases as the evaluation viewpoint is given more importance. For example, in the criticality-oriented test strategy, the weight related to the “defect criticality” is set to 0.7, which is the highest among the evaluation viewpoints, and the weights related to the “function usage frequency” and the “complexity of specifications” are 0. It is 15.

FIG. 6 shows the procedure in the test strategy creating section for creating the test strategy. First, the evaluation viewpoint list is read (S10), and it is determined whether or not a new test strategy needs to be created (S11). If no new test strategy is created, the test data to be edited is selected from the test strategy database (S12).
The test strategy creation unit receives inputs from the evaluation viewpoint database and creates a test strategy by setting weights for each evaluation viewpoint. Then, the evaluation viewpoint for which the weight is set is selected from the list (S13), and the weight is set for the selected evaluation viewpoint (S14). If weights are set for all evaluation viewpoints (S15), the sum of them is 1
(S16). Here, the newly created test strategy or the edited test strategy is
It is registered in the test strategy database (S17). <Selection of Test Strategy> The test strategy selection unit determines what kind of test strategy should be used when executing the test.

The test strategy selection unit selects and outputs the test strategy to be given to the test priority derivation unit from the test strategies registered in the test strategy database. FIG. 7 shows the procedure in the test strategy selection unit for selecting the test strategy. At first, select an arbitrary test strategy (S2
1) As the test cycle progresses, the test strategy evaluation unit and the test result verification unit give instructions to select a more optimal test strategy (S20). Based on the instruction, the test strategy is retrieved from the test strategy database. select.
For example, a test strategy whose test priority has not yet been derived from the test strategy database is selected (S22). It is confirmed whether or not the test strategy suitable for the instruction exists in the database (S23), and if it does not exist, the test strategy is created by the test strategy creating section and registered in the database, and then the test strategy is selected ( S24). Then, the selected test strategy may be output (S25). <Creating a list of specification items with test priority> In the test priority derivation unit, which part of the software system needs to be tested with particular emphasis by applying the selected test strategy is specified for each specification item. The test priority, which is the evaluated index, is derived. The specification item list with test priority created here is generated by the test priority derivation unit based on the specification item list with characteristic values and the test strategy. As shown in FIG. The value of test priority is given to each item.

The test priority is an index indicating that the larger the value, the more preferentially and intensively the tests are executed with respect to the test execution order, the test amount, and the like. The test priority derivation unit calculates the test priority for the specification item from the characteristic value for each evaluation viewpoint given to each specification item and the weighting for each evaluation viewpoint set as the test strategy. The specific procedure is shown in FIG. First, the test strategy and the specification item list with characteristic values are read (S31, S32). Subsequently, the items are sequentially searched from the specification item list (S33), and the weighting for each evaluation viewpoint set in the test strategy and the characteristic value given to each specification item in the specification item list with characteristic values The test priority of the item is calculated (S34). The calculation of such priority is
It is repeated until the specification item search is completed (S3).
5). Generally, the test priority is a characteristic value of a specification item based on n evaluation points for each specification item i.

[0028]

[Equation 1]

When is given, the weight to each evaluation viewpoint by the test strategy is

[0030]

[Equation 2]

Then, the test priority is expressed by the following mathematical expression (1).

[0032]

[Equation 3]

However, the formula for deriving the test priority is
Different calculation formulas may be used as long as they are a combination of the specification item characteristic value and the weight for each evaluation viewpoint. The test priority thus obtained is given to each specification item, and a specification item list with test priority as shown in FIG. 9 is created (S36). <Evaluation of applied test strategy> The test strategy evaluation section determines how effective the test based on the test priority given to each specification item by the applied test strategy is for the software system. Evaluate whether they match. Also, all evaluation results can be stored and compared and examined in order to select the optimum one from a plurality of test strategies. This phase cannot be executed in the development of a new system, but if there is development information of a software system with a similar system specification configuration in the past, it is possible to evaluate the applied test strategy using this.

In the test strategy evaluation section, the specification item list with test priority and the past defect data are given as inputs, and it is compared with the past defect data to determine whether the applied test strategy is appropriate for the software to be tested. evaluate. In the past defect data, defect information of software system development projects having a similar system specification configuration, such as development information before version upgrade of the system as shown in FIG. 11, is accumulated. It contains data that indicates whether a defect was present. It should be noted that the specification items in which “*” is entered in the number of defects in FIG. 11 indicate that the development version has not yet been implemented.

FIG. 10 shows the procedure in the test strategy evaluation section. First, the specification item list with test priority is read (S41), it is confirmed whether past defect data exists (S42), and if it exists, the input specification item list with test priority is compared with the past defect. Simulate to what degree the items that are likely to have many defects compared to the data are positioned higher in the test priority. Specifically, the defect detection tendency is predicted from the use item list with test priority and past defect data (S43), and the predicted defect detection tendency is stored in association with the specification item with test priority and its test strategy. Then, the stored failure detection tendency lists are compared (S44), and the optimum specification item list with test priority is selected (S45).
If it is desired to execute simulation for another test strategy (S46), the test strategy selection unit is instructed to select another test strategy from the test strategy database. The test priority derivation unit derives a specification item list with test priorities from the new test strategy thus selected (S47), and compares the past defect data with the same to evaluate the same. This procedure is repeated to compare the stored list of test strategy evaluations, select one test strategy to be applied to the actual test case design, and output it to the test case design unit (S48). <Test case design> In the test case design department, based on the test priority derived from the applied test strategy, how much priority is given to the test for each specification item is determined, and the test case is designed. .

In the test case design unit, a test resource, a past similar test case, and a test case design means are given as inputs together with a list of specification items with test priority. The procedure in the test case design unit is shown in FIG. First, the specification item list with test priority is read (S51). Next, a test resource indicating a resource used for a test, a schedule, etc. is read (S52), and is distributed for each specification item according to the test priority given to each specification item (S53). An example of the test resource is given in FIG. As a test resource,
Necessary resources are defined according to the categories such as “charge”, “period”, and “resource”.

A necessary and sufficient amount of test cases is predicted for each specification item according to the test priority of each specification item and the allocated test resources. Next, if there is a test case generated in the past for similar system specifications, it is read (S54), the specification items are sequentially searched from the list (S35), and the test case is used by using that information. Design (S56). To examine the amount of test cases for each specification item (S57), if there are no similar test cases in the past, or if there are insufficient test cases compared to the predicted amount of test cases, to supplement the shortfall. A shortage of test cases is created by using a known test case designing means (S58). As a publicly known test case designing means, a method of designing a test case from system specifications like Japanese Patent Laid-Open No. 2001-184232 is used. On the contrary, when there are too many test cases compared to the predicted test case amount, the test cases are reduced to an appropriate amount (S59). In this way, when the search is completed for all the specification items (S60), the optimum test case for the test target is generated (S61). <Reuse of Test Result> The result of test execution by the test case thus designed is output as a test result by using the test execution / result output unit. FIG. 14 shows the procedure in the test execution / result output unit. The test execution / result output unit reads the test case (S6
5) The test is executed based on the read test case (S66), and the defect found as a result and its importance are recorded in association with each specification item of the system (S6).
7). In this way, the number of defects and the degree of importance related to each specification item are totaled and output as a test result (S68).
FIG. 15 shows an example of the output test result. The test is repeated through software development and debugging, and the test result is output in each test cycle. All the test results of each test cycle performed on the current test object are stored as defect data of the current test object together with the test result obtained in what test cycle.

The test result verifying unit inputs the defect data of the current test target and the applied specification item list with test priority and verifies whether or not the applied test strategy is appropriate. FIG. 16 shows the procedure in the test result verification unit.
Shown in. First, the list of specification items with test priority applied to the test case design and the defect detection tendency prediction stored in the test strategy section are read (S71, S72). In the defect data of the current test target that is input, the number of test cycles in which the defect is found, and the importance of the defect are recorded for each specification item. The test result verification unit compares the defect data with the list of specification items with test priority (S73), and verifies whether or not the expected effect is obtained by the applied test strategy (S74). As a result of the verification, if the expected effect is obtained and the defect is not yet converged (S75), the retest is executed again using the same test strategy (S76), and the test priority being applied is applied. The attached specification item list is re-output (S77). On the other hand, if the expected effect is not obtained, or if the effect has been obtained but the defect has already converged (S74, S75), it is decided to newly select another test strategy, The test strategy selection unit is instructed (S78). If there is a list of specification items with an appropriate test priority (S7
9), verify the defect detection tendency from the defect data of the current test target and select a more optimal test strategy (S8)
0). On the other hand, if no specification item list with an appropriate test priority exists (S79), a new test strategy is selected in the test strategy selection section, a specification item list is derived for the test priority, and the test strategy evaluation section is selected. Evaluation / memorization is performed (S81). The selected optimal test strategy may be compared with another test strategy (S82), and the finally selected specification item list with test priority is output (S83).

In this way, the optimum test strategy is always selected throughout the test cycle so that the most effective test case is generated.

The defect data of the current test target is also registered in the defect data of the past as defect information of the current version, and is used as defect data when the test strategy of the next version is evaluated.

[0041]

As described above, the present invention expresses the characteristics of the system by giving characteristic values based on a plurality of evaluation points to the specification items extracted from the system specifications as described above. By designing and selecting an appropriate test strategy for the system under test, the test priority indicating the specification items to be tested preferentially is derived, and the optimum test case is designed. In addition, in order to realize an effective test for the system, it provides a means to select an appropriate test strategy by using past defect data, etc., and is applied by using the defect data found as a result of the test execution. By providing a means for re-verifying the test strategy, it is possible to always select the optimum test strategy, derive the test priority, and design the test case based on it.

[Brief description of drawings]

FIG. 1 is a block diagram showing the overall flow of the present invention.

FIG. 2 is a diagram showing an example of an evaluation viewpoint.

FIG. 3 is a flowchart showing a process of creating a specification item list with characteristic values.

FIG. 4 is a diagram showing an example of a specification item list with characteristic values generated in FIG.

FIG. 5 is a diagram showing an example of a test strategy.

FIG. 6 is a flowchart showing a process of creating a test strategy.

FIG. 7 is a flowchart showing a process of selecting a test strategy.

FIG. 8 is a flowchart showing a process of creating a specification item list with test priority from a specification item list with characteristic values and a test strategy.

9 is a diagram showing an example of a specification item list with test priorities created in FIG.

FIG. 10 is a flowchart showing a process of evaluating a specification item list with test priorities created from a selected test strategy using past defect data.

11 is a diagram showing an example of past defect data used in FIG.

FIG. 12 is a diagram showing an example of a test resource.

FIG. 13 is a flowchart showing a process of designing a test case from the specification item list with test priorities and test resources created in FIG. 8, a similar test case in the past, and a known test case designing means.

FIG. 14 is a flowchart showing a process of creating a defect found as a result of test execution using the test case designed in FIG.

FIG. 15 is a diagram showing an example of a test result created in FIG.

16 is a flowchart showing a process of re-verifying a test strategy using the test result created in FIG.

[Explanation of symbols]

1 System specifications specification item list 2 Evaluation viewpoint database 3 Specification item characteristic value setting section 4 List of specification items with characteristic values 5 Test Strategy Creation Department 6 test strategy database 7 Test strategy selection section 8 test strategies 9 Test priority derivation part 10 Specification list with test priority 11 Test Strategy Evaluation Department 12 Past defect data 13 Test resources 14 Similar test cases in the past 15 Test case design means 16 Test Case Design Department 17 test cases 18 Test execution / result output section 19 test results 20 Defect data of current test target 21 Test result verification unit

   ─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor Jiro Okayasu             1st Komukai Toshiba-cho, Sachi-ku, Kawasaki-shi, Kanagawa             Inside the Toshiba Research and Development Center (72) Inventor Kazunori Tamura             No. 1 Toshiba-cho, Fuchu-shi, Tokyo Toshiba Corporation             Fuchu Office F-term (reference) 5B042 HH11 HH19

Claims (18)

[Claims] 1. A specification item characteristic value setting step of setting a characteristic value based on an evaluation viewpoint of the system for each specification item extracted from a specification of a software system, and which of the evaluation viewpoints is to be emphasized? Defining a test strategy, a test strategy creating step, a test strategy selecting step of selecting a test strategy to be applied to a test of the software system among the created test strategies, and a set characteristic value selected. And a test priority derivation step of deriving a test priority for deciding the specification item to preferentially execute the test from the test strategy. 2. The test priority derivation support method according to claim 1, wherein the test strategy is created by setting a weight for the evaluation viewpoint. 3. The method according to claim 1, further comprising a test strategy evaluation step of evaluating whether an optimal test strategy is applied using the test priority. The test priority derivation support method described. 4. The test priority derivation according to claim 3, wherein in the test strategy evaluation step, it is evaluated whether or not an optimum test strategy is applied by comparing the test priority with defect data. How to help. 5. A specification item characteristic value setting step of setting a characteristic value based on an evaluation viewpoint of the system for each specification item extracted from the specifications of the software system, and which of the evaluation viewpoints is to be emphasized? Defining a test strategy, a test strategy creating step, a test strategy selecting step of selecting a test strategy to be applied to a test of the software system among the created test strategies, and a set characteristic value selected. A test priority derivation step of deriving a test priority for deciding the specification item to execute the test preferentially from the test strategy, and a test case design for designing a test case based on the test priority A test case design support method comprising: a process. 6. The test case design support method according to claim 5, wherein the test strategy is created by setting a weight for the evaluation viewpoint. 7. The method according to claim 5, further comprising a test strategy evaluation step of evaluating whether an optimal test strategy is applied using the test priority. Described test case design support method. 8. The test case design support according to claim 7, wherein in the test strategy evaluation step, it is evaluated whether an optimum test strategy is applied by comparing the test priority with defect data. Method. 9. The method according to claim 5, further comprising a test result verification step of re-verifying the test strategy applied from defect data found as a result of test execution using the test case. Test case design support method described in paragraph. 10. A specification item characteristic value setting function for setting a characteristic value based on an evaluation viewpoint of the system for each specification item extracted from the specifications of the software system, and which of the evaluation viewpoints is to be emphasized? A test strategy creating function that creates a test strategy that defines a test strategy, a test strategy selecting function that selects a test strategy of the created test strategies to be applied to the testing of the software system, and a set characteristic value that is selected. A test priority derivation support program for causing a computer to realize a test priority derivation function for deriving a test priority for determining the specification item for preferentially executing the test from the test strategy. 11. The test priority derivation support program according to claim 10, wherein the test strategy is created by setting a weight for the evaluation viewpoint. 12. The computer according to claim 10, further comprising a test strategy evaluation function for evaluating whether an optimum test strategy is applied using the test priority. The test priority derivation support program described in Section. 13. The test according to claim 12, wherein the test strategy evaluation function evaluates whether or not an optimum test strategy is applied by comparing the test priority with defect data. Priority derivation support program. 14. A specification item characteristic value setting function for setting a characteristic value based on the evaluation viewpoint of the system for each specification item extracted from the specifications of the software system, and which of the evaluation viewpoints is to be emphasized? A test strategy creating function that creates a test strategy that defines a test strategy, a test strategy selecting function that selects a test strategy of the created test strategies to be applied to the testing of the software system, and a set characteristic value that is selected. A test priority derivation function for deriving a test priority for determining the specification items to be preferentially executed from the test strategy,
A test case design support program for causing a computer to realize a test case design function for designing a test case based on the test priority. 15. The test case design support program according to claim 14, wherein the test strategy is created by setting a weight for the evaluation viewpoint. 16. The method according to claim 14, further comprising a test strategy evaluation function for evaluating whether an optimum test strategy is applied using the test priority. Test case design support program described. 17. The test case design support according to claim 16, wherein the test strategy evaluation function evaluates whether an optimum test strategy is applied by comparing the test priority with defect data. program. 18. The test result verification function according to claim 14, further comprising a test result verification function for re-verifying the test strategy applied from defect data found as a result of test execution using the test case. The test case design support program described in Section.