White box Test Case Design Method _ White Box

One, white box test

According to the internal working process of the SOFTWARE PRODUCT, test on the computer to verify that each internal operation meets the design specifications and whether all internal components have been inspected. This test method is white box test. The White box test considers the test object as an open box, allowing the tester to design or select test Cases and test all logical paths of the program using the logic structure and relevant information inside the program. By checking the state of the program at different points, determine whether the actual state is consistent with the expected state.

Either black-box or white-box testing, it is impossible to take all the possible input data for the so-called exhaustive test. Because the number of possible test input data often reaches astronomical numbers. Let's take a look at two examples below.

Suppose a program p has input x and y and output z, see figure 10-4-1. Run on a computer with a 32-bit word length. If x, y takes only integers, consider all the x, Y values as test data, according to the black box test method for exhaustive test, try to "dig" all the errors in the program comprehensively and without omission. The maximum possible number of test data sets (Xi,yi) that can be used in this way is:. If program P tests a set of x, y data for 1 milliseconds, and works 24 hours a day, 365 days a year, it takes 500 million years to complete the 264 group of tests.

Figure 10-4-1 Black box

For a program with multiple selections and loops nested, the number of different paths can also be astronomical. Set up a flowchart for the applet shown in Figure 10-4-2, which includes a loop that executes up to 20 times. The number of different execution paths it contains is up to the bar, and to test it out, overwrite all paths. If the test program takes 1 milliseconds to test each path, and also assumes 24 hours a day and 365 days of work a year, it will take 2 years to test all the paths of the applet shown in Figure 10-4-3,170.

Fig. 10-4-2 Test in white box test

The above analysis shows that the implementation of exhaustive test, because the workload is too large, it is unrealistic to implement. Any software development project is subject to deadlines, costs, human and machine conditions, although testing all possible data is required to fully expose all hidden errors in the program, but the facts tell us that it is impossible to do so.

The overall goal of software engineering is to make full use of the limited human and material resources, and to complete the development project with high efficiency, high quality and low cost. In the test phase, since the exhaustive test is not OK, in order to save time and resources and improve the efficiency of testing, it is necessary to carefully select a small amount of test data from a large number of available test cases, so that the test data can be used to achieve the best test results and can effectively expose hidden errors.

Second, logical coverage

Logical overlay is a technique for designing test cases based on the logical structure within the program. is a white box test. This method requires testers to have a clear understanding of the logical structure of the program, and even to master all the details of the source program. Due to the different objectives of coverage test, logic coverage can be divided into: statement coverage, decision coverage, judgment-condition coverage, conditional combination coverage and path coverage.

1. Statement Overlay

Statement coverage is the design of several test cases, running the program under test, so that each executable statement is executed at least once. This overlay, also known as dot overlay, enables every executable statement in a program to be executed, but it is the weakest logical overlay and has a limited effect and must be used interactively with other methods.

2. Decision covering

Decision coverage is to design a number of test cases, run the program, so that every decision in the program to take the true branch and take false branch at least once. A decision overlay is also known as a branch overlay.

The decision coverage is slightly stronger than the statement coverage, but the actual effect shows that only the determination of coverage, it is not guaranteed to be able to detect errors in the conditions of judgment. Therefore, a stronger logic coverage criterion is needed to test the internal conditions of judgment.

3. Conditional coverage

Conditional coverage is to design a number of test cases, run the program under test, so that every decision in the program can be evaluated at least once for each condition.

Conditions cover each condition in the decision, but may not meet the requirements of the decision overlay.

4. Decision-Condition coverage

Decision-Conditional coverage is the design of sufficient test cases to allow for at least one execution of all possible values of each condition in the judgment, while at least one execution of all possible judgments of each judgment itself. In other words, the combination of all possible conditional-value combinations that require each judgment is executed at least once.

Determination-condition coverage is defective. On the surface, it tests the values of all the conditions. But that is not the case. Some conditions are often concealed by some condition. Some conditions are missing when the value is wrong. In order to thoroughly check the values of all the conditions, we need to decompose the compound conditional expression given in the judgment statement to form a flow chart nested by several basic judgments. This allows you to effectively check that all the conditions are correct.

Figure 10-4-3 (a) examples of compound judgments

Figure 10-4-3 (b) as an example of a nested structure for a single condition decision

5. Multi-condition coverage

Multiple-condition coverage is the design of enough test cases to run the tested program so that all possible combinations of conditional values for each judgment are executed at least once.

This is a fairly strong coverage criterion that effectively checks whether the combination of possible conditional values is correct. It can cover not only the possible combinations of all the conditions, but also the desirable branches of all judgments, but the possible paths will be omitted. The tests are not yet complete.

