軟件測試度量是一種通過檢測軟件測試過程的質(zhì)量和有效性來評估軟件開發(fā)的量化方法。開發(fā)團隊使用測試指標來跟蹤開發(fā)過程各個階段的軟件質(zhì)量。測試指標對于管理層也很有用，它可以讓公司股東評估軟件開發(fā)團隊的效率。

測試指標應該始終是有意義和可執(zhí)行的。問題是有些測試指標無法達到這一目標。許多指標都是誤導，有些只是無價值的指標，而有些則毫無意義。

下面這些無用的測試指標的例子可以幫助你更好地理解測試指標是否提供了所需的洞察力。

1 執(zhí)行的測試用例的數(shù)量

這是一個糟糕的度量標準，原因很簡單，它沒有告訴你測試用例測試的是什么。

這個度量標準的初想法是，我們開發(fā)的測試用例越多，我們的測試就越全面。實際上，許多測試用例根本沒有對測試覆蓋率做出貢獻。許多測試套包含已棄用的測試，這些測試不再與軟件的新版本相關。測試用例的設計效率不高，因此它們會重疊，并且本質(zhì)上是測試相同的功能。

在這些和許多其他的情況下，擁有更多的測試用例并不是一件好事，這可能只是代表一個臃腫且過于復雜的測試套。

2每一個測試人員發(fā)現(xiàn)的Bug數(shù)

這是一個糟糕度量標準的原因之一在于,度量每一個測試人員的任何東西都不是一個好的實踐——它鼓勵過度的競爭，并且破壞協(xié)作的的團隊工作，而團隊合作在敏捷組織中得到了強烈的鼓勵。

有些公司甚至會根據(jù)每個軟件測試人員發(fā)現(xiàn)的缺陷來決定員工報酬，這對團隊的目標尤其不利，因為它往往會抑制信息的共享，并促進“每個人都只為自己”的態(tài)度。

此外，一個員工可能在測試一個穩(wěn)定的軟件特性，而另一個測試一個有缺陷的、不穩(wěn)定的特性。在這個度量標準下，后者會被認為性能更好，因為他發(fā)現(xiàn)了更多的bug，這是很愚蠢的的。

3百分比通過率

使用百分比通率作為度量指標是一個壞主意，因為在你的軟件開發(fā)團隊中不鼓勵的行為很容易操縱這種指標。

例如，測試團隊可能會專注于執(zhí)行更容易通過的測試，從而提高通過率?；蛘?，團隊可以將一個長時間的測試分解成許多小的測試，人為地提高百分比的通過率。換句話說，這個指標變化無常，易于操縱。

4單元測試代碼覆蓋率

代碼覆蓋是另一個常用的度量指標，常常被錯誤地使用。代碼覆蓋率是由單元測試覆蓋的代碼行百分比。代碼覆蓋可以給你一個完全錯誤的實際測試覆蓋圖，原因有兩個：

    首先，單元測試并不是對你軟件的全面測試。它們只是測試代碼中特定的微組件是否能夠正常工作。即使你的車里的所有部件都經(jīng)過了測試和完美的工作，也不能保證汽車會啟動。
    其次，這個指標對單元測試質(zhì)量沒有任何意義。一個單元測試可以包含優(yōu)雅設計的代碼，測試一個方法或函數(shù)的所有相關輸入和輸出?；蛘?，它可能是一團亂麻，只測試其中的一些功能，或者其他無關的或已棄用的功能。用越來越多的草率的單元測試來覆蓋代碼對任何人都沒有好處。

5自動化的百分比

在許多情況下，自動執(zhí)行的測試用例百分比是一個無價值的度量標準。如果自動化測試不像舊的手工測試那樣測試功能，那么越來越多的自動化測試是沒有意義的?；蛘呷绻浖兓?，自動化測試很快就會崩潰，需要完全重構(gòu)。

