測量質量保證成功的基本測試量度

軟件測試度量是測量和監視您的測試活動的一種方法。更重要的是，它們為您的團隊的測試進度、生產力，以及被測試係統的質量提供了見解。當我們問自己“我們測試了什麼?”，比起“我們已經測試過了”，參數將帶給我們更好的答案”。不同的團隊根據他們想要跟蹤、控製或改進的內容來衡量不同的方麵。

指標通常根據數據組合來傳達結果或預測。

為什麼測試指標?你為什麼要在乎?

收藏的目的測試指標是使用數據來改進測試過程，而不是僅僅顯示花哨的報告。這包括找到問題的具體答案:

• 測試需要多長時間?
• 測試需要多少錢?
• 蟲子有多嚴重?
• 有多少發現的bug被修複了?重新開放嗎?關閉?延期嗎?
• 測試團隊沒有發現多少bug ?
• 測試了多少軟件?
• 測試會按時完成嗎?軟件能按時發貨嗎?
• 測試結果如何?我們是否使用了低價值的測試用例?
• 測試的成本是多少?
• 測試工作是否足夠?我們是否可以在這個版本中加入更多的測試?

這些問題的好答案需要衡量。本文包含了測試人員和QA經理最常使用的64個絕對、衍生、結果和預測指標。

基本指標

作為一名測試員，你的指標創造之路必須從某個地方開始。基本質量保證指標是絕對數字的組合，然後可以用來產生導數度量。

絕對數字

1. 測試用例總數
2. 通過的測試用例數
3. 失敗的測試用例數
4. 被阻塞的測試用例的數量
5. 發現的缺陷數量
6. 接受的缺陷數量
7. 拒收缺陷數量
8. 延期缺陷數量
9. 嚴重缺陷的數量
10. 計劃的測試小時數
11. 實際測試小時數
12. 發貨後發現的bug數量

導數指標

絕對數字是一個很好的起點，但通常光有數字是不夠的。

例如，如果你在跟蹤表格上做報告，這可能不足以理解我們是否按時完成，或者我們每天應該查看什麼結果。

一天	第一天	第二天	第三天
結果完成了	35	40	45

在這種情況下，絕對數字產生的問題比答案更多。在衍生度量的幫助下，我們可以更深入地回答在我們的測試過程中在哪裏解決問題。

測試跟蹤和效率

以下是幫助測試跟蹤和效率的衍生指標:

13.
14.
15.
16.
17.
18.
19.
20.
21.

測試工作

測試工作度量標準將回答以下問題:“多長時間，多少，多少?”這些度量標準對於為未來的測試計劃建立基線非常有用。然而，你需要記住這些指標都是平均值。一半的數值高於平均值，一半低於平均值。

具體措施有:

22.
23.
24.
25.
26.
27.

測試效果

測試有效性回答，“測試有多好?”或者“我們正在運行高值測試用例嗎?”它是一個測試集的bug查找能力和質量的度量。測試有效性度量標準通常顯示測試團隊發現的缺陷數量與軟件發現的總體缺陷之間的差異的百分比值。

28.基於度量標準:使用缺陷遏製效率的測試有效性

測試有效性百分比越高，測試集就越好，從長期來看，測試用例維護工作就越少。

例子:如果一個版本的測試有效性是80%，這意味著測試團隊遺漏了20%的缺陷。

• 這個數字應該導致調查、回顧，以及改進測試集的糾正行動，這樣測試集的缺陷識別率就會增長。
• 測試的有效性永遠不可能達到100%。因此，團隊應該以更高的值為目標，如果不是100也不應該感到失望。
• 發布版本的平均效率將顯示對測試集改進的努力是否給出了積極的結果。

29.基於上下文:使用團隊評估的測試有效性

使用缺陷遏製效率度量在以下情況下可能不起作用:

• 產品已經成熟
• 產品不穩定且有bug
• 由於時間/資源的限製，沒有進行足夠的測試

在這種情況下，我們將需要另一種基於意見或上下文的方法來度量測試集的有效性。

您可以讓您的團隊對測試集的好壞進行評分。在您這樣做之前，告訴您的團隊要不偏不倚，並定義好的測試集意味著什麼，這是很重要的。例如，您的團隊可能決定一個好的測試集應該充分覆蓋高風險的需求。現實一點，關注應用程序中最關鍵的領域。

