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

1、1第12章基于缺陷模式的軟件測試 2內容提要12.1概述12.1.1 相關定義12.1.2 軟件缺陷的產(chǎn)生原因12.1.3 減少缺陷的關鍵因素12.1.4 軟件缺陷的特征12.2軟件缺陷屬性12.2.1 缺陷類型12.2.2 缺陷嚴重程度12.2.3 同行評審錯誤嚴重程度12.2.4 缺陷優(yōu)先級12.2.5 缺陷狀態(tài)12.2.6 缺陷起源12.2.7 缺陷來源12.2.8 缺陷根源3內容提要12.3軟件缺陷的嚴重性和優(yōu)先級12.3.1 缺陷的嚴重性和優(yōu)先級的關系12.3.2 處理缺陷的嚴重性和優(yōu)先級的常見錯誤12.3.3 缺陷的嚴重性和優(yōu)先級的表示和確定12.4 軟件缺陷管理和CMM的關系12

2、.4.1 初始級的缺陷管理12.4.2 可重復級的缺陷管理12.4.3 已定義級的缺陷管理12.4.4 定量管理級的缺陷管理12.4.5 持續(xù)優(yōu)化級的缺陷管理4內容提要12.5 報告軟件缺陷12.5.1 報告軟件缺陷的基本原則12.5.2 IEEE軟件缺陷報告模板12.6軟件缺陷管理12.6.1 缺陷管理目標12.6.2 人員職責12.6.3 缺陷生命周期12.6.4 缺陷管理系統(tǒng)12.7軟件缺陷分析12.7.1 缺陷分析方法12.7.2 缺陷分析指標12.8小結512.1概述軟件業(yè)的發(fā)展推動了社會經(jīng)濟的快速發(fā)展，但是軟件質量卻變得越來越難以控制。從某種程度上說，軟件產(chǎn)品的競爭力已經(jīng)不完全取決

3、于技術的先進，更重要的是取決于軟件質量的穩(wěn)定。然而對于軟件開發(fā)而言軟件缺陷始終是不可避免的，為此付出的代價和成本是巨大的。研究表明，大約有60%的錯誤是在設計階段之前注入的，并且修正一個軟件錯誤所需要的費用將隨著軟件生存期的進展而上升。錯誤發(fā)現(xiàn)得越晚，修復它的費用就越高，而且呈指數(shù)上升的趨勢。在軟件的編碼測試階段遺漏編碼缺陷，如果到系統(tǒng)測試時才發(fā)現(xiàn)，那么這時糾正缺陷所花費的成本是在編碼階段糾錯花費的成本的7倍以上，而且測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目（即檢錯率）很可能成正比。712.1.1 相關定義軟件錯誤：軟件錯誤是指在軟件生存期內的不希望或不可接受的人為錯誤，其結果是導

4、致軟件缺陷的產(chǎn)生?？梢姡浖e誤是一種人為過程，相對于軟件本身，是一種外部行為。軟件缺陷：軟件缺陷是存在于軟件（文檔，數(shù)據(jù)或程序）之中的那些不希望或不可接受的偏差。其結果是軟件運行于某一特定條件時出現(xiàn)軟件故障，這時稱軟件缺陷被激活。軟件故障：軟件故障是指軟件運行過程中出現(xiàn)的一種不希望或不可接受的內部狀態(tài)。比如：軟件處于執(zhí)行一個多余循還過程時，我們說軟件出現(xiàn)故障。若此時沒有適當?shù)拇胧ㄈ蒎e）加以處理，便產(chǎn)生軟件失效。軟件故障是一種動態(tài)行為。軟件失效：軟件失效是指軟件運行時產(chǎn)生的一種不希望或不可接受的外部行為結果。 軟件失效機理8軟件缺陷管理：在軟件開發(fā)過程中對所發(fā)現(xiàn)的缺陷進行跟蹤并確保每個被發(fā)現(xiàn)

