軟件測試缺陷跟蹤與管理

1、軟件缺陷跟蹤與管理 軟件缺陷分類 軟件缺陷生命周期 軟件缺陷報告 軟件缺陷管理工具介紹軟件缺陷分類標準軟件缺陷分類標準缺陷屬性缺陷屬性缺陷類型缺陷嚴重等級缺陷優(yōu)先級缺陷狀態(tài)缺陷起源缺陷來源缺陷根源缺陷分類適用范圍軟件缺陷的生命周期軟件缺陷的生命周期發(fā)現(xiàn)軟件缺陷測試員找到并登記軟件缺陷移交給程序員程序員修復軟件缺陷移交給測試員測試員確認軟件缺陷被修復并關閉打開解決關閉軟件缺陷的生命周期（續(xù)）軟件缺陷的生命周期（續(xù)）發(fā)現(xiàn)缺陷打開打開不修復打開打開修復修復關閉測試員發(fā)現(xiàn)并登記軟件缺陷軟 件 缺 陷 移交到程序員程序員認為軟件缺陷微不足道軟件缺陷移交到項目管理員項目管理員認為軟件缺陷不重要軟件缺陷移交

2、到測試員軟件缺陷移交到項目管理員測試員不同意，找出通用失敗案例項目管理員現(xiàn)在同意軟件缺陷需要修復軟 件 缺 陷 移交到程序員程序員修復軟件缺陷軟 件 缺 陷 移交到測試員測試員確認軟件缺陷得以修復測試員關閉軟件缺陷軟件缺陷的生命周期（續(xù)）軟件缺陷的生命周期（續(xù)）發(fā)現(xiàn)軟件缺陷打開解決關閉審查推遲缺陷報告 報告軟件測試錯誤的目的是為了保證修復錯誤的人員可以重復報告的錯誤，從而有利于分析錯誤產(chǎn)生的原因，定位錯誤，然后修正之。因此，報告軟件測試錯誤的基本要求是準確、簡潔、完整、規(guī)范。 報告軟件缺陷的原則報告軟件缺陷的原則 盡快報告軟件缺陷 盡可能提交有說服力的缺陷 有效描述軟件缺陷：短小、單一、明顯和

3、通用、再現(xiàn) 根據(jù)缺陷或錯誤類型，選擇圖象捕捉的方式 在報告軟件缺陷時不作評價 補充完善軟件缺陷報告如何更好的報告缺陷（1） 只有當你確信你已經(jīng)發(fā)現(xiàn)一個bug的時候開始起草bug report，不要在測試結(jié)束或每天結(jié)束之后。那樣，你可能會遺忘掉一些東西。更糟的情況是，我們可能會忘掉那個bug。 花一些時間去診斷你正在報告的缺陷。想想可能存在的原因?？赡艿阶詈竽銜l(fā)現(xiàn)更多的缺陷。在你的bug report中說說你的發(fā)現(xiàn)。開發(fā)人員將不僅僅對你使他們的工作變得輕松而感到高興。如何更好的報告缺陷（2） 不要在bug report中夸大缺陷。同樣，也不要太輕描淡寫了。 不管bug是多么的令人討厭，別忘了是

4、bug令人討厭，而不是開發(fā)人員。永遠不要冒犯開發(fā)人員的努力。使用委婉些的說法?！盎靵y的UI”可以被溫和些改為“不正確的UI”。這樣開發(fā)人員的努力將會得到尊重。 保持簡單誠實。你不是在寫散文或文章，因此使用簡單的語言 在編寫bug report的時候記住你的目標讀者。他們可能是開發(fā)人員，其他的測試人員，經(jīng)理，或者在一些情況下，甚至是客戶。Bug report應該可以被所有的人理解。如何更好的報告缺陷（3） “可重現(xiàn)的步驟”的流程應該是合乎邏輯的。 清楚的列出前提條件 寫下平常的步驟。例如，如果一個步驟要求用戶創(chuàng)建文件并且為它命名，不要要求用戶命名為“Mihirs file”。最好命名為好像“Te

5、st File”一樣的文件名。 “可重現(xiàn)的步驟”應該詳盡。例如，如果你想用戶在Word里保存一個文件，你可以要求用戶到File菜單并且點擊Save子菜單項。你也可以只說“保存文件”。但是記住，并不是所有的人都知道如何在Word中保存文件。因此最好遵守第一種方法。 在一個干凈的系統(tǒng)里測試你的“可重現(xiàn)的步驟”。你可能會發(fā)現(xiàn)有些步驟被遺漏或是毫無關系的。如何更好的報告缺陷（4） 如果bug是和一組特定的測試數(shù)據(jù)相關，在你的bug report上附帶上它。 如果你要在bug report里附帶截屏，要確保那些圖片不是太大的，使用jpg或gif的格式，而不是bmp格式 在截屏上寫上注釋以指出問題所在。這

