1. 設計程序時,目標為 defensive programming(防錯型編程)
- Write specifications for functions
- Modularize programs
- Check conditions on inputs/outputs (assertions)
TESTING/VALIDATION
? Compare input/output pairs to specification
? “It’s not working!”
? “How can I break my program?”
DEBUGGING
? Study events leading upto an error
? “Why is it not working?”
? “How can I fix myprogram?
2. 測試開始前:
- from the start, design code to ease this part
- break program into modules that can be tested and debugged individually
- document constraints on modules
- what do you expect the input to be? the output to be?
- document assumptions behind code design
3. 準備測試:
-
ensure code runs
? remove syntax errors
? remove static semantic errors
? Python interpreter can usually find these for you -
have a set of expected results
? an input set
? for each input, the expected output
4. 測試步驟
Paste_Image.png
5.測試處理:TESTING APPROACHES
- intuition about natural boundaries to the problem
def is_bigger(x, y):
""" Assumes x and y are ints
Returns True if y is less than x, else False """
can you come up with some natural partitions?
2. if no natural partitions, might do **random testing**
> - probability that code is correct increases with more tests
> - better options below
3. **black box testing**
? explore paths through specification
4. **glass box testing**
? explore paths through code
####GLASS BOX TESTING(黑盒測試)
- designed *without looking* at the code
- can be done by someone other than the implementer to
avoid some implementer biases
- testing can be reused if implementation changes
- paths through specification
? build test cases in different natural space partitions
? also consider boundary conditions (empty lists, singleton
list, large numbers, small numbers)
![Paste_Image.png](http://upload-images.jianshu.io/upload_images/4585153-12368d5c40cba40c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
####GLASS BOX TESTING
- use code directly to guide design of test cases
- called path-complete if every potential path through code is tested at least once
- what are some drawbacks of this type of testing?
? can go through loops arbitrarily many times
? missing paths
- guidelines
? branches
>exercise all parts of a conditional
? for loops
? while loop
![Paste_Image.png](http://upload-images.jianshu.io/upload_images/4585153-67da29e53fc69ad3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)