2. Types of faults and how to clasify them
The purpose of testing
Unit testing
Integration testing strategies
Test planning
When to stop testing
3. Wrong requirement: not what the customer
wants
Missing requirement
Requirement impossible to implement
Faulty design
Faulty code
Improperly implemented design
4. Objective of testing: discover faults
A test is successful only when a fault is
discovered
◦ Fault identification is the process of determining
what fault caused the failure
◦ Fault correction is the process of making changes
to the system so that the faults are removed
6. Algorithmic fault
Computation and precision fault
◦ a formula’s implementation is wrong
Documentation fault
◦ Documentation doesn’t match what program does
Capacity or boundary faults
◦ System’s performance not acceptable when certain limits
are reached
Timing or coordination faults
Performance faults
◦ System does not perform at the speed prescribed
7. An algorithmic fault occurs when a
component’s algorithm or logic does not
produce proper output
◦ Branching too soon
◦ Branching too late
◦ Forgetting to initialize variable or set loop
invariants
◦ Comparing variables of inappropriate data types
8. Module testing, component testing, or unit
testing
Integration testing
System Testing
◦ Function testing
◦ Performance testing
Acceptance testing
Installation testing
9.
10. Egoless programming: programs are viewed
as components of a larger system, not as the
property of those who wrote them
11. Independent test team
◦ avoid conflict
◦ improve objectivity
◦ allow testing and coding concurrently
12. Closed box or black box: functionality of the
test objects
◦ Equivalence Class, Boundary Value Analysis,
Scenario-based, Decision Table based, State
Machine based…
Clear box or white box: structure of the test
objects
◦ Control Flow
Basis Path, Branch, Statement, Decision…
◦ Data Flow
Du Path, All-uses Path
13. Black box: external behavior description
State box: black box with state information
White box: state box with a procedure
21. Component Driver: a routine that calls a
particular component and passes a test case
to it
Stub: a special-purpose program to simulate
the activity of the missing component
24. Only A is tested by itself
Stubs of B, C and D are used at first level
N-1 stubs required (N=Number of nodes)
Locating faults?
25. Drivers are used to call the child functions
Drivers are relatively intelligent
N-leaves drivers
Locating faults?
26. Viewed system as three layers
Employ BU where
writing drivers is
not costly
Employ TD where
stubs are easier to
Write
Locating faults?
27. • Adjacency Matrix
• NxN matrix that tells which components call
the other components
• Pairwise Integration
• Test each pair (i.e. each edge)
• E testing sessions
• Neighborhood based Integration
• Integrate each neighborhood
• The nodes at one edge distance from the
node to be integrated
• N-sink nodes sessions
28. Establish test objectives
Design and Write test cases
Test test cases
Execute tests
Evaluate test results
29. Test plan explains
◦ who does the testing
◦ why the tests are performed
◦ how tests are conducted
◦ when the tests are scheduled
30. What the test objectives are
How the test will be run
What criteria will be used to determine when
the testing is complete
32. No time left
No money left
Statistical Criteria
◦ Number of defects found per week becomes
lower than a set threshold
33. The Ariane-5’s flight control system was
tested in four ways
◦ equipment testing
◦ on-board computer software testing
◦ staged integration
◦ system validation tests
The Ariane-5 developers relied on insufficient
reviews and test coverage
34. It is important to understand the difference
between faults and failures
The goal of testing is to find faults, not to
prove correctness
35. UCF Slides
Software Testing, A Craftsman’s Approach by
Jorgensen
Software Testing Tools by Prasad