行家長嘆一口氣�！安淮嬖诓皇У挠布��！彼f�！凹偃绱嬖谶@樣的硬件，用戶還會要程序做不同的事情。這也是一個錯誤�！�
沒有錯誤的程序是荒唐可笑的，是不可能存在的。假如存在沒有任何錯誤的程序，那么世界也會不復存在。
這個故事給不負責任的程序員以借口。但事實是否真的如此嚴重?對于硬件來說，高密集度的電子元件集成使人們很容易理解它是不穩定的這樣一個結論，但從現實情況來看，硬件的穩定性要遠高于軟件的穩定性。
或許，軟件規模的不斷膨脹使其復雜度指數增長，個人能力已無法完成，團隊成為必須。團隊磨合也成了產生錯誤的隱患。但在傳統行業里，這種情況也是屢見不鮮的。揚浦大橋，東方明珠，金貿大廈也不是一個人完成設計的。是缺乏經驗沒有磨合團隊的良好方法?
軟件設計究竟有多復雜?是不是已經復雜到了不可能避免錯誤的程度?我想這不是一個很容易可以回答的問題。
對于第三個問題，我認為也是一個主要的因素。雖然每個公司每個程序員都知道，減少錯誤可以博得用戶的青睞，戰勝競爭對手。但普遍來說，市場的認同縱容了公司和程序員不負責的心態，畢竟，減少錯誤是要付出代價的。
在很多公司和程序員看來，bug和測試似乎是緊密關聯而分不開的。程序員只顧編寫代碼，認為有沒有bug有多少bug測測就知道了。
把軟件質量依賴于測試，是不可能真正解決軟件質量問題的。
測試不是解決錯誤的根本舉措，只是一種輔助手段。但又是必須的手段，我想現在已經不會有人再問出“如果程序員更仔細一點，測試會是不需要的嗎?”這樣的問題了吧。
軟件測試的首要任務是發現錯誤。發現錯誤也許要花很大的代價。因為測試是復雜的，不存在好的辦法使每次測試都是有效的。有這么一句話：
如果做某件事有兩種或多種方法，其中有一種方法會導致一個災難結局，那么也會有另一種方法導致同樣的結局。
測試的復雜性和軟件的復雜性是一致的。也就是說由于軟件的復雜導致了測試的復雜。
測試提出了基本的和令人困惑的難題。假使我們在測試時從來不希望檢測被測系統所有可能的輸入、路徑和狀態，那么應該選擇什么?什么時候應該停止?如果我們必須依賴于測試來防止某種失敗，那么我們怎么來設計既是可測試的又是有效的系統呢?我們怎樣來編寫一個測試包，它可以檢測足夠多的消息和狀態的組合來說明沒有失敗的操作，但是從實用性來說它又足夠的小?
第二個目的是對于給定的測試包，說明被測系統是符合規約所描述的需求。
所以，我覺得測試活動與軟件過程協調一致得好與壞，都對測試的有效性有很重要的影響。
如果測試的開發是在一個項目開始時進行的，那么測試將是非常有效的。及早考慮可測試性，及早進行測試設計，和盡可能早地實現測試，提高了有力預防錯誤的方法。這些過程迫使設計人員更仔細地考慮需求和規約的實現，其結果可能改進應用設計。關于體系結構、詳細設計和編碼實踐的及早決策，都能使測試變得更容易更經濟。
寫到這里，我想應該停下來了，雖然我還有一些問題和想法，但無法固定它們，我覺得已經有些糊涂了。最后，從腦海里跳出了一個問題：
測試與對質量的承諾是一致的嗎?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
