軟件的缺陷分析

1、文檔來源為 :從網(wǎng)絡(luò)收集整理.word 版本可編輯.歡迎下載支持軟件的缺陷分析一、缺陷分析的作用軟件缺陷不只是通常所說程序中存在的錯誤或疏忽，即俗稱的 Bug。其范圍更大，除程序外還包括其相關(guān)產(chǎn)品：項目計劃、需求規(guī)格說明、設(shè)計文檔、測試用例、用戶手冊等等中存在的錯誤和問題。 需要強調(diào)， 在軟件工程整個生命周期中任何背離需求、 無法正確完成用戶所要求的功能的問題， 包括存在于組件、 設(shè)備或系統(tǒng)軟件中因異常條件不支持而導(dǎo)致系統(tǒng)的失敗等都屬于缺陷的范疇。軟件測試的任務(wù)就是發(fā)現(xiàn)軟件系統(tǒng)的缺陷，保證軟件的優(yōu)良品質(zhì)。但在軟件中是不可能沒有缺陷的。 即便軟件開發(fā)人員， 包括測試人員盡了努力， 也是無法完全發(fā)

2、現(xiàn)和消除缺陷。如何做到最大限度地發(fā)現(xiàn)軟件系統(tǒng)的缺陷，人們首先想到提高開發(fā)人員的素質(zhì)和責(zé)任心，科學(xué)地應(yīng)用測試方法和制定優(yōu)秀的測試方案。 但這是不夠的， 我們還需要實施缺陷分析。 缺陷分析是將軟件開發(fā)、 運行過程中產(chǎn)生的缺陷進(jìn)行必要的收集， 對缺陷的信息進(jìn)行分類和匯總統(tǒng)計，計算分析指標(biāo)，編寫分析報告的活動。通過缺陷分析，發(fā)現(xiàn)各種類型缺陷發(fā)生的概率，掌握缺陷集中的區(qū)域、明晰缺陷發(fā)展趨勢、了解缺陷產(chǎn)生主要原因。以便有針對性地提出遏制缺陷發(fā)生的措施、降低缺陷數(shù)量。對于改進(jìn)軟件開發(fā)，提高軟件質(zhì)量有著十分重要的作用。缺陷分析報告中的統(tǒng)計數(shù)據(jù)及分析指標(biāo)既是對軟件質(zhì)量的權(quán)威評估， 也是判定軟件是否能發(fā)布或交付使

3、用的重要依據(jù)。二、管理軟件的缺陷分析不同于系統(tǒng)、工具、工控、游戲等軟件，管理軟件在實際運行時面臨情況要復(fù)雜得多。首先是用戶的需求更加不統(tǒng)一， 而且隨時間的推移需求發(fā)生變化快、 變化大； 其次運行環(huán)境更復(fù)雜，除受操作系統(tǒng)、 數(shù)據(jù)庫等影響外，用戶在網(wǎng)絡(luò)、 甚至同一計算機安裝運行不同性質(zhì)和背景的應(yīng)用軟件， 其影響很難預(yù)測；再者客戶的操作習(xí)性不同， 等等。因此管理軟件的種種缺陷，不是在開發(fā)時通過測試都能預(yù)計的。預(yù)測并控制缺陷有效手段之一是缺陷分析。在高級別的 CMM 中就包含了缺陷分析活動。缺陷分析更是一種以發(fā)展方式進(jìn)行軟件過程改進(jìn)的機制。三、缺陷的信息收集軟件工程通常要求為開發(fā)項目建立缺陷管理庫，

4、也有人稱為變更控制庫。從發(fā)現(xiàn)缺陷開始創(chuàng)建變更，直到缺陷解決、經(jīng)驗證、關(guān)閉變更止。 在缺陷管理的整個生命周期記錄了大量相關(guān)資料，它們是缺陷分析所需要的寶貴信息。由于變更庫并不專為缺陷分析而設(shè)計，缺陷分析主要關(guān)心以下信息項：變更編號、變更主題、變更提交的日期、變更狀態(tài)、變更性質(zhì)、變更解決的日期、變更產(chǎn)生的根本原因、解決變更的工作量、驗證變更的工作量、變更的嚴(yán)重性等級、變更所屬軟件產(chǎn)品及子系統(tǒng)、變更修改的模塊、變更產(chǎn)生的階段、變更來源、變更測試情況等。 缺陷信息部分是在創(chuàng)建變更時輸入的，部分是在變更解決中或解決后輸入的。為了實施統(tǒng)計，有些缺陷信息必需事先設(shè)定關(guān)鍵字。變更控制庫中有一信息項變更原因，

