軟件開發和使用的歷史已經留給了我們很多由于軟件缺陷而導致的巨大財力、物力損失的經驗教訓。這些經驗教訓迫使我們這些測試工程師們必須采取強有力的檢測措施來檢測未發現的隱藏的軟件缺陷。
生產軟件的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟件質量的標準，認為軟件缺陷（ Software Bug ）的具體含義包括下面幾個因素：
軟件未達到客戶需求的功能和性能；
軟件超出客戶需求的范圍；
軟件出現客戶需求不能容忍的錯誤；
軟件的使用未能符合客戶的習慣和工作環境。
考慮到設計等方面的因素，我們還可以認為軟件缺陷還可以包括軟件設計不符合規范，未能在特定的條件（資金、范圍等）達到最佳等�？上У氖�，我們中的很多人更傾向于把軟件缺陷看成運行時出現問題上來，認為軟件測試僅限于程序提交之后。
在目前的國內環境下，我們幾乎看不到完整準確的客戶需求說明書，加以客戶的需求時時在變，追求完美的測試變得不太可能。因此作為一個優異的測試人員，追求軟件質量的完美固然是我們的宗旨，但是明確軟件測試現實與理想的差距，在軟件測試中學會取舍和讓步，對軟件測試是有百益而無一弊的。
下面是一些軟件測試的常識，對這些常識的理解和運用將有助于我們在進行軟件測試時能夠更好的把握軟件測試的尺度。
測試是不完全的（測試不完全）
很顯然，由于軟件需求的不完整性、軟件邏輯路徑的組合性、輸入數據的大量性及結果多樣性等因素，哪怕是一個極其簡單的程序，要想窮盡所有邏輯路徑，所有輸入數據和驗證所有結果是非常困難的一件事情。我們舉一個簡單的例子，比如說求兩個整數的最大公約數。其輸入信息為兩個正整數。但是如果我們將整個正整數域的數字進行一番測試的話，從其數目的無限性我們便可證明是這樣的測試在實際生活中是行不通的，即便某一天我們能夠窮盡該程序，只怕我們乃至我們的子孫都早已作古了。為此作為軟件測試，我們一般采用等價類和邊界值分析等措施來進行實際的軟件測試，尋找最小用例集合成為我們精簡測試復雜性的一條必經之道。
測試具有免疫性（軟件缺陷免疫性）
軟件缺陷與病毒一樣具有可怕的 “ 免疫性 ” ，測試人員對其采用的測試越多，其免疫能力就越強，尋找更多軟件缺陷就更加困難。由數學上的概率論我們可以推出這一結論。假設一個 50000 行的程序中有 500 個軟件缺陷并且這些軟件錯誤分布時均勻的，則每 100 行可以找到一個軟件缺陷。我們假設測試人員用某種方法花在查找軟件缺陷的精力為 X 小時 /100 行。照此推算，軟件存在 500 個缺陷時，我們查找一個軟件缺陷需要 X 小時，當軟件只存在 5 個錯誤時，我們每查找一個軟件缺陷需要 100X 小時。實踐證明，實際的測試過程比上面的假設更為苛刻，為此我們必須更換不同的測試方式和測試數據。該例子還說明了在軟件測試中采用單一的方法不能高效和完全的針對所有軟件缺陷，因此軟件測試應該盡可能的多采用多種途徑進行測試。
測試是 “ 泛型概念 ” （全程測試）
我一直反對軟件測試僅存在于程序完成之后。如果單純的只將程序設計階段后的階段稱之為軟件測試的話，需求階段和設計階段的缺陷產生的放大效應會加大。這非常不利于保證軟件質量。需求缺陷、設計缺陷也是軟件缺陷，記住 “ 軟件缺陷具有生育能力 ” 。軟件測試應該跨越整個軟件開發流程。需求驗證（自檢）和設計驗證（自檢）也可以算作軟件測試（建議稱為：需求測試和設計測試）的一種。軟件測試應該是一個泛型概念，涵蓋整個軟件生命周期，這樣才能確保周期的每個階段禁得起考驗。同時測試本身也需要有第三者進行評估（信息系統審計和軟件工程監理），即測試本身也應當被測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。
文章來源于領測軟件測試網 http://www.kjueaiud.com/