5、的軟件缺陷被關閉。邏輯上僅有2種方法應用于開發(fā)低缺陷的軟件缺陷預防缺陷排除1012.1.3 減少缺陷的關鍵因素軟件在版本發(fā)布后發(fā)現(xiàn)和解決一個軟件存在的問題所需的費用，通常要比在需求和設計階段發(fā)現(xiàn)、解決問題高出約100倍；當前的軟件項目約40%到50%的費用花費在可以避免的重復工作上；大約80%的可避免的重復工作產(chǎn)生于20%的缺陷；大約的80%缺陷產(chǎn)生于20%的模塊，約一半的模塊缺陷是很少的；大約的90%軟件故障來來自于的10%缺陷；有效的審核可以找出約60%的缺陷；有的目的性審核能夠比無方向的審核多捕獲約35%的缺陷；人員的專業(yè)性訓練可減少高達約75%的缺陷出現(xiàn)率；同等情況下，開發(fā)高可信賴的軟

6、件產(chǎn)品與開發(fā)低可信賴的軟件產(chǎn)品相比，成本要高出近50%。然而，如果考慮到軟件項目的運行和維護成本的話，這種投資是完全值得的；大約40%到50%的用戶程序都包含有非常細小的缺陷。1112.1.4 軟件缺陷的特征1、缺陷的發(fā)生都是有原因的2、缺陷的重現(xiàn)性3、缺陷的累積性、放大性（見下頁圖所示）4、缺陷的修復可能又引進新的缺陷12典型瀑布模型的軟件缺陷的累積和放大效應14缺陷標識（Identifier）：缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識；缺陷類型 （Type）：缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類，一般包括功能缺陷、用戶界面缺陷、文檔缺陷、軟件配置缺陷、性能缺陷、

7、系統(tǒng)/模塊接口缺陷等；缺陷嚴重程度 （Severity）：缺陷嚴重程度是指因缺陷引起的故障對軟件產(chǎn)品的影響程度；缺陷優(yōu)先級（Priority）：缺陷的優(yōu)先級指缺陷必須被修復的緊急程度；缺陷狀態(tài)（Status）：缺陷狀態(tài)指缺陷通過一個跟蹤修復過程的進展情況；缺陷起源（Origin）：缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段；缺陷來源（Source）：缺陷來源指引起缺陷的起因；缺陷根源（Root Cause）：缺陷根源指發(fā)生錯誤的根本因素。1512.2.1 缺陷類型缺陷類型編號缺陷類型描述10F- Function影響了重要的特性、用戶界面、產(chǎn)品接口、硬件結構接口和全局數(shù)據(jù)結構。并且設計

8、文檔需要正式的變更。如邏輯，指針，循環(huán)，遞歸，功能等缺陷。20A- Assignment需要修改少量代碼，如初始化或控制塊。如聲明、重復命名，范圍、限定等缺陷。30I- Interface與其他組件、模塊或設備驅動程序、調用參數(shù)、控制塊或參數(shù)列表相互影響的缺陷。40C- Checking提示的錯誤信息，不適當?shù)臄?shù)據(jù)驗證等缺陷。50B Build/package/merge由于配置庫、變更管理或版本控制引起的錯誤。60D- Documentation影響發(fā)布和維護，包括注釋。70G- Algorithm算法錯誤。80U-User Interface人機交互特性：屏幕格式，確認用戶輸入，功能有效性

9、，頁面排版等方面的缺陷。90P-Performance不滿足系統(tǒng)可測量的屬性值，如：執(zhí)行時間，事務處理速率等。100N-Norms不符合各種標準的要求，如編碼標準、設計符號等。1712.2.3 同行評審錯誤嚴重程度#缺陷嚴重等級描述1Major主要的，較大的缺陷2Minor次要的，小的缺陷1812.2.4 缺陷優(yōu)先級#缺陷優(yōu)先級描述1Resolve Immediately缺陷必須被立即解決。2Normal Queue缺陷需要正常排隊等待修復或列入軟件發(fā)布清單。3Not Urgent缺陷可以在方便時被糾正。1912.2.5 缺陷狀態(tài)缺陷狀態(tài)描述Submitted已提交的缺陷Open確認“提交的缺

