軟件測試法則
繼續本章開頭所闡述的問題“在軟件測試中心理因素佔有重要的位置”，通過對心理學的瞭解，我們能夠找出軟件測試中重要的原則或者稱爲重要的指導方針。這些原則大部分都是淺顯易懂，但在實際工作當中卻很容易被忽視。表2.1概括了這些重要的原則，在下面的章節中將詳細闡述。
表2.1 軟件測試指南
| 原則ID | 原則描述 |
| 1 | |
| 2 | |
| 3 | 一個開發團隊應該儘量避免測試自己編寫的程序 |
| 4 | 徹底檢查每個測試結果 |
| 5 | 測試用例中不但要寫明有效的和預期規定的輸入條件，也要包括無效的及預期規定之外的輸入條件 |
| 6 | 檢查程序應該完成哪些功能，這只是測試工作的一半，測試工作的另一半是，檢查程序完成了哪些不應該完成的功能 |
| 7 | 避免一次性的測試用例，除非該程序是一個真正的一次性項目 |
| 8 | 如果沒有很好的對測試工作進行計劃，只憑主觀臆斷來測試，將很難發現程序中存在的錯誤 |
| 9 | 如果某段程序出現了錯誤，那麼該段程序出錯的概率與代碼數量成正比 |
| 10 | 測試是一項具有創造性和挑戰性的任務 |
法則1：定義預期輸出或結果，是測試用例的重要組成部分
這個顯而易面的原則是軟件測試中最容易忽略的問題之一，當然，這個它也涉及了心理學的一些基礎知識。如果一個運行結果在測試用例沒有明確定義，它看起來很合理，實際上卻是錯誤的，結果測試員將它當作了程序的正確運行結果，這個現象叫“希望即所見”。換句話說，就是儘管這個結果是不正確的，但測試員的潛意識裏希望它是正確的，那麼就將主觀的肯定了它的正確性。避免這個現象產生的方法就是在測試用例中列出所有的預期結果，、因此，測試用例必須由以下兩個部分組成：
1. 描述程序的輸入數據
2. 精確的描述出每個輸入數據所對應的正確輸出結果
如果問題的定性沒有明確的解釋，這看起來似乎很不尋常，或者不符合我們預期的目標，這將很難做出正確的判斷。所以我們要事先確定程序的正確運行結果，來明確測試目標。如果沒有期望，就沒有驚喜。
法則2：軟件工程師應該儘量避免測試自己編寫的程序
任何作家都知道或應該知道，校對自己的作品是個壞主意。儘管作者很瞭解文章中哪個部分是應該加入的，哪個部分是多餘的，但是在潛意識裏卻希望自己的作品找不出任何破綻。這個道理同樣適用於軟件開發人員。
軟件工程師測試自己所編寫的代碼的第一個難點在於，在項目中所負擔的工作職責突然發生轉變，完成由編碼到測試的角色轉變將很困難，軟件工程師如果去承擔測試員這一角色，那麼就必須打破在編碼時所肩負的職責，背棄原有的工作思路，這將會需要相當長的時間或者這種轉變根本不可能成功。
正如多數的房屋所有者都知道重新粘貼牆紙（一個破壞的過程）不是件容易的事情，最困難的環節就是動手去貼第一張牆紙並且貼正它。同樣的道理，多數軟件工程師不能對自己編寫的代碼進行有效的測試，因爲從創造者的角度來看，每個人都不希望自己的作品中存在瑕疵。另外，軟件工程師有可能會出於害怕上司的批評影響經後的工作而下意識的逃避錯誤，但是客戶、軟件購買者卻不存在這樣的擔心，所以他們發現的問題要比軟件工程師自己測試後發現的問題更多。
如果再增加一些心理因素，就會引出第二個難點：如果軟件工程師在編寫代碼的聲明的部分時犯了錯誤，或是錯誤的理解了軟件的需求，那麼在測試自己編寫的代碼的過程中，這些錯誤的觀念可能仍會存在，那麼這種測試將會毫無意義，因爲軟件工程師找不出自己究竟犯了哪些錯誤。
這並不意味着軟件工程師一定不能勝任測試自己編寫的代碼，只是說如果讓另一個人來完成測試的工作，軟件測試的有效性和成功性將會大大提高。
對已知問題的爭論遠不如調試一次更爲有效，調試代碼是軟件工程師測試代碼質量的最有效也是有原始的一個步驟。
法則3：軟件開發小組不應該測試自己編寫的程序
本法則與上述的論點有相似之處。一個工程或項目組的成員，在許多問題會有相同的認知，而各個獨立的團隊間對相同事物的認知會有所不同。此外，在軟件行業中，普遍以代碼提交日期及節約項目成本爲評價項目經理能力的標準。如果將上述問題說成節約時間及成本是項目的最終目標，這樣更易於理解，但事實上這個目標卻很難保證代碼的質量。因此一個以時間和成本爲開發目標的團隊不應該去測試自己的產品，因爲看起來增加測試的環節會拖延項目的工期，增加項目成本。
再次強調一下，軟件開發小組不應該測試自己編寫的程序，這與開發團隊制定的工作目標是息息相關的。因此，選擇另一個獨立的團隊來測試自己的程序是個明智的選擇。
法則4：徹底檢查每個測試結果
這是一條最顯而易見，也是最容易被忽視的法則。我們做過很多實驗來證明看似很被人發現的錯誤卻常常被忽視掉，儘管這樣的錯誤已經在輸出結果的清單裏面一一列出了。以另一種方式來解釋這種現像，就是早期測試比晚期測試發現更多的問題。
法則5：測試用例中不但要寫明有效的和預期規定的輸入條件，也要包括無效的及預期規定之外的輸入條件
在測試的過程中，將大部分精力放在檢驗程序在輸入有效數據和預期輸入條件的運行結果上，而忽視了在無效輸入數據和預期外的輸入數據後的運行情況，這種做法是在測試的過程中普遍存在的。舉例來說，在第一章提到的對三角形程序的測試中，這種測試趨勢就已經體現出來了。
在向程序輸入1，2，5這三個數據的時候，只有很少的人會認爲程序將判斷出這是一個無效三角形而並非一個不等邊三角形。就像這樣，許多問題在意想不到的測試條件下暴露無遺。得到的結果顯示，在用例中無效輸入數據和預期外的輸入數據，會檢測出常規數據所檢測不到的問題。
法則6：檢查程序應該完成哪些功能，這只是測試工作的一半，測試工作的另一半是，檢查程序完成了哪些不應該完成的功能
法則中所闡述的觀點已經在上述各個法則的描述中得到了解答。檢查程序是否產生了預期外的結果很重要。例如，一個看似正常運行的薪資系統，爲並不存在的僱員支出了工資或是後面的記錄覆蓋了前面的記錄。
法則7：避免一次性的測試用例，除非該程序是一個真正的一次性項目
這條法則經常用於交互式系統的測試當中。通常的作法是建立靈活性較高的測試用例，然後在程序中執行它們。困難的是已經完成的測試用例是否僅適用於當前的測試環境，當環境變更的時候就再也用不上了。測試用例需要隨時維護（例如，發現用例中存在漏洞的情況下要及時修正），以便在經後的測試中可以重複使用。由於需求的頻繁變更所帶來的測試用例維護的工作量非常大，這也是對測試人員的一種考驗，是否能夠及時的修正測試用例以便測試到程序的新特性，如果用例沒有根據新需求及時做出修改，那麼將會發生漏測的現象，許多錯誤也因此不會在測試中被發現了。將修改後的測試用例存檔，並在新環境中作爲迴歸測試的用例執行它們。
法則8：如果沒有很好的對測試工作進行計劃，只憑主觀臆斷來測試，將很難發現程序中存在的錯誤
大多數的測試經理都會犯這樣的錯誤，原因在於他們錯誤的理解了測試的意義，在他們眼中測試的過程是在證明程序能夠按照預期規定的正確運行。這裏再次強調，測試的真正意義在於儘可能多的找出程序中的缺陷。
法則9：如果某段程序出現了錯誤，那麼該段程序出錯的概率與代碼數量成正比
圖2.2描述了這個現象。很少的人會認同這種現象，但在實現的程序中這種現象卻經常發生。舉個例子，有這樣一段程序，由兩個模塊組成，這兩個模塊可以是類也可以是兩個子程序，將它們分別記作A和B。在模塊A中發現了5個錯誤，在模塊B中只發現了一個，如果對模塊A進行更嚴格的測試的話，你將會發現正好印正了法則中所闡述的觀點，模塊A存在錯誤遠遠大於模塊B。
換一種比較通俗的解釋來說明本法則，就是錯誤簇。在一個典型的程序中，問題更傾向發生在其中一段程序中，那麼這段程序的錯誤發生率就會高於另一段程序，沒有人能解釋這種現象。在測試的過程中要對這個現象加倍注意，如果其中某段程序的錯誤率高於其他部分，那麼投入較多的精力去測試這段程序就十分必要了，因爲有可能通過嚴格的測試後發現，這段程序的確存在很多的錯誤。
法則10：測試是一項具有創造性和挑戰性的任務
軟件測試是比其他工作更具有創造性和挑戰性的工作。在前面我們已經闡述了對程序的完全測試並找出所有錯誤是不可能辦到的事情。在後面的章節中我們將闡述建立合理的測試用例的方法，但學習這些方法需求學習者具有更強的創造性和應變能力。
摘要
如果要繼續閱讀本書，那麼請在腦海中時刻謹記以下三個法則：
軟件測試是找出程序中隱藏錯誤的過程。
高質量的測試用例能夠發現較多的程序中的隱藏錯誤。
一個成功的用例能夠發現未被發現的隱藏錯誤。