你的團隊也可以使用主觀縮放方法。在100%的評分(1到10分)之外，要求您的團隊對測試集給出一個分數，以了解測試集目前的完整程度、最新程度和有效性。獲得一個平均分數，以獲得團隊感知到的平均測試有效性。從主題專家的角度討論哪些測試是好的，哪些測試是壞的，這被證明是縮小測試焦點的一個有意義的練習。

重要的是要告訴您的團隊保持公正，並定義一個好的測試集意味著什麼。

測試覆蓋率

軟件質量度量測量正在測試的應用程序的運行狀況。不可避免的是，您想要分析的下一個核心指標集與覆蓋率有關。測試覆蓋率度量度量測試工作，並幫助回答，“測試了應用程序的多少部分?”

例如，“在這些通過或失敗的測試中，我的應用程序的工件或區域是什麼，它們被設計來確保我的產品以高質量生產。”下麵是一些關鍵的測試覆蓋率指標。

30.

• 這讓我們了解了與未完成的測試運行相比所執行的測試總數。它通常以百分數表示。

31.

• 為了獲得測試覆蓋需求的高級視圖，您隻需將覆蓋的需求數量除以sprint、發布或項目的總範圍需求數量。
• 這通常隻會顯示是否有與測試相關的測試，而不是顯示測試運行的結果。

32.按需求測試用例

• 最常見的方法是查看正在測試哪些特性，以及查看我們已經根據用戶故事或需求進行了多少測試。

要求的事情	TC的名字	測試結果
要求1	TC Name1	通過
要求2	TC Name2	失敗的
要求3	TC Name3	不完整的

33.按要求缺陷(要求缺陷密度)

• 每個需求的缺陷密度有助於發現哪些需求比其他需求更有風險。例如，測試用例可能很好，但是需求可能是導致所有問題的原因。

要求的名字	缺陷總數
申請一個	25
申請B	2

34.沒有測試覆蓋的需求

• 重要的是要知道您是否已經準備好將一個具有適當測試覆蓋率的需求推向生產環境。
• 這顯示了哪些需求沒有測試覆蓋，以及需求處於什麼階段。例如，處於“完成”狀態的需求比處於“做”狀態的需求風險更大。

請求ID	要求的名字	申請狀態
REQ001	申請一個	要做
REQ002	申請B	完成

即使更高的測試覆蓋率百分比和圖表可以為您的測試工作注入信心，但它是一個相對的值。就像我們不能找到所有的bug一樣，我們也不能創建足夠的測試來實現100%的測試覆蓋率。這並不是測試人員的限製，而是由於所有係統都不受約束的現實。當我們考慮字段、功能和端到端級別的測試時，有無數的測試。因此，最好準確地定義有限的測試目錄的100%測試覆蓋率。

在網絡研討會中學習更多關於如何充分利用軟件測試指標的技巧:如何構建老板真正閱讀的報告。

測試經濟學指標

人員(時間)、基礎設施和工具都是測試成本的一部分。測試項目並沒有無限的資金資源。因此，知道你打算花多少錢以及你最終花了多少錢是很重要的。以下是一些測試經濟指標，可以幫助您當前和未來的預算規劃。

35.測試總分配成本

• cio和QA主管為單個項目或一整年的所有測試活動和資源預算的金額

36.測試的實際成本

• 投入測試的實際金錢時間
  
• 計算此成本的一種方法是測量每個需求、每個測試用例或每個測試小時的測試成本。

例如，如果您的預算是1000美元，其中包括測試100個需求，那麼測試一個需求的成本是1000/100= 10美元。每測試一小時的成本，100小時1000美元意味著每小時10美元。這當然假設所有的需求在複雜性和可測試性上都是相等的。

這些數字很重要，可以作為基線，幫助估算項目未來的預算。

37.預算差異

• 實際成本與計劃成本之間的差異

38.進度偏差

• 完成測試所需的實際時間與計劃時間之間的差異
  
  如果實際成本低於分配的預算(負的差異)，這對項目來說是好消息。然而，這也可能意味著估計是錯誤的。方差為零是首選的。