10、陷”，等待處理Rejected拒絕“提交的缺陷”，不需要修復或不是缺陷Resolved缺陷被修復Closed確認被修復的缺陷，將其關閉2012.2.6 缺陷起源缺陷起源描述Requirement在需求階段發(fā)現(xiàn)的缺陷 Architecture在構架階段發(fā)現(xiàn)的缺陷 Design在設計階段發(fā)現(xiàn)的缺陷 Code在編碼階段發(fā)現(xiàn)的缺陷 Test在測試階段發(fā)現(xiàn)的缺陷 2112.2.7 缺陷來源缺陷來源描述Requirement由于需求的問題引起的缺陷 Architecture由于構架的問題引起的缺陷 Design由于設計的問題引起的缺陷 Code由于編碼的問題引起的缺陷 Test由于測試的問題引起的缺陷 I

11、ntegration由于集成的問題引起的缺陷 2212.2.8 缺陷根源缺陷原因描述目標如：錯誤的范圍，誤解了目標，超越能力的目標等；過程，工具和方法如：無效的需求收集過程，過時的風險管理過程，不適用的項目管理方法，沒有估算規(guī)程，無效的變更控制過程等。人如：項目團隊職責交叉，缺乏培訓。沒有經(jīng)驗的項目團隊，缺乏士氣和動機不純等。缺乏組織和通訊如：缺乏用戶參與，職責不明確，管理失敗等。2412.3.1 缺陷的嚴重性和優(yōu)先級的關系嚴重性（Severity）顧名思義就是軟件缺陷對軟件質量的破壞程度，反應其對產(chǎn)品和用戶的影響，即此軟件缺陷的存在將對軟件的功能和性能產(chǎn)生怎樣的影響。在軟件測試中，軟件缺陷的

12、嚴重性的判斷應該從軟件最終用戶的觀點做出判斷，即判斷缺陷的嚴重性要為用戶考慮，考慮缺陷對用戶使用造成的惡劣后果的嚴重性。優(yōu)先級表示修復缺陷的重要程度和應該何時修復，是表示處理和修正軟件缺陷的先后順序的指標，即哪些缺陷需要優(yōu)先修正，哪些缺陷可以稍后修正。確定軟件缺陷優(yōu)先級，更多的是站在軟件開發(fā)工程師的角度考慮問題，因為缺陷的修正順序是個復雜的過程，有些不是純粹的技術問題，而且開發(fā)人員更熟悉軟件代碼，能夠比測試工程師更清楚修正缺陷的難度和風險。2512.3.2 處理缺陷的嚴重性和優(yōu)先級的常見錯誤正確處理缺陷的嚴重性和優(yōu)先級不是件非常容易的事情，對于經(jīng)驗不很豐富的開發(fā)人員經(jīng)常會發(fā)生如下的情形：將比較

13、輕微的缺陷報告成較高級別的缺陷和高優(yōu)先級，夸大缺陷的嚴重程度，經(jīng)常給人“狼來了”的錯覺，將影響軟件質量的正確評估，也耗費開發(fā)人員辨別和處理缺陷的時間。將很嚴重的缺陷報告成輕微缺陷和低優(yōu)先級，這樣可能掩蓋了很多嚴重的缺陷。如果在項目發(fā)布前，發(fā)現(xiàn)還有很多由于不正確分配優(yōu)先級造成的嚴重缺陷，將需要投入很多人力和時間進行修正，影響軟件的正常發(fā)布。或者這些嚴重的缺陷成了“漏網(wǎng)之魚”，隨軟件一起發(fā)布出去，影響軟件的質量和用戶的使用信心。2712.4 軟件缺陷管理和CMM的關系CMM 是指“軟件能力成熟度模型”，其英文全稱為Capability Maturity Model for Software，英文縮

14、寫為SW-CMM，簡稱CMM。它是對于軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發(fā)展階段的描述。CMM的核心是把軟件開發(fā)視為一個過程，并根據(jù)這一原則對軟件開發(fā)和維護，進行過程監(jiān)控和研究，以使其更加科學化、標準化、使企業(yè)能夠更好地實現(xiàn)商業(yè)目標。2812.4.1 初始級的缺陷管理處于CMM一級（或稱為初始級）的軟件組織，對軟件缺陷的管理無章可循。工程師們只是在發(fā)現(xiàn)缺陷后，修改相應的軟件。通常，沒有人會去記錄自己發(fā)現(xiàn)的缺陷。也沒有人知道在新的軟件版本里，究竟糾正了哪些缺陷，還有哪些缺陷未被糾正。而且，只有在下一輪測試中才有可能知道那些所謂己被糾正了的缺陷是否真的被糾正了，更重要的是

