測試缺陷分析

摘要：

    測試活動作為IT項目和產品開發一個重要的環節，通過發現產品或組件的缺陷，并反饋給開發組修復驗證這些缺陷，從而在一定程度上保證了外發產品的質量。對這些測試活動發現的缺陷進行深入的分析，可以有助于我們進行質量預測、進行過程改進、量化的衡量產品質量。

    關鍵詞：

    測試分析、過程改進、質量預測、過程能力、缺陷

    正文：

    項目研發過程中，我們通過單元測試、集成測試、系統測試發現了大量的缺陷。我們把這些Bug輸入到Excel或者其他測試管理系統中，跟蹤其解決。一旦Bug fix完成后，大多數情況下我們就把這份bug list束之高閣，偶爾能想到的用途就是拿出來衡量測試組的績效，或者用來評估開發組的質量表現。

    一般來說質量分析有以下集中情況

• 利用缺陷引入-發現矩陣分析

    缺陷有發現階段和引入階段兩個重要指標，發現階段和引入階段可以是軟件生命周期的各個階段，根據這兩個階段可以繪制出一個矩陣，從而分析出軟件開發各個環節的開展質量，找到最需要改進的環節。

    開始例子分析之前先解釋一下缺陷引入-發現矩陣的一些概念。

    矩陣的每行表示該階段或活動發現的各階段產生的缺陷數；矩陣的每列表示該階段或活動引入的缺陷泄露到后續各環節的缺陷數。

    缺陷移除率定義為：缺陷移除率=(本階段發現的缺陷數/本階段引入的缺陷數)*100%。如需求階段一共引入了15個缺陷，需求評審時候只發現了2個，設計過程中發現了10個，編碼和單元測試階段發現了兩個，還有一個直到系統測試階段才被發現。這樣，需求階段的缺陷移除率=2/15*100%=13%。它反映的是該活動階段的缺陷清除能力。

    反過來還有一個概念，缺陷泄露率，就是有多少本階段引入的缺陷沒有在本階段發現而是被泄露到后階段環節才被發現。其計算公式為：缺陷泄漏率=（下游發現的本階段的缺陷數/本階段注入的缺陷總數）*100%。顯然，它等于[1-缺陷移除率]。它反映的是本階段質量控制措施落實的成效。

    下面是一個分析例子：

    從上表可以看到，編碼過程的缺陷大部分依賴系統測試發現。單元測試和集成測試活動開展不夠深入。我們可以進一步分析這些系統測試出來的測試缺陷，是不是可以被更前端的評審/測試/設計討論活動所替代。詳細見“四、利用泄漏的下游缺陷回溯過程有效性”

    另外，我們看到，需求階段引入的缺陷絕大部分是在設計階段發現的。這可能是我們大部分項目的一個現實，需求不穩定、需求不明確，很多東西需要在設計過程中才能明確下來。也許從這個分析結果中給我們一個啟示，我們在設計評審時候，也需要重新審視我們的需求規格說明書，必要時候利用需求追蹤矩陣這樣的規矩方法來輔助我們發現上游需求的缺陷。把這樣的機制固化起來，作為我們標準研發過程的一個要素或者過程指導書。

    當然，實際規劃“缺陷引入-發現矩陣”時，可以依據自己的管理要求，對缺陷的發現活動和引入階段進行細分或初分，并且在Bug系統中提交時，需要準確的填寫這些屬性字段。

