2023-學(xué)習(xí)資料大全：《軟件測試的藝術(shù)》讀書筆記

知識改變命運勤奮塑造成功整理人落葉時間2011-4-15天才是百分之九十九的勤奮加百分之一的靈感TheArtofSoftWareTesting?讀書筆記〔1〕_引子有關(guān)自己與軟件測試之間的淵源而言，得悉這個領(lǐng)域的時間不長，接觸的時間就更可謂短暫，但仔細想來，還要從大學(xué)期間說起比擬好。軟件測試這個概念第一次出現(xiàn)在我的眼前時，是大四上學(xué)期開的軟件工程這個科目中所涉及到的一點點。由于某些因素，使我在大學(xué)期間忽略了對測試領(lǐng)域相關(guān)知識的儲藏。第二次面對它時，是考研復(fù)習(xí)準(zhǔn)備階段。那時，我對測試這個領(lǐng)域也僅僅只是知道，就是中文書面表達的“測試〞這兩個漢字的含義而已。工作的前兩年里，或許是因為從事的是有關(guān)算法方面性質(zhì)的工作，所以并未對測試這個領(lǐng)域給予過多的關(guān)注，還好，或多或少還是接觸到了一些。直到最近一年多來，由于一個大型工程人手不夠的緣故，所以臨時從自己負責(zé)的另一個研究工程中抽過來〔剛好該工程階段性完成〕，負責(zé)有關(guān)此工程的測試部署與規(guī)劃。而這個時候，才能說是：真正意義上接觸到了軟件測試這個領(lǐng)域。雖然，在此工程中也有自己開發(fā)的一些模塊、算法及一些模塊、算法的優(yōu)化跟重構(gòu)。但，從這個工程階段性結(jié)束后自己的體會而言，給我感悟最深的還是有關(guān)軟件測試這個領(lǐng)域的。通過在這個工程里的工作，讓我真正體會到了：軟件測試是一門藝術(shù)。恰恰也是因為這個緣故，這也才讓我開始有了想重新認識和品位測試藝術(shù)這一領(lǐng)域的微妙所在。?TheArtofSoftWareTesting?讀書筆記〔2〕_前言喜歡在網(wǎng)上書店中遛達，看到不錯的書就買下。為什么不去書店？一個字，懶唄！總覺得，有那去書店的時間，完全可以好好睡一美覺，亦或可親手烹制一頓美味可口的美食。哎，反正就是，懶得走出家門去逛街！恰巧，此次瀏覽書籍時，無意間看到了?TheArtofSoftwareTesting?這本書。在看了大家所給予它極高的評價留言后，雖然有些疑惑〔畢竟這個時代，槍手太多了！〕，但我深信：一本書能夠“活〞25年，應(yīng)該還是很不簡單的。于是，就半信半疑的訂購了這本書，期望能夠從這本書中得悉到有用的知識，來豐富一下自己面對這個領(lǐng)域時的貧乏困境，亦作為知識儲藏。暈，這么薄！這是我拿到這本書后的第一反響。真的！沒有預(yù)料到這書會這么?。≡詾檫@本經(jīng)典的書，會諸如?C++Primer?、?TheC++ProgrammingLanguage?、?ProgrammingWindows?等這些著作那么厚。而當(dāng)翻看了幾章后，覺得確實很經(jīng)典，也明白了為什么這本書會“活〞了25年。于是，就誕生了我對這本書的第二感覺：薄而精！看來是需要自己多花些時間去慢慢的品味，這樣才方可體味到最純最美的底醞。打住自己對這本書的侃侃而談〔怕跑題太遠，拽不回來〕，還是關(guān)注一下軟件測試這個領(lǐng)話題吧！軟件測試，怎么說呢？就自身經(jīng)歷而言，確實如書上所說：測試依然是軟件開發(fā)中的“黑色藝術(shù)〞。大學(xué)期間，計算機課程開的不少，沒聽說有專門開一門關(guān)于測試的課程。所以，在學(xué)生階段，測試就屬于是個被拋棄掉的名詞！畢業(yè)時，不是做軟件就是去搞網(wǎng)絡(luò)，沒有聽到一個同學(xué)去應(yīng)聘測試的！工作中，有專門的測試組〔或部門〕，就更不用自己怎么上心去研究了！如今的氣氛就是：紅的夠紅，黑的夠黑！那叫一個“專〞！哎，為什么不實行“兩手都要抓，兩手都要硬〞的政策呢〔一己之見，偏頗在所難免〕？或許，我還不明白：“術(shù)業(yè)有專攻〞的深刻含義吧！算了，最后還是談?wù)剬@本書的總觀吧！該書是針對測試這一主題進行的實踐探討，而不是理論研究，順便捎帶了些對新的語言和過程的探討；前言中提到了一個最為重要而又是長期、根本的指南：如何確保所開發(fā)的所有軟件做了其應(yīng)該做的，并且同樣重要的是，未做其不應(yīng)該做的？引言里指出一條著名的經(jīng)驗：即在一個典型的編程工程中，軟件測試或系統(tǒng)測試大約占用50%的工程時間和超過50%的總本錢。?TheArtofSoftWareTesting?讀書筆記〔3〕_一次自我檢測有創(chuàng)意！這是我對該書第一章的評價，也是唯一一次在看新書開篇時，能夠把第一章給透透徹徹看完的。為何？還不是實在不能恭維有些書籍在開篇就進行枯燥而繁多的總結(jié)性、介紹性的文字。雖心里也清楚這些文字存在的重要性。但每每，還總是先粗略瞄過，在通讀全書后，才會再次認認真真的看那些文字〔這時，才真的能感悟到“提綱攜領(lǐng)〞的中文含義啊〕。創(chuàng)意在于：它只通過展示一次自評價測試，就能吸引我的眼球，并涌出一種想繼續(xù)向下讀的沖動；更能引起對自身一些有關(guān)邏輯思維〔考慮欠周全、縝密，存在盲點〕、聯(lián)想能力〔需拓展思維，要富于聯(lián)想與想像，即：思維“活〞起來〕、角度問題〔要巧妙轉(zhuǎn)換角度〕等方面，所可能存在的缺乏進行深思。當(dāng)然，能夠引起深思的緣故，還不是在于那個評價測試嘛！提起來，汗顏！依據(jù)所謂的測試用例〔即：特定的數(shù)據(jù)集合〕自測試后，發(fā)現(xiàn)自己只能考慮到11項〔總14項〕需要測試的關(guān)鍵點。文尾，談?wù)勛髡邔Α败浖y試〞這個概念的定義吧。所謂軟件測試，就是一個過程或一系列過程，用來確認計算機代碼完成了其應(yīng)該完成的功能，不執(zhí)行其不該有的操作。軟件應(yīng)當(dāng)是可預(yù)測且穩(wěn)定的，是不會給用戶帶來意外驚奇的。?TheArtofSoftWareTesting?讀書筆記〔4〕_初次探究“軟件測試是一項技術(shù)性工作，但同時也涉及經(jīng)濟學(xué)和人類心理學(xué)的一些重要因素〞，這是該書第二章中最吸引我的話，耐人深思。而對于該章的內(nèi)容，我個人覺得可概括為以下三個方面：心理學(xué)角度：駁斥了一些社會普遍存在的錯誤認識，并給出了測試的正確定義及在含義上進行了延伸?！灿脤懳恼律铣Ｓ玫男g(shù)語來說，是：先破后立?！辰?jīng)濟學(xué)角度：驗證軟件測試不能夠發(fā)現(xiàn)“所有〞的錯誤。〔術(shù)語是：各個擊破?！硽w納了軟件測試中的一些根本原那么〔術(shù)語是：歸納與演繹?！?，及三個重要的測試原那么：軟件測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程；一個好的測試用例具有較高的發(fā)現(xiàn)某個尚未發(fā)現(xiàn)的錯誤的可能性；一個成功的測試用例能夠發(fā)現(xiàn)某個尚未發(fā)現(xiàn)的錯誤。文尾，值得一提的是：在本章能明顯感到作者側(cè)重于從心理學(xué)角度來分析一些潛在的問題。TheArtofSoftWareTesting?讀書筆記〔5〕_心理學(xué)視角解析〔上〕先談?wù)剰男睦韺W(xué)角度所需要分析的問題。在章節(jié)的開始，作者就明確的給予了一個認知：要成功地測試一個軟件應(yīng)用程序，測試人員也需要有正確的態(tài)度。在某些情況下，測試人員的態(tài)度可能比實際的測試過程本身還要重要。并且，分析了現(xiàn)在社會上普遍存在的兩種“本末倒置〞的錯誤認識。針對程序員：一開始就把“測試〞這個術(shù)語的定義搞錯了。所以可想而知，作者肯定要先破其錯誤的根源和弊端，然后再立其正確的認知，為了能更深入的理解和在實踐上的把握，作者又對正確的認知給予了進一步延伸的闡述；針對工程經(jīng)理：針對測試方面而言，對“成功的〞和“不成功的〞的理解認識上的錯誤。文尾，值得一提的是：作者在這引薦一個病人去醫(yī)生那里看病的例子，于是將一些繞人的關(guān)系和原理，剎那間弄的清晰易懂了?？磥砬‘?dāng)適宜的舉例還是比枯燥的講解概念間的區(qū)別與聯(lián)系要容易的多，也生動的多，并且使人也能理解的更加深刻。?TheArtofSoftWareTesting?讀書筆記〔6〕_心理學(xué)視角解析〔中〕上次談到了兩個錯誤認識，那就繼續(xù)這個話題吧。先分析與工程經(jīng)理有關(guān)的這個錯誤認識吧。因為這個因素可能會導(dǎo)致一些在測試問題上的根本性錯誤的認識。作者主要是從“成功的〞和“不成功的〞這兩個方面來剖析的：指明了錯誤認識的根源：“成功的測試〞是指沒有發(fā)現(xiàn)錯誤的測試用例；而“不成功的測試〞是指發(fā)現(xiàn)了某個新錯誤的測試。明確正確認識的本質(zhì)：如果在測試某段程序時發(fā)現(xiàn)了錯誤，而且這些錯誤是可以修復(fù)的，就將這次合理的設(shè)計和由此得到有效執(zhí)行的測試稱為是“成功的〞；并對如果在本次測試中可以最終確定再無其他可查出的錯誤，同樣也被稱作是“成功的〞；而對未能適當(dāng)?shù)貙Τ绦蜻M行檢查，且在大多數(shù)情況下，未能找出錯誤的測試被稱為是“不成功的〞。引薦病人去找醫(yī)生看病的這一生動的例子，加以引申理解并給予了結(jié)論：能發(fā)現(xiàn)新錯誤的測試用例不太可能被認為是“不成功的〞，相反，能發(fā)現(xiàn)錯誤就證明它是值得設(shè)計的。一個“不成功的〞測試用例，會使程序輸出正確的結(jié)果，但不能發(fā)現(xiàn)任何錯誤。細想：如果規(guī)劃的測試用例是能使程序輸出正確的結(jié)果，但不能發(fā)現(xiàn)任何錯誤的話，那是多么的可怕阿。那么測試就等于沒有測試，或者是在徒勞。而潛在的錯誤還依然潛在，這會開發(fā)人員跟用戶來說，都是有不小的隱患的。這才真正認識到：發(fā)現(xiàn)測試真的是一門需要去潛心研究的藝術(shù)。不僅僅是為了我們開發(fā)人員自己，也為了用戶，更為了將來軟件能夠更好的維護跟升級。?TheArtofSoftWareTesting?讀書筆記〔7〕_心理學(xué)視角解析〔下〕接著，來談?wù)劤绦騿T方面會產(chǎn)生的錯誤認識吧！這個方面可能在具體實踐中顯的更重要。由于作者在開篇就先把三個錯誤認識給擺到讀者的眼前；然后就立馬說明了其正確的定義，并給予了分析和對錯誤認識的駁斥。洋灑灑的寫了許多，條理上未免會有些混亂。因此，我就按照自己理解的來小結(jié)一下吧！首先，測試的正確定義是：測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。該定義暗示了兩層含義：軟件測試是一個破壞性的過程，甚至是一個“施虐〞的過程。〔就自己的親身經(jīng)歷而言，大局部的開發(fā)人員在測試期間，對測試人員或多或少都會暫時產(chǎn)生一點厭煩或恐懼的心態(tài)。主要是會讓開發(fā)人員的代碼改的面目全非的，且這個過程是反反復(fù)復(fù)的?！硨τ谝粋€特定的程序，應(yīng)該如何設(shè)計測試用例〔測試數(shù)據(jù)〕、哪些人應(yīng)該而哪些人又不應(yīng)該執(zhí)行測試?！策@是有關(guān)測試人員構(gòu)成的問題。就自己的親身經(jīng)歷而言，這一點很重要，因為測試人員的態(tài)度要比測試的過程更為重要?！橙缓螅鞔_測試的正確含義后，探究了一下現(xiàn)今面臨的三個錯誤認識并逐一給予了充分的駁斥?！败浖y試就是證明軟件不存在錯誤的過程〞。假設(shè)目的僅是為了證明程序中不存在錯誤，就會在潛意識中傾向于實現(xiàn)這個目標(biāo)；即，會傾向于選擇可能較少導(dǎo)致程序失效的測試數(shù)據(jù)；假設(shè)目標(biāo)在于證明程序中存在錯誤，設(shè)計的測試數(shù)據(jù)就有可能更多地發(fā)現(xiàn)問題。后者肯定比前者會更多地增加程序的價值。心理上，對于證明不存在是一個不可能完成的任務(wù)，無論該工程多么??；但假設(shè)是一個尋找錯誤的任務(wù)，是可以完成的。就心理承受而言，也是更容易接受的?！败浖y試的目的在于證明軟件能夠正確完成其預(yù)訂的功能。〞心態(tài)上，不要本著只是為了證明程序能夠正確運行而去測試程序，而應(yīng)該一開始就假設(shè)程序中隱藏著錯誤〔這種假設(shè)對于幾乎所有的程序都成立〕。這樣測試程序時，才能夠發(fā)現(xiàn)盡可能多的錯誤。要清楚這樣一個道理：每當(dāng)測試一個程序，實質(zhì)上是想為其增加一些價值。通過測試來增加程序的價值，及是指測試提高了程序的可靠性或質(zhì)量。而提高了程序的可靠性，就是指找出并最終修改了程序的錯誤?！败浖y試就是建立一個‘軟件做了其應(yīng)該做的’信心的過程。〞錯誤認識的關(guān)鍵在于：程序即使能夠完成預(yù)定的功能，也仍然可能隱藏錯誤。即，當(dāng)程序沒有實現(xiàn)預(yù)期功能時，錯誤是清晰地顯現(xiàn)出來的。但如果程序做了其不應(yīng)該做的，這同樣也是一個錯誤。而后一方面一般都會人為的想當(dāng)然，認為系統(tǒng)不會做那些事情的。但不通過實踐去證明，一切都是不可預(yù)計到的。總體而言，軟件測試更適宜用來作為一個試圖發(fā)現(xiàn)程序中錯誤〔假設(shè)其存在〕的破壞性的過程。一個成功的測試用例，通過誘發(fā)程序發(fā)生錯誤，可以在這個方向上促進軟件質(zhì)量的改良。當(dāng)然，最終還要通過軟件測試來建立某種程度的信心；軟件做了其應(yīng)該作的，未做其不應(yīng)該作的。通過對錯誤的不斷研究是實現(xiàn)這個目的的最正確途徑。需要明確的一點是，針對有人可能會聲稱“本人的程序完美無缺〔不存在錯誤〕〞的這種情況而言，建立起信心的最好方法就是盡量去反駁他，即努力發(fā)現(xiàn)不完美指出，而不只是確認程序在某些輸入情況下能夠正確地工作。文尾，我想到了高爾基先生在?海燕?里邊的一句話：讓暴風(fēng)雨來的更猛烈些吧！不妨，讓測試變的更加瘋狂一些吧！?TheArtofSoftWareTesting?讀書筆記〔8〕_經(jīng)濟學(xué)視角解析再從經(jīng)濟學(xué)視角來分析一下吧。需明確：對一個復(fù)雜的應(yīng)用程序進行完全的測試，將消耗大量的時間和人力資源，以致于在經(jīng)濟上是不可行的。即，從經(jīng)濟學(xué)的角度來說，軟件測試是不能夠發(fā)現(xiàn)“所有〞的錯誤。換言之，要發(fā)現(xiàn)程序中的所有錯誤是不切實際的，也常常是不可能的。這也表達了測試人員對被測試軟件的期望和對測試用例的設(shè)計方式。由此，有了兩種策略，即：黑盒測試和白盒測試〔均從三個方面進行闡述：原理、方法、利弊〕。黑盒測試〔又稱為數(shù)據(jù)驅(qū)動的測試或輸入/輸出驅(qū)動的測試〕原理：將程序視為一個黑盒子，測試目標(biāo)與程序的內(nèi)部機制和結(jié)構(gòu)完全無關(guān)，而是將重點集中放在發(fā)現(xiàn)程序不按其標(biāo)準(zhǔn)正確運行的環(huán)境條件。方法：測試數(shù)據(jù)完全來源于軟件標(biāo)準(zhǔn)〔不需要去了解程序的內(nèi)部結(jié)構(gòu)〕。如果想用這種方法來發(fā)現(xiàn)程序的所有錯誤，判定的標(biāo)準(zhǔn)就是“窮舉輸入測試〞，將所有可能的輸入條件都作為測試用例。利弊：窮舉輸入測試是無法實現(xiàn)的。原因有二：一是無法測試一個程序以確保它是無錯的；二是軟件測試中需要考慮的一個根本問題是軟件測試的經(jīng)濟學(xué)，即，測試投入的目標(biāo)在于通過有限的測試用例，最大限度地提高發(fā)現(xiàn)的問題的數(shù)量以取得最好的測試效果。白盒測試〔又稱為邏輯驅(qū)動的測試〕原理：允許我們檢查程序的內(nèi)部結(jié)構(gòu)的。這種測試策略對程序的邏輯結(jié)構(gòu)進行檢查，從中獲取測試數(shù)據(jù)〔但常忽略了程序的標(biāo)準(zhǔn)〕。方法：窮舉路徑測試。即，如果使用測試用例執(zhí)行了程序中所有可能的控制流路徑，那么程序有可能得到了完全的測試。利弊：程序中不同邏輯路徑的數(shù)量可能會到達天文數(shù)字，那么窮舉路徑測試就同窮舉輸入測試一樣，非但不可能也是不切合實際的。文尾，值得提一下一個錯誤認知：“窮舉路徑測試即完全的測試〞。因為，即使可以測試到程序中的所有路徑，但是程序可能仍然存在著錯誤。其原因有三：即使是窮舉路徑測試也決不能保證程序符合其設(shè)計標(biāo)準(zhǔn)；程序可能會因為缺少某些路徑而存在問題，可窮舉路徑測試不能發(fā)現(xiàn)到底是缺少了那些必需路徑；窮舉路徑測試可能不會暴露數(shù)據(jù)敏感錯誤。?TheArtofSoftWareTesting?讀書筆記〔9〕_原那么解析該章最后，作者給予了十大測試原那么：測試用例中一個必需局部是對預(yù)期輸出或結(jié)果的定義。一個測試用例必需包括兩個局部：對程序的輸入數(shù)據(jù)的描述和對程序在上述輸入數(shù)據(jù)下的正確輸出結(jié)果的精確描述。程序員應(yīng)當(dāng)防止測試自己編寫的程序。原因有三：當(dāng)程序員“建設(shè)性〞地設(shè)計和編寫完程序之后，很難讓他突然改變視角以一種“破壞性〞的眼光來審查程序，即，他們無法改變思維方式來盡力暴露自己程序中的錯誤；程序員可能會下意識地防止找出錯誤來，擔(dān)憂受到同事、上司、客戶或正在開發(fā)的程序或系統(tǒng)的主管的懲罰；由于程序員錯誤地理解了疑難定義或標(biāo)準(zhǔn)，導(dǎo)致程序中存在錯誤。如果是這種情況，程序員可能會帶著同樣的誤解來測試自己的程序。需要指出的是：“調(diào)試〞還是由程序的編寫人員來完成會更加有效的。

