1 Overview of black box testing
Black box testing is also called functional testing, through testing to detect whether each function can be used normally. In the test, the program is regarded as a black box that cannot be opened, and the program interface is tested without considering the internal structure and characteristics of the program, and only checks whether the program function is in normal use according to the requirements specification. Whether the program can properly receive input data and produce correct output information.
Black-box testing is triggered from the relationship between input data and output data from the user's perspective, trying to find the following types of errors:
- Incorrect or missing features
- interface error
- database access error
- performance error
- initialization and termination errors
Use-case design methods include:
- equivalence class division
- Boundary Value Analysis
- decision table
- causal diagram
- scene method
etc.
2 Equivalence class division
2.1 Equivalence classes
An equivalence class is a subset of an input domain in which tests that test that values representative of an equivalence class are equal to other values of that class are equivalent for uncovering program errors. Therefore, all input data can be reasonably divided into several equivalence classes, and one data in each equivalence class is taken as the input condition of the test, and a small amount of representative test data can be used to obtain better results.
Equivalence class division can be divided into:
- Effective equivalence class: It is a reasonable and meaningful set of input data for the specification of the program. The effective equivalence class can be used to check whether the program implements the functions and meanings specified in the specification.
- Invalid equivalence class: Contrary to the effective equivalence class, it refers to a collection of data that is meaningless and unreasonable for the specification of the program
2.2 Principles of division
- If a range of input values is specified, one valid equivalence class and two invalid equivalence classes can be defined
- If the input rules are stipulated, a valid equivalence class (conforming to the rules) and several invalid equivalence classes (violating the principle from different angles) can be divided
- If an organization of input data is specified, and the program treats different input values differently, then each allowed input value has one valid equivalence class and one invalid equivalence class
- If it is stipulated that the input data is an integer, it can be divided into three effective equivalence classes: positive integer, zero, and negative integer.
- When dealing with tables, valid classes are empty table, table with one item, table with multiple items, etc.
3 Boundary value analysis
3.1 Boundary value analysis design principles
Boundary value analysis, as a supplement to equivalence class division, selects the boundary value of equivalence classes as test cases.
Based on boundary value analysis, there are the following principles:
- If the input condition specifies a range of values, values that just reach the boundary of the range, and values that just exceed the boundary of the range, should be selected as test input data
- If the number of values is specified in the input condition, use the largest number, the smallest number, one less than the smallest number, and one more than the largest number as the test data
- If the specification specifies an ordered collection of input domains or output domains, the first and last elements of the collection should be selected as test cases
- If internal data structures are used in the program, values on the boundaries of the internal data structures should be selected as test cases
3.2 Two methods of boundary analysis
Generally include:
- General boundary value analysis: generally take
Min,Min+,Normal,Max-,Max - Robust boundary value analysis: In addition to general boundary value analysis, it also includes
Min-,Max+
4 Decision tables
Decision table, also known as decision table, is a technique for analyzing different operations under various logical conditions. A decision table consists of four parts, including:
- Condition stub: lists all conditions for a problem, the order of the conditions does not matter
- Action pile: List all possible actions specified in the question, and the order of arrangement is not restricted
- Condition item: Lists the true and false values of the value of the condition pile in all possible cases
- Action items: lists the actions that should be taken when the various values of the condition items are organically related
On the other hand, the rules in the decision table refer to the specific values of any combination of conditions and the corresponding actions to be executed. The columns that run through the condition items and action items in the decision table are rules. How many conditions are listed in the decision table? Values correspond to as many rules as there are columns for conditional items.
For example, the following is a printer test case made using a decision table:
5 Causal Diagram
5.1 Definition
The cause-and-effect diagram uses the graphical method to analyze various combinations of inputs, which is suitable for describing the combination of various input conditions and correspondingly generating multiple actions. The benefits of the cause-and-effect diagram are as follows:
- Consider the mutual combination and mutual restriction relationship between multiple inputs
- Guide the selection of test cases and point out the problems in the requirements specification description
- It can help testers follow certain steps to develop test cases efficiently
- The causal diagram method is a method of strictly converting natural language specifications into formal language specifications, which can point out the incompleteness and ambiguity of specifications
5.2 Basic graphic symbols
Reason result graph:
ciBoth and eican take the value 0 or 1, 0 means that the state does not appear, and 1 means that the state appears.
Constraint graph:
6 scene method
Different trigger sequences and processing results of the same event form an event flow, and the scene when each event flow is triggered forms a scene.
Scenario method generally includes basic flow and alternate flow (also called alternate flow). Starting from a process, the process is determined by describing the path passed, and the entire scene is formed by traversing all the basic flows and alternate flows. The basic design steps of the scene method are as follows:
- According to the instructions, describe the basic flow of the program and each alternative flow
- Generate different scenarios based on the basic flow and various alternative flows
- Generate corresponding test cases for each scenario
- Re-review all the generated test cases, remove redundant test cases, and determine the test data value for each test case after the test cases are determined
The diagram is as follows:
