軟件測試的心理學(xué)和經(jīng)濟(jì)學(xué)

《軟件測試的心理學(xué)和經(jīng)濟(jì)學(xué)》由會員分享，可在線閱讀，更多相關(guān)《軟件測試的心理學(xué)和經(jīng)濟(jì)學(xué)（14頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、軟件測試的心理學(xué)和經(jīng)濟(jì)學(xué) 軟件測試是一項技術(shù)性工作，但同步也波及經(jīng)濟(jì)學(xué)和人類心理學(xué)的某些重要因　素。 在抱負(fù)狀況下,我們會測試程序的所有也許執(zhí)行狀況。然而,在大多數(shù)狀況下, 這幾乎是不也許的,雖然一種看起來非常簡樸的程序,其也許的輸入與輸出組合可　達(dá)到數(shù)百種甚至數(shù)千種，對所有的也許狀況都設(shè)計測試用例是不切合實際的。對一　個復(fù)雜的應(yīng)用程序進(jìn)行完全的測試，將耗費大最的時間和人力資源，以至于在經(jīng)濟(jì) 上是不可行的。 此外，要成功地測試一種軟件應(yīng)用程序，測試人員也需要有對的的態(tài)度(也許 用“愿景(ｖision)”這個詞會更好某些)。在某些狀況下，測試人員的態(tài)度也許比實　際的測試過程自身還要

2、重要。因此,在進(jìn)一步探討軟件測試更加技術(shù)化的本質(zhì)之前，　我們先探討一下軟件測試的心理學(xué)和經(jīng)濟(jì)學(xué)問題。 2.1 軟件測試的心理學(xué) 測試執(zhí)行得差，其中一種重要因素在于大多數(shù)的程序員一開始就把“測試”這 個術(shù)語的定義搞錯了,她們也許會覺得： ? “軟件測試就是證明軟件不存在錯誤的過程?！? ??“軟件測試的目的在于證明軟件可以對的完畢其預(yù)定的功能。” ? “軟件測試就是建立一種‘軟件做了其應(yīng)當(dāng)做的’信心的過程?！?這些定義都是本末倒置的?！∶慨?dāng)測試一種程序時，總是想為程序增長某些價值。通過測試來增長程序的價 值，是指測試提高了程序的可靠性或質(zhì)量。提高了程序的可靠性,是指找出并最后

3、 修改了程序的錯誤。因此不要只是為了證明程序可以對的運營而去測試程序；相反， 應(yīng)當(dāng)一開始就假設(shè)程序中隱藏著錯誤（這種假設(shè)對于幾乎所有的程序都成立)，然 后測試程序,發(fā)現(xiàn)盡量多的錯誤。 那么，對于測試，更為合適的定義應(yīng)當(dāng)是： “測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”。 雖然這看起來像是個微妙的文字游戲，但的確有重要的區(qū)別。理解軟件測試的 真正定義，會對成功地進(jìn)行軟件測試有很大的影響。 人類行為總是傾向于具有高度目的性，確立一種對的的目的有著重要的心理學(xué)　影響。如果我們的目的是證明程序中不存在錯誤，那就會在潛意識中傾向于實現(xiàn)這 個目的，也就是說，我們會傾向于選擇也許較少導(dǎo)致程序

