功能/性能测试报告的编写格式及模板
當我們接觸不同的項目或者不同類型的測試類型后，會發現到項目后期都需要輸出測試用例、測試方案、測試報告等文檔，現在我們來聊一下測試報告。
測試報告的類型其實也區分很多，一般來說是分為功能測試報告和性能測試報告最多，再細分的話就是接口測試報告、單元集成測試報告、功能測試報告、兼容性測試報告、并發測試報告等等；但是大部分中小型的項目都是功能測試報告、性能測試報告或者直接輸出一份測試報告（包括功能和性能），這個時候我們就要知道，該功能測試報告需要包含哪些內容；而且因為接觸項目過多，如果自己定制一套測試報告模板，這個對于我們測試效率上會大大提高。
測試報告其實也有兩個面向，一個面向客戶的、一個面向的是內部。眾所周知,其實手工測試僅能發現這個系統的80%的bug，還剩下20%需要依靠不同的工具和別樣的思維去發掘，所以一般情況下，面向客戶的測試報告我們完成率覆蓋率會打到99%-100%;但是面向內部，在測試人員的角度上該系統可提交驗收/上線，其實覆蓋率只有80%。
測試報告的主要內容包括：
一、引言
1.1編寫目的
本測試報告為XXX項目的測試報告，目的在于總結測試階段的測試情況及分析測試結果，描述系統是否符合用戶需求，是否已達到用戶預期的功能目標。測試報告參考文檔提供給用戶、測試人員、開發人員、項目管理者、其他人員和其他需要閱讀本報告的用戶閱讀。
1.2名詞解釋
Fidder/Charles：抓包工具，主要查看接口和前端返回的數值，以及模擬弱網環境下的測試
Postman：數據類型返回錯誤時，使用該工具查看數據
XXXXXXX：XXXXXXXXX
1.3參考資料
XXX項目原型圖、設計稿
XXX項目的需求文檔
（當涉及性能的時候，需要附上一張性能測試指標文件）
二、概述
2.1項目背景（主要對該項目的一個介紹，描述XX項目分為多少個端以及有哪些主要功能模塊）
XXX項目分為移動端和pc端，移動端包含了登錄、XX、XX、XXX、XXX模塊；PC端包含了登錄、XX、XXXX、XXXX。
2.2環境配置（一般情況指的的正式生產環境的配置）
2.2.1硬件環境
|
機器用途 |
|
|
設備品牌、型號 |
|
|
CPU個數/型號 |
|
|
測試工具 |
|
|
物理核心數 |
|
|
內存 |
|
|
硬盤 |
2.2.2軟件環境
|
Pc端 |
移動端 |
|
|
操作系統 |
||
|
環境變量 |
||
|
測試工具 |
2.3測試準備
2.3.3測試安排
測試時間：2021-03-23至2021-03-24
測試地點：廣州
|
角色 |
人員名單 |
|
測試負責人 |
|
|
測試人員 |
|
|
系統調優 |
（最主要說的是性能測試，運維等性能調優相關人員） |
|
需配合的人員 |
2.3.2測試工具
|
工具 |
用途 |
2.3.3測試環境
|
Pc端 |
移動端 |
|
|
測試環境 |
||
|
硬件配置 |
||
|
網絡配置 |
||
2.3.3測試指標
2.3.3.1功能測試采集指標
|
序號 |
監控項 |
|
1 |
按測試用例執行是否通過測試 |
2.3.3.2性能測試采集指標
|
序號 |
監控項 |
|
1 |
并發用戶數 |
|
2 |
事務平均響應時間 |
|
3 |
平均每秒處理事務數TPS |
|
4 |
場景執行時間 |
|
5 |
網絡吞吐量 |
三、測試情況
3.1接口測試
域名：http：//1.1.1.1
端口：8080
測試時間：
|
模塊 |
Url |
請求參數 |
響應參數 |
測試結果 |
|
登錄 |
【post】/api/test |
|||
3.2功能測試
3.2.1冒煙測試
測試對象：移動/pc端（當功能模塊多時區分兩端填寫；若不多則可以寫一起，若寫一起在下列表格左側加多一列寫對應測試端）
版本號：V1.0
冒煙測試時間：（一般情況下測試時間為一天以內）
|
模塊（冒煙測試只需要一級模塊） |
測試內容描述 |
測試結果 |
3.2.2功能測試（執行測試用例）
測試對象：
版本號：V1.0（若冒煙測試通過則與冒煙測試版本號一致）
功能測試時間：
|
模塊 |
測試內容描述 |
測試用例執行 |
測試結果 |
覆蓋率 |
|
|
測試用例數 |
測試用例執行數 |
||||
|
登錄 |
驗證使用用戶名、密碼登錄進入系統 |
3 |
2 |
目前當密碼用戶名未填寫時未有提示信息 |
80% |
|
總結： |
|||||
3.3兼容性測試
主要是從操作系統、瀏覽器、分辨率三個方面的兼容性
|
測試對象 |
分辨率 |
測試工具 |
軟件版本 |
測試結果 |
|
Pc端 |
顯示器1024×768 顯示器1280×1024 顯示器1440×900 |
硬件：電腦、筆記本、顯示屏 |
Google：90.0.4430.72 Firefox：89.0 (64 位) |
測試通過 |
|
移動端 |
手機型號的分辨率（如小米9：2340×1080） |
安卓手機、蘋果手機、平板等（可以說具體幸好也可籠統的描述） |
Android10、IOS11等 |
測試通過 |
3.4回歸測試
|
模塊 |
測試內容描述 |
測試用例執行 |
測試結果 |
測試用例覆蓋率 |
|
|
測試用例總數 |
測試用例已通過數 |
||||
|
登錄 |
驗證使用用戶名、密碼登錄進入系統 |
3 |
3 |
測試通過 |
100% |
|
100 |
99 |
測試通過（覆蓋率達到98%則為通過） |
99% |
||
|
總結： |
|||||
3.5性能測試
3.5.1性能指標
系統的性能需求：
（1）在無其他操作的環境下，用戶并發需達到100人，且占用資源低于60%;
（2）最大用戶數達到500人同時在線，并要求當50人用戶逐步登錄時所消耗的資源占比；
（3）XXXXXXXX（一般填寫的是這次性能測試的性能指標，則用戶要求）
3.5.2性能測試場景
測試對象：XXXX系統或XXX功能模塊
（1）單一場景
|
序號 |
業 務 |
并發數 |
循環執行時間 |
模擬用戶 操作時間 |
|
1 |
測試登錄并發用戶數 |
100 |
2.96s |
（2）多個場景
|
序號 |
業 務 |
用戶數 |
循環執行時間 |
模擬用戶 操作時間 |
|
1 |
測試登錄最大用戶數100 |
100 |
2.96s |
|
|
2 |
XXXXXX |
|||
|
3 |
XXXXXXX |
3.5.3性能測試結果分析
（1）單一場景
|
場景 |
并發數 |
取樣數 |
平均響應時間 |
中位響應時間 |
90%響應時間 |
最小響應時間 |
最大響應時間 |
錯誤率% |
|
（秒） |
（秒） |
（秒） |
（秒） |
（秒） |
||||
|
登錄 |
1 |
100 |
2.71 |
2.73 |
2.21 |
2.52 |
2.96 |
0% |
（2）多個場景
|
場景 |
最大用戶數 |
取樣數 |
平均響應時間 |
中位響應時間 |
90%響應時間 |
最小響應時間 |
最大響應時間 |
錯誤率% |
|
（秒） |
（秒） |
（秒） |
（秒） |
（秒） |
||||
|
登錄最大用戶數 |
100 |
100 |
2.71 |
2.73 |
2.21 |
2.52 |
2.96 |
0% |
匯總結論：
四、總結
4.1缺陷圖表統計
4.1.1bug的分布情況
4.1.2bug的重要程度
4.1.3bug的優先級
4.1.4bug的狀態
4.2總結與建議
目前，XXX項目相對穩定，并且完成的功能模塊也是在計劃之內，開發測試過程中存在時間分配的問題后續繼續改進，充分做好開發和測試上的時間、人員安排上的規劃，把控測試流程中的每一個步驟，提升覆蓋率。遺留的缺陷盡量在本期內完成，沒完成的在后期版本中解決，以提升產品的穩定性和用戶體驗；并且加強服務器的管理，確保系統上線后能夠正常登錄。
建議：
（1）盡可能做到需求的版本控制，按照對應的版本進行一步一步的開發；
（2）項目上從產品需求、開發、測試都有明確的時間和安排計劃，并嚴格按照計劃上執行；額外添加或修改的需求需要考慮時間和人員安排，再考慮其優先級；
（3）測試人員按照測試計劃嚴格執行，并提前做好測試準備和測試環境的搭建。
做自己的事情，讓別人說去吧！人無完人，到那時我相信每個人都在進步的階層，只有不斷的鍛煉和學習，我們才能越來越接近人們所說的“完人”。
總結
以上是生活随笔為你收集整理的功能/性能测试报告的编写格式及模板的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 电子书mobi的格式详解
- 下一篇： Mysql命令drop database