缺陷管理軟件測試與度量講解

1、軟件質(zhì)量保證和測試軟件質(zhì)量保證和測試 Bug管理 姚礪 內(nèi)容 ?Bug相關(guān)概念 ?判斷Bug的規(guī)則 ?Bug的生命周期 ?報告、跟蹤、關(guān)閉Bug ?Bug報告的內(nèi)容 ?Bug的統(tǒng)計 什么是Bug? ?功能沒有實現(xiàn)或與規(guī)格說明不一致的問題是bug； ?不能工作(死機、沒反應(yīng))的部分是bug； ?不兼容的部分是bug； ?邊界條件未做處理是bug； ?界面、消息、提示、幫助不夠準確是bug； ?屏幕顯示、打印結(jié)果不正確也是bug; ?有時把尚未完成的工作也作為一個bug。 什么是Bug? 在IEEE 1983 of IEEE Standard 729中對軟件缺陷下了一個標準的定義： （1）從產(chǎn)品內(nèi)

2、部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護過程中所存在的錯誤、毛病等各種問題； （2）從外部看，軟件缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。 Bug舉例1 文本文件保存錯誤： 在WindowsXP桌面上新建一個文本文檔，輸入“聯(lián)通”兩個字，并保存退出。 退出后再次打開這個文本文件時，剛才輸入的內(nèi)容變成了亂碼。 Bug舉例2 共享文件夾名超長時提示錯誤： Windows XP支持的最大共享文件夾名長度為80個英文字母或40個漢字，但設(shè)置共享文件夾名時可輸入的范圍是80個英文字符或80個漢字，如果共享文件夾名在4180個漢字之間，系統(tǒng)會提示“該共享名包含無效的字符” 。 其實真正的原因是共享文件夾名超

3、長。 Bug舉例3 替換字符串長度未作限定： Word2000中，如果替換字符串長度過長，則會引起程序崩潰。 軟件問題報告（Bug報告） ?軟件問題（Bug）報告是軟件測試過程中最重要的文檔。它記錄了Bug發(fā)生的環(huán)境，如各種資源的配置情況，Bug的再現(xiàn)步驟以及Bug性質(zhì)的說明。 ?更重要的是它還記錄著BugBug的處理過程和狀態(tài)。Bug的處理進程從一定角度反映了測試的進程和被測軟件的質(zhì)量狀況以及改善過程。 如果沒有報告缺陷，后果？ 第1 1份缺陷報告 判斷Bug的規(guī)則 ?軟件未達到產(chǎn)品規(guī)格說明書（需求）標明的功能。 ?軟件出現(xiàn)了規(guī)格說明書指明不會出現(xiàn)的錯誤。 ?軟件功能超出規(guī)格說明書指明的范圍

4、。 ?軟件未達到規(guī)格說明書雖未指出但應(yīng)達到的目標（隱含需求）。 ?軟件測試員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。 ?需要注意的是，測試人員報告Bug時，應(yīng)當保證Bug是可以重現(xiàn)的。對于有時不可重現(xiàn)的Bug，應(yīng)當反復(fù)測試，直到最終確定Bug的發(fā)生場景為止。 報告Bug的基本原則 ?盡快報告Bug ?修改成本小、修改風險小 ?避免報告同類缺陷 ?有效描述Bug ?簡單、明確、具體 ?每個缺陷一份報告 ?簡化和優(yōu)化操作步驟 ?保證重現(xiàn)缺陷 ?缺陷描述客觀公正，不帶評價和感情色彩 ?保證每個缺陷被報告和處理 有效描述Bug ?單一準確單一準確，每個報告只針對一個軟件缺陷 ?

5、可以再現(xiàn)可以再現(xiàn)，不要忽視或省略任何一項操作步驟，特別是關(guān)鍵性的操作一定要描述清楚，確保開發(fā)人員按照所描述的步驟可以再現(xiàn)缺陷 ?完整統(tǒng)一完整統(tǒng)一，提供完整的軟件缺陷描述信息 ?短小簡練短小簡練，如使用業(yè)務(wù)關(guān)鍵詞 ?特定條件，特定條件，必須注明缺陷發(fā)生的特定條件 ?不做評價，不做評價，客觀描述 一個簡單的缺陷報告 缺陷報告的描述 ?缺陷的嚴重性和優(yōu)先級 ?缺陷的類型和來源 ?缺陷附件 ?完整的缺陷信息列表 缺陷的嚴重性和優(yōu)先級 ?嚴重性：缺陷對軟件產(chǎn)品使用的影響程度 ?優(yōu)先級優(yōu)先級：缺陷必須被修復(fù)的緊急程度 ?缺陷越嚴重，越要優(yōu)先得到修正，缺陷嚴重等級和缺陷優(yōu)先級相關(guān)性很強 ? 也有例外，如有些

