建站
咨詢
售后
建站咨詢
新聞中心
關于BUG流程相信大家都已經(jīng)很熟悉了，并且用起來也得心應手，在此不再贅述。以下對BUG有一些小小的建議，主要針對我們?nèi)粘９ぷ髦袥]有注意到的地方說的，建議雖小，但要重視噢。
創(chuàng)新互聯(lián)公司主營楊浦網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,重慶APP軟件開發(fā),楊浦h5成都小程序開發(fā)搭建,楊浦網(wǎng)站營銷推廣歡迎楊浦等地區(qū)企業(yè)咨詢
對于研發(fā)經(jīng)理：
當一個BUG被你審核通過，在派給開發(fā)人員時，你應該將BUG的狀態(tài)改為“打開”。
審核BUG時你有***權限，可以審核BUG的所有信息是否正確，所以***重新審核一下我們提交的BUG嚴重程度，你有權修改哦。還有類型也可以修改的。
對于軟件工程師：
請開發(fā)人員修正后，注明修改后達到的功能效果以及可能影響到哪些其他的功能模塊，還有拒絕或延期的理由。同時***寫上解決的方式或非正常解決問題的原因，對于我們來說這些積累是一筆很大的財富。
如果你正陷入讓測試人員使用bug管理庫的苦惱中，你只要不用其他方法接受bug報告。如果你的測試人員習慣將bug報告用郵件的形式發(fā)給你，你只需用一個簡短的消息回復他們：“請將它們輸入到bug庫中，因為我無法追蹤郵件?！?/p>
對于測試人員：
請測試人員提交新錯誤時，盡量用最簡潔的語言最清晰的描述出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的標題***行寫上錯誤的總結是非常關鍵的。這要求測試人員編寫的報告要能夠吸引讀者，引起他們的注意，并使和管理層的溝通清晰。
再次強調(diào)，在bug report的初稿完成后，測試人員應該反復閱讀它，集中剔除那些沒有關系的步驟或詞語。隱含的或模糊的說明和那些由于對沒有任何關系的細節(jié)或者那些在重現(xiàn)錯誤過程中不需要的步驟而消磨報告歡迎程度的無窮嘮叨都不是bug report的目標。
測試人員在精簡空話的同時或其之后隨即應該再仔細檢查報告是否有會產(chǎn)生誤解的地方。測試人員應該盡量避免使用模糊的，會產(chǎn)生歧義的和主觀的詞語。目標是使用能夠表述事實，清楚的，不會產(chǎn)生爭執(zhí)的詞語。
大家都要注意的地方：
當你發(fā)現(xiàn)一個BUG，或者正在修改BUG時，請考慮如下問題：
1. 同一軟件中的相似功能是否有相同的問題？
2. 其他的瀏覽器是否有相同的問題？
3. 其他的軟硬件配置是否有相同的問題？
4. 其他的區(qū)域（locales）是否有相同的問題？
5. 不同的安排設置是否有相同的問題？
6. 以前的版本否有相同的問題？
希望對你有幫助。
原文地址：http://bbs.51testing.com/thread-77195-1-1.html
【編輯推薦】
- 軟件測試理論：目的、周期、流程
- 淺談軟件測試嵌入式單元測試技能
- 軟件測試中排錯的基本方法
- 軟件測試接口測試的測試用例類型
- 軟件測試過程中的BUG管理
網(wǎng)站欄目：測試管理之BUG流程相關建議
文章起源：http://m.5511xx.com/article/djdoojj.html
