這是那些沒有首先為每個單元編寫一個詳細的規格說明而直接跳到編碼階段的開發人員提出的一條普遍的抱怨， 當編碼完成以后并且面臨代碼測試任務的時候，
他們就閱讀這些代碼并找出它實際上做了什么， 把他們的測試工作基于已經寫好的代碼的基礎上。 當然， 他們無法證明任何事情。
所有的這些測試工作能夠表明的事情就是編譯器工作正常。 是的， 他們也許能夠抓住(希望能夠)罕見的編譯器Bug， 但是他們能夠做的僅僅是這些。
如果他們首先寫好一個詳細的規格說明， 測試能夠以規格說明為基礎。 代碼就能夠針對它的規格說明， 而不是針對自身進行測試。
這樣的測試仍然能夠抓住編譯器的Bug， 同時也能找到更多的編碼錯誤， 甚至是一些規格說明中的錯誤。 好的規格說明可以使測試的質量更高，
所以最后的結論是高質量的測試需要高質量的規格說明。
在實踐中會出現這樣的情況： 一個開發人員要面對測試一個單元時只給出單元的代碼而沒有規格說明這樣吃力不討好的任務。 你怎樣做才會有更多的收獲，
而不僅僅是發現編譯器的Bug? 第一步是理解這個單元原本要做什么， --- 不是它實際上做了什么。 比較有效的方法是倒推出一個概要的規格說明。
這個過程的主要輸入條件是要閱讀那些程序代碼和注釋， 主要針對這個單元， 及調用它和被它調用的相關代碼。 畫出流程圖是非常有幫助的，你可以用手工或使用某種工具。 可以組織對這個概要規格說明的走讀(Review)， 以確保對這個單元的說明沒有基本的錯誤， 有了這種最小程度的代碼深層說明， 就可以用它來設計單元測試了。
3.3 我是個很棒的程序員， 我是不是可以不進行單元測試?
在每個開發組織中都至少有一個這樣的開發人員， 他非常擅長于編程， 他們開發的軟件總是在第一時間就可以正常運行， 因此不需要進行測試。
你是否經常聽到這樣的借口?
在真實世界里， 每個人都會犯錯誤。 即使某個開發人員可以抱著這種態度在很少的一些簡單的程序中應付過去。 但真正的軟件系統是非常復雜的。
真正的軟件系統不可以寄希望于沒有進行廣泛的測試和Bug修改過程就可以正常工作。
編碼不是一個可以一次性通過的過程。 在真實世界中， 軟件產品必須進行維護以對操作需求的改變作出反應，并且要對最初的開發工作遺留下來的Bug進行修改。 你希望依靠那些原始作者進行修改嗎?
這些制造出這些未經測試的原始代碼的資深專家們還會繼續在其他地方制造這樣的代碼。
在開發人員做出修改后進行可重復的單元測試可以避免產生那些令人不快的負作用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/