編寫軟件的組織不應(yīng)當(dāng)測試自己編寫的軟件。應(yīng)該是由客觀、獨立的第三方來進行測試。理由雷同于上條規(guī)那么中所涉及到的。

應(yīng)當(dāng)徹底檢查每個測試的執(zhí)行結(jié)果。在工程測試的時候，總是會發(fā)現(xiàn)在后續(xù)測試中發(fā)現(xiàn)的錯誤，往往是前面的測試遺漏掉的。測試用例的編寫不僅應(yīng)當(dāng)根據(jù)有效和預(yù)料到的輸入情況，而且也應(yīng)當(dāng)根據(jù)無效和未預(yù)料到的輸入情況。其實在軟件產(chǎn)品中暴露出來的許多問題是當(dāng)程序以某些新的或未預(yù)料到的方式運行時發(fā)現(xiàn)的。所以這條原那么的重要性可能在測試中的地位還應(yīng)該是更要值得引起注意的才是。檢查程序是否“未做其應(yīng)該做的〞僅是測試的一半，測試的另一半是檢查程序是否“做了其不應(yīng)該做的〞。應(yīng)防止測試用例用后放棄，除非軟件本身就是一個一次性的軟件。在交互式系統(tǒng)上來測試的話，這條原那么可能就會顯現(xiàn)的更加重要了。這條原那么表達的會更加省時省力。因為如果對程序的更改導(dǎo)致了程序某個先前可以執(zhí)行的局部發(fā)生了故障，這個故障往往是不會被發(fā)現(xiàn)的。保存測試用例，當(dāng)程序其他局部發(fā)生更動后重新執(zhí)行，這就是我們所謂的“回歸測試〞了。方案測試工作時不應(yīng)默認假定不會發(fā)現(xiàn)錯誤。程序某局部存在更多錯誤的可能性，與該局部已發(fā)現(xiàn)錯誤的數(shù)量成正比。作者所說的而言，錯誤總是傾向于聚集存在，而在一個具體的程序中，某些局部要比其他局部更容易存在錯誤。那么為了使測試獲得更大的成效，最好對這些容易存在錯誤的局部進行額外的測試。測試是一項極富創(chuàng)造性、極具智力挑戰(zhàn)性的工作?TheArtofSoftWareTesting?讀書筆記〔10〕_人工測試技術(shù)本書第三章作者著重講述了測試領(lǐng)域里的一個與機器測試相當(dāng)重要，且在機器測試之前進行，也與之相輔相成的技術(shù)，即：人工測試技術(shù)。該技術(shù)共涉及四種方法：代碼檢查、代碼走查、桌面檢查、同行評審；其更著重詳細講述的是第一個方法。同時，作者在開章也提到一種錯誤認識：人工測試技術(shù)由于包含了人為因素在內(nèi)，導(dǎo)致很多方法的正規(guī)性要差于由計算機執(zhí)行的數(shù)學(xué)證明，所以人們可能會疑心某些如此簡單和不正規(guī)的東西是否有用。反之亦然。就個人經(jīng)歷而言，確實這種認知普遍存在，并且對人工測試技術(shù)沒有給予足夠的重視。文尾，有必要記敘一下，人工測試技術(shù)的重要性。它會在兩個方面顯著地提高軟件測試的成效和可靠性。錯誤發(fā)現(xiàn)得越早，改正錯誤的本錢越低，正確改正錯誤的可能性也越大；程序員在開始基于計算機的測試時似乎要經(jīng)歷一個心理上的改變。壓力會急劇增長，且要“盡可能快地修正這個缺陷〞。由于這些，所以，程序員在改正某個基于計算機測試發(fā)現(xiàn)的錯誤時所犯的失誤，可能要比改正早期發(fā)現(xiàn)的問題時所犯的失誤會更多一些的。?TheArtofSoftWareTesting?讀書筆記〔11〕_優(yōu)之共通上篇，提到人工測試技術(shù)的四種方法。其中，代碼檢查和代碼走查稍略勝一籌。于是，作者在本章著重講了這兩個方法。其實，這兩種方法很類似，那就先看看這兩種方法的優(yōu)之共通點吧！具體可分為一下幾個點：方法：組成一個小組來閱讀或直觀檢查特定的程序；并在“頭腦風(fēng)暴會〞上要形成統(tǒng)一的目標(biāo)：找出錯誤，但不必找出改正錯誤的方法。換句話說，是測試，而不是調(diào)試。該組開發(fā)人員〔三至四人為最正確〕是對代碼進行審核，其中參加者當(dāng)中只有一人是程序編寫者；也可以說它是對過去桌面檢查過程的改良。優(yōu)點：一旦發(fā)現(xiàn)錯誤，就可以在代碼中對其進行精確定位，這就降低了調(diào)試的本錢；還通常可以發(fā)現(xiàn)成批的錯誤，這樣就可以一同得到修正，這也優(yōu)于機器測試，因為后者只能暴露出錯誤的某個表癥。效果：通常是能夠有效地查找出30%-70%的邏輯設(shè)計和編碼錯誤，但不能有效地查找出高層次的設(shè)計錯誤。地位：是與計算機的測試互補的，缺少其中任何一種錯誤檢查的效率都會降低。值得提出的是：該處的錯誤發(fā)現(xiàn)率，并不是說所有錯誤中多達70%可能會被找出來，而是講這些方法在測試過程結(jié)束時，可以有效地查找出多達70%的錯誤。應(yīng)始終記住的是：程序中的錯誤總數(shù)始終是未知的。否那么就會浪費大量的精力跟人力，也會在經(jīng)濟效益上或多或少有一些損失的。不過，就經(jīng)驗而言，修改一個現(xiàn)存的程序比編寫一個新程序更容易產(chǎn)生錯誤，這依據(jù)于以每寫一行代碼的錯誤數(shù)量來計的。?TheArtofSoftWareTesting?讀書筆記〔12〕_代碼檢查代碼檢查，怎么說呢？經(jīng)驗而言，我挺喜歡用的。因為，跟工程經(jīng)理〔或設(shè)計人員〕讀設(shè)計，能夠非常容易發(fā)現(xiàn)設(shè)計上的邏輯錯誤或遺漏的問題等等。因此，有必要好好表達下。定義上：所謂的代碼檢查，其實就是以組為單位閱讀代碼，是一系列規(guī)程和錯誤檢查技術(shù)的集合。該過程通常將注意力集中在發(fā)現(xiàn)錯誤上，而不是糾正錯誤。成員組成：一個代碼檢查小組通常是由四人組成，其中一人發(fā)揮著協(xié)調(diào)作用、一人是該程序的編碼人員、一人是其他成員通常是程序的設(shè)計人員、一人是測試專家。這里，值得一提的是：那個發(fā)揮著協(xié)調(diào)作用的成員。該協(xié)調(diào)人應(yīng)該是個稱職的程序員，但不是該程序的編碼人員，不需要對程序的細節(jié)了解得很清楚。協(xié)調(diào)人的職責(zé)包括幾點：為代碼檢查分發(fā)材料、安排進程；在代碼檢查中起主導(dǎo)作用；記錄發(fā)現(xiàn)的所有錯誤；確保所有錯誤隨后得到改正。有關(guān)代碼檢查的具體流程，個人歸納為一個流程表，就不在這里詳述了。不過，這里需要值得注意的是代碼檢查這個過程。在代碼檢查的時間和地點上的選擇上，應(yīng)防止所有的外部干擾；代碼檢查會議的理想時間應(yīng)在90-120分鐘之內(nèi)；大多數(shù)的代碼檢查都是按每小時大約閱讀150行代碼的速度進行；對大型軟件的檢查應(yīng)安排多個代碼檢查會議同時進行，每個代碼檢查會議處理一個或幾個模塊或子程序。除此之外，還需要從心理學(xué)角度給予提前的心理籌備。因為，要使檢查過程有成效，還必須樹立正確的態(tài)度。其心理因素必須要提前分析正確，否那么事倍功半。假設(shè)程序員將代碼檢查視為對其個人的攻擊、采取了防范的態(tài)度，那么檢查過程就不會有效果。而正確的做法應(yīng)該是：一方面：提出的建議應(yīng)針對程序本身，而不應(yīng)針對程序員，即：軟件中存在的錯誤不應(yīng)被視為編寫程序的人員本身的弱點，且這些錯誤應(yīng)被看做是伴隨著軟件開發(fā)的艱難性所固有的；另一方面：程序員必須懷著非自我本位的態(tài)度來對待錯誤檢查，對整個過程采取積極和建設(shè)性的態(tài)度：代碼檢查的目標(biāo)是發(fā)現(xiàn)程序中的錯誤，從而改良程序的質(zhì)量。正因為這個原因，大多數(shù)人建議應(yīng)對代碼檢查的結(jié)果進行保密，僅限于參與者范圍內(nèi)部。尤其是如果管理人員想利用代碼檢查的結(jié)果，那么就與檢查過程的目的背道而馳了。文尾，順便提一下代碼檢查附帶的幾個有益的作用吧。程序員通常會得到編程風(fēng)格、算法選擇及編譯技術(shù)等方面的反響信息；其他參與者也可以通過接觸其他程序員的錯誤和編程風(fēng)格而同樣受益匪淺；代碼檢查還是早期發(fā)現(xiàn)程序中最易出錯局部的方法之一，有助于在基于計算機的測試過程中將更多的注意力集中在這些地方。?TheArtofSoftWareTesting?讀書筆記〔13〕_錯誤列表在代碼檢查過程中，一個重要的局部是需要對照一份編程錯誤列表，來分析程序是否存在常見的錯誤。于是，作者接下來就給出了一份錯誤列表，該份錯誤列表在很大程度上是獨立于編程語言的，即：大多數(shù)的錯誤都可能出現(xiàn)在用任意語言編寫的程序中的。并建議讀者可以把自己使用的編程語言中特有的錯誤，以及代碼檢查發(fā)現(xiàn)的錯誤補充到這份錯誤列表中去。作者給出的該列表比擬詳細，因此，不在這里詳述，只是給出該錯誤列表的總的構(gòu)架。該列表共分為八個局部：數(shù)據(jù)引用錯誤、數(shù)據(jù)聲明錯誤、運算錯誤、比擬錯誤、控制流程錯誤、輸入/輸出錯誤、接口錯誤、其他檢查。?TheArtofSoftWareTesting?讀書筆記〔14〕_代碼走查說完代碼檢查，現(xiàn)在來談?wù)劥a走查。從定義上來講，代碼走查是以小組為單元進行代碼閱讀的，同樣也是一系列規(guī)程和錯誤檢查技術(shù)的集合。且代碼走查也采用了持續(xù)一至兩個小時的不間斷會議的形式。代碼走查的小組成員的構(gòu)成而言，一般是由三至五人組成，其中一人扮演“協(xié)調(diào)人〞；一人擔(dān)任秘書角色，負責(zé)記錄所有查處的錯誤；還有一人擔(dān)任測試人員。不過最正確的組合應(yīng)該是：一位極富經(jīng)驗的程序員；一位程序設(shè)計語言專家；一位程序員新手〔可以給出新穎、不帶偏見的觀點〕；最終將維護程序的人員；一位來自其他不同工程的人員；一位來自該軟件編程小組的程序員。至于測試的流程跟代碼檢查很類似，類似之處就不多談，只說一下不同之處吧。稍有不同的是代碼走查的任務(wù)：就是參與者“使用了計算機〞。被指定為測試人員的那個人會帶著一些書面的測試用例〔程序或模塊具有代表性的輸入集及預(yù)期的輸出集〕來參加會議。且在會議期間，每個測試用例都在人們頭腦中進行推演，即：把測試數(shù)據(jù)沿程序的邏輯結(jié)構(gòu)走一遍，并把程序的狀態(tài)〔如變量的值〕記錄在紙張或白板上以供監(jiān)視。這里，需指出：這些書面的測試用例必須結(jié)構(gòu)簡單、數(shù)量較少，因為人腦執(zhí)行程序的速度比計算機執(zhí)行程序的速度慢上假設(shè)干量級。之所以提供這些測試用例，目的不是在于其本身對測試了關(guān)鍵的作用，而是其提供了啟動代碼走查和質(zhì)疑程序員邏輯思路及其設(shè)想的手段。因為，在大多數(shù)的代碼走查中，很多問題是在向程序員提問的過程中發(fā)現(xiàn)的，而不是由測試用例本身直接發(fā)現(xiàn)的。文尾，至于代碼走查所需要從心理學(xué)角度給予提前的心理籌備、后續(xù)過程和附帶的幾個有益的作用，都與代碼檢查的類似，所以在這里就不提了。?TheArtofSoftWareTesting?讀書筆記〔15〕_桌面檢查與同行評分在本章的最后，作者附帶提了一下桌面檢查和同行評分這兩個方法。首先，來談下桌面檢查。桌面檢查可視為由單人進行的代碼檢查或代碼走查；并由一個人閱讀程序，對照錯誤列表檢查程序，對程序推演測試數(shù)據(jù)。由此，我覺得桌面檢查可以說是上述兩種方法的一個內(nèi)核或者說是雛形吧。所以也可知其效率是相當(dāng)?shù)偷?。然后，看一下同行評分。需指明：其該方法與測試并無關(guān)系，因為其目標(biāo)并不是為了發(fā)現(xiàn)錯誤的，只是它與代碼閱讀的思想有一定的關(guān)聯(lián)而已。定義上：同行評分是一種依據(jù)程序整體質(zhì)量、可維護性、可擴展性、易用性和清晰性對匿名程序進行評價的技術(shù)。不難看出，該技術(shù)的目的是為程序員提供自我評價的手段。其小組成員的構(gòu)成為：一位管理員，負責(zé)擔(dān)任該評分過程的管理工作；6-20名參與者，并要保持匿名性，且要具備相似的背景。評分的資料：由參與者自己挑出兩個由自己編寫的程序以供評審，其中一個應(yīng)是自認為能代表其自身能力的最好作品；另一個是自認為質(zhì)量較差的作品。文尾，至于具體流程，就不再詳敘了。?TheArtofSoftWareTesting?讀書筆記〔16〕_淺談測試用例本書第四章主要講述了白盒測試和黑盒測試的原理、具體方法，及一些測試策略的思考。就經(jīng)驗而言，個人覺得，測試軟件中最重要的因素還是要：設(shè)計和生成有效的測試用例。所以，作者在開章之處特別提及測試用例，我認為是很必要的。緣由：因為測試不可能是完全的，所以最顯然的測試策略就是努力使測試盡可能完全。那么，由于考慮到時間和本錢的約束，那么一個最關(guān)鍵的問題就是：在所有可能的測試用例中，哪個子集最有可能發(fā)現(xiàn)最多的錯誤。很顯然，在所有的方法中效率最低的就是隨機輸入的測試，那么就需要提出一套思考過程，讓其有助于更加睿智地選取測試數(shù)據(jù)。于是，便有了一種比擬合理的測試策略：先使用黑盒測試方法來設(shè)計測試用例，然后視情況需要使用白盒測試方法來設(shè)計補充測試用例。?TheArtofSoftWareTesting?讀書筆記〔17〕_白盒測試先談及、概括一下白盒測試。

