缺陷管理(軟件測試與度量)

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

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

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

4、以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。 需要注意的是，測試人員報告Bug時，應當保證Bug是可以重現(xiàn)的。對于有時不可重現(xiàn)的Bug，應當反復測試，直到最終確定Bug的發(fā)生場景為止。,報告Bug的基本原則,盡快報告Bug 修改成本小、修改風險小 避免報告同類缺陷 有效描述Bug 簡單、明確、具體 每個缺陷一份報告 簡化和優(yōu)化操作步驟 保證重現(xiàn)缺陷 缺陷描述客觀公正，不帶評價和感情色彩 保證每個缺陷被報告和處理,有效描述Bug,單一準確，每個報告只針對一個軟件缺陷 可以再現(xiàn)，不要忽視或省略任何一項操作步驟，特別是關(guān)鍵性的操作一定要描述清楚，確保開發(fā)人員按照所描述的步驟可以再現(xiàn)缺陷 完

5、整統(tǒng)一，提供完整的軟件缺陷描述信息 短小簡練，如使用業(yè)務關(guān)鍵詞 特定條件，必須注明缺陷發(fā)生的特定條件 不做評價，客觀描述,一個簡單的缺陷報告,缺陷報告的描述,缺陷的嚴重性和優(yōu)先級 缺陷的類型和來源 缺陷附件 完整的缺陷信息列表,缺陷的嚴重性和優(yōu)先級,嚴重性：缺陷對軟件產(chǎn)品使用的影響程度 優(yōu)先級：缺陷必須被修復的緊急程度 缺陷越嚴重，越要優(yōu)先得到修正，缺陷嚴重等級和缺陷優(yōu)先級相關(guān)性很強 也有例外，如有些缺陷比較嚴重，但由于技術(shù)的限制或第3方產(chǎn)品的限制，暫時沒法修正，其優(yōu)先級就會低,缺陷的類型和來源,缺陷類型可以分為業(yè)務邏輯、數(shù)據(jù)處理、接口、UI、性能、安全性、兼容性、配置、文檔等 缺陷來源，如需

6、求說明書、設(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)先級 類型 缺陷提交人 缺陷指定解決人 來源 產(chǎn)生原因 構(gòu)建包跟蹤,版本跟蹤 提交時間 修正時間 驗證時間 所屬項目/模塊 產(chǎn)品信息 狀態(tài),編寫B(tài)ug摘要,Bug的摘要是要用一句話的形式簡明扼要地將Bug描述出來，要清晰指出Bug所在部位以及其錯誤類型，不能太籠統(tǒng)。 如“頁面

7、對非法輸入有問題”可以修改為“流量信息查詢頁面對于非法輸入沒有進行校驗”。,有效描述Bug,操作步驟： 使用MappingBuilder對URL為“jdbc:mysql:/2/test”的數(shù)據(jù)庫進行映射，虛擬數(shù)據(jù)庫名稱設(shè)置為“VMysql”。 進入DataView主頁面，在DAS List中點擊“VMysql”右側(cè)的“高級查詢”鏈接。 在高級查詢頁面底端的輸入框中，輸入SQL語句“select * from empinfo”，點擊查詢按鈕。 在得到的查詢結(jié)果頁面中，點擊“下一頁”鏈接。 翻頁到下一頁后，沒有出現(xiàn)“保存當前頁面的查詢結(jié)果”鏈接，無法保存當前頁面結(jié)果。,有效的缺陷描

8、述所帶來的益處,容易再現(xiàn)所報告的問題，加快缺陷的修正 提高工作效率 提高測試人員的信任度，有利于開發(fā)團隊和測試團隊之間的的溝通和合作 客觀、準確的產(chǎn)品質(zhì)量評估 預防缺陷,分離和再現(xiàn)缺陷的技巧,記下每一個操作步驟和中間結(jié)果 逐步嘗試并縮小偵察范圍 查找時間依賴問題 查找資源依賴問題 考慮軟件和硬件配置不同的可能,軟件缺陷的處理和跟蹤,軟件缺陷生命周期 缺陷的跟蹤處理 缺陷狀態(tài)報告,缺陷狀態(tài),軟件缺陷生命周期,復雜的軟件缺陷生命周期,缺陷的跟蹤處理,密切跟蹤缺陷狀態(tài)的變化，及時處理缺陷，使項目按預定的計劃進行 動態(tài)報表，及時更新數(shù)據(jù) 自動郵件機制,缺陷分析,作用 調(diào)整測試進度和項目進度 調(diào)整測試策

