原文來源于：功能測試報告
自己編寫于2019/02/14 20:11，先轉(zhuǎn)移到“簡書”乐横。
本文基于《不會寫測試報告紊册，怎么從測試團隊中脫穎而出》《功能測試報告的編寫》放前，自我總結(jié)編寫的。
什么是測試報告
1痊焊、說明：
是指把測試的過程和結(jié)果寫成文檔盏袄，對發(fā)現(xiàn)的問題和缺陷進行分析，為糾正軟件的存在的質(zhì)量問題提供依據(jù)宋光，同時為軟件驗收和交付打下基礎(chǔ)貌矿。
ps.
【測試過程和測試結(jié)果的分析報告，以及上線許可】
【其實測試報告的內(nèi)容基本都是模板的那些罪佳，只是在實際測試過程中逛漫，如何去整理內(nèi)容結(jié)構(gòu)，使得報告的通常閱讀者：開發(fā)人員赘艳、測試經(jīng)理酌毡、產(chǎn)品經(jīng)理、項目負責人能夠一目了然地查看想要了解的內(nèi)容才是測試報告最值得注意的地方】
2蕾管、組成部分：
- 概述
- 測試范圍
- 測試人員
- 測試進度
- 測試結(jié)果
- 缺陷分析
- 測試結(jié)論（簡言之：是否允許上線）
功能測試報告基本信息如下：
1枷踏、引言部分
1.1、項目背景
本測試報告為xx系統(tǒng)測試報告掰曾，本報告目的在于總結(jié)測試階段的測試過程及測試結(jié)果分析旭蠕，描述系統(tǒng)是否達到需求的目的。
本報告預(yù)期參與人員包括測試人員旷坦、測試部門經(jīng)理掏熬、項目管理人員、SQA人員和其他質(zhì)量控制人員秒梅，開發(fā)旗芬，運維，產(chǎn)品捆蜀。
ps.
測試部門經(jīng)理：把控測試報告編寫是否正確完整疮丛。
運維：根據(jù)測試結(jié)果來判斷是否可以上線幔嫂。
產(chǎn)品：測試范圍是否覆蓋整個需求。
pps.
測試計劃：測試主管編寫誊薄。
測試報告：測試人員編寫（寫的好不好履恩，體現(xiàn)了自己的其中一項價值）。
1.2暇屋、參考資料
《需求說明書》
《原型圖》
《缺陷記錄》
《測試用例》
《測試計劃》
等等（基本包含了軟件開發(fā)生命周期階段似袁，所有的輸出文檔）
2洞辣、測試基本信息
2.1咐刨、測試范圍
| 產(chǎn)品 | 模塊 | 子模塊 | 功能 | 測試點 | 優(yōu)先級 | 測試工程師 |
|---|---|---|---|---|---|---|
| xx | xx | xx | xx | xx | xx | xx |
ps.
測試點：不等同于測試用例標題；
優(yōu)先級：一定要熟悉需求扬霜，了解什么是核心定鸟、基本、次要著瓶；
測試范圍（來源于 產(chǎn)品說明書联予、需求、郵件材原、銷售沸久、實施、客服......）
pps.
沒有任何一個產(chǎn)品是100%沒有bug的余蟹。
保證 不脫離需求卷胯，比較淺顯的bug不出現(xiàn)。
偶然性的bug威酒、深挖的bug不敢保證不會有窑睁。
2.2、測試案例設(shè)計思路
| 測試類型 | 測試用例設(shè)計方法及思路 |
|---|---|
| 功能測試 | 參考需求說明文檔葵孤，使用等價類担钮、邊界值、場景法尤仍、錯誤推算法編寫測試用例箫津，并進行測試。 |
| UI測試 | 參考原型圖宰啦，對頁面文案苏遥、鏈接、圖片圖標等進行界面測試 |
| 兼容性測試 | 使用IE8,9,10绑莺，chrome暖眼，firefox等主流瀏覽器進行兼容性測試（根據(jù)瀏覽器的內(nèi)核不同來區(qū)分） |
2.3、測試環(huán)境
- 硬件環(huán)境
- 軟件環(huán)境
- 網(wǎng)絡(luò)拓撲圖
3纺裁、測試結(jié)果及缺陷分析【重點內(nèi)容】
3.1诫肠、測試執(zhí)行情況及記錄
3.1.1司澎、測試組織
| 項目經(jīng)理 | 軟件工程師（開發(fā)、運維） | 測試工程師 | 業(yè)務(wù)負責人（產(chǎn)品經(jīng)理） |
|---|---|---|---|
| x | x | x | x |
- 軟件/測試工程師：所有的開發(fā)/測試人員栋豫，哪怕只有一行代碼的輸出都要寫上（線上有問題挤安，需要參考這些人員）。
3.1.2丧鸯、測試時間
| 測試階段 | 計劃開始時間 | 計劃結(jié)束時間 | 實際開始時間 | 實際結(jié)束時間 | 計劃工作量(人/天) | 實際工作量(人/天) |
|---|---|---|---|---|---|---|
| x | x | x | x | x | x | x |
- 來源于測試計劃蛤铜。 測試開始時間：提測開始。
- 功能測試丛肢、接口測試围肥，測試報告需要分開寫，此文只是功能測試報告蜂怎。
3.1.3穆刻、冒煙情況
| 冒煙測試 | 時間 | 是否通過 | 如不通過，請寫原因 |
|---|---|---|---|
| x | x | x | x |
- 提測之后杠步，只要出現(xiàn)任何問題氢伟，都要提bug。
3.1.4幽歼、測試用例統(tǒng)計
| 案例總數(shù) | 可執(zhí)行個數(shù) | 未執(zhí)行個數(shù) | 成功個數(shù) | 失敗個數(shù) | 案例成功率 |
|---|---|---|---|---|---|
| x | x | x | x | x | x |
- 案例總數(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個女淑，安全相關(guān)瞭郑、設(shè)計缺陷有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倦逐、測試結(jié)論與建議
4.1譬正、風險分析及建議
風險： 測試環(huán)境接口不通，無法在測試環(huán)境測試 測試時間緊張 需求變更頻繁 xx模塊bug率較高
4.2檬姥、測試結(jié)論
本項目根據(jù)業(yè)務(wù)需求及開發(fā)人員曾我，產(chǎn)品經(jīng)理的反饋意見，覆蓋了所有測試需求健民，所有的案例均已在xx測試環(huán)境驗證完成抒巢。
有效案例一共xx個，執(zhí)行率xx%秉犹，成功率xx%蛉谜，缺陷關(guān)閉率為xx%平酿，目前缺陷均已修復(fù)并回歸關(guān)閉。
未解決的bug（延期處理悦陋、不予解決蜈彼、暫不處理等等）已經(jīng)和產(chǎn)品經(jīng)理，開發(fā)工程師進行溝通俺驶，不影響本次上線的基本功能幸逆。
綜上所述，xx項目暮现，版本Vxx还绘，達到xx項目測試上線標準，可以進行發(fā)布栖袋。
備注拍顷，需求不明確時：一定要去產(chǎn)品經(jīng)理，把不懂的地方弄懂塘幅，把不準確的地方弄準確昔案，不能帶著不清不楚的地方執(zhí)行測試，編寫測試用例电媳。
越總結(jié)越成長踏揣！
