主題：如何書寫測試報告 領導們通常是很關注測試的，因為通常只有測試團隊才能夠提供項目所處的真正位置。這種位置感來源于模塊的成熟度、穩定度和主要問題列表。這種信息，我們叫它項目的可視性信息。可視性信息可以分為兩類：
1）對內的信息匯總，以測試日志為典型，記錄每個測試工程師一天的進度、發現和困難，上報給測試經理；
2）對外的信息發布，以測試報告為典型。測試經理匯總測試的數據和信息，作為項目進度和狀態的重要標識上報給項目管理者。
一、測試日志（Test Log）
測試日志是幫助測試經理獲取測試信息的重要途徑，它的發布者是測試團隊中的每一個成員，測試日志的讀者是測試經理，而在規模大一些的測試團隊中，可能是測試小組的組長。測試日志的使命是讓測試經理了解自己團隊的狀況。
二、測試報告（Test Report）——言簡意賅、圖文并茂
測試報告寫作的七大原則：
（1）字數要夠少夠精煉
用最少的篇幅和最簡單的結構同時傳達出所有的關鍵信息，這才是測試報告應該做的事。
1、首先要減少說廢話套話，和測試無關的語言越少越好；
2、其次要避免過于細節，在報告后面可以盡情地添加附件來提供詳細的信息，給求知欲強的人留有進一步專研的空間；
3、最后，信息要分層派送，比如封面上三句話說出你最想說的心里話，中間的內容把這三點展開來說，最后的封底處作出你作為測試人員對待測軟件的評價和結論。
（2）圖表要夠多夠通俗
1、餅圖比大小（軟件遺留問題模塊分布）
2、柱圖比高矮（各測試組發現問題個數）
3、曲線圖上躥下跳（軟件穩定度的變化，問題解決率的變化，測試用例通過率的變化）
4、面積圖比胖瘦（遺留問題的解決趨勢）
5、圖表要用的正確才有效
項目管理者關注的大部分東西都有合適的圖表來表示：
1、總體成熟度和子模塊的成熟度：成熟度的計算方式有很多，其中最簡單的是統計測試用例的通過率，我們在上面講曲線圖的時候有例子。
2、缺陷分布：各種模塊內遺留的問題數目及其比例，能幫助讀者大略了解各個模塊的穩定程度，餅圖就是個很好的例子。
3、缺陷趨勢：成熟度的變化趨勢，從中可以看出軟件質量的走向，也是那個曲線圖的例子。
4、問題解決趨勢，這是個很有用的關注點，從中可以看出問題解決的速度和趨勢。當問題解決的速度下降的時候，能夠及時向管理層報警提起重視，面積圖的例子講的就是這方面的東西。
圖表能夠標出各測試組或測試工程師的效率和進度，以便及時發現暗藏的問題，避免進度受影響；圖表還能顯示出各模塊問題數和測試用例通過率的關系。
（3）顏色鮮艷，通俗易懂
綠色代表一切正常，紅色代表糟糕，黃色代表不好說。在測試報告中用綠色表示穩定的模塊，紅色表示有問題的模塊。
（4）既報喜又報憂，匯總出最嚴重的問題
在測試報告中列出未解決的TOP10嚴重故障。評審的對象之一就是剩余的嚴重問題都有哪些，以及產品帶著這些問題上市的風險有多大，測試人員公正和客觀的評價將是一個重要的參考。
（5）報告時間要及時
測試報告是為了讓項目的管理者在第一時間了解項目的狀態，因此報告的時間不能拖拖拉拉，新聞變成了舊聞就不值錢了。根據報告的重要程度和所做測試量的大小，測試報告準備的時間也應當不一樣。
（6）羅列的數據準確有力
測試關注質量，但如果測試本身的質量無法保證，那測試還不如不做。測試內部需要建立抽查機制：
1、抽查應該成為一種持續的壓力，不能搞獻禮工程；
2、抽查的比例要事先約定，根據是抽查的工作量和可投入的人力等；
3、執行抽查的人必須有經驗或者夠權威，否則抽查出問題以后必將導致無休止的爭論。
4、參考以往的趨勢（比如：測試用例通過率變化明顯部分抽查）
（7）邏輯要經得起推敲
測試報告中要做出很多結論，要注意結論的邏輯必須經得起推敲，做出的結論要有說服力。
版權聲明：本文出自 hellorenwei 的51Testing軟件測試博客：http://www.51testing.com/?578951
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
相關鏈接：
《笑傲測試》筆記（前言+第一式：廬山面目）
《笑傲測試》筆記（第二式：蓬門始開）
《笑傲測試》筆記（第四式：矯如龍翔）
《笑傲測試》筆記（第五式：浮云遮日）
《笑傲測試》筆記（第六式：伯仲伊呂）