大家好，我是「Bigder」
我們先熟悉一下Bug的處理流程。就會知道為什麽要學習送出一個高品質的Bug了。
研發同學會有天然的自信，不覺得自己的開發的套用會有Bug、加上Bug從分析、修復、再部署到測試環境驗收、關閉很耗時間。
實際工作，研發同學可能又再接手了其他新的需求，任務交叉。送出一個清晰、明確的問題能夠幫助他們理清邏輯、快速修復問題、也能體現測試同學的價值，否則很可能送出的問題沒有人會回應和響應
清晰的bug，能看懂、有步驟、輸入、輸出、數據、帶截圖、有日誌
「 標題 」 ：
標題格式，需求名_版本號_業務模組名_問題描述
「前置條件」
明確指出所送出的Bug是在怎麽樣的情況下出現的，當所發現Bug前提條件為空時、
填[無]
「測試步驟」
簡明清晰分步驟描述如何復現Bug問題，步驟用序號編排，舉例:
1、登入x1系統
2、點選、授權 -> 設定->開啟
3、系統提示錯誤
UI型別：Bug需要上傳截圖和圈出明確標識（加相應的紅框標識）
功能型別：錄制一個上傳視訊檔，上傳格式MP4為主（尤其是APP類、視訊圖動圖容易辨識）
崩潰型別：Bug則需要上傳視訊和輸出的log日誌
「預期結果」
-需求、原型要求的結果，期望結果不要包含測試步驟，要是簡單的一個結果
如：授權開啟成功
「實際結果」
-實際測試得到的結果。期望結果和實際結果要相互對應
如：授權開啟失敗
以上，
Bigder
