關於軟體質量和軟體測試的一點點看法 (轉)

關於軟體質量和軟體測試的一點點看法 (轉)[@more@]

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