測試覆蓋率之三——測試覆蓋率100%相關的話題 軟件測試工具
上一篇文章中，介紹了測試覆蓋率的意義之類的東西。測試覆蓋率可以幫助我們檢查測試質量，檢查測試用例的有效率。如果有興趣的話，可以閱讀測試覆蓋率之二——測試覆蓋率有什么用?
關于測試覆蓋率，我個人的感覺是說的多，用的少。最近在網絡上看到一篇文章，討論一個問題“測試需要100%的覆蓋率嗎?”被轉載了很多次，有興趣的同行可以找來看看。的確，一想到測試覆蓋率，立馬就有完美主義者跳出來說100%。100%的測試覆蓋率有什么好處呢?
1、100%的覆蓋率表示我們的測試覆蓋到了所有語句，分支，條件 軟件測試
2、100%的覆蓋率表示我們測試考慮的很完全，我們可以回去睡大覺了~~
測試仿佛在這里變得不那么可怖了，但是我們至少遺漏了兩個重要的地方：怎么達到100%的測試覆蓋率或者說是否能夠達到100%的測試覆蓋率，另外一個就是100%的測試覆蓋率到底能告訴我們什么信息。
首先來講，我們是否可以達到100%的測試覆蓋率?如果我們簡單的將測試覆蓋率理解為需求覆蓋率，代碼覆蓋率，那么我想這是可以達到的，只要擁有足夠的時間，我們的測試覆蓋到每一個需求點，我們的測試覆蓋到每一條語句，每一個條件，每一個分支，看起來的確沒有問題。但是我們還要考慮另外一個問題，是否由我們未曾列入到需求分析中的需求呢，這種情況是存在的，如果我們計算需求覆蓋率是根據Feature Spec來的(實際上如果我們需要計算的話，一般就是這樣計算得來的)，那么當我們有需求沒有被寫入Feature Spec并且我們也沒有在測試中考慮相關的測試，那么我們實際的“需求覆蓋率”就不是100%了。在實際開發過程中，是不可能在Feature Spec中將需求全部列出來的，所以我們得到的100%的需求覆蓋率是存在水分的。
另外，對于一個應用程序(除了一些極其簡單的程序)來講，要覆蓋到所有的語句。條件，分支是極其困難的，甚至可以說是不可能的。筆者在經歷的一個項目中花了一整天寫一個模塊的單元測試，當我忙完一天并運行了所有的用例之后，我發現我的代碼覆蓋率僅僅增加了2%，而且是從35%到37%，不要說100%，連80%我當時都覺得是奢望。
對于第二個問題，100%的測試覆蓋率能代表什么?我在上面講到，100%的測試覆蓋率表示覆蓋到了所有的語句，分支和條件，但是這又說明什么呢?這是否說明了我們做到了完全測試一個軟件呢?很抱歉，答案是否定的。給出下面這一段代碼：
private int add(int a，int b)
{
return a+b;
}
夠簡單的一段代碼了吧，我們可以很輕松的達到100%的覆蓋率，比如我們使用用例 add(3，4)就可以覆蓋所有的語句，分支，條件(當然這里面是不存在分支和條件的，所以只需要覆蓋語句就可以達到代碼覆蓋率100%了)，但是聰明的你一定會發現我們的測試遠遠不夠：如果輸入的是add(2147483647，2)，這個應用程序是會出現問題的，如果我們僅僅滿足于100%的代碼覆蓋率，是不能保證我們的軟件的質量的。
關于代碼覆蓋率，由一個很有趣的現象：高覆蓋率有時候比低覆蓋率還“沒用”。注意“沒用”是打了引號的，我的意思是高覆蓋率不能說明我們做了完全的測試，低覆蓋率卻可以說明我們測試遠遠不夠，從這一點來講，低覆蓋率似乎更有意義。當然我不是在講我們不去追求高覆蓋率，我的意思是與其把A模塊覆蓋率從85% 提高到90%，還不如把與其類似的B模塊的覆蓋率從30%提高到50%更有意義。繞一大圈說回來，在任何時候高覆蓋率都比低覆蓋率好，但是作為一個軟件，我們要顧及軟件整體的測試質量，我們還要估計成本，時間等等很多問題。
上面說了不少，最后總結一下我的觀點：
1、測試覆蓋率100%是一個理想的情況，是很難達到的;
2、測試覆蓋率100%不能說明我們做了完全的測試;
3、較低的測試覆蓋率能說明我們的測試還不夠，反之是不成立的，參考第二條;
4、同一模塊高覆蓋率相對于低覆蓋率能說明我們做了更多的測試;
5、測試覆蓋率達到多少要考慮到軟件整體的覆蓋率情況，以及項目成本，包括人力，時間等等。
個人觀點，僅供參考。
關于測試覆蓋率100%的問題的討論還會繼續下去，如果必要的話，筆者將在本系列文章的后期繼續總結，根據計劃，在下一篇文章中我將介紹自己使用過的相關工具，以及我未使用但是可以從網上找到相關資料的工具，幫助大家總結一下，以備查看。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
