Shulou(Shulou.com)06/03 Report--

Black box test case design method:

It divides all possible input data, that is, the input field of the program, into several parts (subsets), and then selects a small number of representative data from each subset as test cases. This method is an important and commonly used black box test case design method.

1) Partition equivalence class: equivalence class refers to a subset of an input field. In this subset, each input data is equivalent to exposing errors in the program. It is reasonably assumed that testing the representative value of an equivalent class is equal to testing other values of this class. Therefore, all the input data can be reasonably divided into several equivalent classes, and a small amount of representative test data can be used if a data is taken as the input condition of the test in each equivalence class. Better test results are obtained. There are two different cases of equivalence class division: effective equivalence class and invalid equivalence class.

Efficient equivalence class: a collection of input data that is reasonable and meaningful for the specification of the program. The effective equivalence class can be used to verify whether the program achieves the function and performance specified in the specification.

Invalid equivalence class: the opposite of the definition of valid equivalence class.

When designing test cases, consider these two equivalence classes at the same time. Because software should not only be able to receive reasonable data, but also be able to withstand unexpected tests. This kind of testing can ensure that the software has higher reliability.

2) the method of dividing the equivalence class: here are six principles for determining the equivalence class.

① can establish a valid equivalence class and two invalid equivalence classes when the input condition specifies the range or the number of values.

② can establish a valid equivalence class and an invalid equivalence class when the input condition specifies the set of input values or the condition of "what must be".

③ can determine a valid equivalence class and an invalid equivalence class when the input condition is a Boolean quantity.

Under the condition that ④ defines a set of values of input data (assuming n), and the program needs to deal with each input value separately, it can establish n effective equivalence classes and one invalid equivalence class.

Under the condition that ⑤ prescribes the rules that the input data must follow, it can establish a valid equivalence class (conforming to the rules) and several invalid equivalence classes (violating the rules from different angles).

⑥ should further divide the equivalence class into smaller equivalence classes when it is certain that the elements of the divided equivalence class have different ways of processing in the program.

3) Design test cases: after the equivalence class is established, a table of equivalence classes can be established, listing all the divided equivalence classes:

Input conditional valid equivalence class invalid equivalence class

.........

.........

Then the test cases are designed according to the following three principles from the divided equivalence classes:

① assigns a unique number to each equivalence class.

② designs a new test case to cover as many valid equivalence classes as possible that have not been covered. Repeat this step. Until all valid equivalence classes are covered.

③ designs a new test case to cover only one invalid equivalent class that has not been covered. Repeat this step. Until all invalid equivalence classes are overwritten.

Boundary value analysis

The boundary value analysis method is a supplement to the equivalent class division method.

(1) consideration of boundary value analysis method:

Long-term testing experience tells us that a large number of errors occur at the boundary of the input or output range, not within the input and output range. Therefore, more errors can be found by designing test cases for various boundary conditions.

When boundary value analysis is used to design test cases, the boundary condition should be determined first. Usually the boundary of the input and output equivalence class is the boundary case that should be tested. The value just equal to or less than the boundary should be selected as the test data, instead of the typical value or any value in the equivalence class as the test data.

(2) the principle of selecting test cases based on boundary value analysis method:

1) if the input condition specifies the range of values, the value that has just reached the boundary of the range and the value that has just exceeded the boundary of the range should be taken as the test input data.

2) if the input condition specifies the number of values, the maximum number, the minimum number, one less than the minimum number and one more than the maximum number are used as the test data.

3) use the previous principle 1) according to each output condition of the specification.

4) apply the previous principle 2) according to each output condition of the specification.

5) if the input field or output field given by the specification of the program is an ordered set, the first and last elements of the set should be selected as the test case.

6) if an internal data structure is used in the program, the value on the boundary of the internal data structure should be selected as the test case.

7) analyze the specification and find out other possible boundary conditions.

Error inference method

Speculate all kinds of possible errors in the program based on experience and intuition, so as to design test cases pertinently.

The basic idea of error inference method: enumerate all possible errors and special cases prone to errors in the program, and select test cases according to them. For example, many common errors in modules have been listed during unit testing. The mistakes that have been found in previous product tests are a summary of experience. Also, the input data and output data are 0. The input form is a space or has only one row. These are all error-prone situations. Examples in these cases can be selected as test cases.

Causality diagram method

The equivalence class division method and boundary value analysis method introduced earlier focus on considering the input conditions, but do not take into account the relationship between the input conditions, mutual combination and so on. Considering the combination of input conditions, some new situations may arise. However, it is not easy to check the combination of input conditions, even if all input conditions are divided into equivalence classes, there are quite a lot of combinations between them. Therefore, it is necessary to consider designing test cases in a form that is suitable to describe the combination of multiple conditions and generate multiple actions accordingly. This requires the use of causality diagrams (logical models).

The final result of causality diagram method is the decision table. It is suitable for checking various combinations of program input conditions.

The basic steps for generating test cases using causality diagrams:

(1) in the description of the specification of the analysis software, which are the causes (that is, the equivalent class of input conditions or input conditions), and those are the results (that is, output conditions), and each reason and result is assigned an identifier.

(2) analyze the semantics in the description of software specification. Find out the corresponding relationship between cause and result, cause and cause. According to these relationships, draw a causality diagram.

(3) due to grammatical or environmental limitations, the combination of some reasons and causes and between causes and results is not impossible. In order to show these special cases, some marks are used to indicate the constraints or constraints on the causality diagram.

(4) convert the causality diagram into a decision table.

(5) take out each column of the decision table as a basis to design test cases.

The test cases generated from the causality diagram (partial, combinatorial relation) include all the cases of taking TRUE and FALSE of input data, the number of test cases is minimum, and the number of test cases increases linearly with the increase of the number of input data.

The decision table has been used in the previous causality diagram method. Decision table (Decision Table) is a tool to analyze and express different operations under multiple logic conditions. In the early days of programming, decision tables have been used as an auxiliary tool for programming. Because it can express the complex logical relationship and the combination of many conditions concretely and clearly.

A decision table usually consists of four parts.

Conditional pile (Condition Stub): lists all the conditions of the problem. It is generally believed that the order in which the conditions are listed does not matter.

Action pile (Action Stub): lists the possible actions to be taken by the problem. There is no constraint on the order in which these operations are arranged.

Condition item (Condition Entry): lists the values for its left column of conditions. True and false values in all possible cases.

Action item (Action Entry): lists the actions that should be taken in the case of various values of the condition item.

Rules: the specific values of any combination of conditions and the corresponding actions to be performed. A column that runs through condition items and action items in the decision table is a rule. Obviously, there are many rules for determining how many sets of condition values are listed in the table, that is, how many columns there are for condition items and action items.

Steps to establish the decision table: (according to the software specification)

① determines the number of rules. If there are n conditions. Each condition has two values (0 # 1), so there is a rule.

② lists all conditional piles and action piles.

③ fill in the condition item.

④ fill in the action item. Wait until the initial decision table.

⑤ is simplified. Merge similar rules (same actions).

B. Beizer points out the conditions that are suitable for designing test cases using decision tables:

① specifications are given in the form of a decision table, or can be easily converted to a decision table.

The order of the ② conditions does not and does not affect what actions are performed.

The order in which ③ rules are arranged does not and does not affect what actions are performed.

④ whenever the conditions of a rule have been met and determine the action to be performed, there is no need to check other rules.

⑤ if a rule is satisfied, multiple actions are performed, the order in which they are performed does not matter.

>-I want to page! It would be nice to have a page here for such a long article. Ha ha-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.