測試報告是 測試人員在測試過程中用于反映測試狀況的文檔，其重要性通過網上哀求、跪求、旋轉360度冰天雪地各種求測試報告模塊的帖子中就可見一斑。其實測試報告的 內容基本都是模板的那些，只是在實際測試過程中，如何去整理內容結構，使得報告的通常閱讀者：開發人員、測試經理、產品經理、項目負責人能夠一目了然地查 看想要了解的內容才是測試報告最值得注意的地方。
產品要想有廣闊的市場，得需要切實了解用戶的需求及感受，同理測試報告要想能夠讓閱讀 者能夠滿意，也需要能將質量情況條理性地列出。通常來說，開發人員往往希望能從報告中了解缺陷的情況，而測試經理還關心用例的執行情況及覆蓋率、項目責任 人則最關心還有多少問題，此次版本是否測試通過。因此測試報告根據內容的側重點，分為『版本測試報告』和『總結測試報告』，目的也是希望不將所有內容列舉 在一個報告中，造成內容臃腫繁雜。
〖版本測試報告〗
● 主要反映開發人員提交的測試版本的質量狀況。
● 測試用例設計與執行、缺陷概況及問題概要是版本測試報告中的主要內容。
● 測試人員在每個輪次測試結束時編寫提交。
其內容結構如下：
對版本測試報告的每個章節的編寫內容進行說明：
大綱 | 子章節 | 詳細內容 |
測試簡介 | 測試目的 | 本次測試的背景及主要內容 |
測試資源 | 測試人員、本次測試開始和截止日期、花費工作日 |
測試環境 | 硬件環境 | 實際情況的詳細列舉，過低的配置、軟件版本的不匹配、網絡拓撲的錯誤都會讓提交的缺陷缺乏說服力，也會讓開發人員對于某些缺陷是否由于環境因素導致而產生疑惑。 |
軟件版本 |
網絡拓撲圖 |
測試方法 | 無 | 本次測試的功能點、各功能點對應的測試用例設計、測試用到的測試工具 |
測試用例 | 用例分析 | 測試用例維護記錄 |
用例執行情況 | 用例執行總數、通過用例數、未通過用例數、阻塞用例數 測試執行率=（已執行的用例數）/用例總數 測試用例效率=發現的缺陷總數/測試用例的數量 |
測試過程 | 缺陷統計 | 新建bug數、修復bug數、未修復bug數、bug總數 |
問題摘要 | 遺留問題、拒絕問題、掛起問題、長期驗證問題、待評估問題 |
測試結果 | 資源占用 | 測試項目的啟動、退出時間 測試項目的CPU占用率初始值、峰值（如果項目啟動會有多個進程，則分多個進程進行統計） 測試項目的內存占用初始值、峰值 |
測試結論 | 測試結論不論僅僅只是測試通過或不通過，應該使用詳細的數據來支持測試結論，需要列舉的數據有: 『測試用例通過率』 『遺留bug情況』 |
備注 | 用例執行記錄 | 插入測試用例的詳細執行結果文檔 |
資源監控記錄 | 說明資源占用監控的場景，詳細列舉各場景的監控時長、監控內容，場景操作 |
〖總結測試報告〗
● 主要偏重于各已測試版本的缺陷變化分析，風險預估。
● 各測試版本質量情況概況統計、缺陷分布統計、風險分析是總結測試報告中的主要內容。
● 測試人員在項目發布上線前編寫提交。
其內容結構如下：
對總結測試報告的每個章節的編寫內容進行說明：
| 標題 | 子章節 | 詳細內容 |
| 測試簡介 | 測試目的 | 本次測試的背景及主要內容 |
| 測試資源 | 測試人員、第一輪測試的開始日期和最后一輪測試的截止日期、總共花費工作日統計 |
| 測試環境 | 硬件環境 | 實際情況的詳細列舉，過低的配置、軟件版本的不匹配、網絡拓撲的錯誤都會讓提交的缺陷缺乏說服力，也會讓開發人員對于某些缺陷是否由于環境因素導致而產生疑惑。 |
| 軟件版本 |
| 網絡拓撲圖 |
| 測試過程 | 各版本測試狀況 | 各測試版本的計劃提交日期、實際提交日期、測試類型（回歸或全量）、測試耗時、備注（被打回或提交補丁次數） |
| 各版本bug統計 | 各測試版本的新建bug數、修復bug數、遺留bug數，表格統計、線形圖或餅狀圖輔助表示 |
| 測試分析 | 缺陷分析 | 缺陷的總體分布情況，以線形圖或餅狀圖輔助表示 根據功能模塊進行劃分 根據嚴重、較嚴重、普通、輕微級別進行劃分 |
| 遺留問題 | 打開狀態bug、長期驗證bug、用戶體驗問題 |
| 測試小結 | 資源占用 | 測試項目的啟動、退出時間 測試項目的CPU占用率初始值、峰值（如果項目啟動會有多個進程，則分多個進程進行統計） 測試項目的內存占用初始值、峰值 |
| 風險分析 | 測試進度、人員安排導致的風險 測試內容考慮范圍之外導致的風險 測試環境不全面導致的風險 其他因素導致的風險 |
以上是對功能測試報告編寫的總結，性能測試報告、兼容性測試報告因為內容的不同是不能套用以上測試報告的結構進行編寫，功能測試報告的編寫就是要做到簡約而不簡單。