| 該章最后，作者給予了十大測試原則：
測試用例中一個(gè)必需部分是對預期輸出或結果的定義。
一個(gè)測試用例必需包括兩個(gè)部分：對程序的輸入數據的描述和對程序在上述輸入數據下的正確輸出結果的精確描述。
程序員應當避免測試自己編寫(xiě)的程序。
原因有三：
當程序員“建設性”地設計和編寫(xiě)完程序之后，很難讓他突然改變視角以一種“破壞性”的眼光來(lái)審查程序，即，他們無(wú)法改變思維方式來(lái)盡力暴露自己程序中的錯誤；
程序員可能會(huì )下意識地避免找出錯誤來(lái)，擔心受到同事、上司、客戶(hù)或正在開(kāi)發(fā)的程序或系統的主管的懲罰；
由于程序員錯誤地理解了疑難定義或規范，導致程序中存在錯誤。如果是這種情況，程序員可能會(huì )帶著(zhù)同樣的誤解來(lái)測試自己的程序。需要指出的是：“調試”還是由程序的編寫(xiě)人員來(lái)完成會(huì )更加有效的。
編寫(xiě)軟件的組織不應當測試自己編寫(xiě)的軟件。
應該是由客觀(guān)、獨立的第三方來(lái)進(jìn)行測試。理由雷同于上條規則中所涉及到的。
應當徹底檢查每個(gè)測試的執行結果。
在項目測試的時(shí)候，總是會(huì )發(fā)現在后續測試中發(fā)現的錯誤，往往是前面的測試遺漏掉的。
測試用例的編寫(xiě)不僅應當根據有效和預料到的輸入情況，而且也應當根據無(wú)效和未預料到的輸入情況。
其實(shí)在軟件產(chǎn)品中暴露出來(lái)的許多問(wèn)題是當程序以某些新的或未預料到的方式運行時(shí)發(fā)現的。所以這條原則的重要性可能在測試中的地位還應該是更要值得引起注意的才是。
檢查程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應該做的”。
應避免測試用例用后放棄，除非軟件本身就是一個(gè)一次性的軟件。
在交互式系統上來(lái)測試的話(huà)，這條原則可能就會(huì )顯現的更加重要了。這條原則體現的會(huì )更加省時(shí)省力。因為如果對程序的更改導致了程序某個(gè)先前可以執行的部分發(fā)生了故障，這個(gè)故障往往是不會(huì )被發(fā)現的。保留測試用例，當程序其他部分發(fā)生更動(dòng)后重新執行，這就是我們所謂的“回歸測試”了。
計劃測試工作時(shí)不應默認假定不會(huì )發(fā)現錯誤。
程序某部分存在更多錯誤的可能性，與該部分已發(fā)現錯誤的數量成正比。
作者所說(shuō)的而言，錯誤總是傾向于聚集存在，而在一個(gè)具體的程序中，某些部分要比其他部分更容易存在錯誤。那么為了使測試獲得更大的成效，最好對這些容易存在錯誤的部分進(jìn)行額外的測試。
測試是一項極富創(chuàng )造性、極具智力挑戰性的工作 | 
