【正文】 實(shí)際運(yùn)行的程序視乎是 不太可能的。這個(gè)測(cè)驗(yàn)說明，即使測(cè)試這樣一個(gè)小的程序，也不是件容易的事。但是，由于問題1至問題13代表了該程序不同版本中已經(jīng)實(shí)際出現(xiàn)的錯(cuò)誤，對(duì)該程序的充分測(cè)試至少應(yīng)該能夠暴露這些錯(cuò)誤。對(duì)每個(gè)回答“是”的答案，可以得1分：1. 是否有這樣的測(cè)試用例，代表了一個(gè)有效的不規(guī)則三角形？（注意，如1，2，3，和2，5，10這樣的測(cè)試用例并不能確?！笆恰钡拇鸢?，因?yàn)榫邆溥@樣邊長(zhǎng)的三角形不存在。程序顯示提示信息，指出該三角形究竟是不規(guī)則三角形、等腰三角形還是等邊三角形。 我們要求設(shè)計(jì)一組測(cè)試用例（特定的數(shù)據(jù)集合），使當(dāng)?shù)販y(cè)試一個(gè)相當(dāng)簡(jiǎn)單的程序。 所謂軟件測(cè)試就是一個(gè)過程或一系列過程，用來確認(rèn)計(jì)算機(jī)代碼完成了其應(yīng)該完成的功能，不執(zhí)行其不該有的操作。 因此，我們現(xiàn)在編寫的軟件會(huì)潛在地影響到數(shù)以百萬計(jì)的人，使他們更高地完成工作，反之也會(huì)給他們帶來數(shù)不清的麻煩，導(dǎo)致工作或事業(yè)的損失。軟件測(cè)試的藝術(shù)第1章一次自評(píng)價(jià)測(cè)試 子本書25年前首次出版以來，軟件測(cè)試變得比以前容易得多，也困難德多。況且，計(jì)算機(jī)本身的功能也比以前增強(qiáng)了數(shù)百倍。例如，圖形用戶界面（GUI）可以從開發(fā)語言的類庫(kù)中建立起來，同時(shí)，由于它們是經(jīng)過充分調(diào)試和測(cè)試的可編程對(duì)象，將其作為用戶應(yīng)用程序測(cè)組成部分進(jìn)行測(cè)試 的要求就減少了許多。 好了，在開始閱讀本書之前，我們想讓讀者做一個(gè)小測(cè)驗(yàn)。這三個(gè)整數(shù)數(shù)值代表了三角形三邊的長(zhǎng)度。 用你的測(cè)試用例集回答下列問題，借以對(duì)其進(jìn)行評(píng)價(jià)。）8. 是否至少有三個(gè)地7類的測(cè)試用例，列舉了一邊等于另外兩邊之和的全部的可能情況（如1，2，3；1，3，2；3，1，2）？9. 是否有這樣的測(cè)試用例，三個(gè)整數(shù)皆大于0，其中兩個(gè)整數(shù)之和小于第三個(gè)整數(shù)（如1，2，4；12，15，30）？10. 是否至少有三個(gè)第9類的測(cè)試用例，列舉了一邊大于另外兩邊之和的全部可能情況（如1，2，4；1，4，2；4，1，2）？11. 是否有這樣的測(cè)試用例，三邊長(zhǎng)度皆為0（0，0，0）？12. 是否至少有一個(gè)這樣的測(cè)試用例，輸入的邊長(zhǎng)為非整數(shù)（，）？13. 是否至少有一個(gè)這樣的測(cè)試用例，輸入的邊長(zhǎng)個(gè)數(shù)不對(duì)（如僅輸入了兩個(gè)而不是三個(gè)整數(shù)）？14. 對(duì)于每一個(gè)測(cè)試用例，除了定義輸入值之外，是否定義了程序針對(duì)該輸入值的預(yù)期輸出值？當(dāng)然，測(cè)試用例即使?jié)M足了上述條件，也不能確保能查處所有可能的錯(cuò)誤。如果沒那么高，我們將盡力幫助你。舉例來說，為測(cè)試這些語言開發(fā)出來的應(yīng)用程序，測(cè)試用例必須要找出與對(duì)象實(shí)例或內(nèi)存管理有關(guān)的錯(cuò)誤。 在理想情況下，我們會(huì)測(cè)試程序的所有可能情況。 另外，要成功地測(cè)試一個(gè)軟件應(yīng)用程序，測(cè)試人員也需要有正確的態(tài)度（也許用“愿景（vision）”這個(gè)詞會(huì)更好一些）。他們可能會(huì)認(rèn)為： “軟件測(cè)試就是證明軟件不存在錯(cuò)誤的過程。 每當(dāng)測(cè)試一個(gè)程序時(shí)，總是想為程序增加一些價(jià)值。 那么，對(duì)于測(cè)試，更為適合的定義應(yīng)該是： “測(cè)試是為發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程”。如果我們的目的是證明程序中不存在錯(cuò)誤，那就會(huì)潛在意識(shí)中傾向于實(shí)現(xiàn)這個(gè)目標(biāo)； 也就是說，我們會(huì)傾向于選擇可能較少導(dǎo)致程序失效的測(cè)試數(shù)據(jù)。舉例來說，它暗示了軟件測(cè)試是一個(gè)破壞性的過程，甚至是一個(gè)“施虐”的過程，這就是說明為什么大多數(shù)人都覺得它困難，這種定義可能是違反我們?cè)竿模凰业氖?，我們大多?shù)人總是對(duì)生活充滿建設(shè)性而不是破壞性的愿景。當(dāng)項(xiàng)目經(jīng)理歸納測(cè)試用例的結(jié)果時(shí)，尤其會(huì)用到這兩個(gè)詞。我們認(rèn)為，如果測(cè)試某段程序時(shí)發(fā)現(xiàn)了錯(cuò)誤，而且這些錯(cuò)誤是可以修復(fù)的，就將這次合理設(shè)計(jì)并得到有效的測(cè)試稱作是“成功的”。 能發(fā)現(xiàn)新錯(cuò)誤的測(cè)試用例不太可能被認(rèn)為是“不成功的”；相反能發(fā)現(xiàn)錯(cuò)誤就證明它是值得設(shè)計(jì)的。之所以是“不成功的”檢測(cè)，是因?yàn)椴∪酥Ц读税嘿F的實(shí)驗(yàn)檢測(cè)費(fèi)用，而病狀卻依然如故。我們當(dāng)然可以類推到軟件測(cè)試中來，當(dāng)我們開始測(cè)試某個(gè)程序是，它就是好似我們的病人。舉例來說，如果要求人們?cè)?5分鐘之內(nèi)完成星期日《紐約時(shí)報(bào)》里的縱橫填字游戲，那么我們會(huì)觀察到10分鐘之后的進(jìn)展非常小，因?yàn)榇蠖鄶?shù)人都會(huì)卻步于這個(gè)現(xiàn)實(shí)，即這個(gè)任務(wù)似乎是不可能完成的。也也就是說，當(dāng)程序沒有實(shí)現(xiàn)預(yù)期功能是，錯(cuò)誤是清晰地顯示出來的；如果做了其不該做的，這同樣是一個(gè)錯(cuò)誤。 總結(jié)一下，軟件測(cè)試更適合被視為試圖發(fā)現(xiàn)程序中錯(cuò)誤（假設(shè)其存在）的破壞性東東過程。 有人可能會(huì)聲稱“本人的程序完美無缺”（不存在錯(cuò)誤），針對(duì)這種的情況建立起信心的最好辦法就是盡量反駁他，即努力發(fā)現(xiàn)不完美之處，而不是確認(rèn)程序在某些輸入情況下能夠正確地工作。這個(gè)基本的問題反過來暗示出軟件的經(jīng)濟(jì)學(xué)問題，測(cè)試人員對(duì)被測(cè)試的期望，以及測(cè)試用例的設(shè)計(jì)方式。使用這種測(cè)試方法時(shí)，將程序視為一個(gè)黑盒子。為什么這樣做？比如說在三角形測(cè)試的程序中，試過了三個(gè)等邊三角形的測(cè)試用例，這不能確保正確地判斷出所有的等邊三角形。這些測(cè)試用例本是就是個(gè)天文數(shù)字，但這還不是所謂的窮舉的；當(dāng)程序指出一3，4，5是一個(gè)不規(guī)則三角形或2，A，2是一個(gè)等腰三角形時(shí)，問題就暴露出來了。設(shè)想下，如果要對(duì)一個(gè)C++編譯器進(jìn)行黑盒窮舉測(cè)試，不進(jìn)要?jiǎng)?chuàng)建代表所有有效C++程序的測(cè)試用例（實(shí)際上，這又是一個(gè)無窮數(shù)），還需要?jiǎng)?chuàng)建代表所有無效C++程序的測(cè)試用例（無窮數(shù)），以確定編譯器能夠檢測(cè)出他們是無效的。因此，不僅要測(cè)試所有有效的和無效的事務(wù)處理，還要測(cè)試所有可能的事物處理順序。除了其他因數(shù)以外，要實(shí)現(xiàn)這個(gè)目標(biāo)，還需要能夠窺見軟件的內(nèi)部，對(duì)測(cè)試做些合理但非無懈可擊的假設(shè)（例如，如果三角形程序?qū)?，2，2視為等邊三角形，那就有理由認(rèn)為程序?qū)?，3，3，也做同樣的判斷）。 這這里我們的目標(biāo)是針對(duì)這種測(cè)試策略，建立起與黑盒測(cè)試中窮舉輸入測(cè)試相似的方法。所謂窮舉路徑測(cè)試，即如果使用測(cè)試用例執(zhí)行了程序中所有可能的控制流路徑，那么程序有可能得到完全測(cè)試。該圖是一個(gè)控制流圖，每一個(gè)結(jié)點(diǎn)或圓圈都代表一個(gè)按順序執(zhí)行的語句段，通常以一個(gè)分支語句結(jié)束。要確定不同的邏輯路徑的數(shù)量，也相當(dāng)于要確定從點(diǎn)a~點(diǎn)b之間所有不同路徑的數(shù)量（假設(shè)程序中所有的判斷語句都是相互獨(dú)立的）。 當(dāng)然，在實(shí)際程序中，判斷并非都是彼此獨(dú)立的，這意味著可能實(shí)際執(zhí)行的路徑數(shù)量要稍微少一些。這有三個(gè)原因。窮舉路徑測(cè)試當(dāng)然不能發(fā)現(xiàn)缺少了哪呢必須路徑。比如，我們可能會(huì)這樣編一條JAVA語言的IF語句：if （ab c）( “ab c”)。那么，也許存在別的方法，將黑盒測(cè)試和白盒測(cè)試的要素結(jié)合起來，形成一個(gè)合理并不十分完美的測(cè)試策略。這些原則看上去大多數(shù)都是顯而易見，但常?？偸潜晃覀兒鲆暤簟Ｍ瑯?，這個(gè)問題也是基于人們的心理的。因此，一個(gè)測(cè)試用例必須包括兩個(gè)部分：1. 對(duì)程序的輸入數(shù)據(jù)的描述。沒有期望，也沒有所謂的意外。對(duì)程序員而言，也錯(cuò)在同樣的問題。同樣，大多數(shù)程序員都不能有效地測(cè)試自己編寫的程序，因?yàn)樗麄儫o法改變思維方式來盡力暴露自己程序的錯(cuò)誤。這并不意味著程序員測(cè)試自己的程序員是不可能的。原則3：編寫軟件的組織不應(yīng)當(dāng)測(cè)試自己編寫的軟件。其中的一個(gè)原因是，度量時(shí)間和成本目標(biāo) 比較容易，而定量地衡量軟件的可靠性則極其困難。原則4：應(yīng)當(dāng)徹底檢查每個(gè)測(cè)試的執(zhí)行結(jié)果。原則 5：測(cè)試用例的編寫不僅應(yīng)當(dāng)根據(jù)有效和預(yù)期的輸入情況，而且也應(yīng)當(dāng)根據(jù)無效和未預(yù)料到的輸入情況。此外，在軟件產(chǎn)品中突然暴露出來的許多問題是當(dāng)程序以某些新的或未預(yù)料到的方式運(yùn)行是發(fā)現(xiàn)的。必須檢查程序是否有我們不希望的負(fù)作用。人們通常會(huì)坐在終端前，匆忙地編寫測(cè)試用例，然后將這些用例交由程序執(zhí)行。因此，對(duì)程序的重新測(cè)試極少會(huì)同上次一樣嚴(yán)格。項(xiàng)目經(jīng)理經(jīng)常容易犯這個(gè)錯(cuò)誤，這也是使用了不正確的測(cè)試定義的一個(gè)跡象—也就是說，假定“測(cè)試是一個(gè)證明程序正確運(yùn)行的過程”。例如，假如某個(gè)程序由兩個(gè)模塊、類或子程序A和B組成，模塊A中已經(jīng)發(fā)現(xiàn)了五個(gè)錯(cuò)誤，而模塊B中近近找到了一處錯(cuò)誤。殘存錯(cuò)誤的可能性已知錯(cuò)誤的數(shù)量圖2—2殘存錯(cuò)誤與已知錯(cuò)誤間令人驚奇的聯(lián)系原則10：軟件測(cè)試是一項(xiàng)極富創(chuàng)造性、極具挑戰(zhàn)性的工作。在閱讀本書接下來的內(nèi)容時(shí)，請(qǐng)牢記一下三個(gè)重要的一測(cè)試原則：u 軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。20世紀(jì)70年代早期，一些程序員最先意思到閱讀代碼對(duì)于構(gòu)成完善的軟件測(cè)試和調(diào)試手段的價(jià)值，通過他們的努力，原有的觀念開始發(fā)生變化。人工測(cè)試技術(shù)在查找錯(cuò)誤方面非常有效，以至于任何編程項(xiàng)目都應(yīng)該使用其中的一種或多種技術(shù)。反之亦然，這些不正規(guī)的方法并沒有妨礙測(cè)試取得成功；相反它們從一嚇兩個(gè)方面顯著地提高了測(cè)試的功效和可靠性。由于這些壓力的存在，程序員在改正某個(gè)由基于計(jì)算機(jī)測(cè)試發(fā)現(xiàn)的錯(cuò)誤時(shí)所犯的失誤，要比改正早期發(fā)現(xiàn)的問題時(shí)所犯的失誤更多一些。無論采用那種方法，參加者都要完成一些準(zhǔn)備工作。 代碼檢查與走查已經(jīng)廣泛運(yùn)用了很長(zhǎng)時(shí)間。因此，軟件測(cè)試的主要工作是有其他人，而不是軟件編寫者本人來完成，這符合“軟件編寫者往往不能有效地測(cè)試自己編寫的軟件”的測(cè)試原則。另外，這個(gè)過程通常發(fā)現(xiàn)成批的錯(cuò)誤，這樣錯(cuò)誤就可以一同得到修改。請(qǐng)注意，所謂30%~70%的錯(cuò)誤發(fā)現(xiàn)率，并不是說所有錯(cuò)誤中多達(dá)70%可能會(huì)被找出來，而是講這些方法在測(cè)試過程結(jié)束時(shí)可以有效地查找出多大70%的已知錯(cuò)誤。這就意味著，代碼檢查/走查與基于計(jì)算機(jī)的測(cè)試是互補(bǔ)的。因此，出來回歸測(cè)試方法之外，更改后的程序還要進(jìn)行這些人工方法的測(cè)試。一個(gè)代碼檢查小組通常由四人組成，其中一個(gè)人發(fā)揮著協(xié)調(diào)作用。u 確保所有錯(cuò)誤隨后得到改正。 在代碼檢查之前的幾天，協(xié)調(diào)人將程序清單和設(shè)計(jì)規(guī)范分發(fā)給其他成員。在講述中、很可能是程序編碼人員本人而不是其他小組成員發(fā)現(xiàn)了大部分錯(cuò)誤。如果發(fā)現(xiàn)的錯(cuò)誤太多，或者某個(gè)錯(cuò)誤涉及對(duì)程序做根本的改動(dòng)，協(xié)調(diào)人可能會(huì)在錯(cuò)誤修改后安排對(duì)程序進(jìn)行再次檢查。那么，對(duì)這個(gè)小問題的討論，反過來會(huì)將整個(gè)小組的注意力集中在設(shè)計(jì)的某個(gè)部分。 在代碼檢查的時(shí)間及地點(diǎn)的選擇上，應(yīng)避免所有的外部干擾。因此，對(duì)大型軟件的檢查應(yīng)安排多個(gè)代碼檢查會(huì)議同時(shí)進(jìn)行，每個(gè)代碼檢查會(huì)議處理一個(gè)或幾個(gè)模塊或子程序。正是因?yàn)檫@個(gè)原因，大多數(shù)人建議應(yīng)對(duì)代碼檢查的結(jié)果進(jìn)行保密，僅限于參與者范圍內(nèi)部。其他參與者也可以通過接觸其他程序員的錯(cuò)誤和編程風(fēng)格而同樣受益匪淺。本節(jié)鎮(zhèn)南關(guān)討論的錯(cuò)誤列表是經(jīng)多年對(duì)軟件錯(cuò)誤的研究編輯而成的。在引用每個(gè)數(shù)據(jù)項(xiàng)（如變量、數(shù)據(jù)元素、結(jié)構(gòu)中的域）時(shí)，應(yīng)試圖非正式地“證明”該數(shù)據(jù)項(xiàng)在當(dāng)前位置具有確定的值。當(dāng)指針引用了過程中的一個(gè)局部變量，而指針的值有被賦給一個(gè)輸出參數(shù)或一個(gè)全局變量，過程返回（釋放了引用的內(nèi)存單元）結(jié)束，爾后程序試圖使用指針的值時(shí)，這種錯(cuò)誤就會(huì)發(fā)生。？當(dāng)C、C++或COBOL程序?qū)⒛硞€(gè)記錄讀到內(nèi)存中，并使用一個(gè)結(jié)構(gòu)來引用它時(shí)，由于記錄的物理表示與結(jié)構(gòu)定義在差異，這種情況下錯(cuò)誤就可能發(fā)生。，被引用的內(nèi)存的屬性是否編譯所預(yù)期的一致？這種錯(cuò)誤的一個(gè)例子是，當(dāng)一個(gè)指向某個(gè)數(shù)據(jù)結(jié)構(gòu)的C++指針，被賦值為另為的數(shù)據(jù)結(jié)構(gòu)的地址。3. 如果變量在聲明語句中被初始化，那么它的初始化是否正確？在很多語言中，數(shù)組和字符串的初始化比較復(fù)雜，因此也成為容易錯(cuò)誤的地方。這種情況并不一定是錯(cuò)誤，但應(yīng)該謹(jǐn)慎使用，確保程序語言的轉(zhuǎn)換規(guī)則能夠被正確理解。z = x/y。3. 是否有相同數(shù)據(jù)類型、不同字長(zhǎng)變量間的運(yùn)算？4．賦值語句的目標(biāo)變量的數(shù)據(jù)類型是否小于右邊表達(dá)的數(shù)據(jù)類型或結(jié)果？5. 在表達(dá)式的運(yùn)算中是否存在表達(dá)向上或向下溢出的情況？也就是說，最終的結(jié)果看以來是個(gè)有效的值、但中間結(jié)果對(duì)于編程 語言的數(shù)據(jù)類型可能過大或過小。，例如，將字符串與地址、日期或數(shù)字相比較？，或不同長(zhǎng)度的變量間的比較運(yùn)算？如果有，應(yīng)確保程序能正確理解轉(zhuǎn)換規(guī)則。如果想判斷i是否在2~10之間，表達(dá)式2i 10是不正確的；相反，正確的應(yīng)該是（2 i）amp。如果要比較三個(gè)數(shù)字是否相等，表達(dá)式if（a= =b = = c）的實(shí)際意思卻大相徑庭。，是否有二進(jìn)制表示的小數(shù)或浮點(diǎn)數(shù)的比較運(yùn)算？由于四舍五入，以及用二進(jìn)制表示十進(jìn)制數(shù)的近似度，這往往是錯(cuò)誤的根源。amp。 i=z。i=10。 i++){ ( i)。 REJURNB: ENTRY ( Y,Z)。 輸入/輸出錯(cuò)誤，其屬性是否正確？？（就各項(xiàng)的數(shù)量和屬性而言）？，來保留程序?qū)⒆x取額文件?？？，并正確處理？？？ 其他檢查，那么對(duì)該列表進(jìn)行檢查，查看是否有變量從未引用過，或僅被引用過一次?！疤崾尽毙畔⒖赡軙?huì)羅列出沒有聲明的變量，或者是不利于代碼優(yōu)化的用法。 就像代碼檢查一樣，代碼走查也是采用持續(xù)以至兩個(gè)小時(shí)的不間斷會(huì)議的形式。我們建議另外的參與者應(yīng)該包括：（1）一位極富經(jīng)驗(yàn)的測(cè)試員；（2）一位程序設(shè)計(jì)語言專家；（3）一位程序員新手（可以給出新穎、不帶偏見的觀點(diǎn)）；（4）最終將維護(hù)程序的人員；（5）一位來自其他不同醒目的人員；（6）一位來自該軟件編程小組的程序員。被指定為測(cè)試人員的那個(gè)熱鬧會(huì)帶著一些書面的測(cè)試用例（程序或模塊具有代表的輸入集及預(yù)期的輸出集）來參加會(huì)議。 當(dāng)然，這些測(cè)試用例必須結(jié)構(gòu)簡(jiǎn)單、數(shù)量較少，因?yàn)槿四X執(zhí)行程序的數(shù)度比計(jì)算機(jī)執(zhí)行程序的數(shù)度慢上若干量級(jí)。提出的建議應(yīng)針對(duì)程序本身，而不應(yīng)對(duì)程序員。同樣，代碼檢查所帶來的附帶作用（如可以發(fā)現(xiàn)易出錯(cuò)的程序區(qū)域，通過接觸軟件錯(cuò)誤、編程風(fēng)格和方法來獲得教育等）同樣也會(huì)發(fā)生在代碼走查過程中。其中的一個(gè)原因是，它是一個(gè)完全沒有約束的過程。原因在于代碼檢查和代碼走查小組中存在著互相促進(jìn)的效應(yīng)。 同行評(píng)分 最后一種人工評(píng)審方法與程序并無關(guān)系（其目的不是未來發(fā)現(xiàn)錯(cuò)誤），卻仍在這里談到，這是因?yàn)樗c代碼閱讀的思想有關(guān)。這些參與者都應(yīng)具備相似的背景（例如，不能把JAVA應(yīng)用程序員與匯編語言系統(tǒng)程序員編為一組）。每個(gè)參與者拿到4個(gè)程序進(jìn)行評(píng)審，其中兩耳是“最好”的程序，另外兩個(gè)是相對(duì)“較差”的程序，但評(píng)審人自己并不知道。評(píng)審結(jié)束之后，參與者會(huì)收到自己的那兩個(gè)程序的匿名評(píng)價(jià)表，此外還會(huì)收到一個(gè)帶統(tǒng)計(jì)的總結(jié)，說明所有的程序中其程序的整體和具體得分，以及他對(duì)其他程序的評(píng)價(jià)與其他評(píng)審人對(duì)同一程序打分的比較分析情況。大多數(shù)人都認(rèn)為，因?yàn)槌绦蚴菫榱颂峁C(jī)器執(zhí)行而編寫的，那么也應(yīng)該由機(jī)器來對(duì)程序進(jìn)行測(cè)試。u 小組代碼走查。 3,4,3。 1,