Posts Tagged ‘Structural Testing’
Structural Testing
Structural testing is white box testing, not black box testing, since black boxes are considered opaque and do not permit visibility into the code. Structural testing is a dynamic technique in which test data selection and evaluation are driven by the goal of covering various characteristics of the code during testing. Assessing such coverage involves the instrumentation of the code to keep track of which characteristics of the program text are actually exercised during testing. The inexpensive cost of such instrumentation has been a prime motivation for adopting this technique. More importantly, structural testing addresses the fact that only the program text reveals the detailed decisions of the programmer. For example, for the sake of efficiency, a programmer might choose to implement a special case that appears nowhere in the specification. The corresponding code will be tested only by chance using functional testing, whereas use of a structural coverage measure such as statement coverage should indicate the need for test data for this case. Structural testing is also known as clear box testing, also known as glass box testing. Structural testing is a way to test software with knowledge of the internal workings of the code being tested. Structural coverage measures for a rough hierarchy, with a higher level being more costly to perform and analyze, but being more beneficial, as described below.
• Statement Testing
Statement Testing is a structural or white box technique, because it is conducted with reference to the code. Statement testing requires that every statement in the program be executed. While it is obvious that achieving 100 percent statement coverage does not ensure a correct program, it is equally obvious that anything less means that there is code in the program that has never been executed.
• Branch Testing
Achieving 100 percent statement coverage does not ensure that each branch in the program flow graph has been executed. For example, executing an “if…then” statement, (no “else”) when the tested condition is true, tests only one of two branches in the flow graph. Branch testing seeks to ensure that every branch has been executed. Branch coverage can be checked by probes inserted at points in the program that represent arcs from branch points in the flow graph. This instrumentation suffices for statement coverage as well.
• Conditional Testing
In conditional testing, each clause in every condition is forced to take on each of its possible values in combination with those of other clauses. Conditional testing thus subsumes branch testing; and therefore, inherits the same problems as branch testing. Instrumentation for conditional testing can be accomplished by breaking compound conditional statements into simple conditions and nesting the resulting “if” statements.
• Expression Testing
Expression testing requires that every expression assume a variety of values during a test in such a way that no expression can be replaced by a simpler expression and still pass the test. If one assumes that every statement contains an expression and that conditional expressions form a proper subset of all the program expressions, then this form of testing properly subsumes all the previously mentioned techniques. Expression testing does require significant run-time support for the instrumentation.
• Path Testing
Path testing has been one of the first test methods, and even though it is a typical white box test, it is nowadays also used in black box tests. The procedure itself is similar to the walk-through. First, a certain path through the program is chosen In path testing, data is selected to ensure that all paths of the program have been executed. In practice, of course, such coverage is impossible to achieve for a variety of reasons. First, any program with an indefinite loop contains an infinite number of paths, one for each iteration of the loop. Thus, no finite set of data will execute all paths. The second difficulty is the infeasible path problem: it is undecided whether an arbitrary path in an arbitrary program is executable. Attempting to generate data for such infeasible paths is futile, but it cannot be avoided. Third, it is undecided whether an arbitrary program will halt for an arbitrary input. It is therefore impossible to decide whether a path is finite for a given input.
Structural Testing
Structural testing is white box testing, not black box testing, since black boxes are considered opaque and do not permit visibility into the code. Structural testing is a dynamic technique in which test data selection and evaluation are driven by the goal of covering various characteristics of the code during testing. Assessing such coverage involves the instrumentation of the code to keep track of which characteristics of the program text are actually exercised during testing. The inexpensive cost of such instrumentation has been a prime motivation for adopting this technique. More importantly, structural testing addresses the fact that only the program text reveals the detailed decisions of the programmer. For example, for the sake of efficiency, a programmer might choose to implement a special case that appears nowhere in the specification. The corresponding code will be tested only by chance using functional testing, whereas use of a structural coverage measure such as statement coverage should indicate the need for test data for this case. Structural testing is also known as clear box testing, also known as glass box testing. Structural testing is a way to test software with knowledge of the internal workings of the code being tested. Structural coverage measures for a rough hierarchy, with a higher level being more costly to perform and analyze, but being more beneficial, as described below.
-
Statement Testing
-
Branch Testing
-
Conditional Testing
-
Expression Testing
-
Path Testing
