基于缺陷模式的軟件測試(第12章)

1、12內容提要內容提要p12.1概述概述l12.1.1 相關定義l12.1.2 軟件缺陷的產生原因l12.1.3 減少缺陷的關鍵因素l12.1.4 軟件缺陷的特征p12.2軟件缺陷屬性軟件缺陷屬性l12.2.1 缺陷類型l12.2.2 缺陷嚴重程度l12.2.3 同行評審錯誤嚴重程度l12.2.4 缺陷優(yōu)先級l12.2.5 缺陷狀態(tài)l12.2.6 缺陷起源l12.2.7 缺陷來源l12.2.8 缺陷根源3內容提要內容提要p12.3軟件缺陷的嚴重性和優(yōu)先級軟件缺陷的嚴重性和優(yōu)先級l12.3.1 缺陷的嚴重性和優(yōu)先級的關系l12.3.2 處理缺陷的嚴重性和優(yōu)先級的常見錯誤l12.3.3 缺陷的嚴重性

2、和優(yōu)先級的表示和確定p12.4 軟件缺陷管理和軟件缺陷管理和CMM的關系的關系l12.4.1 初始級的缺陷管理l12.4.2 可重復級的缺陷管理l12.4.3 已定義級的缺陷管理l12.4.4 定量管理級的缺陷管理l12.4.5 持續(xù)優(yōu)化級的缺陷管理4內容提要內容提要p12.5 報告軟件缺陷報告軟件缺陷l12.5.1 報告軟件缺陷的基本原則l12.5.2 IEEE軟件缺陷報告模板p12.6軟件缺陷管理軟件缺陷管理l12.6.1 缺陷管理目標l12.6.2 人員職責l12.6.3 缺陷生命周期l12.6.4 缺陷管理系統(tǒng)p12.7軟件缺陷分析軟件缺陷分析l12.7.1 缺陷分析方法l12.7.2

3、 缺陷分析指標p12.8小結小結512.1概述概述p軟件業(yè)的發(fā)展推動了社會經濟的快速發(fā)展，但是軟件質量軟件業(yè)的發(fā)展推動了社會經濟的快速發(fā)展，但是軟件質量卻變得越來越難以控制。從某種程度上說，軟件產品的競卻變得越來越難以控制。從某種程度上說，軟件產品的競爭力已經不完全取決于技術的先進，更重要的是取決于軟爭力已經不完全取決于技術的先進，更重要的是取決于軟件質量的穩(wěn)定。件質量的穩(wěn)定。p然而對于軟件開發(fā)而言軟件缺陷始終是不可避免的，為此然而對于軟件開發(fā)而言軟件缺陷始終是不可避免的，為此付出的代價和成本是巨大的。付出的代價和成本是巨大的。l研究表明，大約有60%的錯誤是在設計階段之前注入的，并且修正一個

4、軟件錯誤所需要的費用將隨著軟件生存期的進展而上升。l錯誤發(fā)現得越晚，修復它的費用就越高，而且呈指數上升的趨勢。p在軟件的編碼測試階段遺漏編碼缺陷，如果到系統(tǒng)測試時在軟件的編碼測試階段遺漏編碼缺陷，如果到系統(tǒng)測試時才發(fā)現，那么這時糾正缺陷所花費的成本是在編碼階段糾才發(fā)現，那么這時糾正缺陷所花費的成本是在編碼階段糾錯花費的成本的錯花費的成本的7倍以上，而且測試后程序中殘存的錯誤倍以上，而且測試后程序中殘存的錯誤數目與該程序中已發(fā)現的錯誤數目（即檢錯率）很可能成數目與該程序中已發(fā)現的錯誤數目（即檢錯率）很可能成正比。正比。6殘存的錯誤和已發(fā)現的錯誤數目殘存的錯誤和已發(fā)現的錯誤數目的關系的關系 712

5、.1.1 相關定義相關定義p軟件錯誤軟件錯誤：軟件錯誤是指在軟件生存期內的不希望或不可接受：軟件錯誤是指在軟件生存期內的不希望或不可接受的人為錯誤，其結果是導致軟件缺陷的產生。可見，軟件錯誤的人為錯誤，其結果是導致軟件缺陷的產生?？梢?，軟件錯誤是一種人為過程，相對于軟件本身，是一種外部行為。是一種人為過程，相對于軟件本身，是一種外部行為。p軟件缺陷軟件缺陷：軟件缺陷是存在于軟件（文檔，數據或程序）之中：軟件缺陷是存在于軟件（文檔，數據或程序）之中的那些不希望或不可接受的偏差。其結果是軟件運行于某一特的那些不希望或不可接受的偏差。其結果是軟件運行于某一特定條件時出現軟件故障，這時稱軟件缺陷被激活

