孔子說“人無遠慮，必有近憂”，用在軟件測試上，是什么意思呢？可以這樣理解，如果我們不從發生問題的根源上解決問題，認為測試僅僅是找Bug，千方百計找Bug，覺得Bug總是找不完，意識中就會陷入“永無天日”的狀態。然而，有小部分測試人員還真希望軟件存在多一些問題（唯恐天下不亂），這樣可以多提交Bug，認為業績比沒有提交多少Bug肯定要好。無獨有偶，有小部分開發人員也把自己犯下的程序錯誤視為理所當然，甚至還有個別人會戲虐地說“軟件如果沒有Bug的話，測試人員不就失業了”。這好像在唱一出雙簧戲。軟件開發的整個過程中，Bug是理所當然要存在的，是這樣嗎？軟件工程中軟件危機的根源問題只能通過找到Bug的手段來控制嗎？
實際上，我們都很清楚，任何一個Bug的產生都是有來源的，來源包括需求的設計、軟件的設計（含代碼的編寫）等。相對于前端的設計，測試是事后的驗證，是一種“堵”漏洞的措施。然而，在實際工作中，時間與成本并不允許我們去堵住所有的Bug。日本質量大師田口玄一說得好“質量是設計出來的，而不是測試出來的”。如果我們能變被動為主動，在設計之前，就做好設計的防患措施，為設計高質量的軟件打下堅實的基礎，這便是本節打算向讀者介紹的測試的第三重境界：挑戰零缺陷。
缺陷的防與堵
幾乎在每次面試測試工程師時，筆者都會問一個這樣的問題：“你所負責測試過的模塊，是否存在漏測的情況”，幾乎每個應聘者都回答說“有”。面對復雜的軟件，紛繁復雜的運行環境，在有限時間內進行的測試活動，做到真正的零Bug是 不可能的，也是不現實的。但這些都不是理由，所有的測試活動是有目的的商業活動，每個公司有自己測試通過的一套標準或原則。雖然漏測不可避免，但并不是說 漏測是一種正常現象或應該的現象，出現的漏測問題如果超出公司所能接受的原則，就屬于不正常的現象，很有必要進行漏測分析。進行漏測分析活動（需要特別注 意的是它絕不是對漏測人員的批斗會），它的主要目的是通過分析過去的教訓，找出問題的根源，分析測試中哪個環節工作存在缺失，以拿出規避的可操作的措施出 來。
測試人員進行漏測分析時，免不了對問題進行追本溯源。軟件是由開發人員設計出來的，所以漏測分析活動少不了開發人員在場，甚至有時還會涉及需求設計人員。關于漏測分析的追本溯源，這里有一個關于開發與測試之間的工作關系像修筑堤壩一樣的有趣比喻，如圖2？11所示。開發人員設計軟件就像修筑一道堤壩，如果堤壩在結構上存在問題，當洪水沖擊時，可能不只是局部的泄漏，而是直接的決堤，猶如軟件的崩潰。高高的堤壩，難免會存在漏水的小洞，或滲水的小孔，就好像軟件中存在的小Bug。越是在堤壩基部的漏水或滲水問題越難發現，解決的代價也越大。
在設計時要把結構建牢，不存在漏洞當然更好，這是一種防范。如果超越防范界線，把設計帶出的大洞小孔遺留到測試環節，它只好拿著各種放大鏡（使用各種方法）來檢測，以網羅各種深深淺淺、大大小小的問題，最后通過“打補丁”的方式，堵住堤壩上的“百孔千瘡”。
在對缺陷的防與堵方面，測試是發現問題的中間角色，告訴開發人員哪里漏水或滲水了。防與堵的工作是由建堤者來做的。當然，防是主動的，堵是被動的，主動變為被動后，中間經歷了資源與時間的投入，誠然即使是同一個Bug，它們的代價也是完全不一樣的。這種堵越在后面，影響越大，代價也就越大，如表2-6所示（摘自《代碼大全》）是一個根據缺陷出現的階段來增加測試成本的例子。
表2-6 根據缺陷的引入和檢測時間，修正同一缺陷所需的平均成本
引 入 時 間 | 需 求 | 體 系 結 構 | 建 設 | 系 統 測 試 | 發 布 之 后 |
需求 | 1 | 3 | 5～10 | 10 | 10～100 |
體系結構 | -- | 1 | 10 | 15 | 25～100 |
建設 | -- | -- | 1 | 1 | 10～25 |
如表2-6所示為在需求階段引入的一個缺陷。如果立即發現了此問題，修改成本只需要1美元，但如果在系統測試階段發現它，修改成本就增加了10倍。更為嚴重的是，如果在版本發布后用戶端發現了此問題，則需付出10倍以上甚至是100倍的代價。缺陷在系統中的時間越長，解決它的代價就越大，因為時間越長，開發與測試人員修改的成本就越高，還將影響大面積的用戶端升級。
相關鏈接：
軟件測試的第一重境界：圍著Bug轉
軟件測試的第二重境界：站在Bug之上