一、什么是性能測試
百度百科解釋：
性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。
會LR，jmeter等工具的人不一定會性能測試，會性能測試的人不一定會LR或者jmeter。這兩款工具都是我們日常使用得比較多的性能測試工具。性能測試時一個復雜的過程，它更像是一個過程的統稱。
既然是個過程，那么有必要先對性能測試進行分層，大體上可以分為三層：服務端層、客戶端層，網絡層。
1、服務端
學習性能測試我們首先要弄清楚兩個方向，服務端方向和客戶端方向。首先說服務端，無論是web還是app，服務端的性能測試方向大體上都是類似的。大體也可以分為：操作系統、中間件和容器。
2、客戶端
客戶端性能一般是指具有圖形界面的應用程序的性能，能看得到的頁面，比如網站的各個頁面，app的各個頁面等。當客戶端出現性能問題時，一般的表現就是應用的操作不流暢，圖形界面發生卡頓等。這里要強調一點就是app的性能測試，好多人分不清app的性能測試，首先app的性能測試也是大體分為前端性能測試（即app專項測試）和服務端性能測試，服務端性能測試也就是平常所說的性能測試。
3、區分服務端和客戶端的性能問題
當我們發現性能問題的時候，首先要大概區分是服務端的性能問題還是客戶端的性能問題，然后再去做相應的分析調優。
一般來說單機應用出現性能問題，大部分都是客戶端問題，比如：
- 單機游戲卡頓
- 畫圖軟件打開圖片超慢
- web頁面切換卡頓，頁面加載時間長
一般來說下面的一些性能問題就有可能是服務端問題或網絡問題，比如：
- 微博api訪問速度慢
- 數據查詢速度慢，比如查詢商品或者訂單很慢
還有一些聯網的應用出現性能問題，可能是客戶端也可能是服務端或網絡問題，比如：
- 聊天軟件發送信息慢
- 郵件客戶端收信發信都很卡
- 直播軟件聲音卡頓
二、性能測試目的
- 1、壓力測試下系統是否滿足預期目標；
- 2、發現系統存在的瓶頸，為調優指明方向；
- 3、察看系統承受的最大壓力以及最佳壓力；
- 4、系統在長時間的規定壓力下是否能正常處理各種請求，
考察系統的穩定性； - 5、容量規划，要考慮到未來的用戶慢慢增加后系統是否能滿足要求。
三、性能測試主要術語
並發數：
LoadRunner 中的虛擬用戶數就是並發數，即和系統產生了交互操作，這里注意定義，
是與服務器產生了交互的！
100米比賽，一聲槍響，同時起跑。
注冊用戶數：指系統中全部注冊用戶的數量
在線用戶數：指在相同時間段內都登錄了系統，但未必會產生交互操作。別和並發數混了！
響應時間：
客戶端的請求響應時間 = N1 + A1 + N2 + A2 +N3 + A3 + N4 + A4 + N5 + A5 + N6：
TPS：
- TPS(Transaction Per Second)俗稱每秒通過事務數。即每秒鍾系統能夠處理的交易或
事務的數量， 它是衡量系統處理能力的重要指標。你可以理解為每秒地鐵的檢票機器
能過多少人。 - TPS 不僅僅是 LoadRunner 中重要的性能參數指標，在其他工具或系統里也是非常重
要的指標
他是基於事務統計出來的，所以必須先定義事務 - TPS 不等於吞吐量！！！！不同緯度的統計，吞吐量從網絡角度看，指單位時間內網絡
上傳輸的數據量（吞吐量 = 吞吐率 * 單位時間）
性能測試中TPS上不去的幾種原因淺析
-
1、網絡帶寬
在壓力測試中，有時候要模擬大量的用戶請求，如果單位時間內傳遞的數據包過大，超過了帶寬的傳輸能力，那么就會造成網絡資源競爭，間接導致服務端接收到的請求數達不到服務端的處理能力上限。 -
2、硬件資源
包括CPU（配置、使用率等）、內存（占用率等）、磁盤（I/O、頁交換等）。 -
3、數據庫配置
高並發情況下，如果請求數據需要寫入數據庫，且需要寫入多個表的時候，如果數據庫的最大連接數不夠，或者寫入數據的SQL沒有索引沒有綁定變量，抑或沒有主從分離、讀寫分離等，就會導致數據庫事務處理過慢，影響到TPS。 -
4、壓力機
比如jmeter，單機負載能力有限，如果需要模擬的用戶請求數超過其負載極限，也會間接影響TPS（這個時候就需要進行分布式壓測來解決其單機負載的問題）。 -
5、業務邏輯
業務解耦度較低，較為復雜，整個事務處理線被拉長導致的問題。
事務：事務是性能測試腳本的一個重要特性。要度量服務器的性能，需要定義事務，每個事務
都包含事務開始和事務結束標記。事務用來衡量腳本中一行代碼或多行代碼的執行所耗
費的時間。
PV
page view（PV）：頁面瀏覽量或點擊量，用戶每次刷新即被計算一次。我們可以認為，用戶的一次刷新，給服務器造成了一次請求
去並發數
並發數的定義：並發數，計算機網絡術語，是指同時訪問服務器站點的連接數。
大部分人在剛開始做性能測試的時候都一直在糾結“並發數”，
並發用戶數並沒有那么重要，也不是衡量的重要指標。
- 1、假如 1 個用戶在 1s 內完成 1 筆事物，tps=1
- 2、假如某筆業務響應時間是 1ms，1 個用戶在 1s 內完成 1000 筆事物，tps=1000；
- 3、如果某筆業務響應時間是 1s，1 個用戶在 1s 內完成 1 筆事物，要想達到 1000tps，至少需要 1000 個用戶；
所以，1 個用戶可以產生 1000tps，1000 個用戶也可以產生 1000tps，無非是看響應
時間快還是慢，用並發數來衡量沒什么意義。因此，我們要弱化並發數的概念。
而且如果你加入思考時間，並發數基本可以增加一倍。
再舉個例子：
每個地鐵口閘機每秒鍾只能通過1個人（TPS=1），10個人去排隊，想一起通過（並發數=10），那是不行的，只能慢慢排隊一個一個通過。把通過閘機的時間壓縮，比如刷卡相應很快，0.1s就能通過一個人了。那1秒鍾通過的人數就是10了，抑或增加閘機數（相當於加服務器），那每秒鍾通過的人數（tps）是不是多了。所以並發更多的是去幫我們找到性能瓶頸的那個點。
- 在性能測試中做上萬的用戶並發這種情況非常少，如果只需要保證系統處理業務時間足
夠快，那么幾百個甚至幾十個足已。
日活量有10萬，同時在線的有多少？1萬？
同時對一個接口產生的壓力又有多少人（比如同時加入購物車，注意是同時），1千？就算你是同時點擊加入購物車，
到達服務器的時間也是有差別的哦，中間不是還要經過網絡么，所以仔細想想，並發真的需要這么多么。
性能測試典型模型分析
性能曲線模型
- 最開始，隨着並發用戶數的增長，資源占用率和吞吐量會相應的增長，但是響應時間的
變化不大； - 不過當並發用戶數增長到一定程度后，資源占用達到飽和，吞吐量增長明顯放緩甚至停
止增長，而響應時間卻進一步延長。 - 如果並發用戶數繼續增長，你會發現軟硬件資源占用繼續維持在飽和狀態，吞吐量開始
下降，響應時間明顯的超出了用戶可接受的范圍，並且最終導致用戶放棄了這次請求甚
至離開。 - 根據這種性能表現，圖中划分了三個區域，分別是較輕的壓力區、較重的壓力區和用戶無法忍受並放棄請求區域。在較輕的壓力區和
較重的壓力區兩個區域交界處的並發用戶數，我們稱為“最佳並發用戶數（The
Optimum Number of Concurrent Users）”。
而 較重的壓力區 和用戶無法忍受並放棄請求區域兩個區域交界處的並發用戶數則稱為“最大並發用戶數（The Maximum Number of
Concurrent Users）”。 - 當系統的負載等於最佳並發用戶數時，系統的整體效率最高，沒有資源被浪費，用戶也
不需要等待 - 當系統負載處於最佳並發用戶數和最大並發用戶數之間時，系統可以繼續工作，但是用
戶的等待時間延長，滿意度開始降低，並且如果負載一直持續，將最終會導致有些用戶
無法忍受而放棄； - 而當系統負載大於最大並發用戶數時，將注定會導致某些用戶無法忍受超長的響應時間
而放棄。
木桶原理/短板效應
一個木桶能裝多少水不是取決於最長的板，而是最短的板。所以在性能測試中我們
應該優先調整最短的那個板，而不是一籮筐都搞！
多角度看待性能測試
從三個不同層面來對性能進行闡述：
- 從用戶角度，軟件性能就是軟件對用戶操作的響應時間；
- 從運維人員角度，軟件性能表現在系統是否能夠提供給用戶穩定、可靠、可持續服務，
包括服務器資源等； - 從開發員角度，軟件性能表現在如何調整設計和代碼的實現，通過調整系統的設置等提
高性能；
故考慮性能測試，要從不同角度去思考問題，從用戶角度和從應用系統角度來看性能
測試，理解上會存在一些差異；
電商網站每年的雙 11 活動都是對其服務器性能的挑戰。因為在這一天很多商品特價
（但其實特價沒有只有鬼知道），購物的用戶量劇增。做為網站的高層更多的關心是什么指
標？對於一名技術人員，我們可能更關心什么指標？
四、性能測試流程
過程分析：
（1）性能需求點獲取
- 根據客戶的需求由客戶方提出
- 根據歷史數據分析
- 參考歷史項目或者其他同行業的項目
- 業內通用規則
- 確實沒有數據，那就根據自己來，然后一邊分析
（2）測試點的提取，常放在客戶常用的、重點的模塊和功能上
- 用戶常用功能，比如登錄
- 數據流轉向復雜或頻繁的地方
- 發生頻率高的地方，比如搜索，提交訂單，下單結賬。
- 關鍵程度高的（比如產品經理認為絕對不能出現問題的地方，登錄、下單等）
- 資源占用非常嚴重的
- 關鍵的接口
（3）測試環境
- 最好能和線上保持一致
- 如果不能那就等比的放大或縮小
- 軟件版本應該一致
（4）測試數據
- 鋪底數據的准備：是空庫還是有數據量。數據量的選擇參考線上的數據量進行
等比的放大或縮小。 - 最好的數據來源於線上的真實數據，因為分布合理
- 如果涉及到保密的數據，注意數據的脫密處理
（5）測試過程
- 性能測試時一個需要不斷改進的過程，每一次盡量做得更好，多做一點點以前
沒想到的東西，然后不斷積累總結，然后你會發現自己對性能測試有了更深的
理解
（6）響應時間預估
- 線上監控系統得知
- 業界統一參考標准：2 - 5 - 8
（7）預估並發用戶數
-
系統的性能由TPS決定，跟並發用戶數沒有多大關系。系統最大的TPS是一定
的，就好比池塘里裝的水是有限的。但是並發用戶數不一定，可以通過減小思
考時間來增大並發用戶數。 -
新系統：沒有歷史數據參考，只能通過業務部門來評估；
80-20：百分之八十的事物是在百分之二十的時間內完成的。（只知道系統注冊用戶數 or 在線用戶數的時候可選擇） -
舊系統：最好通過日志分析來得出
-
可以選取峰值時刻，在一定時間內（單位：秒）使用系統的人數，並發用戶數取 10%，
之后可根據實際情況梯階式增加