6、。定條件時出現軟件故障，這時稱軟件缺陷被激活。p軟件故障軟件故障：軟件故障是指軟件運行過程中出現的一種不希望或：軟件故障是指軟件運行過程中出現的一種不希望或不可接受的內部狀態(tài)。比如：軟件處于執(zhí)行一個多余循還過程不可接受的內部狀態(tài)。比如：軟件處于執(zhí)行一個多余循還過程時，我們說軟件出現故障。若此時沒有適當的措施（容錯）加時，我們說軟件出現故障。若此時沒有適當的措施（容錯）加以處理，便產生軟件失效。軟件故障是一種動態(tài)行為。以處理，便產生軟件失效。軟件故障是一種動態(tài)行為。p軟件失效軟件失效：軟件失效是指軟件運行時產生的一種不希望或不可：軟件失效是指軟件運行時產生的一種不希望或不可接受的外部行為結果。接

7、受的外部行為結果。 軟件失效機理8p軟件缺陷管理：在軟件開發(fā)過程中對所發(fā)軟件缺陷管理：在軟件開發(fā)過程中對所發(fā)現的缺陷進行跟蹤并確保每個被發(fā)現的軟現的缺陷進行跟蹤并確保每個被發(fā)現的軟件缺陷被關閉。件缺陷被關閉。p邏輯上僅有邏輯上僅有2種方法應用于開發(fā)低缺陷的種方法應用于開發(fā)低缺陷的軟件軟件l缺陷預防l缺陷排除912.1.2 軟件缺陷的產生原因軟件缺陷的產生原因p程序編寫錯誤程序編寫錯誤p編寫程序未按照規(guī)定編寫程序未按照規(guī)定p軟件越來越復雜軟件越來越復雜p開發(fā)人員的態(tài)度開發(fā)人員的態(tài)度p溝通上的問題溝通上的問題p需求變更太過頻繁需求變更太過頻繁p進度上的壓力進度上的壓力p管理上的失誤管理上的失誤系統(tǒng)

8、開發(fā)的三個平衡點1012.1.3 減少缺陷的關鍵因素減少缺陷的關鍵因素p軟件在版本發(fā)布后發(fā)現和解決一個軟件存在的問題所需的費用，軟件在版本發(fā)布后發(fā)現和解決一個軟件存在的問題所需的費用，通常要比在需求和設計階段發(fā)現、解決問題高出約通常要比在需求和設計階段發(fā)現、解決問題高出約100倍；倍；p當前的軟件項目約當前的軟件項目約40%到到50%的費用花費在可以避免的重復的費用花費在可以避免的重復工作上；工作上；p大約大約80%的可避免的重復工作產生于的可避免的重復工作產生于20%的缺陷；的缺陷；p大約的大約的80%缺陷產生于缺陷產生于20%的模塊，約一半的模塊缺陷是很的模塊，約一半的模塊缺陷是很少的；少

9、的；p大約的大約的90%軟件故障來來自于的軟件故障來來自于的10%缺陷；缺陷；p有效的審核可以找出約有效的審核可以找出約60%的缺陷；的缺陷；p有的目的性審核能夠比無方向的審核多捕獲約有的目的性審核能夠比無方向的審核多捕獲約35%的缺陷；的缺陷；p人員的專業(yè)性訓練可減少高達約人員的專業(yè)性訓練可減少高達約75%的缺陷出現率；的缺陷出現率；p同等情況下，開發(fā)高可信賴的軟件產品與開發(fā)低可信賴的軟件同等情況下，開發(fā)高可信賴的軟件產品與開發(fā)低可信賴的軟件產品相比，成本要高出近產品相比，成本要高出近50%。然而，如果考慮到軟件項目的。然而，如果考慮到軟件項目的運行和維護成本的話，這種投資是完全值得的；運行

10、和維護成本的話，這種投資是完全值得的；p大約大約40%到到50%的用戶程序都包含有非常細小的缺陷。的用戶程序都包含有非常細小的缺陷。1112.1.4 軟件缺陷的特征軟件缺陷的特征1、缺陷的發(fā)生都是有原因的2、缺陷的重現性3、缺陷的累積性、放大性（見下頁圖所示）4、缺陷的修復可能又引進新的缺陷12典型瀑布模型的軟件缺陷的累積和放大效應1312.2軟件缺陷屬性軟件缺陷屬性 認識軟件缺陷，首先了解軟件缺陷的概念，軟件缺陷的描述方法，其次就是了解軟件缺陷的屬性。對于開發(fā)人員，需要定義軟件缺陷屬性，作為參考，按照優(yōu)先級、嚴重程度修復軟件缺陷，不至于遺漏嚴重的軟件缺陷。對于測試人員，利用軟件缺陷屬性可以跟