• 利用缺陷的分布進行分析

    可以選某個階段的測試缺陷進行分析，按照這些缺陷對應的產品組成部分來匯總這些數據。利用這樣的分布，可以找出我們產品/項目的高危模塊來。這些模塊導致了我們產品的主要缺陷。主要用到的分析手段是數據透視表和柏拉圖。讓我們看看下面的例子：

    這是一個簡單的OA系統，它只有5個子系統。我們把這些子系統各有多少缺陷列出來，找到了改善質量的關鍵模塊是后臺交易模塊。

    像上圖，這是一個較為復雜的MIS系統，有近20個功能塊。這個時候，可以利用柏拉圖識別出占80%問題的那少數模塊，針對其采取強于其它產品組成部分的質量控制措施。

    需要指出的是：采用缺陷分布只是分析的第一步。它只不過提供了你分析影響產品質量的那些重點模塊，其信息不足以給出更深層次的原因。需要針對這些高危模塊進行進一步的分析，識別缺陷的產生根源。

    當然，也有人認為絕對數去衡量缺陷的分布并不合適，所以有些人也會把缺陷按照嚴重程度對應一定的權重系數折算成分析意義上的標準故障。如上表，折算系數為，嚴重*10，關鍵*5，一般*3，次要*1，優化*0。

    這種分析需要我們的bug系統建立產品組件的概念，使得缺陷填報人能夠正確的填報每個缺陷的產品組件位置。

• 利用缺陷的階段分布模型進行質量預測

    假設我們為bug管理系統建立了“一、利用缺陷引入-發現矩陣分析”中描述的缺陷引入-缺陷發現階段信息，那么我們可以對相似的項目的缺陷階段分布進行度量，形成該類型項目的缺陷分布的過程模型。它給予我們的信息是：只要是這種類型的項目，按照相似的過程方法進行研發，那么其質量表現也是相似的。

    我們之所以作這樣的假設，是有一個前提，就是我們研發過程是高度一致的，并且過程的表現也是穩定的。這樣，我們得出的過程能力模型才具有可信度。

    下面是一個如何運用測試分布模型進行質量預測的例子：

    如果需求階段發現了10個缺陷，就可以預計到設計階段我大概要清除70個缺陷，依次可以估計到后階段各個環節的缺陷數，作為我們該階段工作的交付準則。并且，可以預測到產品發布后的使用表現會出現大約2個故障泄露到用戶手中。

    這種分析預測模型的建立，要求組織的測試/評審過程比較穩定。即組織整體達到CMMI三級成熟度，同時在VAL和VER（驗證和確認）過程域的達到CMMI四級的成熟度級別，即量化管理級別。

• 利用泄漏的下游缺陷回溯過程有效性

    經驗告訴我們，越到后端發現的缺陷，用于問題復現、問題定位和bug修復的時間就越多。那么我們是不是可以在項目研發的更前端發現這些缺陷呢？有什么方式讓我們識別項目研發前端哪些活動沒有充分投入、或者沒有運用合適的工程/技術方法導致這些問題被泄露到下游呢？

    其實，我們有很簡便的方法可以達到這個目的。從團隊的典型項目中運用一定的抽樣原則抽樣出某個階段的若干個缺陷，從技術、流程、工程方法、費效比方面去分析其更適合、更經濟的清除方法。然后把這些方法固化到我們日常的項目實施過程中，逐步就可以降低上游對后端的缺陷泄露。

    下面以對一個項目的系統測試階段發現的故障為例進行過程有效性回溯分析：

    從上表可以看出，真正需要遺留到系統測試階段才能發現的故障只有7%，大部分故障應該在集成測試和設計評審過程中就應該發現的。

    導致在集成測試過程中未能充分發現這些缺陷的原因主要有：

    1、測試環境不具備，導致部分測試項必須到系統測試階段才具備測試條件；

    2、測試設計中某些測試項的缺失，需要加強測試設計的評審工作；

    3、回歸測試過程中，開發部只是對測試故障進行驗證，而對bug fix波及的范圍缺乏分析和驗證；

    這樣，針對這些分析結論，我們就可以制定針對性的整改措施。如：

• 加強開發部的故障波及分析及波及分析驗證工作；
• 項目計劃中加強對測試需求的關注，提前采購和協調必要的測試環境；
• 每次回歸對泄露的缺陷開發部都作相應的復盤，并根據復盤結果，完善單元測試和集成測試的測試設計；
  