4、失效的測試數(shù)據(jù)。另一方 面,如果我們的目的在于證明程序中存在錯誤,我們設(shè)計的測試數(shù)據(jù)就有也許更多 地發(fā)現(xiàn)間題。與前一種措施相比，后一種措施會更多地增長程序的價值。 這種對軟件測試的定義,涉及著無窮的內(nèi)蘊,其中的諸多都蘊涵在本書各處。 舉例來說,它暗示了軟件測試是一種破壞性的過程，甚至是一種“施虐”的過程, 達(dá)就闡明為什么人多數(shù)人都覺得它困難。這種定義也許是違背我們愿望的，所幸的　是,我們大多數(shù)人總是對生活布滿建設(shè)性而不是破壞性的愿景。大多數(shù)人都本能地 傾向于發(fā)明事物,而不是將事物破壞。這個定義還暗示了對于一種特定的程序：應(yīng)　該如何設(shè)計測試用例(測試數(shù)據(jù)）、哪些人應(yīng)當(dāng)而哪些人又不應(yīng)當(dāng)執(zhí)行測

5、試。 為增進(jìn)對軟件測試對的定義的理解,另一條途徑是分析一下對“成功的”和“不　成功的”這兩個詞的使用,當(dāng)項目經(jīng)理在歸納測試用例的成果時,特別會用到這兩 個詞。大多數(shù)的項日經(jīng)理將沒發(fā)現(xiàn)錯誤的測試用例稱為一次“成功的測試”，而將 發(fā)現(xiàn)了某個新錯誤的測試稱為“不成功的測試”。 這又是一次本末倒置。“不成功的”表達(dá)事情不遂人意或令人失望。我們覺得， 如果在測試某段程序時發(fā)現(xiàn)了錯誤,并且這些錯誤是可以修復(fù)的,就將這次合理設(shè) 計并得到有效執(zhí)行的測試稱作是“成功的”。如果本次測試可以最后擬定再無其她　可查出的錯誤，同樣也被稱作是“成功的”。所謂“不成功的”測試，僅指未能適　本地對程序進(jìn)行檢查,在

6、大多數(shù)狀況下,未能找出錯誤的測試被覺得是“不成功的”， 這是由于覺得軟件中不涉及錯誤的觀點基本上是不切實際的。 能發(fā)現(xiàn)新錯誤的測試用例不太也許被覺得是“不成功的”；相反,能發(fā)現(xiàn)錯誤　就證明它是值得設(shè)計的。一種“不成功的”測試用例．會使程序輸出對的的成果， 但不能發(fā)現(xiàn)任何錯誤. 我們可以類比一下病人看醫(yī)生的狀況，病人由于身體不舒服而去看醫(yī)生。如果 醫(yī)生對病人進(jìn)行了某些實驗檢測，卻沒有診斷出任何病因，我們就不會覺得這此實 驗檢測是“成功的”。之因此是“不成功的”檢側(cè),是由于病人支付了昂貴的實驗 檢測費用,而病狀卻仍然如故。病人會因此而質(zhì)疑醫(yī)生的診斷能力。但是,如果實 驗檢測診斷出病人

7、是胃潰瘍，那么這次檢測就是“成功的”,醫(yī)生可以開始進(jìn)行適 當(dāng)?shù)闹委煛Ｒ虼?醫(yī)療行業(yè)會使用“成功的”或“不成功的”來體現(xiàn)合適的意思。 我們固然可以類推到軟件測試中來，當(dāng)我們開始測試某個程序時,它就好似我們的 病人。 “軟件測試就是證明軟件不存在錯誤的過程”,這個定義會帶來第二個問題?！τ趲缀跛械某绦蚨?甚至是非常小的程序，這個目的事實上也是無法達(dá)到的。 此外，心理學(xué)研究表白,當(dāng)人們開始一項工作時，如果已經(jīng)懂得它是不可行的　或無法實現(xiàn)時，人的體現(xiàn)就會相稱糟糕。舉例來說，如果規(guī)定人們在 1５ 分鐘之內(nèi) 完畢星期日《紐約時報》里的縱橫填字游戲,那么我們會觀測到 l0 分鐘之后的進(jìn)展　

