近在翻看一些老帖子，發(fā)現(xiàn)一些很有意思的東西，收集整理后，把它放到了這里，那天回頭看會有另一翻感受。^_^

　　Ayi 問： 請問怎么寫 bug 才能不被開發(fā)人員討厭？

　　davy_chen 答：

　　1、描述精確，完整；

　　2、簡潔，無歧義；

　　3、可穩(wěn)定復現(xiàn)；

　　4、利用截圖，調(diào)試信息等輔助說明；

　　5、反饋驗證結(jié)果及時，變化內(nèi)容描述詳盡。不被開發(fā)人員討厭主要的是建立威信，也是你說出的都是真實的，你說有 bug 確實存在。

　　6、若對于很難重現(xiàn)的 Bug 還需要注明該 Bug 在測試過程中出現(xiàn)的幾率。

　　sww1980 答：

　　1、不被討厭不一定用寫 bug 的方式，跟開發(fā)人員搞好關(guān)系也很重要。

　　2、只要有 bug， 開發(fā)人員肯定會煩，這時候你的親和力尤為重要，讓開發(fā)人員覺得你不是在挑他的毛病，

　　而是想一起開心的把軟件做好。

　　小穎 答：

　　1、如果能夠指出 bug 的原因或出處一方面可以讓開發(fā)人員感覺你的水平比較高，另一方面減少了開發(fā)人員找錯的時間，他會心服口服。

　　2、在有不要抓住一些規(guī)范性的錯誤不放，應該發(fā)現(xiàn)一些有深度的錯誤，功能實現(xiàn)是重要的

　　celine 答：

　　我覺得溝通很重要，嘗試站在開發(fā)人員的角度上描述問題，而且要對事不對人。

　　gigobin 答：

　　1、開發(fā)人員喜歡的 bug ，是能夠一幕了然知道出現(xiàn)了什么樣的問題，然后是一個簡潔的復顯問題的步驟。 一般我都習慣于先寫一個簡單的問題的 brief ，一句話，比如：在 xxx 輸入某字符后，點擊 save 報 500 錯誤。 然后下面是你的測試端的配置。然后是你的測試平臺的情況。這些都是參考。 然后是第一步怎么做，第二步怎么做，......，然后出現(xiàn)了什么錯誤。 好是一個 bug 里面只有一個問題。這樣便于大家跟蹤狀態(tài)。

　　2、對于交流問題，我覺得如果有一個好的 bug 平臺，在一個清楚的 bug 時，很少需要開發(fā)人員和測試人員交流。尤其是什么是不是一個問題時，如果開發(fā)人員認定不是，不需要太多的糾纏。除非你認為這個將非常有損客戶的利益。而且這個時候應該報知測試 leader 去和開發(fā) leader 進行協(xié)調(diào)。 而且盡量不要去寫我認為這個問題是什么引起的，應該怎么改。你只需要保證開發(fā)人員能夠復顯可以了。過多的涉及這個問題，會牽扯雙方的精力。你的任務是發(fā)現(xiàn)問題，報告問題，追蹤問題而不是解決問題。

　　3、測試人員不是在找開發(fā)人員的錯，也不是開發(fā)人員的矛盾體。測試人員是幫助開發(fā)人員節(jié)省精力去找出錯誤，修改錯誤的。一個好的開發(fā)人員是不會因為測試人員找出他很多錯誤而煩惱的，因為不斷改進錯誤的同時，是對他的一個提高。一個好的產(chǎn)品團隊是協(xié)作良好的開發(fā)團隊，測試團隊以及管理組和設(shè)計核心組組成的。

相關(guān)鏈接：

測試人員應該如何報bug？