JP6604892B2 - Rule test apparatus and rule test method - Google Patents

Description

  The present invention relates to a rule test apparatus and a rule test method for detecting a failure of a rule.

Software that supports operations such as distribution and finance has its specifications determined and designed in accordance with legal regulations, business rules and standards (hereinafter referred to as “business rules”) regarding business such as products and services.
Such software may organize its specifications in IF-THEN format. The specifications in the IF-THEN format (hereinafter, IF clause is called “condition part” and THEN clause is called “result part”), such as business rules, system rules, check rules, etc. (Hereafter, these are called “rules”). The rule is a description in a natural sentence such as “if is”, a description according to a predetermined rule interpretable by a computer such as “IF A = 1 AND B = 2 THEN R = 1”, and Expressed in various forms, such as a description in a decision table that defines the correspondence between conditions and results in tabular form.

Since the rules are determined according to the business rules, they need to be consistent with the business rules. Whether it is consistent or not can be confirmed by a review by an expert, for example. However, taking legal regulations as an example, there are an enormous number of rules, and they are complicated by the dependency between rules. Therefore, it is very difficult to check the consistency between rules and business rules in reviews.
Another way to check if a rule is consistent with the rule is to give a specific input value to the rule and check if the expected result is obtained (hereinafter referred to as “test”) For example, it is disclosed in Patent Document 1.

US Patent Application Publication No. 2009/0112654

  With the technology disclosed in Patent Document 1, it is possible to guarantee the consistency between rules and business rules within a tested range using specific input values. Cannot be guaranteed. To ensure consistency between rules and business rules, it is necessary to test using all possible combinations of input values. However, if the number of possible input value combinations becomes enormous, it will be difficult to complete the test in practical time.

  The rule test apparatus according to the present invention is a rule test apparatus described in the IF-THEN format as a software specification, wherein a condition part for storing a condition for satisfying the rule and a result when the condition is satisfied are obtained. A rule creation / correction unit that accepts a rule set that is a set of one or more rules including a result part to be stored; an input condition unit that stores a condition of an input value to be tested described in a logical expression; and the input A test case correcting / creating unit that accepts one or more logical test cases including an expected output condition part that stores an expected result for an input that satisfies a value condition, one or more rule sets, and one logical test From the case, the input / output of the rule set satisfies the input condition of the logical test case and the expected output condition of the logical test case The result for all inputs that satisfy the input conditions of the logical test case is determined by generating a fail case generation expression that represents a case not to be satisfied and determining whether the fail case generation expression is satisfactory. A test execution unit that determines whether or not the test is performed, and a test result output unit that outputs a test result determined by the test execution unit.

  According to the rule test apparatus of the present invention, a test can be performed on a plurality of inputs in one test case, and an input to an untested rule can be detected. Can be implemented.

FIG. 1 is a diagram showing an example of the configuration of a rule test apparatus according to the present invention. FIG. 2 is a diagram illustrating an example of a rule test. FIG. 3 is a diagram illustrating an example of the data structure of the rule recording unit. FIG. 4 is a diagram illustrating an example of a data structure of the test case recording unit. FIG. 5 is a diagram illustrating a description example of a test case set. FIG. 6 is a diagram illustrating an example of the data structure of the test result recording unit. FIG. 7 is a diagram illustrating an example of a rule creation / editing screen. FIG. 8 is a diagram illustrating an example of a test case set creation / edit screen. FIG. 9 is a diagram illustrating an example of a test result display screen. FIG. 10 is a diagram illustrating an example of an application case display screen. FIG. 11 is a diagram illustrating an example of an application case analysis result screen. FIG. 12 is a diagram illustrating an example of a display / edit screen for complementary test cases. FIG. 13 is a diagram illustrating a flowchart of processing executed by the test case leakage inspection unit. FIG. 14 is a diagram illustrating an example of a leak check expression and related logical expressions. FIG. 15 is a diagram illustrating a flowchart of processing executed by the test execution unit. FIG. 16 is a diagram illustrating an example of a logical expression generated in the processing flow of the test execution unit. FIG. 17 is a diagram illustrating a flowchart of processing executed by the complementary test case generation unit. FIG. 18 is a diagram illustrating an example of a logical expression generated in the processing flow of the complementary test case generation unit. FIG. 19 is a diagram illustrating a flowchart of processing executed by the failure location analysis unit. FIG. 20 is a diagram illustrating a flowchart of processing executed by the influence range analysis unit. FIG. 21 is a diagram illustrating a flowchart of processing executed by the influence range analysis unit in order to acquire a logical test case that may change pass / fail.

  DESCRIPTION OF EMBODIMENTS Hereinafter, embodiments according to the present invention will be described as examples with reference to the drawings. The embodiments described below do not limit the invention according to the claims, and all elements and combinations thereof described in the embodiments are essential for the solution of the invention. Not exclusively.

In the present embodiment, a rule test apparatus in which an apparatus user detects a failure of a rule will be described as an example.
FIG. 1 is a diagram illustrating an example of the configuration of a rule test apparatus 100 according to an embodiment of the present invention. The rule test device 100 includes at least a processor 131 such as a CPU (Central Processing Unit), a memory 132 such as a RAM (Random Access Memory), a ROM (Read Only Memory), an auxiliary storage device 120, a keyboard, a display monitor, and the like. The computer includes an input / output device 133.

Also, the rule test apparatus 100 includes a rule creation / correction unit 101, a test case creation / correction unit 102, a test case leakage inspection unit 103, a test execution unit 104, a test result output unit 105, a complementary test case generation unit 106, a defect location The functional logic of the analysis part 107 and the influence range analysis part 108 is provided. These functional logics are realized as a computer program and executed by the processor 131 on the memory 132.
Further, the rule test apparatus 100 stores data such as the test case recording unit 121, the rule recording unit 122, and the test result recording unit 123 in the auxiliary storage device 120. These data are read from the auxiliary storage device 120 and used when the processor 131 executes the above-described functional logic.

  FIG. 2 is a diagram illustrating an example of a rule test using two rule sets (RS1 and RS2) and one test case. The rule set will be described later. An ID (identifier) is attached to a rule having a condition part and a result part. For example, a rule in which the condition part is “2001 <= subscription year” and the result part is “subscription period = application year−subscription year” is given R1 as its ID, and “IF 2001 <= subscription year THEN subscription period” = Applicable year-Joined year ".

When applying a rule, a variable to which a value is assigned is called an “input item”, and a variable to which a value is assigned as a result of applying the rule is called an “output item”.
In the rule of R1 and R2 of the subscription period calculation (RS2), “applicable year” and “subscription year” are input items, and “subscription period” is an output item. The value of the input item is called “input value”, and the value of the output item is called “output value”. For example, in the rule of R1, values “2015” and “1995” given as “application year” and “joining year” are input values, and “20” (= 2015-1995) given as “subscription period”. ) Is the output value.

  Further, in the rules R1 to R8 of the member privilege grant determination (RS1), “privilege grant” is an output item, and “do not” is an output value. As is clear from FIG. 2, the input value and the output value are not necessarily numerical values but may be a character string or the like (hereinafter, input is a collection of input values).

  A collection of such rules is called a “rule set”. In FIG. 2, two rule sets (RS1 and RS2) of member privilege grant determination and subscription period calculation are represented. Where a rule set is a collection of one or more rules, the output items of each rule are the same. If there are a plurality of rules, the input is true (establishes) the condition part of any one of the rules included in the rule set. For example, in the rule set (RS2) for calculating the subscription period, the output items of each rule are the same “subscription period”. When an input value is assigned to the “applied year” and “joined year”, any one of the condition parts of the rules R1 to R2 is true.

  In FIG. 2, the output item of the rule set for calculating the subscription period (RS2) is used as one of the input items of the rule set (RS1) for determining membership benefits (hereinafter, the output item of the rule set is a different rule set). The relationship between these two rule sets is called “dependency”. As is clear from FIG. 2, the input items include input items that are output items of other rulesets and input items that are not output items of other rulesets (hereinafter, other items). An input item that is an output item of the rule set is called a “dependent input item”, and an input item that is not an output item of another rule set is called an “independent input item”).

