Class Notes (1,100,000)
CA (620,000)
UTSG (50,000)
CSC (1,000)
Lecture 13

CSC302H1 Lecture 13: 2014.02.25

Computer Science
Course Code
Matt Medland

This preview shows half of the first page. to view the full 3 pages of the document.
Developer Testing
oTest Driven Development (TDD)
1. Developer write Unit Test (initially fails)
this is an example of Test Case First Strategy
2. Write minimum code to pass Unit Test
3. Refactor (write more code) to meet full speci%cation
oTest Case First Strategy
Test Case First Strategy – pros:
Minimize the time to defect discovery
Forces to think about requirements, expose
requirement problems
"daily smoke test"  reveal simple failures
Test-case %rst stragegy valuable, but not enough
oDeveloper Testing Limitations
Developers emphasis on clean tests
Clean Test = test to see if code works
Dirty Test = test for ways the code will break
Developers overestimate Test Coverage
Structural Coverage Strategies
oWhite Box Testing b/c relys on knowledge of the code
oStructured Basis Testing:
Minimal set of test to cover every branch
1 test for a straight path (all if fails)
1 test for each keyword: if, while, repeat, for,
and, or
1 test for each branche of case-switch
Ex. 1 + 3 = 4 test cases
1. x=3, y=2, z=1 (satis%es %rst 2 if's)
2. x=3, y=3, z=4 (satis%es %rst if, fails
second if)
3. x=2, y=3, z=4 (fails %rst if, satis%es third
4. x=2, y=3, z=4 (fails %rst if, fails second
oMay test every possible condition
Branch Coverage: for each IF-ELSE statement
1 case for TRUE, 1 case for FALSE
Condition Coverage: for each condition variable
valuable in an expression in a IF-ELSE statement
1 case for TRUE, 1 case for FALSE
oData$ow Testing
Normal Data Life:De%ned once  Used N times  Killed
Test each thing that can happen to data:
De&ned (D): data is initialized but not yet used
Used (U): data is used in a computation
Killed (K): space is released
Entered (En): working copy created on entry to
a method
Exited (Ex): working copy removed on exit
from a method
Poential Defects:
D-D: variable is de%ned twice
D-Ex, D-K: variable de%ned but not used
En-K: destroying a local variable that
wasn't de%ned
En-U: for local variable, used before its
K-K: unnecessary killing, may hang
K-U: using data after it has been
U-D: rede%ning a variable after it has been
Testing all D-U paths  Minimal set of test to cover
every D-U path = 1 test for each path from each
De%nition to each Use of variable
Ex. Structured Basis Testing = 2 (straight path
Ex. All DU testing = 4 test cases
oBoundary Checking
Boundary Analysis: every boundary needs at least 3
Bounary, Boundary + 1, Boundary – 1
Ex. if (x < MAX) {...}
Cases for x: MAX+1, MAX-1, MAX
Compound Boundaries: variables may have
combined boundaries
Functional Coverage Strategies
oBlack Box Testing b/c test cases rely on the requirements
of the code
oUse Cases as Test Cases
1. Test for Basic Flow
2. Test for each Alternate Flow
3. Test the Post Conditions
Is this meet through all paths of the Use Case?
4. Break the Pre Conditions  What happens? Could
this happen?
5. Identify options for each Input Choice
Test combinations of options for each Test Case
User acceptance testing
"Business as usual" functional testing
Manual black-box tests
Can record automated script for common
Likely to be incomplete (gaps/inconsistencies
btwn cases)
Use cases don't describe enough detail of use
You're Reading a Preview

Unlock to view full version