CSC 395 – Software Engineering Lecture 27: White-Box Testing

In This Lecture Evaluate approaches for white-box testing How should we test when we can see the code? Methods of developing test suites When white-box testing is appropriate

Test Case Design Black-box testing – test to specifications Check functionality of code Test cases derived from original requirements, analysis, and design White-box testing – test code as it is written Use internals of the code to drive tests Premise: if checked 100%, there are no errors But cannot do full checks in finite time!

Software Defects Logic errors & bad assumptions inversely proportional to chance path is executed Common cases usually correct Rare or exceptional cases contain the bugs Remember the Pareto property! But, often believe path is unlikely to be executed when it is executed regularly Typographical error are random - Jones

White-box Testing Test all independent paths at least once Each line of code run in test suite Also called statement coverage Test all logical decisions All ifs should have both decisions checked Also called branch coverage Test all loops at boundaries & within operational bounds Consider normal & abnormal initial values Test all data structures

Cyclomatic Complexity Compute the cyclomatic complexity: number of simple decisions + 1 -or- number of enclosed areas + 1 V(G) = 4

Cyclomatic Complexity Studies indicate that the higher V(G), the higher the probability for errors Code has more opportunities for errors Errors tend to clumped in methods Spend more time testing these complex methods V(G) more complex & error prone # of Modules

White Box Testing Statement coverage Execute each statement in program at least once Branch coverage Executes each branching statement in each direction at least once Path coverage Executes all possible combinations of branches Not possible in practice

Coverage Measures All Statements:1, 2, 3, 4, 5 All Branches: 1, 2, 3, 4, 5 1, 3, 5 All Paths: 1, 2, 3, 4, 5 1, 3, 5 1, 2, 3, 5 1, 3, 4, 5

Loop Testing Nested Loops Concatenated Loops Unstructured Loops Simple loop

Loop Testing: Simple Loops If loop can be executed at most n times, try: Skipping loop entirely Exactly one pass through the loop Two passes through the loop Pass through loop m times ( m < n ) ( n -1), n, and ( n +1) passes through the loop

Loop Testing: Nested Loops 1.Starting from innermost loop, set outer loops to minimum iteration value. 2.Test ( min +1), average, ( max -1) & max runs of innermost loop, with outer loops at minimum values. 3.Repeat step 2 with next innermost loop

Loop Testing: Complex Loops For concatenated loops If loops independent, test independently Otherwise (loop dependent), test as nested loops For unstructured loops Fire the programmer, designer, & anyone else Burn the code Rewrite from design

Integration Testing Testing the combination of several modules Assumes unit-level testing has been done Incrementally test & add modules to system Add multiple when looking to burn several weeks Three traditional approaches to this process Top-down Bottom-up Sandwich

Top-Down Integration Modules tested with stubs for children Stubs replaced one-by-one “depth first” Re-run subset of tests as modules integrated A B C DE FG

Bottom-Up Integration Drivers test modules at the bottom Drivers replaced one at a time “depth first” Modules grouped into clusters and integrated A B C DE FG

Sandwich Integration Stubs used to help test modules at top Drivers test modules at the bottom Bottom modules clustered and integrated A B C DE FG

For Next Lecture Examine other analysis methods “Classical methods” for non-OO development Large amount of existing code still not OO Discusses many useful techniques Ultimately important to learn for workplace