某年某月某日某日，負責的網站出現崩潰的狀態。于是不懂技術的我問了我們公司的軟件工程師小哥，他說：“網絡問題導致的崩潰狀態”，由于過了10分鐘還沒好（已經被領導劈頭蓋臉的罵了一頓），我就弱弱的問，是不是有bug，能不能解決一下呢？他說有bug，會自己解決的，不用你教我哈！于是，過了1個小時，網站才恢復正常！我也不敢問，我也不敢說啊！

但今天，我不是來吐槽的，是我看到一篇文章《軟件測試工程師怎么正確描述bug？》，覺得很有意思，想給大家分享一下，并且會附上我的觀點哈！如有侵權，請及時聯系我進行刪除！

有些工程師心想：“作為測試工程師我怎么不知道提交bug嗎？難道還要你來教我嗎？好low的問題。”正因為軟件測試工程師的這種傲慢，這種傲慢直接導致和開發人員沖突，經常碰到開發人員抱怨測試提交的bug看不懂，結果導致問題越來越嚴重。
1.現在我們站在軟件開發人員以及運營者的角度，看軟件測試工程師有哪些毛病？
①描述bug不清晰，就一句話，沒有具體的操作步驟。
比如：撥打電話出現死機。（就簡單的一句話，就啥都沒了，撥打什么號碼–沒寫，在什么情況下撥打電話–沒寫）
②提交的bug看不懂啥意思，不知所云。
這種bug只有測試工程師自己能看懂，別人根本看不懂，他卻以為別人能懂。
③沒有寫出現的概率。
偶發的bug沒有log和其他更多信息，有的bug概率很小，小到不影響用戶使用，如果不寫清楚，開發人員將浪費大量時間去定位問題。
④bug發生的前提條件都不寫。
比如：bug描述是充電圖標顯示重疊。但是沒有寫什么條件下出現，開機狀態？還是關機狀態？開發工程師懵逼，還要自己去一個個去試，浪費開發人員的時間，描述不詳細但是測試工程師還覺得自己沒毛病，一切挺好。
⑤.bug等級亂定位
比如一個很小的甚至是建議性的問題，把bug等級提到最高。軟件開發一看，全是致命性1級bug，仔細一看很多小問題也被提為1級bug，此時開發人員的心情肯定的奔潰的。
⑥測試工程師描述bug，卻不寫預期結果。

開發都不知道要修改成什么樣，一臉懵逼。結果開發理解錯了，修改的結果不是預期的結果，這就浪費開發的時間了，你想想此刻開發人員的心情是怎樣的？
⑦出現問題的軟件版本沒寫清楚，開發人員不知道是在哪個軟件版本出現的。
8.bug出現的模塊沒有劃分清楚，所有的bug都提到一塊，看的眼花繚亂。
2.正確的提交bug才是我們和開發人員友好的溝通的最好方式。
①.bug標題要簡潔明了，不要啰嗦一堆。
②要寫出現問題的前提條件。

什么情況才會出現,必須要寫清楚。
③操作步驟要分步驟一步步寫清楚，不要怕麻煩。比如步驟1，步驟2，步驟3。
④要寫實際結果和預期結果，讓開發清楚要修改bug到達的預期效果。
⑤要寫出現的概率，比如操作10次出現1次。
⑥提供必要的截圖和log，甚至復雜的操作步驟要提供視頻。
⑦bug等級要分類好，致命性bug、嚴重bug、一般性bug、建設性意見，必須嚴格按照標準劃分。
⑧出現bug的軟件版本號，要寫清楚。
⑨bug出現的模塊要寫清楚。

比如app–設置模塊出現了bug，就把bug歸類為設置模塊的bug，這樣分類讓人一目了然。
3.以下是完整的bug：

前提條件：
操作步驟：
1.
2.
3.
實際結果：
預期結果：
概率：
版本號：
log、截圖、視頻等

4.bug的分類嚴格遵守，如下：
①致命（1級bug）
通常表現為:系統無法運行，崩潰。
應用模塊無法啟動或異常退出，主要功能模塊無法使用。
比如：1.內存泄漏；2.系統容易崩潰；3.系統無法登陸；4.循壞報錯，無法正常退出。
②嚴重（2級bug）
通常表現為：影響系統功能或操作，主要功能存在嚴重缺陷，但不會影響到系統穩定性。
比如：1. 功能未實現；2.功能存在報錯；3.數值輕微的計算錯誤；4.亂碼；

5.程序里有有危害國家安全或帶有政治色彩的字樣。
③一般（3級bug）
通常表現為：界面、性能缺陷。
比如：1.邊界條件下錯誤；2.極限條件下容易無響應；4.大數據操作時，沒有提供進度條；出現錯別字，但是不影響功能
④建設性意見（4級bug）
通常表現為：易用性及建議性問題
比如：1.界面顏色搭配不好；2.文字排列不整齊；3界面格式不規范。

以上，就是小編看到這篇文章時的感受哈，希望大家理解軟件工程師的工作，每個崗位每個人都有他的難處，多理解他人的處境，要知道軟件開發整天面對密密麻麻的代碼很費腦，再碰到測試提交的很多bug，他們的內心是排斥、抗拒的。