測試是一個尚未解決的問題

寫幾行程式碼很容易，測試它是另一回事。

為什麼計算機程式不能像日常數學邏輯問題一樣，推理正確即是正確？為什麼軟體程式需要測試？原因很多，可以追溯到計算機科學的起源、數學的核心乃至經濟學。即使是最有技術實力、擁有無數天才的的公司也會在軟體推出前四處測試，發現問題，解決問題。這讓測試成為計算機科學中最有趣的部分。

如果作為測試人員，你認為軟體測試是一個無限且未解決的問題，那麼你一定在一家偉大的公司；如果你是軟體工程師，透過檢視程式碼，很容易就判斷面前的程式是否正確，雖然只能說你幾乎是正確的。

因為，眾所周知，程式並不會按照人們的邏輯準確無誤的執行，他們總會反饋一些很細微的bug。最聰明的人告訴我們，構建軟體程式來驗證最簡單的程式可能也是無法企及的。

舉個例子：F（x）=x+1

如果輸入為 1，則返回 2。如果輸入為 41，則返回 42。如果輸入為 419，則返回 420。

undefined

f（x） 的快速測試程式碼

在第一次透過時，我們只需要將每個可能的數字應用於此函式。即使我們僅限於簡單的整數輸入（沒有分數或者浮點數0。333），這仍然是一個無限的輸入空間。如果我們將其限制為典型機器/語言可以表示的 32 位整數，那仍然是一個非常大的輸入空間，需要花費相當多的計算時間和金錢來嘗試。

簡單的測試程式碼將“永遠”執行……

顯然，這段程式碼需要很長時間才能完成。對於 64 位整數，它實際上永遠不會完成。無論如何，Python 都有任意大的整數——我們不能用一種演算法來詳盡地測試這個微不足道的函式，該演算法用不同的離散測試輸入來呼叫它。

更糟糕的是，我們通常不知道該功能是如何實現的，而且它可能會因構建而異，需要重新測試。更糟糕的是，如果 f（x） 依賴於可能從上次呼叫中儲存的變數，那麼問題將變得更加困難。這是最簡單的測試功能。

如果函式維護任何本地狀態，更不用說從程式的另一部分讀取狀態變數，它會變得更難處理。該函式的行為現在對多個輸入很敏感，並且總輸入空間繼續呈指數增長。