軟件測試的真正目標是什么？

軟件測試的真正目標是什么？為了研究這個問題，我隨機問了一些軟件開發和測試工程師、管理人員。其中一些說目標是驗證軟件是否滿足用戶和產品的需求。其他的人給出了更簡單的回答，例如：“確認軟件沒有Bugs”以及“為了驗證軟件能夠正常運轉”。 就我看來，這些說法都不準確。簡單來說，軟件測試的真正目的是找到以前沒有發現的bug。

1 下面我將從我對軟件測試目標的看法出發，剖析我同事關于軟件測試的主要目標的誤解，并給測試人員一些建議。 

誤解1：軟件測試的目的是為了確保沒有Bug

　　這種看法反映了一種對于軟件本質的樂觀但從根本上錯誤的觀點。一個簡單的事實就是不存在“bug-free”的軟件。 

　　為什么是這樣呢？首先，在等式的開發一邊，你必須面對時刻在變化的技術，一個復雜的而且經常有缺陷的應用設計，集成新的已存在的系統帶來的困難，等等。人本身的錯誤也是一個很大的因素。雖然現代思維應用開發工具可以自動生成代碼，但是在有些地方人必須參與到開發過程中，而人是會犯錯誤的。

　　而在等式的測試這一邊，不可能讓你的產品在送到你的用戶以前運行所有可能的測試來檢測出每一個可能的bug。讓我們來看一個簡單的假定的例子。比如說你要測試一個這樣的程序： 

　　接受3個整型的數值作為輸入，每一個數值的范圍在0到9之間。在2種操作系統下運行?？梢栽L問存儲在3個不同廠商中任何一個提供的數據庫中的數據。我們計算一下，我們有1,000種可能的排列作為測試輸入。為了測試在每個操作系統上的每種排列，我們需要2,000個測試用例，另外再考慮到每種輸入在每個支持的數據庫運行一遍，我們需要6,000個測試用例。這個數字還沒有考慮到其他的測試情況，例如網絡故障，磁盤空間不足以及內存耗盡等等。所以實際上我們需要測試用例的數目要更大一些。 

　　無疑，我們不得不接受這樣一個事實：我們只能生活在一個所有的軟件都有bug的世界當中。然而，我們沒有必要絕望。經過精心的計劃，我們可以選擇性地找出產品中最多出現危險以及對我們的用戶最重要的部分中的bug。下面是我發現的有效的一些步驟。

　　在你的計劃當中加入風險分析

　　正確理解你的客戶需求文檔本身就是一門科學（后面將會詳細講到）。如果你不能直接接觸到你的用戶－－例如，通過客戶焦點小組，那么你就應該和你的客戶支持部門一起商討你的測試計劃，因為他們直接接觸到最終用戶。

　　要明白你的產品哪些部分處于危險當中同樣需要分析。變更是危險的主要來源；如果你引入了一個變更，你可能不注意地引入了一個新的bug或者發現一個已經存在的bug。因此，支持新功能的代碼一直是一個尋找危險的好地方。為了修正一個bug而修改的代碼也是這樣。而且，如果你在某個地方發現了bug，那么在附近潛藏著其他bug的可能性就很大。雖然你可能認為經過多年修正了很多bug的地方最后“清除干凈了”，這種想法只是在修正時發現了bug的根源的情況下才是正確的。如果bug的根源是糟糕的設計，而進行的修正只是一個簡單的補丁而不是從根本上解決這個問題，那么這個修正實際上可能引入了新的bug。另外，記?。杭词故腔凇案驹颉钡男拚灿锌赡軙l基礎性變更，暴露其他嚴重bug。 

　　理解產品是如何工作的－－和為何可能出故障

　　對一些測試者來說，第一個想做的就是看產品外在的可見的“行為”－－將精力集中在他們的產品客戶將看到的部分。這樣做效力有限，因為他們沒有清楚的理解產品程序的邏輯，數據流等等，這些是用戶不可見的。為了能夠理解產品是如何工作的，以及怎樣會出故障，你必須看“罩子下面”并且在你的測試中用到你看到的東西。 [Page]

　　例如，如果你只看一個GUI，你可能看到程序通過一個格式化的HTML表格顯示一個特定的數據庫查詢的結果。然而，除非你知道這個表格的表示是一個Java數組對象，從服務器傳到客戶端，然后轉化為一個HTML表格，否則你就不會知道這里存在一個潛在的一個客戶端性能瓶頸的危險。如果一個用戶運行一個查詢，返回的記錄太多，就會導致客戶端在處理表格的時候像死機一樣。（我在幾年前是通過這樣的方法解決這個問題的：每次讓客戶端只接收一部分結果數據，并且明確地告訴用戶還有其他的數據未傳過來。） 

　　如果有充足的時間設計和進行測試，你總是可以找到更多的bug。然而，如果那個bug好像對你的客戶影響不大，那就不值得花時間和精力去找到它。去搜索每一個可能導致系統在5,000年發生一次故障的bug是沒有意義的，因為那可能需要你花5,000年去運行所必要的測試。3 花時間去找出哪里可能藏有真正有影響的bug，并將測試集中于那些地方，會好很多。 

　　理解客戶究竟會怎樣去使用產品

　　之前，我間接提到了通過直接接觸實際用戶或者通過你公司用戶服務部門去了解用戶需求的重要性。通過同樣的渠道，你也應該確認你的測試計劃是否反映了你用戶的系統配置，特殊需求以及吞吐/系統能力需求。 

原文轉自：http://www.anti-gravitydesign.com