11、蹤軟件缺陷，保證軟件質量。14p缺陷標識（缺陷標識（Identifier）：缺陷標識是標記某個缺陷的一：缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識；組符號。每個缺陷必須有一個唯一的標識；p缺陷缺陷類型類型 （Type）：缺陷類型是根據缺陷的自然屬性劃：缺陷類型是根據缺陷的自然屬性劃分的缺陷種類，一般包括功能缺陷、用戶界面缺陷、文檔分的缺陷種類，一般包括功能缺陷、用戶界面缺陷、文檔缺陷、軟件配置缺陷、性能缺陷、系統(tǒng)缺陷、軟件配置缺陷、性能缺陷、系統(tǒng)/模塊接口缺陷等；模塊接口缺陷等；p缺陷嚴重程度缺陷嚴重程度 （Severity）：缺陷嚴重程度是指因缺陷：缺陷嚴重程度是指因缺陷

12、引起的故障對軟件產品的影響程度；引起的故障對軟件產品的影響程度；p缺陷優(yōu)先級（缺陷優(yōu)先級（Priority）：缺陷的優(yōu)先級指缺陷必須被修：缺陷的優(yōu)先級指缺陷必須被修復的緊急程度；復的緊急程度；p缺陷狀態(tài)（缺陷狀態(tài)（Status）：缺陷狀態(tài)指缺陷通過一個跟蹤修：缺陷狀態(tài)指缺陷通過一個跟蹤修復過程的進展情況；復過程的進展情況；p缺陷起源（缺陷起源（Origin）：缺陷來源指缺陷引起的故障或事：缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段；件第一次被檢測到的階段；p缺陷來源（缺陷來源（Source）：缺陷來源指引起缺陷的起因；：缺陷來源指引起缺陷的起因；p缺陷根源（缺陷根源（Root Caus

13、e）：缺陷根源指發(fā)生錯誤的根本：缺陷根源指發(fā)生錯誤的根本因素。因素。1512.2.1 缺陷類型缺陷類型缺陷類型缺陷類型編號編號缺陷類型缺陷類型描述描述10F- Function影響了重要的特性、用戶界面、產品接口、硬件結構接口和全局數據結構。并且設計文檔需要正式的變更。如邏輯，指針，循環(huán)，遞歸，功能等缺陷。20A- Assignment需要修改少量代碼，如初始化或控制塊。如聲明、重復命名，范圍、限定等缺陷。30I- Interface與其他組件、模塊或設備驅動程序、調用參數、控制塊或參數列表相互影響的缺陷。40C- Checking提示的錯誤信息，不適當的數據驗證等缺陷。50B Build/p

14、ackage/merge由于配置庫、變更管理或版本控制引起的錯誤。60D- Documentation影響發(fā)布和維護，包括注釋。70G- Algorithm算法錯誤。80U-User Interface人機交互特性：屏幕格式，確認用戶輸入，功能有效性，頁面排版等方面的缺陷。90P-Performance不滿足系統(tǒng)可測量的屬性值，如：執(zhí)行時間，事務處理速率等。100N-Norms不符合各種標準的要求，如編碼標準、設計符號等。1612.2.2 缺陷嚴重程度缺陷嚴重程度#缺陷嚴重缺陷嚴重等級等級描述描述1Critical不能執(zhí)行正常工作功能或重要功能?；蛘呶＜叭松戆踩?。2Major嚴重地影響系統(tǒng)要求

15、或基本功能的實現，且沒有辦法更正。（重新安裝或重新啟動該軟件不屬于更正辦法）3Minor嚴重地影響系統(tǒng)要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啟動該軟件不屬于更正辦法）4Cosmetic使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能。5Other其它錯誤。1712.2.3 同行評審錯誤嚴重程度同行評審錯誤嚴重程度# #缺陷嚴重等級缺陷嚴重等級描述描述1Major主要的，較大的缺陷2Minor次要的，小的缺陷1812.2.4 缺陷優(yōu)先級缺陷優(yōu)先級# #缺陷優(yōu)先級缺陷優(yōu)先級描述描述1Resolve Immediately缺陷必須被立即解決。2Normal Queue

