Smart test
7 test methods for black box testing
Black box testing is also called functional testing, which is to test whether each function can be used normally. In the test, the program is regarded as a black box that cannot be opened. The program interface is tested without considering the internal structure and internal characteristics of the program. It only checks whether the program functions are used normally according to the requirements specification. Whether the program can properly receive input data and generate correct output information. Black box testing focuses on the external structure of the program, without considering the internal logical structure, and mainly tests the software interface and software functions.
Black box testing is based on the user's point of view, starting from the corresponding relationship between input data and output data. Obviously, if there is a problem with the design of the external feature itself or the specification is wrong, the black box test method will not be able to find it.
7 test methods for black box testing
There are 7 test methods for black box testing, namely equivalence class division method, boundary value analysis method, error guessing method, causality diagram method, decision table driven method, function diagram method, and orthogonal experiment method. We will introduce them one by one below.
equivalence class division method
equivalence class division is to divide all possible input data, that is, the input field of the program into several parts (subsets), and then select a few representative data from each subset as test cases. This method is an important and commonly used black box test case design method.
7 test methods for black box testing
1. Divide equivalence classes:
Equivalence class refers to a subset of an input field. In this subset, each input data is equivalent for exposing errors in the program. And it is reasonable to assume that: testing the representative value of a certain equivalence class is equivalent to testing other values of this class. Therefore, all input data can be reasonably divided into several equivalence classes, and a small amount of representative test data can be used by taking one data in each equivalence class as the input condition of the test. Achieve better test results. The equivalence class can be divided into two different situations: valid equivalence class and invalid equivalence class.
Effective equivalence class: Refers to the set 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 functions and performance specified in the specification.
Invalid equivalence class: It is the opposite of the definition of effective equivalence class. When designing test cases, consider these two equivalence classes at the same time. Because the software must not only be able to receive reasonable data, but also be able to withstand unexpected tests. Such testing can ensure that the software has higher reliability.
2, the method of dividing equivalence classes:
Here are six principles for determining equivalence classes.
① In the case that the input condition specifies the value range or the number of values, one valid equivalence class and two invalid equivalence classes can be established.
② In the case where the input condition specifies the set of input values or the condition of "how it must be", a valid equivalence class and an invalid equivalence class can be established.
③When the input condition is a Boolean quantity, a valid equivalence class and an invalid equivalence class can be determined.
④ When a set of values (assuming n) of input data is specified, and the program needs to process each input value separately, n valid equivalence classes and one invalid equivalence class can be established.
⑤ In the case of stipulating the rules that the input data must comply with, a valid equivalence class (conforming to the rule) and several invalid equivalence classes (violating the rule from different angles) can be established.
⑥ When it is known that each element in the equivalence class has been divided into different ways in program processing, the equivalence class should be further divided into smaller equivalence classes.
3. Design test cases:
After the equivalence class is established, an equivalence class table can be established to list all the equivalence classes divided out: input conditions, valid equivalence classes, invalid equivalence classes
4. Design principles:
Then design test cases from the equivalence classes divided according to the following three principles:
① Specify a serial number for each equivalence class.
②Design a new test case to cover as many effective equivalence classes as possible that have not been covered, and repeat this step. Until all valid equivalence classes are covered.
③Design a new test case to cover only one invalid equivalence class that has not been covered. Repeat this step until all invalid equivalence classes are covered.
boundary value analysis method
The boundary value analysis method is a supplement to the equivalence class division method.
7 test methods for black box testing
(1) Consideration of boundary value analysis method:
Long-term test work experience tells us that a large number of errors occur on the boundary of the input or output range, rather than inside the input and output range. Therefore, by designing test cases for various boundary conditions, more errors can be detected. To design test cases using boundary value analysis methods, first determine the boundary conditions. Usually the boundary of the input and output equivalence classes is the boundary case that should be tested. The value that is exactly equal to, just greater than or just less than the boundary should be selected as the test data, rather than the typical value or any value in the equivalence class as the test data.
(2) The principle of selecting test cases based on the boundary value analysis method:
1. If the input condition specifies a value range, the value that has just reached the boundary of this range and the value that has just exceeded the boundary of this range should be used as the test input data.
2. If the input condition specifies the number of values, use the number, the number, one less than the number, and one more than the number as the test data.
3. According to each output condition stated in the specification, use the previous principle 1.
4. According to each output condition stated in the specification, the previous principle 2 shall be applied.
5. If the input field or output field given by the program specification is an ordered set, then one element and one element of the set should be selected as a test case.
6. If an internal data structure is used in the program, the value on the boundary of this internal data structure should be selected as the test case.
7. Analyze the specifications and find out other possible boundary conditions.
wrong speculation
Based on experience and intuition to speculate all possible errors in the program, so as to design a targeted method of test cases.
7 test methods for black box testing
The basic idea of the error speculation method: List all possible errors in the program and special situations that are prone to errors, and select test cases based on them. For example, many common mistakes in modules have been listed during unit testing. Errors found in previous product tests, etc., these are the summary of experience. Also, the input data and output data are 0. The input form is blank or the input form has only one line. These are all error-prone situations. The examples in these situations can be selected as test cases.
Causal Diagram
The equivalence class division method and boundary value analysis method introduced above all focus on the input conditions, but do not consider the connection between the input conditions, mutual combination, etc. Considering the mutual combination of input conditions, some new situations may arise. But 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 suitable for describing a combination of multiple conditions and correspondingly generating multiple actions. This requires the use of cause and effect diagrams (logical models).
7 test methods for black box testing
The result of the causality diagram method is the decision table. It is suitable for checking various combinations of program input conditions.
The basic steps of using cause and effect diagrams to generate test cases:
(1) In the analysis software specification description, those are causes (ie input conditions or equivalent classes of input conditions), those are results (ie output conditions), and an identifier is assigned to each cause and result.
(2) Analyze the semantics in the software specification description. Find out the corresponding relationship between cause and effect, and between cause and cause. Based on these relationships, draw a cause-and-effect diagram.
(3) Due to grammatical or environmental constraints, it is impossible to combine some causes and causes, and between causes and effects. In order to show these special cases, some signs are used on the causal diagram to indicate constraints or restrictive conditions.
(4) Convert the cause and effect diagram into a judgment table.
(5) Take out each column of the judgment table as a basis to design test cases. The test cases (partial, under the combination relationship) generated from the causality diagram include the TRUE and FALSE cases of all input data. The number of test cases is reduced, and the number of test cases increases linearly with the increase in the number of input data. increase.
judgment table driving method
1. Condition stub: List all the conditions of the problem. It is generally believed that the order of the listed conditions is not important.
2. Action stub: List the actions that may be taken according to the problem. There is no restriction on the order of these operations.
3. Condition item: List the values of the conditions listed in it, and the true and false values in all possible situations.
4. Action item: List the values for the conditions listed in it, and the true and false values in all possible situations.
5. Rules: the specific value of any combination of conditions and the corresponding operation to be performed. A column that runs through the condition item and the action item in the decision table is a rule. Obviously, as many sets of condition values are listed in the decision table, there are as many rules, condition items and action items as there are columns.
The basis and steps for establishing the judgment table:
1. Determine the number of rules. If there are N conditions, each condition has two values (0, 1), so 2N kinds of rules.
2. List all the condition piles and action piles.
3. Fill in the condition items.
4. Fill in the action items. Develop an initial judgment form.
5. Simplify. Combine similar rules or same actions.
Conditions suitable for the use of the prescribed judgment table design case:
1. The rule description is given in the form of a judgment table, or can be easily converted into a judgment table.
2, the sort order of the conditions does not affect the execution of those operations.
3. The order of the rules does not affect the execution of those operations.
4. When the conditions of a certain rule have been met and the operation to be performed is determined, there is no need to check other rules.
5. If a rule needs to perform multiple operations, the order in which these operations are performed does not matter.
function map method
Use the function diagram to visually show the function description of the program, and the use case of the machine to generate the function diagram. Function diagram is a black box and white box mixed use case design method.
7 test methods for black box testing
The function diagram is composed of a state transition diagram and a logical function model:
1. The state transition diagram is used to represent the input data sequence and its corresponding input data. In the state transition diagram, input data and current state determine output data and subsequent state.
2. The logical function model is used to represent the corresponding relationship between input conditions and output conditions in the state. The logical function model is only suitable for describing static descriptions, and the output data is only determined by the input data. The test case is composed of a series of states passed in the test and a pair of conditions that must be met by input/output data in each state.
The concept and method of logic coverage and path testing are used in the function diagram method. The designer is required to have a clear understanding of the logical structure of the program.
Generate use cases:
1. Generate partial test cases: In each state, generate partial test cases from the cause-effect diagram. The local test library is composed of a combination of cause values (input data) and corresponding result values (output data or status).
2. Test path generation: Use the above rules to generate a test path from the initialization state to the state.
3. Test case synthesis: Synthesize partial test cases of each state in the test path and function diagram. The result is a sequence of states from state to state, and the combination of input data and corresponding output data in each state.
4. The synthesis algorithm of test cases: the tree is constructed using conditions.
Orthogonal Test Method
Select an appropriate amount of representative points from a large amount of experimental data, and rationally arrange the design method of the test.
7 test methods for black box testing
1. Description of the extraction function, the structure factor-status table refers to the condition that affects the experimental index as a factor, and the condition that affects the experimental factor is called the state of the factor. When using the orthogonal experiment design method to design test cases, first find out the operating objects and external factors that affect the realization of the function according to the specifications of the tested software, and treat them as factors; and the value of each factor as the state . Divide the functional requirements in the software requirements specification, decompose and expand the overall and summary functional requirements layer by layer, and decompose them into specific, relatively independent, basic functional requirements. In this way, all the factors in the tested software can be determined, and provide a reference basis for determining the weight of each factor. Determining factors and status is the key to designing test cases. Therefore, it is required to determine the value as comprehensively and correctly as possible to ensure that the design of the test case is complete and effective.
2. Weighted screening, the selection of factors and states can be weighted according to their importance. The size of the weight can be determined according to the size of the effect of each factor and state, the size of the frequency of occurrence, and the needs of the test.
3. Use orthogonal table to construct test data set. Use orthogonal experiment design method to design test cases, which has the following advantages than using equivalence class division, boundary value analysis, causality diagram and other methods: it saves test work man-hours; it can control the generated test cases Quantity; test cases have a certain coverage.
Comprehensive strategy of test method:
1. First, perform equivalence division, including equivalence division of input and output conditions, and turn the infinite test into a finite test.
2, use boundary value analysis method.
3. Use error guessing and add some use cases.
4. Check the logic coverage of the use case design against the program logic, and strive to reach the coverage standard.
5. If there is a combination of input conditions in the program function description, the causality diagram and judgment table driving method can be selected.
6. For parameter configuration software, use the orthogonal experiment method to select fewer combinations to achieve the effect.
7. Function diagrams are a good way to design use cases. Different test data are designed based on the validity of conditions in different periods. Corresponding to a system with a clear business process, the scenario method is used throughout the test process, and various test methods are used in a comprehensive manner.