2.3　軟件測試的原則

讓我們繼續(xù)本章的話題基礎(chǔ)，即軟件測試中大多數(shù)重要的問題都是心理學(xué)問題。我們可以歸納出一系列重要的測試指導(dǎo)原則。這些原則看上去大多都是顯而易見的，但常常總是被我們忽視掉。表2-1總結(jié)了這些重要原則，每條原則都將在下面的章節(jié)中詳細(xì)介紹。

原則1：測試用例中一個(gè)必需部分是對預(yù)期輸出或結(jié)果的定義。

這條顯而易見的原則在軟件測試中是最常犯的錯誤之一。同樣，這個(gè)問題也是基于人們的心理的。如果某個(gè)測試用例的預(yù)期結(jié)果事先沒有得到定義，由于“所見即所想”現(xiàn)象的存在，某個(gè)似是而非、實(shí)際上是錯誤的結(jié)果可能會被解釋成正確的結(jié)論。換句話說，盡管“軟件測試是破壞性”的定義是合理的，但人們在潛意識中仍然渴望看到正確的結(jié)果。克服這種傾向的一種方法，就是通過事先精確定義程序的預(yù)期輸出，鼓勵人們對所有的輸出進(jìn)行仔細(xì)檢查。因此，一個(gè)測試用例必須包括兩個(gè)部分：

1.對程序的輸入數(shù)據(jù)的描述。

2.對程序在上述輸入數(shù)據(jù)下的正確輸出結(jié)果的精確描述。

所謂“問題”，可以歸納為一個(gè)或一組我們不能給出可信服的解釋、看上去不太正常或不符合我們期望或預(yù)想的事實(shí)。應(yīng)當(dāng)明確的是，在確定事物存在“問題”之前，人們必須已經(jīng)形成了特定的認(rèn)識。沒有期望，也就沒有所謂的意外。

原則2：程序員應(yīng)當(dāng)避免測試自己編寫的程序。

任何作者都知道或應(yīng)該知道，親自編輯或校對自己的作品確實(shí)是個(gè)不好的做法。作者清楚某段文字要說明的是什么，實(shí)際表達(dá)出來的意思卻南轅北轍，而自己可能卻意識不到。況且實(shí)際上也不會想在自己的作品中找出什么錯誤來。對程序員而言，也存在相同的問題。

如果我們對軟件項(xiàng)目關(guān)注的重點(diǎn)發(fā)生變化，就會產(chǎn)生另外一個(gè)問題。當(dāng)程序員“建設(shè)性”地設(shè)計(jì)和編寫完程序之后，很難讓他突然改變視角以一種“破壞性”的眼光來審查程序。

正如許多房屋業(yè)主都知道的那樣，撕下屋里的墻紙（這是個(gè)破壞性的過程）并不容易，如果這些墻紙又恰恰是業(yè)主第一個(gè)親手貼的，尤其令其沮喪不已。同樣，大多數(shù)程序員都不能有效地測試自己編寫的程序，因?yàn)樗麄儫o法改變思維方式來盡力暴露自己程序中的錯誤。另外，程序員可能會下意識地避免找出錯誤來，擔(dān)心受到同事、上司、客戶或正在開發(fā)的程序或系統(tǒng)的主管的懲罰。

僅次于上面的心理學(xué)問題，還有一個(gè)重要的問題：由于程序員錯誤地理解了疑難定義或規(guī)范，導(dǎo)致程序中存在錯誤。如果情況是這樣，程序員可能會帶著同樣的誤解來測試自己的程序。

這并不意味著程序員測試自己的程序是不可能的。當(dāng)然，我們的言下之意是，讓其他人來測試程序會更加有效，也會更容易測試成功。

請注意，我們的論據(jù)并不適合于“調(diào)試”（糾正已知的錯誤）。“調(diào)試”由程序的編寫人員來完成會有效得多。

原則3：編寫軟件的組織不應(yīng)當(dāng)測試自己編寫的軟件。

這里的論據(jù)與前面的論據(jù)相似。從很多方面來講，一個(gè)軟件項(xiàng)目或編程組織是一個(gè)有機(jī)的機(jī)構(gòu)，具有與個(gè)體程序員相似的心理問題。而且在大多數(shù)情況下，主要是根據(jù)其在給定時(shí)間、特定成本范圍內(nèi)開發(fā)軟件的能力來衡量編程組織或項(xiàng)目經(jīng)理。其中的一個(gè)原因是，度量時(shí)間和成本目標(biāo)比較容易，而定量地衡量軟件的可靠性則極其困難。即便是合理規(guī)劃和實(shí)施的測試過程，也可能被認(rèn)為降低了完成進(jìn)度和成本目標(biāo)的可能性，因此，編程組織難以客觀地測試自己的軟件。

同樣，我們并不是說編程組織發(fā)現(xiàn)程序中的問題是不可能的，事實(shí)上很多組織已經(jīng)在某種程度上成功地做到了這一點(diǎn)。當(dāng)然，我們的言下之意是，更經(jīng)濟(jì)的方法是由客觀、獨(dú)立的第三方來進(jìn)行測試。

原則4：應(yīng)當(dāng)徹底檢查每個(gè)測試的執(zhí)行結(jié)果。