16、缺陷需要正常排隊等待修復或列入軟件發(fā)布清單。3Not Urgent缺陷可以在方便時被糾正。1912.2.5 缺陷狀態(tài)缺陷狀態(tài)缺陷狀態(tài)缺陷狀態(tài)描述描述Submitted已提交的缺陷Open確認“提交的缺陷”，等待處理Rejected拒絕“提交的缺陷”，不需要修復或不是缺陷Resolved缺陷被修復Closed確認被修復的缺陷，將其關閉2012.2.6 缺陷起源缺陷起源缺陷起源缺陷起源描述描述Requirement在需求階段發(fā)現的缺陷 Architecture在構架階段發(fā)現的缺陷 Design在設計階段發(fā)現的缺陷 Code在編碼階段發(fā)現的缺陷 Test在測試階段發(fā)現的缺陷 2112.2.7 缺陷來

17、源缺陷來源缺陷來源缺陷來源描述描述Requirement由于需求的問題引起的缺陷 Architecture由于構架的問題引起的缺陷 Design由于設計的問題引起的缺陷 Code由于編碼的問題引起的缺陷 Test由于測試的問題引起的缺陷 Integration由于集成的問題引起的缺陷 2212.2.8 缺陷根源缺陷根源缺陷原因缺陷原因描述描述目標如：錯誤的范圍，誤解了目標，超越能力的目標等；過程，工具和方法如：無效的需求收集過程，過時的風險管理過程，不適用的項目管理方法，沒有估算規(guī)程，無效的變更控制過程等。人如：項目團隊職責交叉，缺乏培訓。沒有經驗的項目團隊，缺乏士氣和動機不純等。缺乏組織和通

18、訊如：缺乏用戶參與，職責不明確，管理失敗等。2312.3軟件缺陷的嚴重性和優(yōu)先級軟件缺陷的嚴重性和優(yōu)先級p缺陷嚴重性和缺陷優(yōu)先級是表征軟件缺陷的兩個缺陷嚴重性和缺陷優(yōu)先級是表征軟件缺陷的兩個重要因素，它影響軟件缺陷的統(tǒng)計結果和修正缺重要因素，它影響軟件缺陷的統(tǒng)計結果和修正缺陷的優(yōu)先順序，特別在軟件測試的后期，將影響陷的優(yōu)先順序，特別在軟件測試的后期，將影響軟件是否能夠按期發(fā)布。軟件是否能夠按期發(fā)布。p對于軟件測試初學者或者沒有對于軟件測試初學者或者沒有軟件開發(fā)軟件開發(fā)經驗的測經驗的測試工程師而言，對于這兩個概念的理解，對于它試工程師而言，對于這兩個概念的理解，對于它們的作用和處理方式往往理解的

19、不徹底，實際測們的作用和處理方式往往理解的不徹底，實際測試工作中不能正確表示缺陷的嚴重性和優(yōu)先級。試工作中不能正確表示缺陷的嚴重性和優(yōu)先級。l這將影響軟件缺陷報告的質量，不利于盡早處理嚴重的軟件缺陷，可能影響軟件缺陷的處理時機。2412.3.1 缺陷的嚴重性和優(yōu)先級的缺陷的嚴重性和優(yōu)先級的關系關系p嚴重性（嚴重性（Severity）顧名思義就是軟件缺陷對軟件質量）顧名思義就是軟件缺陷對軟件質量的破壞程度，反應其對產品和用戶的影響，即此軟件缺陷的破壞程度，反應其對產品和用戶的影響，即此軟件缺陷的存在將對軟件的功能和性能產生怎樣的影響。的存在將對軟件的功能和性能產生怎樣的影響。l在軟件測試中，軟件

20、缺陷的嚴重性的判斷應該從軟件最終用戶的觀點做出判斷，即判斷缺陷的嚴重性要為用戶考慮，考慮缺陷對用戶使用造成的惡劣后果的嚴重性。p優(yōu)先級表示修復缺陷的重要程度和應該何時修復，是表示優(yōu)先級表示修復缺陷的重要程度和應該何時修復，是表示處理和修正軟件缺陷的先后順序的指標，即哪些缺陷需要處理和修正軟件缺陷的先后順序的指標，即哪些缺陷需要優(yōu)先修正，哪些缺陷可以稍后修正。優(yōu)先修正，哪些缺陷可以稍后修正。l確定軟件缺陷優(yōu)先級，更多的是站在軟件開發(fā)工程師的角度考慮問題，因為缺陷的修正順序是個復雜的過程，有些不是純粹的技術問題，而且開發(fā)人員更熟悉軟件代碼，能夠比測試工程師更清楚修正缺陷的難度和風險。2512.3.

