首先說明，我對測試的了解屬於從外部逐漸了解的那種，可以說基本上是外行。但是如果願意討論這個問題，希望不要因為我的業餘，就完全否認我的說法。另外需要重申的是，我並不否定tdd，因為我認為測試更多的應該發揮乙個工程上的作用，我質疑的是通過測試保證正確性。
迪斯特拉說過，測試只能證明乙個事情是錯的，但永遠不能證明乙個事情是對的。
這是一句沒法否認的話。但是我心裡也明白，沒有必要要求形式上的、100%可以保證的正確性，關鍵在於代價和效果的比。如果在「正確性」上，可以得到乙個比如99%的概率（請注意哪怕1%的概率，也意味著存在完全正確的可能性，只是心裡比較沒譜罷了），而使用某種方法的成本很低，這樣的做法我完全認同。
問題在於，在複雜度足夠高的某些過程上，要達到相同的概率，測試付出的代價超出了構造該過程本身甚至再加上多次、多人驗證的代價，而且可能對「是否正確」這一結論引入新的不確定性。在保證正確性這一問題上，連infoq這種站的某些作者都指出，比如「淨室開發」也可以取得至少一樣好甚至更好的結果。
根據mcconnell書中引用的報告，相比其它檢驗手段，測試的bug檢出率即便不是最少那也是相當的少了。你可以認為這是測試做得不到位，但這也揭示了測試作為一種手法，保證正確性這一部分功效，在相當多的工程中也是不可行的：因為我們只能以平均水準要求參與工程的人員。
在這方面，我覺得討論更先進的測試手法來體現測試的優越性，太過具體，而且實際上最終指向的還是：在給定的條件下，可以保證的正確性概率是否滿足要求（如果同一過程在條件之外給出完全錯誤的結果其實也不是不能接受的）；其次，滿足要求要花費的成本是多少。在這方面，我也懇請懂行的人可以給出各方面的資料，讓我和其它有興趣深入的人可以更好的了解和研討。
對於一些過程而言，使用測試在正確性保障方面，因為在覆蓋等方面本身存在著可行但成本很高或完全不可行的情況，想要達成某一較高的概率甚至是根本無法實現的（比如迪斯特拉舉的例子）；而這些過程很可能存在其它的檢驗手段可以達成目標。理解了這一點（這是進行簡單的思維試驗就可以弄清楚的），就知道了我這個外行在說什麼。
最後強調的是，我不否認測試在工程上所起的作用；甚至在正確性這方面，在很多地方使用測試的可行性也非常高，而相應的成本會比較低。比如knuth雖然也很不客氣的否認測試作為一種手法的優越性，不過在他的具體專案中，也不是完全不使用測試的。但如果只是一味倡導，而完全忽略其中我們需要細心的思考的、可能存在的破綻，我覺得就比較不能接受了。
在本篇中，以過程作為討論物件，是因為過程的正確是構成軟體正確性最根本的基石，尤其是關鍵性過程的正確，我個人目前不贊成使用測試來保障（雖然還是應該根據過程的特點來決定）。另外需要注意的一點，本文討論的是正確的概率，而不是測試的覆蓋率（雖然這是影響概率的主要因素之一）。
最終，這是乙個減小出錯風險的效果的價效比問題，在某些過程上，是可行性的問題。另外，我覺得這個問題是乙個典型的例子：我們無需深入課題內部各個細節，就可以通過分析思考學到很多的東西，甚至作出有益的判斷和決定。
老調重彈之整除與實數除
學計算機的同學一定被人問到這樣的問題 1.5除以2等於多少？很多人第一反應就是暴怒，這麼簡單的問題居然還拿來考我，真是豈有此理。小學生都會的啊，等於2.5嘛 等等，好像事情沒有那麼簡單吧？如果這麼簡單的話，為什麼還要拿來問呢？我們來看一下到底等於多少？看到了嗎?它的結果是等於2.太不可思議了吧。但其...
老調重彈之整除與實數除
學計算機的同學一定被人問到這樣的問題 1.5除以2等於多少？很多人第一反應就是暴怒，這麼簡單的問題居然還拿來考我，真是豈有此理。小學生都會的啊，等於2.5嘛 等等，好像事情沒有那麼簡單吧？如果這麼簡單的話，為什麼還要拿來問呢？我們來看一下到底等於多少？看到了嗎?它的結果是等於2.太不可思議了吧。但其...
老調重彈 access注入過主機衛
首先開啟伺服器上安裝了主機衛士的 嘗試在變數id的值後面插入萬惡的單引號，根據報錯，我們可以分析出來，使用的是access資料庫。通過order by檢視當前表有多少個列，發現6的時候報錯，5的時候正常，表明當前表中有5個列 接著試試聯合查詢 duang的一下，就被攔截了 嗚嗚嗚 那只能操出萬能的黑...