如何寫好測試報告

最近讀Cem Kaner，James Bach，Bret Pettichord合著的《軟件測試經驗與教訓》受益頗多，因此根據文中的部份內容總結出來與大家共享，希望能達到知識交流與共享的目的。如果感興趣，也可以閱讀原書。

測試報告是產品部與技術部進行溝通的主要手段，測試報告的好壞直接影響BUG的修改速度和程序員的心情。如果下苦功夫研究并寫好報告，則所有閱讀這些報告的人都會受益。因此我整理并撰寫此文，希望對于能修直產品部與技術部的橋梁有所幫助。

一、 缺陷報告的原則

1、 有些錯誤永遠也不會改正。測試員的責任不是保證所有錯誤都得到改正，而是準確報告問題，使程序員能夠理解問題的影響。而深入研究并寫出好的報告，常常對錯誤改正的可能性產生巨大的影響。

2、 及時報告缺陷。不要等到第二天或是下周才報告程序錯誤，不要等到忘記了一些關鍵細節才報告。拖延的時間越長，程序錯誤被解決的可能性就越小。

3、 每個程序錯誤都需要單獨報告。不要努力把不同的程序錯誤合并到同一份報告，來減輕項目經理或程序員對重復錯誤報告的不斷抱怨。如果多個程序錯誤寫到一份報告中，有些錯誤就可能得不到修改。

4、 小缺陷也值得報告。小錯誤會使客戶感到困惑，并降低客戶對產品其他部份的信心。被認為是很小的缺陷可能包括拼寫錯誤、小的屏幕格式問題，鼠標遺跡、小的計算錯誤，圖形比例不準、在線幫助錯誤、不適當的灰掉了的菜單選項、不起作用的快捷鍵、不正確的錯誤信息，以及其它程序員認為不值得花精力去修改的缺陷。

5、 努力使錯誤報告有更高的價值。由于有很多人都要閱讀并依賴錯誤報告，因此要下功夫豐富每個錯誤報告的信息。提高報告的可理解性。如：A、清楚列出錯誤報告的前置條件與實現的每一個步驟，避免前后語言混亂，它應該只需要描述現象，不要在產生錯誤的步驟中試圖給出程序員的解決辦法。這樣會使錯誤報告看來冗長而難于理解。如果有好的解決辦法或建議可以附在錯誤報告描述之后。B、要始終保持中立語氣。C、不要開玩笑，否則有可能造成誤解。

6、 永遠都要報告不可重現的錯誤，這樣的錯誤可能是時間炸彈。不可重現的錯誤可能會是公司能夠支付的最昂貴的缺陷。有時錯誤無法重現�？吹匠绦蝈e誤一次，但不知道如何使其再次出現。如果產品交付客戶還出現這種情況，會影響客戶對產品的信心，如果技術支持人員需要很長時間評估客戶的數據或環境，客戶則會更加厭煩。如果測試員清晰地報告錯誤征兆，程序員通過研究測試員怎么得到特定消息，或當測試員查看對話框或點擊特定控件時可能會出現的情況。從而能夠跟蹤代碼，相信程序員能夠改正報告中“不可重現”缺陷中的20%。但在報告此類BUG時，一定要明確說明自己不能重現這個程序錯誤。

二、 缺陷報告的注意事項

1、 引用別人的錯誤報告要小心。如果沒有得到錯誤報告的提交者的允許，可以補充評論，但不能編輯別人的材料。對于其他測試員的錯誤報告即使很糟糕也不要擅自修改。任何時候需要在錯誤報告中做補充，都要注明自己的姓名和日期。

2、 看似極端的缺陷可能是潛在的安全漏洞。如在一個在預期接受一個1~99的字段中，輸入65536個9會導致程序崩潰。會有人真的這么干嗎？是的，有人當然要這樣做。有人會認為“如果有人愚蠢到這樣做，程序崩潰會教訓他“而忽略該錯誤，但實際上白癡不是惟一濫用程序的人。任何會產生嚴重后果的問題都應該解決，不管其多么“不可能”發生，當熟練的攻擊者利用程序中的缺陷得手后，會寫下這個消息并廣為傳播，使得其所有生手都可以使用腳本。

3、 立即對程序錯誤延遲決定上訴，如果決定據理力爭，就一定要贏。如果測試員對某個BUG的處理有意見，確實需要上訴，不要依賴自己最初錯誤報告中的語言和信息，報告是不可更改的，但是測試員需要列舉更有效的例子，測試員需要與其他產品項目相關人員溝通，補充做一些后續測試，尋找該程序錯誤可能存在的更嚴重的錯誤。程序員所做的每個上訴都必須是有說服力的。即使不能贏得所有上訴（當然不可能贏得所有上訴）也應該得到自己的所有上訴理應獲勝的好名聲。