In the input items of the rule set (RS1) for member privilege grant determination, the rule set and the input items of the rule are not limited to one, and the conditional expressions of the individual input items are combined by an operator. In the rule set (RS1) for member privilege grant determination, an AND logical operator is used.
Although the output items of each rule in the rule set are the same, if there are rules that are common to (can be shared with) multiple types of output items, a single rule set may have multiple types of output items. Is possible. However, if there are multiple types of output items in a rule set, changing the rules of the rule set becomes complicated according to changes in business rules. Therefore, from the viewpoint of easy understanding of the meaning of the rule set and easy change of the rule, it is desirable to provide a plurality of rule sets each having one output item for a plurality of types of output items.

  In order to check whether these rulesets (which may be one) are consistent with the business rules, first, humans interpret the business rules and create the input and expected results (hereinafter referred to as “test cases”). "). Next, the input is given to the rule set, and it is confirmed whether the obtained result satisfies the expectation. At this time, when the test is performed without considering the dependency relationship between the rule sets, input values for both the dependent input item and the independent input item are input. When a test is performed in consideration of the dependency relationship between rule sets, an input value for an independent input item is used as an input.

  In the example of FIG. 2, as a result of giving “applicable year: 2015, subscription year: 1995, age: 40” as inputs to “member privilege grant determination” and “subscription period calculation”, member privilege grant determination ( The rule R5 of the RS1) and the rule R2 of the subscription period calculation (RS2) are applied, and “privilege grant: not” that is a result satisfying “privilege grant: not” as the expected result is obtained. Therefore, it turns out that the test is passed.

Hereinafter, a set of rules applied to the input is referred to as an “application case”. In the application case, all rule sets including each rule are different.
In the rule test realized by the rule test apparatus according to the present invention, not a specific input value as a test case but an input condition (hereinafter referred to as “input condition”) for performing a test described by a logical expression and an expected result (Hereinafter referred to as “expected output condition”).

As an explanation of each processing unit of the rule test apparatus 100 shown in FIG. 1, an outline of a rule test using a test case described by a logical expression will be described (hereinafter, a test case described by a logical expression is referred to as “ Logical test case ").
The rule creation / modification unit 101 receives information on input items, output items, and rules added, changed, or deleted by the apparatus user, and registers the information in the rule recording unit 122.
The test case creation / correction unit 102 receives information on the logical test case added, changed, or deleted by the apparatus user and registers it in the test case recording unit 121.

  The test case leakage inspection unit 103 may occur in a rule set to be tested for each group of one or more test cases (hereinafter referred to as “test case set”) having the same rule set to be tested. In the test case set, it is determined whether or not there is an input that has not been tested (hereinafter referred to as “input leakage”). The processing of the test case leakage inspection unit 103 will be described later.

  The test execution unit 104 determines whether the rule registered in the rule recording unit 122 satisfies the expected output condition for all inputs satisfying the input conditions of each logical test case registered in the test case recording unit 121. Judge whether to meet. For all inputs that satisfy the input conditions of this logical test case, if the rule application result satisfies the expected output condition, the test is considered to pass and if the rule application result does not satisfy the expected output condition , Considered a test failure.

  Next, the test execution unit 104 applies an input case satisfying an expected output condition (hereinafter referred to as “passed case”) and an input satisfying an expected output condition in an input satisfying an input condition of a logical test case. Acquire all applicable cases (hereinafter referred to as “failed cases”). In FIG. 2, when “applicable year: 2015, subscription year: 1995, age: 40” is given as an input, the conditions of rule R2 for membership period calculation (RS2) and rule R5 for membership benefit grant determination (RS1) are given. The part becomes true, and these rules apply respectively. The result is “privilege grant: no”. Since this is a result that satisfies the expected result, “Rule R2 for calculating the subscription period (RS2) and Rule R5 for granting the member privilege (RS1)” is a passing case. The processing of the test execution unit 104 will be described later. Next, the test execution unit 104 records pass / fail of each logical test case, a pass case, and a fail case (hereinafter referred to as “test result”) in the test result recording unit 123 as test results.

The test result output unit 105 displays the test result registered in the test result recording unit 123 to the apparatus user or the like.
The complementary test case generation unit 106 generates a logical test case for the input leakage detected by the test case leakage inspection unit 103. The processing of the complementary test case generation unit 106 will be described later. Further, the complementary test case generation unit 106 records the generated logical test case in the test case recording unit 121.

The failure location analysis unit 107 uses the test result recorded in the test result recording unit 123 to specify a rule that is biased to be included in the failure case or a rule that is common to the failure case. The processing of the defect location analysis unit 107 will be described later.
The influence range analysis unit 108 detects the editing of the rule, and uses the edited content of the rule and the test result registered in the test result recording unit 123, among the logical test cases recorded in the test result recording unit 123. As a result of editing the rule, a logical test case that may change the pass / fail of the test result is specified. The processing of the influence range analysis unit 108 will be described later.

  FIG. 3 is a diagram illustrating an example of the data structure of the rule recording unit 122. The rule recording unit 122 includes tables of rule set information 310, entity information 320, rule information 330, input information 340, output information 350, and attribute information 360. The notation of each table in FIG. 3 is composed of two rectangles, the table name is shown in the upper rectangle, and the column name of the table is shown in the lower rectangle. The relationship between the tables is expressed by connecting the diamond and the solid line, and the diamond side table and the solid line side table are in a one-to-many relationship. The same notation is used for the other data structure diagrams shown below.

  The rule set information 310 illustrated in FIG. 3 includes a rule set ID and a rule set name as information on the rule set. The rule set ID is an identifier that is unique among rule sets. In FIG. 2, as the rule set ID, there are RS1 for member privilege grant determination and RS2 for subscription period calculation. Since the rule set name is the name of the rule set indicated by the rule set ID, in FIG. 2, the name of the rule set is “member benefit grant determination” and “subscription period calculation”.

The entity information 320 has an entity name as information on the entity of the input value of the rule set. The entity name is the name of the entity.
The rule information 330 includes a rule ID, a condition part logical expression, and a result part logical expression as information on rules included in the rule set. The rule ID is a unique identifier assigned to each rule in the rule set. In the example of FIG. 2, R <b> 1 to R <b> 8 included in the rule set “Member benefit grant determination” are rule IDs. The conditional part logical expression is a logical expression that represents the conditional part of the rule, and is expressed by a combination of input items, comparison operators (including equality operators), four arithmetic operators, logical operators, and the like. The result part logical expression is a logical expression that represents the result part of the rule, and is expressed by a combination of an input item, a value that the input item can take, an output item, a value that the output item can take, an equation operator, and an arithmetic operator. Is done.

  The input information 340 includes an input item name, a reference type, and a reference expression as information related to the input items of the rule set. The input item name is the name of the input item. The reference type is a type of a reference destination of a value to be assigned to the input item, and in the embodiment, is one of “Entity” and “RuleSet”. When the reference type is “Entity”, the reference destination is the entity information 320, and when the reference type is “RuleSet”, the reference destination is the rule set information 310. The reference expression is a reference destination of a value to be assigned to the input item. When the reference type is “Entity”, the reference expression is “entity name.attribute name”, and when the reference type is “RuleSet”, the reference expression is “rule set name.output item name”. When the reference type of the input information 340 is “RuleSet”, it indicates that it depends on an output item of another rule set, and therefore, the dependency relationship between the rule sets is expressed.

  An example of the input information 340 will be described using the member privilege grant determination (RS1) in FIG. The input item names of the rule set (RS1) for determining membership benefit grant are “age” and “subscription period”. The reference type of “Age” is “Entity”, and the entity according to the definition of the entity information 320 is assigned a value according to the definition of the entity information 320 with reference to the entity information 320 described later using the reference formula of “entity name.attribute name”. The input value of “age” of the determination rule set (RS1) is used. The reference type of “subscription period” is “RuleSet”, and “subscription period calculation.subscription period” is used as a reference expression of “rule set name.output item name”, and the output item “subscription” of the subscription period calculation (RS2) is used. The output value of “period” is set as the input value of “subscription period” in the rule set (RS1) for determining membership benefit grant.

The output information 350 includes an output item name and an output item type as information related to the output items of the rule set. The output item name is the name of the output item. The output item type is an output item data type such as an Integer type, a Boolean type, a Date type, and a user-defined enumeration type.
The attribute information 360 includes an attribute name and an attribute type as information related to the attributes included in the entity information 320. The attribute name is the name of the attribute. The attribute type is a data type of the attribute such as an integer type (an integer type), a bool type, a date type, and a user-defined enumeration type.

  FIG. 4 is a diagram illustrating an example of the data structure of the test case recording unit 121. The test case recording unit 121 has a table of test case set information 410 and logical test case information 420.

  The test case set information 410 includes a test type, a test case set ID, a test case set name, and a rule set ID as test case set information. The test type is a type of test performed using a test case set. In the embodiment, the test type is either “unit” or “combination”. When the test type is “single”, only the rule set corresponding to the rule set ID (hereinafter referred to as “test target rule set”) is used when performing the test. When the test type is “join”, all rule sets (hereinafter referred to as “dependent rule sets”) on which the test target rule set and the input items of the rule set depend directly or indirectly (“dependent rule set”) ). In the following, a test using a test case set whose test type is “unit” is called “unit test”, and a test using a test case set whose test type is “join” is called “integration test”. .

  In FIG. 2, when the test type of the test case set is “combined” in the rule set member benefit grant determination (RS1) test, the input item “subscription period” of the rule set member benefit grant determination (RS1) is Since it depends on the subscription period calculation (RS2), the combination test is performed using the rule set member privilege grant determination (RS1) and the subscription period calculation (RS2). Furthermore, when the input item “subscription year” of the subscription period calculation (RS2) depends on another rule set, the rule set is also used to perform the test.

  Returning to FIG. 4, the test case set ID is an identifier unique among the test case sets. The test case set name is the name of the test case set for the test case set ID. The rule set ID is an ID of a rule set to be tested, and is any of the rule set information 310.

  The logical test case information 420 includes a test case ID, an input condition, and an expected output condition as information on the logical test case included in the test case set. The test case ID is an identifier that is unique among logical test cases in the test case set. An input condition is a conditional logical expression of the input that is the target of the logical test case. Input items, possible values of input items, comparison operators (including equality operators), arithmetic operators, logical operators, etc. It is expressed by the combination of When the unit test is performed, the input items of the test target rule set can be used in the input condition of the logical test case. When performing an integration test, the independent input items of the test target rule set and the independent input items of the rule set included in the set of dependent rule sets of the test target rule set can be used as input conditions for the logical test case. . The expected output condition is a logical expression of the condition that the result obtained from the target input in the logical test case should satisfy. The input item, the output item of the test target rule set, the value that the output item can take, the comparison operation It is expressed by a combination of a child (including an equation operator), an arithmetic operator and a logical operator.

