軟件測(cè)試缺陷跟蹤與管理

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

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

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

4、bug令人討厭，而不是開(kāi)發(fā)人員。永遠(yuǎn)不要冒犯開(kāi)發(fā)人員的努力。使用委婉些的說(shuō)法。“混亂的UI”可以被溫和些改為“不正確的UI”。這樣開(kāi)發(fā)人員的努力將會(huì)得到尊重。 保持簡(jiǎn)單誠(chéng)實(shí)。你不是在寫散文或文章，因此使用簡(jiǎn)單的語(yǔ)言 在編寫bug report的時(shí)候記住你的目標(biāo)讀者。他們可能是開(kāi)發(fā)人員，其他的測(cè)試人員，經(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)。你也可以只說(shuō)“保存文件”。但是記住，并不是所有的人都知道如何在Word中保存文件。因此最好遵守第一種方法。 在一個(gè)干凈的系統(tǒng)里測(cè)試你的“可重現(xiàn)的步驟”。你可能會(huì)發(fā)現(xiàn)有些步驟被遺漏或是毫無(wú)關(guān)系的。如何更好的報(bào)告缺陷（4） 如果bug是和一組特定的測(cè)試數(shù)據(jù)相關(guān)，在你的bug report上附帶上它。 如果你要在bug report里附帶截屏，要確保那些圖片不是太大的，使用jpg或gif的格式，而不是bmp格式 在截屏上寫上注釋以指出問(wèn)題所在。這

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

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

8、可以最大程度地表現(xiàn)缺陷的特征。 *盡可能減小圖像的大小，以便于傳輸和查看。 最常見(jiàn)的是截取當(dāng)前活動(dòng)窗口，例如包含缺陷的對(duì)話框。截取全屏幕用的較少，而且消耗很多的文件存儲(chǔ)空間。缺陷報(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ī)范的截圖命名形式如下：語(yǔ)言_操作系統(tǒng)_類型_編號(hào).GIF 同一個(gè)測(cè)試項(xiàng)目中，截圖的編輯方式、命名規(guī)則、存儲(chǔ)類型等信息要保持一致。 沒(méi)有足夠的時(shí)間 不算真正的軟件缺陷 修復(fù)的風(fēng)險(xiǎn)太大 不值得修復(fù) 軟件缺陷報(bào)告不夠有效分離和再現(xiàn)軟件缺陷分離和再現(xiàn)軟件缺陷 分離和再現(xiàn)軟件缺陷是非常技巧性的工作 不存在隨機(jī)軟件缺陷的事情 分離和再現(xiàn)軟件缺陷的建議： 不要想當(dāng)然地接受任何假設(shè) 查找時(shí)間依賴和競(jìng)爭(zhēng)條件的問(wèn)題 檢查與壓迫和負(fù)荷相關(guān)的邊

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

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

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

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

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

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