性能測試的目的，是通過模擬真實的業務場景和海量的用戶請求及數據對業務系統進行多種場景的測試，來驗證各個服務的性能表現是否滿足實際的業務需要。
長期來看，性能測試最終的目標是為生產環境容量規划提供可靠地參考數據，使生產服務的可用性、擴展性和穩定性更高，讓技術更好的服務業務，創造更多的價值。
從整個性能測試的生命周期來說，測試報告的產出就意味着一次完整性能測試項目的結束。那么，怎樣的測試報告，才是真正具有價值的呢？
這篇博客，聊聊一份完善且具有價值的性能測試報告，都包含哪些內容。。。
關鍵詞：信息完善，簡潔明了，有圖有數據有結論！！！即讓每一個業務服務能夠清晰地知道：
單機水位是多少、滿足業務需求要上多少機器、什么時候該加機器、什么時候應該減機器。雙11等大促場景需要准備多少機器，既能保障系統擴展性和穩定性，又能節約成本。
一份完善且具有價值的性能測試報告，主要包含如下幾個方面：
一、測試背景
首先要闡述本次性能測試的背景，即被測系統類型，面向哪些用戶，具備什么特點，為什么要進行性能測試，預期的一些指標等等。
比如：為了保證“雙十一”大促期間，系統能穩定運行且保障業務的高可用，進行性能測試。
核心：評估系統性能、分析性能變化趨勢、定位系統瓶頸風險、協助規划系統容量。
二、測試目的
測試的目的要根據測試背景來分析設定，比如：
1、線上服務由於流量過高某部分應用掛了，那測試目的就是：定位瓶頸、分析調優驗證；
2、運營做了拉新和新的渠道拓展，那測試目的就是：評估系統性能是否滿足新的線上業務；
3、系統架構由集群技改為微服務，那測試目的就是：驗證穩定性、可用性、單實例容量，為線上服務擴容提供容量規划數據；
三、測試范圍
比如，梳理出測試的業務域、場景、對應的服務：
| 業務歸屬模塊 | 業務涉及場景 | 對應服務 |
| 訂單 | 創建訂單 | order-service |
| 取消訂單 | ||
| 購物車 | 添加購物車 | |
| 刪除購物車 | ||
| 商品 | 商品列表 | product-service |
| 商品詳情 | ||
| 支付 | 余額支付 | payment-service |
| 支付寶支付 | ||
| 微信支付 |
或者，以思維導圖的形式進行說明也可以，如下圖：
四、預期指標
這里的性能指標包含如下兩項：
①、業務性能指標
即預期的TPS、RT、99%RT、請求成功率（一般默認請求成功率≥99.99%）。
②、硬件性能指標
即服務端資源耗用指標（也稱為水位），常規的資源監控指標有：CPU使用率、Memory使用率、系統IO、網絡IO等。
③、應用流量指標
比如：核心業務鏈路的QPS、Redis的命中率、DB的峰值QPS等數值。
五、實施說明
實施說明主要包含如下兩項：
1、環境配置
| 服務名稱 | 數量 | 配置 | 備注 |
| gateway server | 5 | 4C8G | 網關服務，身份驗證和請求轉發 |
| web server | 2 | 4C8G | |
| app server | 2 | 8C8G | |
| Redis | 2 | 12G | 哨兵模式，一主一從 |
| DB | 2 | 8C16G | 一主一從 |
2、測試策略
本次性能測試所采用的測試策略，比如：
探測系統性能拐點，需要階梯式壓測；
探測系統在可接受的性能指標下最大的處理能力，需要采用負載、容量測試策略；
驗證系統的穩定性和高可用，需要采用穩定性、高可用測試策略；
驗證系統在不同配置下的性能表現，一般采用配置測試策略；
六、測試結果
測試結果展示，依據具體的測試范圍、目的來選擇性展示。展示的方式可以是多種形式，最常見的是圖表類型。
舉個例子：單鏈路基准的場景，一般只需要以表格形式羅列出測試結果即可，做個記錄。全鏈路壓測，可以用相對具體的圖表來提現測試的結果。
但最重要的，還是結論！以及最終在線上環境所展現的價值。
demo1：表格統計
demo2：圖形化展示
PS：報告中具體貼多少的圖表，以公司實際的流程和技術文化為准。比如銀行金融業就比較重視，互聯網企業，一般只需要核心的數據證明即可。
七、階段進度
這里主要指的是從需求階段到結束，各個階段的工作進展以及資源安排，建議采用看板的方式，及時更新進度，方便推進工作的開展。示例如下：
| 階段 |
事項 |
開始時間 |
結束時間 |
狀態 |
責任人 |
| 需求階段 |
需求評審 |
|
|
完成 |
多方參與 |
| 系統架構圖 |
|
|
完成 |
開發 |
|
| 需求調研 |
|
|
完成 |
性能測試人員 |
|
| 准備階段 |
環境交付 |
|
|
完成 |
運維、開發 |
| 應用部署 |
|
|
完成 |
運維、開發 |
|
| 數據准備 |
|
|
完成 |
開發、DBA、測試 |
|
| 腳本開發 |
|
|
完成 |
性能測試人員 |
|
| 實施階段 |
執行壓測 |
|
|
未完成 |
性能測試人員 |
| 服務監控 |
|
|
未完成 |
運維、測試 |
|
| 數據收集 |
|
|
未完成 |
性能測試人員 |
|
| 結束 |
報告評審 |
|
|
未完成 |
多方評審 |
八、問題記錄
壓測過程中的問題進行記錄匯報，也是很有必要的，測試同學懂得都懂。。。下面是一個示例的問題記錄表格，請參考。
九、測試結論
還記得本篇文章最開始是怎么說的么？性能測試的最終目的是，讓每一個業務服務能夠清晰地知道：
單機水位是多少、滿足業務需求要上多少機器、什么時候該加機器、什么時候應該減機器。雙11等大促場景需要准備多少機器，既能保障系統擴展性和穩定性，又能節約成本。
下面是一個比較萬金油的描述，具體的結論還需要根據具體的壓測需求和場景來描述：
本次性能測試在性能測試環境進行，所有涉及場景已測試完畢；測試過程中發現的缺陷已全部修復並驗證通過。
A-service服務在水位為50%時最大TPS為200，業務預期指標為2000TPS，生產環境現有同等配置服務器8台。
為滿足本次活動的營銷增長需要，線上建議部署12台機器（10台正常提供服務，2台留作buffer）經過評估，當前性能表現滿足預期性能指標，達到上線要求。
本次性能測試通過。
如上，就是一個比較完整地性能測試報告內容，當然，可以根據研發部門或者公司具體的情況進行內容的增刪，僅供參考。。。