6、缺陷比較嚴重，但由于技術(shù)的限制或第3方產(chǎn)品的限制，暫時沒法修正，其優(yōu)先級就會低 缺陷的類型和來源 ?缺陷類型可以分為業(yè)務(wù)邏輯、數(shù)據(jù)處理、接口、UI、性能、安全性、兼容性、配置、文檔等 ?缺陷來源，如需求說明書、設(shè)計規(guī)格說明書、代碼、用戶手冊等 ?缺陷關(guān)聯(lián)的模塊名，缺陷來自于產(chǎn)品的特定模塊的名稱 ?缺陷發(fā)生的階段，例如需求、系統(tǒng)架構(gòu)設(shè)計、詳細設(shè)計、編碼等 缺陷附件 ?一張圖片可能勝過千言萬語 ?Log file ?工具捕捉的其它數(shù)據(jù)文件等 完整的缺陷信息列表 ?ID ?標題 ?前提 ?環(huán)境 ?操作步驟 ?期望結(jié)果 ?實際結(jié)果 ?頻率 ?嚴重程度 ?優(yōu)先級 ?類型 ?缺陷提交人 ?缺陷指定解決人

7、?來源 ?產(chǎn)生原因 ?構(gòu)建包跟蹤 ?版本跟蹤 ?提交時間 ?修正時間 ?驗證時間 ?所屬項目/模塊 ?產(chǎn)品信息 ?狀態(tài) 編寫B(tài)ug摘要 ?Bug的摘要是要用一句話的形式簡明扼要地將Bug描述出來，要清晰指出Bug所在部位以及其錯誤類型，不能太籠統(tǒng)。 ?如“頁面對非法輸入有問題”可以修改為“流量信息查詢頁面對于非法輸入沒有進行校驗”。 有效描述Bug 操作步驟： 1.使用MappingBuilder對URL為“jdbc:mysql:/2/test” 的數(shù)據(jù)庫進行映射，虛擬數(shù)據(jù)庫名稱設(shè)置為“VMysql” 。 2.進入DataView主頁面，在DAS List中點擊“VMysql”

8、 右側(cè)的“高級查詢”鏈接。 3.在高級查詢頁面底端的輸入框中，輸入SQL語句“select * from empinfo” ，點擊查詢按鈕。 4.在得到的查詢結(jié)果頁面中，點擊“下一頁”鏈接。 5.翻頁到下一頁后，沒有出現(xiàn)“保存當前頁面的查詢結(jié)果”鏈接，無法保存當前頁面結(jié)果。 有效的缺陷描述所帶來的益處 ?容易再現(xiàn)所報告的問題容易再現(xiàn)所報告的問題，加快缺陷的修正加快缺陷的修正 ?提高工作效率提高工作效率 ?提高測試人員的信任度提高測試人員的信任度，有利于開發(fā)團隊和測試團隊之間的的溝通和合作 ?客觀、準確的產(chǎn)品質(zhì)量評估客觀、準確的產(chǎn)品質(zhì)量評估 ?預(yù)防缺陷預(yù)防缺陷 分離和再現(xiàn)缺陷的技巧 ?記下每一個

9、操作步驟和中間結(jié)果 ?逐步嘗試并縮小偵察范圍 ?查找時間依賴問題 ?查找資源依賴問題 ?考慮軟件和硬件配置不同的可能 軟件缺陷的處理和跟蹤 ?軟件缺陷生命周期軟件缺陷生命周期 ?缺陷的跟蹤處理 ?缺陷狀態(tài)報告 發(fā)現(xiàn) 打開 修復(fù) 關(guān)閉 缺陷狀態(tài) 軟件缺陷生命周期 發(fā)現(xiàn)軟件缺陷 軟件缺陷移交到項目管理員 測試員找到并登記軟件缺陷 軟件缺陷被移交到程序員 程序員認為軟件缺陷微不足道 軟件缺陷移交到測試員 項目管理員認為軟件缺陷不重要 測試員不同意，找出 通用失敗案例 軟件缺陷移交到項目管理員 軟件缺陷移交到測試員 軟件缺陷移交到程序員 測試員確認 軟件缺陷得以修復(fù) 程序員修復(fù)軟件缺陷 測試員關(guān)閉軟件