An example of a logical test case will be described using an example of a test case set for performing a combination test on the member privilege grant determination (RS1) shown in FIG.
The independent item of the member privilege grant determination (RS1) is “age”, the dependent input item is “subscription period”, and the input value of the “subscription period” depends on the subscription period calculation (RS2). The independent input items of the subscription period calculation (RS2) are “subscription year” and “application year”, and do not have a dependent input item. The test type of the test case set is “join”, and the input items that can be used for the input condition are “age”, “joining year”, and “application year”. The input condition of the logical test case (T1) of the test case set is “100 <= age”, the expected output condition is “privilege = not”, and the result is “input is 100 or older”. It is hoped that “granting: no”.

FIG. 6 is a diagram illustrating an example of the data structure of the test result recording unit 123. The test result recording unit 123 includes tables of test result information 610, application case information 620, and rule path information 630.
The test result information 610 includes a test case set ID, a test case ID, and a test pass / fail as information regarding the test result. The test case set ID is information for identifying a test case set including the logical test case corresponding to the test result information 610, and is any one of the test case set information 410. The test case ID is information for identifying the logical test case corresponding to the test result information 610, and is any one of the logical test case information 420. The test pass / fail is pass / fail of the logical test case.

  The application case information 620 includes an application case ID and pass / fail as information regarding a pass case and a fail case of the test result. The application case ID is a unique identifier in the test result. Pass / Fail is the type of application case. In the examples, it is either “Pass” or “Fail”. For a pass case, the pass / fail is “Pass”, and for a fail case, the pass / fail is “Fail”. Passed ".

  The rule path information 630 includes a rule set ID and a rule ID as information regarding rules included in the application case. The rule set ID is information for identifying the rule set including the rule included in the application case, and is any one of the rule set information 310. The rule ID is information for identifying a rule included in the application case, and is one of the rule information 330.

FIG. 7 is a diagram illustrating an example of a rule creation / editing screen.
The rule creation / editing screen 700 is a screen displayed on the input / output device 133 in order for the rule creation / modification unit 101 to accept rule editing input from a device user.
The rule creation / editing screen 700 includes a rule set basic information display area 710, an input item edit area 720, an output item edit area 730, a rule edit area 740, and a test case set display area 750.

  The rule set basic information display area 710 is an area for displaying basic information related to the rule set to be edited, and displays a rule set ID and a rule set name. The rule creation / modification unit 101 displays the titles (item names) of “rule set ID” and “rule set name”, and inputs the rule set ID and rule set name by the device user. FIG. 7 shows an example in which “RS1” is input as the rule set ID and “member benefit grant determination” is input as the rule set name.

  The input item edit area 720 is an area for editing (adding, changing, and deleting) the input items of the rule set, and displays the input item name, type, and reference expression items. The rule creation / modification unit 101 adds or deletes the number of lines in the input item edit area 720 according to the number of input items. Further, the rule creation / modification unit 101 reflects the result of editing (addition, change, and deletion) of the input items by the apparatus user in the rule recording unit 122. Therefore, the contents of each item after editing correspond to the input item name, reference type, and reference expression of the input information 340 of the rule recording unit 122, respectively.

  The output item edit area 730 is an area for editing (adding, changing, and deleting) the output items of the rule set, and displays output item names and type items. The contents of each item after being edited by the device user are reflected in the rule recording unit 122 by the rule creating / modifying unit 101 as in the input item editing area 720, and output item names of the output information 350 of the rule recording unit 122, respectively. And output item type.

  The rule edit area 740 is an area for editing (adding, changing, and deleting) rules in the rule set, and displays a rule ID, a condition part logical expression, and a result part logical expression. When the device user selects a rule to be edited, the rule creation / correction unit 101 holds the rule ID, the condition part, and the result part before editing in the memory 132. After editing the condition part logical expression or result part logical expression by the apparatus user, the rule creating / modifying unit 101 notifies the influence range analyzing unit 108 of the rule after editing and the rule before editing.

  The influence range analysis unit 108 performs a test using a logical test case whose pass / fail may change by editing the rule, and creates / corrects a change in the pass / fail of the logical test case before and after editing the rule. Notification to the unit 101. The rule creation / modification unit 101 presents the apparatus user with a change in pass / fail of the logical test case notified from the influence range analysis unit 108 and confirms whether the edited content is reflected in the rule recording unit 122. When the apparatus user selects to reflect, the rule creating / modifying unit 101 deletes the pre-editing rule recorded in the memory 132 and reflects the edited content in the rule recording unit 122. The contents of each item in the edited rule editing area 740 correspond to the rule ID, the condition part logical expression, and the result part logical expression of the rule information 330 of the rule recording unit 122, respectively.

  The test case set display area 750 is an area for displaying a test case set whose target is the rule set, and displays a test case set ID and a test case set name.