21、2 處理缺陷的嚴重性和優(yōu)先處理缺陷的嚴重性和優(yōu)先級的常見錯誤級的常見錯誤p正確處理缺陷的嚴重性和優(yōu)先級不是件非常容易正確處理缺陷的嚴重性和優(yōu)先級不是件非常容易的事情，對于經驗不很豐富的開發(fā)人員經常會發(fā)的事情，對于經驗不很豐富的開發(fā)人員經常會發(fā)生如下的情形：生如下的情形：l將比較輕微的缺陷報告成較高級別的缺陷和高優(yōu)先級，夸大缺陷的嚴重程度，經常給人“狼來了”的錯覺，將影響軟件質量的正確評估，也耗費開發(fā)人員辨別和處理缺陷的時間。l將很嚴重的缺陷報告成輕微缺陷和低優(yōu)先級，這樣可能掩蓋了很多嚴重的缺陷。如果在項目發(fā)布前，發(fā)現還有很多由于不正確分配優(yōu)如果在項目發(fā)布前，發(fā)現還有很多由于不正確分配優(yōu)先級造成

22、的嚴重缺陷，將需要投入很多人力和時間進先級造成的嚴重缺陷，將需要投入很多人力和時間進行修正，影響軟件的正常發(fā)布。行修正，影響軟件的正常發(fā)布?；蛘哌@些嚴重的缺陷成了或者這些嚴重的缺陷成了“漏網之魚漏網之魚”，隨軟件一起，隨軟件一起發(fā)布出去，影響軟件的質量和用戶的使用信心。發(fā)布出去，影響軟件的質量和用戶的使用信心。2612.3.3 缺陷的嚴重性和優(yōu)先級的缺陷的嚴重性和優(yōu)先級的表示和確定表示和確定p對于缺陷的嚴重性，如果分為對于缺陷的嚴重性，如果分為4級，則可以參考下面的方法確定：級，則可以參考下面的方法確定：l非常嚴重的缺陷，例如，軟件的意外退出甚至操作系統(tǒng)崩潰，造成數據丟失。l較嚴重的缺陷，例如

23、，軟件的某個菜單不起作用或者產生錯誤的結果；l軟件一般缺陷，例如，本地化軟件的某些字符沒有翻譯或者翻譯不準確；l軟件界面的細微缺陷，例如，某個控件沒有對齊，某個標點符號丟失等；p對于缺陷的優(yōu)先性，如果分為對于缺陷的優(yōu)先性，如果分為4級，則可以參考下面的方法確定：級，則可以參考下面的方法確定：l最高優(yōu)先級，例如，軟件的主要功能錯誤或者造成軟件崩潰，數據丟失的缺陷。l較高優(yōu)先級，例如，影響軟件功能和性能的一般缺陷；l一般優(yōu)先級，例如，本地化軟件的某些字符沒有翻譯或者翻譯不準確的缺陷；l低優(yōu)先級，例如，對軟件的質量影響非常輕微或出現幾率很低的缺陷；2712.4 軟件缺陷管理和軟件缺陷管理和CMM的關

24、系的關系pCMM 是指是指“軟件能力成熟度模型軟件能力成熟度模型”，其英文全，其英文全稱為稱為Capability Maturity Model for Software，英文縮寫為，英文縮寫為SW-CMM，簡稱，簡稱CMM。p它是對于軟件組織在定義、實施、度量、控制和它是對于軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發(fā)展階段的描述。改善其軟件過程的實踐中各個發(fā)展階段的描述。CMM的核心是把軟件開發(fā)視為一個過程，并根的核心是把軟件開發(fā)視為一個過程，并根據這一原則對軟件開發(fā)和維護，進行過程監(jiān)控和據這一原則對軟件開發(fā)和維護，進行過程監(jiān)控和研究，以使其更加科學化、標準化、使企業(yè)能夠

25、研究，以使其更加科學化、標準化、使企業(yè)能夠更好地實現商業(yè)目標。更好地實現商業(yè)目標。2812.4.1 初始級的缺陷管理初始級的缺陷管理p處于處于CMM一級（或稱為初始級）的軟件組織，對軟件缺一級（或稱為初始級）的軟件組織，對軟件缺陷的管理無章可循。工程師們只是在發(fā)現缺陷后，修改相陷的管理無章可循。工程師們只是在發(fā)現缺陷后，修改相應的軟件。通常，沒有人會去記錄自己發(fā)現的缺陷。也沒應的軟件。通常，沒有人會去記錄自己發(fā)現的缺陷。也沒有人知道在新的軟件版本里，究竟糾正了哪些缺陷，還有有人知道在新的軟件版本里，究竟糾正了哪些缺陷，還有哪些缺陷未被糾正。哪些缺陷未被糾正。p而且，只有在下一輪測試中才有可能知