至此，上面羅列的條款都與我們實際工作有著密切的關聯，希望能借助此篇文章，讓你能有興趣讀完本書的全部內容,相信一定能讓你獲益匪淺。

回復：如何寫好測試報告 曾盛開（技術部）

我看完了，總是覺得程序員和測試員之間在問題分歧上存在很多不同之處，其中包括個人專業知識的深度，對軟件理解的能力，對業務、程序的理解能力，產品開發成本、周期與bug之間的協調。

諸多方面加起來，使我的脾氣在溝通協調bug問題上變得很容易激昂，或者說發火，頭腦發熱。程序員多少都有些自大，不甘屈服的情緒，而且確實很多東西由于變得和以前寫好、定好的需求有出入，導致做好的東西可能又被推翻。。。心里那種滋味很不好受的。。。畢竟每個地方和環節都是自己努力去想過的，有時候一個問題可能是花去幾天時間確保那樣做沒有漏洞和正確。

我感覺到兩個部門之間協調缺少更多互動，比如產品部在測試之前或者有空時候可以培訓一下技術部，一般會測試哪些東西，如何測試的，這樣子程序員心里多少有更多的底，在寫程序的時候會有一種警惕性，從而產品部也會輕松一些，雙方有利，應該是三方有利，公司最有利。。產品部也要考慮如何幫助程序員快速有利地處理bug，而不是一味為了bug而找bug，這根本背離了兩個部門合作的基調；技術部也同樣有責任去幫助產品部理解好系統運行的流程，找出隱藏的bug 。

另外，我想說的是在文檔細節上面不要過分苛求，否則一方面是開發進度和成本，另一方面是使Xp輕量級文檔開發流程又變成重量級文檔開發，程序員為了文檔忙于疲命。。我深有體會的，文檔花去的時間幾乎占用了1/4－1/3。

我覺得在測試的同事面前談測試，有些班門弄斧，關公賣刀，但有些話不得不說，那就開誠布公拿出來，就算貽笑大方也好吧~~~

回復：回復：如何寫好測試報告 李鵬

文檔花去的時間幾乎占用了1/4－1/3：這個時間我不覺得多，我覺得不夠�；ㄔ谛枨蠖�義，開發文檔方面的時間應該是1/2以上
我覺得XP編程不適合我們，理由有三：
1、我們的8.0項目跨度有近2年，可以說是個中型項目，xp編程比較適合小項目（2-3個月）。
2、xp編程理論中基本上沒有提到如何對程序進行系統的測試，而我們公司非常重視軟件測試，程序員和測試員的比例近1：1。
3、xp中對文檔的定義是“夠用就好”，而在眾多的工程理論（rup、cmm）中都建議要有詳盡得需求和開發文檔�；ㄔ谛枨蠖�義，開發文檔方面的時間應該是1/2以上。

回復：回復：如何寫好測試報告 黃為東

技術部和產品部的斗爭性，有它的積極作用，但確實存在兩個部門目標不一致性的問題，既存在內部損耗，又存在被共同忽視的中間地帶。
大膽設想一下，假設把技術部和產品部合并為一個大部，每個小組都配2個測試員，是否會更好呢？這樣測試人員對本組開發人員的配合密切程度也許會更高。問題是，測試的專業性、分工性是否會下降？
該怎么組織，是一個大問題。

回復：回復：如何寫好測試報告 蒲冬梅

產品只有足夠人性化，用戶才會樂意使用此功能，而不是買回去就將其束之高閣。文檔只有足夠詳細化，才能為產品部測試提供準確的依據。因此就需要產品部與技術部能夠有更多溝通，更充分的文檔準備，更大的耐心。

因為最終目標我們只有一個，做出來的產品要對得起用戶。因此我們需要彼此體諒，理解與尊重。

如果技術部有時間或是計劃能夠安排接受產品部的測試培訓，我想我們部門每個同事都會舉雙手雙腳贊成的。這樣應該能減少很大部份測試的工作量。

關于為了找BUG而找BUG的說法，我覺得是很有必要就此申明一兩句的�，F在產品部最終提交到技術部的BUG都是有人負責審核的（BUG的定位是否準確，BUG的描述是否清晰等）。由于BUG的數量，這項工作其實是相當費時與費力的，因此曾停過一段的時間，但是為了提高BUG的質量和減少為了BUG而需要與產品部溝通的時間，這部份工作我們依然堅持在做。但是難免會有部份BUG在產品部進行準確定位是很困難的，而如果改為由技術部來定位則僅僅只是幾分鐘的事情，因此我們并未嚴格控制每個BUG都會精確定位，但是我們的目標是盡可能減少技術部為了BUG的描述或定位而進行多次反復的溝通。

因此就BUG本身的問題，也歡迎技術部能多多提意見，我們一定堅絕改正。

文章來源于領測軟件測試網 http://www.kjueaiud.com/