原文來源于：功能測試報告
自己編寫于2019/02/14 20:11，先轉移到“簡書”。

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

什么是測試報告

1、說明：

是指把測試的過程和結果寫成文檔，對發(fā)現(xiàn)的問題和缺陷進行分析，為糾正軟件的存在的質量問題提供依據(jù)，同時為軟件驗收和交付打下基礎。

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

2、組成部分：

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

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

1、引言部分

1.1、項目背景

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

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

ps.
測試部門經理：把控測試報告編寫是否正確完整。
運維：根據(jù)測試結果來判斷是否可以上線。
產品：測試范圍是否覆蓋整個需求。
pps.
測試計劃：測試主管編寫。 
測試報告：測試人員編寫（寫的好不好，體現(xiàn)了自己的其中一項價值）。

1.2、參考資料

《需求說明書》
《原型圖》
《缺陷記錄》
《測試用例》
《測試計劃》
等等（基本包含了軟件開發(fā)生命周期階段，所有的輸出文檔）

2、測試基本信息

2.1、測試范圍

ps.
測試點：不等同于測試用例標題；
優(yōu)先級：一定要熟悉需求，了解什么是核心、基本、次要；
測試范圍（來源于 產品說明書、需求、郵件、銷售、實施、客服......）
pps.
沒有任何一個產品是100%沒有bug的。
保證 不脫離需求，比較淺顯的bug不出現(xiàn)。
偶然性的bug、深挖的bug不敢保證不會有。

2.2、測試案例設計思路

2.3、測試環(huán)境

• 硬件環(huán)境
• 軟件環(huán)境
• 網絡拓撲圖

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

3.1、測試執(zhí)行情況及記錄

3.1.1、測試組織

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

3.1.2、測試時間

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

3.1.3、冒煙情況

• 提測之后，只要出現(xiàn)任何問題，都要提bug。

3.1.4、測試用例統(tǒng)計

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

3.2、缺陷的統(tǒng)計與分析

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

3.2.1、缺陷匯總

｛餅狀圖，可來源于tapd｝

本次項目發(fā)現(xiàn)缺陷總數(shù)：X，解決的缺陷數(shù)：X，殘留的缺陷數(shù)：X。

3.2.2、缺陷分析

3.2.2.1、按缺陷類型：

｛餅狀圖｝

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

3.2.2.2、按嚴重程度：

｛餅狀圖｝

該項目的缺陷，大量的是屬于一般缺陷，小部分屬于優(yōu)化缺陷，嚴重缺陷極少。

3.2.2.3、按功能分布：

｛餅狀圖｝

bug發(fā)生在x、x、x...模塊居多，小部分發(fā)生在x，x，x模塊

3.2.2.4、按測試階段：

｛餅狀圖｝

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

4、測試結論與建議

4.1、風險分析及建議

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

4.2、測試結論

• 本項目根據(jù)業(yè)務需求及開發(fā)人員，產品經理的反饋意見，覆蓋了所有測試需求，所有的案例均已在xx測試環(huán)境驗證完成。

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

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

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

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

越總結越成長！