8、非常小，由于大多數(shù)人都會卻步于這個現(xiàn)實,即這個任務(wù)似乎是不也許完畢的。但 是如果規(guī)定在四個小時之內(nèi)完畢填字游戲,我們很也許有理由盼望在最初 10　分鐘 之內(nèi)的進(jìn)展會比前一種狀況下的大。將軟件測試定義為發(fā)現(xiàn)程序錯誤的過程，使得　測試是個可以完畢的任務(wù)，從而克服了這個心理障礙。 諸如“軟件測試就是證明‘軟件做了其應(yīng)當(dāng)做的’的過程”此類的定義所帶來 的第三個問題是，程序雖然可以完畢預(yù)定的功能，也仍然也許隱藏錯誤。也就是說，　當(dāng)程序沒有實現(xiàn)預(yù)期功能時，錯誤是清晰地顯現(xiàn)出來的；如果程序做了其不應(yīng)當(dāng)做　的，這同樣是一種錯誤;考慮一下第 l 章中的三角形測試程序。雖然我們證明了程 序可以對的辨認(rèn)出不規(guī)

9、則三角形、等腰三角形和等邊三角形，但是在完畢了不應(yīng)執(zhí) 行的任務(wù)后(例如將 1,2,3 說成是一種不規(guī)則三角形或?qū)?０，0，0 說成是一種等 邊三角形），程序仍然是錯的。如果我們將軟件測試視作發(fā)現(xiàn)錯誤的過程，而不是 將其視為證明“軟件做了其應(yīng)當(dāng)做的”的過程,我們發(fā)現(xiàn)后一類錯誤的也許性會大 諸多。 總結(jié)一下，軟件測試更適合被視為試圖發(fā)現(xiàn)程序中錯誤（假設(shè)其存在）的破壞 性的過程。一種成功的測試用例,通過誘發(fā)程序發(fā)生錯誤，可以在這個方向上增進(jìn)軟件質(zhì)量的改善。固然，最后我們還是要通過軟件測試來建立某種限度的信心:軟 件做了其應(yīng)當(dāng)做的，未做其不應(yīng)當(dāng)做的。但是通過對錯誤的不斷研究是實現(xiàn)這個目　的

10、的最佳途徑。 有人也許會聲稱“本人的程序完美無缺”(不存在錯誤)，針對這種狀況建立起 信心的最佳措施就是盡量辯駁她，即努力發(fā)現(xiàn)不完美之處,而不只是確認(rèn)程序在某 些輸入狀況下可以對的地工作。 2．2 軟件測試的經(jīng)濟(jì)學(xué) 給出了軟件測試的合適定義之后，下一步就是擬定軟件測試與否可以發(fā)現(xiàn)“所　有”的錯誤。我們將證明答案與否認(rèn)的，雖然是規(guī)模很小的程序。一般說來，要發(fā)　現(xiàn)程序中的所有錯誤也是不切實際的,常常也是不也許的。這個基本的問題反過來　暗示出軟件測試的經(jīng)濟(jì)學(xué)問題、測試人員對被測軟件的盼望,以及測試用例的設(shè)計 方式。 為了應(yīng)對測試經(jīng)濟(jì)學(xué)的挑戰(zhàn)，應(yīng)當(dāng)在開始測試之前建立某些方略

11、。黑盒測試和 白盒測試是兩種最普遍的方略,我們將在下面兩節(jié)中討論。 2.2.1 黑盒測試 黑盒測試是一種重要的測試方略,又稱為數(shù)據(jù)驅(qū)動的測試或輸入/輸出驅(qū)動的測 試。使用這種測試措施時,將程序視為一種黑盒子。測試目的與程序的內(nèi)部機(jī)制和　構(gòu)造完全無關(guān),而是將重點集中放在發(fā)現(xiàn)程序不按其規(guī)范對的運營的環(huán)境條件。 在這種措施中,測試數(shù)據(jù)完全來源于軟件規(guī)范(換句話說,不需要去理解程序 的內(nèi)部構(gòu)造)。如果想用這種措施來發(fā)現(xiàn)程序的所有錯誤,鑒定的原則就是“窮舉　輸入測試”,將所有也許的輸入條件都作為測試用例。為什么這樣做?例如說在三 角形測試的程序中，試過了三個等邊三角形的測試用例。

