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