FIG. 8 is a diagram illustrating an example of a test case set creation / edit screen.
The test case set creation / editing screen 800 is a screen displayed on the input / output device 133 in order for the test case creation / modification unit 102 to accept an input for editing a logical test case from a device user.
The test case set creation / edit screen 800 includes a test case set basic information display area 810, an input item display area 820, an output item display area 830, a test case edit area 840, a leak check button 850, and a test execution button 860.

  The test case set basic information display area 810 is an area for displaying basic information regarding the test case set to be edited, and displays a test type, a test case set ID, a test case set name, and a test target rule set ID. The test case creation / modification unit 102 displays the titles (item names) of “test type”, “test case set ID”, “test case set name”, and “test target rule set ID”, and the test case by the device user Enter the set ID, test case set name, and test target rule set ID. FIG. 8 shows an example in which “combination” is input as the type, “TS1” is input as the test case set ID, “combination test for member privilege grant determination” is input as the test case set name, and “RS1” is input as the test target rule set ID ing.

  The input item display area 820 is an area for displaying input items usable in the input conditions and expected output conditions of the logical test cases of the test case set. Similarly to the input item editing area 720 in FIG. Displays name, type, and reference expression. As shown in the example of the test case set in FIG. 5, the components of the input item display area 820 are “age”, “year of participation”, and “year of application”.

  The output item display area 830 is an area for displaying output items that can be used as expected output conditions of the logical test cases of the test case set, and displays output item names and types. The components of the output item display area 830 are the same as the output item edit area 730 of FIG. 7 (the description of the components is omitted).

  The test case editing area 840 is an area for editing (adding, changing, and deleting) a logical test case of the test case set, and displays a test case ID, an input condition, and an expected output condition. The test case creation / modification unit 102 adds or deletes the number of lines in the test case editing area 840 according to the number of logical test cases. Further, the test case creation / modification unit 102 reflects the result of editing (addition, change, and deletion) of the logical test case by the apparatus user in the test case recording unit 121. Therefore, the contents of each item after editing correspond to the test case ID, input condition, and expected output condition of the logical test case information 420 of the test case recording unit 121, respectively.

  The leak check button 850 is an operation button for performing the test case set leak inspection by the test case leak inspection unit 103. The test case creation / correction unit 102 performs a leakage inspection by the test case leakage inspection unit 103 after the user presses the button, and the test case leakage inspection unit 103 complements the result of the inspection described later. The test case display / edit screen 1200 is displayed.

  The test execution button 860 is an operation button for performing a test by the test execution unit 104. The test case creation / modification unit 102 performs a test by the test execution unit 104 after the apparatus user presses the button, and the test execution unit 104 displays the test result on a test result display screen 900 described later. To do.

FIG. 9 is a diagram illustrating an example of a test result display screen.
The test result display screen 900 is a screen displayed on the input / output device 133 in order for the test execution unit 104 to display a test execution result.
The test result display screen 900 includes a test case set basic information display area 910 and a test result display area 920.

The components of the test case set basic information display area 910 are the same as the test case set basic information display area 810 of FIG. 8 (the description of the components is omitted).
The test result display area 920 is an area for displaying a test result, and displays a test case ID, a test pass / fail, a pass case, and a fail case. Each component displays either test result information 610, application case information 620, or rule path information 630. When the apparatus user selects one or more of the application cases displayed in the pass case and the fail case in the test result display area 920, the test execution unit 104 displays the application case on the application case display screen 1000 described later. Illustrated.
In addition, you may make it display the specific combination of input value in the case of passing or failing in the test result display area 920.

FIG. 10 is a diagram illustrating an example of the application case display screen.
The application case display screen 1000 is a screen that the test execution unit 104 displays on the input / output device 133 in order to display the application case selected by the apparatus user.
The application case display screen 1000 includes an application case display area 1010. The application case display area 1010 is an area illustrating the application case selected by the apparatus user.

FIG. 10 is a diagram illustrating a case where the apparatus user in FIG. 9 selects application cases of logical test cases with test case IDs “T3” and “T5”.
A square shown in the application case display area 1010 represents a rule appearing in the application case, and an ellipse represents a rule set including the rule. A line between rules indicates that the rule is included in the same application case, a solid line indicates that the application case is a pass case, and a dotted line indicates that the application case is a fail case. Represents each.

FIG. 11 is a diagram illustrating an example of an application case analysis result display screen.
The application case analysis result display screen 1100 is a screen displayed on the input / output device 133 so that the defect location analysis unit 107 performs a test on the application case selected by the apparatus user and displays the analysis result of the failure location. is there.
The application case analysis result display screen 1100 includes an application case analysis result display area 1110.

  The application case analysis result display area 1110 is an area for displaying the result of analyzing the application case for each rule as analysis of a defective part, and includes a rule name, a pass rate, and an appearance rate (fail). The rule name is the ID of the rule and the ID of the rule set including the rule, and is displayed in the form of “ID of the rule set.ID of the rule”.

The pass rate is a ratio of the pass cases among the application cases including the rule, and “(the number of pass cases including the rule / the number of pass cases) / ((the number of pass cases including the rule / the number of pass cases. ) + (Number of failed cases including the rule / number of failed cases)) ”.
The appearance rate (failed) is a ratio of failed cases in which the rule is included among the failed cases, and is calculated by an expression “(number of failed cases in which the rule is included) / number of failed cases”.

Further, the defect location analysis unit 107 enables rearrangement of data displayed in the application case analysis result display area 1110 in accordance with an operation instruction from the apparatus user. When the triangle 1111 is pressed in a state in which the triangle 1111 is downward with respect to the triangle 1111 provided in the pass rate column, the triangles are rearranged in descending order of the acceptance rate, and when the triangle 1111 is pressed in a state in which the triangle 1111 is upward, Sort by the highest acceptance rate. Similarly, when the triangle 1112 is pressed in a state where the triangle 1112 is downward with respect to the triangle 1112 provided in the column of the appearance rate (failure), the triangles 1112 are rearranged in descending order of appearance rate (failure). When the triangle 1102 is pressed in the upward state, the triangles are rearranged in descending order of appearance rate (failure).
The application case analysis result display area 1110 may display the number of successful cases, the number of failed cases, the number of successful cases including the rule, and the number of failed cases including the rule.

FIG. 12 is a diagram illustrating an example of a screen for displaying and editing the result of the leakage inspection and the test case generated by the complementary test case generation unit 106 (hereinafter referred to as “complementary test case”).
The complementary test case display / edit screen 1200 displays the result of the leakage inspection inspected by the test case leakage inspection unit 103 and the logical test case generated by the complementary test case generation unit 106, and displays the complementary test case from the device user. This is a screen displayed on the input / output device 133 in order to accept editing input.

