測試管理之BUG流程相關(guān)建議
關(guān)于BUG流程相信大家都已經(jīng)很熟悉了，并且用起來也得心應(yīng)手，在此不再贅述。以下對BUG有一些小小的建議，主要針對我們?nèi)粘９ぷ髦袥]有注意到的地方說的，建議雖小，但要重視噢。
對于研發(fā)經(jīng)理：
當一個BUG被你審核通過，在派給開發(fā)人員時，你應(yīng)該將BUG的狀態(tài)改為“打開”。
審核BUG時你有***權(quán)限，可以審核BUG的所有信息是否正確，所以***重新審核一下我們提交的BUG嚴重程度，你有權(quán)修改哦。還有類型也可以修改的。
對于軟件工程師：
請開發(fā)人員修正后，注明修改后達到的功能效果以及可能影響到哪些其他的功能模塊，還有拒絕或延期的理由。同時***寫上解決的方式或非正常解決問題的原因，對于我們來說這些積累是一筆很大的財富。
如果你正陷入讓測試人員使用bug管理庫的苦惱中，你只要不用其他方法接受bug報告。如果你的測試人員習(xí)慣將bug報告用郵件的形式發(fā)給你，你只需用一個簡短的消息回復(fù)他們：“請將它們輸入到bug庫中，因為我無法追蹤?quán)]件。”
對于測試人員：
請測試人員提交新錯誤時，盡量用最簡潔的語言最清晰的描述出BUG的出處、操作步驟、現(xiàn)象、（建議），并盡量截圖。
盡量減少重現(xiàn)的步驟以達到用最少的步驟來重現(xiàn)問題；這對編程人員來說是很有幫助發(fā)現(xiàn)問題根源的。
當你的bug報告以“not repro（不可重現(xiàn)）”打回給你時，先檢查一個步驟是否有遺漏或清晰，再去找編程人員。編程人員通常是在無法用bug報告中的步驟重現(xiàn)bug時才選擇這個選項。
不要使用完全的大寫形式，那樣會讓人感覺象控訴。不要使用感嘆號或其他表現(xiàn)個人感情色彩的詞語或符號。
不要使用含糊的詞語（例如，好像，似乎）來描述發(fā)現(xiàn)的現(xiàn)象。
在提交BUG的標題***行寫上錯誤的總結(jié)是非常關(guān)鍵的。這要求測試人員編寫的報告要能夠吸引讀者，引起他們的注意，并使和管理層的溝通清晰。
再次強調(diào)，在bug report的初稿完成后，測試人員應(yīng)該反復(fù)閱讀它，集中剔除那些沒有關(guān)系的步驟或詞語。隱含的或模糊的說明和那些由于對沒有任何關(guān)系的細節(jié)或者那些在重現(xiàn)錯誤過程中不需要的步驟而消磨報告歡迎程度的無窮嘮叨都不是bug report的目標。
測試人員在精簡空話的同時或其之后隨即應(yīng)該再仔細檢查報告是否有會產(chǎn)生誤解的地方。測試人員應(yīng)該盡量避免使用模糊的，會產(chǎn)生歧義的和主觀的詞語。目標是使用能夠表述事實，清楚的，不會產(chǎn)生爭執(zhí)的詞語。
大家都要注意的地方：
當你發(fā)現(xiàn)一個BUG，或者正在修改BUG時，請考慮如下問題：
1. 同一軟件中的相似功能是否有相同的問題？
2. 其他的瀏覽器是否有相同的問題？
3. 其他的軟硬件配置是否有相同的問題？
4. 其他的區(qū)域（locales）是否有相同的問題？
5. 不同的安排設(shè)置是否有相同的問題？
6. 以前的版本否有相同的問題？
希望對你有幫助。
原文地址：http://bbs.51testing.com/thread-77195-1-1.html
【編輯推薦】