26、道那些所謂己被糾而且，只有在下一輪測試中才有可能知道那些所謂己被糾正了的缺陷是否真的被糾正了，更重要的是糾正過程是否正了的缺陷是否真的被糾正了，更重要的是糾正過程是否引入了新的缺陷。所以這樣的軟件組織的項目交貨期表現引入了新的缺陷。所以這樣的軟件組織的項目交貨期表現出強烈的不可預測性。出強烈的不可預測性。p并且，為了獲得一個高質量的軟件產品（如果能夠的話），并且，為了獲得一個高質量的軟件產品（如果能夠的話），通常要在測試上花費大量的人力。通常要在測試上花費大量的人力。2912.4.2 可重復級的缺陷管理可重復級的缺陷管理p在在 CMM 二級（或稱為可重復級）的軟件組織中，二級（或稱為可重復級）

27、的軟件組織中，軟件項目會從自身的需要出發(fā)，制定本項目的缺軟件項目會從自身的需要出發(fā)，制定本項目的缺陷管理過程。一個完備軟件缺陷管理過程通常會陷管理過程。一個完備軟件缺陷管理過程通常會包括如下幾個方面：包括如下幾個方面：l提交缺陷；l分析和定位缺陷；l提請修改相應的軟件；l修改相應的軟件；l驗證修改。p項目組會完整地記錄開發(fā)過程中的缺陷，監(jiān)控缺項目組會完整地記錄開發(fā)過程中的缺陷，監(jiān)控缺陷的修改過程，并驗證修改缺陷的結果。陷的修改過程，并驗證修改缺陷的結果。3012.4.3 已定義級的缺陷管理已定義級的缺陷管理pCMM 三級（或稱為己定義級）的軟件組織會匯三級（或稱為己定義級）的軟件組織會匯集組織

28、內部以前項目的經驗教訓，制定組織級的集組織內部以前項目的經驗教訓，制定組織級的缺陷管理過程。缺陷管理過程。p并且，要求項目根據組織級的缺陷管理過程定制并且，要求項目根據組織級的缺陷管理過程定制本項目的缺陷管理過程。本項目的缺陷管理過程。l從而，整個軟件組織中的項目都遵循類似的過程來管理缺陷。l好的缺陷管理實踐成為所有項目的實踐，而教訓也為所有項目所了解。p更重要的是，隨著組織的不斷發(fā)展完善，組織的更重要的是，隨著組織的不斷發(fā)展完善，組織的過程會得到持續(xù)性的改進，所有項目的過程也都過程會得到持續(xù)性的改進，所有項目的過程也都會相應的改進。會相應的改進。3112.4.4 定量管理級的缺陷管理定量管理

29、級的缺陷管理沒實現缺陷預防的缺陷密度CMM4（已管理級）：建立軟件過程能力基線3212.4.5 持續(xù)優(yōu)化級的缺陷管理持續(xù)優(yōu)化級的缺陷管理實現了缺陷預防的缺陷密度CMM5（持續(xù)優(yōu)化級）：強調對組織的過程進行持續(xù)性改進3312.5 報告軟件缺陷報告軟件缺陷p12.5.1 報告軟件缺陷的基本原則報告軟件缺陷的基本原則l準確報告軟件缺陷是非常重要的，因為：清晰準確的軟件缺陷描述可以減少軟件缺陷從開清晰準確的軟件缺陷描述可以減少軟件缺陷從開發(fā)人員返回的數量；發(fā)人員返回的數量；提高軟件缺陷修復的速度，使每一個小組能夠有提高軟件缺陷修復的速度，使每一個小組能夠有效的工作；效的工作；提高測試人員的信任度，可以

30、得到開發(fā)人員對清提高測試人員的信任度，可以得到開發(fā)人員對清晰的軟件缺陷描述有效的響應；晰的軟件缺陷描述有效的響應；加強開發(fā)人員，測試人員和管理人員的協(xié)同工作，加強開發(fā)人員，測試人員和管理人員的協(xié)同工作，讓他們可以更好的工作；讓他們可以更好的工作；34軟件缺陷的有效描述規(guī)則軟件缺陷的有效描述規(guī)則p軟件缺陷的有效描述規(guī)則，主要包括：軟件缺陷的有效描述規(guī)則，主要包括：l單一準確。每個報告只針對一個軟件缺陷。在一個報告中報告多個軟件缺陷的弊端是常常會導致缺陷部分被注意和修復，不能得到徹底的修正。l可以再現。提供缺陷的精確操作步驟，使開發(fā)人員容易看懂，可以自己再現這個缺陷，通常情況下，開發(fā)人員只有再現了

