軟件測試和軟件質(zhì)量的概念是分不開的。測試是手段，質(zhì)量是目的。關(guān)于軟件質(zhì)量，學(xué)軟件工程的時候曾考慮過這個問題，但想得不深。現(xiàn)在正好可以借把想法變成文字的過程理一理自己的思路，談?wù)勎业目捶ā?/p>

　　在學(xué)校讀書的時候，我有很多與我不同專業(yè)的朋友，建筑的，橋梁的，機械的，等等。他們有一個與我不同的共同之處，都常背一塊大木板，機械制圖是他們很重要的課程。我和我的同學(xué)們則學(xué)習(xí)程序設(shè)計，學(xué)習(xí)計算機的結(jié)構(gòu)和原理。我們往往抱怨操作系統(tǒng)編譯原理太復(fù)雜，可是看看那老大一張紙上鉛筆細(xì)細(xì)勾出的房屋結(jié)構(gòu)機械零件，精確到0.1毫米的內(nèi)徑外徑，鋼筋水泥混凝土的組成結(jié)構(gòu)及抗這抗那的能力，我覺得簡單考量一下的話，二者本并不具直接可比性的復(fù)雜程度至少是在一個量級上的。

　　我也知道一些各行業(yè)的工程師，包括我的姑姑是橋梁設(shè)計師，我的父親是機械模具設(shè)計師。從小我就對父親那一卷卷的圖紙印象很深。父親從無到有在一張張白紙上勾出一幅平面的在我看來亂七八糟什么也不是的東西，可是按照它對原料裁剪、加工就變成了一個實實在在的產(chǎn)品。當(dāng)時覺得神奇，現(xiàn)在想來，這是需要很扎實的知識的。在設(shè)計圖紙的整個過程中，并沒有什么工具和方法可以檢查一下是否有錯誤或疏漏，而最終送到工人手里的圖紙必須是正確無誤的，否則原料就成了廢品。

　　作為一個工程師，確保所從事的工作是正確的，對于工程師們是很重要的。假如建筑師因為偷懶疏忽而不能使我們的房子十分結(jié)實，將會發(fā)生什么情況?房子會倒塌而且我們要受到傷害。假設(shè)GM的工程師們對于汽車剎車不做最終的測試，當(dāng)我們需要剎車時，它就可能不能正常工作，就可能出事故。所以當(dāng)工程師回答一個有關(guān)如何工作的問題時，必須確信自己是正確的，必須確信沒有忘掉什么。

　　要做到這些，是需要大量工作的。

　　而軟件行業(yè)好象有著很大的不同。也是還在讀書的時候，我就曾問自己，同樣是工程師，為什么軟件行業(yè)的工程師不能像傳統(tǒng)行業(yè)的工程師一樣對自己的工作的品質(zhì)有著如此的確信?

　　在很多方面，程序設(shè)計師還是有著相當(dāng)?shù)谋憷摹Ｆ┤?，在從開始編寫代碼直到完成最終的軟件成品的過程中，每當(dāng)完成一個功能、一個模塊、一個代碼段，或者干脆程序員對自己不自信的時候，都可以運用各種工具編譯、跟蹤、調(diào)試程序去發(fā)現(xiàn)隱藏的錯誤或疏漏。而即便是由于偷懶疏忽沒有發(fā)現(xiàn)錯誤導(dǎo)致最終的產(chǎn)品中有很多的bug，似乎也不會發(fā)生什么，市場仍然接受，用戶仍然使用。

　　有兩個數(shù)據(jù)可以說明程序設(shè)計師的工作品質(zhì)：

　　人們發(fā)現(xiàn)，即使具有較多經(jīng)驗的編程人員，其編程正確率的得分平均只有7.8/14。

　　在有經(jīng)驗的編程人員寫的代碼中，平均每150行就會有一個bug。

　　是什么導(dǎo)致了這樣的情況?

　　是程序員心浮氣躁，責(zé)任心不強?是軟件行業(yè)的復(fù)雜程度遠(yuǎn)遠(yuǎn)超過傳統(tǒng)行業(yè)?是行業(yè)的特殊性造成市場和用戶對如此高的錯誤率持接受態(tài)度?還是其他的什么原因?

　　給自己提了這么些問題，卻不知道該怎么回答了。

　　對于第一個問題，這確實是大量程序員的寫照。從這里產(chǎn)生的大量問題也確實嚴(yán)重影響了軟件產(chǎn)品的質(zhì)量。

　　對于第二個問題，我想起了一個經(jīng)典的對話：

　　程序設(shè)計行家說：“任何程序，無論多么小，都有錯誤。”

　　新手不相信行家的話。“如果一個程序小到只能執(zhí)行一個單一的功能，也是這樣嗎?”他問道。

　　“這樣的程序不會有任何意義。”行家說。“假如這樣的程序存在，操作系統(tǒng)最終也會由于一個錯誤而失效。”

