標籤:
1. 測試的不完全性
很顯然,由於軟體需求的不完整性、軟體邏輯路徑的組合性、輸入資料的大量性及結果多樣性等因素,哪怕是一個極
其簡單的程式,要想窮盡所有邏輯路徑,所有輸入資料和驗證所有結果是非常困難的一件事情。我們舉一個簡單的例
子,比如說求兩個整數的最大公約數。其輸入資訊為兩個正整數。但是如果我們將整個正整數域的數字進行一番測試
的話,從其數目的無限性我們便可證明是這樣的測試在實際生活中是行不通的。為此作為軟體測試,我們一般採用等
價類和邊界值分析等措施來進行實際的軟體測試,尋找最小用例集合成為我們精簡測試複雜性的一條必經之道。
2.測試具有免疫性(軟體缺陷免疫性)
軟體缺陷與病毒一樣具有可怕的“ 免疫性 ” ,測試人員對其採用的測試越多,其免疫能力就越強,尋找更多軟體缺
陷就更加困難。由數學上的機率論我們可以推出這一結論。假設一個 50000行的程式中有 500 個軟體缺陷並且這些
軟體錯誤分布時均勻的,則每 100 行可以找到一個軟體缺陷。我們假設測試人員用某種方法花在尋找軟體缺陷的精力
為 X小時 /100 行。照此推算,軟體存在 500 個缺陷時,我們尋找一個軟體缺陷需要 X 小時,當軟體只存在 5 個錯
誤時,我們每尋找一個軟體缺陷需要 100X小時。實踐證明,實際的測試過程比上面的假設更為苛刻,為此我們必須
更換不同的測試方式和測試資料。該例子還說明了在軟體測試中採用單一的方法不能高效和完全的針對所有軟體缺
陷,因此軟體測試應該儘可能的多採用多種途徑進行測試。
3. 為效益而測試
為什麼我們要實施軟體測試,是為了提高項目的品質效益最終以提高項目的總體效益。為此我們不難得出我們在實施
軟體測試應該掌握的度。軟體測試應該在軟體測試成本和軟體品質效益兩者間找到一個平衡點。這個平衡點就是我們
在實施軟體測試時應該遵守的度。單方面的追求都必然損害軟體測試存在的價值和意義。一般說來,在軟體測試中我
們應該盡量地保持軟體測試簡單性,切勿將軟體測試過度複雜化,拿物理學家愛因斯坦的話說就是:Keep it simple
but not too simple 。
4. 缺陷的必然性
軟體測試中,由於錯誤的關聯性,並不是所有的軟體缺陷都能夠得以修複。某些軟體缺陷雖然能夠得以修複但在修複
的過程中我們會難免引入新的軟體缺陷。很多軟體缺陷之間是相互矛盾的,一個矛盾的消失必然會引發另外一個矛盾
的產生。比如我們在解決通用性的缺陷後往往會帶來執行效率上的缺陷。更何況在缺陷的修複過程中,我們常常還會
受時間、成本等方面的限制因此無法有效、完整地修複所有的軟體缺陷。因此評估軟體缺陷的重要度、影響範圍,選
擇一個折中的方案或是從非軟體的因素(比如提升硬體效能)考慮軟體缺陷成為我們在面對軟體缺陷時一個必須直面的
事實。
軟體測試的一些常識