軟件測試工作的三重境界(3)

　　首先，分析在我們的軟件系統中，哪些功能對用戶來說是核心且重要的功能，然后安排合適的測試工程師負責這些模塊。設計出的測試方案、用例進行重點評審，測 試執行過程重點跟蹤。每一次軟件版本發布時，即使沒有更改此部分的代碼，也對它們進行回歸測試(這種回歸需講究策略與方法)，因為它們太重要了，不允許有錯誤。

　　下面是軟件測試2-8原則的詳細內容。

　　1.80%的錯誤是由20%的模塊引起的

　　簡單、容易的模塊或功能是很少引入過多Bug的，而對于存在復雜邏輯的一些關鍵模塊往往會引起系統80%的錯誤。只有關鍵模塊穩定了，整個系統才可能真正的健壯和穩定。

　　這個原則對于測試來說就是站在用戶角度(而不是研發實現的角度)，正確地選擇重要功能模塊作為測試的重點，不偏離方向。

　　2.80%的測試成本花在20%的軟件模塊中

　　設計測試用例時，常會用日產多少條用例來衡量工程師的工作。用例的多少與需求量有關，而影響軟件架構設計的需求描述往往是比較少的。在這種情況下，設計測 試用例時特別需要結合軟件的概要設計、詳細設計一起考慮。如果用例設計人員為了達到用例的數量，通過大量復制用例，修改個別字眼，而沒有真正去設計高效的 測試用例，那么用如此低效甚至更多的用例數量來對待復雜的20%的核心模塊，在測試執行過程中必將導致一部分關鍵Bug找不出來。

　　3.80%的測試時間花在20%的軟件模塊中

　　對于復雜的模塊，前期的測試設計和思考可能會耗費大量時間，而產出的用例量可能并不大。對于復雜的系統，特別是對于全新系統，必須舍得投入充足的時間來優先考慮設計，前期方案、用例設計的時間越短，后期的風險越大。

　　在項目進展到一定階段后，增加人力并不一定能解決縮短時間的問題。例如，如果復雜且核心模塊在項目的后期才開始執行測試，由于Bug較多，而項目又需要短 時間把版本穩定下來，通常的做法是加人。然而加入的新兵需要一段時間的熟悉期，必要時還需要老兵來帶，這本身又會影響到老兵的工作。另外一些性能測試、自動化測試工作也只有等版本穩定后才會有更好的效果。

　　測試的第三重境界：挑戰零缺陷

　　孔子說“人無遠慮，必有近憂”，用在軟件測試上，是什么意思呢?可以這樣理解，如果我們不從發生問題的根源上解決問題，認為測試僅僅是找Bug，千方百計找Bug，覺得Bug總是找不完，意識中就會陷入“永無天日”的狀態。然而，有小部分測試人員還真希望軟件存在多一些問題(唯恐天下不亂)，這樣可以多提交Bug，認為業績比沒有提交多少Bug肯定要好。無獨有偶，有小部分開發人員也把自己犯下的程序錯誤視為理所當然，甚至還有個別人會戲虐地說“軟件如果沒有Bug的話，測試人員不就失業了”。這好像在唱一出雙簧戲。軟件開發的整個過程中，Bug是理所當然要存在的，是這樣嗎?軟件工程中軟件危機的根源問題只能通過找到Bug的手段來控制嗎?

　　實際上，我們都很清楚，任何一個Bug的產生都是有來源的，來源包括需求的設計、軟件的設計(含代碼的編寫)等。相對于前端的設計，測試是事后的驗證，是一種“堵”漏洞的措施。然而，在實際工作中，時間與成本并不允許我們去堵住所有的Bug。日本質量大師田口玄一說得好“質量是設計出來的，而不是測試出來的”。如果我們能變被動為主動，在設計之前，就做好設計的防患措施，為設計高質量的軟件打下堅實的基礎，這便是本節打算向讀者介紹的測試的第三重境界：挑戰零缺陷。

　　1、缺陷的防與堵

　　幾乎在每次面試測試工程師時，筆者都會問一個這樣的問題：“你所負責測試過的模塊，是否存在漏測的情況”，幾乎每個應聘者都回答說“有”。面對復雜的軟件，紛繁復雜的運行環境，在有限時間內進行的測試活動，做到真正的零Bug是 不可能的，也是不現實的。但這些都不是理由，所有的測試活動是有目的的商業活動，每個公司有自己測試通過的一套標準或原則。雖然漏測不可避免，但并不是說 漏測是一種正?，F象或應該的現象，出現的漏測問題如果超出公司所能接受的原則，就屬于不正常的現象，很有必要進行漏測分析。進行漏測分析活動(需要特別注 意的是它絕不是對漏測人員的批斗會)，它的主要目的是通過分析過去的教訓，找出問題的根源，分析測試中哪個環節工作存在缺失，以拿出規避的可操作的措施出來。

原文轉自：http://www.uml.org.cn/Test/201306184.asp