12、這不能保證對的地判斷出 所有的等邊三角形。程序中也許涉及對邊長為 3842,384２，384２　的特殊檢查,并　指出此三角形為不規(guī)則三角形。由于程序是個黑盒子，因此可以擬定此條語句存在 的惟一措施,就是實驗所有的輸入狀況。 要窮舉測試這個三角形程序，也許需要為所有有效的三角形創(chuàng)立測試用例，只要三角形邊長在開發(fā)語言容許的最大整數(shù)值范疇內(nèi)。這些測試用例自身就是天文數(shù) 字,但這還決不是所謂窮盡的，當(dāng)程序指出-3，4，5 是一種不規(guī)則三角形或 ２，Ａ， 2 是一種等腰三角形時，問題就暴露出來了,為了保證可以發(fā)現(xiàn)所有這樣的錯誤，　不僅得用所有有效的輸入,并且還得用所有也許的輸入進(jìn)行測試。因

13、此，為了窮舉　測試三角形程序，事實上需要創(chuàng)立無限的測試用例:這固然是不也許的。 如果測試這個三角形程序都這樣難的話，那么要窮舉測試一種稍大些的程序的 難度就更大了,設(shè)想一下,如果要對一種 C＋+編譯器進(jìn)行黑盒窮舉測試,不僅要創(chuàng)　建代表所有有效 C++程序的測試用例（事實上,這又是個無窮數(shù)），還需要創(chuàng)立代 表所有無效 C+＋程序的測試用例（無窮數(shù)）,以保證編譯器可以檢測出它們是無效 的。也就是說，編譯器必須進(jìn)行測試,保證其不會執(zhí)行不應(yīng)執(zhí)行的操作——如順利　地編譯成功一種語法上不對的的程序。 如果程序使用到數(shù)據(jù)存儲，如操作系統(tǒng)或數(shù)據(jù)庫應(yīng)用程序,這個問題會變得尤 為嚴(yán)重。舉例來說,在航班

14、預(yù)定系統(tǒng)這樣的數(shù)據(jù)庫應(yīng)用程序中，諸如數(shù)據(jù)庫查詢、 航班預(yù)約這樣的事務(wù)解決需要隨上次事務(wù)的執(zhí)行狀況而定，因此,不僅要測試所有　有效的和無效的事務(wù)解決，還要測試所有也許的事務(wù)解決順序。 上述討論闡明，窮舉輸入測試是無法實現(xiàn)的,這有兩方面的含義,一是我們無 法測試一種程序以保證它是無錯的，二是軟件測試中需要考慮的一種基本問題是軟　件測試的經(jīng)濟(jì)學(xué)。也就是說,由于窮舉測試是不也許的,測試投人的目的在于通過 有限的測試用例,最大限度地提高發(fā)現(xiàn)的問題的數(shù)量,以獲得最佳的測試效果。除　了其她因素之外,要實現(xiàn)這個目的，還需要可以窺見軟件的內(nèi)部,對程序作些合理　但非無懈可擊的假設(shè)(例如,如果三角形程序?qū)?２

15、,2,2　視為等邊三角形，那就有 理由覺得程序?qū)Α?,3，３ 也作同樣判斷）。這種思路將形成本書第 4　章中測試用例　設(shè)計方略的部分措施。 2.2.２　 白盒測試 另一種測試方略稱為白盒測試或稱邏輯驅(qū)動的測試,容許我們檢查程序的內(nèi)部 構(gòu)造。這種測試方略對程序的邏輯構(gòu)造迸行檢查,從中獲取測試數(shù)據(jù)（遺憾的是，　常常忽視了程序的規(guī)范)。在這里我們的目的是針對達(dá)種測試方略,建立起與黑盒測試中窮舉輸入測試相 似的測試措施。也許有一種解決的措施，即將程序中的每條語句至少執(zhí)行一次。但 是我們不難證明,這還是遠(yuǎn)遠(yuǎn)不夠的。這種措施一般稱為窮舉途徑測試，在本書第 ４　章中將進(jìn)一步進(jìn)行進(jìn)一步