　　新手并不滿意。“如果操作系統(tǒng)不失效呢?”他問道。

　　“沒有不失效的操作系統(tǒng)。”行家說。“假如這樣的操作系統(tǒng)存在，硬件最終也會由于錯誤而失效。”

　　新手仍然感到不滿意。“如果硬件不失效呢?”他問道。

　　行家長嘆一口氣。“不存在不失效的硬件。”他說。“假如存在這樣的硬件，用戶還會要程序做不同的事情。這也是一個錯誤。”

　　沒有錯誤的程序是荒唐可笑的，是不可能存在的。假如存在沒有任何錯誤的程序，那么世界也會不復(fù)存在。

　　這個故事給不負(fù)責(zé)任的程序員以借口。但事實是否真的如此嚴(yán)重?對于硬件來說，高密集度的電子元件集成使人們很容易理解它是不穩(wěn)定的這樣一個結(jié)論，但從現(xiàn)實情況來看，硬件的穩(wěn)定性要遠(yuǎn)高于軟件的穩(wěn)定性。

　　或許，軟件規(guī)模的不斷膨脹使其復(fù)雜度指數(shù)增長，個人能力已無法完成，團隊成為必須。團隊磨合也成了產(chǎn)生錯誤的隱患。但在傳統(tǒng)行業(yè)里，這種情況也是屢見不鮮的。揚浦大橋，東方明珠，金貿(mào)大廈也不是一個人完成設(shè)計的。是缺乏經(jīng)驗沒有磨合團隊的良好方法?

　　軟件設(shè)計究竟有多復(fù)雜?是不是已經(jīng)復(fù)雜到了不可能避免錯誤的程度?我想這不是一個很容易可以回答的問題。

　　對于第三個問題，我認(rèn)為也是一個主要的因素。雖然每個公司每個程序員都知道，減少錯誤可以博得用戶的青睞，戰(zhàn)勝競爭對手。但普遍來說，市場的認(rèn)同縱容了公司和程序員不負(fù)責(zé)的心態(tài)，畢竟，減少錯誤是要付出代價的。

　　在很多公司和程序員看來，bug和測試似乎是緊密關(guān)聯(lián)而分不開的。程序員只顧編寫代碼，認(rèn)為有沒有bug有多少bug測測就知道了。

　　把軟件質(zhì)量依賴于測試，是不可能真正解決軟件質(zhì)量問題的。

　　測試不是解決錯誤的根本舉措，只是一種輔助手段。但又是必須的手段，我想現(xiàn)在已經(jīng)不會有人再問出“如果程序員更仔細(xì)一點，測試會是不需要的嗎?”這樣的問題了吧。

　　軟件測試的首要任務(wù)是發(fā)現(xiàn)錯誤。發(fā)現(xiàn)錯誤也許要花很大的代價。因為測試是復(fù)雜的，不存在好的辦法使每次測試都是有效的。有這么一句話：

　　如果做某件事有兩種或多種方法，其中有一種方法會導(dǎo)致一個災(zāi)難結(jié)局，那么也會有另一種方法導(dǎo)致同樣的結(jié)局。

　　測試的復(fù)雜性和軟件的復(fù)雜性是一致的。也就是說由于軟件的復(fù)雜導(dǎo)致了測試的復(fù)雜。

　　測試提出了基本的和令人困惑的難題。假使我們在測試時從來不希望檢測被測系統(tǒng)所有可能的輸入、路徑和狀態(tài)，那么應(yīng)該選擇什么?什么時候應(yīng)該停止?如果我們必須依賴于測試來防止某種失敗，那么我們怎么來設(shè)計既是可測試的又是有效的系統(tǒng)呢?我們怎樣來編寫一個測試包，它可以檢測足夠多的消息和狀態(tài)的組合來說明沒有失敗的操作，但是從實用性來說它又足夠的小?

　　第二個目的是對于給定的測試包，說明被測系統(tǒng)是符合規(guī)約所描述的需求。

　　所以，我覺得測試活動與軟件過程協(xié)調(diào)一致得好與壞，都對測試的有效性有很重要的影響。

　　如果測試的開發(fā)是在一個項目開始時進行的，那么測試將是非常有效的。及早考慮可測試性，及早進行測試設(shè)計，和盡可能早地實現(xiàn)測試，提高了有力預(yù)防錯誤的方法。這些過程迫使設(shè)計人員更仔細(xì)地考慮需求和規(guī)約的實現(xiàn)，其結(jié)果可能改進應(yīng)用設(shè)計。關(guān)于體系結(jié)構(gòu)、詳細(xì)設(shè)計和編碼實踐的及早決策，都能使測試變得更容易更經(jīng)濟。

　　寫到這里，我想應(yīng)該停下來了，雖然我還有一些問題和想法，但無法固定它們，我覺得已經(jīng)有些糊涂了。最后，從腦海里跳出了一個問題：

　　測試與對質(zhì)量的承諾是一致的嗎?