本文將深入探討性能測試的重要性，介紹不同類型的性能測試，并解釋如何通過性能測試來優化系統性能。從產品經理的視角出發，我們將學習如何關注關鍵性能指標，以及如何閱讀和理解性能測試報告。

小A接到個網站設計需求，由于是感興趣的領域，拿到手可開心了。哼哧哼哧畫了好幾天原型，又拿著菜刀架在開發脖子上猛干了幾天，終于在一個月黑風高的晚上上線了這個網站。

然而過了不久，客服電話被打爆，所有投訴都是一句話“你xxx還讓不讓人用了！一直在加載是什么鬼？”于是，在第一百個投訴打來的時候，小A已經騎著電驢去送外賣了。而導致小A撿瓶蓋的罪魁禍首瀏覽人數過多，系統直接崩了。

至今，被采訪的小A都表示“現在就是后悔，非常后悔，怎么就沒盯下性能測試呢？”為了避免過早和小A合伙送外賣，我們一起來學習下性能測試吧。

01 什么是性能測試？

性能測試是驗證軟件系統是否能夠達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，優化軟件，最后起到優化系統的目的。

在產品上線前，我們無法知道用戶數量，而且用戶場景也存在不確定性，一旦用戶多了就可能整出各種幺蛾子，所以需要進行系統性能測試。

性能測試可以告訴我們用戶數量增加、系統負載增加時，系統能承受的并發用戶數量，以及帶寬是否夠用、cpu是否夠用、內存是否夠用、硬盤速度是否跟得上等問題。

02 性能測試測什么？

性能測試的類型和劃分網上有很多定義，我這取比較常見的幾個

• 負載測試（Load Testing）：負載測試主要測試軟件系統在不同負載下，性能指標是否符合預定指標，譬如在一定負載時，系統最大支持多少并發用戶數，軟件請求出錯率等。
• 壓力測試（Stress Testing）：壓力測試是指在被測系統在一定飽和狀態下，例如CPU、內存等在飽和使用情況下，系統能夠處理的會話能力。說人話就是看看在極端情況下系統還能不能轉得起來。
• 容量測試（Volume Testing）：確定系統最大承受量，譬如系統最大用戶數，最大存儲量，最多處理的數據流量等。

03 作為產品需要關注的性能點有哪些？

為了安穩端好產品經理的飯碗，我們需要關注這些性能點：

1. 系統處理一個請求或一個任務耗時多少？
2. 系統最多支持多少用戶訪問、系統最大業務處理量是多少？
3. 系統性能可能存在的瓶頸在哪里？
4. 系統能否支持7×24小時的業務訪問？

04 性能測試的常見指標有哪些？

上面叨叨了這么多，大家對性能測試和需要關注的內容應該有所了解了，那么作為產品，我們怎么對性能測試進行驗收呢？為了防止被忽悠，這里我們需要了解一些性能的關鍵指標：

1. 外部指標

• 吞吐量：每秒鐘系統能夠處理的請求數、任務數。
• 響應時間：服務處理一個請求或一個任務的耗時。
• 錯誤率：一批請求中結果出錯的請求所占比例。

2. 內部指標

• 從服務器的角度看，性能測試主要關注CPU、內存、服務器負載、網絡、磁盤IO等。

由于我們是只用指手畫腳，不用自己操刀的產品經理，我們只需要重點關注外部指標就可以了。接下來我們學習這些外部指標。

對于響應時間，我們比較關注的是它的均值、中位值、P95值、P99值等。平均值和中位值比較好理解，P分位值是什么意思呢？以P95為例，將響應時間從小到大排列，順序處于95%位置的值就是P95值。

系統吞吐量則有幾個重要參數：QPS（TPS）、并發數、響應時間：

• QPS（TPS）：每秒鐘request/事務數
• 并發數：系統同時處理的request/事務數
• 響應時間：一般取平均響應時間

QPS（TPS）=并發數/平均響應時間

可以看出一個系統吞吐量通常由QPS（TPS）、并發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降。