5、由修改缺陷程序的程序員詳細(xì)記錄缺陷產(chǎn)生的具體原因。 這項信息顯然無法直接用于分類和匯總。 變更產(chǎn)生的根本原因信息項， 則是基于 變更原因的關(guān)鍵字字段，是專為處理缺陷分析中缺陷原因而設(shè)計的信息項。軟件發(fā)布前缺陷分析所用缺陷根本原因的關(guān)鍵字，可以有下幾種實例：* 編程：原始編程出錯，沒有客觀原因。* 修改：由于修改缺陷而引發(fā)的新變更，并且引發(fā)的變更與原變更的錯誤是相關(guān)的。* 培訓(xùn)：項目組新成員培訓(xùn)不充分，或使用新工具不熟練引起的變更。* 需求文檔：需求分析文檔不明確、不詳盡等原因所引起的變更。* 信息交流：信息交流不暢，開發(fā)成員間溝通不及時引起的變更。* 外部問題：所涉及軟件模塊外部問題引起的變更

6、。* 其他：指以上各種原因之外所產(chǎn)生的變更。軟件發(fā)布后缺陷分析所用缺陷根本原因的的關(guān)鍵字，可以有下幾種實例：* 需求分析：需求分析不足等原因所引起的變更。* 系統(tǒng)設(shè)計：軟件系統(tǒng)設(shè)計種種原因所引起的變更。* 程序編碼：軟件開發(fā)階段中編程錯誤所引起的變更。* 維護(hù)：軟件發(fā)布后程序維護(hù)時引起的變更。* 實施：實施人員做軟件初始化設(shè)置或系統(tǒng)參數(shù)設(shè)置不當(dāng)?shù)?，實施時所引發(fā)的變更。* 用戶：泛指用戶不了解業(yè)務(wù)和軟件、不熟悉操作等原因產(chǎn)生的異常問題。* 數(shù)據(jù)異常：運行中不明原因引起的用戶數(shù)據(jù)混亂和異常。* 升級： 軟件版本升級過程發(fā)生的問題， 包括用戶在升級時未按規(guī)程操作產(chǎn)生的問題。* 外部問題：所涉及軟件外

7、部問題引起的變更，包括屬操作系統(tǒng)、數(shù)據(jù)庫軟件、第三方軟件所引起的問題。 * 錯誤變更：錯誤地提交的變更。包括無法重現(xiàn)出錯、所列現(xiàn)象不是錯誤的變更。* 其他：指以上各種原因之外的變更，包括變更原因不明。 測試情況信息項是應(yīng)用于分析缺陷是如何通過測試關(guān)的?？梢杂幸韵聨追N實例：* 漏測試：軟件發(fā)布前測試時沒有被發(fā)現(xiàn)的缺陷，也沒有對應(yīng)測試用例。* 條件冷僻：缺陷形成條件很冷僻，設(shè)計測試用例時很難考慮到。* 回歸測試：專指那些原先測試時是通過的、不存在錯誤，后來由于修改其他程序時產(chǎn)生的缺陷。關(guān)鍵是軟件版本或補丁發(fā)布前未進(jìn)行回歸測試，因而被漏過。* 判斷標(biāo)準(zhǔn)：測試時已發(fā)現(xiàn)該現(xiàn)象但當(dāng)時不認(rèn)為是問題，沒提交變

8、更。* 已測試：測試時已發(fā)現(xiàn)缺陷并提交變更，但缺陷沒解決。有些計算分析指標(biāo)用到的信息在變更庫中是沒有的，可通過其他渠道獲取。例如：軟件規(guī)模（軟件源代碼的行數(shù)，單位是千行） 、開發(fā)人員的平均人力成本（單位是元/ 人天） 、軟件持續(xù)運行時間（在開發(fā)階段以軟件測試的工作量來替代） 、項目總工作量等。記錄缺陷信息的關(guān)鍵是注意信息正確性。 不能有人為因素失真， 尤其像變更產(chǎn)生根本原因、變更測試情況。只有正確的信息，才能保障正確的分析結(jié)果。四、缺陷的分析1 、分析指標(biāo)缺陷分析時需計算一些分析指標(biāo)，使分析結(jié)果得到度量，以便直觀比對。分析指標(biāo)有以下幾項：* 反映產(chǎn)品質(zhì)量的指標(biāo)：缺陷密度 = 缺陷數(shù)量 / 軟件

