大家好，我是黎潘，來自重慶，狂師老師的全棧測開訓練營中上一期的學員。
大多數測試人員在談到性能測試時，往往會倍感壓力。對於我來說更是如此，想做好性能測試需要龐大的知識體系，不斷實踐所總結的經驗教訓更是彌足珍貴。而且每個人對性能測試的理解都有獨到的地方，此次有幸參加全棧測開訓練營在狂師老師的指導下逐步揭開性能測試得神秘面紗，結合課堂學習及自身消化理解后的，歸納了一些性能測試的基礎知識，希望對大家理解性能測試有所幫助。
一、簡述性能測試
性能測試含義：系統在一個給定的環境和場景中的性能表現是否與預期目標一致，評判系統是否存在性能缺陷，並根據測試結果識別性能瓶頸，改善系統性能的完整的過程。
介入時機：通常是在功能測試完成之后，並且系統功能處於相對穩定狀態。
1.1 性能測試開展范圍
客戶端：web端，PC端，移動端，小程序，每一個都是不同領域的性能測試，關注點都不盡相同。還包括一個服務端的性能測試，本篇也主要是以服務端的性能測試來展開的。
1.2 軟件性能關注點
- 終端用戶
使用過程中更加關注響應時間，穩定性。總得來說就是用戶體驗要好。
- 系統運維人員
系統最大並發，最大業務處理量，能支持多少用戶訪問，能否長時間提供服務，服務器資源使用，數據庫資源使用，系統是否可以實現擴展。總的來說，更加關注系統的穩定性，資源利用率，可擴展性，系統容量等。
- 軟件設計開發人員
架構設計，數據庫設計，代碼設計，是否存在不合理的內存使用和線程同步方式，以及資源競爭等，總的來說，更加關注系統架構，數據庫設計，設計與代碼實現等。
- 性能測試人員
系統資源指標，業務性能指標，DB性能指標，系統穩定性，支持最大並發，性能拐點等，幾乎包括了上述所有人員的關注點。
二、后端性能常見指標
2.1 業務性能指標
並發用戶數：並發用戶數取決於業務並發用戶數和用戶行為模式，也就是說實際使用的用戶並不是每種用戶行為都會對服務端產生壓力，通常是指同一批用戶同時執行一個對后端服務產生壓力的操作行為。
響應時間：響應時間是系統最重要的性能指標，直觀的反映了系統的快慢。指的是用戶端發出請求到得到響應的整個過程所經歷的。
系統處理能力：系統處理能力是指系統在利用系統硬件平台和軟件平台進行信息處理的能力，通常有以下幾個指標衡量。
- TPS：每秒事務數，指服務器在單位時間內（秒）可以處理的事務數量。
- QPS：每秒查詢率，指服務器在單位時間內（秒）處理的查詢請求速率。
- HPS：每秒點擊次數，單位是次/秒。
吞吐量：系統在單位時間內處理請求的數量。
事務成功率：單位時間內系統可以成功完成多少個定義的事務。
超時錯誤率：主要指事務由於超時或系統內部其它錯誤導致失敗占總事務的比率。
2.2 系統資源指標
CPU使用率：指用戶進程與系統進程消耗的CPU時間百分比。
內存利用率：內存利用率=（1-空閑內存/總內存大小）*100%。
磁盤I/O：磁盤吞吐量簡稱為 Disk Throughput，是指在無磁盤故障的情況下單位時間內通過磁盤的數據量。
網絡帶寬：發送和接收字節的速率，包括幀字符在內。
數據庫性能指標：sql語句，連接數，讀寫速度，資源使用率等。
上述只是一些常見的指標，通常還包括一些其他中間件，以及整個鏈路所經過的服務器指標。
2.3 並發用戶數，響應時間，系統吞吐量三者之間的關系
未達到系統瓶頸：隨着並發用戶數的增加，系統吞吐量會逐漸增加，此時響應時間會較快。
達到系統瓶頸：隨着並發用戶數的增加，系統吞吐量不再會增加，此時響應時間會開始變長。
超過系統瓶頸：隨着並發用戶數的增加，系統吞吐量出現下降，此時響應時間會逐漸拉長，甚至無響應。
三、常見性能測試方法
后端性能測試：通過模擬一定的並發用戶量，獲取一系列需要的系統，業務性能指標，來驗證是否滿足我們預期性能需求或者探索系統的容量和潛在的問題。
代碼級性能測試：在單元測試階段，針對代碼本身，例如通過多次執行單元測試用例，獲取一些關鍵算法的性能指標，是否滿足需求。
壓力測試：系統在一定資源飽和的情況下，模擬一定用戶量，不斷對系統施壓，驗證系統處於壓力情況下的性能表現，尋找系統的性能瓶頸點。
配置測試：觀察系統在不同配置下性能的表現，了解不同環境配置對系統性能的影響程度。
並發測試：模擬多個用戶同一時間訪問一個系統，模塊或數據記錄等其他並發操作，關注系統可能存在的性能瓶頸，如內存泄漏，線程死鎖或資源競爭等問題。
可靠性測試：給系統施加一定的壓力，持續運行一段時間，觀察系統能否穩定運行。
四、企業中常見性能測試類型
性能基准測試：基於固定的硬件環境和部署架構（比如專用的服務器、固定的專用網絡環境、固定大小的集群規模、相同的系統配置、相同的數據庫背景數據等），通過執行固定的性能測試場景得到系統的性能測試報告，然后與上一版本發布時的指標進行對比，如果發現指標有“惡化”的趨勢，就需要進一步排查。
穩定性測試：又稱可靠性測試，主要是通過長時間（7*24 小時）模擬被測系統的測試負載，來觀察系統在長期運行過程中是否有潛在的問題。通過對系統指標的監控，穩定性測試可以發現諸如內存泄漏、資源非法占用等問題。
並發測試：是在高並發情況下驗證單一業務功能的正確性以及性能的測試手段。高並發測試一般使用思考時間為零的虛擬用戶腳本來發起具有“集合點”的測試。
容量規划測試：是為了完成容量規划而設計執行的測試。容量規划的主要目的是，解決當系統負載將要達到極限處理能力時，我們應該如何通過垂直擴展（增加單機的硬件資源）和水平擴展（增加集群中的機器數量）增加系統整體的負載處理能力的問題。
五、常見的性能測試工具
目前市面上比較常見的服務端性能測試少說也有幾十種，這里我們簡單的比較下常見的三種，即JMeter，locust，LoadRunner。
5.1 組件對比
5.2 功能區別
通過以上對比，大家結合自己公司的需求，選擇合適的性能測試工具。
5.3 locust入門
定義
Locust是使用Python語言編寫實現的開源性能測試工具，簡潔、輕量、高效，並發機制基於gevent協程，可以實現單機模擬生成較高的並發壓力。中文意為：蝗蟲，蝗蟲過境，寸草不生。
主要特點
- 使用Python語言編寫用戶測試場景
- 分布式、可擴展，支持成千上萬的用戶
- 基於事件驅動，基於gevent協程實現並發機制。
- 基於Web的用戶界面，用戶可以實時監控腳本運行狀態
- 幾乎可以測試任何系統，除了Web HTTP接口外，還可自定義Clients測試其他類型系統
安裝
直接通過pip install locust命令安裝。
安裝成功后可以輸入pip show locust命令查看是否安裝成功，以及通過locust --help查看幫助信息。
簡單腳本示例
from locust import HttpUser, TaskSet, task
class WebsiteTasks(TaskSet):
# 任務啟動前置執行
#def on_start(self):
self.login()
# self.client屬性使用Python request庫的所有方法，調用和使用方法和requests完全一致
#def login(self):
# self.client.post("/login", {"username": "mikezhou", "password": "123456"})
# 此腳本用不到提前登陸，只起個示例作用，運行前注釋掉
@task(2) # 通過@task()裝飾的方法為一個事務，方法的參數用於指定該行為的執行權重，參數越大每次被虛擬用戶執行的概率越高，默認為1
def index(self):
self.client.get("/")
def about(self):
self.client.get("/about/")
class WebsiteUser(HttpUser):
# 被測系統的host，在終端中啟動locust時沒有指定--host參數時才會用到
host = "http://example.com"
# TaskSet類，該類定義用戶任務信息，必填。這里就是WebsiteTasks類名,因為該類繼承TaskSet
tasks = [WebsiteTasks]
# 每個用戶執行兩個任務間隔時間的上下限（毫秒）,具體數值在上下限中隨機取值，若不指定默認間隔時間固定為1秒
min_wait = 3000
max_wait = 10000
locust腳本命令運行
# 方法一：腳本調試無頭模式運行
locust -f locustfile.py --headless -u 10 -r 1 -t 30s
# -f:指定文件
# -u：指定用戶量
# -r：每秒啟動用戶數
# -t：運行時間
# --headless：開啟無頭模式，即不使用UI界面操作
# 方法二：指定IP和端口啟動，使用UI界面
locust -f locustfile.py --web-host 127.0.0.1 --web-port 8080
# 以上就是簡單的啟動locust腳本的方式，詳細可以查看官方文檔或者locust --help
locust的UI界面
- Number of new load test：設置模擬的用戶總數
- Spawn rate (users spawned/second)：每秒啟動的虛擬用戶數
- Host (e.g. http://www.example.com)：被測目標地址
- Start swarming：執行locust腳本
測試結果頁面
- Type：請求類型
- Name：請求路徑
- Requests：當前完成的請求數量
- Fails：當前失敗數量
- Median：響應時間中間值
- 90%ile（ms）：正態分布90%的值在300ms內
- Average（ms）：平均響應時間
- Min（ms）：最小響應時間
- Max（ms）：最大響應時間
- Average size (bytes)：平均
- Current RPS：當前RPS
- Current Failures/s：當前失敗的RPS/s
其他模塊
- New test：點擊該按鈕對總虛擬用戶數和每秒啟動的虛擬用戶數進行編輯重跑
- Statistics：類似JMeter的聚合報告
- Charts：測試結果變化趨勢圖
- Failures：失敗請求的展示界面
- Exceptions：異常請求的展示界面
- Download Data：測試數據下載模塊，提供三種類型的CSV格式下載，分別是：Statistics、responsetime、exceptions，還有總的測試報告Report
由於本篇是對性能測試理論知識的分享，想了解更多locust的高級使用方法，可以參考官方文檔。
注意： 后端性能測試工具是實現后端性能測試的技術手段，不能簡單地把使用后端性能測試工具等同於后端性能測試。一般是在測試腳本開發和測試執行階段發揮作用。
六、性能測試流程
對於我們初學性能測試時，往往會陷入一個誤區，那就是單純的去學習性能測試工具，認為學會了工具的使用，就掌握了性能測試。這其實是大錯特錯的，工具的學習只是其中的一個階段，而且是比較基礎的一個階段，在整個性能測試流程中，性能測試執行策略，性能場景和分析才是重中之重，也是最難的部分。
性能測試的學習路徑可以分為五個階段：
- 性能理論學習期
- 性能工具學習期
- 性能場景學習期
- 性能分析學習期
- 性能調優學習期
6.1 性能測試的前提
日常工作中，被問及何時進行性能測試時，往往很多人都是摸不着頭腦，大多數情況下都是被動接受領導或者開發給的任務，才回去進行性能測試，很少人會主動出擊，去思考在什么階段進行性能測試，下面給出幾點建議，當然大前提肯定是在功能測試之后，整個系統都是處於一種穩定的狀態。
- 應用使用人數逐漸增多，性能問題頻發，影響到用戶的日常操作
- 需要提供很高穩定性的基礎服務，這種一般都是系統的核心服務，支撐了多端的業務
- 改動了核心應用，擔心對鏈路有影響
6.2 制定性能測試目標
- 第一種是以衡量系統的處理能力為核心目標
- 第二種檢測系統的健壯性
- 第三種目標是系統的穩定性
- 第四種性能測試目標是專項能力是否達標
6.3 性能測試場景設計
1. 測試負載組成
- 虛擬用戶腳本
- 各個虛擬用戶腳本的並發數量
- 總的並發用戶數
2. 負載策略
- 加壓策略
- 減壓策略
- 最大負載運行時間
- 延時策略
3. 資源監控范圍定義
- 操作系統級別的監控指標
- 應用服務器的監控指標
- 數據庫服務器的監控指標
- 緩存集群的監控指標
4. 終止方式
- 腳本出錯時的處理方式
- 負載熔斷機制
5. 負載產生規划
- 壓力產生器數量
- 網絡帶寬要求
6.4 制定性能測試方案
性能測試方案是在正式進行性能測試之前的工作，主要包括：
- 制定性能測試目的
- 性能測試場景梳理
- 確定被測業務的部署結構
- 業務數據的分析
- 業務規則的分析確認
- 測試監控的內容確定
- 性能測試排期涉及人員
七、總結
今天談到的性能測試知識，不過是九牛一毛。想要正真掌握性能測試還需要不斷的親身實踐，擴大自己知識的廣度和深度，對於初識性能測試且沒有實際經驗的我來說，這將是我以后學習，並加以實踐的基石。