1.2 軟件測試的七項基本原則

下面是業界公認的軟件測試的七項原則。

1.2.1 原則1：軟件測試顯示存在缺陷

軟件測試可以顯示軟件中存在缺陷，但不能證明軟件不存在缺陷。軟件測試可以減少軟件中存在未被發現缺陷的可能性，但即使軟件測試沒有發現任何缺陷，也不能證明軟件或系統是完全正確的。軟件中到底存在多少缺陷，誰也不知道。軟件測試的目的是盡可能發現更多的缺陷。此外，有些缺陷是不影響使用的，所以在考慮時間和成本上可以不必修改，從而防止過度測試帶來對資源的浪費。

1.2.2 原則2：窮盡軟件測試是不可行的

進行完全（各種輸入和前提條件的組合）的軟件測試是不可行的。通過運用風險分析和不同系統功能的軟件測試優先級，確定軟件測試的關注點，從而替代窮盡軟件測試。窮盡軟件測試真正的意思是，在軟件測試完畢后，軟件測試工程師知道在系統里沒有殘留任何未知的Bug。因為如果有未知的Bug，那么就可以通過做更多的軟件測試找到他們，這樣軟件測試也就還沒有窮盡。因為零缺陷的軟件是不存在的，所以窮盡的軟件測試也是不可行的。

1.2.3 原則3：軟件測試盡早介入

為了盡早發現缺陷，在軟件或系統開發生命周期中，軟件測試活動應該盡可能早地介入，并且也應該將關注點放在已經定義的軟件測試目標上。在軟件測試的各個階段，軟件測試最好在需求分析期間就介入進去，一方面可以盡早發現缺陷，另一方面可以盡早掌握產品的需求和設計，為更好地進行測試做好準備。請參考1.1.4節介紹的W軟件測試模型。

1.2.4 原則4：缺陷集群性

軟件測試工作的分配比例應該與預期的和后期觀察到的缺陷分布模塊相適應。少數模塊通常包含大部分在軟件測試版本中發現的缺陷或失效。這個符合80-20原則，即80%的缺陷發生在20%的模塊中。造成這種現象的可能性如下：

● 該模塊功能比較復雜；

● 實現該功能模塊的開發工程師水平比較低；

● 其他原因。

James Whittaker等著的《探索式軟件測試》書中提到對軟件災難區進行重點測試也是基于這點考慮的。

案例1-18：缺陷集群性。

產品項目同案例1-17，根據前兩周的測試，總結出來的缺陷報告如下：

由此可見，模塊D的缺陷是最多的，其次為模塊A，然后是模塊B，模塊F和模塊C，模塊E和模塊G相對缺陷比較少。根據缺陷集群性，測試經理調整第三周的測試任務如下：

1.2.5 原則5：殺蟲劑悖論

采用同樣的測試用例多次重復進行測試，最后將不再發現新的缺陷。為了克服這種“殺蟲劑悖論”，測試用例需要進行定期評審和修改，同時需要不斷增加新的不同的測試用例，來測試軟件或系統的不同部分，從而發現更多的潛在缺陷。具體可以參見1.1.11節中關于殺蟲劑現象的描述。

1.2.6 原則6：軟件測試活動依賴于軟件測試背景

針對不同的軟件測試背景，進行不同的軟件測試活動。比如，對通信系統的軟件進行軟件測試，與對嵌入式機頂盒系統軟件的軟件測試的方法是不一樣的。

1.2.7 原則7：不存在缺陷（即有用系統）的謬論

假如系統無法使用，或者系統不能完成客戶的需求和期望，發現和修改缺陷是沒有任何意義的。