[功能測試報告]

原文鏈接：https://my.oschina.net/niepanLs/blog/3010204

本文基於《不會寫測試報告，怎么從測試團隊中脫穎而出》《功能測試報告的編寫》，自我總結編寫的。

越總結越成長！

什么是測試報告？

1、說明：是指把測試的過程和結果寫成文檔，對發現的問題和缺陷進行分析，為糾正軟件的存在的質量問題提供依據，同時為軟件驗收和交付打下基礎。

ps.

• 【測試過程和測試結果的分析報告，以及上線許可】
• 【其實測試報告的內容基本都是模板的那些，只是在實際測試過程中，如何去整理內容結構，使得報告的通常閱讀者：開發人員、測試經理、產品經理、項目負責人能夠一目了然地查看想要了解的內容才是測試報告最值得注意的地方】

2、組成部分：

• 概述
• 測試范圍
• 測試人員
• 測試進度
• 測試結果
• 缺陷分析
• 測試結論（簡言之：是否允許上線）

功能測試報告基本信息如下：

1、引言部分

1.1、項目背景

本測試報告為xx系統測試報告，本報告目的在於總結測試階段的測試過程及測試結果分析，描述系統是否達到需求的目的。

本報告預期參與人員包括測試人員、測試部門經理、項目管理人員、SQA人員和其他質量控制人員，開發，運維，產品。

ps.

• 測試部門經理：把控測試報告編寫是否正確完整。
• 運維：根據測試結果來判斷是否可以上線。
• 產品：測試范圍是否覆蓋整個需求。

pps.

• 測試計划：測試主管編寫。
• 測試報告：測試人員編寫（寫的好不好，體現了自己的其中一項價值）。

1.2、參考資料

1. 《需求說明書》
2. 《原型圖》
3. 《缺陷記錄》
4. 《測試用例》
5. 《測試計划》
6. 等等（基本包含了軟件開發生命周期階段，所有的輸出文檔）

2、測試基本信息

2.1、測試范圍

測試范圍

產品	模塊	子模塊	功能	測試點	優先級	測試工程師

ps.

• 測試點：不等同於測試用例標題；
• 優先級：一定要熟悉需求，了解什么是核心、基本、次要；
• 測試范圍（來源於 產品說明書、需求、郵件、銷售、實施、客服......）

pps.

• 沒有任何一個產品是100%沒有bug的。
• 保證 不脫離需求，比較淺顯的bug不出現。
• 偶然性的bug、深挖的bug不敢保證不會有。

2.2、測試案例設計思路

測試案例設計思路

測試類型	測試用例設計方法及思路
功能測試	參考需求說明文檔，使用等價類、邊界值、場景法、錯誤推算法編寫測試用例，並進行測試。
UI測試	參考原型圖，對頁面文案、鏈接、圖片圖標等進行界面測試
兼容性測試	使用IE8,9,10，chrome，firefox等主流瀏覽器進行兼容性測試（根據瀏覽器的內核不同來區分）

2.3、測試環境

• 硬件環境
• 軟件環境
• 網絡拓撲圖

3、測試結果及缺陷分析【重點內容】

3.1、測試執行情況及記錄

3.1.1、測試組織

測試組織

項目經理	軟件工程師（開發）	測試工程師	業務負責人（產品經理）

• 軟件/測試工程師：所有的開發/測試人員，哪怕只有一行代碼的輸出都要寫上（線上有問題，需要參考這些人員）。

3.1.2、測試時間

測試階段	計划開始時間	計划結束時間	實際開始時間	實際結束時間	計划工作量(人/天)	實際工作量(人/天)

• 來源於測試計划。 測試開始時間：提測開始。
• 功能測試、接口測試，測試報告需要分開寫，此文只是功能測試報告。

3.1.3、冒煙情況

冒煙測試	時間	是否通過	如不通過，請寫原因

• 提測之后，只要出現任何問題，都要提bug。

3.1.4、測試用例統計

案例總數	可執行個數	未執行個數	成功個數	失敗個數	案例成功率

• 案例總數：用例的總數，所有人寫的總數。
• 可執行的：
• 未執行的：測試環境接口不通。這情況很少。
• 案例成功率=成功個數/可執行個數。

3.2、缺陷的統計與分析

• 缺陷匯總：列出本次實際發現缺陷數、解決的缺陷數、殘留的缺陷數（未解決缺陷）。
• 缺陷分析：對測試中發現的缺陷按缺陷類型、嚴重程度進行分類統計： 對測試中發現的缺陷就其功能分步、測試階段進行統計，分析軟件缺陷傾向及其主要原因。
• 殘留缺陷與未解決問題 對殘留缺陷對系統功能的影響情況進行分析：對未解決問題對項目的影響。
• 建議使用“bug狀態統計”報表 分析bug。

3.2.1、缺陷匯總

｛餅狀圖，可來源於tapd｝

本次項目發現缺陷總數：X，解決的缺陷數：X，殘留的缺陷數：X。

3.2.1、缺陷分析

3.2.1.1、按缺陷類型：

｛餅狀圖｝

該項目功能問題有x個，其次，頁面優化有x個，安全相關、設計缺陷有x個，其他有x個。 大量的bug來源於功能模塊，占比達到xx%，優化問題也有x個，達到xx%。

3.2.1.2、按嚴重程度：

｛餅狀圖｝

該項目的缺陷，大量的是屬於一般缺陷，小部分屬於優化缺陷，嚴重缺陷極少。

3.2.1.3、按功能分布：

｛餅狀圖｝

bug發生在x、x、x...模塊居多，小部分發生在x，x，x模塊

3.2.1.4、按測試階段：

｛餅狀圖｝

冒煙測試V1.1，第一輪V1.1，第二輪V1.2，第三輪V1.3， bug大量的發生在V1.1，V1.2少部分，V1.3極少

4、測試結果與建議

4.1、風險分析及建議

風險： 測試環境接口不通，無法在測試環境測試 測試時間緊張 需求變更頻繁 xx模塊bug率較高

4.2、測試結論

本項目根據業務需求及開發人員，產品經理的反饋意見，覆蓋了所有測試需求，所有的案例均已在xx測試環境驗證完成。

有效案例一共xx個，執行率xx%，成功率xx%，缺陷關閉率為xx%，目前缺陷均已修復並回歸關閉。

未解決的bug（延期處理、不予解決、暫不處理等等）已經和產品經理，開發工程師進行溝通，不影響本次上線的基本功能。

綜上所述，xx項目，版本Vxx，達到xx項目測試上線標准，可以進行發布。

備注，需求不明確時：一定要去產品經理，把不懂的地方弄懂，把不准確的地方弄准確，不能帶着不清不楚的地方執行測試，編寫測試用例。