3.4 不管怎樣， 集成測試將會抓住所有的Bug。
我們已經在前面的討論中從一個側面對這個問題進行了部分的闡述。 這個論點不成立的原因在于規模越大的代碼集成意味著復雜性就越高。
如果軟件的單元沒有事先進行測試， 開發人員很可能會花費大量的時間僅僅是為了使軟件能夠運行， 而任何實際的測試方案都無法執行。
一旦軟件可以運行了， 開發人員又要面對這樣的問題： 在考慮軟件全局復雜性的前提下對每個單元進行全面的測試。 這是一件非常困難的事情，
甚至在創造一種單元調用的測試條件的時候， 要全面的考慮單元的被調用時的各種入口參數。 在軟件集成階段， 對單元功能全面測試的復雜程度遠遠的超過獨立進行的單元測試過程。
最后的結果是測試將無法達到它所應該有的全面性。 一些缺陷將被遺漏， 并且很多Bug將被忽略過去。
讓我們類比一下， 假設我們要清洗一臺已經完全裝配好的食物加工機器! 無論你噴了多少水和清潔劑， 一些食物的小碎片還是會粘在機器的死角位置，只有任其腐爛并等待以后再想辦法。 但我們換個角度想想， 如果這臺機器是拆開的， 這些死角也許就不存在或者更容易接觸到了，并且每一部分都可以毫不費力的進行清洗。
3.5 它的成本效率不高
一個特定的開發組織或軟件應用系統的測試水平取決于對那些未發現的Bug的潛在后果的重視程度。
這種后果的嚴重程度可以從一個Bug引起的小小的不便到發生多次的死機的情況。 這種后果可能常常會被軟件的開發人員所忽視(但是用戶可不會這樣)，這種情況會長期的損害這些向用戶提交帶有Bug的軟件的開發組織的信譽， 并且會導致對未來的市場產生負面的影響。 相反地，一個可靠的軟件系統的良好的聲譽將有助于一個開發組織獲取未來的市場。
很多研究成果表明， 無論什么時候作出修改都要進行完整的回歸測試， 在生命周期中盡早地對軟件產品進行測試將使效率和質量得到最好的保證。
Bug發現的越晚， 修改它所需的費用就越高， 因此從經濟角度來看， 應該盡可能早的查找和修改Bug。 在修改費用變的過高之前，單元測試是一個在早期抓住Bug的機會。
相比后階段的測試， 單元測試的創建更簡單， 維護更容易， 并且可以更方便的進行重復。 從全程的費用來考慮， 相比起那些復雜且曠日持久的集成測試，
或是不穩定的軟件系統來說， 單元測試所需的費用是很低的。
4。 一些圖表
這些圖表摘自<<實用軟件度量>>(Capers Jones， McGraw-Hill 1991)， 它列出了準備測試， 執行測試，
和修改缺陷所花費的時間(以一個功能點為基準)， 這些數據顯示單元測試的成本效率大約是集成測試的兩倍， 系統測試的三倍(參見條形圖)。
文章來源于領測軟件測試網 http://www.kjueaiud.com/