Several common methods for generating test cases with black box technology

Because the experiment hasn't been done yet, I can't write the experiment report. Here I will briefly describe several common black-box test methods.

Black box testing, also known as functional testing or data-driven testing. is to think of the test object as a black box. When using black-box test method for dynamic testing, the function of software product needs to be tested. There is no need to test the internal structure and process of software products.

The test case methods designed with black box technology are:

1. Equivalence class Partitioning method
2. Boundary value Analysis
3. False speculation
4. Causality Diagram method
5. Decision table Driven Analysis method
6. Design method of orthogonal experiment
7. Function Diagram Analysis method

Equivalence class Partitioning:

It is an important and common black box test case design method to divide all possible input data, that is, the input field of a program into several parts, and then select a few representative data from each subset as the test case. Equivalence classes can be divided into two different cases: valid equivalence class and invalid equivalence class.

1. Valid equivalence class: a set of meaningful input data that is reasonable for the specification of a program. The effective equivalence class can be used to verify whether the program implements the functions and performance specified in the specification.
2. Invalid equivalence class: Contrary to the definition of a valid equivalence class.

Boundary Value Analysis Method:

The boundary value analysis method complements the equivalence class partitioning method. Long-term testing experience tells us that a large number of errors occur on the boundary of the input or output range, rather than within the input and output range, so you can find more errors by designing test cases for various boundary conditions.

Using the Boundary value analysis method to design test cases, we should first determine the boundary condition, usually the boundary of the input and output equivalence class, that is, the boundary condition should be emphasized, should choose exactly equal, just greater than or just less than the boundary of the value as the test data, rather than select the boundary class typical value or any value as test data.

Error-Guessing Hair:

A method of designing test cases based on experience and intuition to speculate on all possible errors in the program.

Enumerate all the possible errors in the program and the special circumstances that are prone to errors, depending on their choice of test cases. For example, many of the errors that are common in the module during unit testing, errors that are often found in previous product tests, and so on, are summaries of experience. Also, the input data and output data is zero, the input table is a space or the input table has only one row, these are prone to error situations, you can choose examples of these cases as test cases.

Causality Diagram Method:

The equivalence class partitioning method and boundary value analysis method described above are mainly concerned with the input conditions, but the relation between the input conditions is not considered. Considering the combination of the input conditions may result in some new situations, but to check the combination of input conditions an easy thing, so you must consider a suitable for the description for a combination of multiple conditions, the corresponding generation of multiple actions form to consider design test cases, which requires the use of causality diagram.

The causality diagram method ultimately generates a decision table, which is suitable for checking the various combinations between the program input conditions.

The basic steps for generating test cases using causality diagrams:

(1) Analysis software Specification Description, those are the reason (that is, the input condition or the equivalence class of the input condition), those are the results (that is, the output condition), and give each cause and result assigned an identifier.

(2) Analyze the semantics in the description of the software specification. Identify the relationship between the cause and the result, the reason and the reason. According to these relationships, draw a causal diagram.

(3) Due to grammatical or environmental constraints, there are some reasons and reasons, the combination of cause and result is not impossible to appear. In order to show these special cases, some marks are used to indicate constraints or constraints on the causal diagram.

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

(5) Each column of the decision table is taken out as the basis for the design of test cases.

The test cases (local, combined relationships) generated from the causality diagram include the fact that all input data is true and false, and the number of test cases is minimized, and the number of test cases increases linearly with the number of input data.

The decision table is already used in the preceding causality diagram method. The decision table (decision table) is a tool for analyzing and expressing different operations under multiple logic conditions. In the early stages of the development of programming, The decision table has been used as a tool for writing programs. Because it can express the complex logic relation and the condition of the combination of the various conditions is both concrete and definite.

A decision table is usually made up of four parts.

Conditional pile (Condition Stub): Lists all the conditions for the problem. The order of the listed conditions is generally considered to be irrelevant.

Action stub: Lists the actions that may be taken by the problem rule. The order of these operations is not constrained.

Condition Item (Condition Entry): Lists the values that are for its left column condition. The true and false values in all possible cases.

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

Rule: The specific value of any combination of conditions and the corresponding action to be taken. A column that runs through the condition and action items in a decision table is a rule. Obviously, how many sets of criteria are listed in the decision table, and how many rules are there, and how many columns are there for both conditional 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 the condition piles and action piles.

③ fill in the condition.

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

⑤ simplification. Merging similar rules (same action)

B. Beizer points out the criteria for designing test cases with a decision table:

The ① specification is given in the form of a decision table or easily converted into a decision table.

The order of ② conditions does not and does not affect which operations are performed.

The order of ③ rules does not and does not affect which operations are performed.

④ you do not have to test other rules whenever the conditions of a rule have been met and the action you want to perform is determined.

⑤ If a rule is satisfied to perform multiple operations, the order of execution of these operations does not matter.

Several common methods for generating test cases with black box technology