效能測試的目的，是通過模擬真實的業務場景和海量的使用者請求及資料對業務系統進行多種場景的測試，來驗證各個服務的效能表現是否滿足實際的業務需要。
長期來看，效能測試最終的目標是為生產環境容量規劃提供可靠地參考資料，使生產服務的可用性、擴充套件性和穩定性更高，讓技術更好的服務業務，創造更多的價值。
從整個效能測試的生命週期來說，測試報告的產出就意味著一次完整效能測試專案的結束。那麼，怎樣的測試報告，才是真正具有價值的呢？
這篇部落格，聊聊乙份完善且具有價值的效能測試報告，都包含哪些內容。。。
單機水位是多少、滿足業務需求要上多少機器、什麼時候該加機器、什麼時候應該減機器。雙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
54c8g
閘道器服務，身份驗證和請求**
web server
24c8g
28c8g
redis
212g
哨兵模式，一主一從db2
8c16g
一主一從
2、測試策略
本次效能測試所採用的測試策略，比如：
探測系統效能拐點，需要階梯式壓測；
探測系統在可接受的效能指標下最大的處理能力，需要採用負載、容量測試策略；
驗證系統的穩定性和高可用，需要採用穩定性、高可用測試策略；
驗證系統在不同配置下的效能表現，一般採用配置測試策略；
六、測試結果
測試結果展示，依據具體的測試範圍、目的來選擇性展示。展示的方式可以是多種形式，最常見的是圖表型別。
舉個例子：單鏈路基準的場景，一般只需要以**形式羅列出測試結果即可，做個記錄。全鏈路壓測，可以用相對具體的圖表來提現測試的結果。
demo1：**統計
demo2：圖形化展示
ps：報告中具體貼多少的圖表，以公司實際的流程和技術文化為準。比如銀行金融業就比較重視，網際網路企業，一般只需要核心的資料證明即可。
七、階段進度
這裡主要指的是從需求階段到結束，各個階段的工作進展以及資源安排，建議採用看板的方式，及時更新進度，方便推進工作的開展。示例如下：
階段事項
開始時間
結束時間
狀態責任人
需求階段
需求評審
完成多方參與
系統架構圖
完成開發
需求調研
完成效能測試人員
準備階段
環境交付
完成運維、開發
應用部署
完成運維、開發
資料準備
完成開發、dba、測試
指令碼開發
完成效能測試人員
實施階段
執行壓測
未完成效能測試人員
服務監控
未完成運維、測試
資料收集
未完成效能測試人員
結束報告評審
未完成多方評審
八、問題記錄
壓測過程中的問題進行記錄匯報，也是很有必要的，測試同學懂得都懂。。。下面是乙個示例的問題記錄**，請參考。
九、測試結論
還記得本篇文章最開始是怎麼說的麼？效能測試的最終目的是，讓每乙個業務服務能夠清晰地知道：
單機水位是多少、滿足業務需求要上多少機器、什麼時候該加機器、什麼時候應該減機器。雙11等大促場景需要準備多少機器，既能保障系統擴充套件性和穩定性，又能節約成本。
下面是乙個比較萬金油的描述，具體的結論還需要根據具體的壓測需求和場景來描述：
本次效能測試在效能測試環境進行，所有涉及場景已測試完畢；測試過程中發現的缺陷已全部修復並驗證通過。
a-service服務在水位為50%時最大tps為200，業務預期指標為2000tps，生產環境現有同等配置伺服器8臺。
為滿足本次活動的營銷增長需要，線上建議部署12臺機器（10臺正常提供服務，2台留作buffer）經過評估，當前效能表現滿足預期效能指標，達到上線要求。
本次效能測試通過。
如上，就是乙個比較完整地效能測試報告內容，當然，可以根據研發部門或者公司具體的情況進行內容的增刪，僅供參考。。。
從零開始介面測試
介面測試現在已經是每個測試從業人員必須掌握的知識，介面測試實施在多系統多平台的構架下，有著極為高效的投入產出比，所以介面測試也在各大網際網路公司中越來越受到重視。但是很多測試人員一開始都是從功能測試開始的，可能很多人並沒有接觸過介面測試，那如何快速對介面測試上手呢，我們來看看吧。介面測試是測試系統元...
七 效能測試從零開始 LoadRunner入門
1.4 效能測試 工具的評估和選擇 我們可以看到，效能測試和一般 功能測試 不同的是，效能測試的執行是基本功能的重複和併發，因此我們在效能開始之前需要模擬多使用者，在效能測試進行時要監控指標引數，同時效能測試的結果不是那麼顯而易見，需要對資料進行分析。這些特點決定了效能測試更適合通過工具來完成。市場...
六 效能測試從零開始 LoadRunner入門
1.3 如何做效能測試 乙個專案要取得成功是困難的，因為成功的專案需要多個因素和條件來支援 而乙個專案失敗卻很容易，只要若干因素之中的乙個出現問題，就有可能導致專案失敗。比如中途測試人員發生變化，效能指標未和使用者達成統一理解等。筆者還曾看過乙個例子，因為測試報告的格式與使用者要求的格式不一致，而不...