Structural testing is also known as while-box testing and it examines the internal structure of the program. In this strategy, we derive test cases from an examination of the program’s logic. No attention is payed to specifications. For example, if the first statement of the code is if ( x £ 100 ), then we may try testing the program with a test case of 100.

Therefore, the knowledge to the internal structure of the code can be used to find the number of test cases required to generate a given level of test coverage.

In functional testing, all specifications are being checked against the implementation, so why do we really require structural testing. It is necessary because there might be part of the code, which are not fully exercised by the functional tests. There may be sections of code, which are surplus to requirements. That is to say, we have checked the program against the functional tests and no errors are reveled then inspection by structural tests reveals a piece of code that is not even needed by the specifications and hence not examined by functional testing. This can be regarded as an error since it is a deviation from requirements.

If we test the program while running then it is called reviewing the software design, architecture or code for bugs without executing it. It is sometimes referred as structural analysis.

Path Testing: Path testing is a name given to a group of test techniques based on selecting a set of tests paths through the program. If the set of paths is properly chosen, then it means that we have achieved some measures of test thoroughness.

Path testing is used for module testing on unit testing. It requires complete knowledge of the program’s structure. The effectiveness of path testing deteriorates as the size of the software under test increases. It is not useful for system testing.

This type of testing involves:

1.    Generating a set of paths that will cover every branch in the program.
2.    Finding a set of test cases the will execute every path in this set of program paths.

Flow Graph: The control flow of a program can be analyzed using a graphical representation known as flow graph. The flow graph is a directed graph in which nodes are either entire statements or fragments of a statement, and edges represents flow of control. If i and j are nodes in the program graph, there is an edge from node i to node j if the statement, (fragment) corresponding to node j can be executed immediately after the statement (fragment) corresponding to node i.

A flow graph can easily be generated from the code of any problem. The basic contracts.

DD Path Graph: The flow graph generation is the first step of path testing. The second step is to draw a DD path graph from the flow graph. The DD path graph is known as decision to decision path graph. In this we concentrate only on decision nodes. The nodes of flow graph, which are in a sequence are combined into a single node.

Hence DD path graph is a directed graph in which nodes are sequence of statements and edges represent control flow between nodes.

Independent Paths: The DD paths graph is used to find independent paths. We want to execute all independent paths at least once during path testing.



An independent path is any path through the DD path graph that introduces at least one new set of processing statements or new conditions. Therefore an independent path must move along at least one edge that has not been traversed before the path is defined.

Independent paths is used to ensure that
(i)    Every statement in the program has been executed at least once.
(ii)    Every branch has been exercised for true and false conditions.

For more help in Structural Software Testing click the button below to submit your homework assignment