摘要：

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

關(guān)鍵詞：

測試分析、過程改進、質(zhì)量預(yù)測、過程能力、缺陷

正文：

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

一般來說質(zhì)量分析有以下幾中情況

• 利用缺陷引入-發(fā)現(xiàn)矩陣分析

缺陷有發(fā)現(xiàn)階段和引入階段兩個重要指標，發(fā)現(xiàn)階段和引入階段可以是軟件生命周期的各個階段，根據(jù)這兩個階段可以繪制出一個矩陣，從而分析出軟件開發(fā)各個環(huán)節(jié)的開展質(zhì)量，找到最需要改進的環(huán)節(jié)。

開始例子分析之前先解釋一下缺陷引入-發(fā)現(xiàn)矩陣的一些概念。

矩陣的每行表示該階段或活動發(fā)現(xiàn)的各階段產(chǎn)生的缺陷數(shù)；矩陣的每列表示該階段或活動引入的缺陷泄露到后續(xù)各環(huán)節(jié)的缺陷數(shù)。

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

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

下面是一個分析例子：

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

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

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

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

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

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

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

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

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

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

• 利用缺陷的階段分布模型進行質(zhì)量預(yù)測

假設(shè)我們?yōu)閎ug管理系統(tǒng)建立了“一、利用缺陷引入-發(fā)現(xiàn)矩陣分析”中描述的缺陷引入-缺陷發(fā)現(xiàn)階段信息，那么我們可以對相似的項目的缺陷階段分布進行度量，形成該類型項目的缺陷分布的過程模型。它給予我們的信息是：只要是這種類型的項目，按照相似的過程方法進行研發(fā)，那么其質(zhì)量表現(xiàn)也是相似的。

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

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

如果需求階段發(fā)現(xiàn)了10個缺陷，就可以預(yù)計到設(shè)計階段我大概要清除70個缺陷，依次可以估計到后階段各個環(huán)節(jié)的缺陷數(shù)，作為我們該階段工作的交付準則。并且，可以預(yù)測到產(chǎn)品發(fā)布后的使用表現(xiàn)會出現(xiàn)大約2個故障泄露到用戶手中。

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

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

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

其實，我們有很簡便的方法可以達到這個目的。從團隊的典型項目中運用一定的抽樣原則抽樣出某個階段的若干個缺陷，從技術(shù)、流程、工程方法、費效比方面去分析其更適合、更經(jīng)濟的清除方法。然后把這些方法固化到我們?nèi)粘５捻椖繉嵤┻^程中，逐步就可以降低上游對后端的缺陷泄露。

下面以對一個項目的系統(tǒng)測試階段發(fā)現(xiàn)的故障為例進行過程有效性回溯分析：

從上表可以看出，真正需要遺留到系統(tǒng)測試階段才能發(fā)現(xiàn)的故障只有7%，大部分故障應(yīng)該在集成測試和設(shè)計評審過程中就應(yīng)該發(fā)現(xiàn)的。

導致在集成測試過程中未能充分發(fā)現(xiàn)這些缺陷的原因主要有：

1、測試環(huán)境不具備，導致部分測試項必須到系統(tǒng)測試階段才具備測試條件；

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

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

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

• 加強開發(fā)部的故障波及分析及波及分析驗證工作；
• 項目計劃中加強對測試需求的關(guān)注，提前采購和協(xié)調(diào)必要的測試環(huán)境；
• 每次回歸對泄露的缺陷開發(fā)部都作相應(yīng)的復盤，并根據(jù)復盤結(jié)果，完善單元測試和集成測試的測試設(shè)計；
  　
• 利用缺陷分類來進行缺陷的根源分析

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

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

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

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

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

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

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

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

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

3、概要設(shè)計文檔按子系統(tǒng)規(guī)劃，詳細設(shè)計文檔按模塊規(guī)劃，通過相關(guān)組參加評審協(xié)調(diào)接口設(shè)計；

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

• 缺陷收斂趨勢分析

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

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

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

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

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

小結(jié)：

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

當然，這種分析來源于一個前提，我們需要規(guī)劃一個好的Bug管理系統(tǒng)，滿足我們這些分析的信息需要。另外，我們的研發(fā)過程是穩(wěn)定的，其質(zhì)量表現(xiàn)大體是一致的，這樣數(shù)據(jù)反映的趨勢才具備可信度。