• 利用缺陷分類來進行缺陷的根源分析

    對于測試出來的BUG進行缺陷分類，按照BUG的類型分布，找出那些關鍵的缺陷類型，進一步分析其產生的根源，從而針對性的制定改進措施。

    下面以一個項目的系統測試故障為例進行分析：

    從系統測試故障來看，有較多故障是由接口原因造成的，細分有以下幾種原因：

    1、跨項目間的接口，接口設計文檔的更改沒有建立互相通知的機制，導致接口問題到系統測試時候才暴露出來；

    2、部門內部跨子系統的接口，由于本項目設計文檔按功能規劃編寫的，而不是按照產品組件，一般由主要承接功能工作的組編寫該文檔，接口內容可能不為其他開發組理解并熟悉，導致因接口問題而出錯；

    3、系統設計基線化后，更改系統接口，沒有走嚴格的變更流程，進行波及分析，導致該接口變更只在某個子系統中被修改，而使錯誤遺漏下來；

    那么我們可以針對性的制定改進建議：

    1、對接口文檔的評審一定要識別受影響的相關干系人，使他們了解并參與接口設計的把關；

    2、對基線化的接口設計文檔的變更一定要提交變更單給ＣＣＢ決策，并做好充分的波及影響分析，以便同步修改所有關聯的下游代碼；

    3、概要設計文檔按子系統規劃，詳細設計文檔按模塊規劃，通過相關組參加評審協調接口設計；

    以上例子的缺陷分類只是為了描述方便，本身描述并不盡合理。實際定義缺陷分類可能有很多個維度，如發現活動、引入活動、缺陷來源、缺陷類型、嚴重程度等。只要滿足自己的缺陷管理、缺陷分析需求即可。

• 缺陷收斂趨勢分析

    項目管理中一項非常重要但也十分困難的工作是衡量項目的進度、質量、成本等，統稱為項目的狀態，以確定項目是否能按期保質完成。這方面，測試提供了兩個非常重要的參數，一個是缺陷數量的趨勢，另一個是缺陷修復的趨勢。（注：此節所說的測試均指代系統測試）

    缺陷趨勢就是將每月新生成的缺陷數、每月被解決的缺陷數和每月遺留的缺陷數標成一個趨勢圖表。一般在項目的開始階段發現缺陷數曲線會呈上升趨勢，到項目中后期被修復缺陷數曲線會趨于上升；而發現缺陷數曲線應總體趨于下降；同時處于OPEN狀態的缺陷也應該總體呈下降趨勢，到項目最后，三條曲線都趨向于零。如：

    項目經理會持續觀察這張圖表，確保項目健康發展，同時通過分析預測項目測試缺陷趨于零的時間。在一定的歷史經驗的基礎上分析使用這一圖表會得到很多有價值的信息，比如說，可分析開發和測試在人力資源的配比上是否恰當，可以分析出某個嚴重的缺陷所造成的項目質量的波動。對于異常的波動，如本來應該越測試越收斂的，卻到了某個點，發現的故障數反而呈上升趨勢，那么，這些點往往有一些特殊事件的發生。如：

• 在該時間段送測的回歸版本增加了新的功能，導致缺陷引入；
• 該回歸版本開發部沒有進行集成測試就直接送測？等等。

    當然，這個統計周期也可以根據我們的項目實施情況進行。如按照回歸版本的版本號進行統計、按周進行統計等。也有公司把缺陷收斂情況當作判斷版本是否可以最終外發的一個標志。

    小結：

    通過對測試缺陷分析，能夠給予我們很多改進研發和測試工作的信息。

    當然，這種分析來源于一個前提，我們需要規劃一個好的Bug管理系統，滿足我們這些分析的信息需要。另外，我們的研發過程是穩定的，其質量表現大體是一致的，這樣數據反映的趨勢才具備可信度