一份BUG提交規範
阿新 • • 發佈：2019-02-01
1，BUG全部提交到http://XXX.XXX.XXX.XXXBUG論壇上
2，建立的問題的時候，“概要”--用簡單明瞭的語句說明白你這個BUG，就相當與BUG的中心語句
3，BUG優先順序分為4種情況
致命問題：系統任何一個主要功能完全喪失、使用者資料受到破壞、系統崩潰、懸掛、宕機，或者危及人身安全
嚴重問題： 系統的主要功能部分喪失、資料不能儲存，系統的次要功能完全喪失，系統所提供的功能或服務受到明顯的影響
一般問題： 系統的次要功能沒有完全實現，但不影響使用者的正常使用。
建議性問題：不影響功能的、有關易用性的、文字、操作可以提出一些建議的問題
4，然後選擇你提交的BUG所以那個模組,並選擇提交問題時
5，選擇這個BUG所屬模組是屬於那個開發人員 ，並把問題指派給他
6，環境：填寫你當時出這個BUG的現場環境，如：作業系統是winxp,測試的終截者是那天的版本等（這個根據實況進行填寫，可寫也可不寫）
7，另外可以通過上傳截圖或附件，可以進行簡單明瞭的說明BUG存在，也可做為BUG證據
8，最重要的在填寫描述: 最好是把BUG產生的步驟一步一步寫清楚，可以用以下方法寫（如果一句話就可以說明的BUG，就不必要分步驟了）
1，。。。
2，。。。
3，。。。
4，。。。
寫清楚，然後寫出測試出的結果和你期望的結果，如：
測試結果：。。。。。
期望結果：。。。。。
9，BUG驗證/關閉問題說明：
當BUG由open變為FIXed，你就應該進行迴歸測試，如果迴歸測試後該問題被解決，則你就closed該BUG，並在註釋中填寫如下資訊：
驗證通過：是
驗證日期：。。。
驗證版本：。。。
如果迴歸測試驗證不通過，則Reopend該BUG，並在註釋中填寫你驗證的版本
10，關於研發人員解決問題
研發人員解決BUG寫的註釋一定要有以下幾點：
1，說清楚BUG產生的原因
2，寫出BUG產生的檔案
3，修改後該檔案的版本號
如果研發解決問題的註釋上只寫“已解決”這樣的話，就一定要叫他們加上上面的資訊
可能這個要根據不同的公司進行修改，我們分配問題就是直接分給相關開發人員，而不用通過經理再去分配任務。
2，建立的問題的時候，“概要”--用簡單明瞭的語句說明白你這個BUG，就相當與BUG的中心語句
3，BUG優先順序分為4種情況
致命問題：系統任何一個主要功能完全喪失、使用者資料受到破壞、系統崩潰、懸掛、宕機，或者危及人身安全
嚴重問題： 系統的主要功能部分喪失、資料不能儲存，系統的次要功能完全喪失，系統所提供的功能或服務受到明顯的影響
一般問題： 系統的次要功能沒有完全實現，但不影響使用者的正常使用。
建議性問題：不影響功能的、有關易用性的、文字、操作可以提出一些建議的問題
4，然後選擇你提交的BUG所以那個模組,並選擇提交問題時
5，選擇這個BUG所屬模組是屬於那個開發人員 ，並把問題指派給他
6，環境：填寫你當時出這個BUG的現場環境，如：作業系統是winxp,測試的終截者是那天的版本等（這個根據實況進行填寫，可寫也可不寫）
7，另外可以通過上傳截圖或附件，可以進行簡單明瞭的說明BUG存在，也可做為BUG證據
8，最重要的在填寫描述: 最好是把BUG產生的步驟一步一步寫清楚，可以用以下方法寫（如果一句話就可以說明的BUG，就不必要分步驟了）
1，。。。
2，。。。
3，。。。
4，。。。
寫清楚，然後寫出測試出的結果和你期望的結果，如：
測試結果：。。。。。
期望結果：。。。。。
9，BUG驗證/關閉問題說明：
當BUG由open變為FIXed，你就應該進行迴歸測試，如果迴歸測試後該問題被解決，則你就closed該BUG，並在註釋中填寫如下資訊：
驗證通過：是
驗證日期：。。。
驗證版本：。。。
如果迴歸測試驗證不通過，則Reopend該BUG，並在註釋中填寫你驗證的版本
10，關於研發人員解決問題
研發人員解決BUG寫的註釋一定要有以下幾點：
1，說清楚BUG產生的原因
2，寫出BUG產生的檔案
3，修改後該檔案的版本號
如果研發解決問題的註釋上只寫“已解決”這樣的話，就一定要叫他們加上上面的資訊
可能這個要根據不同的公司進行修改，我們分配問題就是直接分給相關開發人員，而不用通過經理再去分配任務。