軟件測試心理學(xué)和經(jīng)濟學(xué)（一）

1、軟件測試的心理學(xué)

在某些情況下，測試人員的態(tài)度可能比實際的測試過程本身還要重要。

（1）對于“測試”的誤解

軟件測試就是證明軟件不存在錯誤的過程。

軟件測試的目的在于證明軟件能夠正確完成其預(yù)定的功能。

軟件測試就是建立一個“軟件做了其應(yīng)該做的”信心的過程。

（2）正確的理解

每當(dāng)測試一個程序時，應(yīng)當(dāng)想到要為程序增加一些價值。如：提高程序的可靠性或質(zhì)量。

測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。

軟件測試是一個破壞性的過程，甚至是一個“施虐”的過程。

軟件的錯誤包含兩種：（1）程序沒有實現(xiàn)預(yù)期功能。（2）程序做了其不應(yīng)該做的。

2、軟件測試的經(jīng)濟學(xué)

一般來說，要發(fā)現(xiàn)程序中的所有錯誤也是不切實際的，常常也是不可能的。

2.1 黑盒測試

黑盒測試是一種重要的測試策略，又稱為數(shù)據(jù)驅(qū)動的測試或輸入/輸出驅(qū)動的測試。使用這種測試方法時，將程序視為一個黑盒子。測試目標(biāo)與程序的內(nèi)部機制和結(jié)構(gòu)完全無關(guān)，而是將重點集中放在發(fā)現(xiàn)程序不按其規(guī)范正確運行的環(huán)境條件。在這種方法中，測試數(shù)據(jù)完全來源于軟件規(guī)范（不需要去了解程序的內(nèi)部結(jié)構(gòu)）。

如果想要用這種方法來發(fā)現(xiàn)程序的所有錯誤，判定的標(biāo)準(zhǔn)就是“窮舉輸入測試”，將所有可能的輸入條件都作為測試用例。

窮舉輸入測試是無法實現(xiàn)的。兩個含義：一、我們無法測試一個程序以確保它是無錯的。二、軟件測試中需要考慮的一個基本問題是軟件測試的經(jīng)濟學(xué)。也就是說由于窮舉測試是不可能的，測試投入的目標(biāo)在于通過有限的測試用例，最大限度地提高發(fā)現(xiàn)的問題的數(shù)量，以取得最好的測試效果。

2.2 白盒測試

白盒測試，又稱邏輯驅(qū)動測試，允許我們檢查程序的內(nèi)部結(jié)構(gòu)。這種測試策略對程序的邏輯結(jié)構(gòu)進行檢查，從中獲取測試數(shù)據(jù)。（常常忽略了程序規(guī)范）。

使用測試用例執(zhí)行了程序中所有可能的控制流路徑，那么程序有可能得到了完全測試。此方法稱為窮舉路徑測試。

窮舉路徑測試存在兩個問題：一、程序中不同邏輯路徑的數(shù)量可能達到天文數(shù)字，實際執(zhí)行是不可能且不實際的。

二、雖然我們可以測試到程序中的所有路徑，但是程序可能仍然存在著錯誤。

原因：

1.即使是窮舉路徑測試也決不能保證程序符合其設(shè)計規(guī)范。

如：要編寫一個升序排序程序，但錯誤的編寫成一個降序排序的程序。這樣即使進行窮舉路徑測試也沒多大價值，程序本身就是一個錯誤程序，不符合設(shè)計規(guī)范。

2.程序可能會因為缺少某些路徑而存在問題。

窮舉路徑測試不能發(fā)現(xiàn)缺少了哪些必需路徑。

3.窮舉路徑測試可能不會暴露數(shù)據(jù)敏感錯誤。

如：程序要比較兩個數(shù)值是否收斂，也就是檢查兩個數(shù)值之間的差是否小于某個既定的值，而僅僅執(zhí)行程序中的每條路徑并不一定能找出錯誤。

if(a - b < c)System.out.println("a - b < c");程序的原意是將a - b的絕對值和c比較，要找出這樣的錯誤，取決于a，b的取值，而僅僅執(zhí)行程序中的每一條路徑并不一定能找出錯誤來。

軟件測試的原則

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

事先精確定義程序的預(yù)期輸出，鼓勵人們對所有輸出進行仔細檢查。因此，一個測試用例必須包括兩個部分： 1.對程序的輸入數(shù)據(jù)描述。 2.對程序在上述輸入數(shù)據(jù)下的正確輸出結(jié)果的精確描述。

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

當(dāng)程序員“建設(shè)性”地設(shè)計和編寫完程序之后，很難讓他突然改變視角以一種“破壞性”的眼光來審查程序。 原因有兩個： 1.大多數(shù)程序員都不能有效地測試自己編寫的程序，因為他們無法改變思維方式來盡力暴露自己程序中的錯誤。另外，程序員可能會下意識地避免找出錯誤來，擔(dān)心受到同事、上司、客戶或正在開發(fā)的程序或系統(tǒng)的主管的懲罰。 2.另一個原因，由于程序員錯誤地理解了疑難定義或規(guī)范，導(dǎo)致程序中存在錯誤。如果情況是這樣，程序員可能會帶著同樣的誤解來測試自己的程序。以上論據(jù)不適合于“調(diào)試”，“調(diào)試”由程序的編寫人員來完成會有效的多。

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

由于一個軟件項目或編程組織是一個有機的機構(gòu)，具有與個體程序員相似的心理問題。

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

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

在軟件產(chǎn)品中突然暴露出來的許多問題是當(dāng)程序以某些新的或未預(yù)料到的方式運行時發(fā)現(xiàn)的。因此，針對未預(yù)料到的和無效輸入情況的測試用例，似乎比針對有效輸入情況的那些用例更能發(fā)現(xiàn)問題。

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

這條原則是上一條原則的必然結(jié)果，必須檢查程序是否有我們不希望的負作用。

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

由于測試用例用后即棄，一旦軟件需要重新測試（如：當(dāng)改正了某個錯誤或作了某種改進后），又必須重新設(shè)計這些測試用例。情況往往是這樣的，由于重新設(shè)計測試用例需要投入大量的工作，人們總是避免這樣做。因此，對該程序的重新測試極少會同上一次一樣嚴(yán)格。這就意味著，如果對程序的更改導(dǎo)致了程序某個先前可以執(zhí)行的部分發(fā)生了故障，這個故障往往是不會被發(fā)現(xiàn)的。保留測試用例，當(dāng)程序其他部件發(fā)生更動后重新執(zhí)行，這就是我們所謂的“回歸測試”。

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

測試，是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程，不是證明程序正確運行的過程。

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

錯誤總是傾向于聚集存在，而在一個具體的程序中，某些部分要比其他部分更容易存在錯誤，盡管沒有人能夠?qū)@種現(xiàn)象給出很好的解釋。

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

幾個重要的測試原則（總結(jié)）

（1）軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行的過程。 （2）盡量避免編碼人員測試自己的程序。 （3）好的測試用例能夠?qū)ξ窗l(fā)現(xiàn)的錯誤高度敏感。 （4）成功的測試用例能夠發(fā)現(xiàn)未知的錯誤。 （5）成功的測試用例需要仔細定義輸入輸出的期望值。 （6）成功的測試需要仔細研究分析測試結(jié)果。

總結(jié)

以上是生活随笔為你收集整理的软件测试的艺术读书笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。