16、探討,在這里就不多加論述。所謂窮舉途徑測試，即如果 使用測試用例執(zhí)行了程序中所有也許的控制流途徑,那么程序有也許得到了完全測 試。 然而，這個論斷存在兩個問題。一方面,程序中不同邏輯途徑的數(shù)最也許達(dá)到天 文數(shù)字。圖 2-1　所示的小程序顯示了這一點。該圖是一種控制流圖,每一種結(jié)點或 圓圈都代表一種按順序執(zhí)行的語句段,一般以一種分支語句結(jié)束。每一條邊或弧線　表達(dá)語句段之間的控制（分支)的轉(zhuǎn)換。圖 ２-1 描述的是一種有著　10~20 行語句的 程序，涉及一種迭代 2０　次的?。腛 循環(huán)。在?。腛 循環(huán)體中，涉及一系列嵌套的 IF 語 句。要擬定不同邏輯途徑的數(shù)量,也相稱于要擬定從點 a～點

17、 b 之間所有不同途徑的　數(shù)量(假定程序中所有的判斷語句都是互相獨立的）。這個數(shù)量大概是 １01４，即 １０0 萬億，是從 520+5１9…　十　51 計算而來，5　是循環(huán)體內(nèi)的途徑數(shù)量。由于大多數(shù)的人 難以對這個數(shù)字有一種直觀的概念，不妨設(shè)想一下:如果在每五分鐘內(nèi)可以編寫、 執(zhí)行和確認(rèn)一種測試用例，那么需要大概 １0 億年才干測試完所有的途徑。如果可　以快上　300 倍,每秒就完畢一次測試,也得用漫長的　320 萬年才干完畢這項工作. 圖　2-1 一種小型程序的控制流圖 固然

18、,在實際程序中,判斷并非都是彼此獨立的,這意味著也許實際執(zhí)行的路　徑數(shù)量要稍微少某些。但是，從另一方面來講，實際應(yīng)用的程序要比圖 ２－1　所描述　的簡樸程序復(fù)雜得多。因此，窮舉途徑測試就猶如窮舉輸入測試，非但不也許，也　是不切實際的。 “窮舉途徑測試即完全的測試”論斷存在的第二個問題是,雖然我們可以測試 到程序中的所有途徑，但是程序也許仍然存在著錯誤。這有三個因素。 第一，雖然是窮舉途徑測試也決不能保證程序符合其設(shè)計規(guī)范。舉例來說，如　果要編寫一種升序排序程序,但卻錯誤地編成了一種降序排序程序，那么窮舉途徑 測試就沒多大價值了;程序仍然存在著一種缺陷:它是個錯誤的程序由于不符合設(shè)

19、計的規(guī)范。 第二，程序也許會由于缺少某些途徑而存在問題。窮舉途徑測試固然不能發(fā)現(xiàn)　缺少了哪些必需途徑． 第三，窮舉途徑測試也許不會暴露數(shù)據(jù)敏感錯誤。這樣的例子有諸多,舉一種 簡樸的例子就能闡明問題。假設(shè)在某個程序中要比較兩個數(shù)值與否收斂，也就是檢 查兩個數(shù)值之間的差別與否不不小于某個既定的值。例如,我們也許會這樣編一條　Java　語言的 IF 語句: iｆ (a　– b < c)　Systｅｍ.Out.println(“a-b<ｃ”); 固然，這條語句涉及一種錯誤,由于它也許將 ｃ　與 a－b 的絕對值進(jìn)行比較?！∪欢页鲞@樣的錯誤，取決于 a 和 b 所取的值，而僅僅執(zhí)

20、行程序中的每條路 徑并不一定能找出錯誤來。 總之,盡管窮舉輸入測試要強(qiáng)于窮舉途徑測試，但兩者都不是有效的措施，因 為這兩種措施都不可行。那么,也許存在別的措施，將黑盒測試和白盒測試的要素 結(jié)合起來,形成一種合理但并不十分完美的測試方略。本書的第　４ 章將進(jìn)一步討論這 個話題。 2.３ 軟件測試的原則 讓我們繼續(xù)本章的話題基本,即軟件測試中大多數(shù)重要的問題都是心理學(xué)問 題。我們可以歸納出一系列重要的測試指引原則，這些原則看上去大多都是顯而易 見的,但常常總是被我們忽視掉。表 2-l 總結(jié)了這些重要原則，每條原則都將在下 面的章節(jié)中具體簡介。 表 2-1 軟件測試

21、的重要原則 編號 原則 1 測試用例中一種必需部分是對預(yù)期輸出或成果進(jìn)行定義 2 程序員應(yīng)避免測試自己編寫的程序 3 編寫軟件的組織不應(yīng)當(dāng)測試自已編寫的軟件 4 應(yīng)當(dāng)徹底檢查每個測試的執(zhí)行成果 5 測試用例的編寫不僅應(yīng)當(dāng)根據(jù)有效和預(yù)料到的輸入狀況,并且也應(yīng)當(dāng)根據(jù)無效 和未預(yù)料到的輸入狀況 6 檢查程序與否“未做其應(yīng)當(dāng)做的”僅是測試的一半，測試的另一半是檢查程是 否“做了其不應(yīng)當(dāng)做的” 7 應(yīng)避免測試用例用后即棄，除非軟件自身就是個一次性的軟件 8 籌劃測試工作時不應(yīng)默許假定不會發(fā)現(xiàn)錯誤 9 程序某部分存在更多錯誤的也許性，與該部分已發(fā)現(xiàn)錯誤的數(shù)量

22、成正比 10 軟件測試是一項極富發(fā)明性,極具智力的挑戰(zhàn)性的工作 原則 ｌ:測試用例中一種必需部分是對預(yù)期輸出或成果的定義。 這條顯而易見的原則在軟件測試中是最常犯的錯誤之一。同樣，這個問題也是 基于人們的心理的。如果某個測試用例的預(yù)期成果事先沒有得到定義,由于“所見 即所想”現(xiàn)象的存在。某個似是而非、事實上是錯誤的成果也許會被解釋成對的的 結(jié)論。換句話說,盡管“軟件測試是破壞性”的定義是合理的,但人們在潛意識中 仍然渴望看到對的的成果?？朔@種傾向的一種措施、就是通過事先精擬定義程序 的預(yù)期輸出,鼓勵人們對所有的輸出進(jìn)行仔細(xì)檢查。因此,一種測試用例必須涉及 兩個部分:

23、 １.對程序的輸入數(shù)據(jù)的描述。 2.對程序在上述輸入數(shù)據(jù)下的對的輸出成果的精確描述。 所謂“問題”,可以歸納為一種或一組我們不能給出可信服的解釋、看上去不 太正?；虿环衔覀兣瓮蝾A(yù)想的事實。應(yīng)當(dāng)明確的是,在擬定事物存在“問題” 之前,人們必須已經(jīng)形成特定的結(jié)識。沒有盼望，也就沒有所謂的意外?！≡瓌t 2：程序員應(yīng)當(dāng)避免測試自己編寫的程序． 任何作者都懂得或應(yīng)當(dāng)懂得,親自編輯或校對自己的作品的確是個不好的做 法。作者清晰某段文字要闡明的是什么,實際體現(xiàn)出來的意思卻南轅北轍,而自己 也許卻意識不到。況且事實上也不會想在自己的作品中找出什么錯誤來。對程序員 而言,也存在相似的問題。

24、 如果我們對軟件項目關(guān)注的重點發(fā)生變化,就會產(chǎn)生此外一種問題。當(dāng)程序員　“建設(shè)性”地設(shè)計和編寫完程序之后,很難讓她忽然變化視角以一種“破壞性”的 眼光來審查程序。正如許多房屋業(yè)主都懂得的那樣,撕下屋里的墻紙(這是個破壞 性的過程）并不容易，如果這些墻紙又恰恰是業(yè)主第一種親手貼的，特別令其沮喪 不已。同樣，大多數(shù)程序員都不能有效地測試自己編寫的程序,由于她們無法變化 思維方式來竭力暴露自己程序中的錯誤。此外，程序員也許會下意識地避免找出錯 誤來，緊張受到同事、上司、客戶或正在開發(fā)的程序或系統(tǒng)的主管的懲罰。 僅次于上面的心理學(xué)問題,尚有一種重要的問題:由干程序員錯誤地理解了疑 難定義或規(guī)范，

25、導(dǎo)致程序中存在錯誤。如果狀況是這樣,程序員也許會帶著同樣的誤解來測試自己的程序。 這并不意味著程序員測試自己的程序是不也許的。固然，我們的言下之意是,　讓其她人來測試程序會更加有效,也會更容易測試成功。 請注意,我們的論據(jù)并不適合于“調(diào)試”(糾正已知的錯誤）?！罢{(diào)試”由程序 的編寫人員來完畢會有效得多。 原則 3：編寫軟件的組織不應(yīng)當(dāng)測試自己編寫的軟件.　這里的論據(jù)與前面的論據(jù)相似。從諸多方面來講，一種軟件項目或編程組織是 一種有機(jī)的機(jī)構(gòu),具有與個體程序員相似的心理問題。并且在大多數(shù)狀況下，重要 是根據(jù)其在給定期間、特定成本范疇內(nèi)開發(fā)軟件的能力來衡量編程組織或項目經(jīng)

26、理。其中的一種因素是，度量時間和成本目的比較容易,而定量地衡量軟件的可靠 性則極其困難．即便是合理規(guī)劃和實行的測試過程,也也許被覺得減少了完畢進(jìn)度 和成本目的的也許性，因此、編程組織難以客觀地測試自己的軟件。 同樣，我們并不是說編程組織發(fā)現(xiàn)程序中的問題是不也許的，事實上諸多組織 已經(jīng)在某種限度上成功地做到了這一點。固然,我們的言下之意是，更經(jīng)濟(jì)的措施 是由客觀、獨立的第三方來進(jìn)行測試。 原則 4：應(yīng)當(dāng)徹底檢查每個測試的執(zhí)行成果。 這個原則也許是最顯而易見的原則,但也同樣常常被忽視。我們見過大量的例 子，即便錯誤的癥狀在輸出清單中可以清晰地看到，但還是沒有找出那些錯誤來。 換

27、言之，在后續(xù)測試中發(fā)現(xiàn)的錯誤,往往是前面的測試漏掉掉的。 原則 5：測試用例的編寫不僅應(yīng)當(dāng)根據(jù)有效和預(yù)期的輸入狀況，并且也應(yīng)當(dāng)根據(jù)無 效和未預(yù)料到的輸入狀況。 在測試軟件時，有一種自然的傾向，即將重點集中在有效和預(yù)期的輸入狀況上, 而忽視了無效和未預(yù)料到的狀況。例如,在本書第 l 章三角形程序的測試中,總是　浮現(xiàn)這個傾向。 例如,很少有人會向程序輸入 1，2,５　以證明程序不會錯誤地將其解釋為一種　不規(guī)則三角形,而不是一種無效三角形。此外，在軟件產(chǎn)品中忽然暴露出來的許多 問題是當(dāng)程序以某些新的或未預(yù)料到的方式運營時發(fā)現(xiàn)的。因此，針對未預(yù)料到的 和無效輸入狀

28、況的測試用例，似乎比針對有效輸入狀況的那些用例更能發(fā)現(xiàn)問題。 原則　６：檢查程序與否“未做其應(yīng)當(dāng)做的”僅是測試的一半，測試的另一半是檢查 程序與否“做了其不應(yīng)當(dāng)做的”。 這條原則是上條原則的必然成果。必須檢查程序與否有我們不但愿的負(fù)作用?！±纾硞€工資管理程序即便可以生成對的的工資單，但是如果也為非雇員生成工 資單或者它覆蓋掉了人員文獻(xiàn)的第一條記錄,這樣的程序仍然是不對的的程序。 原則　7:應(yīng)避免測試用例用后即棄，除非軟件自身就是一種一次性的軟件。 這個問題在采用交互式系統(tǒng)來測試軟件時最常用。人們一般會坐在終端前,匆 忙地編寫測試用例，然后將這些用例交由程序執(zhí)行。這樣做的

29、問題在于,飽含我們 珍貴投人的測試用例,在測試結(jié)束后就消失了,一旦軟件需要重新測試(例如,當(dāng) 改正了某個錯誤或作了某種改善后）,又必須重新設(shè)計這些測試用例。狀況往往是 這樣的,由于重新設(shè)計測試用例需要投人大量的工作,人們總是避免這樣做。因此， 對該程序的重新測試很少會同上次同樣嚴(yán)格。這就意味著，如果對程序的更改導(dǎo)致　了程序某個先前可以執(zhí)行的部分發(fā)生了故障,這個故障往往是不會被發(fā)現(xiàn)的,保存 測試用例,當(dāng)程序其她部件發(fā)生更動后重新執(zhí)行,這就是我們所謂的“回歸測試”。 原則　8:籌劃測試工作時不應(yīng)默許假定不會發(fā)現(xiàn)錯誤。 項目經(jīng)理常常容易犯這個錯誤，這也是使用了不對的的測試定義的一種跡象—

30、 —也就是說，假定“測試是一種證明程序?qū)Φ倪\營的過程”。我們再一次重申，所 謂測試,就是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 原則 9：程序某部分存在更多錯誤的也許性,與該部分已發(fā)現(xiàn)錯誤的數(shù)目成正比?！∵@種現(xiàn)象如圖　2-２ 所示。乍看上去，這幅圖似乎沒有什么意義，但諸多程序都存在這種現(xiàn)象。例如,如果某個程序由兩個模塊、類或子程序 Ａ 和 B　 構(gòu)成，模塊A 中已經(jīng)發(fā)現(xiàn)了五個錯誤,而模塊 Ｂ 中僅僅找到了一處錯誤。如果模塊?。痢∷ㄟ^　的測試并不是故意設(shè)計得更為嚴(yán)格,那么該原則告訴我們,模塊 A 與模塊 B 相比,　存在更多錯誤的也許性要大。 該原則的另一種說法是,錯誤總是傾向于匯集存在

31、，而在一種具體的程序中, 某些部分要比其她部分更容易存在錯誤，盡管沒有人可以對這種現(xiàn)象給出較好的解　釋。這種現(xiàn)象之因此有用.是由于它予以了我們對軟件測試過程的洞察或反饋。如　果一種程序的某個部分遠(yuǎn)比其她部分更容易產(chǎn)生錯誤．那么這種現(xiàn)象告訴我們,為 了使測試獲得更大的成效，最佳對這些容易存在錯誤的部分進(jìn)行額外的測試。 圖 2-2 　殘存錯誤與已知錯誤間令人驚奇的聯(lián)系 原則 10：軟件測試是一項極富發(fā)明性、極具智力挑戰(zhàn)性的工作。 測試一種大型軟件所需要的發(fā)明性很也許超過了開發(fā)該軟件所需要的發(fā)明 性.我們已經(jīng)看到，要充足地測試一種軟件以保證所有錯誤都不存在是不也許的。 本書后續(xù)章節(jié)討論的技術(shù)使我們可覺得某個軟件設(shè)計出合理的測試用例集，然而這 些技術(shù)仍然需要大量的發(fā)明性。 ２.4 小結(jié) 在閱讀本書接下來的內(nèi)容時，請牢記如下三個重要的測試原則: ? 軟件測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 ??一種好的測試用例具有較高的發(fā)現(xiàn)某個尚未發(fā)現(xiàn)的錯誤的也許性。 ? 一種成功的測試用例可以發(fā)現(xiàn)某個尚未發(fā)現(xiàn)的錯誤.