10、缺陷 項目管理員現(xiàn)在同意 軟件缺陷需要修復(fù) 打開 打開 以不修復(fù) 形式解決 打開 打開 以修復(fù) 形式解決 關(guān)閉 復(fù)雜的軟件缺陷生命周期 缺陷的跟蹤處理 ?密切跟蹤缺陷狀態(tài)的變化，及時處理缺陷，使項目按預(yù)定的計劃進行 ?動態(tài)報表，及時更新數(shù)據(jù) ?自動郵件機制 缺陷分析 ?作用 ?調(diào)整測試進度和項目進度 ?調(diào)整測試策略和項目資源分配 ?測試人員與開發(fā)人員考核 ?精心設(shè)計 ?謹慎使用 ?度量軟件質(zhì)量、評估測試過程的效率、預(yù)期發(fā)布時間 ?數(shù)據(jù)最能反映真實情況 ?數(shù)據(jù)也最能制造假象 缺陷分析 ?關(guān)注對象 ?正在測試的軟件哪個模塊的問題最多？ ?測試人員中誰報告的軟件缺陷最多？ ?測試人員中誰報告的軟件缺

11、陷準確率最高？ ?各類缺陷所占的數(shù)量百分比分別是多少？ ?開發(fā)人員能及時修正軟件缺陷嗎？ ?開發(fā)人員一次正確修正缺陷的百分比是多少？ ?有多少重復(fù)報告的缺陷？ ?正在開發(fā)的軟件能否在計劃的時間內(nèi)正常發(fā)布？ 缺陷分析工具 ?實時趨勢分析 ?累積趨勢分析 ?缺陷分布分析 實時趨勢分析 ?實時數(shù)據(jù)，由每日或每周發(fā)生的數(shù)據(jù)構(gòu)成的時間序列 ?對隨時間變化的趨勢進行分析 累積趨勢分析 ?累積數(shù)據(jù)是將前面產(chǎn)生的數(shù)據(jù)不斷累加起來所構(gòu)成的時間序列 ?累積曲線趨勢特征更明顯 借助趨勢分析發(fā)現(xiàn)問題 http:/ ?產(chǎn)品的質(zhì)量是否達到預(yù)定的標準 ?缺陷修正的速度是否滯后 ?測試人員 驗證缺陷是否及時 ?缺陷遺漏程度

12、?回歸缺陷數(shù)量 ?流程 實例 缺陷分布分析 ?缺陷分布分析，主要借助于圓餅圖、直方圖等工具進行分析 ?包括功能模塊、來源分布 、不同類型、開發(fā)團隊等各種分布 表 5-2 一個項目的缺陷分布情況 發(fā) 現(xiàn) 階 段 缺陷造成階段 需求 總體 設(shè)計 詳細 設(shè)計 編碼 單元 測試 集成 測試 系統(tǒng) 測試 驗收 測試 試運行產(chǎn)品 發(fā)布 產(chǎn)品 缺陷總量 需求 0 8 4 1 0 0 5 6 2 1 27 總體設(shè)計 0 9 3 0 1 3 1 2 1 20 詳細設(shè)計 0 15 3 4 0 0 1 8 31 編碼 0 62 16 6 2 3 20 109 總計 0 8 13 19 65 21 14 9 8 30

13、 187 直方圖 圓餅圖 綜合 ?缺陷分析通常用以下三類形式的度量提供缺陷評測： ?缺陷發(fā)現(xiàn)率 ?缺陷潛伏期 ?缺陷密度 缺陷分析 ?缺陷發(fā)現(xiàn)率 缺陷發(fā)現(xiàn)率是將發(fā)現(xiàn)的缺陷數(shù)量作為時間的函數(shù)來評測，即創(chuàng)建缺陷趨勢圖，如下圖所示。 ?缺陷潛伏期 測試有效性的另外一個有用的度量是缺陷潛伏期，通常也稱為階段潛伏期。缺陷潛伏期是一種特殊類型的缺陷分布度量。在實際測試工作中，發(fā)現(xiàn)缺陷的時間越晚，這個缺陷所帶來的損害就越大，修復(fù)這個缺陷所耗費的成本就越多。表 5-1顯示了一個項目的缺陷潛伏期的度量。 表 5-1 一個項目的缺陷潛伏期的度量 發(fā) 現(xiàn) 階 段 缺陷造成階段 需求 總體 設(shè)計 詳細 設(shè)計 編碼 單

