大家好，我是黎潘，來自重慶，狂師老師的全棧測開訓練營中上一期的學員。
大多數測試人員在談到效能測試時，往往會倍感壓力。對於我來說更是如此，想做好效能測試需要龐大的知識體系，不斷實踐所總結的經驗教訓更是彌足珍貴。而且每個人對效能測試的理解都有獨到的地方，此次有幸參加全棧測開訓練營在狂師老師的指導下逐步揭開效能測試得神祕面紗，結合課堂學習及自身消化理解後的，歸納了一些效能測試的基礎知識，希望對大家理解效能測試有所幫助。
一、簡述效能測試
效能測試含義：系統在一個給定的環境和場景中的效能表現是否與預期目標一致，評判系統是否存在效能缺陷，並根據測試結果識別效能瓶頸，改善系統效能的完整的過程。
介入時機：通常是在功能測試完成之後，並且系統功能處於相對穩定狀態。
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 制定效能測試方案
效能測試方案是在正式進行效能測試之前的工作，主要包括：
- 制定效能測試目的
- 效能測試場景梳理
- 確定被測業務的部署結構
- 業務資料的分析
- 業務規則的分析確認
- 測試監控的內容確定
- 效能測試排期涉及人員
七、總結
今天談到的效能測試知識，不過是九牛一毛。想要正真掌握效能測試還需要不斷的親身實踐，擴大自己知識的廣度和深度，對於初識效能測試且沒有實際經驗的我來說，這將是我以後學習，並加以實踐的基石。