軟件測試的原則

點擊領取學習資料

前言

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

一、軟件測試的重要原則

測試用例中一個必需部分是對預期輸出或結果進行定義

程序員應避免測試自己編寫的程序

編寫軟件的組織不應當測試自已編寫的軟件

應當徹底檢查每個測試的執行結果

測試用例的編寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效 和未預料到的輸入情況

檢查程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程是 否“做了其不應該做的”

應避免測試用例用后即棄，除非軟件本身就是個一次性的軟件

計劃測試工作時不應默許假定不會發現錯誤

程序某部分存在更多錯誤的可能性，與該部分已發現錯誤的數量成正比

軟件測試是一項極富創造性，極具智力的挑戰性的工作

二、測試用例中一個必需部分是對預期輸出或結果的定義。

1.引入庫

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

• 1．對程序的輸入數據的描述。
• 2．對程序在上述輸入數據下的正確輸出結果的精確描述。

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

2.程序員應當避免測試自己編寫的程序

任何作者都知道或應該知道，親自編輯或校對自己的作品確實是個不好的做法。作者清楚某段文字要說明的是什么，實際表達出來的意思卻南轅北轍，而自己可能卻意識不到。況且實際上也不會想在自己的作品中找出什么錯誤來。對程序員而言，也存在相同的問題。
如果我們對軟件項目關注的重點發生變化，就會產生另外一個問題。當程序員“建設性”地設計和編寫完程序之后，很難讓他突然改變視角以一種“破壞性”的眼光來審查程序。正如許多房屋業主都知道的那樣，撕下屋里的墻紙（這是個破壞性的過程）并不容易，如果這些墻紙又恰恰是業主第一個親手貼的，尤其令其沮喪不已。

同樣，大多數程序員都不能有效地測試自己編寫的程序，因為他們無法改變思維方式來盡力暴自己程序中的錯誤。另外，程序員可能會下意識地避免找出錯誤來，擔心受到同事、上司、客戶或正在開發的程序或系統的主管的懲罰。僅次于上面的心理學問題，還有一個重要的問題：由干程序員錯誤地理解了疑難定義或規范，導致程序中存在錯誤。如果情況是這樣，程序員可能會帶著同樣的軟件測試的藝術誤解來測試自己的程序。

這并不意味著程序員測試自己的程序是不可能的。當然，我們的言下之意是，讓其他人來測試程序會更加有效，也會更容易測試成功。請注意，我們的論據并不適合于“調試”（糾正已知的錯誤）。“調試”由程序的編寫人員來完成會有效得多。
點擊領取學習資料

3.編寫軟件的組織不應當測試自己編寫的軟件

．
這里的論據與前面的論據相似。從很多方面來講，一個軟件項目或編程組織是一個有機的機構，具有與個體程序員相似的心理問題。而且在大多數情況下，主要是根據其在給定時間、特定成本范圍內開發軟件的能力來衡量編程組織或項目經理。其中的一個原因是，度量時間和成本目標比較容易，而定量地衡量軟件的可靠性則極其困難．即便是合理規劃和實施的測試過程，也可能被認為降低了完成進度和成本目標的可能性，因此、編程組織難以客觀地測試自己的軟件。
同樣，我們并不是說編程組織發現程序中的問題是不可能的，事實上很多組織已經在某種程度上成功地做到了這一點。當然，我們的言下之意是，更經濟的方法是由客觀、獨立的第三方來進行測試。

4 應當徹底檢查每個測試的執行結果

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

5測試用例的編寫不僅應當根據有效和預期的輸入情況，而且也應當根據無效和未預料到的輸入情況。

在測試軟件時，有一個自然的傾向，即將重點集中在有效和預期的輸入情況上，而忽略了無效和未預料到的情況。比如，在本書第 l 章三角形程序的測試中，總是出現這個傾向。

例如，很少有人會向程序輸入 1，2，5 以證明程序不會錯誤地將其解釋為一個不規則三角形，而不是一個無效三角形。此外，在軟件產品中突然暴露出來的許多問題是當程序以某些新的或未預料到的方式運行時發現的。因此，針對未預料到的和無效輸入情況的測試用例，似乎比針對有效輸入情況的那些用例更能發現問題。
點擊領取學習資料

6.程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應該做的”。

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

7.避免測試用例用后即棄，除非軟件本身就是一個一次性的軟件

這個問題在采用交互式系統來測試軟件時最常見。人們通常會坐在終端前，匆忙地編寫測試用例，然后將這些用例交由程序執行。這樣做的問題在于，飽含我們寶貴投人的測試用例，在測試結束后就消失了，一旦軟件需要重新測試（例如，當改正了某個錯誤或作了某種改進后），又必須重新設計這些測試用例。情況往往是這樣的，由于重新設計測試用例需要投人大量的工作，人們總是避免這樣做。

因此，對該程序的重新測試極少會同上次一樣嚴格。這就意味著，如果對程序的更改導致了程序某個先前可以執行的部分發生了故障，這個故障往往是不會被發現的，保留測試用例，當程序其他部件發生更動后重新執行，這就是我們所謂的“回歸測試”。

8.劃測試工作時不應默許假定不會發現錯誤。

項目經理經常容易犯這個錯誤，這也是使用了不正確的測試定義的一個跡象——也就是說，假定“測試是一個證明程序正確運行的過程”。我們再一次重申，所謂測試，就是為發現錯誤而執行程序的過程。

10.件測試是一項極富創造性、極具智力挑戰性的工作

點擊領取學習資料

測試一個大型軟件所需要的創造性很可能超過了開發該軟件所需要的創造性．我們已經看到，要充分地測試一個軟件以確保所有錯誤都不存在是不可能的。本書后續章節討論的技術使我們能夠為某個軟件設計出合理的測試用例集，然而這些技術仍然需要大量的創造性

小結

點擊領取學習資料

請牢記以下三個重要的測試原則：

• 軟件測試是為發現錯誤而執行程序的過程。
• 一個好的測試用例具有較高的發現某個尚未發現的錯誤的可能性。
• 一個成功的測試用例能夠發現某個尚未發現的錯誤。

總結

以上是生活随笔為你收集整理的软件测试的艺术——软件测试的原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。