6. Path Testing

Path testing is the design of enough test cases to overwrite all possible paths in the program. This is the strongest coverage criterion. However, when the number of paths is very large, it is very difficult to really complete coverage, the number of coverage path must be compressed to a certain limit. Let's do an analysis below.

Some discussions on the control structure test

1. Number of paths to the branch structure

When more than one is judged in the program, the branching structure can be divided into two types: nested branch structure and chain branch structure. As shown in Figure 10-4-4. For nested branch structure, if there are N decision statements, you need to n+1 a test case, but for the chain branch structure, if there are N decision statements, you need to have a test case to cover its path. When n is large, it cannot be tested.

(a) nested branching structure

(b) Chain-type branching structure

Figure 10-4-4 of the two types of branching

To reduce the number of test cases, the test design method can be used to extract partial paths for testing. Because the sampling is uniformly distributed, uniform sampling can be done assuming that the paths are of the same importance, or the importance of each path is temporarily unclear. If the importance of each path is clarified, a weighted method can be used to filter out some paths and then sample them with the following measures. The specific steps are as follows:

(1) Having n judgments in the coupling-type branching structure, and calculating the minimum natural number m that satisfies the relational formula;

(2) Set, take orthogonal table L4, and use it to design test data.

For example, there are three decision statements p1,p2,p3 in a coupled branching structure. It all path is 23 = 8. The first calculation of T, get t= 4. Take the orthogonal table L4, as shown in Figure 10-4-5 (a), each column as a judgment, each row as a desirable test case, then the orthogonal table L4 up to three judgments, replaced by P1,P2,P3. The P1,P2,P3 branch and the real branch of the decision-making are respectively recorded as S1, S2;s3, S4;S5, S6, using the false branch of each decision to replace the "0" in the orthogonal table L4, and substituting the real branch to replace "1" in the orthogonal table, a test path matrix is established, as shown in Figure 10-4-5 (b). This way, the number of test paths is reduced from the bar to the 3+1=4 bar.

Figure 10-4-5 (a) orthogonal table L4

Figure 10-4-5 (b) Path sampling matrix

2. Strategy for conditional testing

The conditions in the program are divided into simple conditions and compound conditions. A simple condition is a Boolean variable or a relational expression (which can be prefixed with not), and a compound condition is connected by a simple condition by a logical operator (and, or, not) and parentheses. If the condition is wrong, at least one of the ingredients in the condition is wrong. Possible types of errors in the condition are Boolean operator error, Boolean error, Boolean parenthesis error, relational operator error, arithmetic expression error.

If each Boolean and relational operator appears at most once in a judged compound condition expression, and there are no public variables, a test method called bro (branching and relational operators) can discover multiple Boolean or relational operator errors, as well as other mistakes.

Bro Policy introduces the concept of conditional constraint. A compound condition C with n simple conditions is bound to be the output constraint of the first simple condition in condition C. If in the execution of C, the output of each simple condition satisfies the corresponding constraint in D, then the conditional C's condition constraint D is covered by the execution of C. In particular, the output constraints of a Boolean or Boolean expression must be true (t) or False (f), and the output constraint for the relational expression is symbol >, =, <.

(1) Set the condition for. Where is the Boolean variable, the output constraint is, here, and or for T or F. is a possible constraint. The test that overrides this constraint (one run) will be T and F. A set of test cases is designed for each of the possible constraints set on the Bro policy requirements. If the Boolean operator is wrong, the three sets of test cases must have a set of results that will cause the failure.

(2) Set the condition for. Where the Boolean expression, and the arithmetic expression, the output constraint is, here, or T or F; <, = or >. Therefore, only a different set of constraints can be modified, and the set of constraints is exported. Because in, "t" equals "=" and "F" equals "<" or ">", the constraint is set to. Design 4 sets of test cases to check for possible errors in Boolean or relational operators.

(3) Set the condition for. All of which are arithmetic expressions, the output constraints are, here, and the constraints are <, =, >. The set of constraints that can be modified, and the set of constraints that are exported, are only different from those in. Because in, "T" is equivalent to ">", "F" equals "<" or "=", the constraint is set to. By designing test cases from this set of constraints, you can detect errors in the relational operators in.

3. Cycle test

There are 4 different types of loops: simple loops, chain loops, nested loops, and unstructured loops, as shown in Figure 10-4-6.

Graph 10-4-6 Classification of loops

For a simple loop, the test should include the following, where n represents the maximum number of times the loop allows.

(1) 0 cycles: Jump directly from the recycle inlet to the recycle exit.

(2) One cycle: find errors in the cyclic initial values.

(3) Two cycles: Check for errors that can be exposed in multiple loops.