The complementary test case display / edit screen 1200 includes a test case set basic information display area 1210, a leakage inspection result display area 1220, a complementary test case editing area 1230, a leakage check button 1240, and an end button 1250.
The constituent elements of the test case set basic information display area 1210 are the same as the test case set basic information display area 810 of FIG. 8 (the description of the constituent elements is omitted).

  The leak test result display area 1220 is an area for displaying the result of the leak test, and is either “leak ant” or “leak pear”. As a result of the leakage inspection, the test case leakage inspection unit 103 displays “leakage ant” when an input leakage is detected, and displays “leakage no” when there is no input leakage. The leakage inspection result display area 1220 may be an independent screen only in this area.

The complementary test case editing area 1230 displays the logical test cases created by the device user on the test case set creation / edit screen 800 and edits (adds, changes, and changes) the complementary test cases generated by the complementary test case generation unit 106. This is an area for deleting, and displays acceptance / rejection 1231, input conditions and expected output conditions.
The acceptance / rejection 1231 is a check box for the apparatus user to input whether or not to adopt a complementary test case, and is displayed only in the complementary test case.

  The leakage check button 1240 is a button for performing an input leakage inspection by the test case leakage inspection unit 103 for the logical test case in the complementary test case editing area 1230 and the complementary test case for which acceptance / rejection 1231 is checked. is there. When the apparatus user presses the leakage check button 1240, the test case leakage inspection unit 103 determines whether there is an input leakage of the complementary test case in which the logical test case and acceptance / rejection 1231 in the complementary test case editing area 1230 are checked. Inspect. When the leakage of the input is detected, “leakage ant” is displayed in the leakage inspection result display area 1220, and a complementary test case for the leakage of the input is generated using the complementary test case unit 106. In addition to the test case editing area 1230, a complementary test case for which acceptance / rejection 1231 is not checked in the area is deleted. When there is no leakage, the complementary test case in which the acceptance / rejection 1231 is not checked is deleted in the area. Note that when a complementary test case cannot be generated, the test case leakage inspection unit 103 displays a message. This is the same when the leak check button 850 in FIG. 8 is pressed.

  The end button 1250 is an operation button for reflecting, in the test case recording unit 121, a complementary test case in which acceptance / rejection 1231 in the complementary test case editing area 1230 is checked as a logical test case. When the apparatus user presses the end button 1250, the test case leakage inspection unit 103 assigns a test case ID to the complementary test case in which the acceptance / rejection 1231 in the complementary test case editing area 1230 is checked, as a logical test case. It is added to the test case recording unit 121. Therefore, the input condition and the expected output condition in the complementary test case editing area 1230 correspond to the input condition and the expected output condition of the logical test case information 420, respectively.

FIG. 13 is a diagram illustrating a flowchart of processing executed by the test case leakage inspection unit 103.
In step 1300 (S1300), the test case leakage inspection unit 103 starts processing when the apparatus user presses the leakage check button 850 in FIG. 8 or the leakage check button 1240 in FIG.

In step 1301 (S1301), the test case leakage inspection unit 103 refers to the test case recording unit 121 and acquires all the input conditions of the logical test cases included in the test case set to be input leakage inspection target.
In step 1302 (S1302), the test case leakage inspection unit 103 refers to the rule recording unit 122 and acquires a test target rule set for the test case.

  In step 1303 (S1303), the test case leakage inspection unit 103 confirms the type of the test case set to be input for leakage inspection. The test case leakage inspection unit 103 proceeds to step 1305 (S1305) when the type is “single”, and proceeds to step 1304 (S1304) when the type is “combined”.

In step 1304 (S1304), the test case omission inspection unit 103 obtains a set of dependency rule sets by following the dependency relationship of the input items of the test target rule set.
In step 1305 (S1305), the test case leakage inspection unit 103 generates a leakage inspection formula 1400, which will be described later, in order to determine whether or not there is a leakage in the test case set.

FIG. 14 is a diagram illustrating an example of a leak check expression 1400 and related logical expressions.
The leak check expression 1400 is an expression obtained by combining the non-test input value expression 1410 and the target rule set input value expression 1420 in the case of a unit test, and in the case of an integration test, the dependency constraint expression 1430 is calculated based on the AND of the unit test. This is a formula that is combined by AND and adding.

The non-test input value expression 1410 is a logical expression in which the input conditions of all the logical test cases included in the test case set are combined with a logical sum and the whole is negated.
The target rule set input value expression 1420 is a logical expression in which the condition parts of all the rules included in the test target rule set are combined with a logical sum.

The dependency constraint expression 1430 is obtained by combining a logical expression obtained by combining the condition part and result part of each rule included in each rule set included in the set of dependent rule sets by logical inclusion with a logical product. It is a logical expression that is connected by AND in a set.
In FIG. 14, TS is a test case set, tc is a logical test case included in the test case set, and tc. con is an input condition of the logical test case, RS_SET is a set of dependent rule sets, DependRS is a rule set included in the set of dependent rule sets, TargetRS is a test target rule set, and rule is a rule included in the test target rule set , Rule. con is a condition part of the rule, rule. res represents the result part of the rule.

Returning to FIG. 13, in step 1306 (S 1306), the test case leakage inspection unit 103 determines whether or not the leakage inspection formula 1400 is satisfiable. It is determined that there is no leakage, and the process ends in step 1307 (S1307).
Satisfiability is a property that indicates whether or not there is a combination of variable values that makes a given logical expression true. The leak check expression 1400 is satisfiable that the leak check expression 1400 is true, that is, there is an input that is not included in the input to be tested in the test case set among the inputs that can occur in the rule set to be tested. Means.

  Satisfiability can be determined simply by checking the combinations of the values of all variables. In addition, there are tools such as a DPLL (Davis-Putnam-Logemann-Loveland) algorithm for efficiently determining satisfiability by focusing on the structure of a logical expression rather than a combination of variable values. For example, an SMT (Satisfiability Modulo Theories) solver is a type of tool that determines satisfiability, and can determine the sufficiency of the leak check expression 1400.

FIG. 15 is a diagram illustrating a flowchart of processing executed by the test execution unit 104.
In step 1500 (S1500), the test execution unit 104 may change the pass / fail status when the apparatus user presses the test execution button 860 of FIG. 8, or by the influence range analysis unit 108 described later with reference to FIG. When a certain logical test case is notified, the process is started for each logical test case to be tested (S1500).

In step 1501 (S1501), the test execution unit 104 acquires a logical test case from the test case recording unit 121.
In step 1502 (S1502), the test execution unit 104 acquires a necessary rule set. When the test executed in the logical test case is an integration test, a set of test target rule sets and dependent rule sets is acquired, and when the test is a unit test, only the test target rule set is acquired.

  In step 1503 (S1503), the test execution unit 104 matches the output values between the rules for which the condition part is true with respect to the input in each rule set in the set of the test target rule set and the dependency rule set. Check the consistency between rules that indicate At this time, in the test execution by another logical test case, the process is omitted for the rule set that has already been processed in step 1503 (S1503). As a method for determining consistency between rules, for example, a method using satisfiability determination disclosed in JP 2012-190203 A can be used.

If the consistency check result in step 1503 (S1503) is “not consistent”, the test execution unit 104 ends the process in step 1513 (S1513).
If the consistency check result in step 1503 (S1503) is “consistent”, the test execution unit 104 proceeds to step 1504 (S1504).
In step 1504 (S1504), the test execution unit 104 generates a pass case generation formula 1600 described later in order to generate a pass case.

