,,

軟件開發和使用的歷史已經留給了我們很多由于軟件缺陷而導致的巨大財力、物力損失的經驗教訓。這些經驗教訓迫使我們這些測試工程師們必須采取強有力的檢測措施來檢測未發現的隱藏的軟件缺陷。

生產軟件的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟件質量的標準，認為軟件缺陷（ Software Bug ）的具體含義包括下面幾個因素：

?  軟件未達到客戶需求的功能和性能；

?  軟件超出客戶需求的范圍；

?  軟件出現客戶需求不能容忍的錯誤；

?  軟件的使用未能符合客戶的習慣和工作環境。

考慮到設計等方面的因素，我們還可以認為軟件缺陷還可以包括軟件設計不符合規范，未能在特定的條件（資金、范圍等）達到最佳等。可惜的是，我們中的很多人更傾向于把軟件缺陷看成運行時出現問題上來，認為軟件測試僅限于程序提交之后。

在目前的國內環境下，我們幾乎看不到完整準確的客戶需求說明書，加以客戶的需求時時在變，追求完美的測試變得不太可能。因此作為一個優異的測試人員，追求軟件質量的完美固然是我們的宗旨，但是明確軟件測試現實與理想的差距，在軟件測試中學會取舍和讓步，對軟件測試是有百益而無一弊的。

下面是一些軟件測試的常識，對這些常識的理解和運用將有助于我們在進行軟件測試時能夠更好的把握軟件測試的尺度。

?  測試是不完全的（測試不完全）

很顯然，由于軟件需求的不完整性、軟件邏輯路徑的組合性、輸入數據的大量性及結果多樣性等因素，哪怕是一個極其簡單的程序，要想窮盡所有邏輯路徑，所有輸入數據和驗證所有結果是非常困難的一件事情。我們舉一個簡單的例子，比如說求兩個整數的最大公約數。其輸入信息為兩個正整數。但是如果我們將整個正整數域的數字進行一番測試的話，從其數目的無限性我們便可證明是這樣的測試在實際生活中是行不通的，即便某一天我們能夠窮盡該程序，只怕我們乃至我們的子孫都早已作古了。為此作為軟件測試，我們一般采用等價類和邊界值分析等措施來進行實際的軟件測試，尋找最小用例集合成為我們精簡測試復雜性的一條必經之道。

?  測試具有免疫性（軟件缺陷免疫性）

軟件缺陷與病毒一樣具有可怕的 “ 免疫性 ” ，測試人員對其采用的測試越多，其免疫能力就越強，尋找更多軟件缺陷就更加困難。由數學上的概率論我們可以推出這一結論。假設一個 50000 行的程序中有 500 個軟件缺陷并且這些軟件錯誤分布時均勻的，則每 100 行可以找到一個軟件缺陷。我們假設測試人員用某種方法花在查找軟件缺陷的精力為 X 小時 /100 行。照此推算，軟件存在 500 個缺陷時，我們查找一個軟件缺陷需要 X 小時，當軟件只存在 5 個錯誤時，我們每查找一個軟件缺陷需要 100X 小時。實踐證明，實際的測試過程比上面的假設更為苛刻，為此我們必須更換不同的測試方式和測試數據。該例子還說明了在軟件測試中采用單一的方法不能高效和完全的針對所有軟件缺陷，因此軟件測試應該盡可能的多采用多種途徑進行測試。

?  測試是 “ 泛型概念 ” （全程測試）

我一直反對軟件測試僅存在于程序完成之后。如果單純的只將程序設計階段后的階段稱之為軟件測試的話，需求階段和設計階段的缺陷產生的放大效應會加大。這非常不利于保證軟件質量。需求缺陷、設計缺陷也是軟件缺陷，記住 “ 軟件缺陷具有生育能力 ” 。軟件測試應該跨越整個軟件開發流程。需求驗證（自檢）和設計驗證（自檢）也可以算作軟件測試（建議稱為：需求測試和設計測試）的一種。軟件測試應該是一個泛型概念，涵蓋整個軟件生命周期，這樣才能確保周期的每個階段禁得起考驗。同時測試本身也需要有第三者進行評估（信息系統審計和軟件工程監理），即測試本身也應當被測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。