這個(gè)原則可能是最顯而易見的原則，但也同樣常常被忽視。我們見過大量的例子，即便錯誤的癥狀在輸出清單中可以清楚地看到，但還是沒有找出那些錯誤來。換言之，在后續(xù)測試中發(fā)現(xiàn)的錯誤，往往是前面的測試遺漏掉的。

原則5：測試用例的編寫不僅應(yīng)當(dāng)根據(jù)有效和預(yù)期的輸入情況，而且也應(yīng)當(dāng)根據(jù)無效和未預(yù)料到的輸入情況。

在測試軟件時(shí)，有一個(gè)自然的傾向，即將重點(diǎn)集中在有效和預(yù)期的輸入情況上，而忽略了無效和未預(yù)料到的情況。比如，在本書第1章三角形程序的測試中，總是出現(xiàn)這個(gè)傾向。

例如，很少有人會向程序輸入1，2，5以證明程序不會錯誤地將其解釋為一個(gè)不規(guī)則三角形，而不是一個(gè)無效三角形。此外，在軟件產(chǎn)品中突然暴露出來的許多問題是當(dāng)程序以某些新的或未預(yù)料到的方式運(yùn)行時(shí)發(fā)現(xiàn)的。因此，針對未預(yù)料到的和無效輸入情況的測試用例，似乎比針對有效輸入情況的那些用例更能發(fā)現(xiàn)問題。

原則6：檢查程序是否“未做其應(yīng)該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應(yīng)該做的”。

這條原則是上條原則的必然結(jié)果。必須檢查程序是否有我們不希望的負(fù)作用。比如，某個(gè)工資管理程序即便可以生成正確的工資單，但是如果也為非雇員生成工資單或者它覆蓋掉了人員文件的第一條記錄，這樣的程序仍然是不正確的程序。

原則7：應(yīng)避免測試用例用后即棄，除非軟件本身就是一個(gè)一次性的軟件。

這個(gè)問題在采用交互式系統(tǒng)來測試軟件時(shí)最常見。人們通常會坐在終端前，匆忙地編寫測試用例，然后將這些用例交由程序執(zhí)行。這樣做的問題在于，飽含我們寶貴投入的測試用例，在測試結(jié)束后就消失了。一旦軟件需要重新測試（例如，當(dāng)改正了某個(gè)錯誤或作了某種改進(jìn)后），又必須重新設(shè)計(jì)這些測試用例。情況往往是這樣的，由于重新設(shè)計(jì)測試用例需要投入大量的工作，人們總是避免這樣做。因此，對該程序的重新測試極少會同上次一樣嚴(yán)格。這就意味著，如果對程序的更改導(dǎo)致了程序某個(gè)先前可以執(zhí)行的部分發(fā)生了故障，這個(gè)故障往往是不會被發(fā)現(xiàn)的。保留測試用例，當(dāng)程序其他部件發(fā)生更動后重新執(zhí)行，這就是我們所謂的“回歸測試”。

原則8：計(jì)劃測試工作時(shí)不應(yīng)默許假定不會發(fā)現(xiàn)錯誤。

項(xiàng)目經(jīng)理經(jīng)常容易犯這個(gè)錯誤，這也是使用了不正確的測試定義的一個(gè)跡象—也就是說，假定“測試是一個(gè)證明程序正確運(yùn)行的過程”。我們再一次重申，所謂測試，就是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。

原則9：程序某部分存在更多錯誤的可能性，與該部分已發(fā)現(xiàn)錯誤的數(shù)量成正比。

這種現(xiàn)象如圖2-2所示。乍看上去，這幅圖似乎沒有什么意義，但很多程序都存在這種現(xiàn)象。例如，假如某個(gè)程序由兩個(gè)模塊、類或子程序A和B組成，模塊A中已經(jīng)發(fā)現(xiàn)了五個(gè)錯誤，而模塊B中僅僅找到了一處錯誤。如果模塊A所經(jīng)過的測試并不是故意設(shè)計(jì)得更為嚴(yán)格，那么該原則告訴我們，模塊A與模塊B相比，存在更多錯誤的可能性要大。

該原則的另一個(gè)說法是，錯誤總是傾向于聚集存在，而在一個(gè)具體的程序中，某些部分要比其他部分更容易存在錯誤，盡管沒有人能夠?qū)@種現(xiàn)象給出很好的解釋。這種現(xiàn)象之所以有用，是因?yàn)樗o予了我們對軟件測試過程的深入理解或反饋信息。如果一個(gè)程序的某個(gè)部分遠(yuǎn)比其他部分更容易產(chǎn)生錯誤，那么這種現(xiàn)象告訴我們，為了使測試獲得更大的成效，最好對這些容易存在錯誤的部分進(jìn)行額外的測試。

原則10：軟件測試是一項(xiàng)極富創(chuàng)造性、極具智力挑戰(zhàn)性的工作。

測試一個(gè)大型軟件所需要的創(chuàng)造性很可能超過了開發(fā)該軟件所需要的創(chuàng)造性。我們已經(jīng)看到，要充分地測試一個(gè)軟件以確保所有錯誤都不存在是不可能的。本書后續(xù)章節(jié)討論的技術(shù)使我們能夠?yàn)槟硞€(gè)軟件設(shè)計(jì)出合理的測試用例集，然而這些技術(shù)仍然需要大量的創(chuàng)造性。