-
Notifications
You must be signed in to change notification settings - Fork 0
10 27 16 white box and grey box testing
Read "Head First" chapters 7-8.
Read Ron Patton "Software Testing" chapter 7
Still do not read code (maybe)
Similar to black box but looks below the surface, invisible to users. Looks at internal I/O within the system and subsystems.
- saved persistently or recoverable.
- Correct format and contents file permission
- database on other server or networks
- check format for all outgoing data
- check data details including responses
- check sums
- check time stamp
secure risk and resource leak
- delete what is supposed to be deleted
- uninstall should leave system clean
http headers, cache expiration, cookies
penetration testing wiki
security team can access everything visible from browsers. Like javascript, html...
knowledge of venerability
====================
"coverage": all statements, branchs, def-use path,
intuition: If you have never excute a given *** in the program, how can you konw it won't go wrong?
Basic approach:
- Find a coverage tool for your language or platform
- Run all the white and grey box tests
- Find that never tested case and invent new input to test them
Statement coverage .vs. Branch coverage .vs. Path coverage
- Are all statements covered by tests before? If not, why? go 2.
- Are the statements reachable? Can be checked by static analysis.
- If reachable, build new input test cases.
- If neither leg has been executed, then save as statement.
- If only one, try another
In both cases, in order to force a path, might need to back trace a series of conditions need to be -> path conditions and then solve the contrains
- defination:
- use:
Similary need to trace the path, but may have 'dead' path.
Valuable to consider all errors, handling either using exceptions.
clean after: relase memory, handlers... thread-safe code
Test tools will run test cases automatically, but will not write test code for you.
Useful for CI(continous Intgretion)
Tset cases should be independent.