被這個指標掩蓋的另一個方面是測試持續(xù)時間。添加越來越多的Selenium測試，進行自動化UI測試是一個好主意。但是運行這些測試可以使構(gòu)建時間從幾分鐘增加到幾小時。在當前頻繁發(fā)布版本的現(xiàn)實中，進行這樣的測試需要非常謹慎，對于需要匆忙進行交付的團隊就只能跳過了。

6每一個缺陷的成本

這可能是軟件質(zhì)量的古老的度量標準，它早在上世紀60年代就在IBM內(nèi)部使用過。改度量指標為一個bug貼上一個價格標簽——識別一個bug、修復它、并驗證它的成本。這個共識就是：在開發(fā)周期的早期修復bug要便宜得多，而在測試后期，或者在生產(chǎn)過程中，修復它們是非常昂貴的。

在開發(fā)周期的不同階段度量每個缺陷的成本是一個很好的想法。然而，一些團隊度量每個缺陷的成本，以使軟件維護更有效。

主要問題是：對于軟件的質(zhì)量和用戶的經(jīng)驗，缺陷有不同的含義。有些缺陷是“化妝品”，對于軟件的用戶幾乎沒什么影響。而其他的一些缺陷，如安全問題，如果不解決的話可能會帶來災難性后果。

一個軟件團隊可能會把注意了放在那些影響不大的缺陷上，大幅降低每個缺陷的成本，但是終會損壞軟件的質(zhì)量。

7缺陷密度

缺陷密度是指軟件中檢測到的得到確認的缺陷數(shù)量。通常認為較低的缺陷密度等同于較低的軟件質(zhì)量，但這并不是真的。

缺陷密度的一個問題是，缺陷的數(shù)量取決于測試是如何構(gòu)造和報告的，以及軟件測試人員的技能。某個軟件問題可以被當成一個bug、或者是該問題不同方面的15個bug，或者根本沒有bug報告，因為測試人員沒有發(fā)現(xiàn)它。因此，對于相同的軟件，缺陷密度可能會有很大的變化。

結(jié)論

三個測試的挑戰(zhàn)

在當今的測試世界中，有三個挑戰(zhàn)與測試指標密切相關:

    找到一種同時提高測試質(zhì)量和速度的方法。持續(xù)測試是一種實踐，它有助于提高軟件質(zhì)量，同時與快速迭代保持同步。在持續(xù)的測試環(huán)境中，度量標準是至關重要的，以確保軟件質(zhì)量真實的提高，而不是在迭代之間被侵蝕。
    防止未經(jīng)測試的代碼更改流入到生產(chǎn)環(huán)節(jié)中。沒有軟件可以真正做到百分百的測試覆蓋率(即使如上面提到的那樣做到100%的代碼覆蓋，這也不一樣。)傳統(tǒng)的通過/失敗度量不會告訴你近的代碼更改是否經(jīng)過了測試。如果沒經(jīng)過測試，度量標準不會揭示發(fā)布這部分軟件所固有的風險。
    收集用于分析的質(zhì)量指標出處單一。有大量的工具可以提供QA指示。但是它們都比較典型的集中與度量測試團隊的過程和工作。其中的某些指標會如上述所說的那樣不確定或者誤導。今天的指標不能提供足夠的、有意義的、顯示軟件質(zhì)量趨勢的信息。

真正提供有用信息，并幫助你了解軟件質(zhì)量的真實度量標準是很難得到的。

新的平臺，如SeaLights，一個在敏捷環(huán)境中測量真實測試覆蓋率的平臺，通過提供更有用的測試指標和更具有代表性的軟件質(zhì)量來改變測試場景。具體地說，一種跨越所有類型自動和手工測試的對于測試覆蓋的全面度量方法;一個“圣杯”度量，它揭示了每個敏捷版本中固有的風險。

隨著敏捷的出現(xiàn)，軟件開發(fā)已經(jīng)成長起來，而測試也是如此，但是度量標準遠遠落在后面。重要的是識別、評估和實踐真實的度量標準能夠幫助敏捷團隊開發(fā)出更好的軟件。