15、糾正過程是否引入了新的缺陷。所以這樣的軟件組織的項目交貨期表現(xiàn)出強烈的不可預測性。并且，為了獲得一個高質量的軟件產(chǎn)品（如果能夠的話），通常要在測試上花費大量的人力。2912.4.2 可重復級的缺陷管理在 CMM 二級（或稱為可重復級）的軟件組織中，軟件項目會從自身的需要出發(fā)，制定本項目的缺陷管理過程。一個完備軟件缺陷管理過程通常會包括如下幾個方面：提交缺陷；分析和定位缺陷；提請修改相應的軟件；修改相應的軟件；驗證修改。項目組會完整地記錄開發(fā)過程中的缺陷，監(jiān)控缺陷的修改過程，并驗證修改缺陷的結果。3012.4.3 已定義級的缺陷管理CMM 三級（或稱為己定義級）的軟件組織會匯集組織內部以前項目的

16、經(jīng)驗教訓，制定組織級的缺陷管理過程。并且，要求項目根據(jù)組織級的缺陷管理過程定制本項目的缺陷管理過程。從而，整個軟件組織中的項目都遵循類似的過程來管理缺陷。好的缺陷管理實踐成為所有項目的實踐，而教訓也為所有項目所了解。更重要的是，隨著組織的不斷發(fā)展完善，組織的過程會得到持續(xù)性的改進，所有項目的過程也都會相應的改進。3112.4.4 定量管理級的缺陷管理沒實現(xiàn)缺陷預防的缺陷密度CMM4（已管理級）：建立軟件過程能力基線3212.4.5 持續(xù)優(yōu)化級的缺陷管理實現(xiàn)了缺陷預防的缺陷密度CMM5（持續(xù)優(yōu)化級）：強調對組織的過程進行持續(xù)性改進3312.5 報告軟件缺陷12.5.1 報告軟件缺陷的基本原則準確

17、報告軟件缺陷是非常重要的，因為：清晰準確的軟件缺陷描述可以減少軟件缺陷從開發(fā)人員返回的數(shù)量；提高軟件缺陷修復的速度，使每一個小組能夠有效的工作；提高測試人員的信任度，可以得到開發(fā)人員對清晰的軟件缺陷描述有效的響應；加強開發(fā)人員，測試人員和管理人員的協(xié)同工作，讓他們可以更好的工作；34軟件缺陷的有效描述規(guī)則軟件缺陷的有效描述規(guī)則，主要包括：單一準確。每個報告只針對一個軟件缺陷。在一個報告中報告多個軟件缺陷的弊端是常常會導致缺陷部分被注意和修復，不能得到徹底的修正?？梢栽佻F(xiàn)。提供缺陷的精確操作步驟，使開發(fā)人員容易看懂，可以自己再現(xiàn)這個缺陷，通常情況下，開發(fā)人員只有再現(xiàn)了缺陷，才能正確地修復缺陷。完

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

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

20、（例如，在下一個版本中修正）。對于每個被發(fā)現(xiàn)的缺陷的處理方式應當在開發(fā)組織內中達成一致。收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢曲線來識別測試過程是否結束。決定測試過程是否結束有很多種方式，通過缺陷趨勢曲線來確定測試過程是否結束是常用并且較為有效的一種方式。收集缺陷數(shù)據(jù)并在其上進行數(shù)據(jù)分析，作為組織的過程財富。3712.6.2 人員職責參與缺陷管理過程人員角色包括項目經(jīng)理、項目測試負責人、測試人員、項目相關開發(fā)人員、質量保證人員，其職責描述如下：項目經(jīng)理（PM）：負責指派缺陷給相關責任人。項目測試負責人（TM）:決定缺陷管理方式和工具，擬定決策評審計劃；管理所有缺陷關閉情況；審核測試人員提交的缺陷；對測試人