FIG. 16 is a diagram illustrating an example of a logical expression generated in the process flowchart of the test execution unit 104. In the case of a unit test, the pass case generation expression 1600 is an expression obtained by combining the expected satisfaction expression 1610 and the rule set input / output expression 1620 with a logical product. It is an expression connected by logical product.
Here, the expected satisfaction formula 1610 is a formula obtained by combining the input condition of the logical test case and the expected output condition by a logical product. The rule set input / output expression 1620 is an expression obtained by combining an expression obtained by combining a condition part and a result part of a rule included in the rule set by logical inclusion with a logical product.

  In FIG. 16, tc. con is the input condition of the logical test case, tc. exres is an expected output condition of the logical test case, RS is a test target rule set, rule is a rule included in the test target rule set, rule. con is a condition part of the rule, rule. res represents the result part of the rule and Case represents the application case.

  Returning to FIG. 15, in step 1505 (S 1505), the test execution unit 104 determines whether or not the acceptable case generation formula 1600 is satisfied. That the pass case generation formula 1600 is satisfiable means that the pass case generation formula 1600 is true, that is, in the input value of the test target rule set that satisfies the input conditions of the logical test case, the expected output condition of the logical test case is It means that there is a case where a satisfactory result is obtained.

If it is determined in step 1505 (S1505) that the acceptable case generation formula 1600 is “unsatisfiable”, the test execution unit 104 proceeds to step 1508 (S1508).
If it is determined in step 1505 (S1505) that the acceptable case generation formula 1600 is “satisfiable”, the test execution unit 104 proceeds to step 1506 (S1506).

  In step 1506 (S1506), the test execution unit 104 acquires an input (hereinafter referred to as a “model”) to a rule set in a set of a rule set to be tested and a dependent rule set for which the pass case generation formula 1600 is true. Then, a rule of a set of a test target rule set and a dependent rule set whose condition part is true in the model is acquired, and the set of rules is set as a passing case. This can be confirmed by actually giving a model as an input to the condition part of the rule. In the model, if there are two or more rules that are true in the rules in the same rule set, each is a different pass case.

  In step 1507 (S1507), the test execution unit 104 generates a duplication prohibition constraint expression 1630 in which the condition parts of the rules included in the pass case are combined by a logical product and the whole is negated from the pass case. Then, the duplication prohibition constraint expression 1630 is combined with the acceptable case generation expression 1600 by logical product, and the process proceeds to step 1505 (S1505). When a plurality of acceptable traces are acquired in step 1506 (S1506), the duplication prohibition constraint 1630 is generated from all the acceptable traces, and is combined with the acceptable case generation formula 1600 by AND.

In step 1505 (S1505), when the sufficiency of the above-described pass case generation formula 1600 is determined, a constraint is added so that the same thing does not appear in step 1507 (S1507). Is “unsatisfiable”, and the process proceeds to step 1508 (S1508).
In step 1508 (S1508), the test execution unit 104 generates a failure case generation formula 1640 described later in order to generate a failure case.

  The failure case generation formula 1640 shown in FIG. 16 is an expression that is combined by a logical product of the rule set input / output expression 1620 and the expected unsatisfied expression 1650 in the case of a unit test. This is an expression obtained by adding a dependency relation constraint expression 1430 and combining them by logical product. Here, the expected unsatisfied expression 1650 is an expression obtained by combining the input condition of the logical test case and the negation of the expected output condition by logical product.

  Returning to FIG. 15, in step 1509 (S 1509), the test execution unit 104 determines whether or not the failure case generation formula 1640 is satisfied. The failure case generation expression 1640 is satisfiable that the failure case generation expression 1640 is true, that is, in the input value of the rule set to be tested that satisfies the input condition of the logical test case, the expectation of the logical test case This means that there are cases where results that do not satisfy the output conditions are obtained.