更多的信息在這裏

39.每個Bug修複的成本

• 這是根據每個開發人員在一個缺陷上所花費的工作量來計算的
• 如果一個開發者花了10個小時去修複一個漏洞，而他的時薪是60美元，那麼修複漏洞的成本就是10 * 60美元= 600美元。
• 一些團隊還考慮為了更精確的測量而重新測試的成本。

40.不測試的成本

• 如果一組新特性投入生產，但需要返工，那麼所有用於返工的費用就等於不測試的費用。
• 不進行測試的成本也可以追溯到更主觀的價值，比如一個人的觀點。以下是一些不進行測試的主觀成本的例子:
  • 更多客戶關懷電話/服務請求
  • 生產中斷
  • 失去用戶/客戶的信任等。
  • 客戶忠誠度的喪失
  • 可憐的品牌知名度

測試團隊指標

這些度量標準可以用來理解每個測試團隊成員的工作分配是否統一，並查看是否有任何團隊成員需要更多的過程/項目知識澄清。這些指標不應該被用來指責，而應該被用作學習工具。

41.每個團隊成員返回的缺陷的分布——見解2.0

42.每個測試團隊成員重新測試的開放缺陷分布——Insights 2.0
43.每個測試團隊成員分配的測試用例——Insights 2.0

44.測試團隊成員執行的測試用例- Insights 2.0

通常，餅圖或直方圖用於獲得工作分配的快速快照。下麵的圖表立即引起了我們的注意，鮑勃被超額預定，而大衛沒有得到充分利用。這給了測試主管/經理一個機會來研究為什麼會出現這種情況，並在必要時采取糾正措施。

測試執行狀態

測試執行快照圖顯示了按照通過、失敗、阻塞、不完整和未執行的方式組織的總執行，以方便吸收測試運行狀態。這些圖表對於日常狀態會議來說是很好的視覺輔助，因為原始數據更容易從人們的腦海中溜走。不斷增長和萎縮的棒子吸引了注意力，更有效地傳達了進展和速度。

45.測試執行狀態圖

測試執行/缺陷發現率跟蹤

這些圖表有助於理解測試的比率和缺陷發現的比率如何與期望的值相比較。

計算累積的缺陷計數和測試執行率，就可以繪製出理論曲線。與實際值相比，這將觸發一個早期的危險信號，如果要達到目標，測試過程需要更改。

46.測試執行跟蹤和缺陷發現率跟蹤

更多信息和圖像來源

變更度量的有效性

軟件經曆變化——頻繁的、很少的、間隔很長。必須監測所納入的變化，以了解它們對現有係統穩定性的影響。變更通常會引起新的缺陷，降低應用程序的穩定性，導致時間線的滑動，危及質量，等等。

這些措施有助於我們更好地了解影響:

47.測試變更的影響

可以歸因於變更的缺陷總數。這可能意味著確保缺陷在報告給開發時具有適當的影響和修複視圖。將這些缺陷分類為與變更相關的或者不相關的，需要付出一點努力，但是這是值得的。

48.缺陷注入量

由變更引起的測試變更/問題的數量

例如:如果對係統進行了10個更改，並且有30個缺陷可歸因於這些更改，那麼每個更改最終會注入3個缺陷，每個更改的缺陷注入率為3。

知道這個數字將有助於預測每個新更改所期望的缺陷數量。這允許測試團隊有策略地使用回顧會議來了解他們幫助識別和修複來自新變更的缺陷的能力。

缺陷分布圖表

缺陷可以根據類型、根本原因、嚴重程度、優先級、模塊/組件/功能區域、平台/環境、測試人員職責、測試類型等進行分類。您的團隊可能正確地設置了缺陷報告的完整的細化分類列表。

缺陷分布圖對於理解分布和識別最大缺陷去除目標區域是有幫助的。通過使用直方圖、餅圖或帕累托圖來顯示您的開發和測試工作的方向。

49.缺陷按原因分布

50.缺陷按模塊/功能區域分布

51.缺陷按嚴重程度分布

52.缺陷按優先級分布

53.缺陷類型分布

54.按照測試人員(或測試人員類型)——開發人員、QA人員、UAT人員或最終用戶——來分配缺陷

