Structured Testing


Structured Testing

Structural testing on the other hand is concerned with testing the implementation of the program. The intent of structural testing is not to exercise all the different input or output conditions but to exercise the different programming structures and data structures used in the program. The other names of structural testing are also called clear box testing, open box testing, logic driven testing or path driven testing. This type of testing requires knowledge of the code. It is more concerned with how the system does it rather than the functionality of the system.

Structural testing provides more coverage to the testing. It is possible to miss out one node while testing the requirements drafted in SRS. Since structural testing aims to cover all the nodes and paths in the structure of code. Structural testing on the other hand is concerned with testing the implementation of the program. The intent of structural testing is not to exercise all the different input or output conditions but to exercise the different programming structures and data structures used in the program.

Developers use structural testing in component testing and component integration testing, especially where there is good tool support for code coverage. Structural testing is also used in system and acceptance testing. However, the structures are different. For example, the coverage of menu options or major business transactions could be the structural element in system or acceptance testing.


Structural Testing Techniques

Statement Coverage

One of the most important functions that a tester needs is an understanding of the app or website that they are testing. This understanding provides context and includes information such as competitive benchmark data, industry knowledge and company details. An understanding like this ensures that the tester is able to take in all manner of inputs relating to the app or website when he or she is performing the actual test. Contextual knowledge allows testers to provide details surrounding results that they may find and whether or not they are applicable.

Designing

It aims to test all the statements present in the program. Adequacy Criterion should be equal to 1 to ensure 100% coverage. It is a good measure of testing each part in terms of statements but it is not a good technique for testing the control flow.

Branch Coverage

It is also known as Decision coverage testing. Branch coverage aims to test all the branches or edges at least once in the test suite or to test each branch from a decision point at least once. It provides a solution for the problem faced in Statement coverage.
Branch Testing provides better coverage than Statement testing but it too has its shortcomings. It does not provide good coverage from different conditions that lead from node 1 to node 2 as it covers that branch only once.

Condition Coverage

It aims to test individual conditions with possible different combinations of Boolean input for the expression.
It is a modification of Decision coverage. But it provides better coverage. However when compound conditions are involved, the number of test cases may increase exponentially. Which is not favourable.

Path Coverage

Path coverage aims to test the different path from entry to the exit of the program. Which is a combination of different decisions taken in the sequence.
For example, a loop can go on and on. Which helps in finding out the redundant test cases. So, cyclomatic complexity helps aiming to test all linearly independent paths in a program at least once. These were some of the test coverage under this Testing.


Pro’s and Con’s