本節書摘來自異步社群《軟體測試技術實戰：設計、工具及管理》一書中的第1章，第1.2節軟體測試的七項基本原則，作者顧翔，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
1.2 軟體測試的七項基本原則
下面是業界公認的軟體測試的七項原則。
1.2.1 原則1：軟體測試顯示存在缺陷
軟體測試可以顯示軟體中存在缺陷，但不能證明軟體不存在缺陷。軟體測試可以減少軟體中存在未被發現缺陷的可能性，但即使軟體測試沒有發現任何缺陷，也不能證明軟體或系統是完全正确的。軟體中到底存在多少缺陷，誰也不知道。軟體測試的目的是盡可能發現更多的缺陷。此外，有些缺陷是不影響使用的，是以在考慮時間和成本上可以不必修改，進而防止過度測試帶來對資源的浪費。
1.2.2 原則2：窮盡軟體測試是不可行的
進行完全（各種輸入和前提條件的組合）的軟體測試是不可行的。通過運用風險分析和不同系統功能的軟體測試優先級，确定軟體測試的關注點，進而替代窮盡軟體測試。窮盡軟體測試真正的意思是，在軟體測試完畢後，軟體測試工程師知道在系統裡沒有殘留任何未知的bug。因為如果有未知的bug，那麼就可以通過做更多的軟體測試找到他們，這樣軟體測試也就還沒有窮盡。因為零缺陷的軟體是不存在的，是以窮盡的軟體測試也是不可行的。
擴充閱讀：good enough原則
軟體測試的原則是good-enough原則：這是一種權衡投入/産出比的原則，測試既不要不充分，也不要過分，不充分和過分都是一種不負責任的表現，當然達到good enough是一種理想狀态。
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：不存在缺陷（即有用系統）的謬論
假如系統無法使用，或者系統不能完成客戶的需求和期望，發現和修改缺陷是沒有任何意義的。