效能測試介紹

指通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試

對效能的認識

從使用者的角度：

從開發的角度：

從系統管理員的角度：

那麼？測試應該關注哪些呢？
測試人員通常是做為軟體質量控制的一個角色，不僅僅是找bug，需要對整個軟體的質量負責，效能也屬於質量的一部分，因此測試人員眼中的效能應該是全面的，考慮的東西也需要全面：

1. 測試人員需要考慮全面的效能，包括使用者、開發、管理員等各個視角的效能。
2. 測試人員在做效能測試時除開要關注表面的現象如響應時間，也需要關注本質，比如使用者看不到的伺服器資料利用率，架構設計是否合理？程式碼是否合理等方方面面。

效能測試型別

1. 基準測試：在給系統施加較低壓力時，檢視系統的執行狀況並記錄相關數做為基礎參考
2. 負載測試：是指對系統不斷地增加壓力或增加一定壓力下的持續時間，直到系統的某項或多項效能指標達到安全臨界值，例如某種資源已經達到飽和狀態等 。
3. 壓力測試：壓力測試是評估系統處於或超過預期負載時系統的執行情況，關注點在於系統在峰值負載或超出最大載荷情況下的處理能力。
4. 穩定性測試：在給系統載入一定業務壓力的情況下，使系統執行一段時間，以此檢測系統是否穩定。
5. 併發測試：測試多個使用者同時訪問同一個應用、同一個模組或者資料記錄時是否存在死鎖或者其他效能問題

應用場景

效能測試應用場景（領域）主要有：能力驗證、規劃能力、效能調優、缺陷發現、效能基準比較。

下表簡單介紹和對比了這幾個場景的各自用途和特點：

效能測試基本概念

1、響應時間

1. 定義：從使用者傳送一個請求到使用者接收到伺服器返回的響應資料這段時間就是響應時間
2. 關鍵路徑：下圖為一次http請求經過的路徑，請求會經過網路傳送到web伺服器進行處理，如果需要操作DB，再由網路轉發到資料庫進行處理，然後返回值給web伺服器，web伺服器最後把結果資料通過網路返回給客戶端
   
3. 計算方法：Response time = (N1+N2+N3+N4)+ (A1+A2+a3)，即：（網路時間 + 應用程式處理時間）
4. 響應時間-負載對應關係：
   
   圖中拐點說明：
   （1）響應時間突然增加
   （2）意味著系統的一種或多種資源利用達到的極限
   （3）通常可以利用拐點來進行效能測試分析與定位

2、吞吐量

1. 定義：單位時間內系統處理的客戶端請求的數量
2. 計算單位：一般使用請求數／秒做為吞吐量的單位，也可以使用頁面數／秒錶表示。
   另外，從業務角度來說也可以使用 訪問人數 /天 或 頁面訪問量／天 做為單位。
3. 計算方法：Throughput = (number of requests) / (total time).
4. 吞吐量-負載對應關係：
   
   圖中拐點說明：
   （1）吞吐量逐漸達到飽和
   （2）意味著系統的一種或多種資源利用達到的極限
   （3）通常可以利用拐點來進行效能測試分析與定位

3、併發數：

（1）併發使用者數：某一物理時刻同時向系統提交請求的使用者數，提交的請求可能是同一個場景或功能，也可以是不同場景或功能。
（2）線上使用者數：某段時間內訪問系統的使用者數，這些使用者並不一定同時向系統提交請求
（3）系統使用者數：系統註冊的總使用者資料
　　　　
三者之間的關係：系統使用者數 >= 線上使用者數 >= 併發使用者數

4、資源利用率

1. 定義：指的是對不同系統資源的使用程度，通常以佔用最大值的百分比來衡量
2. 通常需要關注的伺服器資源如下：
   （1）CPU：就像人的大腦，主要負責相關事情的判斷以及實際處理的機制
   （2）記憶體：大腦中的記憶塊區，將眼睛，面板等收集到的資訊記錄起來的地方，以供cpu進行判斷，但是是臨時的，訪問速度快，如果關機或斷電這裡的資料會消失。
   （3）磁碟IO：大腦中的記憶區塊，將重要的資料儲存起來（永久儲存，關機或斷電不會丟失，速度慢），以便將來再次使用這些資料。
   （4）網路：
3. 資源利用-負載對應關係：
   
   圖中拐點說明：
   （1）伺服器某薦資源使用逐漸達到飽和
   （2）通常可以利用拐點來進行效能測試分析與定位

其它常用概念：

