軟件測試和軟件質量的概念是分不開的。測試是手段，質量是目的。關於軟件質量，學軟件工程的時候曾考慮過這個問題，但想得不深。現在正好可以借把想法變成文字的過程理一理自己的思路，談談我的看法。
在學校讀書的時候，我有很多與我不同專業的朋友，建築的，橋樑的，機械的，等等。他們有一個與我不同的共同之處，都常背一塊大木板，機械製圖是他們很重要的課程。我和我的同學們則學習程序設計，學習計算機的結構和原理。我們往往抱怨操作系統編譯原理太複雜，可是看看那老大一張紙上鉛筆細細勾出的房屋結構機械零件，精確到0.1毫米的內徑外徑，鋼筋水泥混凝土的組成結構及抗這抗那的能力，我覺得簡單考量一下的話，二者本並不具直接可比性的複雜程度至少是在一個量級上的。
我也知道一些各行業的工程師，包括我的姑姑是橋樑設計師，我的父親是機械模具設計師。從小我就對父親那一卷卷的圖紙印象很深。父親從無到有在一張張白紙上勾出一幅平面的在我看來亂七八糟什麼也不是的東西，可是按照它對原料裁剪、加工就變成了一個實實在在的產品。當時覺得神奇，現在想來，這是需要很紮實的知識的。在設計圖紙的整個過程中，並沒有什麼工具和方法可以檢查一下是否有錯誤或疏漏，而最終送到工人手裏的圖紙必須是正確無誤的，否則原料就成了廢品。
作爲一個工程師，確保所從事的工作是正確的，對於工程師們是很重要的。假如建築師因爲偷懶疏忽而不能使我們的房子十分結實，將會發生什麼情況？房子會倒塌而且我們要受到傷害。假設GM的工程師們對於汽車剎車不做最終的測試，當我們需要剎車時，它就可能不能正常工作，就可能出事故。所以當工程師回答一個有關如何工作的問題時，必須確信自己是正確的，必須確信沒有忘掉什麼。
要做到這些，是需要大量工作的。
而軟件行業好象有着很大的不同。也是還在讀書的時候，我就曾問自己，同樣是工程師，爲什麼軟件行業的工程師不能像傳統行業的工程師一樣對自己的工作的品質有着如此的確信？
在很多方面，程序設計師還是有着相當的便利的。譬如，在從開始編寫代碼直到完成最終的軟件成品的過程中，每當完成一個功能、一個模塊、一個代碼段，或者乾脆程序員對自己不自信的時候，都可以運用各種工具編譯、跟蹤、調試程序去發現隱藏的錯誤或疏漏。而即便是由於偷懶疏忽沒有發現錯誤導致最終的產品中有很多的bug，似乎也不會發生什麼，市場仍然接受，用戶仍然使用。
有兩個數據可以說明程序設計師的工作品質：
人們發現，即使具有較多經驗的編程人員，其編程正確率的得分平均只有7.8/14。
在有經驗的編程人員寫的代碼中，平均每150行就會有一個bug。
是什麼導致了這樣的情況？
是程序員心浮氣躁，責任心不強？是軟件行業的複雜程度遠遠超過傳統行業？是行業的特殊性造成市場和用戶對如此高的錯誤率持接受態度？還是其他的什麼原因？
給自己提了這麼些問題，卻不知道該怎麼回答了。
對於第一個問題，這確實是大量程序員的寫照。從這裏產生的大量問題也確實嚴重影響了軟件產品的質量。
對於第二個問題，我想起了一個經典的對話：
程序設計行家說：“任何程序，無論多麼小，都有錯誤。”
新手不相信行家的話。“如果一個程序小到只能執行一個單一的功能，也是這樣嗎？”他問道。
“這樣的程序不會有任何意義。”行家說。“假如這樣的程序存在，操作系統最終也會由於一個錯誤而失效。”
新手並不滿意。“如果操作系統不失效呢？”他問道。
“沒有不失效的操作系統。”行家說。“假如這樣的操作系統存在，硬件最終也會由於錯誤而失效。”
新手仍然感到不滿意。“如果硬件不失效呢？”他問道。
行家長嘆一口氣。“不存在不失效的硬件。”他說。“假如存在這樣的硬件，用戶還會要程序做不同的事情。這也是一個錯誤。”
沒有錯誤的程序是荒唐可笑的，是不可能存在的。假如存在沒有任何錯誤的程序，那麼世界也會不復存在。
這個故事給不負責任的程序員以藉口。但事實是否真的如此嚴重？對於硬件來說，高密集度的電子元件集成使人們很容易理解它是不穩定的這樣一個結論，但從現實情況來看，硬件的穩定性要遠高於軟件的穩定性。
或許，軟件規模的不斷膨脹使其複雜度指數增長，個人能力已無法完成，團隊成爲必須。團隊磨合也成了產生錯誤的隱患。但在傳統行業裏，這種情況也是屢見不鮮的。揚浦大橋，東方明珠，金貿大廈也不是一個人完成設計的。是缺乏經驗沒有磨合團隊的良好方法？
軟件設計究竟有多複雜？是不是已經複雜到了不可能避免錯誤的程度？我想這不是一個很容易可以回答的問題。
對於第三個問題，我認爲也是一個主要的因素。雖然每個公司每個程序員都知道，減少錯誤可以博得用戶的青睞，戰勝競爭對手。但普遍來說，市場的認同縱容了公司和程序員不負責的心態，畢竟，減少錯誤是要付出代價的。
在很多公司和程序員看來，bug和測試似乎是緊密關聯而分不開的。程序員只顧編寫代碼，認爲有沒有bug有多少bug測測就知道了。
把軟件質量依賴於測試，是不可能真正解決軟件質量問題的。
測試不是解決錯誤的根本舉措，只是一種輔助手段。但又是必須的手段，我想現在已經不會有人再問出“如果程序員更仔細一點，測試會是不需要的嗎？”這樣的問題了吧。
軟件測試的首要任務是發現錯誤。發現錯誤也許要花很大的代價。因爲測試是複雜的，不存在好的辦法使每次測試都是有效的。有這麼一句話：
如果做某件事有兩種或多種方法，其中有一種方法會導致一個災難結局，那麼也會有另一種方法導致同樣的結局。
測試的複雜性和軟件的複雜性是一致的。也就是說由於軟件的複雜導致了測試的複雜。
測試提出了基本的和令人困惑的難題。假使我們在測試時從來不希望檢測被測系統所有可能的輸入、路徑和狀態，那麼應該選擇什麼？什麼時候應該停止？如果我們必須依賴於測試來防止某種失敗，那麼我們怎麼來設計既是可測試的又是有效的系統呢？我們怎樣來編寫一個測試包，它可以檢測足夠多的消息和狀態的組合來說明沒有失敗的操作，但是從實用性來說它又足夠的小？
第二個目的是對於給定的測試包，說明被測系統是符合規約所描述的需求。
所以，我覺得測試活動與軟件過程協調一致得好與壞，都對測試的有效性有很重要的影響。
如果測試的開發是在一個項目開始時進行的，那麼測試將是非常有效的。及早考慮可測試性，及早進行測試設計，和儘可能早地實現測試，提高了有力預防錯誤的方法。這些過程迫使設計人員更仔細地考慮需求和規約的實現，其結果可能改進應用設計。關於體系結構、詳細設計和編碼實踐的及早決策，都能使測試變得更容易更經濟。
寫到這裏，我想應該停下來了，雖然我還有一些問題和想法，但無法固定它們，我覺得已經有些糊塗了。最後，從腦海裏跳出了一個問題：
測試與對質量的承諾是一致的嗎？
