Testing and Debugging

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

1. 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)