白盒測試，所關(guān)注的是：測試用例執(zhí)行的程度或覆蓋程序邏輯結(jié)構(gòu)〔源代碼〕的程度。因此，也可以認為是邏輯覆蓋測試。具體方法有五個，按其邏輯覆蓋的從弱到強依次列出：語句覆蓋〔面〕：將程序中的每條語句至少執(zhí)行一次，但實現(xiàn)不太可能，該準(zhǔn)那么有很大的缺乏，以至于它通常沒有什么用處判定/分支覆蓋〔線〕：

必須編寫足夠的測試用例，使得每一個判斷都至少有一個為真和為假的輸出結(jié)果。即：每條分支路徑都必須至少遍歷一次。換句話說：所有判斷的每個可能結(jié)果都至少執(zhí)行一次，以及將程序或子程序的每個入口點都至少執(zhí)行一次。需要指出的是：該準(zhǔn)那么滿足語言覆蓋準(zhǔn)那么。條件覆蓋〔點〕：編寫足夠的測試用例以確保將一個判斷中的每個條件的所有可能的結(jié)果至少執(zhí)行一次。判定/條件覆蓋〔點線結(jié)合〕：設(shè)計出足夠的測試用例，將一個判斷中的每個條件的所有可能結(jié)果至少執(zhí)行一次，將每個判斷的所有可能結(jié)果至少執(zhí)行一次，將每個入口點都至少調(diào)用一次。需明確一點，該準(zhǔn)那么有一個極大的缺點：盡管看上去所有條件的所有結(jié)果似乎都執(zhí)行到了，但由于某些特定的條件會屏蔽掉其他的條件，通常并不能全部都執(zhí)行到。例如：該準(zhǔn)那么并不一定會發(fā)現(xiàn)邏輯表達式中的錯誤〔與、或〕。