9、略和項目資源分配 測試人員與開發(fā)人員考核 精心設(shè)計 謹慎使用 度量軟件質(zhì)量、評估測試過程的效率、預期發(fā)布時間 數(shù)據(jù)最能反映真實情況 數(shù)據(jù)也最能制造假象,缺陷分析,關(guān)注對象 正在測試的軟件哪個模塊的問題最多？ 測試人員中誰報告的軟件缺陷最多？ 測試人員中誰報告的軟件缺陷準確率最高？ 各類缺陷所占的數(shù)量百分比分別是多少？ 開發(fā)人員能及時修正軟件缺陷嗎？ 開發(fā)人員一次正確修正缺陷的百分比是多少？ 有多少重復報告的缺陷？ 正在開發(fā)的軟件能否在計劃的時間內(nèi)正常發(fā)布？,缺陷分析工具,實時趨勢分析 累積趨勢分析 缺陷分布分析,實時趨勢分析,實時數(shù)據(jù)，由每日或每周發(fā)生的數(shù)據(jù)構(gòu)成的時間序列 對隨時間變化的趨勢進

10、行分析,累積趨勢分析,累積數(shù)據(jù)是將前面產(chǎn)生的數(shù)據(jù)不斷累加起來所構(gòu)成的時間序列 累積曲線趨勢特征更明顯,借助趨勢分析發(fā)現(xiàn)問題,產(chǎn)品的質(zhì)量是否達到預定的標準 缺陷修正的速度是否滯后 測試人員 驗證缺陷是否及時 缺陷遺漏程度 回歸缺陷數(shù)量 流程,實例,缺陷分布分析,缺陷分布分析，主要借助于圓餅圖、直方圖等工具進行分析 包括功能模塊、來源分布 、不同類型、開發(fā)團隊等各種分布,直方圖,圓餅圖,綜合,缺陷分析通常用以下三類形式的度量提供缺陷評測： 缺陷發(fā)現(xiàn)率 缺陷潛伏期 缺陷密度,缺陷分析,缺陷發(fā)現(xiàn)率 缺陷發(fā)現(xiàn)率是將發(fā)現(xiàn)的缺陷數(shù)量作為時間的函數(shù)來評測，即創(chuàng)建缺陷趨勢圖，如下圖所示。,缺陷潛伏期 測試有效性

11、的另外一個有用的度量是缺陷潛伏期，通常也稱為階段潛伏期。缺陷潛伏期是一種特殊類型的缺陷分布度量。在實際測試工作中，發(fā)現(xiàn)缺陷的時間越晚，這個缺陷所帶來的損害就越大，修復這個缺陷所耗費的成本就越多。表5-1顯示了一個項目的缺陷潛伏期的度量。,表5-2顯示了一個項目的缺陷分布情況（按缺陷造成階段和缺陷發(fā)現(xiàn)階段）。,缺陷密度 缺陷密度是一種以平均值估算法來計算出軟件缺陷分布的密度值。程序代碼通常是以千行為單位的，軟件缺陷密度是用下面公式計算的：,下圖顯示了一個項目的各個模塊中每千行代碼的缺陷密度。,但是，在實際評測中，缺陷密度這種度量方法是極不完善的，度量本身是不充分的。這里邊存在的主要問題是：所有的

12、缺陷并不都是均等構(gòu)造的。各個軟件缺陷的惡劣程度，及其對產(chǎn)品和用戶的影響的嚴重程度，以及修復缺陷的重要程度有很大差別，有必要對缺陷進行“分級、加權(quán)”處理，給出軟件缺陷在各嚴重性級別或優(yōu)先級上的分布作為補充度量，這樣將使這種評測更加充分，更有實際應用價值。,因為在測試工作中，大多數(shù)的缺陷都記錄了它的嚴重程度的等級和優(yōu)先級，所以這個問題通常都能夠很好解決。例如，下圖所示的缺陷分布圖表示軟件缺陷在各優(yōu)先級上所應體現(xiàn)的分布方式。,各優(yōu)先級上軟件缺陷分布圖,報告和管理缺陷,缺陷報告管理系統(tǒng)（缺陷跟蹤系統(tǒng)） 過程強制 權(quán)限控制 質(zhì)量記錄 文檔管理 信息共享 度量和統(tǒng)計,不僅可以統(tǒng)一數(shù)據(jù)格式、完成數(shù)據(jù)校驗，而且確保每一個缺陷不會被忽視，使開發(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， Bugzilla：/projects/bugzilla/ Bugzero： Scarab：htt