55.缺陷分布通過測試類型——評審、演練、測試執行、探索，等等。

56.缺陷按平台/環境分布

直方圖或餅狀圖顯示了對高度受影響地區的即時視覺識別。但是，當有太多的參數，沒有模式，很難辨別，你可能不得不使用帕累托圖表。缺陷

分布餅狀圖:這隻有一個目的。它可以幫助您快速找到最密集的區域(大多數缺陷的原因)。

缺陷分布柱狀圖:

在創建直方圖時，請確保從高到低或從低到高組織數據值，以獲得最大的影響。

您可以在此停止，但要從您的指標中獲得更多信息，請繼續進行下一步。

將直方圖與每個原因中缺陷嚴重程度的分布相結合。這會讓你更準確地找到你應該關注的領域。

例如:我們知道導致大多數缺陷的區域是用戶數據條目，但是僅僅因為計數高，我們不需要首先關注它，因為大多數“用戶數據條目”是低的(綠色)。下一個類別中缺陷數量最多，並且嚴重問題的比例很高，它是“代碼錯誤”。因此，這張圖表將完善我們的數據，並讓我們更深入地了解如何引導進一步的開發和修複工作。

缺陷分布帕累托圖:

您還可以創建一個帕累托圖來找出哪些原因可以修複大多數缺陷。在許多情況下，帕累托圖可能是不必要的。但是，如果原因太多，直方圖或餅圖不足以清楚地顯示趨勢，帕累托圖就可以派上用場。

為了知道要關注哪些原因，以便以最小的工作量修複最大的缺陷(或者什麼20%的原因可以修複80%的缺陷)，在Secondary軸的80%標記處畫一條線，並將其放到X軸上，如下所示:

用戶數據輸入錯誤和代碼錯誤的原因應該得到更多的關注。

缺陷隨時間的分布圖表

測試周期結束時的缺陷分布或者測試周期中某個點上的缺陷分布是那個時間點上缺陷數據的快照。它不能用來得出事情是變好還是變壞的結論。例如:在某一時刻，您將知道有X個嚴重的bug。我們不知道X比上一個循環大還是小，還是相同。

隨著時間的推移，您將知道每個類別中的缺陷發生了什麼。我們可以看到缺陷是否隨著時間的推移或版本的發布而增加、減少或穩定。

缺陷隨時間的分布是一個多線形圖，顯示了一段時間內每個原因/模塊/嚴重程度的缺陷趨勢。

57.缺陷在一段時間內按原因分布

58.缺陷隨時間按模塊分布

59.缺陷隨時間的嚴重性分布

60.缺陷隨時間按平台分布

以下數據:

測試周期	代碼錯誤	安全問題(訪問權限)	用戶錯誤(數據錄入)
周期1	8	4	15
周期2	7	3.	13
周期3	1	5	9
周期4	1	5	4
周期5	0	4	1

在5個周期內繪製3種原因的多折線圖，如下所示:

以下是圖表可以幫助我們理解的內容:

1. 最初兩個周期的代碼錯誤一直很高，但從周期3開始顯著下降並保持在較低水平。這表明開發工作的有效性。
2. 用戶數據輸入錯誤從最初發布的版本大幅下降;這表明用戶對產品的熟悉度和接受度增加
3. 隨著測試周期的推進，與安全相關的缺陷保持穩定，並且沒有改進(即減少數量)。這意味著，這些問題必須作為優先事項加以重視和處理。

限製:

1. 對於消極的趨勢，例如發布/測試周期，如果缺陷計數在一個特定的原因類別中增加，這個圖表告訴我們這是什麼，但沒有告訴我們為什麼。
2. 當需要處理的原因很少時，它是最有效的。想象一下這個圖表有10個原因類別，而不是3個，它會有太多的行，使它太忙，難以解釋。

產生的缺陷與解決的缺陷圖表

61.產生的缺陷與解決的缺陷圖表

Bug發現與修複圖是一個缺陷分析折線圖，它讓我們看到缺陷移除過程模式，並理解缺陷管理的有效性

要開始創建固定vs.發現圖表，你必須首先收集號碼。發現的缺陷和沒有。測試周期中每天解決的缺陷。這是一個需要累積數字才能有意義的圖表。在10天的測試周期中考慮以下缺陷數據:

測試周期1-日期	錯誤了	缺陷解決	累計產生的bug(總數到目前為止創造的bug)	累計解決的bug(到目前為止解決的bug總數)
10/10/2016	6	4	6	4
10/11/2016	3.	0	9	4
10/12/2016	4	4	13	8
10/13/2016	2	4	15	12
10/14/2016	2	3.	17	15
10/15/2016	0	0	17	15
10/16/2016	1	0	18	15
10/17/2016	0	2	18	17
10/18/2016	0	2	18	19
10/19/2016	0	0	18	19

為上述數據創建的缺陷與解決的圖表如下所示:

這張圖表很好，但是有太多的線讓我們分心。創建和解決的bug的原始數量是沒有意義的，你可以從圖表中刪除它們，以獲得更清晰的創建和解決圖表，如下所示:

這個圖表回答了以下問題:

• 我們準備好出貨了嗎?
• 軟件在測試結束時是否獲得了穩定性?
• 缺陷管理係統是否有效?

方法如下:

1. 在測試周期的末尾，綠線變得更直、更平或更穩定。這表明bug發現率下降了，並且累積的bug數量是恒定的—因此，它幫助我們回答以下問題—“我們測試的足夠了嗎?”，或者“產品準備好了嗎?”

如果綠線變得越來越陡峭，這意味著發現漏洞的速度甚至在測試結束時也沒有下降。所以，需要更多的測試，產品還不能發貨。

2.在曲線的末端，創建和解決的線(或多或少)是收斂的。這也是一個好跡象，因為它表明缺陷管理過程正在工作，並且正在有效地修複問題。

如果藍線遠遠低於綠線，這意味著缺陷沒有被及時地處理，我們可能需要一個過程改進。

限製:雖然這張圖表回答了很多重要的問題，但它也有其局限性。

• 綠線中的峰值可能發生在測試周期的開始階段，此時bug發現率通常很高。當開發團隊遍曆所有缺陷並將其中很多標記為完成時，藍色線中的尖峰也會出現。這可能會引起短暫的恐慌。
• 圖表顯示了發生了什麼，但需要進一步的研究來了解原因。

引用:

https://confluence.atlassian.com/jira064/created-vs-resolved-issues-report-720416052.html

管理測試過程，Rex Black，第4章:“缺陷移除如何進行”

http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470404159.html

更多的缺陷度量

62.缺陷去除效率/缺陷間隙分析

缺陷消除效率是開發團隊能夠處理並消除測試團隊報告的有效缺陷的程度。

為了計算缺陷差距，獲得提交給開發團隊的缺陷總數，以及周期結束時修複的缺陷總數。用這個公式快速計算一個百分比，

示例:在一個測試周期中，如果QA團隊報告了100個缺陷，其中20個是無效的(不是bug，重複，等等)，並且如果開發團隊已經解決了其中的65個，那麼缺陷差距%是:(65/100-20)X100= 81%(大約)

當在一段時間內收集數據時，缺陷間隙分析也可以繪製成如下圖:

巨大的差距表明開發過程需要改變。

更多信息:https://www.equinox.co.nz/blog/software-testing-metrics-defect-removal-efficiency

63.缺陷密度

缺陷密度被定義為每軟件或軟件應用區域的大小缺陷的數量。

如果一個測試周期結束時缺陷總數為30個，且缺陷均來自6個模塊，則缺陷密度為5。

更多信息:http://www.softwaretestinghelp.com/defect-density/

64.缺陷的年齡

缺陷年齡是幫助我們跟蹤開發團隊開始修複並解決缺陷所花費的平均時間的度量。缺陷年齡通常以天為單位進行度量，但是對於每周或每天發布項目的快速部署模型團隊來說，應該以小時為單位進行度量。

對於具有高效開發和測試過程的團隊來說，較低的缺陷年齡標誌著對缺陷修複的更快周轉。

缺陷年齡=創建時間和解決時間的差異

學習如何Tricentis分析能夠提供跨測試項目和組織範圍內工具的組合可見性。

本文由斯瓦特Seela而且瑞安Yackel．