多重條件覆蓋〔點線組合〕：編寫足夠多的測試用例，將每個判定中的所有可能的條件結(jié)果的組合，以及所有的入口點都至少執(zhí)行一次。需要說明的是，滿足多重條件覆蓋準(zhǔn)那么的測試用例集，同樣滿足判定覆蓋準(zhǔn)那么、條件覆蓋準(zhǔn)那么以及判定/條件覆蓋準(zhǔn)那么。需明確的是：在存在循環(huán)的情況下，多重條件覆蓋準(zhǔn)那么所需要的測試用例的數(shù)量通常會遠遠小于其路徑的數(shù)量。文尾，作者小結(jié)了一下。包含每個判斷只存在一種條件的程序，最簡單的測試準(zhǔn)那么就是：設(shè)計出足夠數(shù)量的測試用例，將每個判斷的所有結(jié)果都至少執(zhí)行一次；將所有的程序入口都至少調(diào)用一次，以確保全部的語句都至少執(zhí)行一次。包含多重條件判斷的程序，最簡單的測試準(zhǔn)那么是：設(shè)計出足夠數(shù)量的測試用例，將每個判斷的所有可能的條件結(jié)果的組合，以及所有的入口點都至少執(zhí)行一次。?TheArtofSoftWareTesting?讀書筆記〔18〕_黑盒測試之等價類劃分再概述一下黑盒測試。那么首先就是等價類劃分法。等價類劃分，是一個最優(yōu)子集的挑選過程。該子集必須具備兩個特性：嚴格控制測試用例的增加，減少為到達“合理測試〞的某些既定目標(biāo)而必須設(shè)計的其他測試用例的數(shù)量；即：每個測試用例都必須表達盡可能多的不同的輸入情況，以使最大限度地減少測試所需的全部用例的數(shù)量；〔經(jīng)驗而言，是用于生成有效測試用例的約束?！掣采w了大局部其他可能的測試用例：使用或不使用這個特定的輸入集合，哪些錯誤會被發(fā)現(xiàn)，哪些會被遺漏掉。即：應(yīng)該盡量將程序輸入范圍進行劃分，將其劃分為有限數(shù)量的等價類，這樣就可以合理地假設(shè)測試每個等價類的代表性數(shù)據(jù)等于測試該類的其他任何數(shù)據(jù)?！步?jīng)驗而言，是用于生成無效測試用例的約束的?！尘唧w步驟為：確定等價類：確定等價類是選取每一個輸入條件，將其劃分為兩個或更多的組。這里可以借助表格來進行劃分，并確定了兩類等價類：有效等價類、無效等價類。生成測試用例。〔具體三步就不再表達了〕文尾，順便提一點個人經(jīng)驗：依據(jù)規(guī)格說明確定輸入條件時，一定要思維緊密和周全，否那么會出現(xiàn)很大的遺漏性；且用單個測試用例覆蓋無效等價類，是因為某些特定的輸入錯誤可能會評比或取代其他輸入錯誤檢查。所以應(yīng)：少而全、多而專。?TheArtofSoftWareTesting?讀書筆記〔19〕_黑盒測試之邊界值分析、錯誤猜想邊界值分析法，有較好的測試回報率。該法較簡單，僅是用于考察正處于等價劃分邊界或在邊界附近的狀態(tài)。因此，只需明確邊界條件這一定義即可。邊界條件，是指輸入和輸出等價類中那些恰好處于邊界、或超過邊界、或在邊界以下的狀態(tài)。錯誤猜想法，沒有用到任何特殊的方法，只是利用直覺和經(jīng)驗猜想出錯的可能類型，然后編寫測試用例來暴露這些錯誤。根本思想是列舉出可能犯的錯誤或錯誤易發(fā)情況的清單，然后依據(jù)清單來編寫測試用例；并且在閱讀規(guī)格說明時聯(lián)系程序員可能做的假設(shè)來確定測試用例，也就是說規(guī)格說明中的一些內(nèi)容會被忽略，要么是由于偶然因素，要么是程序員認為其顯而易見。文尾，需提及注意的是：邊界值分析法，考慮到了結(jié)果空間的邊界〔因為輸入范圍的邊界并不總是能代表輸出范圍的邊界情況?！?TheArtofSoftWareTesting?讀書筆記〔20〕_黑盒測試之因果圖分析因果圖分析法，依作者而言，是為了解決邊界值分析和等價劃分的一個弱點：未對輸入條件的組合進行分析。而因果圖恰恰有助于用一個系統(tǒng)的方法選擇出此類高效的測試用例集，并且可以指出規(guī)格說明的不完整性和不明確之處。因果圖，是一種形式語言〔有嚴格語法限制的語言，計算機語言都是形式語言〕，是將自然語言描述的規(guī)格說明轉(zhuǎn)換為因果圖。實質(zhì)上，是一種數(shù)字邏輯電路〔一個組合的邏輯網(wǎng)絡(luò)〕，但沒有使用標(biāo)準(zhǔn)的電子學(xué)符號，而是使用了稍微簡單點的符號。具體有六步〔涉及到的每步具體過程及圖樣，由于篇幅，都在此略去〕：將規(guī)格說明分解為可執(zhí)行的片段；確定規(guī)格說明中的因果關(guān)系；分析規(guī)格說明的語義內(nèi)容，并將其轉(zhuǎn)換為連接因果關(guān)系的布爾圖，即：因果圖；給圖加上注解符號，說明由于語法或環(huán)境的限制而不能聯(lián)系起來的“因〞和“果〞；過仔細地跟蹤圖中的狀態(tài)變化情況，將因果圖轉(zhuǎn)換成一個有限項的判定表；將判定表中的列轉(zhuǎn)換成測試用例。?TheArtofSoftWareTesting?讀書筆記〔21〕_測試策略本章最后，作者給出了一個合理的測試策略：“測試用例涉及方法可以組合為一個整體的策略，即：每一種方法都可以提供一組具體的有用的測試用例，但是都不能單獨提供一個完整的測試用例集，所以一組合理的策略為：如果規(guī)格說明中包含輸入條件組合的情況，應(yīng)首先使用因果圖分析方法；在任何情況下都應(yīng)使用邊界值分析方法。應(yīng)注意，是對輸入和輸出邊界進行分析；為輸入和輸出確定有效和無效等價類，在必要情況下對確認的測試用例進行補充；使用錯誤猜想技術(shù)增加更多的測試用例；針對上述測試用例集檢查程序的邏輯結(jié)構(gòu)，即白盒測試的五種方法?？蛇m當(dāng)?shù)脑黾幼銐驍?shù)量的測試用例，以便覆蓋準(zhǔn)那么得到滿足。〞?TheArtofSoftWareTesting?讀書筆記〔22〕_模塊〔單元〕測試單元測試，是本書第五章講述的重點。它是構(gòu)建大型程序〔>500linescodes〕測試的第一個步驟?？蓮娜齻€方面給予了概括：定義上：單元測試是對程序中的單個子程序、子程序或過程進行測試的過程，即：一開始并不是對整個程序進行測試，而是首先將注意力集中在對構(gòu)成程序的較小模塊的測試上面；必要性上：它是一種管理組合的測試元素的方法手段；以減輕調(diào)試〔準(zhǔn)確定位并糾正某個錯誤的過程〕的難度；并提供同時測試多個模塊的可能，將并行工程引入軟件測試中。目的上：它是將模塊的功能與定義模塊的功能規(guī)格說明或接口規(guī)格說明進行比擬。文尾，需指明：單元測試的目標(biāo)不是為了說明模塊符合其規(guī)格說明，而是為了揭示模塊與其規(guī)格說明存在著的矛盾。?TheArtofSoftWareTesting?讀書筆記〔23〕_單元測試用例設(shè)計單元測試用例的設(shè)計，需先明確兩點：單元測試設(shè)計測試用例時，需兩種類型的信息，即：模塊的規(guī)格說明、模塊的源代碼。雖單元測試總體上是采用面向白盒測試的，但是其設(shè)計主導(dǎo)思想是：使用一種或多種白盒測試方法分析模塊的邏輯結(jié)構(gòu)，然后使用黑盒測試方法對照模塊的規(guī)格說明以補充測試用例。文中，作者給予了實例講解。從中可得悉：在使用白盒測試方法前，需要列舉出程序中所有的條件判斷；而在使用白盒測試方法時，應(yīng)在開始就使用多重條件覆蓋的方法；而在使用黑盒測試方法時，最好要使用邊界值分析的方法，且不要依據(jù)邊界值分析的結(jié)果來重寫白盒測試的測試用例，最好黑盒測試的用例再單獨寫出來進行補充，不改動前邊已經(jīng)確認過的白盒測試的測試用例。文尾，須明確兩個觀點：其一、多重條件覆蓋準(zhǔn)那么要優(yōu)于其他準(zhǔn)那么；其二、任何邏輯覆蓋準(zhǔn)那么尚缺乏以勝任作為生成模塊測試用例的惟一手段。同樣，無論在白盒測試中判定狀態(tài)或生成測試用例時都需要利用這樣一個輔助手段：列表；即，狀態(tài)判定表。?TheArtofSoftWareTesting?讀書筆記〔24〕_增量測試與非增量測試執(zhí)行單元測試過程中，有兩點需考慮：其一、如何設(shè)計一個有效的測試用例集；其二、將模塊組裝成工作程序的方式。前者涉及的內(nèi)容在上篇已表達過，而后者，涉及模塊測試用例編寫的形式、可能用到的測試工具類型、模塊編碼和測試的順序、生成測試用例的本錢以及調(diào)試的本錢等。它有兩種具體實現(xiàn)方法：增量測試〔自頂向下和自底向上的開發(fā)或測試過程〕、非增量測試。增量測試：將測試的模塊組裝到測試完成的模塊集合中，再進行測試。且必須要為每個模塊準(zhǔn)備一個驅(qū)動模塊，但不需要樁模塊。非增量測試：先要獨立地測試每個模塊，再將這些模塊組裝成完整的程序。且測試單獨的模塊時，需一個特殊的驅(qū)動模塊和一個或多個樁模塊。驅(qū)動模塊：人們編寫的一個小模塊，用來將測試用例驅(qū)動或傳輸?shù)奖粶y模塊中，也可以用測試工具替代；還必須向測試人員顯示該模塊的結(jié)果。樁模塊：被測模塊可能調(diào)用到了其他的模塊，所以還必須使用一個額外的組件，即：特殊模塊，用于模擬被調(diào)用模塊的功能。文尾，需提及一個結(jié)論：增量測試要更好一些。原因如下：非增量測試所需的工作量要多一些；〔樁模塊〕增量測試可以較早發(fā)現(xiàn)模塊中與之不匹配接口、不正確假設(shè)相關(guān)的編程錯誤；增量測試，調(diào)試會進行得比擬容易些；〔調(diào)試〕增量測試會將測試進行得更徹底；〔可能會誘發(fā)先前測試完的模塊出現(xiàn)新缺陷，且會經(jīng)受更多的檢驗〕非增量測試所占用的機器時間顯得少一些；模塊測試階段開始時，非增量測試，就會有更多的時機進行并行操作，即：所有的模塊可以同時測試。?TheArtofSoftWareTesting?讀書筆記〔25〕_幾個誤解在開始概述兩種增量測試方法之前，作者對幾個誤解給予了澄清：自頂向下的測試、自頂向下的開發(fā)、自頂向下的設(shè)計被常用作近義詞。自頂向下的測試和自頂向下的開發(fā)確實是近義詞，表示安排模塊的編碼和測試順序的策略；而自頂向下的設(shè)計那么完全不同并且是獨立的概念，即：按自頂向下模塊設(shè)計的程序既可使用自頂向下的方式，也可使用自底向上的方式進行增量測試。自底向上的測試〔或自底向上的開發(fā)〕常被錯誤得當(dāng)作非增量測試；原因在于自底向上的測試的開展方式與非增量測試是相同的，即：對底層或終端模塊進行測試。?TheArtofSoftWareTesting?讀書筆記〔26〕_自頂向下測試、自底向上測試自頂向下測試，是從程序的頂部或初始模塊開始。測試開始之后，挑選哪一個后續(xù)模塊進行增量測試沒有惟一正確的方法；惟一的原那么是：要成為符合條件的下一個模塊，至少一個該模塊的附屬模塊〔調(diào)用它的模塊〕事先經(jīng)過了測試。該測試策略里邊最關(guān)鍵的可能就是編寫樁模塊了。它涉及到的幾個關(guān)鍵點概括為：樁模塊的返回信息一定要給予此次調(diào)用所希望的返回值，否那么調(diào)用模塊將會發(fā)生失效或是產(chǎn)生一個混亂的結(jié)果；早期，測試數(shù)據(jù)要通過其一個或多個樁模塊提交給模塊的。需要指出一點，就是測試完一個模塊后，就用一個實際的模塊代替其中的一個樁模塊，而該模塊需要的樁模塊也被添加起來。需要注意的是：不存在最正確的模塊序列。但盡量讓包含I/O操作的樁模塊和重要的樁模塊添入。自底向上測試，是開始于程序的終端模塊，此類模塊不再調(diào)用其他任何模塊。測試完這些模塊之后，同樣沒有最正確的方法來挑選要進行增量測試的下一個模塊；惟一正確的原那么是：要成為符合條件的下一個模塊，該模塊所有的附屬模塊〔它調(diào)用的模塊〕都已經(jīng)事先經(jīng)過了測試。需要指出的是，如果終端模塊是多個的話，既可以進行串行測試，也可以進行并行測試。且每一個模塊都需要一個特殊的驅(qū)動模塊，即：包含著有效的測試輸入、調(diào)用被測模塊且將輸出顯示出來〔或?qū)嶋H輸出與預(yù)期輸出作比擬〕的模塊。對于測試序列也同自頂向下測試的一樣。?TheArtofSoftWareTesting?讀書筆記〔27〕_幾個注意點本章，最后作者給予了單元測試的其他局部的實際測試策略。應(yīng)對測試用例進行測試。當(dāng)測試用例造成模塊輸出的實際結(jié)果與預(yù)期結(jié)果不匹配的情況時，存在兩個可能的解釋：要么該模塊存在錯誤；要么預(yù)期的結(jié)果不正確〔測試用例不正確〕，所以為了將這種混亂降低到最低程度，應(yīng)在測試執(zhí)行之前對測試用例集進行審核或檢查。使用自動化測試工具可以使測試過程中的枯燥勞動減至最低；在準(zhǔn)備單元測試時，要重溫以下心理學(xué)和經(jīng)濟學(xué)原那么，會有所裨益的；因為個人試圖測試自己編寫的程序所帶來的心理學(xué)問題，也適用于模塊測試。?TheArtofSoftWareTesting?讀書筆記〔28〕_更高級別的測試本書第六章,主要講的是更高級別的測試，它最適合用于軟件產(chǎn)品?？蓮膬蓚€層面來概述。更高級別的測試當(dāng)程序無法實現(xiàn)其最終用戶要求的合理功能時，就發(fā)生了一個軟件錯誤。因而即使完成了一次非常完美的單元測試，仍然不能保證已經(jīng)找出了程序中的所有錯誤，所以必須有這一測試環(huán)節(jié)。軟件開發(fā)過程與測試過程的對應(yīng)軟件開發(fā)過程在很大程度上是溝通有關(guān)最終程序的信息、并將信息從一種形式轉(zhuǎn)換到另一種形式，因此，絕大局部軟件錯誤都可以歸因為信息溝通和轉(zhuǎn)換時發(fā)生的故障?，F(xiàn)有三個補充的方法來預(yù)防或識別這些錯誤，它們分別是：可以使軟件開發(fā)過程更加精密，以防其中出現(xiàn)很多錯誤；在每個階段結(jié)束時，可以引入一個獨立的驗證過程，在進入下一個階段之前盡可能多地發(fā)現(xiàn)問題；對不同的開發(fā)階段采用不同的測試方法。即：將每一個測試過程都重點針對一個特定的轉(zhuǎn)換步驟，從而也針對一類具體的錯誤?！材茉陂_發(fā)過程和測試過程之間建立起一對一的聯(lián)系，能防止沒有效果的多余測試，并使我們不會遺漏掉大量的錯誤類型。〕文尾，需注明的是：測試過程順序并不一定意味著嚴格的時間順序，多種測試在時間上是可以發(fā)生局部重疊測試的。但需要說明，集成測試往往并不作為一個獨立的測試步驟，而且在進行增量模塊測試時，它是模塊測試的隱含局部?！查_發(fā)過程與測試過程的對應(yīng)關(guān)系圖，由于篇幅的原因，在此就不再表達?！?TheArtofSoftWareTesting?讀書筆記〔29〕_功能測試功能測試，作者從三個方面來概述：定義上：是一個試圖發(fā)現(xiàn)程序與其外部規(guī)格說明之間存在不一致的過程。方法上：通常是一項黑盒測試，即：要依賴早期的單元測試的過程來實現(xiàn)理想的白盒邏輯覆蓋準(zhǔn)那么。過程上：需要對規(guī)格說明進行分析以獲取測試用例集。?TheArtofSoftWareTesting?讀書筆記〔30〕_系統(tǒng)測試、系統(tǒng)測試的執(zhí)行作者從兩個方面來概述一下系統(tǒng)測試，至于細節(jié)就不再詳細表達了。對錯誤理解方面而言，主要是容易跟功能測試混淆?！矐?yīng)重點注意那些在設(shè)計外部規(guī)格說明的過程中所犯的轉(zhuǎn)換錯誤?！硨щy性而言，是由于要將程序與其目標(biāo)進行比擬，是系統(tǒng)測試的核心目的，可是沒有說明使用什么樣的測試用例設(shè)計方法。因此，系統(tǒng)測試采取一種不同的測試用例設(shè)計法，共計15種的系統(tǒng)測試策略。〔具體每個測試策略所采用的步驟就不再表達了。〕它們分別是：能力測試、容量測試、強度測試、易用性測試、平安性測試、性能測試、存儲測試、配置測試、兼容性/配置/轉(zhuǎn)換測試、安裝測試、可靠性測試、可恢復(fù)性測試、適用性測試、文檔測試、過程測試。系統(tǒng)測試的執(zhí)行，所涉及的關(guān)鍵是：規(guī)定了不能進行系統(tǒng)測試的人員及機構(gòu)：一是程序員；一是負責(zé)該程序開發(fā)的機構(gòu)。原因如下：執(zhí)行系統(tǒng)測試的人思考問題的方式必須與最終用戶相同；系統(tǒng)測試是一項“隨心所欲，百無禁忌〞的活動，而軟件開發(fā)機構(gòu)會受到心理束縛，有悖于此項活動。大多數(shù)的開發(fā)機構(gòu)最為關(guān)心的是讓系統(tǒng)測試進行得盡可能順利并按時完成，而不會盡力證明程序不能滿足其目標(biāo)。系統(tǒng)測試至少應(yīng)由很少受開發(fā)機構(gòu)左右的獨立人群來執(zhí)行。也許最經(jīng)濟的執(zhí)行系統(tǒng)測試的方法，是將測試分包給一個獨立的公司來完成。?TheArtofSoftWareTesting?讀書筆記〔31〕_驗收測試與安裝測試、測試的方案與控制驗收測試，通常是由訂購方〔用戶〕來進行驗收測試，并將程序的實際操作與原始合同進行對照的，其測試用例是為了盡力證明程序沒有滿足合同要求。所以，明智的用戶首先會進行一次驗收測試以判斷產(chǎn)品是否滿足其要求的。安裝測試，不是為了發(fā)現(xiàn)軟件中的錯誤，而是為了發(fā)現(xiàn)在安裝過程中出現(xiàn)的錯誤。錯誤類型主要為：用戶必須選擇大量的選項；必須分配并加載文件和庫；必須進行有效的硬件配置；軟件可能要求網(wǎng)絡(luò)聯(lián)通，以便與其他軟件連接。并且，安裝測試應(yīng)由生產(chǎn)軟件系統(tǒng)的機構(gòu)來設(shè)計，作為軟件的一局部來發(fā)布，在系統(tǒng)安裝完成之后進行。此外，測試用例需要檢查以確認已選的選項集合互不沖突，系統(tǒng)的所有部件全部存在，所有的文件已經(jīng)創(chuàng)立并包含必須內(nèi)容，硬件配置妥當(dāng)?shù)取?/p>

