軟體測試度量是一種通過檢測軟體測試過程的質量和有效性來評估軟體開發的量化方法。開發團隊使用測試指標來跟蹤開發過程各個階段的軟體質量。測試指標對於管理層也很有用，它可以讓公司股東評估軟體開發團隊的效率。
測試指標應該始終是有意義和可執行的。問題是有些測試指標無法達到這一目標。許多指標都是誤導，有些只是無價值的指標，而有些則毫無意義。
下面這些無用的測試指標的例子可以幫助你更好地理解測試指標是否提供了所需的洞察力。
1執行的測試用例的數量
這是乙個糟糕的度量標準，原因很簡單，它沒有告訴你測試用例測試的是什麼。
這個度量標準的最初想法是，我們開發的測試用例越多，我們的測試就越全面。實際上，許多測試用例根本沒有對測試覆蓋率做出貢獻。許多測試套包含已棄用的測試，這些測試不再與軟體的新版本相關。測試用例的設計效率不高，因此它們會重疊，並且本質上是測試相同的功能。 在這些和許多其他的情況下，擁有更多的測試用例並不是一件好事，這可能只是代表乙個臃腫且過於複雜的測試套。
2每乙個測試人員發現的bug數
這是乙個糟糕度量標準的原因之一在於,度量每乙個測試人員的任何東西都不是乙個好的實踐——它鼓勵過度的競爭，並且破壞協作的的團隊工作，而團隊合作在敏捷組織中得到了強烈的鼓勵。
有些公司甚至會根據每個軟體測試人員發現的缺陷來決定員工報酬，這對團隊的目標尤其不利，因為它往往會抑制資訊的共享，並促進「每個人都只為自己」的態度。
此外，乙個員工可能在測試乙個穩定的軟體特性，而另乙個測試乙個有缺陷的、不穩定的特性。在這個度量標準下，後者會被認為效能更好，因為他發現了更多的bug，這是很愚蠢的的。
3百分比通過率
使用百分比通率作為度量指標是乙個壞主意，因為在你的軟體開發團隊中不鼓勵的行為很容易操縱這種指標。
例如，測試團隊可能會專注於執行更容易通過的測試，從而提高通過率。或者，團隊可以將乙個長時間的測試分解成許多小的測試，人為地提高百分比的通過率。換句話說，這個指標變化無常，易於操縱。
4單元測試**覆蓋率
**覆蓋是另乙個常用的度量指標，常常被錯誤地使用。**覆蓋率是由單元測試覆蓋的**行百分比。**覆蓋可以給你乙個完全錯誤的實際測試覆蓋圖，原因有兩個：
首先，單元測試並不是對你軟體的全面測試。它們只是測試**中特定的微元件是否能夠正常工作。即使你的車裡的所有部件都經過了測試和完美的工作，也不能保證汽車會啟動。
其次，這個指針對單元測試質量沒有任何意義。乙個單元測試可以包含優雅設計的**，測試乙個方法或函式的所有相關輸入和輸出。或者，它可能是一團亂麻，只測試其中的一些功能，或者其他無關的或已棄用的功能。用越來越多的草率的單元測試來覆蓋**對任何人都沒有好處。
5自動化的百分比
在許多情況下，自動執行的測試用例百分比是乙個無價值的度量標準。如果自動化測試不像舊的手工測試那樣測試功能，那麼越來越多的自動化測試是沒有意義的。或者如果軟體變化太快，自動化測試很快就會崩潰，需要完全重構。
被這個指標掩蓋的另乙個方面是測試持續時間。新增越來越多的selenium測試，進行自動化ui測試是乙個好主意。但是執行這些測試可以使構建時間從幾分鐘增加到幾小時。在當前頻繁發布版本的現實中，進行這樣的測試需要非常謹慎，對於需要匆忙進行交付的團隊就只能跳過了。
6每乙個缺陷的成本
這可能是軟體質量的最古老的度量標準，它早在上世紀60年代就在ibm內部使用過。改度量指標為乙個bug貼上乙個**標籤——識別乙個bug、修復它、並驗證它的成本。這個共識就是：在開發周期的早期修復bug要便宜得多，而在測試後期，或者在生產過程中，修復它們是非常昂貴的。
在開發周期的不同階段度量每個缺陷的成本是乙個很好的想法。然而，一些團隊度量每個缺陷的成本，以使軟體維護更有效。
主要問題是：對於軟體的質量和使用者的經驗，缺陷有不同的含義。有些缺陷是「化妝品」，對於軟體的使用者幾乎沒什麼影響。而其他的一些缺陷，如安全問題，如果不解決的話可能會帶來災難性後果。 乙個軟體團隊可能會把注意了放在那些影響不大的缺陷上，大幅降低每個缺陷的成本，但是最終會損壞軟體的質量。
7缺陷密度
缺陷密度是指軟體中檢測到的得到確認的缺陷數量。通常認為較低的缺陷密度等同於較低的軟體質量，但這並不是真的。
缺陷密度的乙個問題是，缺陷的數量取決於測試是如何構造和報告的，以及軟體測試人員的技能。某個軟體問題可以被當成乙個bug、或者是該問題不同方面的15個bug，或者根本沒有bug報告，因為測試人員沒有發現它。因此，對於相同的軟體，缺陷密度可能會有很大的變化。
結論三個測試的挑戰
在當今的測試世界中，有三個挑戰與測試指標密切相關:
找到一種同時提高測試質量和速度的方法。持續測試是一種實踐，它有助於提高軟體質量，同時與快速迭代保持同步。在持續的測試環境中，度量標準是至關重要的，以確保軟體質量真實的提高，而不是在迭代之間被侵蝕。
防止未經測試的**更改流入到生產環節中。沒有軟體可以真正做到百分百的測試覆蓋率（即使如上面提到的那樣做到100%的**覆蓋，這也不一樣。）傳統的通過/失敗度量不會告訴你最近的**更改是否經過了測試。如果沒經過測試，度量標準不會揭示發布這部分軟體所固有的風險。
收集用於分析的質量指標出處單一。有大量的工具可以提供qa指示。但是它們都比較典型的集中與度量測試團隊的過程和工作。其中的某些指標會如上述所說的那樣不確定或者誤導。今天的指標不能提供足夠的、有意義的、顯示軟體質量趨勢的資訊。
真正提供有用資訊，並幫助你了解軟體質量的真實度量標準是很難得到的。
新的平台，如sealights，乙個在敏捷環境中測量真實測試覆蓋率的平台，通過提供更有用的測試指標和更具有代表性的軟體質量來改變測試場景。具體地說，一種跨越所有型別自動和手工測試的對於測試覆蓋的全面度量方法;乙個「聖杯」度量，它揭示了每個敏捷版本中固有的風險。
隨著敏捷的出現，軟體開發已經成長起來，而測試也是如此，但是度量標準遠遠落在後面。最重要的是識別、評估和實踐真實的度量標準能夠幫助敏捷團隊開發出更好的軟體。
《it專案管理與職業生涯規劃大型論壇》蘇州專場報名鏈結
軟體開發的七個步驟
軟體開發的七個步驟 功能設計 結構設計 編寫 功能測試 效能測試 部署維護 使用者體驗。關於軟體開發流程，英語中對應的單詞比較多，叫法不統一。我感覺在中文中採用這個七個詞更合適一些。箭頭首尾相接，組成乙個迴圈，表示這七個步驟不是一次性完成的，而是多次進行的。先設計核心的和主要的功能，然後就實現和測試...
軟體開發中的30個錯誤
1.不理解使用者的需求。缺乏使用者提出需求，或者根本就不問。2.低估專案的規模。3.快速通過計畫編制過程，或者沒有計畫編制過程。嚴重地編碼優先，計畫靠後！4.沒有盡早的 經常性地測試，或者根本就不測試。並且養成如此習慣。5.選擇很 酷 的方法學。6.不使用方 7.讓軟體開發者執行軟體開發專案。8.盲...
軟體開發中存在的25個常見問題
乙個軟體專案從開始到結束，由於資源 人員 管理 方法學等等各方面的因素，往往不可避免的會存在一些問題，如需求不明確 專案管理失敗 溝通問題等等，今天無意中看到老外寫的關於這方面的一篇文章，總結的比較全面，翻譯過來結合自己的一些經驗做了點補充和修改，存檔以備時常可以告誡一下自己。1.不能很好的理解使用...