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