測試在于暴露缺陷
把我們關注的焦點局限在測試團隊的兩個主要目的上：
除了開發團隊意外的人，會考慮尋找有關的(值得報告的)缺陷并修改這些缺陷。
即使在這些目的范圍內，也有很多種不同的好的測試方法。例如，我們也許會說一個測試好于另一個測試，如果它：
更有力。
根據一般的統計學常識，我是這樣理解有利的：如果存在缺陷就更可能暴露出來。注意，對一類缺陷來說，測試1比測試2更有力;對另一類缺陷來說，測試1不如測試2有力。
更可能產生重大(更有根據、更有說服力的結果)。
如果對一個重大問題有影響力的負責人拒絕修改這個問題。(負責人是指對產品有影響的人。對產品有影響力的負責人是指其喜好和觀點會導致產品變更的人。)
更可靠。
可靠的測試更可能像是程序員或其他有影響力的負責人進行的真實的(或合理的)操作集合�！斑吔菧y試”是程序員慣用的一個例子，它是說測試或缺陷不可靠：“沒有什么可以證明它�！比绻行�(或所有)對產品有影響力的負責人同意測試用例的真實性，那么它就是可靠性。
更可能發現客戶遇到的典型事件。
設計的很多測試都有很高的可信度。讓你的人去影響真正的使用用途。
越經常出現的活動組就越可能被覆蓋或完全覆蓋。(我說的活動組是指很多特性同時被用，所以我們就追蹤哪些特性集合體按照什么次序被使用了，并根據我們的分析反映這些信息。)更詳細的請參閱Musa的(1998)關于軟件可靠性工程。
更易于評價。
問題是程序是否通過了測試?為了易于進行評價，測試人員應該有能力快速、不費力地決定程序是否能通過測試。說程序可能是否會測試是不夠的。較難進行評價的是，花費的時間越多，錯誤越可能在不經意間閃過。面對費時的評估，測試人員會用便捷的方法、另辟蹊徑來減少程序是否完好的費時的評測。這些便捷的方法往往不完全精確(就是說，他們會發現不了明顯的缺陷或把正確的代碼標記為錯誤的。)
更有利于解決問題。
比如，在不能給有關測試條件提供大量信息以重現問題的情況下，大量的自動測試經常會搞毀系統。
他們對解決問題沒有好處。越難重復的測試越不利于解決問題。
如果需要解決的問題是由這個測試發現的，那么這個測試就越難執行，下次測試也越難執行正確。
更有信息量。
測試的價值就是我們能從中學到東西。
大多數情況下，你從通過測試的程序中學到的東西比沒通過測試的程序中學到的多，但有信息的測試會教你(減少不確定性)判定程序是否能通過測試。
比如，如果我們已經在多次構建之后運行了一個測試，并且程序每次都可靠地通過測試，那么我們就期望程序能再次通過這項測試。從重復測試中得到的另外的“通過”結果不會有助于我們對程序的認知。
等價類的觀點是信息價值的另一個例子。任何測試背后都是一個測試集，他們之間有很高的相似度，我們認為其他測試實質上是這個測試的冗余。用口頭的行話說，這就是“等價類”或者“等價部分”。如果這些測試充分的相似，那么第二次測試得到的附加信息會少于第一次測試。
這個標準很接近于Karl Popper的實驗價值理論(參考Popper 1992)。優秀的實驗涵蓋了風險預測。這個理論預言人們期望的某些事物并不真實，你偏愛的理論是錯的或者會令許多人感到驚訝。Popper分析認為優秀的實驗(優秀的測試)是近似于科學哲理的主流核心理念。
或許，在這里真正要考慮的是，你希望從測試中學到的東西與測試設計、運行的機會成本是均衡的。你花費在測試上的時間就是你沒有花費在其他測試或活動上的時間。
更加復雜。
一個復雜的測試包含被測軟件的很多方面、或變量、或其他屬性。
當程序有很多變更或一次測了很多特性時，不提倡用復雜測試。如果程序存在很多BUG，復雜測試很快就會失敗，也就沒必要再執行它了。測試組主要依靠復雜測試發現模塊化的BUG。模塊化的BUG使很多測試都無法通過，阻礙測試組了解測試應該暴露的信息。因此，測試初期，進行簡單測試是合理的、有必要的。當程序更穩定時，或(在極限編程或任何開發生命周期)程序有了更穩定的特性時，更復雜的測試就會變得更有意義。
更可能幫助測試人員或編碼人員洞察產品、客戶或者外界環境的某些方面。
有時，我們通過測試了解產品，了解其如何運轉以及存在的風險。隨后，我們會設計測試來暴露產品的缺陷，但測試剛開始時，我們會對“是什么”和“怎么測”感興趣。很多這樣的測試不會重復進行。然而，在第一次測試環境中，期望(典型地，單元)測試集合警示編碼人員實驗上出現代碼變更的副作用。在這種環境下，設計的測試會標記出性能變更、化整誤差的差異、或者其他某些變更，這些都不是缺陷。程序中意想不到的變更會警示編碼人員，她的代碼或代碼變更影響的原型是不完整或錯誤的，并引導她進行額外的測試或者解決問題。(感謝Ward Oummingham和Brain Marick提供的這個例子。)
文章來源于領測軟件測試網 http://www.kjueaiud.com/
