Wk 11 Glass Box Testing, Flow Graphs, Test Coverage

1
Wk 11 Glass Box Testing, Flow Graphs, Test
Coverage

• SW Engineering of Standalone Programs

2
Basis set for statement coverage testing

• Draw the flow graph
• Count the bounded regions including the outside
  region
• N is the number of linearly independent paths
  through the program control structure
• A linearly independent path includes one node of
  the control flow graph not contained in any other
• Create a basis set of linearly independent paths
• Prepare test cases to force execution of each
  path in the basis set.
• Execution of these test cases yields ______
  coverage

3
Flow GraphMcCabes is25
4
Flow Graph Revelations
5
Complexity impact
6
Uses of Test Coverage Measurement

• Measure test suite completeness
• Identify risk areas
• Combine execution counts with complexity
• Understand complex code segments that are
  frequently executed
• Understand criticality
• Assist in creating new test cases
• Assist in manual detection of faults
• Prioritize test cases for regression tests

7
Some More Test Coverage terms
8
Test Coverage MeasuresCompleteness of Test Suite
9
Test Coverage MeasurementMinimize and select
regression tests
377 Total Tests Blocks Decisions P-uses
All-uses 75 65 38 44
160 Total Tests Blocks Decisions P-uses
All-uses 75 65 38 44
5 of original tests provide 85 of original
coverage
18 Total Tests Blocks Decisions P-uses
All-uses 62 52 30 37
42 of the original tests provide identical
coverage
10
Unit Test Coverage vsSystem Test Errors
11
System Test Observed Expected Failures
12
System Test Failure Rate over Active Hrs
13
System Test Case Completion Graph
14
HW 7 start of code

• getop(s, lim) /get next operator or operand /
• char all
• int lim
• int i, c
• while ((c getch ( ) ) c \t c
  \n)
• if (c ! . (clt0 cgt9))
• return (c)
• s0 c
• for (i1 (cgetchar()) gt 0 c lt9 i)
• if (i lt lim)
• si c
• if ...

15
Inspections
16
What are inspections?

• Means of verifying work products
• Manual examination technique
• One piece at a time
• Small group of peers at least 4

17
Purpose

• Verification of a work product against
• established criteria
• product specifications

18
How performed?

• Planning
• Overview
• Preparation
• Meeting
• Re-work
• Follow up

19
Roles of participants

• Author
• Moderator
• Reader
• Recorder
• Inspector

20
The meeting

• Each participant reports preparation time
• Reader paraphrases
• Pace should be effective
• Not too slow, not too fast
• Inspectors look, listen, and think simultaneously
• Author and inspectors speak up if they disagree
  with readers paraphrase need to decide which
  is correct. If Reader, Recorder notes location
  brief description of issue
• Moderator can adjust pace and atmosphere

21
End of meeting

• Recorders list goes to author
• After rework, at a minimum, author reviews
  changes with one inspector.
• Better inspect the changed item

22
Benefits

• Errors found at faster rate
• Errors found early are cheaper to fix
• Cross-training
• Learn good and bad techniques by seeing them,
  e.g. coding techniques

23
A Word about Extreme Programming

• My personal view of extreme programming is that
  Beck Cunningham managed to incorporate many
  effective software engineering tasks into short
  iterations with high feedback.
• One example pair programming is ...