The white box strategy, or approach to logic-based testing, allows you to explore the internal structure of the program. In this case, the tester receives test data by analyzing the program logic (unfortunately, the program specification is not used in this case).
Let us compare the method of building tests based on this strategy with exhaustive input testing that is a criterion of black box strategy. The uninitiated reader may think that it is enough to build a set of tests in which each statement is executed at least once. It is not difficult to prove that this is not true. Without going into details, we only point out that exhaustive input testing can be matched to exhaustive path testing. It is understood that the program is fully tested if the tests help to execute all possible paths of this program through its control flow graph.
The last assertion has two weak points. One of them is that there is an astronomical number of non-repeating paths in the program. In order to make sure of this, we will consider the control flow graph in the simplest program (see Fig. 1.) Each vertex, or circle, designates a program section containing a sequence of linear operators that can end with a branch operator. Arcs ending with arrows correspond to control flows. Apparently, the graph describes a program containing 10-20 statements, including the WHILE (or DO WHILE) loop, which is executed at least 20 times (the figure shows it in a dark color). Inside the loop, there are several IF statements (in the figure, the corresponding nodes of the graph are represented by empty circles). In order to determine the number of non-repeating paths in program execution, we calculate the number of non-repeating paths from point A to B under the assumption that all orders are mutually independent. This number is calculated as the sum of 520 + 519 + … + 51 = 1014, or 100 trillion, where 5 is the number of paths inside the loop. Since it is difficult for most people to estimate this number, let us give an example: if we assume that we spend five minutes on each test, then we need about one billion years to build a test suite. Selenium testing service can be useful for you to examine web products across a lots of browsers, mobile devices and platforms.
// i = 1; while (i<=20) {
≤20 раз
А
B // i ++; }
Fig 1. Control flow graph of a simple program
Of course, in real-world programs conditional transitions cannot be mutually independent, i.e., the number of execution paths will be somewhat less. Contrariwise, real-world programs are much bigger than the simple program shown in Fig. 1. Consequently, exhaustive testing of paths, as well as exhaustive input testing, is not only undoable, but also impossible.
