1、開發和使用的歷史已經留給了很多由于缺陷而導致的巨大財力、物力損失的經驗教訓。這些經驗教訓迫使這些測試工程師們必須采取強有力的檢測措施來檢測未發現的隱藏的缺陷。生產的最終目的是為了滿足客戶需求，以客戶需求作為評判質量的標準，缺陷（ Software Bug ）的具體含義包括下面幾個認為：未達到客戶需求的功能和性能；超出客戶需求的范圍；出現客戶需求的錯誤；的使用未能符合客戶的和工作環境。考慮到設計等方面的，還可以認為缺陷還可以包括設計不符合規范，未能在特定的條件（、范圍等）達到最佳等?？上У氖牵械暮芏嗳烁鼉A向于把軟件缺陷看成運行時出現問題上來，認為測試僅限于程序提交之后。在目前的國內環境下，幾乎

2、看不到完整準確的客戶需求說明書，加以客戶的需求時時在變，追求完美的測試變得不太可能。因此作為一個優異的測試，追求質量的完美固然是的，但是明確測試現實與理想的差距，在測試中學會取舍和讓步，對測試是有百益而無一弊的。下面是一些測試的，對這些的理解和運用將有助于在進行測試時能夠更好的把握測試的尺度。測試是不完全的（測試不完全）很顯然，由于需求的不完整性、邏輯路徑的組合性、輸入數據的大量性及結果多樣性等，哪怕是一個極其簡單的程序，要想窮盡所有邏輯路徑，所有輸入數據和驗證所有結果是非常的一件事情舉一個簡單的例子，比如說求兩個整數的最大公約數。其輸入信息為兩個正整數。但是如果整個正整數域的數字進行一番測試

3、的話，從其數目的無限性便可證明是這樣的測試在實際生活中是行不通的，即便某一天能夠窮盡該程序，只怕乃至的子孫都早已作古了。為此作為測試，一般采用等價類和邊界值分析等措施來進行實際的測試，尋找最小用例集為精簡測試復雜性的一條必經之道。測試具有免疫性（缺陷免疫性）一樣具有可怕的 “免疫性 ” ，測試缺陷與對其采用的測試越多，其免疫能力就越強，尋找缺陷就更加。由數學上的概率論可以推出這一結論。假設一個 50000 行的程序中有500 個缺陷并且這些錯誤分布時均勻的，則每 100 行可缺陷的精力為 X 小時 /以找到一個缺陷。假設測試用某種方法花在查找100 行。照此推算，存在 500 個缺陷時，查找一

4、個缺陷需要 X 小時，當軟件只存在 5 個錯誤時，缺陷需要 100X 小時。實踐證明，實際的測試每查找一個過程比上面的假設更為苛刻，為此須更換不同的測試方式和測試數據。該例子還說明了在測試中采用單一的方法不能高效和完全的針對所有缺陷，因此測試應該盡可能的多采用多種途徑進試。測試是 “ 泛型概念 ” （全程測試）我一直測試僅存在于程序完成之后。如果單純的只將程序設計階段后的階段稱之為測試的話，需求階段和設計階段的缺陷產生的放大效應會加大。這非常不利于保證質量。需求缺陷、設計缺陷也是缺陷，記住 “缺陷具有能力 ” 。測試應該整個開發流程。需求驗證（自檢）和設計驗證（自檢）也可以算作測試（建議稱為：

5、需求測試和設計測試）的一種。測試應該是一個泛型概念，涵蓋整個軟件生命周期，這樣才能確保周期的每個階段禁得起考驗。同時測試本身也需要有第三者進行評估（信息系統審計和工程監理），即測試本身也應當被測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。另外還需的是測試是提高產品質量的必要條件而非充分條件測試是提高產品質量最直接、最快捷段，但決不是一個根本。80-20 原則80% 的缺陷常常生存在20% 的空間里。這個原則告訴，如果你想使軟件測試有效地話，記住常常光臨其高危多發 “ 地段 ” 。在那里發現缺陷的可能性會大的多。這一原則對于測試提高測試效率及缺陷發現率有著的意義。聰明的測試會根

6、據這個原則很快找出較多的缺陷而愚蠢的測試卻仍在漫無目的地到處搜尋。80-20 原則的另外一種情況是，在系統分析、系統設計、系統實現階段的復審，測試工作中能夠發現和避免 80% 的缺陷，此后的系統測試能夠幫助找出剩余缺陷中的 80% ，最后的 5% 的缺陷可能只有在系統交付使用后用戶經過大范圍、長時間使用后才會曝露出來。因為測試只能夠保證盡可能多地發現缺陷，卻無法保證能夠發現所有的缺陷。助人工測試而發現， 20% 的缺陷可以借助自動化測試能夠得以發現。由于這二者間具有交叉的部分，因此尚有 5% 左右的缺陷需要通過其他方式進行發現和修正。為什么要實施測試，是為了提高項目的質量效益最終以提高項目的總

7、體效益。為此不難得出在實施測試應該掌握的度 測試應該在測試成本和質量效益兩者間找到一個平衡點。這個平衡點就是在實施測試時應該遵守的度。單方面的追求都必然損害測試存在的價值和意義。一般說來，在測試中應該盡量地保持測試簡單性，切勿將測試過度復雜化，拿物理學家的話說就是： 陷雖然能夠得以修復但在修復的過程中會難免引入新的缺陷。很多缺陷之間是相互的，一個的必然會另外一個的產生。比如在解決通用性的缺陷后往往會帶來執行效率上的缺陷。更何況在缺陷的修復過程中，常常還會受時間、成本等方面的限制因此無法有效、完整地修復所有的缺陷。因此評估缺陷的重要度、影響范圍，選擇一個折中的方案或是從非的（比如硬件性能）考慮缺

8、陷成為在面對缺陷時一個必須直面的事實。 測試必須有預期結果沒有預期結果的測試是不可理喻的。缺陷是經過對比而得出來的。這正如沒有標準無法進行度量一樣。如果事先不知道或是無法肯定預期的結果，然無法了解測試正確性。這很容易然人感覺如盲人摸象一般，不少測試常常憑借自身的感覺去評判 測試的意義 - 事后分析重蹈 ” 。沒有對進行認真的分析，就無法了解缺陷發生的原因和應對措施，結果是不得不耗費的大量的人力和物力來再次查找缺陷。很可惜，目前大多測試團隊都沒有這一點，測試中缺乏分析這一環節。測試的目的單單是發現缺陷這么簡單嗎？如果是 “ 是 ” 的話，我敢保證，類似的缺陷在下一次新項目的測試中還會發生。古語說得好， “ 不知道歷史的人必然會缺陷的發生，其結果往往是把似是而非的東西作為正確的結果來判斷，因此常常出現誤測的現象。Keep it simple but not too simple 。缺陷的必然性測試中，由于錯誤的關聯性，并不是所有