首先應該明確的是，測試人員的職責是“軟件質量”�；镜墓ぷ魇�，根據一定的方法和邏輯，尋找或者發現軟件中的缺陷，通過這個過程來證明軟件的質量是優秀的，還是低劣的。所以，往往發現缺陷，成為很多測試人員關注的焦點。但是，事實上，我們還應該對缺陷進行分類統計，從綜合的角度考慮軟件的質量問題。
現在和大家分享一下如下的規則給我們測試工作帶來的指導意義。
規則 1：發現的缺陷的數量說明不了軟件的質量。
軟件中不可能沒有缺陷，發現很多的缺陷對于測試工作來說，是件很正常的事。缺陷的數量大，只能說明測試的方法很好，思路很全面，測試工作有成效。但是，以此來否認軟件的質量，還比較的武斷。
如果，測試中發現的這些缺陷，絕大多數都是屬于提示性錯誤、文字錯誤等，錯誤的等級很低，而且這些缺陷的修改幾乎不會影響到執行指令的部分，而軟件的基本功能或者是性能，發現很少的缺陷，很多時候，這樣的測試證明的是“軟件的質量是穩定的”，因而它屬于優秀的軟件的范疇。這樣的軟件，只要處理好發現的缺陷，進行一下返測，基本就可以發行使用了；進行完整的回歸，就是增加軟件的成本，浪費商機和時間。
反過來，如果在測試中發現的缺陷比較少，但是這些缺陷都集中在功能沒有實現，性能沒有達標，動不動就引起死機、系統崩潰等現象，而且，在大多數的用戶在使用的過程中都會發現這樣的問題，這樣的軟件不會有人輕言“發布”的，因為他承擔的風險太大了。
雖然，這兩個例子都比較的極端，在實際的測試中，幾乎不會發生，但是，提出來，是希望從事測試工作的同行們，不要把自己的工作集中在發現缺陷的問題上。
規則 2：缺陷要分類統計
看一下，筆者在實際的測試過程中得到的一組缺陷的統計的柱狀圖：（見第一幅圖）
它說明的是，在某些模塊，執行的測試用例多，但是沒有成比例的發現很多缺陷，所以這些模塊是比較成熟的，因為在這些模塊幾乎不怎么修改，再測試的話，也不會發現什么問題的；但是某些模塊執行的測試少，卻發現了更多的缺陷，這些模塊修復的地方，或者發生功能變更的可能性大，所以將成為質量不穩定的關鍵點。
如果，你是一個軟件質量管理人員，你就應該明白的是，在以后的回歸測試中，應該在質量不穩定的模塊中投入更多的人手和時間，進行更全面的測試，其它模塊就相應減少測試工作的投入。這樣，測試工作的壓力就不是那么大了，而且效率也相對提高了。
規則 3：不要指望找出軟件中所有的缺陷
很多人都知道這個道理，但是卻不明白這個規則給軟件測試工作的意義。它其實是在指導我們，該在什么時候停止軟件測試，發布軟件。
我們再來看一組數據：（見第二幅圖）
這個缺陷趨勢分析圖，說明了，軟件在測試版本的 Ver 1.4的時候，軟件的質量已經得到了很好的控制了，在 Ver 1.8的時候，基本上就已經可以發布軟件了，后面的測試幾乎是沒有什么意義的。原因很簡單，軟件中的缺陷既然是不可能全部發現的，就不要指望找出軟件中全部的缺陷，當它足夠少（各公司的定義是不同的）的時候，就應該停止測試了。
規則 4：只依賴缺陷的趨勢也可能有問題
缺陷固然是在減少，但是是不是所有模塊的缺陷都在減少呢？是不是所有級別的缺陷都在減少呢？而且它們也符合你的期望呢？
同樣是上面一組數據，我們換個角度統計，看看又會怎么樣？（見第三幅）
可能眼睛看得很花，沒有關系，我想你至少能夠看到的是，各模塊之間，不同的階段都會發現缺陷突然變多，這就是統計各模塊的時候，發現的各模塊的缺陷趨勢。它給我們的信息是，軟件不同階段，各模塊的質量和軟件整體的質量是不對稱的。雖然缺陷在不斷的減少，但是一些關鍵的模塊，尤其是風險分析中風險值比較大的模塊，仍然是質量不穩定的，這樣的軟件可能可以算優秀的軟件，因為缺陷的絕對值可能真的很小了，但是，也同時是風險大的軟件。
這個缺陷趨勢分析圖，說明了，軟件在測試版本的 Ver 1.4的時候，軟件的質量已經得到了很好的控制了，在 Ver 1.8的時候，基本上就已經可以發布軟件了，后面的測試幾乎是沒有什么意義的。原因很簡單，軟件中的缺陷既然是不可能全部發現的，就不要指望找出軟件中全部的缺陷，當它足夠少（各公司的定義是不同的）的時候，就應該停止測試了。
規則 4：只依賴缺陷的趨勢也可能有問題
缺陷固然是在減少，但是是不是所有模塊的缺陷都在減少呢？是不是所有級別的缺陷都在減少呢？而且它們也符合你的期望呢？
同樣是上面一組數據，我們換個角度統計，看看又會怎么樣？（見第三幅）
可能眼睛看得很花，沒有關系，我想你至少能夠看到的是，各模塊之間，不同的階段都會發現缺陷突然變多，這就是統計各模塊的時候，發現的各模塊的缺陷趨勢。它給我們的信息是，軟件不同階段，各模塊的質量和軟件整體的質量是不對稱的。雖然缺陷在不斷的減少，但是一些關鍵的模塊，尤其是風險分析中風險值比較大的模塊，仍然是質量不穩定的，這樣的軟件可能可以算優秀的軟件，因為缺陷的絕對值可能真的很小了，但是，也同時是風險大的軟件。
諸如此類的規則，其實還有很多的，例如：修改一個缺陷，可能引入了更多更深的缺陷；軟件測試中的“二八定律”等等。
很多公司都有嚴格的缺陷分類和管理制度，并在此基礎上對軟件產品的發布標準，都有具體的要求。例如：產品在發布的時候，一般都會要求，各模塊致命的缺陷不得有 2個，嚴重的缺陷不得超過 5個，輕微的缺陷不能多于 5個，殘留的缺陷總數不得多于 10個等。
這些看似簡單的規定，其實是經歷了很多人長期的努力才總結出來的經驗，他們大多來源于一些事故，但是現在，卻直接指導著我們的測試工作，無疑對減少軟件測試工作的壓力和工作量都提供了足夠充分的理論依據。
綜合的講，筆者在這里的建議僅僅只是希望，即將進入或者已經進入軟件測試行業的兄弟姐妹們，不要只關心如何發現軟件中的缺陷，還應當對這些缺陷進行分類的跟蹤、管理和分析，并從這些已經存在的數據中，找到一些對我們的軟件測試工作有意義的指導，這才是缺陷跟蹤分類、統計、跟蹤管理的意義。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