另外還需指出的是軟件測試是提高軟件產品質量的必要條件而非充分條件，軟件測試是提高產品質量最直接、最快捷的手段，但決不是一個根本手段。

?  80-20 原則

80% 的軟件缺陷常常生存在軟件 20% 的空間里。這個原則告訴我們，如果你想使軟件測試有效地話，記住常常光臨其高危多發 “ 地段 ” 。在那里發現軟件缺陷的可能性會大的多。這一原則對于軟件測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的地到處搜尋。

80-20 原則的另外一種情況是，我們在系統分析、系統設計、系統實現階段的復審，測試工作中能夠發現和避免 80% 的軟件缺陷，此后的系統測試能夠幫助我們找出剩余缺陷中的 80% ，最后的 5% 的軟件缺陷可能只有在系統交付使用后用戶經過大范圍、長時間使用后才會曝露出來。因為軟件測試只能夠保證盡可能多地發現軟件缺陷，卻無法保證能夠發現所有的軟件缺陷。

80-20 原則還能反映到軟件測試的自動化方面上來，實踐證明 80% 的軟件缺陷可以借助人工測試而發現， 20% 的軟件缺陷可以借助自動化測試能夠得以發現。由于這二者間具有交叉的部分，因此尚有 5% 左右的軟件缺陷需要通過其他方式進行發現和修正。

?  為效益而測試

為什么我們要實施軟件測試，是為了提高項目的質量效益最終以提高項目的總體效益。為此我們不難得出我們在實施軟件測試應該掌握的度。軟件測試應該在軟件測試成本和軟件質量效益兩者間找到一個平衡點。這個平衡點就是我們在實施軟件測試時應該遵守的度。單方面的追求都必然損害軟件測試存在的價值和意義。一般說來，在軟件測試中我們應該盡量地保持軟件測試簡單性，切勿將軟件測試過度復雜化，拿物理學家愛因斯坦的話說就是： Keep it simple but not too simple 。

?  缺陷的必然性

軟件測試中，由于錯誤的關聯性，并不是所有的軟件缺陷都能夠得以修復。某些軟件缺陷雖然能夠得以修復但在修復的過程中我們會難免引入新的軟件缺陷。很多軟件缺陷之間是相互矛盾的，一個矛盾的消失必然會引發另外一個矛盾的產生。比如我們在解決通用性的缺陷后往往會帶來執行效率上的缺陷。更何況在缺陷的修復過程中，我們常常還會受時間、成本等方面的限制因此無法有效、完整地修復所有的軟件缺陷。因此評估軟件缺陷的重要度、影響范圍，選擇一個折中的方案或是從非軟件的因素（比如提升硬件性能）考慮軟件缺陷成為我們在面對軟件缺陷時一個必須直面的事實。

?  軟件測試必須有預期結果

沒有預期結果的測試是不可理喻的。軟件缺陷是經過對比而得出來的。這正如沒有標準無法進行度量一樣。如果我們事先不知道或是無法肯定預期的結果，我們必然無法了解測試正確性。這很容易然人感覺如盲人摸象一般，不少測試人員常常憑借自身的感覺去評判軟件缺陷的發生，其結果往往是把似是而非的東西作為正確的結果來判斷，因此常常出現誤測的現象。

?  軟件測試的意義 - 事后分析

軟件測試的目的單單是發現缺陷這么簡單嗎？如果是 “ 是 ” 的話，我敢保證，類似的軟件缺陷在下一次新項目的軟件測試中還會發生。古語說得好， “ 不知道歷史的人必然會重蹈覆轍 ” 。沒有對軟件測試結果進行認真的分析，我們就無法了解缺陷發生的原因和應對措施，結果是我們不得不耗費的大量的人力和物力來再次查找軟件缺陷。很可惜，目前大多測試團隊都沒有意識到這一點，測試報告中缺乏測試結果分析這一環節。

結論：

軟件測試是一個需要 “ 自覺 ” 的過程，作為一個測試人員，遇事沉著，把持尺度，從根本上應對軟件測試有著正確的認識，希望本文對讀者對軟件測試的認識有所幫助