如果有充足的時間設計和進行測試，你總是可以找到更多的bug。然而，如果那個bug好像對你的客戶影響不大，那就不值得花時間和精力去找到它。去搜索每一個可能導致系統在5,000年發生一次故障的bug是沒有意義的，因為那可能需要你花5,000年去運行所必要的測試�；〞r間去找出哪里可能藏有真正有影響的bug，并將測試集中于那些地方，會好很多。
理解客戶究竟會怎樣去使用產品
之前，我間接提到了通過直接接觸實際用戶或者通過你公司用戶服務部門去了解用戶需求的重要性。通過同樣的渠道，你也應該確認你的測試計劃是否反映了你用戶的系統配置，特殊需求以及吞吐/系統能力需求。
這也需要了解你的客戶的條件限制，這些限制將直接影響用戶怎樣使用你的產品。在我加入Rational之前，我的工作是有關一個Internet防火墻，它能夠支持常被稱之為“split-brained DNS”功能網絡配置功能。這個功能使用戶能夠在他們的防火墻后面維護一個私有的DNS服務器。然而我們發現，一些內部DNS服務器被錯誤的配置了，在我們沒有更正他們的DNS 配置之前，無法使防火墻正常工作。最后我們不得不更改我們的安裝工具使得即使在用戶的內網斷了的情況下防火墻仍能夠正常運行。這樣我們就可以把修理他們的網絡當做一個獨立的(收費的)任務。
現在讓我們轉到第二個誤解。如果我們接受了bug-free軟件真的是不存在的這一觀念，我們可以通過運行測試找到故障，那么我們要測試到出故障，對嗎?但是如果測試中出故障是一個好事情，那么我們是否能夠把它叫做“失敗”呢?
誤解2：軟件測試的目的是為了驗證軟件能夠正常運轉
和第一個誤解一樣，這個說法也反映了一個對軟件測試完全樂觀的觀點。在我們一生的活動中，我們盡力去創造和建造能夠正常運行的事物，我們盡我們最大的努力去避免故障。然而，軟件測試人員必須有不同觀念：為了能夠成功，我們必須有意地盡量去促使故障的產生。
如果我們不采用“不正當的”方法會發生什么?如果我們設計避免故障的測試，那么將會使我們的客戶失望。當你開發一個軟件應用程序的時候，你會清楚地了解應用程序所使用的數據類型，配置以及它能運行所需要的環境。你也知道程序的局限性。如果你的目標是驗證應用程序能夠工作，你就會限制你在數據、配置和應用程序最初設計所支持環境的邊界處測出故障的可能。如果你這樣做，你有較大的機會通過你所有的測試。然而在現實世界中，你的客戶很有可能會超越這些邊界并遇到你測試中沒有測出來的bug。
下面是一些要成為一個好的測試者所需要的可以使用的建議。
如果產品出現了故障，你就進行了一個成功的測試。
如果你在頭腦中保持測試的目標是為了發現一個bug這一觀念，那么你就可以開始考慮一個“成功”的測試就是讓軟件運行出現故障。不論你只是運行了一個測試還是運行了成千上萬次測試，即使你沒有發現bug，你的軟件仍然不能說沒有bug。bug仍然潛伏在測試沒有覆蓋到的領域。換句話說，要證明沒有bug是一件非常困難的事情，并且，我們前面提到過，你必須集中力量去找到產品中危險最大的領域中的bug。
不久前，我接受了一個產品的測試任務，在我之前這個產品已經經過了成百上千次測試。產品出來以后，他們所有人對產品的一些過去投入了幾年的工作的組件進行測試。然而，他們的測試很少甚至沒有涉及到感興趣的測試領域。雖然這種回歸測試有利于驗證新代碼的變更沒有導致一些舊的函數無法運行，但是我不得不在可能導致麻煩的區域設計新的測試。在 軟件測試的藝術， 一書中，Glenford Myers用了一個醫學上的類比，如果你覺得不舒服去醫院檢查，但檢查的結果并不足以診斷病因，那能夠說這個檢查是“成功”的嗎?不!你還是有病，你的醫生必須再進行正確的檢查。
所有的使用者都會犯錯誤
在測試一個新的軟件應用程序的時候，看到不好的測試結果的人肯定要反對你的測試場景�！皼]有人會那樣做!”。不要相信沒有這個。一些用戶會那樣做，或者做一些更糟的事情，并且他們不是有意那樣。你的工作就是在產品運送到客戶手里以前，考慮用戶會犯的錯誤中最壞的情況，并且確認你的產品仍然能夠安然無恙，沒有崩潰或者丟失數據。再說一遍，你要尋求的是那些能夠發現危險bug的測試故障。
讓我們再看一下我們之前討論的簡單程序，那個需要6,000次測試才能包括所有可能的程序。如果你要設計只在合法的輸入，環境，操作等情況下的測試，那么你的測試只涵蓋了對你系統運行來說最好的場景。但是，如果有些地方出錯會怎樣?如果用戶手指滑了一下，或者錯誤的配置了什么，或者刪除了非常重要的信息，你的軟件會怎樣表現?或者當一個系統/服務器出現掛起，或者出現達到一些資源的上限(比如內存，磁盤空間，數據庫記錄的ID等)，會發生什么?當一些應該被標識為損壞的數據進入或者通過系統會怎么樣?如果操作中斷，系統處于含糊不清的狀態?或者如果太多的人在同樣的時間做同樣的事情?潛在錯誤的列表是無限的，并且如果你只想確認“它可以工作”的話，你可能就會忽略掉這些場景中的大部分。
結論
我希望這篇文章可以讓你確信軟件測試的真正目標是尋找bug。即使是在交付時間表很緊的情況下，采取一個步驟來想一下從哪里開始著手，你的測試將會是最有效率的。但即使在時間非常充足的情況下，你也不可能測試出每一個bug，所以你必須將你的測試劃分優先級，劃分的根據是基于產品目前的狀態(新的，修改的或者只是純漏洞)和對客戶的可能影響而進行的最誠實的評估。避免采用你知道軟件可以處理的測試數據和操作;你的任務是在測試中擴大軟件的邊界。在你設計自動化測試時，也要避免“踩滅”失敗條件的誤區。你的任務不是創造大量的總是可以干凈的成功運行的測試。你需要去尋找和理解故障條件。不要浪費時間去想你的軟件產品中是否存在bug。它肯定有bug，并且你不可能全部找出它們。你的組織和你的顧客指望你找出那些最有影響的bug。你必須要做的是，你要從消極的角度考慮這些問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
