詳見-廖雪峯python教程的【錯誤、調試和測試章節】
1.出錯的時候，一定要分析錯誤的調用棧信息，才能定位錯誤的位置。
記錄錯誤
如果不捕獲錯誤，自然可以讓Python解釋器來打印出錯誤堆棧，但程序也被結束了。既然我們能捕獲錯誤，就可以把錯誤堆棧打印出來，然後分析錯誤原因，同時，讓程序繼續執行下去。
Python內置的logging模塊可以非常容易地記錄錯誤信息：
拋出錯誤
因爲錯誤是class，捕獲一個錯誤就是捕獲到該class的一個實例。因此，錯誤並不是憑空產生的，而是有意創建並拋出的。Python的內置函數會拋出很多類型的錯誤，我們自己編寫的函數也可以拋出錯誤。
如果要拋出錯誤，首先根據需要，可以定義一個錯誤的class，選擇好繼承關係，然後，用raise語句拋出一個錯誤的實例：
#err_raise.py
class FooError(ValueError):
pass
def foo(s):
n = int(s)
if n==0:
raise FooError('invalid value: %s' % s)
return 10 / n
foo('0')
最後，我們來看另一種錯誤處理的方式：
#err_reraise.py
def foo(s):
n = int(s)
if n==0:
raise ValueError('invalid value: %s' % s)
return 10 / n
def bar():
try:
foo('0')
except ValueError as e:
print('ValueError!')
raise
bar()
在bar()函數中，我們明明已經捕獲了錯誤，但是，打印一個ValueError!後，又把錯誤通過raise語句拋出去了，這不有病麼？
其實這種錯誤處理方式不但沒病，而且相當常見。捕獲錯誤目的只是記錄一下，便於後續追蹤。但是，由於當前函數不知道應該怎麼處理該錯誤，所以，最恰當的方式是繼續往上拋，讓頂層調用者去處理。好比一個員工處理不了一個問題時，就把問題拋給他的老闆，如果他的老闆也處理不了，就一直往上拋，最終會拋給CEO去處理。
raise語句如果不帶參數，就會把當前錯誤原樣拋出。此外，在except中raise一個Error，還可以把一種類型的錯誤轉化成另一種類型：
try:
10 / 0
except ZeroDivisionError:
raise ValueError('input error!')
只要是合理的轉換邏輯就可以，但是，決不應該把一個IOError轉換成毫不相干的ValueError。
2.調試
程序能一次寫完並正常運行的概率很小，基本不超過1%。總會有各種各樣的bug需要修正。有的bug很簡單，看看錯誤信息就知道，有的bug很複雜，我們需要知道出錯時，哪些變量的值是正確的，哪些變量的值是錯誤的，因此，需要一整套調試程序的手段來修復bug。
1.第一種方法簡單直接粗暴有效，就是用print()把可能有問題的變量打印出來看看：
用print()最大的壞處是將來還得刪掉它，想想程序裏到處都是print()，運行結果也會包含很多垃圾信息。所以，我們又有第二種方法。
2.斷言
凡是用print()來輔助查看的地方，都可以用斷言（assert）來替代：
def foo(s):
n = int(s)
assert n != 0, 'n is zero!'
return 10 / n
def main():
foo('0')
assert的意思是，表達式n != 0應該是True，否則，根據程序運行的邏輯，後面的代碼肯定會出錯。
如果斷言失敗，assert語句本身就會拋出AssertionError：
$ python err.py
Traceback (most recent call last):
...
AssertionError: n is zero!
3.logging
把print()替換爲logging是第3種方式，和assert比，logging不會拋出錯誤，而且可以輸出到文件：
import logging
s = '0'
n = int(s)
logging.info('n = %d' % n)
print(10 / n)
logging.info()就可以輸出一段文本。運行，發現除了ZeroDivisionError，沒有任何信息。怎麼回事？
別急，在import logging之後添加一行配置再試試：
import logging
logging.basicConfig(level=logging.INFO)
看到輸出了：
$ python err.py
INFO:root:n = 0
Traceback (most recent call last):
File "err.py", line 8, in <module>
print(10 / n)
ZeroDivisionError: division by zero
這就是logging的好處，它允許你指定記錄信息的級別，有debug，info，warning，error等幾個級別，當我們指定level=INFO時，logging.debug就不起作用了。同理，指定level=WARNING後，debug和info就不起作用了。這樣一來，你可以放心地輸出不同級別的信息，也不用刪除，最後統一控制輸出哪個級別的信息。
logging的另一個好處是通過簡單的配置，一條語句可以同時輸出到不同的地方，比如console和文件。
4.pdb
這種通過pdb在命令行調試的方法理論上是萬能的，但實在是太麻煩了，如果有一千行代碼，要運行到第999行得敲多少命令啊。還好，我們還有另一種調試方法。
小結
寫程序最痛苦的事情莫過於調試，程序往往會以你意想不到的流程來運行，你期待執行的語句其實根本沒有執行，這時候，就需要調試了。
雖然用IDE調試起來比較方便，但是最後你會發現，logging纔是終極武器
3.單元測試
單元測試是用來對一個模塊、一個函數或者一個類來進行正確性檢驗的測試工作。
比如對函數abs()，我們可以編寫出以下幾個測試用例：
輸入正數，比如1、1.2、0.99，期待返回值與輸入相同；
輸入負數，比如-1、-1.2、-0.99，期待返回值與輸入相反；
輸入0，期待返回0；
輸入非數值類型，比如None、[]、{}，期待拋出TypeError。
把上面的測試用例放到一個測試模塊裏，就是一個完整的單元測試。
如果單元測試通過，說明我們測試的這個函數能夠正常工作。如果單元測試不通過，要麼函數有bug，要麼測試條件輸入不正確，總之，需要修復使單元測試能夠通過。
單元測試通過後有什麼意義呢？如果我們對abs()函數代碼做了修改，只需要再跑一遍單元測試，如果通過，說明我們的修改不會對abs()函數原有的行爲造成影響，如果測試不通過，說明我們的修改與原有行爲不一致，要麼修改代碼，要麼修改測試。
這種以測試爲驅動的開發模式最大的好處就是確保一個程序模塊的行爲符合我們設計的測試用例。在將來修改的時候，可以極大程度地保證該模塊行爲仍然是正確的。
編寫單元測試時，我們需要編寫一個測試類，從unittest.TestCase繼承。
以test開頭的方法就是測試方法，不以test開頭的方法不被認爲是測試方法，測試的時候不會被執行。
對每一類測試都需要編寫一個test_xxx()方法。由於unittest.TestCase提供了很多內置的條件判斷，我們只需要調用這些方法就可以斷言輸出是否是我們所期望的。最常用的斷言就是assertEqual()：
self.assertEqual(abs(-1), 1) # 斷言函數返回的結果與1相等
另一種重要的斷言就是期待拋出指定類型的Error，比如通過d['empty']訪問不存在的key時，斷言會拋出KeyError：
with self.assertRaises(KeyError):
value = d['empty']
setUp與tearDown
可以在單元測試中編寫兩個特殊的setUp()和tearDown()方法。這兩個方法會分別在每調用一個測試方法的前後分別被執行。
setUp()和tearDown()方法有什麼用呢？設想你的測試需要啓動一個數據庫，這時，就可以在setUp()方法中連接數據庫，在tearDown()方法中關閉數據庫，這樣，不必在每個測試方法中重複相同的代碼：
class TestDict(unittest.TestCase):
def setUp(self):
print('setUp...')
def tearDown(self):
print('tearDown...')
可以再次運行測試看看每個測試方法調用前後是否會打印出setUp...和tearDown...。
小結
單元測試可以有效地測試某個程序模塊的行爲，是未來重構代碼的信心保證。
單元測試的測試用例要覆蓋常用的輸入組合、邊界條件和異常。
單元測試代碼要非常簡單，如果測試代碼太複雜，那麼測試代碼本身就可能有bug。
單元測試通過了並不意味着程序就沒有bug了，但是不通過程序肯定有bug。
4.文檔測試
doctest非常有用，不但可以用來測試，還可以直接作爲示例代碼。通過某些文檔生成工具，就可以自動把包含doctest的註釋提取出來。用戶看文檔的時候，同時也看到了doctest。