. Bug 數量——可能按優先級或嚴重性排列
一般來說，錯誤的數量會在項目生命周期的中期開始增加。在截止日期之前的幾天或幾周（取決于項目的規模），團隊將集中精力減少 bug 的數量，直到 bug 的數量達到某種漸近線。這個漸近線最終代表了項目產品的整體質量。因此，跟蹤錯誤總數（區分其優先級）是一個很好的指標。

然而，并非所有錯誤都是一樣的。這就是為什么大多數團隊都會為錯誤分配優先級和/或嚴重性。例如，跟蹤 P1 錯誤和 P2 錯誤可能很有趣，而且僅跟蹤這些錯誤。這取決于您產品的成熟度。對于新產品，您需要繼續關注 P1。事實上，具有大量 P1 的產品會被認為不起作用。

如果您不再有任何 P1，但仍然有 P2，用戶仍然會遇到這些錯誤，這可能會對他們對產品的看法產生負面影響。

如果你希望你的產品被認為是高質量的，例如蘋果的水平，那么當你解決了很多 P3 和 P4 錯誤時，這實際上就會發生。這是您需要達到的水平。因此，只專注于跟蹤現在對您重要的事情。

什么時候使用它？

如果您的產品質量對您的業務很重要，那么此指標非常有幫助。如果是這樣，您應該不斷跟蹤它。但是，如果您解決了所有 P1 和 P2 問題，您可能希望通過跟蹤 P3 等方式來實現更高的質量標準。

2. 更改失敗百分比
Accelerate將故障定義為“導致服務降級或隨后需要修復（例如，導致服務受損或中斷、需要修補程序、回滾、修復轉發或補丁）”的更改。所以這個評級是導致部署失敗的部署數量。

請注意，此定義不包括部署失敗的更改。該信息很有用，但不是此 KPI 的重點。

什么時候使用它？

如果您專注于將頻繁部署變成日常習慣，那么為了使其有價值，您需要保持較低的失敗率。事實上，隨著 DevOps 團隊的經驗和能力的增強，這個評級應該會隨著時間的推移而降低。故障率不斷上升，或者故障率很高且不會隨著時間的推移而下降，這表明整個 DevOps 流程中存在問題。這是整個過程質量的一個很好的代理指標。

3. 拉取請求質量
拉取請求可以讓您很好地了解代碼庫的整體復雜性。代碼庫越復雜，以下指標較高的可能性就越大：

拉取請求破壞構建或無法通過測試套件的次數百分比；
合并請求與拒絕請求的百分比；
拉取請求的評論數量 - 您不希望數字太低，但也不希望數字太高。這些指標顯示您的團隊如何協作以及您的拉取請求是否引起了足夠的關注。它可以間接指示投入生產的代碼的質量。
何時使用它們？

該指標不是衡量 DevOps 流程的質量（例如變更失敗百分比），而是衡量團隊的工作和協作方式。代碼審查是如何使用的以及它們有用嗎？衡量合并的拉取請求與拒絕的拉取請求的演變將幫助您了解您的團隊是否隨著時間的推移而改進。您還可以深入研究團隊成員，看看他們是否也在進步。

4. 測試覆蓋率
該指標只是您正在測試的軟件中的代碼總行數與當前執行的所有測試用例的代碼行數之間的比率。

當通過執行的代碼行數來衡量時，普遍接受的“足夠”測試覆蓋率是多少？共識徘徊在 80% 左右——對于關鍵系統來說更高（關鍵的定義可能因行業、地理位置、用戶群等而異）。

什么時候使用它？

當然，您不需要 100% 的測試覆蓋率。然而，了解自己的處境并對其進行跟蹤有助于了解您是否在以速度換取質量。請記住，“建立在不良需求之上的高質量產品是劣質產品”，尤其是測試覆蓋率。

5. 平均故障間隔時間 (MTBF) 和平均恢復/修復時間 (MTTR)
這兩個指標都衡量軟件在生產環境中的性能。由于軟件故障幾乎是不可避免的，因此這些軟件指標試圖量化軟件恢復和保存數據的效果。

如果 MTTR 值隨著時間的推移而變小，則意味著開發人員在理解問題（例如錯誤）以及如何修復這些問題方面變得更加有效。

何時使用它們？

如果團隊使用這些指標來實現特定目標，那么這些指標會非常有趣：“我們需要在我們的產品上達到這一水平的 MTBF 或 MTTR。” 這將促進您的團隊對客戶提出的重要問題的響應能力，并將幫助您保持產品和團隊的高標準。為了提高這些指標的性能，團隊可能會明白他們需要解決問題的真正原因，而不是簡單的補丁。

