軟件測試-理論常識篇

最近1直在學習測試方面的知識，也閱讀了許多博客，通過這些博客也了解到了許多未曾接觸過的關于測試方面的理

論和原則和1些常識性的東西，比如測試的不完全性，測試中的28定律，缺點的必定性等。這篇文章做下整理，

分享給大家。了解這些將對我們在進行軟件測試時掌控軟件測試尺度很有幫助。

☆測試的不完全性

很明顯，由于軟件需求的不完全性、軟件邏輯路徑的組合性、輸入數據的大量性及結果多樣性等因素，哪怕是1個極

其簡單的程序，要想窮盡所有邏輯路徑，所有輸入數據和驗證所有結果是非常困難的1件事情。我們舉1個簡單的例

子，比如說求兩個整數的最大公約數。其輸入信息為兩個正整數。但是如果我們將全部正整數域的數字進行1番測試

的話，從其數目的無窮性我們即可證明是這樣的測試在實際生活中是行不通的。為此作為軟件測試，我們1般采取等

價類和邊界值分析等措施來進行實際的軟件測試，尋覓最小用例集合成為我們精簡測試復雜性的1條必經之道。

☆測試具有免疫性(軟件缺點免疫性)

軟件缺點與病毒1樣具有可怕的“ 免疫性 ” ，測試人員對其采取的測試越多，其免疫能力就越強，尋覓更多軟件缺

陷就更加困難。由數學上的幾率論我們可以推出這1結論。假定1個 50000行的程序中有 500 個軟件缺點并且這些

軟件毛病散布時均勻的，則每 100 行可以找到1個軟件缺點。我們假定測試人員用某種方法花在查找軟件缺點的精力

為 X小時 /100 行。照此推算，軟件存在 500 個缺點時，我們查找1個軟件缺點需要 X 小時，當軟件只存在 5 個錯

誤時，我們每查找1個軟件缺點需要 100X小時。實踐證明，實際的測試進程比上面的假定更加刻薄，為此我們必須

更換不同的測試方式和測試數據。該例子還說明了在軟件測試中采取單1的方法不能高效和完全的針對所有軟件缺

陷，因此軟件測試應當盡量的多采取多種途徑進行測試。

☆測試是 “泛型概念 ” (要全程測試)

軟件測試僅存在于程序完成以后？現在這個概念恐怕難以立足了。由于如果單純的只將程序設計階段后的階段稱之為

軟件測試的話，需求階段和設計階段的缺點產生的放大效應會加大。這非常不利于保證軟件質量。需求缺點、設計缺

陷也是軟件缺點，記住“ 軟件缺點具有生育能力 ”。軟件測試應當逾越全部軟件開發流程。需求驗證(自檢)和設計驗

證(自檢)也能夠算作軟件測試的1種。軟件測試應當是1個泛型概念，涵蓋全部軟件生命周期，這樣才能確保周期的

每一個階段禁得起考驗。同時測試本身也需要有第3者進行評估(信息系統審計和軟件工程監理)，即測試本身也應當被

測試，從而確保測試本身的可靠性和高效性。否則本身不正，難以服人。

另外還需指出的是軟件測試是提高軟件產品質量的必要條件而非充分條件，軟件測試是提高產品質量最直接、最快捷

的手段，但決不是1個根本手段。

☆28定律

28定律，這里感覺非常親切，原來28定律也能夠用在測試里，80%的軟件缺點常常生存在軟件 20% 的空間里。

這個原則告知我們，如果你想使軟件測試有效地話，記住常常光臨其高危多發 “ 地段 ”。在那里發現軟件缺點的可

能性會大的多。這1原則對軟件測試人員提高測試效力及缺點發現率有側重大的意義。聰明的測試人員會根據這個

原則很快找出較多的缺點而笨拙的測試人員卻仍在漫無目的地到處搜索。

28定律的另外1種情況是，我們在系統分析、系統設計、系統實現階段的復審，測試工作中能夠發現和避免 80% 

的軟件缺點，爾后的系統測試能夠幫助我們找出剩余缺點中的 80% ，最后的 5%的軟件缺點可能只有在系統交付使

用后用戶經過大范圍、長時間使用后才會曝露出來。由于軟件測試只能夠保證盡量多地發現軟件缺點，卻沒法保證

能夠發現所有的軟件缺點。

28定律還能反應到軟件測試的自動化方面上來，實踐證明 80%的軟件缺點可以借助人工測試而發現， 20% 的軟件

缺點可以借助自動化測試能夠得以發現。由于這2者間具有交叉的部份，因此尚有5% 左右的軟件缺點需要通過其他

方式進行發現和修正。

☆為效益而測試

為何我們要實行軟件測試，是為了提高項目的質量效益終究以提高項目的整體效益。為此我們不難得出我們在實行

軟件測試應當掌握的度。軟件測試應當在軟件測試本錢和軟件質量效益二者間找到1個平衡點。這個平衡點就是我們

在實行軟件測試時應當遵照的度。單方面的尋求都必定侵害軟件測試存在的價值和意義。1般說來，在軟件測試中我

們應當盡可能地保持軟件測試簡單性，切勿將軟件測試過度復雜化，拿物理學家愛因斯坦的話說就是：Keep it simple 

but not too simple 。

☆缺點的必定性

軟件測試中，由于毛病的關聯性，其實不是所有的軟件缺點都能夠得以修復。某些軟件缺點雖然能夠得以修復但在修復

的進程中我們會難免引入新的軟件缺點。很多軟件缺點之間是相互矛盾的，1個矛盾的消失必定會引發另外1個矛盾

的產生。比如我們在解決通用性的缺點后常常會帶來履行效力上的缺點。更何況在缺點的修復進程中，我們常常還會

受時間、本錢等方面的限制因此沒法有效、完全地修復所有的軟件缺點。因此評估軟件缺點的重要度、影響范圍，選

擇1個折衷的方案或是從非軟件的因素(比如提升硬件性能)斟酌軟件缺點成為我們在面對軟件缺點時1個必須直面的

事實。

這些常識性的理論原則我覺得非常有必要了解1下，由于這些都是先輩們經過無數次嘗試總結出來的，站在偉人的肩

膀上能使我們少走1些彎路，關于測試的學習仍在繼續！

參考： <http://www.ltesting.net/ceshi/ceshijishu/rjcsgcsrm/2013/1023/206738.html> 

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