1. TPS：Transactions Per Second，每秒事務數
2. 思考時間：使用者每個操作後的暫停時間，或者叫操作之間的間隔時間，此時間內是不對伺服器產生壓力的
3. 點選數：每秒鐘使用者向WEB伺服器提交的HTTP請求數。
   這個指標是WEB應用特有的一個指標:WEB應用是”請求-響應”模式,使用者發出一次申請,伺服器就要處理一次，所以點選是WEB應用能夠處理的交易的最小單位。如果把每次點選定義為一個交易，點選率和TPS就是一個概念。容易看出，點選率越大，對伺服器的壓力越大。點選率只是一個性能參考指標，重要的是分析點選時產生的影響。需要注意的是，這裡的點選並非指滑鼠的一次單擊操作，因為在一次單擊操作中，客戶端可能向伺服器發出多個HTTP請求.
4. PV：訪問一個URL，產生一個PV（Page View，頁面訪問量），每日每個網站的總PV量是形容一個 網站規模的重要指標。
5. UV：作為一個獨立的使用者，訪問站點的所有頁面均算作一個UV（Unique Visitor，使用者訪問）

效能測試模型

曲線拐點模型

1. X軸代表併發使用者數，Y軸代表資源利用率、吞吐量、響應時間。X軸與Y軸區域從左往右分別是輕壓力區、重壓力區、拐點區。
2. 隨著併發使用者數的增加，在輕壓力區的響應時間變化不大，比較平緩，進入重壓力區後呈現增長的趨勢，最後 進入拐點區後傾斜率增大，響應時間急劇增加。
3. 接著看吞吐量，隨著併發使用者數的增加，吞吐量增加，進入重壓力區後逐步平穩，到達拐點區後急劇下降，說明系統已經達到了處理極限，有點要扛不住的感覺。
4. 同理，隨著併發使用者數的增加，資源利用率逐步上升，最後達到飽和狀態。
5. 最後，把所有指標融合到一起來分析，隨著併發使用者數的增加，吞吐量與資源利用率增加，說明系統在積極處理，所以響應時間增加得並不明顯，處於比較好的狀態。但隨著併發使用者數的持續增加，壓力也在持續加大，吞吐量與資源利用率都達到了飽和，隨後吞吐量急劇下降，造成響應時間急劇增長。輕壓力區與重壓力區的交界點是系統的最佳併發使用者數，因為各種資源都利用充分，響應也很快；而重壓力區與拐點區的交界點就是系統的最大併發 使用者數，因為超過這個點，系統性能將會急劇下降甚至崩潰。

地鐵模型

假設：
某地鐵站進站只有3個刷卡機。
人少的情況下，每位乘客很快就可以刷卡進站，假設進站需要1s。
乘客耐心有限，如果等待超過30min，就暴躁、嘮叨，甚至放棄。

場景一：只有1名乘客進站時，這名乘客可以在1s的時間內完成進站，且只利用了一臺刷卡機，剩餘2臺等待著。

場景二：只有2名乘客進站時，2名乘客仍都可以在1s的時間內完成進站，且利用了2臺刷卡機，剩餘1臺等待著。

場景三：只有3名乘客進站時，3名乘客還能在1s的時間內完成進站，且利用了3臺刷卡機，資源得到充分利用。

場景四：A、B、C三名乘客進站，同時D、E、F乘客也要進站，因為A、B、C先到，所以D、E、F乘客需要排隊。
那麼，A、B、C乘客進站時間為1s，而D、E、F乘客必須等待1s，所以他們3位在進站的時間是2s。

場景五：假設這次進站一次來了9名乘客，有3名的“響應時間”為1s，有3名的“響應時間”為2s（等待1s+進站1s）， 還有3名的“響應時間”為3s（等待2s+進站1s）。

場景六：如果地鐵正好在火車站，每名乘客都拿著大小不同的包，包太大導致卡在刷卡機堵塞，每名乘客的進站時 間就會又不一樣。刷卡機有加寬的和正常寬度的兩種型別，那麼拿大包的乘客可以通過加寬的刷卡機快速進站（增 加頻寬）。

場景七：進站的乘客越來越多，3臺刷卡機已經無法滿足需求，為了減少人流的積壓，需要再多開幾個刷卡機，增 加進站的人流與速度（提升TPS、增大連線數）。

場景八：到了上班高峰時間了，乘客數量上升太快，現有的進站措施已經無法滿足，越來越多的人開始抱怨、 擁擠，情況越來越糟。單單增加刷卡機已經不行了，此時的乘客就相當於“請求”，乘客不是在地鐵進站排隊，就是 在站臺排隊等車，已經造成嚴重的“堵塞”，那麼增加發車頻率（加快應用伺服器、資料庫的處理速度）、增加車廂數量（增加記憶體、增大吞吐量）、增加線路（增加服務的執行緒）、限流、分流等多種措施便應需而生。