軟件測試缺陷跟蹤與管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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