在低吞吐量下的響應時間的均值、分布比較穩定，不會產生太大的波動。而在高吞吐量下，響應時間會隨著吞吐量的增長而增長，增長的趨勢可能是線性的，也可能接近指數的。當吞吐量接近系統的峰值時，響應時間會出現激增。

上圖便是吞吐量、響應時長、并發數幾者的關系圖。橫坐標是并發數，綠線是CPU使用率，紫線是吞吐量，即QPS，藍線是響應時間。

05 測試報告長啥樣？

理論終歸于實踐，能看懂測試報告，那讀這篇文章的目的才算達到了。

1. 測試概述

1.1 測試目標

本次測試的目的在于探查XXX項目二期重構環境的系統業務處理性能，以及在高負載情況下的系統表現。

1.2 指標和術語
描述本次測試中涉及到的性能指標術語

2. 環境、工具

2.1 測試環境

服務器：

客戶機：

2.2 測試工具

3. 測試方案

3.1 測試類型

本次性能測試將主要采用以下幾種測試類型：

• 基準測試：在小并發條件下，探測系統各性能指標表現，作為后續比對基礎。
• 壓力測試：由于無法準確預估用戶訪問量，因此考慮使用壓力測試方法。壓力測試旨在通過不斷 增加系統并發處理事務數，增加系統負載，直到系統到達性能瓶頸。以此推算出系統可承載用戶和事務請求數。穩定性測試：
• 將系統置于較長時間高負載場景下，探測系統是否出現穩定性缺陷。

3.2 業務模型

針對系統接口，究竟哪些需要被納入壓測范疇？不同事務應該以何種比例被調用，這是需要建模設計的，也是性能測試的難點之一。

通過對于項目架構和業務場景分析，設計以下業務模型進行模擬和測試：

場景1：簡單業務場景

場景2：混合業務場景

3.3 加密驗簽處理

由于系統對于所有事務請求都進行了加密驗簽處理，因此在本次性能測試中，需要對請求報文進行一致的加密和簽名。處理邏輯如下：

• 使用APP同樣的加密簽名代碼，導出jar包做為加密工具類
• 使用jmeter前置處理器-beanshell處理器調用上述jar包方法實現請求參數加密
• 將加密簽名后的請求參數存儲為變量，后續接口調用時使用

3.4 壓力梯度

對于3.2所述場景，分別進行梯度加壓，從100并發開始，每次遞增100并發數，直至到達系統瓶頸。

4. 測試結果

4.1 聚合報告

場景1-10并發-循環5次

場景1-500并發-循環1次

場景1-550并發-循環1次

4.2 系統吞吐量

場景1-550并發-循環1次

場景2-450并發-循環10次

4.3 資源占用率

最優負載條件下：CPU使用率

內存占用率

磁盤使用率

5. 分析和建議

5.1 測試結論分析

經過多次測試和數據報表分析，可以得出如下結論：

• 當總體并發用戶數為450-500時，系統具有最優性能表現；當事務并發數超過500時，事務失敗率整體上升，系統到達性能拐點。
• 多事務混合條件下，系統巔峰TPS在90左右，平均吞吐量在13-18/s。
• 在小壓力條件下（10并發），最大事務響應時間為查詢用戶信息事務的2042毫秒，平均在600毫秒左右系統。整體事務微觀響應速度較優。
• 滿負載條件下，登錄具有最佳的性能表現，平均響應時間為7000-12000毫秒；查詢用戶信息事務性能較差，平均響應時間在30000-40000區間。滿負載條件下系統整體微觀響應時間較差。查詢用戶接口由于其使用極為頻繁，建議進行SQL效率調優
• 系統資源方面，內存占用率始終處于高位水平（90%以上），磁盤空間由于日志寫入而不斷被占用。

5.2 問題

測試過程中發現了如下顯著問題：

• 加密驗簽功能并未生效-現階段任何簽名均可通過驗簽。屬于功能性問題，不影響性能表現。
• 日志文件由于不斷寫入導致磁盤占滿，建議調低系統日志級別，并做好定期日志備份。
• 內存占用處于高位水平，需要進一步探查原因。