軟件測試的目標：失敗等于成功[2] 軟件測試
理解產品是如何工作的--和為何可能出故障
對一些測試者來說，第一個想做的就是看產品外在的可見的“行為”--將精力集中在他們的產品客戶將看到的部分。這樣做效力有限，因為他們沒有清楚的理解產品程序的邏輯，數據流等等，這些是用戶不可見的。為了能夠理解產品是如何工作的，以及怎樣會出故障，你必須看“罩子下面”并且在你的測試中用到你看到的東西。
例如，如果你只看一個GUI，你可能看到程序通過一個格式化的HTML表格顯示一個特定的數據庫查詢的結果。然而，除非你知道這個表格的表示是一個Java數組對象，從服務器傳到客戶端，然后轉化為一個HTML表格，否則你就不會知道這里存在一個潛在的一個客戶端性能瓶頸的危險。如果一個用戶運行一個查詢，返回的記錄太多，就會導致客戶端在處理表格的時候像死機一樣。(我在幾年前是通過這樣的方法解決這個問題的：每次讓客戶端只接收一部分結果數據，并且明確地告訴用戶還有其他的數據未傳過來。)
如果有充足的時間設計和進行測試，你總是可以找到更多的bug。然而，如果那個bug好像對你的客戶影響不大，那就不值得花時間和精力去找到它。去搜索每一個可能導致系統在5,000年發生一次故障的bug是沒有意義的，因為那可能需要你花5,000年去運行所必要的測試。3 花時間去找出哪里可能藏有真正有影響的bug，并將測試集中于那些地方，會好很多。
理解客戶究竟會怎樣去使用產品
之前，我間接提到了通過直接接觸實際用戶或者通過你公司用戶服務部門去了解用戶需求的重要性。通過同樣的渠道，你也應該確認你的測試計劃是否反映了你用戶的系統配置，特殊需求以及吞吐/系統能力需求。
這也需要了解你的客戶的條件限制，這些限制將直接影響用戶怎樣使用你的產品。在我加入Rational之前，我的工作是有關一個Internet防火墻，它能夠支持常被稱之為“split-brained DNS”功能網絡配置功能。這個功能使用戶能夠在他們的防火墻后面維護一個私有的DNS服務器。然而我們發現，一些內部DNS服務器被錯誤的配置了，在我們沒有更正他們的DNS 配置之前，無法使防火墻正常工作。最后我們不得不更改我們的安裝工具使得即使在用戶的內網斷了的情況下防火墻仍能夠正常運行。這樣我們就可以把修理他們的網絡當做一個獨立的(收費的)任務。
現在讓我們轉到第二個誤解。如果我們接受了bug-free軟件真的是不存在的這一觀念，我們可以通過運行測試找到故障，那么我們要測試到出故障，對嗎?但是如果測試中出故障是一個好事情，那么我們是否能夠把它叫做“失敗”呢?
誤解2：軟件測試的目的是為了驗證軟件能夠正常運轉
和第一個誤解一樣，這個說法也反映了一個對軟件測試完全樂觀的觀點。在我們一生的活動中，我們盡力去創造和建造能夠正常運行的事物，我們盡我們最大的努力去避免故障。然而，軟件測試人員必須有不同觀念：為了能夠成功，我們必須有意地盡量去促使故障的產生。4
如果我們不采用“不正當的”方法會發生什么?如果我們設計避免故障的測試，那么將會使我們的客戶失望。當你開發一個軟件應用程序的時候，你會清楚地了解應用程序所使用的數據類型，配置以及它能運行所需要的環境。你也知道程序的局限性。如果你的目標是驗證應用程序能夠工作，你就會限制你在數據、配置和應用程序最初設計所支持環境的邊界處測出故障的可能。如果你這樣做，你有較大的機會通過你所有的測試。然而在現實世界中，你的客戶很有可能會超越這些邊界并遇到你測試中沒有測出來的bug。
下面是一些要成為一個好的測試者所需要的可以使用的建議。
如果產品出現了故障，你就進行了一個成功的測試。
如果你在頭腦中保持測試的目標是為了發現一個bug這一觀念，那么你就可以開始考慮一個“成功”的測試就是讓軟件運行出現故障。不論你只是運行了一個測試還是運行了成千上萬次測試，即使你沒有發現bug，你的軟件仍然不能說沒有bug。bug仍然潛伏在測試沒有覆蓋到的領域。換句話說，要證明沒有bug是一件非常困難的事情，并且，我們前面提到過，你必須集中力量去找到產品中危險最大的領域中的bug。
不久前，我接受了一個產品的測試任務，在我之前這個產品已經經過了成百上千次測試。產品出來以后，他們所有人對產品的一些過去投入了幾年的工作的組件進行測試。然而，他們的測試很少甚至沒有涉及到感興趣的測試領域。雖然這種回歸測試有利于驗證新代碼的變更沒有導致一些舊的函數無法運行，但是我不得不在可能導致麻煩的區域設計新的測試。在 軟件測試的藝術，5 一書中，Glenford Myers用了一個醫學上的類比，如果你覺得不舒服去醫院檢查，但檢查的結果并不足以診斷病因，那能夠說這個檢查是“成功”的嗎?不!你還是有病，你的醫生必須再進行正確的檢查。
文章來源于領測軟件測試網 http://www.k11sc111.com/