文尾，提及一下作者所講述的測試的管理和方案。一個良好的測試方案應(yīng)該包括以下幾點：目標(biāo)、結(jié)束準(zhǔn)那么、進度、責(zé)任、測試用例庫及標(biāo)準(zhǔn)、工具、計算機時間、硬件配置、集成、跟蹤步驟、調(diào)試步驟、回歸測試。?TheArtofSoftWareTesting?讀書筆記〔32〕_測試結(jié)束準(zhǔn)那么、獨立的測試機構(gòu)測試結(jié)束準(zhǔn)那么，常常用到的且是沒有任何作用的兩個準(zhǔn)那么是：用完了安排的測試時間后，測試便結(jié)束；當(dāng)執(zhí)行完所有測試用例都未發(fā)現(xiàn)錯誤，測試便結(jié)束。即：當(dāng)所有的測試用例不成功時便結(jié)束。作者在這里給予了三類較為有用的結(jié)束準(zhǔn)那么，它們分別是：有用但不是最正確的準(zhǔn)那么，根據(jù)的是特定的測試用例技術(shù)；最有價值的準(zhǔn)那么，是以確切的數(shù)量來描述結(jié)束測試的條件；在測試過程中記錄每單位時間內(nèi)發(fā)現(xiàn)的錯誤數(shù)量；并通過檢查統(tǒng)計曲線的形狀，來確定是否繼續(xù)或終止該階段的測試。最正確結(jié)束準(zhǔn)那么可能還是對上述三種類型的組合使用。單元測試用第一類，而其他測試，用后兩類的組合使用。這種策略還是比擬佳的。文尾，作者談及公司的架構(gòu)中，認為測試部門應(yīng)盡可能遠離開發(fā)部門。事實上，最理想的是測試機構(gòu)不應(yīng)是同一個公司的一局部，因為如果不是這樣，測試機構(gòu)仍然會受到與開發(fā)部門同樣的管理壓力的影響。所以解決這個矛盾的一個方法就是雇傭獨立的公司進行軟件測試。這樣以來，就可以提升了測試過程中的積極性、建立了與開發(fā)機構(gòu)的良性競爭、防止了測試過程處于開發(fā)機構(gòu)的管理控制之下，以及獨立的測試機構(gòu)帶來的解決問題的專業(yè)知識。?TheArtofSoftWareTesting?讀書筆記〔33〕_調(diào)試、暴力法調(diào)試作者在該書第七章著重講述了調(diào)試的五種方法。不過有必要先明確一下調(diào)試的定義。調(diào)試，是執(zhí)行一次成功的測試之后所要進行的工作。它有兩個步驟：從錯誤定位〔可解決95%的問題〕；再錯誤修改。而對于各種方法的具體步驟及過程，都不再詳敘。暴力法調(diào)試，不需要過多的思考，但同時也是效率低下，即：不是很成功。它至少可被劃分為三種類型：用內(nèi)存信息輸出來調(diào)試；根據(jù)一般的“在程序中插入打印語句〞建議來調(diào)試；使用自動化的調(diào)試工具進行調(diào)試〔可設(shè)置斷點〕。不過，該方法的主要問題在于：它忽略了思考的過程。因此，該方法的使用情況為：其它的方法都失敗了；座位其它方法思考過程的補充，而不是替代方法。?TheArtofSoftWareTesting?讀書筆記〔34〕_歸納法、演繹法、回溯法、測試法調(diào)試及其原那么、錯誤分析歸納法調(diào)試，是一個需要思考的過程。歸納，是一種特殊的思考過程，可以從細節(jié)轉(zhuǎn)到全局，即：從線索除法，尋找線索之間的聯(lián)系。也就意味著：從特殊到一般。歸納調(diào)試的步驟可以概括為以下一個圖，在此就不再詳敘。演繹法調(diào)試，也是一個需要思考的過程。演繹，是從一些普遍的理論或前提除法，使用排除和精煉的過程，到達一個結(jié)論，即：錯誤的位置。其步驟也可以通過一個圖來概述，在此就不再詳敘。

