In software testing , "
black box testing
" and "
white box testing
" are most often heard , which are the most basic testing methods in software testing.
So what exactly is a "black box" and what is a "white box"? The following is an introduction to its concepts and commonly used methods.
Black box testing:
Also known as
functional
testing and data-driven testing, it treats the software under test as a black box that cannot be opened, and mainly
designs
and tests test cases based on functional requirements.
Concept: Black-box testing is a test that is performed on software from outside the software, also known as functional testing or specification-based testing. The basic point of view is that any program can be regarded as a mapping from the input domain to the output value domain. In this view, the program under test is regarded as a black box that cannot be opened, and the content (implementation) in the black box is completely I don't know, I just know what the software is going to do. Because I can't see the contents of the box, I don't know how the software is implemented, and I don't care about the structure in the black box. I only care about the input data and output results of the software.
Check whether the software functions can work normally according to the requirements and specifications, and whether there are function omissions;
Detecting human-computer interaction errors, data structure and external
database
access errors, proper reception of data and maintaining the integrity of external information (such as databases or files), etc.;
Detect whether the behavior, performance and other characteristics meet the requirements, etc.; Detect errors in program initialization and termination, etc.
advantage:
① It has nothing to do with the specific implementation of the software. If the software implementation changes, the test case is still available;
② The design of black-box test cases can be carried out at the same time as the software implementation, so the total development time of the project can be compressed.
Common methods of black box testing
Equivalence Class Division
Boundary value analysis
cause and effect diagram
Decision table analysis
Equivalence Class Division
The internal structure of the program is not considered at all, and only the input range is divided according to the program specification. All possible input data, that is, the program input field, is divided into several disjoint subsets, called equivalence classes, and then from each Select a few representative data from each equivalence class as test cases for testing.
Partitioning principles: interval, value, set of values, restriction or rule, subdivision equivalence class
Boundary value analysis
Boundary values and equivalence classes are closely related, and the boundaries of the input equivalence class and the output equivalence class are the boundary cases to focus on testing. Many equivalence class boundaries are generated during the division of equivalence classes. Boundaries are the most error-prone, so you should pay attention to boundary values when selecting test data from equivalence classes.
The basic idea of performing boundary value analysis and testing on the basis of equivalence class division is to select values that are exactly equal to, just greater than, or just less than the boundary of the equivalence class as test data, rather than selecting typical values or arbitrary values in the equivalence class as test data. for test data.
For a program of n variables, the boundary value analysis test will generate 4n+1 test cases.
cause and effect diagram
(1) Determine the cause and effect in the software specification. Analyze which of the specifications are causes (ie, input conditions or equivalence classes of input conditions) and which are effects (ie, output conditions), and assign an identifier to each cause and effect.
(2) Determine the logical relationship between cause and effect. Analyze the semantics in the software specification, find out the corresponding relationship between the cause and the effect, and between the cause and the cause, and draw a cause-and-effect diagram based on these relationships.
(3) Determine each constraint in the causal graph. Some combinations of cause and cause and cause and effect are not possible due to syntax or environmental constraints. To show these special cases, some notation is used on the causal diagram to indicate constraints or constraints.
(4) Convert the causal diagram into a decision table.
(5) Design test cases according to the decision table.
Decision table analysis
Among all black box testing methods, decision table based testing is the most rigorous and logical testing method.
A decision table is a table formed by listing various combination values of all inputs and corresponding output values as conditions.
It can list complex problems according to all possible situations, concise and avoid omission. Therefore, a complete set of test cases can be designed using the decision table.
step:
(1) List all condition piles and action piles.
(2) Determine the number of rules.
(3) Fill in the condition items.
(4) Fill in the action items to get the initial decision table.
(5) Simplify the decision table and merge similar rules.
For a decision table with n conditions, there are corresponding 2n rules
Decision table merging principle: If there are more than two rules in the table with the same action, and there is a very similar relationship between the condition items, they can be merged.
White box testing:
Also known as structural test or logic-driven test, it is to know the internal working process of the product, and it can be tested to detect whether the internal action of the product is carried out normally in accordance with the provisions of the specification. All works correctly as intended, regardless of its functionality.
Common methods of white box testing
Basic coverage standards: logic drive, loop, base road test, etc., mainly used for software verification.
The "white box" method has a comprehensive understanding of the internal logical structure of the program and tests all logical paths.
The "white box" approach is exhaustive path testing. When using this scheme, the tester must check the internal structure of the program, start with checking the logic of the program, and obtain test data. The number of independent paths through the program is astronomical. But even if every path is tested there may still be errors.
reason:
First, exhaustive path testing can never find out that the program violates the design specification, that is, the program itself is a wrong program.
Second, exhaustive path testing is unlikely to detect errors in programs due to missing paths.
Third, exhaustive path testing may not find some data-related errors.
Logic-driven approach to white-box testing
statement coverage
decision coverage
Condition coverage
Decision/Condition Coverage
Condition combination coverage
path coverage
If you have any questions, welcome to add QQ group test entry God 755431660 to learn together ~