6. 服務水平協議（SLA）
每個團隊都有自己的 SLA 定義。但這里是 Airbnb 使用的一個，你會發現它非常有趣。SLA 是您的團隊在特定時間內修復和部署的阻止程序錯誤的百分比（例如，阻止程序錯誤 24 小時，關鍵錯誤 5 天）。您可能真正喜歡這個指標的原因是它讓您從用戶的角度更好地了解您的產品質量。

什么時候使用它？

該指標非常接近MTTR，但不僅限于軟件故障。它擴展到任何類型的錯誤。同樣，如果由具有特定目標的團隊使用該指標，則非常有趣：“我們需要在我們的產品上實現此 SLA。” 該指標可培養團隊的產品質量所有權和響應能力。這就是 Airbnb 使用它的原因。

7. 缺陷去除效率（DRE）
缺陷去除效率用于量化最終用戶在產品交付后 (D) 發現的缺陷數量與產品交付前發現的錯誤 (E) 之間的關系。公式為：DRE = E / (E+D)

DRE越接近1，產品交付后發現的缺陷就越少。在整個測試計劃中，平均 DRE 分數通常約為 85%。然而，通過徹底、全面的要求和設計檢查流程，這一比例有望提升至 95% 左右。

什么時候使用它？

該指標的用途與跟蹤錯誤數量的演變類似。跟蹤它們可能是多余的。我們對錯誤數量有偏好，因為您現在可以區分哪些錯誤優先級對您很重要，并且仍然了解總體數量（而不僅僅是趨勢）。

8. 應用程序崩潰率（ACR）
應用程序崩潰率的計算方法是應用程序失敗次數 (F) 除以應用程序使用次數 (U)。但實際上有幾種方法可以計算它。

每個用戶的應用程序崩潰次數：此數字顯示有多少用戶曾經遇到過崩潰情況。該指標的可接受范圍為 < 1%。對于成熟的應用程序來說，這個數字應該更低，因為功能會更穩定。但是，在計算整個應用程序的實際數量時，可以忽略最終在回滾實例中出現的錯誤更新，以獲得準確的表示。
每個會話的應用程序崩潰次數：此數字顯示與會話數相比應用程序崩潰的次數。該指標的可接受范圍為 < 0.1%。但是，可以將其分為會話類型和應用程序流，以便更好地理解問題。
每個屏幕視圖的應用程序崩潰次數：此數字將應用程序收到的總屏幕視圖數與崩潰次數進行比較。該指標的可接受范圍為 < 0.01%。必須對此進行分類，以了解崩潰對功能交付的影響。
什么時候使用它？

當您心中有特定目標時，這個指標很有趣。例如，您可以努力使軟件最關鍵的用戶流中的 ACR 低于 0.25%。

9. 缺陷密度
有兩種不同的方法來查看缺陷密度：

面向規模的指標關注軟件的規模，通常以千行代碼 (KLOC) 表示。一旦決定了一行代碼的構成，這是一個相當容易收集的軟件指標。不幸的是，它對于比較用不同語言編寫的軟件項目沒有用。一些示例包括每個 KLOC 的錯誤或每個 KLOC 的缺陷。

面向功能的指標重點關注軟件提供的功能量。但功能不能直接測量。因此，面向功能的軟件指標依賴于計算功能點（FP） ?——一種量化產品提供的業務功能的測量單位。功能點對于比較用不同語言編寫的軟件項目也很有用。該指標將查看每個 FP 的錯誤或每個 FP 的缺陷

功能點不是一個容易掌握的概念，而且方法也各不相同。這就是為什么許多軟件開發經理和團隊完全跳過功能點的原因。他們認為功能點不值得花時間。

什么時候使用它？

依賴于代碼行的面向大小的指標使得它們本身沒有用處。因此，您不應該將兩個不同的軟件項目與它們進行比較。這就是為什么您可能不太喜歡使用它。而且面向功能的指標很難計算和達成一致。您可能想向它們引入控制措施，但列表中可能有更好的指標。

10. 依賴時代
技術債務的另一個指標是代碼庫中使用的依賴項的過時程度。跟蹤這一點可能會很有趣，作為所有依賴項的平均值，可能有一個變體，這樣您就可以確定一個依賴項何時很舊并且需要您的注意。