回溯法調(diào)試，也是一個需要思考的過程。它常用于小型程序中來定位錯誤。它是沿著程序的邏輯結(jié)構(gòu)回溯不正確的結(jié)果，直到找出程序邏輯錯誤的位置，即：從程序產(chǎn)生不正確結(jié)果的地方開始，從該處觀察到的結(jié)果推斷出程序變量應(yīng)該是些什么值。所以使用這個過程，可以確定程序中從狀態(tài)符合預(yù)期的位置點，到第一個狀態(tài)不符合預(yù)期值的位置點之間的范圍。測試法調(diào)試，也是一個需要思考的過程。它是要使用測試用例來調(diào)試。而測試用例可分兩類：供測試的測試用例；供調(diào)試的測試用例?！沧⒁鈨烧叩牟煌?。〕不過，該方法不是一個完全獨立的方法。它常常與歸納法一起使用，以獲得進行假設(shè)和/或證明假設(shè)所需的信息；它也可以和演繹法一起使用，以排除有嫌疑的原因，提煉剩下的假設(shè)，并/或證明假設(shè)。文尾，作者給予了調(diào)試的一些原那么〔首先是定位錯誤的原那么；其次是修改錯誤的技術(shù)〕，及詳細的錯誤分析。?TheArtofSoftWareTesting?讀書筆記〔35〕_XP作者在第八章著重講述了XP與XT。它設(shè)計于20世紀(jì)90年代且于1996年進行了首次測試。目前，它依然是最流行的敏捷軟件開發(fā)過