軟件測試管理中Bug追蹤過程中需要注意的問題

第第頁軟件測試管理中Bug追蹤過程中需要注意的問題軟件測試管理中Bug追蹤過程中需要注意的問題

發(fā)表于：2023-05-06來源：：點擊數(shù)：標簽：

軟件測試管理中Bug追蹤過程中需要注意的問題很多朋友都問我，為什么那么喜歡研究bug報告，其實個人一直覺得bug報告高于一切，它是測試人員價值的終極體現(xiàn)。也許是工作的性質(zhì)，我經(jīng)常將香港的同事和深圳同事做比較，發(fā)現(xiàn)他們一個優(yōu)點特別值得我們學(xué)習(xí)：

軟件測試管理中Bug追蹤過程中需要注意的問題

很多朋友都問我，為什么那么喜歡研究bug報告，其實個人一直覺得bug報告高于一切，它是測試人員價值的終極體現(xiàn)。也許是工作的性質(zhì)，我經(jīng)常將香港的同事和深圳同事做比較，發(fā)現(xiàn)他們一個優(yōu)點特別值得我們學(xué)習(xí)：做什么事一般不會去衡量事情的最終利益，更多的是決定后考慮如何更好地把事情做好。

腳踏實地，希望我自己也能夠這樣努力下去。。盡量減少重現(xiàn)的步驟以達到用最少的步驟來重現(xiàn)問題；這對編程人員來說是很有幫助發(fā)現(xiàn)問題根源的。。最好由報bug的人驗證bug是否可以關(guān)閉。任何人都可以修復(fù)bug，但只有那個發(fā)現(xiàn)bug的人才能夠確信bug是否真正的已被修復(fù)。。在將bug解決時要分清楚解決的方式。一般的bug系統(tǒng)允許你通過例如“fixed（已修復(fù)）”，“won'tfix（不打算修復(fù)）”，“postponed（以后修復(fù)）”，“notrepro（不可重現(xiàn)）”，“duplicate（重復(fù)）”或“bydesign（設(shè)計如此）”方式來解決bug.同時最好寫上解決的方式或非正常解決問題（如以上幾種類型）的原因。。當你的bug報告以“notrepro（不可重現(xiàn)）”打回給你時，先檢查一個步驟是否有遺漏或清晰，再去找編程人員。編程人員通常是在無法用bug報告中的步驟重現(xiàn)bug時才選擇這個選項。。仔細地追蹤版本信息。你給測試人員的每一個build都應(yīng)該有一個buildID編號，這樣剛?cè)腴T的測試人員就不會重新測試壓根就沒有修復(fù)的那個版本。。如果你是個編程人員，并且正陷入讓測試人員使用bug管理庫的苦惱中，你只要不用其他方法接受bug報告。如果你的測試人員習(xí)慣將bug報告用郵件的形式發(fā)給你，你只需用一個簡短的消息回復(fù)他們：“請將它們輸入到bug庫中，因為我無法追蹤?quán)]件?！?。如果你是一個測試人員，并且正陷入讓測試人員使用bug管理庫的苦惱中，你只要不和他們說任何有關(guān)bug的事――將bug輸入到數(shù)據(jù)庫中，數(shù)據(jù)庫會自動發(fā)送email給他們。。不要添加太多的新字段。有些人喜歡添加一些新的字段來追蹤他所需的信息。試想一下，測試人員要花多長的時間去填寫一個幾十個字段的表單，而且又有多少人還愿意填寫下一個bug呢。。如果知道bug出現(xiàn)模塊的負責(zé)人員或?qū)⒔鉀Qbug的開發(fā)人員，請在標題中明確的指出，例如你發(fā)現(xiàn)的bug是有關(guān)增加人員的，那么在標題中可以指出“增加人員時出現(xiàn)xx錯誤”。。如果用英文報bug，最好使用現(xiàn)在時或過去時，例如用"appears"而不是"willappear".。不要使用完全的大寫形式，那樣會讓人感覺象控訴。不要使用感嘆號或其他表現(xiàn)個人感情色彩的詞語或符號。。不要使用含糊的詞語（例如，好像，似乎）來描述發(fā)現(xiàn)的現(xiàn)象。。請考慮如下問題：

1.同一軟件中的相似功能是否有相同的問題？

2.其他的瀏覽器是否有相同的問題？

3.其他的軟硬件配置是否有相同的問題？

4.其他的區(qū)域（locales）是否有相同的問題？

5.不同的安排設(shè)置是否有相同的問題？

6.以前的版本否有相同的問題？。編寫bugreport沒有什么定式，沒有絕對的范本，最基本的是能夠讓客戶或目標修改，瀏覽bugreport人員看懂，而且在短時間內(nèi)，而不需反復(fù)思考的。其他有時要考慮目標讀者的一些喜歡。例如有些類似的bug到底是合并還是單獨提交，bug的步驟劃分（到底是每一步都為一點，還是有些點可以合并）。在這一點上我覺得“靈活和適應(yīng)”是很關(guān)鍵的。。在發(fā)現(xiàn)一個Bug并填寫完bugreport之后，在review的時候，需要特別注意的一點是：這個bugreport會不會讓其他人還有聯(lián)想或發(fā)揮的空間。一個好的bugreport是不可以細分的，換句話說就是這個bug是不會讓他人覺得你還有些地方需要在測試一下，或許還有其他的問題。例如，有個測試人員發(fā)現(xiàn)在輸入16這個數(shù)字（允許范圍內(nèi)）且提交時系統(tǒng)會返回一個錯誤：不能輸入48以下的數(shù)字。這確實是一個錯誤，但是如果就只按現(xiàn)