(4) m-Cycle: At this time of the m

• Maximum cycles, cycles that are more than the maximum number of times, and one less than the maximum number of times.

For nested loops, you cannot simply extend the test method of a simple loop to a nested loop, because the number of possible tests grows geometrically multiple as the nesting level increases. This may result in an astronomical number of tests. A test method that helps reduce the number of tests is given below.

• In addition to the most inner loop, starting from the inner loop, the cycle of all the other layers is the smallest value;

• Full test of simple loops for the inner loop. The loop variable that maintains all outer loops at the time of the test is the smallest value. In addition, a similar test is done for cross-border values and illegal values.

• Step out and test the loop outside of it. The loop variable that keeps all the outer loops at the time of the test takes the minimum value, and all other nested loops of the loop variable take a "typical" value.

• Repeat until all layers have been tested and completed.

• Take the minimum number of cycles at the same time for all layers, or take the maximum number of cycles at the same time. For the latter test, because the test volume is too large, the need to specify the maximum number of cycles.

For chain cycles, two different situations are needed. If each cycle is independent of each other, the chain cycle can be tested in the same way as a simple loop. For example, if there are two loops in a chain state, the value of the loop variable of the previous loop can be used as the initial values for the latter loop. However, if several loops are not independent of each other, you need to use a test nested loop to handle them.

For unstructured loops, you should redesign test cases using structured programming methods.

Four, basic path test

If you compress the number of paths covered to a certain limit, for example, the loop body in the program executes only 0 times and once, it becomes the basic path test. It is based on the program control flow diagram, through analyzing and controlling the loop complexity of the construction, we derive the basic executable path set, and then design the test case method.

The test case designed to ensure that in the test, the program's every executable statement to execute at least once.

1. Control flow diagram of the program

A control flow diagram is a graphical method for describing program flow. The graphical symbols for the basic control constructs are shown in Figure 10-4-7. Symbol 0 is called a node of the control flow graph, and a set of sequential processing boxes can be mapped to a single node. The arrows in the control flow diagram are called edges, which represent the direction of the control flow, and there should be a converging node in the convergence of branches in the selected or multiple branching structure, even if no statements are executed. The area delineated by the edges node is called a region, and when the area is counted, the area outside the graph should also be recorded as a region.

Figure 10-4-7 Various graphical symbols for control flow graphs

If the conditional expression in the decision is a compound condition, that is, if the conditional expression is a logical expression that is connected by one or more logical operators (Or,and,nand,nor), the decision to change the compound condition is a series of nested judgments with only a single condition. For example, the determination of the compound condition of the graph 10-4-8 (a) should be drawn into the control flow diagram shown in Figure 10-4-8 (b). Conditional A and Condition B in conditional statement Ifaorb each have a single condition to determine the node.

Graph 10-4-8 Control flow diagram under composite logic

2. Computational program Loop Complexity

When performing the basic path test of a program, the loop complexity of the program gives the number of independent paths in the set of basic paths of the program, which is the upper bound of the number of test cases necessary to ensure that each executable statement is executed at least once in a program.

An independent path is a path that includes a set of statements or conditions that were not previously handled. As in the control flow diagram shown in Figure 10-4-9 (b), a set of independent paths is

Path1:1-11

Path2:1-2-3-4-5-10-1-11

Path3:1-2-3-6-8-9-10-1-11

Path4:1-2-3-6-7-9-10-1-11

The path Path1,path2,path3,path4 constitutes a basic set of paths for the control flow graph shown in Figure 10-4-9 (b). As long as the test cases are designed to ensure the execution of these basic paths, each executable statement in the program can be executed at least once, and the true and false branches of each condition can be tested. The basic path set is not unique, and for a given control flow graph, a different set of basic paths can be obtained.

(a) Process flow chart

(b) Control flow chart

Figure 10-4-9 Program flow chart and corresponding control flow diagram

Typically, loop complexity can be obtained in the following 3 ways.

(1) Define the loop complexity as the number of regions in the control flow diagram.

(2) to set E as the number of edges of the control flow graph and N to the node numbers of the graph, the loop complexity is defined as V (G) =e-n+2.

(3) a V (G) =p+1 If the P is set to the number of decision nodes in the control flow graph.

Because the control flow diagram shown in Figure 10-4-9 (b) has 4 regions. Its loop complexity is 4. It is the upper bound of the number of independent paths constituting the basic path set. The number of test cases that should be designed can be obtained accordingly.

3. Export Test Cases Use the logical overlay method to generate test cases to ensure the execution of each path in the basic path set.

Word version download address/files/jackc/white box test Case design method. doc

From:http://www.cnblogs.com/jackc/archive/2009/09/16/1567203.html