14、元 測試 集成 測試 系統(tǒng) 測試 驗收 測試 試運行 產(chǎn)品 發(fā)布 產(chǎn)品 需求 0 1 2 3 4 5 6 7 8 9 總體設(shè)計 0 1 2 3 4 5 6 7 8 詳細設(shè)計 0 1 2 3 4 5 6 7 編碼 0 1 2 3 4 5 6 總計 ? 表5-2顯示了一個項目的缺陷分布情況（按缺陷造成階段和缺陷發(fā)現(xiàn)階段）。 表 5-2 一個項目的缺陷分布情況 發(fā) 現(xiàn) 階 段 缺陷造成階段 需求 總體 設(shè)計 詳細 設(shè)計 編碼 單元 測試 集成 測試 系統(tǒng) 測試 驗收 測試 試運行產(chǎn)品 發(fā)布 產(chǎn)品 缺陷總量 需求 0 8 4 1 0 0 5 6 2 1 27 總體設(shè)計 0 9 3 0 1 3 1 2

15、1 20 詳細設(shè)計 0 15 3 4 0 0 1 8 31 編碼 0 62 16 6 2 3 20 109 總計 0 8 13 19 65 21 14 9 8 30 187 ?缺陷密度 缺陷密度是一種以平均值估算法來計算出軟件缺陷分布的密度值。程序代碼通常是以千行為單位的，軟件缺陷密度是用下面公式計算的： 代碼行或功能點的數(shù)量軟件缺陷數(shù)量軟件缺陷密度 ?下圖顯示了一個項目的各個模塊中每千行代碼的缺陷密度。 ? 但是，在實際評測中，缺陷密度這種度量方法是極不完善的，度量本身是不充分的。這里邊存在的主要問題是：所有的缺陷并不都是均等構(gòu)造的。各個軟件缺陷的惡劣程度，及其對產(chǎn)品和用戶的影響的嚴重程度，

16、以及修復(fù)缺陷的重要程度有很大差別，有必要對缺陷進行“分級、加權(quán)”處理，給出軟件缺陷在各嚴重性級別或優(yōu)先級上的分布作為補充度量，這樣將使這種評測更加充分，更有實際應(yīng)用價值。 ? 因為在測試工作中，大多數(shù)的缺陷都記錄了它的嚴重程度的等級和優(yōu)先級，所以這個問題通常都能夠很好解決。例如，下圖所示的缺陷分布圖表示軟件缺陷在各優(yōu)先級上所應(yīng)體現(xiàn)的分布方式。 各優(yōu)先級上軟件缺陷分布圖各優(yōu)先級上軟件缺陷分布圖 報告和管理缺陷報告和管理缺陷 ?缺陷報告管理系統(tǒng)（缺陷跟蹤系統(tǒng)） ?過程強制 ?權(quán)限控制 ?質(zhì)量記錄 ?文檔管理 ?信息共享 ?度量和統(tǒng)計 ?不僅可以統(tǒng)一數(shù)據(jù)格式、完成數(shù)據(jù)校驗，而且確保每一個缺陷不會被忽視，使開發(fā)人員的注意力保持在那些必須盡快修復(fù)的高優(yōu)先級的缺陷上。 ?可以隨時建立符合各種需求的查詢條件，而且有利于建立各種動態(tài)的數(shù)據(jù)報表，用于項目狀態(tài)報告和缺陷數(shù)據(jù)統(tǒng)計分析。 ?可以隨時得到最新的缺陷狀態(tài)，大家獲得一致又準確的信息，掌握相同的實際情況，消除溝通上的障礙。 ?可以將缺陷和測試用例、需求等關(guān)聯(lián)起來，可以完成更深度的分析，有利于產(chǎn)品的質(zhì)量改進等。 開源缺陷跟蹤系統(tǒng) ?Mantis，http:/ ?Bugzilla ：/projects/bugzilla/ ?Bugzero：h