31、缺陷，才能正確地修復缺陷。l完整統(tǒng)一。提供完整、前后統(tǒng)一的軟件缺陷的步驟和信息，例如：圖片信息，Log文件等。l短小簡練。通過使用關鍵詞，可以使軟件缺陷的標題的描述短小簡練，又能準確解釋產生缺陷的現象。如“主頁的導航欄在低分辨率下顯示不整齊”中“主頁”、“導航欄”、“分辨率”等是關鍵詞。l特定條件。許多軟件功能在通常情況下沒有問題，而是在某種特定條件下會存在缺陷，所以軟件缺陷描述不要忽視這些看似細節(jié)的但又必要的特定條件（如特定的操作系統(tǒng)、瀏覽器或某種設置等），能夠提供幫助開發(fā)人員找到原因的線索。如“搜索功能在沒有找到結果返回時跳轉頁面不對”。l補充完善。從發(fā)現bug那一刻起，測試人員的責任就是

32、保證它被正確的報告，并且得到應有的重視，繼續(xù)監(jiān)視其修復的全過程。l不做評價。在軟件缺陷描述不要帶有個人觀點，對開發(fā)人員進行評價。軟件缺陷報告是針對產品、針對問題本身，將事實或現象客觀地描述出來就可以，不需要任何評價或議論。3512.5.2 IEEE軟件缺陷報告模板軟件缺陷報告模板3612.6軟件缺陷管理軟件缺陷管理p12.6.1 缺陷管理目標缺陷管理目標l由于不同的軟件開發(fā)組織在軟件開發(fā)過程、質量保證體系的不同，缺陷管理的方式和處理流程也不盡相同。但其目的都是對各階段測試發(fā)現的缺陷進行跟蹤管理，以保證各級缺陷的修復率達到標準。一般而言缺陷管理應當具有以下目標：及時了解并跟蹤每個被發(fā)現的缺陷；及

33、時了解并跟蹤每個被發(fā)現的缺陷；確保每個被發(fā)現的缺陷都能夠被處理。這里處理的意思不一確保每個被發(fā)現的缺陷都能夠被處理。這里處理的意思不一定是被修正，也可能是其他處理方式（例如，在下一個版本定是被修正，也可能是其他處理方式（例如，在下一個版本中修正）。對于每個被發(fā)現的缺陷的處理方式應當在開發(fā)組中修正）。對于每個被發(fā)現的缺陷的處理方式應當在開發(fā)組織內中達成一致?？梼戎羞_成一致。收集缺陷數據并根據缺陷趨勢曲線來識別測試過程是否結束。收集缺陷數據并根據缺陷趨勢曲線來識別測試過程是否結束。決定測試過程是否結束有很多種方式，通過缺陷趨勢曲線來決定測試過程是否結束有很多種方式，通過缺陷趨勢曲線來確定測試過程是

34、否結束是常用并且較為有效的一種方式。確定測試過程是否結束是常用并且較為有效的一種方式。收集缺陷數據并在其上進行數據分析，作為組織的過程財富。收集缺陷數據并在其上進行數據分析，作為組織的過程財富。3712.6.2 人員職責人員職責p參與缺陷管理過程人員角色包括項目經理、項目測試負責人、測試人員、參與缺陷管理過程人員角色包括項目經理、項目測試負責人、測試人員、項目相關開發(fā)人員、質量保證人員，其職責描述如下：項目相關開發(fā)人員、質量保證人員，其職責描述如下：l項目經理（PM）：負責指派缺陷給相關責任人。負責指派缺陷給相關責任人。l項目測試負責人（TM）:決定缺陷管理方式和工具，擬定決策評審計劃；決定缺

35、陷管理方式和工具，擬定決策評審計劃；管理所有缺陷關閉情況；管理所有缺陷關閉情況；審核測試人員提交的缺陷；審核測試人員提交的缺陷；對測試人員的工作質量進行跟蹤與評價。對測試人員的工作質量進行跟蹤與評價。l測試人員（TE）負責報告系統(tǒng)缺陷記錄，且協(xié)助項目人員進行缺陷定位；負責報告系統(tǒng)缺陷記錄，且協(xié)助項目人員進行缺陷定位；負責驗證缺陷修復情況，且填寫缺陷記錄中相應信息；負責驗證缺陷修復情況，且填寫缺陷記錄中相應信息；負責執(zhí)行系統(tǒng)回歸測試；負責執(zhí)行系統(tǒng)回歸測試；提交缺陷報告；提交缺陷報告；負責被測軟件進行質量數據和分析。負責被測軟件進行質量數據和分析。l項目相關開發(fā)人員（DE）修改測試發(fā)現的缺陷，并提

