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