9、規(guī)模潛在缺陷概數(shù)= （100% - 發(fā)布前缺陷去處率） * 缺陷密度* 反映產(chǎn)品可靠性的指標(biāo)：平均失效時間 = 軟件持續(xù)運行時間 / 缺陷數(shù)量* 反映缺陷發(fā)現(xiàn)及修復(fù)的效率的指標(biāo)：缺陷檢出率= 某階段當(dāng)時發(fā)現(xiàn)的缺陷 / 屬該階段的全部缺陷 * 100%發(fā)布前缺陷去處率=發(fā)布前發(fā)現(xiàn)的缺陷 / （發(fā)布前發(fā)現(xiàn)的缺陷 +軟件運行的前3 個月發(fā)現(xiàn)的缺陷 ）* 100%缺陷修正率= 修復(fù)過程中未引發(fā)其他問題的缺陷數(shù)/ 被修復(fù)缺陷的總數(shù)*100%* 反映缺陷修復(fù)成本的指標(biāo)：平均修復(fù)時間=匯缺陷修復(fù)時間/缺陷數(shù)量平均修復(fù)成本= 開發(fā)人員的平均人力成本* 平均修復(fù)時間相對返工成本= 返工的工作量/ 項目總工作量*

10、100%2、匯總統(tǒng)計在缺陷分析中可以使用統(tǒng)計方法對收集的變更進(jìn)行分類、匯總。* 缺陷發(fā)生日期統(tǒng)計：是按變更提交的年月統(tǒng)計。分析反映缺陷發(fā)生的動態(tài)趨勢。* 缺陷性質(zhì)統(tǒng)計：變更性質(zhì)屬性一般分為：缺陷變更和需求變更兩種。* 缺陷狀態(tài)分布： 變更狀態(tài)屬性分類很多， 但在缺陷分析中沒必要分那么細(xì)， 故按 3 種統(tǒng)計： 關(guān)閉、掛起和處理中。分析主要反映缺陷修改完成情況。* 缺陷按產(chǎn)品分類統(tǒng)計：該分析能顯示各軟件子系統(tǒng)的缺陷分布情況。* 缺陷按原因分類統(tǒng)計：是按變更的根本原因?qū)傩赃M(jìn)行分類統(tǒng)計，統(tǒng)計不包括需求變更。該分析能揭示缺陷原因的分布。* 缺陷測試情況統(tǒng)計：統(tǒng)計僅涉及變更的根本原因是系統(tǒng)設(shè)計、程序編碼、

11、維護(hù)和外部問題等缺陷變更。該分析能暴露軟件測試本身存在的問題。* 缺陷來源統(tǒng)計：該分析主要反映用戶或軟件代理的地區(qū)分布，發(fā)現(xiàn)一些客戶分布規(guī)律。分析統(tǒng)計表、圖可按單一屬性，也可按多個屬性進(jìn)行匯總統(tǒng)計。請看以下幾個實例。附表一、缺陷變更原因統(tǒng)計表2004/10 2004/11 2004/12 小計變更的原因數(shù)量 % 數(shù)量 % 數(shù)量% 數(shù)量%程序編碼問題 7 29 5 20 5 20 17 23系統(tǒng)設(shè)計問題 2 8 1 4 3 4維護(hù) 2 8 6 24 4 16 12 16外部問題0 1 4 1 4 2 3需求分析1 4 2 8 4 16 7 10實施 3 12 4 16 7 10升級問題 2 8

