bug處理流程
（1）新建bug單
寫上bug的標題，
復現這個bug的具體步驟，
一些前置條件和截圖，
把bug單指定給相關的開發人員
（2）待修改
等開發人員修改完畢
把bug單置成待驗證狀態
返回給測試
（3）待驗證
測試人員獲取最新的產品，如果發現bug已經修復則置成已驗證，
如果發現bug還存在，則置成待驗證，如果開發人員發現這個bug
是無法處理的，把這個問題指定給產品人員，由產品人員確定是否遺留
有些bug是由於測試環境問題或其他一些因素造成的，或許並不是乙個問題，
測試人員可能會出現誤判，此時開發人員會把這個問題置成不是問題，返回給
測試人員，確認後直接關閉
（4）已驗證
（5）關閉
bug型別：
功能錯誤：功能上的錯誤性bug
**錯誤：一般很少出現，通常在自測時出現（對白盒測試、自測的比較適合）
表單相關：表單邏輯、樣式、內容問題
使用者介面：ui表現，包括對話方塊樣式和文字描述問題
需求變動：原有的需求基礎上的更改
新增需求：會議上提出的新需求，非正式會議提出的不屬於該項
設計文件：資料庫設計文件、概要/詳細設計文件
建議：功能已滿足但待改善，屬於改良性建議
配置相關：如web伺服器或者資料庫伺服器配置等問題
安裝部署：專案部署時出現的錯誤，可能不是程式本身的問題而是工具本身和人為因素引起
安全相關：加密和水印等安全資訊
效能壓力：負載、壓力測試
標準規範：根據國際標準或者公司內部制定的某標準
測試指令碼：如用工具lr編寫並執行指令碼進行測試
事務跟蹤：產品缺陷/bug跟蹤（defect/bug tracking）
工作任務跟蹤（task tracking）
問題解決過程跟蹤（problem tracking）
產品需求管理（request management）
bug處理流程
自己總結僅供參考。必現問題，測試工程師提單未通知開發工程師，若開發工程師檢視該bug單時存在疑慮，可找測試工程師進行問題復現。偶發問題，需要測試工程師繼續觀察，測試工程師每天在相應觀察版本中進行針對性測試，並且將測試執 況如實詳細注釋到bug中，便於問題定位和追溯。拒絕問題，開發未經與測試溝通確認情...
Bug的處理流程
軟體沒有實現產品的說明書所描述的功能 軟體實現了產品說明書描述不應有的功能 軟體執行了產品說明書沒講的操作 軟體沒有實現產品說明書沒講但應該實現的功能 從軟體測試員的角度來看，軟體難以理解 不易使用 執行緩慢，或者終端使用者認為不對 致命 一招斃命的缺陷，使你的系統無法執行，有造成資料洩漏的安全性問...
Bug的處理流程
軟體沒有實現產品的說明書所描述的功能 軟體實現了產品說明書描述不應有的功能 軟體執行了產品說明書沒講的操作 軟體沒有實現產品說明書沒講但應該實現的功能 從軟體測試員的角度來看，軟體難以理解 不易使用 執行緩慢，或者終端使用者認為不對 致命 一招斃命的缺陷，使你的系統無法執行，有造成資料洩漏的安全性問...