最近一直在學習測試方面的知識，也瀏覽了許多部落格，通過這些部落格也了解到了許多未曾接觸過的關於測試方面的理
論和原則以及一些常識性的東西，比如測試的不完全性，測試中的二八定律，缺陷的必然性等。這篇文章做下整理，
分享給大家。了解這些將對於我們在進行軟體測試時把握軟體測試尺度很有幫助。
☆測試的不完全性
很顯然，由於軟體需求的不完整性、軟體邏輯路徑的組合性、輸入資料的大量性及結果多樣性等因素，哪怕是乙個極
其簡單的程式，要想窮盡所有邏輯路徑，所有輸入資料和驗證所有結果是非常困難的一件事情。我們舉乙個簡單的例
子，比如說求兩個整數的最大公約數。其輸入資訊為兩個正整數。但是如果我們將整個正整數域的數字進行一番測試
的話，從其數目的無限性我們便可證明是這樣的測試在實際生活中是行不通的。為此作為軟體測試，我們一般採用等
價類和邊界值分析等措施來進行實際的軟體測試，尋找最小
用例集合成為我們精簡測試複雜性的一條必經之道。
☆測試具有免疫性(軟體缺陷免疫性)
軟體缺陷與病毒一樣具有可怕的「 免疫性 」 ，測試人員對其採用的測試越多，其免疫能力就越強，尋找更多軟體缺
陷就更加困難。由數學上的概率論我們可以推出這一結論。假設乙個 50000行的程式中有 500 個軟體缺陷並且這些
軟體錯誤分布時均勻的，則每 100 行可以找到乙個軟體缺陷。我們假設測試人員用某種方法花在查詢軟體缺陷的精力
為 x小時 /100 行。照此推算，軟體存在 500 個缺陷時，我們查詢乙個軟體缺陷需要 x 小時，當軟體只存在 5 個錯
誤時，我們每查詢乙個軟體缺陷需要 100x小時。實踐證明，實際的測試過程比上面的假設更為苛刻，為此我們必須
更換不同的測試方式和測試資料。該例子還說明了在軟體測試中採用單一的方法不能高效和完全的針對所有軟體缺
陷，因此軟體測試應該盡可能的多採用多種途徑進行測試。
☆測試是「泛型概念」 (要全程測試)
軟體測試僅存在於程式完成之後？現在這個概念恐怕難以立足了。因為如果單純的只將程式設計階段後的階段稱之為
軟體測試的話，需求階段和設計階段的缺陷產生的放大效應會加大。這非常不利於保證軟體質量。需求缺陷、設計缺
陷也是軟體缺陷，記住「 軟體缺陷具有生育能力 」。軟體測試應該跨越整個軟體開發流程。需求驗證(自檢)和設計驗
證(自檢)也可以算作軟體測試的一種。軟體測試應該是乙個泛型概念，涵蓋整個軟體生命週期，這樣才能確保週期的
每個階段禁得起考驗。同時測試本身也需要有第三者進行評估(資訊系統審計和軟體工程監理)，即測試本身也應當被
測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。
另外還需指出的是軟體測試是提高軟體產品質量的必要條件而非充分條件，軟體測試是提高產品質量最直接、最快捷
的手段，但決不是乙個根本手段。
☆二八定律
二八定律，這裡感覺非常親切，原來二八定律也可以用在測試裡，80%的軟體缺陷常常生存在軟體 20% 的空間裡。
這個原則告訴我們，如果你想使軟體測試有效地話，記住常常光臨其高危多發 「 地段 」。在那裡發現軟體缺陷的可
能性會大的多。這一原則對於軟體測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個
原則很快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的地到處搜尋。
二八定律的另外一種情況是，我們在系統分析、系統設計、系統實現階段的複審，測試工作中能夠發現和避免 80%
的軟體缺陷，此後的
系統測試
能夠幫助我們找出剩餘缺陷中的 80% ，最後的 5%的軟體缺陷可能只有在系統交付使
用後使用者經過大範圍、長時間使用後才會曝露出來。因為軟體測試只能夠保證盡可能多地發現軟體缺陷，卻無法保證
能夠發現所有的軟體缺陷。
二八定律還能反映到軟體測試的
自動化方面上來，實踐證明 80%的軟體缺陷可以借助人工測試而發現， 20% 的軟體
缺陷可以借助
自動化測試能夠得以發現。由於這二者間具有交叉的部分，因此尚有5% 左右的軟體缺陷需要通過其他
方式進行發現和修正。
☆為效益而測試
為什麼我們要實施軟體測試，是為了提高專案的質量效益最終以提高專案的總體效益。為此我們不難得出我們在實施
軟體測試應該掌握的度。軟體測試應該在軟體測試成本和軟體質量效益兩者間找到乙個平衡點。這個平衡點就是我們
在實施軟體測試時應該遵守的度。單方面的追求都必然損害軟體測試存在的價值和意義。一般說來，在軟體測試中我
們應該盡量地保持軟體測試簡單性，切勿將軟體測試過度複雜化，拿物理學家愛因斯坦的話說就是：keep it ******
but not too ****** 。
☆缺陷的必然性
軟體測試中，由於錯誤的關聯性，並不是所有的軟體缺陷都能夠得以修復。某些軟體缺陷雖然能夠得以修復但在修復
的過程中我們會難免引入新的軟體缺陷。很多軟體缺陷之間是相互矛盾的，乙個矛盾的消失必然會引發另外乙個矛盾
的產生。比如我們在解決通用性的缺陷後往往會帶來執行效率上的缺陷。更何況在缺陷的修復過程中，我們常常還會
受時間、成本等方面的限制因此無法有效、完整地修復所有的軟體缺陷。因此評估軟體缺陷的重要度、影響範圍，選
擇乙個折中的方案或是從非軟體的因素(比如提公升硬體效能)考慮軟體缺陷成為我們在面對軟體缺陷時乙個必須直面的
事實。
這些常識性的理論原則我覺得非常有必要了解一下，因為這些都是前輩們經過無數次嘗試總結出來的，站在巨人的肩
膀上能使我們少走一些彎路，關於測試的學習仍在繼續！
參考：<
>
軟體測試常識
軟體開發和使用的歷史已經留給了我們很多由於軟體缺陷而導致的巨大財力 物力損失的經驗教訓。這些經驗教訓迫使我們這些測試工程師們必須採取強有力的檢測措施來檢測未發現的隱藏的軟體缺陷。生產軟體的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟體質量的標準，認為軟體缺陷 software bug 的具體...
軟體測試常識
軟體開發和使用的歷史已經留給了我們很多由於軟體缺陷而導致的巨大財力 物力損失的經驗教訓。這些經驗教訓迫使我們這些測試工程師們必須採取強有力的檢測措施來檢測未發現的隱藏的軟體缺陷。生產軟體的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟體質量的標準，認為軟體缺陷 software bug 的具體...
軟體測試常識
墮落佛發表於 2006年06月25日 08 33 00 href http blog.csdn.net laorer services pingback.aspx rel pingback 軟體測試的常識 軟體開發和使用的歷史已經留給了我們很多由於軟體缺陷而導致的巨大財力 物力損失的經驗教訓。這些經...