12、1 4 3 4數(shù)據(jù)異常 2 8 4 16 2 8 8 11用戶 1 4 2 8 3 4錯誤變更 1 4 1 4 7 28 9 12其它 3 12 3 4變更總數(shù) 24 25 25 74附表二：程序缺陷變更測試情況統(tǒng)計表測試情況缺陷變更原因變更數(shù)漏測試 條件冷僻 回歸測試 判斷標(biāo)準(zhǔn) 已測試程序編碼問題20 7 54 4系統(tǒng)設(shè)計問題3 1 2維護(hù)問題12 12外部問題1 1合計 36 8 5 16 4 3附圖：缺陷按產(chǎn)品分布圖3、定性分析在分析指標(biāo)、統(tǒng)計數(shù)據(jù)的基礎(chǔ)上，還需要對軟件的缺陷狀況進(jìn)行定性的分析，得出結(jié)論意見。必要時可召開相關(guān)人員的分析會進(jìn)行分析和討論。例如，根據(jù)上述附表二程序缺陷變更測試

13、情況統(tǒng)計表，可以得到以下幾點看法：在缺陷中高達(dá)92%的變更與測試把關(guān)不嚴(yán)有關(guān)。其中22%的變更屬于明顯漏測試。其中44%的變更屬于在回歸測試環(huán)節(jié)出問題。在維護(hù)階段修改缺陷程序后只對變更本身進(jìn)行驗證，而沒有進(jìn)行回歸測試，引發(fā)了新的缺陷。其中8%的缺陷在軟件發(fā)布前已測試發(fā)現(xiàn)，但沒有給予解決。根據(jù)上述分析，可采取針對性措施：增加測試的強度。將缺陷所發(fā)現(xiàn)的問題，增補到測試用例中。軟件維護(hù)階段的軟件補丁必需通過回歸測試，才能發(fā)布。軟件發(fā)布時對未關(guān)閉的變更需嚴(yán)加把關(guān)。五、軟件發(fā)布前和發(fā)布后的缺陷分析缺陷分析有兩種：軟件發(fā)布前和軟件發(fā)布后的缺陷分析。兩者的區(qū)別是：分析的變更不同前者分析的對象是軟件開發(fā)階段發(fā)

14、生的缺陷， 居多是軟件程序代碼的缺陷。 軟件發(fā)布后的缺陷分析，分析的對象是軟件運行階段發(fā)生的缺陷。現(xiàn)在更多是：軟件實施、維護(hù)、用戶操作所發(fā)生的異常問題， 不明原因引發(fā)的數(shù)據(jù)混亂， 軟件版本升級或各種運行環(huán)境引起的系統(tǒng)錯誤，還有用戶提出的新的需求變更。分析的目的也不同軟件發(fā)布前的缺陷分析主要是通過計算缺陷指標(biāo)， 評估開發(fā)階段軟件的質(zhì)量， 預(yù)測軟件上市后的運行情況， 判定軟件產(chǎn)品是否能夠發(fā)布。 軟件發(fā)布后的缺陷分析是通過定期分析掌握缺陷的分布和發(fā)展趨勢，以便控制缺陷的發(fā)生，降低維護(hù)成本。分析的內(nèi)容不同大部分的計算指標(biāo)是適用于發(fā)布前缺陷分析， 象發(fā)布前缺陷去處率是專為其設(shè)計的。 但分類統(tǒng)計只有狀態(tài)分

15、布和按原因分類統(tǒng)計比較適用。對發(fā)布后缺陷分析而言，大部分計算指標(biāo)不適用。僅平均修復(fù)時間指標(biāo)比較重要，它反映了維護(hù)階段處理缺陷的效率。 各分類統(tǒng)計基本都適用于發(fā)布后缺陷分析， 象缺陷測試情況統(tǒng)計、缺陷來源統(tǒng)計等是專為發(fā)布后分析設(shè)計的。缺陷分析除了應(yīng)用在軟件開發(fā)階段。 在軟件發(fā)布后或交付使用后， 同樣應(yīng)重視缺陷分析的作用。當(dāng)軟件產(chǎn)品推向市場后，將真正面臨考驗，涌現(xiàn)大量缺陷也會時有發(fā)生。 若處理延誤或不當(dāng)， 就會遭到用戶的抱怨和投訴。 不能簡單地靠增加維護(hù)人員來應(yīng)對， 這會造成維護(hù)成本的提高。 必需靠科學(xué)的手段來揭示軟件缺陷偏多的內(nèi)在規(guī)律和癥結(jié)所在， 有效地遏制缺陷的發(fā)生，給用戶一個滿意的交代。六、結(jié)束語我們知道了缺陷分析的作用， 但在實際中往往還是沒有對缺陷分析給予足夠的重視。 主要由于借助于變更管理、 CMM 的