沒錯，任何軟件都存在
bug，哪怕是我們自己也存在缺陷，因為程序員也是普通人，人是會犯錯誤的。當有人在使用軟件時遇到bug，你需要使用郵件形成一份缺陷bug，發送給開發人員。開發者可以依據該報告定位問題，復現問題，修復問題。
但是很多時候，開發人員很難理解提交上的缺陷報告，因為發送人并不了解我們需要的是什么，那如何與開發人員溝通以及如何寫出一份缺陷報告，在這篇文章，我將教你如何寫出一份清晰的缺陷報告能使開發者理解、復現、修復問題，這里下載缺陷報告模板。
為什么要發送缺陷報告
缺陷報告可以用很多方式來幫助我們的開發者。
● 他們能告知我們沒有意識到的問題
● 他們能發現我們可能還沒想到的新特性
● 他們能幫助我們感受到客戶是如何使用我們的軟件，以至于我們可以做的更好
沒有這些缺陷報告，我們就不知道出錯的地方，我們需要它就像你唱歌跳舞時需要有軟件的支持一樣。
什么時候發送缺陷報告
● 簡單來說就是越快越好，詳細來說就是：
● 當你看到一個錯誤消息時就發送錯誤報告
● 當屏幕是空白或者數據缺失就發送報告
● 當程序沒有出現預期的結果時發送報告
● 當程序崩潰、死機、沒有響應或者響應很慢時發送報告
● 當程序返回錯誤結果時發送報告
● 當你得不到想需要的結果時發送報告
● 如果你不清楚怎樣做時發送報告
● 如果你不喜歡軟件做的方式，或者軟件老打攪你時，發送錯報告
● 如果你想在系統中實現一個變通方案時發送報告
缺陷報告需要有哪些內容
缺陷報告應該包含很多信息，你提供的信息越多效果越好，對于開發者，就像我，提供一個純文本文件模板給你填充然后郵件發給我，當然也有表格形式的，但是最期待你自己杜撰一份然后發給我。下面是一些必須包括的部分以及如何寫好每部分：
標題：創建一個簡短的標題，讓問題看起來更清晰。“應用崩潰”是一個很惱人的標題因為它沒有足夠的信息包括在這份報告里面。取而代之的是標題應該包含錯 誤消息和消息碼，或者是結果的名稱以及失敗時你正在做的事情。例如：Error 402：訪問拒絕當點擊“發送郵件”這個例子就提供了缺陷系統的上下文信息。
差：“程序崩潰”，“報錯”，“Bug”
好：“從’Kifu’中打印時5C79錯誤”，“’Kifu honors’報表為空”
產品：用名稱標識產品，告知你使用的是哪個版本。絕大部分軟件都包含有版本信息。web應用的版本信息通常在頁腳。
差：“你的應用”
好：”Kifu v1.01″
平臺：告訴我們軟件運行在什么平臺。尤其是操作系統的名字及版本和游覽器名稱版本。特別是web應用，這些信息對我們很重要。
差：“Windows”
好：“Windows7，IE9”
是否能重現：有些惱火的Bug是間歇性的出現，我們想預先知道，如果我們正在處理一個靈異事件或者正逢Bug出現時。
差：留空白
好：“每次”，“偶然”，“不重現”
描述：這部分是很多人拿不定的地方，不知道怎么描述問題，在描述中做到包括下面的內容：
● 總結：用簡潔的語言概括出Bug出現時你正在做的事情。從上下文開始，在操作應用的哪個部分。聚焦在你做的時候軟件做了什么？
差：“系統不能用了”
好：在“honor report”頁面單擊“打印按鈕”，但是報表是空的。
● 發生了什么：一步一步描述你做的事情當bug出現時，為什么你認為是錯誤的。事無巨細，打印出菜單的名稱，頁面標題，點擊時的按鈕或者鏈接的名稱。做相同的操作是不是出現一樣的錯誤。
差：“空白報表”
好：“點擊 ‘File/Save as…’，’Save‘對話空彈出，然后點擊‘OK’按鈕，但是文件沒有保存”
● 錯誤時什么：如果錯誤消息出現時，拷貝粘貼整個信息，這樣更有利于我們跟蹤錯誤。
差：“有個錯誤，點擊它始終讀不出”
好：“Error 403：訪問拒絕”
● 復現的步驟：如果你可以讓bug重現，那太好了，這能提供很大的幫助。一步步描述如何重現次bug。
差：“打印沒法使用”
好：“從‘Honors Report’頁面，點擊‘打印按鈕’”
● 預期結果：描述你預期發生的結果當bug發生時，這部分特別有用如果程序沒有按照你期待的結果發生時，因為它很詭異。
差：“我期待能正常工作”
好：“我期待能看到‘Honors Reports’的PDF文件”
真實結果：當bug發生時是怎么發生的，什么錯誤，為什么有錯，或者如果錯誤拋出，拋出什么錯。
差：“沒法用”
好：“我收到是空的PDF文件，或者’403錯誤，訪問拒絕’”
● 附件：如果你知道怎么截屏，做吧，附上一個簡短的錯誤，截屏可以是錯誤之前或者發生錯誤之后，我們的開發者能夠看到究竟發生了什么。如果應用有崩潰的日志，同樣附上它。
● 聯系方式：附上你的名字和email，我們可以讓你提交的報告及時的得到答復，在我們不理解問題的描述時還能夠詢問你，如果你忘記附聯系方式了，我們也就沒法聯系到你，也沒法修復bug。