6、將幫助開發(fā)人員一眼就可以馬上定位問題。如何更好的報告缺陷（5） 在設置bug report的嚴重程序之前應該全面的分析缺陷的影響程序。如果你認為你的bug具有很高的優(yōu)先級應該被修復，在bug report中證明這點。應該在bug report的描述部分指出這個理由。 如果bug是來自上個內(nèi)部小版本或版本回歸的結(jié)果，那么發(fā)出警報。象這種bug的嚴重程度可能是低的，但是優(yōu)先級別應該是高。如何更好的報告缺陷（6） 在bug report里附上日志或日志的摘錄片斷。這將幫助開發(fā)人員輕松地分析且調(diào)試系統(tǒng)。 如果你在不同的地方遇到相似的問題，且要求同一種修復方法,但是在不同的地方，那么就要為每一個問題書寫

7、單獨的bug report。每個bug report對應一個修復。 缺陷報告中的屏幕截圖處理（缺陷報告中的屏幕截圖處理（1） 截取缺陷的圖像可以使用Windows操作系統(tǒng)的快捷鍵，但是更多的是使用屏幕捕捉工具（Capturing Tools）。雖然截取并附上缺陷圖像不太復雜，但是關于截圖的類型、工具、編輯、存儲格式、命名規(guī)則，有不少值得注意的事項，為了準確、有效地截取和編輯缺陷圖像，需要測試工程師遵守相同的處理規(guī)則。 缺陷報告中的屏幕截圖處理（缺陷報告中的屏幕截圖處理（2） 截取缺陷的圖像，通常分為截取全屏幕、當前活動窗口、局部圖像三種形式。實際測試過程中，根據(jù)下列兩條原則選擇合適的類型： *

8、可以最大程度地表現(xiàn)缺陷的特征。 *盡可能減小圖像的大小，以便于傳輸和查看。 最常見的是截取當前活動窗口，例如包含缺陷的對話框。截取全屏幕用的較少，而且消耗很多的文件存儲空間。缺陷報告中的屏幕截圖處理（缺陷報告中的屏幕截圖處理（3） 如果截圖運行在Windows操作系統(tǒng)下的軟件缺陷，可以使用Windows操作系統(tǒng)自帶的快捷鍵，但是最經(jīng)常使用的是利用各種截圖工具直接截取。 截圖工具有很多種，截圖靜態(tài)圖像最常使用的是HyperSnap，它的優(yōu)點是支持各種截圖類型，而且截圖后可以在HyperSnap中直接編輯。 缺陷報告中的屏幕截圖處理（缺陷報告中的屏幕截圖處理（4） 缺陷截圖的編輯內(nèi)容包括： 圈出缺

9、陷的典型表現(xiàn)特征。 添加描述性文字。 利用箭頭將圈出的特征和描述性文字相連接。 僅圈選最能表示缺陷特征的區(qū)域。 缺陷報告中的屏幕截圖處理（缺陷報告中的屏幕截圖處理（5） 比較規(guī)范的截圖命名形式如下：語言_操作系統(tǒng)_類型_編號.GIF 同一個測試項目中，截圖的編輯方式、命名規(guī)則、存儲類型等信息要保持一致。 沒有足夠的時間 不算真正的軟件缺陷 修復的風險太大 不值得修復 軟件缺陷報告不夠有效分離和再現(xiàn)軟件缺陷分離和再現(xiàn)軟件缺陷 分離和再現(xiàn)軟件缺陷是非常技巧性的工作 不存在隨機軟件缺陷的事情 分離和再現(xiàn)軟件缺陷的建議： 不要想當然地接受任何假設 查找時間依賴和競爭條件的問題 檢查與壓迫和負荷相關的邊

10、界條件 關注事件發(fā)生的次序 考慮資源依賴性和內(nèi)存、網(wǎng)絡、硬件共享的相互作用 不要忽視硬件偶然性不可重現(xiàn)偶然性不可重現(xiàn)BUG的處理的處理 盡力去查找出錯的原因，比如有什么特別的操作，或者一些操作環(huán)境等。 程序員對程序比測試人員熟悉的多，也許你提交了，即使無法重現(xiàn)，程序員也會了解問題所在。 無法重現(xiàn)的問題再次出現(xiàn)后，可以直接叫程序員來看看問題。 對于測試人員來說，沒有操作錯誤這條.既然遇到，就是問題。即使真的操作錯了，也要推到程序員那里，既然測試人員犯錯誤，用戶也可能會犯同樣的錯誤。 Bug追蹤過程中需要注意的問題（追蹤過程中需要注意的問題（1） 盡量減少重現(xiàn)的步驟以達到用最少的步驟來重現(xiàn)問題；這