36、交成果物做再測試；修改測試發(fā)現的缺陷，并提交成果物做再測試；負責接收各自的缺陷記錄，并且修改；負責接收各自的缺陷記錄，并且修改；負責提供缺陷記錄跟蹤中其它相應信息。負責提供缺陷記錄跟蹤中其它相應信息。l質量保證人員（SQA）監(jiān)控項目組缺陷管理規(guī)程執(zhí)行情況。監(jiān)控項目組缺陷管理規(guī)程執(zhí)行情況。3812.6.3 缺陷生命周期缺陷生命周期p軟件缺陷的狀態(tài)在其生命周期中變化如下：軟件缺陷的狀態(tài)在其生命周期中變化如下：l缺陷從隱藏在產品中被發(fā)現，這時缺陷狀態(tài)為“創(chuàng)建”。l得到缺陷修復請求以后，開發(fā)經理將缺陷修復任務分配給相應的開發(fā)人員進行修復，這時缺陷的狀態(tài)變?yōu)椤耙逊峙洹?。l開發(fā)人員得到缺陷修復任務以后，根

37、據缺陷的描述重現缺陷的癥狀、修復缺陷，然后提交測試人員驗證修改，這時缺席的狀態(tài)變?yōu)椤耙研迯汀?。l測試人員驗證修改的有效性，若缺陷的修正得到最終確認，其狀態(tài)變?yōu)椤耙汛_認”。l最終缺陷提交者或者測試人員，關閉這個缺陷，結束其生命周期。這時缺陷狀態(tài)變?yōu)椤耙殃P閉”?；镜能浖毕萆芷?9實踐中的軟件缺陷生命周期實踐中的軟件缺陷生命周期 實踐中的軟件缺陷生命周期4012.6.4 缺陷管理系統(tǒng)缺陷管理系統(tǒng)p缺陷管理系統(tǒng)是用來管理軟件缺陷整個生命的工作流系統(tǒng)，跟蹤缺陷從發(fā)生缺陷管理系統(tǒng)是用來管理軟件缺陷整個生命的工作流系統(tǒng)，跟蹤缺陷從發(fā)生到被修正并發(fā)布的整個過程。到被修正并發(fā)布的整個過程。p它能夠加強缺

38、陷修正的過程控制，是缺陷管理的實現工具。缺陷跟蹤系統(tǒng)能它能夠加強缺陷修正的過程控制，是缺陷管理的實現工具。缺陷跟蹤系統(tǒng)能否成功的實施取決于相應的缺陷跟蹤流程的設計和軟件設計。其作用主要表否成功的實施取決于相應的缺陷跟蹤流程的設計和軟件設計。其作用主要表現在：現在：l提高軟件缺陷報告的質量。軟件缺陷報告的一致性和正確性是衡量軟件測試過程專業(yè)化程度的重要指標之一。通過正確和完整填寫軟件缺陷管理系統(tǒng)提供的各項內容，可以保證不同測試工程師的缺陷報告格式統(tǒng)一。l實時管理和控制缺陷狀態(tài)。軟件缺陷查詢、篩選、排序、添加、修改保存、權限控制是缺陷管理系統(tǒng)的基本功能和主要優(yōu)勢。通過方便的數據庫查詢和分類篩選，便于迅速定位缺陷和統(tǒng)計缺陷的類型。通過權限設置，保證只有適當權限的人才能修改或刪除軟件缺陷，確保了數據安全性。l量化修復工作量。通過缺陷管理系統(tǒng)建立對缺陷數據的分析功能可以幫助軟件組織對員工績效、項目進展情況等等進行評估，幫助企業(yè)改進軟件過程提高員工工作效率。l確保每一個缺陷能被處理，避免缺陷被遺忘或信息丟失等情況的發(fā)生。l提供解決問題的知識，開發(fā)人員利用缺陷跟蹤系統(tǒng)，對已解決的問題所采用方法進行學習，提高軟件缺陷修復效率。pBugzillapClearQuest41缺陷管理系統(tǒng)比較缺陷管理系統(tǒng)比較 工具名