我們開發和交付軟件的方式已經改變了
在過去的5年裏發生了戲劇性的變化——但我們用來衡量質量的指標
大體保持不變。盡管商業預期發生了翻天覆地的變化，
開發方法、係統架構和團隊結構
組織仍然依賴於質量度量標準，這些度量標準是為許多人而設計的
不同的時代。
應用程序交付的其他所有方麵都已經完成了
在我們為DevOps轉變我們的流程時仔細審查和優化。為什麼不把
顯微鏡下的質量指標?
度量是否像自動化測試的數量、測試用例
覆蓋率和通過/不合格率在DevOps的上下文中很重要，這是目標
是否能夠立即洞察到給定的發布候選版本是否具有可接受的版本
風險水平?還有什麼指標可以幫助我們確保源源不斷的
更新不會破壞我們一直在努力的用戶體驗
提高?
為了給DevOps社區提供一個客觀的視角，讓他們了解哪些質量指標對DevOps的成功至關重要，Tricentis委托Forrester對這個主題進行了研究。研究結果發表在一本55頁的電子書中，Forrester研究《重要的開發運維質量指標:75個常見指標——由行業專家排名》．
對於每一類的質量
在參數方麵，我們製作了一張顯示使用率與價值排名的熱圖。為
例如，下麵是構建類別指標的熱圖。
我們還繪製了每個指標的數據
分成四個部分的象限:
- 增值: DevOps專家經常使用的指標，並且一直被度量它們的組織評為有價值的指標。
- 隱藏的寶石:DevOps專家不經常使用的度量，但是度量它們的組織始終認為這些度量是有價值的。
- 高估了:DevOps專家經常使用的度量標準，但度量它們的組織並不認為它們有價值。
- 分散注意力:DevOps專家不經常使用的指標，也沒有被度量它們的組織評為有價值的指標。
例如，這裏是構建類別的象限
指標:
的
電子書提供所有4個類別的熱圖和象限，a
快速查看75個指標中的每一個，每個類別和總體分析
很少有有趣的列表。這裏有一個預覽…
隱藏的寶石
以下指標並不常用(即使在
DevOps專家)，但是被那些選擇的團隊評為極有價值的
實際測量它們:
- 新的缺陷(IT)
- 關鍵缺陷(FV)
- 按風險(構建)進行優先級排序的自動化測試
- 代碼覆蓋率(構建)
- 執行的測試用例(構建)
- 靜態分析結果(構建)
- 測試用例百分比基線的方差
通過(E2E) - 發布準備(E2E)
頂級DevOps差異化因素
DevOps專家/領導者衡量以下指標
遠遠超過了DevOps落後者的衡量標準:
- 按風險(構建)進行優先級排序的自動化測試
- 自動化端到端測試用例(E2E)的百分比
- 風險覆蓋範圍(IT)
- 發布準備(FV, IT, E2E)
- 測試效率(FV和IT)
- 測試涵蓋的需求(構建、FV、IT、
E2E) - 測試用例覆蓋率(構建，E2E)
- 靜態分析結果(構建)
- 測試用例百分比與基線的差異
通過(E2E) - 測試
有效性(FV、IT、E2E)
主要由DevOps專家使用
以下指標是最常用的(總體而言)
DevOps專家/領導者:
- 測試用例覆蓋率(E2E)
- 合格/不合格率(FV)
- API通過率/不合格率(IT)
- 執行的測試數(E2E)
- API bug密度(IT)
- 測試涵蓋的需求(FV)
- 測試涵蓋的需求(E2E)
- 被阻塞的測試用例(FV)
- 自動化端到端測試用例(E2E)的百分比
- 成功的
代碼構建(構建)
最受DevOps專家重視
以下指標是最有價值的(總體而言)
DevOps專家/領導者:
- API測試涵蓋的需求(IT)
- 自動化端到端測試的百分比(E2E)
- 測試涵蓋的需求(E2E)
- 測試涵蓋的需求(FV)
- 關鍵功能缺陷(FV)計數
- 測試中發現的缺陷總數(E2E)
- 執行的測試用例的數量(E2E)
- 不合格率(FV)
- 發現新的API缺陷(IT)
- 自動化
按風險(構建)劃分優先級的測試
對調查結果的行業評論
Vincent Lussenburg，開發運營戰略總監XebiaLabs,對調查結果發表了以下評論……
“我很高興地看到，在調查中，發布就緒度被確定為DevOps成功的關鍵指標。我們知道Release Readiness對我們的客戶來說是一個區別——它允許他們使他們的交付過程更有效，降低風險，並快速交付高質量的軟件。
我們的DevOps平台集成了組織現有的工具，比如Tricentis Tosca，並內置了一些特性，幫助IT團隊確保他們的版本在投入生產之前是可靠的。例如，是否所有關鍵測試都運行並成功了?發生的測試失敗是否存在發布風險?是否對環境問題進行分類，是否為更持久的修複而創建問題，是否記錄了根本原因?XebiaLabs通過管道自動執行這些檢查，並從不同的角度可視化發布風險，包括但不限於您的測試活動。我們甚至可以幫助您預測哪些版本最容易失敗。”