11、對編程人員來說是很有幫助發(fā)現(xiàn)問題根源的。 最好由報bug的人驗證bug是否可以關閉。任何人都可以修復bug，但只有那個發(fā)現(xiàn)bug的人才能夠確信bug是否真正的已被修復。 Bug追蹤過程中需要注意的問題（追蹤過程中需要注意的問題（2） 在將bug解決時要分清楚解決的方式。一般的bug系統(tǒng)允許你通過例如“fixed(已修復)”, “wont fix (不打算修復)”, “postponed(以后修復)”, “not repro(不可重現(xiàn))”, “duplicate（重復）”或“by design(設計如此)”方式來解決bug。同時最好寫上解決的方式或非正常解決問題（如以上幾種類型）的原因。 Bug

12、追蹤過程中需要注意的問題（追蹤過程中需要注意的問題（3） 仔細地追蹤版本信息。你給測試人員的每一個build都應該有一個build ID編號 當你的bug報告以“not repro(不可重現(xiàn))”打回給你時，先檢查一個步驟是否有遺漏或清晰，再去找編程人員。 如果知道bug出現(xiàn)模塊的負責人員或?qū)⒔鉀Qbug的開發(fā)人員，請在標題中明確的指出，例如你發(fā)現(xiàn)的bug是有關增加人員的，那么在標題中可以指出“增加人員時出現(xiàn)xx錯誤”。 Bug追蹤過程中需要注意的問題（追蹤過程中需要注意的問題（4） 如果用英文報bug，最好使用現(xiàn)在時或過去時，例如用“appears”而不是“will appear”。 不要使用完

13、全的大寫形式，那樣會讓人感覺象控訴。不要使用感嘆號或其他表現(xiàn)個人感情色彩的詞語或符號。 一個好的bug report是不可以細分的, 換句話說就是這個bug是不會讓他人覺得你還有些地方需要在測試一下，或許還有其他的問題。 軟件缺陷跟蹤軟件缺陷跟蹤對于項目管理，缺陷跟蹤是很重要的一個環(huán)節(jié)，它除了可以對需求的完成度進行控制，同時也可以對軟件本身的質(zhì)量進行控制，以保證軟件開發(fā)迭代的順利進行。 手工軟件缺陷報告和跟蹤手工軟件缺陷報告和跟蹤 表單可以容納標識和描述軟件缺陷的必要信息 書面表單的問題在于效率比較低自動軟件缺陷報告和跟蹤自動軟件缺陷報告和跟蹤缺陷跟蹤工具 原來的軟件項目開發(fā)中的缺陷跟蹤都是通

14、過EXCEL表格的形式來完成的，這種表格雖然也可以進行項目管理和項目執(zhí)行度的交互，但效率與實時性不高，同時也不好維護和統(tǒng)計，因此就出現(xiàn)了缺陷跟蹤系統(tǒng)，通過軟件技術來解決軟件項目的管理問題。 目前缺陷跟蹤系統(tǒng)還是比較多的，比較有名的像Mercury的TestDirector，Seapine的Test Track Pro，TechExcel的DevTrack，Atlassian的JIRA以及IBM的ClearQuest。測試跟蹤工具測試跟蹤工具Bugzilla介紹（介紹（1） Buzilla作為一個產(chǎn)品缺陷的記錄及跟蹤工具，它能夠為你建立一個完善的Bug跟蹤體系，包括報告Bug、查詢Bug記錄并產(chǎn)

15、生報表、處理解決、管理員系統(tǒng)初始化和設置四部分。 測試跟蹤工具測試跟蹤工具Bugzilla介紹（介紹（2） 基于Web方式，安裝簡單、運行方便快捷、管理安全。 有利于缺陷的清楚傳達。系統(tǒng)使用數(shù)據(jù)庫進行管理，提供全面詳盡的報告輸入項，產(chǎn)生標準化的Bug報告。能根據(jù)各種條件組合進行Bug統(tǒng)計。當錯誤在它的生命周期中變化時，開發(fā)人員、測試人員、及管理人員將及時獲得動態(tài)的變化信息，允許你獲取歷史紀錄。 測試跟蹤工具測試跟蹤工具Bugzilla介紹（介紹（3） 系統(tǒng)靈活，強大的可配置能力。Buzilla工具可以對軟件產(chǎn)品設定不同的模塊，并針對不同的模塊設定開發(fā)人員和測試人員；這樣可以實現(xiàn)提交報告時自動發(fā)給指定的責任人；