21、員的工作質量進行跟蹤與評價。測試人員（TE）負責報告系統(tǒng)缺陷記錄，且協(xié)助項目人員進行缺陷定位；負責驗證缺陷修復情況，且填寫缺陷記錄中相應信息；負責執(zhí)行系統(tǒng)回歸測試；提交缺陷報告；負責被測軟件進行質量數(shù)據(jù)和分析。項目相關開發(fā)人員（DE）修改測試發(fā)現(xiàn)的缺陷，并提交成果物做再測試；負責接收各自的缺陷記錄，并且修改；負責提供缺陷記錄跟蹤中其它相應信息。質量保證人員（SQA）監(jiān)控項目組缺陷管理規(guī)程執(zhí)行情況。3812.6.3 缺陷生命周期軟件缺陷的狀態(tài)在其生命周期中變化如下：缺陷從隱藏在產(chǎn)品中被發(fā)現(xiàn)，這時缺陷狀態(tài)為“創(chuàng)建”。得到缺陷修復請求以后，開發(fā)經(jīng)理將缺陷修復任務分配給相應的開發(fā)人員進行修復，這時缺陷

22、的狀態(tài)變?yōu)椤耙逊峙洹?。開發(fā)人員得到缺陷修復任務以后，根據(jù)缺陷的描述重現(xiàn)缺陷的癥狀、修復缺陷，然后提交測試人員驗證修改，這時缺席的狀態(tài)變?yōu)椤耙研迯汀薄y試人員驗證修改的有效性，若缺陷的修正得到最終確認，其狀態(tài)變?yōu)椤耙汛_認”。最終缺陷提交者或者測試人員，關閉這個缺陷，結束其生命周期。這時缺陷狀態(tài)變?yōu)椤耙殃P閉”?；镜能浖毕萆芷?9實踐中的軟件缺陷生命周期 實踐中的軟件缺陷生命周期4012.6.4 缺陷管理系統(tǒng)缺陷管理系統(tǒng)是用來管理軟件缺陷整個生命的工作流系統(tǒng)，跟蹤缺陷從發(fā)生到被修正并發(fā)布的整個過程。它能夠加強缺陷修正的過程控制，是缺陷管理的實現(xiàn)工具。缺陷跟蹤系統(tǒng)能否成功的實施取決于相應的缺陷

23、跟蹤流程的設計和軟件設計。其作用主要表現(xiàn)在：提高軟件缺陷報告的質量。軟件缺陷報告的一致性和正確性是衡量軟件測試過程專業(yè)化程度的重要指標之一。通過正確和完整填寫軟件缺陷管理系統(tǒng)提供的各項內容，可以保證不同測試工程師的缺陷報告格式統(tǒng)一。實時管理和控制缺陷狀態(tài)。軟件缺陷查詢、篩選、排序、添加、修改保存、權限控制是缺陷管理系統(tǒng)的基本功能和主要優(yōu)勢。通過方便的數(shù)據(jù)庫查詢和分類篩選，便于迅速定位缺陷和統(tǒng)計缺陷的類型。通過權限設置，保證只有適當權限的人才能修改或刪除軟件缺陷，確保了數(shù)據(jù)安全性。量化修復工作量。通過缺陷管理系統(tǒng)建立對缺陷數(shù)據(jù)的分析功能可以幫助軟件組織對員工績效、項目進展情況等等進行評估，幫助企業(yè)改進軟件過程提高員工工作效率。確保每一個缺陷能被處理，避免缺陷被遺忘或信息丟失等情況的發(fā)生。提供解決問題的知識，開發(fā)人員利用缺陷跟蹤系統(tǒng)，對已解決的問題所采用方法進行學習，提高軟件缺陷修復效率。BugzillaClearQuest41缺陷管理系統(tǒng)比較 工具名稱BugzillaClearQuest流程定制支持支持查詢功能支持支持郵件通知支持支持系統(tǒng)架構B/SC/S，B/S支持平臺Linux，F(xiàn)reeBSD，WindowsUnix，Windows數(shù)據(jù)庫SQL ServerOacle，SQL Server復雜度簡單復雜產(chǎn)品價格