If it is determined in step 1509 (S1509) that the failed case generation formula 1640 is “unsatisfiable”, the test execution unit 104 proceeds to step 1512 (S1512).
If it is determined in step 1509 (S1509) that the failed case generation formula 1640 is “satisfiable”, the test execution unit 104 proceeds to step 1510 (S1510).

  In step 1510 (S1510), the test execution unit 104 acquires a model of the failed case generation expression 1640, and acquires a rule of a set of rule sets to be tested and dependent rule sets whose condition part is true in the model. Then, the set of rules is regarded as a failure case. This can be confirmed by actually giving a model as an input to the condition part of the rule. In the model, if there are two or more rules that are true among the rules in the same rule set, they are regarded as different failure cases.

  In step 1511 (S1511), the test execution unit 104 generates a duplication prohibition constraint expression 1630 from the failed case. Then, the duplication prohibition constraint expression 1630 is combined with the failure case generation expression 1640 by a logical product, and the process proceeds to step 1509 (S1509). When a plurality of failure cases are acquired in step 1511 (S1511), duplication prohibition constraints 1630 are generated from all failure cases, and are combined with failure case generation formula 1640 by AND.

  In step 1512 (S1512), the test execution unit 104 determines that the test has failed if one or more generated failure cases exist, and determines that the test has passed if none exists. In step 1513 (S1513), the test execution unit 104 ends the process.

  In the embodiment, all pass traces and fail traces are acquired, but only a predetermined number may be acquired. For example, this is realized by limiting the number of loops of the repetition process from step 1505 (S1505) to step 1507 (S1507) and the repetition process from step 1509 (S1509) to step 1512 (S1512). Thereby, the processing time when the number of pass traces and fail traces becomes enormous can be shortened.

  Also, a pass case is not acquired (the processing from step 1503 (S1503) to step 1507 (S1507) is omitted), the processing of step 1509 (S1509) is left, and a failure case is not acquired (step from step 1510 (S1510) to step 1511 (S1511 is omitted). In this case, only the pass / fail of the test can be acquired, which is effective when it is desired to know only the pass / fail of the test.

FIG. 17 is a diagram illustrating a flowchart of processing executed by the complementary test case generation unit 106.
In step 1700 (S1700), the complementary test case generation unit 106 starts processing when an input leak is found by the test case leak check unit 103.
In step 1701 (S1701), the complementary test case generation unit 106 sets the test rule set of the test case set (hereinafter referred to as “leak test case set”) in which input leakage exists and the dependency rule set of the test target rule set. Check the integrity of each rule set in the set to see if it is complete.

  A rule set is complete when the condition part of any rule in the rule set is true for all inputs. For example, two rules “IF A <1 THEN R = 1” and “IF A> 1 THEN R = 2” are assumed in the rule set. When the input is A = 1, the condition part of any rule is not true, so the rule set is not complete. The determination of whether or not the rule set is complete is performed, for example, by determining whether or not the negation of the logical sum of the condition parts in the rule set is satisfied. At this time, if it is satisfiable, the rule set is not complete, and if it is not satisfactory, the rule set is complete.

  If it is determined in step 1701 (S1701) that the rule set is complete, the complementary test case generation unit 106 generates a rule application formula 1800 described later from the leak test case set in step 1702 (S1702).

FIG. 18 is a diagram illustrating an example of a logical expression generated in the processing flow of the complementary test case generation unit 106.
The rule application formula 1800 is a logical product of the rule set input / output formula 1620, the non-test input value formula 1410, and the target rule set input value formula 1420 when the test to be executed is a unit test. This is a logical product of the output formula 1620, the non-test input value formula 1410, the target rule set input value formula 1420, and the dependency relation constraint formula 1430.

In FIG. 18, Case indicates an application case, rule indicates a rule in the application case, rule. con represents the condition part of the rule. Also, rule. “replaced_con” replaces the dependency input item in the condition part of the rule with the result part of the rule included in the rule set referred to by the dependency input item among the rules in the application case. A logical expression from which input items are removed (hereinafter referred to as “replaced condition part”).
For example, in FIG. 2, the application case {member benefit grant determination (RS1). R5, subscription period calculation (RS2). In the case of R1}, member privilege grant determination (RS1). The replaced condition part of R5 is “age <60 and 25 <= application date−subscription date”. "

Returning to FIG. 17, in step 1703 (S 1703), the complementary test case generation unit 106 determines whether or not the rule application formula 1800 is satisfied. The rule application formula 1800 being satisfiable means that the rule application formula becomes true, that is, there is a case where the rule is applied in the case of omission of input.
If it is determined in step 1703 (S1703) that the rule application formula 1800 is “unsatisfiable”, the complementary test case generation unit 106 proceeds to step 1706 (S1706).
If it is determined in step 1703 (S1703) that the rule application formula 1800 is “satisfiable”, the complementary test case generation unit 106 proceeds to step 1704 (S1704).

  In step 1704 (S1704), the complementary test case generation unit 106 determines, from the model of the rule application formula 1800, the test target rule set and the test target rule set for which the output value and the condition part of the test target rule set are true. A rule of a set of dependent rule sets is specified, and the specified set of rules is used as an application case. This can be confirmed by actually giving the model as an input to the condition part of the rule (hereinafter, the obtained output value and application case are referred to as “application result pair”). In the model, the rules in the same rule set If there are two rules that are true, each is a different application case.

In step 1705 (S1705), the complementary test case generation unit 106 generates a duplication prohibition constraint expression 1630 from the application case of the application result pair, and combines the duplication prohibition constraint expression 1630 with the rule application formula 1800 using a logical product. The process proceeds to step 1703 (S1703). If a plurality of application cases are acquired in step 1704 (S1704), duplication prohibition constraints 1630 are generated from all the application cases and combined with the rule application formula 1800 by logical product.
In step 1706 (S1706), the complementary test case generation unit 106 generates an equivalence class expression 1810 described later from the application case for each application result pair.

  In FIG. 18, equivalence class expression 1810 is a combination of the non-test input value expression 1410 of FIG. 14 and the condition parts of all the rules included in the application case in a unit test when the test performed in the leak test case set is a unit test. This is an expression that is combined with the logical expression, and in the case of the combined test, the expression obtained by combining the non-test input value expression 1410 and the replaced condition part of all the rules included in the application case with the logical product is further combined with the logical product. It is a formula.

  Returning to FIG. 17, in step 1707 (S 1707), the complementary test case generation unit 106 uses the equivalence class expression 1810 of the application result pair as an input condition for all application result pairs, and sets the output value to “output item = item value”. Generates a complementary test case using a logical expression described in the format as an expected output condition. In step 1708 (S1708), the complementary test case generation unit 106 ends the process.

Here, the complementary test case generation unit 106 may convert the equivalence class expression 1810 into a shorter logical expression when generating the complementary test case.
For example, it is possible to shorten the equivalence class expression 1810 by deleting a portion (hereinafter referred to as “don't care”) that does not affect the truth of the logical expression. Whether or not part of the logical expression is don't care is determined as follows. If the test to be performed in the leak test case set is a unit test, the equivalence class expression 1810 and the equivalence class expression from which a part is deleted (hereinafter referred to as “equivalence class expression after deletion”) are used. The satisfiability of the don't care determination expression 1820 that negates the logical product of the “equivalence class expression” and “equivalence class expression after deletion → equivalence class expression 1810” is determined. If the test performed in the leak test case set is a combined test, the satisfaction of the don't care determination formula 1820 obtained by combining the dependency relationship constraint expression 1430 of FIG.

If the don't care determination formula 1820 can be satisfied, the deleted part is not don't care. If the don't care determination formula 1820 can be satisfied, the deleted part is don't care. In order to improve the comprehension of the equivalence class expression 1810, the denotation operator “not” existing in the equivalence class expression 1810 is replaced with “input item comparison operator calculation expression” using De Morgan's law or the like. It is also possible to move immediately before a comparison expression such as “input item comparison operator item value” to reduce the number of parentheses in the expression. Furthermore, by changing the comparison operator in the comparison expression to a comparison operator corresponding to the negation of the operator, the negation operator immediately before the comparison expression can be removed.
For example, in the case of the equivalence class expression 1810 “not ((year of subscription> 2001) or (year of subscription <2001))”, it is converted into “not (year of subscription> 2001) and not (year of subscription <2001)”, and , “(Year of subscription ≦ = 2001) and (year of subscription ≧ = 2001)”.

FIG. 19 is a diagram illustrating a flowchart of processing executed by the defect location analysis unit 107.
In step 1900 (S1900), the failure location analysis unit 107 starts processing when a failed logical test case is found as a result of performing a test on one or more logical test cases. Note that steps 1903 (S1903) to 1906 (S1906) in FIG. 19 are rules included in application cases in the test results recorded in the test result recording unit 123 (hereinafter referred to as “analysis target application case set”). The process is executed for each (hereinafter referred to as “analysis target rule”).

In step 1901 (S1901), the failure location analysis unit 107 counts the number of accepted cases from the set of analysis target application cases.
In step 1902 (S1902), the failure location analysis unit 107 counts the number of failed cases from the set of analysis target application cases.
In step 1903 (S1903), the defect location analysis unit 107 acquires analysis target rules included in the set of analysis target application cases.

In step 1904 (S1904), the defect location analysis unit 107 calculates the failure appearance rate by counting the number of failed cases including the analysis target rule in the set of analysis target application cases.
In step 1905 (S1905), the failure location analysis unit 107 calculates the appearance rate of the pass by counting the number of pass cases including the analysis target rule in the set of analysis target application cases.

In step 1906 (S1906), the defect location analysis unit 107 calculates a pass rate from the appearance rate (failed) and the appearance rate (passed) obtained previously. From this calculation result, it is possible to specify a rule that is biased in the failed case or a rule that is common to the failed case.
The defect location analysis unit 107 executes the processing from step 1903 (S1903) to step 1906 (S1906) for all the analysis target rules, and then ends the processing at step 1907 (S1907).

FIG. 20 is a diagram illustrating a flowchart of processing executed by the influence range analysis unit 108.
In step 2000 (S2000), the influence range analysis unit 108 starts processing when the rule creation / editing screen 700 in FIG. 7 detects the editing of the rule by the device user (hereinafter, edited by the device user). Rules are called "edited rules").

In step 2001 (S2001), the influence range analysis unit 108 acquires the rule before editing from the memory 132 and the rule after editing from the rule editing area 740 in FIG.
In step 2002 (S2002), the influence range analysis unit 108 specifies the editing content.
For example, the addition / deletion of a rule can be specified depending on whether a rule before editing exists or a rule after editing exists. In addition, regarding the change of the rule ID and the result part, it can be specified whether or not the change has been made due to the character string match. Furthermore, regarding the condition part, the input value increasing expression “¬ (condition part of the rule after editing → condition part of the rule before editing)” and the input value decreasing expression “¬ (condition part of the rule before editing → editing) By determining whether or not the “condition part of the later rule” can be satisfied, an increase or decrease in the input value that makes the condition part of the edited rule true can be specified.

An input increase expression is satisfiable means that the check expression for increasing the input value is true, that is, among the inputs that make the condition part of the rule after editing true, the condition part of the rule before editing is true It means that there is an input that must not be.
Also, that the input reduction formula is satisfiable means that the input value reduction check formula is true, that is, among the inputs that make the pre-edit rule condition part true, the post-edit rule condition part is true. It means that there is an input that does not become.

  In step 2003 (S2003), the influence range analysis unit 108 acquires, from the test case recording unit 121, a logical test case whose pass / fail may change due to editing. For example, a logical test case whose pass / fail may change with respect to the edited content can be acquired by the processing flow shown in FIG.

FIG. 21 is a diagram illustrating a flowchart of a process in which the influence range analysis unit 108 acquires a logical test case that may change pass / fail.
In step 2100 (S2100), the influence range analysis unit 108 starts the process of the flowchart of FIG. 21 in step 2003 (S2003) of FIG.

In step 2101 (S2101), the influence range analysis unit 108 confirms the editing content.
If the edited content is “add rule”, the influence range analyzing unit 108 proceeds to step 2102 (S2102).
If the edited content is “delete rule”, the influence range analyzing unit 108 proceeds to step 2104 (S2104).
If the edited content is “change rule”, the influence range analyzing unit 108 proceeds to step 2106 (S2106).

  If the edited content is “add rule”, in step 2102 (S2102), the influence scope analysis unit 108 sets a rule set including the edited rule as a test target rule as a logical test case that may change pass / fail. All logical test cases (hereinafter referred to as “candidate test cases”) included in the test case set to be set are acquired, and the process ends in step 2103 (S2103).

  When the edited content is “delete rule”, in step 2104 (S2104), the influence range analysis unit 108 acquires a logical test case having an application case including the edited rule from the candidate test cases, The process ends in 2105 (S2105).

If the edited content is “change rule”, in step 2106 (S2106), the influence range analysis unit 108 checks the change target.
When the change target is “rule ID”, the influence range analysis unit 108 ends the process in step 2107 (S2107).
When the change target is the “result part”, the influence range analysis unit 108 proceeds to step 2108 (S2108).
When the change target is the “condition part”, the influence range analysis unit 108 proceeds to step 2110 (S2110).

When the change target is the “result part”, in step 2108 (S2108), the influence range analysis unit 108 acquires a logical test case having an application case including the edited rule from the candidate test cases, and in step 2109. The process ends at (S2109).
When the change target is the “condition part”, in step 2110 (S2110), the influence range analysis unit 108 confirms whether or not the input increase formula is satisfiable.

If the input increase formula is “satisfiable”, the influence range analysis unit 108 proceeds to step 2111 (S2111). In step 2111 (S2111), the influence range analysis unit 108 acquires all candidate test cases, and ends the process in step 2114 (S2114).
When the input increase formula is “unsatisfiable”, the influence range analysis unit 108 proceeds to Step 2112 (S2112). In step 2112 (S2112), the influence range analysis unit 108 checks the satisfiability of the input reduction formula.

If the input reduction formula is “satisfiable”, the influence range analysis unit 108 proceeds to step 2113 (S2113). In step 2113 (S2113), the influence range analysis unit 108 acquires a logical test case having an application case including the edited rule from the candidate test cases, and ends the process in step 2114 (S2114).
When the input decrease formula is “unsatisfiable”, that is, both the input increase formula and the input decrease formula are unsatisfactory, meaning that there is no change, and the influence range analysis unit 108 performs processing in step 2114 (S2114). Exit.

  Returning to FIG. 20, in step 2004 (S2004), the influence range analysis unit 108 executes a test on the affected logical test case, and ends the process in step 2005 (S2005).

DESCRIPTION OF SYMBOLS 100 ... Rule test apparatus, 101 ... Rule creation / modification part, 102 ... Test case creation / modification part, 103 ... Test case omission inspection part, 104 ... Test execution part, 105 ... Test result output part, 106 ... Complementary test case production | generation , 107 ... failure location analysis part, 108 ... influence range analysis part, 120 ... auxiliary storage device, 121 ... test case recording part, 122 ... rule recording part, 123 ... test result recording part, 131 ... processor, 132 ... memory, 133 ... I / O device

Claims (10)

A test device for rules described in IF-THEN format as software specifications,
A rule creation / modification unit that accepts a rule set that is a set of one or more of the rules, including a condition part that stores a condition for satisfying the rule and a result part that stores a result when the condition is satisfied;
One or more logics including an input condition part that stores a condition of an input value to be tested described by a logical expression and an expected output condition part that stores an expected result for an input that satisfies the condition of the input value A test case modification / creation unit that accepts test cases;
A failure indicating that the input / output of the rule set satisfies the input condition of the logical test case and does not satisfy the expected output condition of the logical test case from one or more rule sets and one logical test case Generates a case generation expression and determines whether or not the result for all inputs satisfying the input condition of the logical test case satisfies the expected output condition by determining the satisfaction of the reject case generation expression. A test execution unit;
A rule test apparatus comprising: a test result output unit that outputs a test result determined by the test execution unit. The rule test device according to claim 1,
The test execution unit includes the one or more rules applied when the pass / fail for each logical test case satisfies the input condition of the logical test case and does not satisfy the expected output condition of the logical test case. Obtaining and recording part or all of a case and a passing case including one or more of the rules applied when the input condition of the logical test case is satisfied and the expected output condition of the logical test case is satisfied,
The rule test apparatus, wherein the test result output unit displays the pass / fail, the fail case, and the pass case recorded by the test execution unit as test results determined by the test execution unit. The rule test apparatus according to claim 1 or 2, wherein
For each test case set including one or more logical test cases with the same test target, a test case leak inspection unit that detects the presence of an input of the rule set that has not been tested as a leak,
A rule test apparatus further comprising a complementary test case generation unit that generates one or more complementary test cases for testing an input range of the rule set corresponding to the leakage using the leakage and the rule set. A rule test apparatus according to claim 3 quoting claim 2 or claim 2 ,
Analyzing the pass / fail for each logical test case, the fail case and the pass case, and identifying the rule that is biased to the fail case and the rule common to the fail case; A rule test device further provided. The rule test device according to claim 2 or 3,
Using the edited contents of the rule and the test result determined by the test execution unit, the influence range analysis unit for identifying the logical test case that may change the pass / fail determined by the test execution unit by editing the rule A rule test apparatus further comprising: A test method for rules described in IF-THEN format as software specifications,
A first step of accepting a rule set that is a set of one or more of the rules including a condition part for storing a condition for establishing the rule and a result part for storing a result when the condition is satisfied;
One or more logics including an input condition part that stores a condition of an input value to be tested described by a logical expression and an expected output condition part that stores an expected result for an input that satisfies the condition of the input value A second step of accepting the test case;
A failure indicating that the input / output of the rule set satisfies the input condition of the logical test case and does not satisfy the expected output condition of the logical test case from one or more rule sets and one logical test case Generates a case generation expression and determines whether or not the result for all inputs satisfying the input condition of the logical test case satisfies the expected output condition by determining the satisfaction of the reject case generation expression. A third step;
And a fourth step of outputting the test result determined in the third step. The rule test method according to claim 6,
The third step includes one or more rules that are applied when the pass / fail of each logical test case satisfies the input condition of the logical test case and does not satisfy the expected output condition of the logical test case. Acquire and record a part or all of a passing case and a passing case that satisfies the input condition of the logical test case and includes one or more of the rules applied when the expected output condition of the logical test case is satisfied Including
The rule test method according to claim 4, wherein the fourth step includes displaying the pass / fail, the fail case, and the pass case recorded as the test result determined in the third step. The rule test method according to claim 6 or 7, wherein
A test case leak check step for detecting the presence of an input of the rule set that is not tested as a leak for each test case set including one or more of the logical test cases with the same test target;
A rule test method further comprising: generating one or more complementary test cases for testing an input range of the rule set corresponding to the leak using the leak and the rule set. A rule test method according to claim 8 quoting claim 7 or claim 7 ,
Analyzing the pass / fail, the fail case and the pass case for each logic test case, and the failure point analyzing step for identifying the rule common to the fail case and the rule common to the fail case A rule test method further comprising: The rule test method according to claim 7 or 8, wherein
Using the edited contents of the rule and the test result determined in the third step, the influence range for specifying the logical test case that may change the pass / fail determined in the third step by editing the rule A rule test method further comprising an analysis step.

Images