性能測試介紹
指通過自動化的測試工具模拟多種正常、峰值以及異常負載條件來對系統的各項性能名額進行測試
對性能的認識
從使用者的角度：
從開發的角度：
從系統管理者的角度：
那麼？測試應該關注哪些呢？
測試人員通常是做為軟體品質控制的一個角色，不僅僅是找bug，需要對整個軟體的品質負責，性能也屬于品質的一部分，是以測試人員眼中的性能應該是全面的，考慮的東西也需要全面：
- 測試人員需要考慮全面的性能，包括使用者、開發、管理者等各個視角的性能。
- 測試人員在做性能測試時除開要關注表面的現象如響應時間，也需要關注本質，比如使用者看不到的伺服器資料使用率，架構設計是否合理？代碼是否合理等方方面面。
性能測試類型
- 基準測試：在給系統施加較低壓力時，檢視系統的運作狀況并記錄相關數做為基礎參考
- 負載測試：是指對系統不斷地增加壓力或增加一定壓力下的持續時間，直到系統的某項或多項性能名額達到安全臨界值，例如某種資源已經達到飽和狀态等 。
- 壓力測試：壓力測試是評估系統處于或超過預期負載時系統的運作情況，關注點在于系統在峰值負載或超出最大載荷情況下的處理能力。
- 穩定性測試：在給系統加載一定業務壓力的情況下，使系統運作一段時間，以此檢測系統是否穩定。
- 并發測試：測試多個使用者同時通路同一個應用、同一個子產品或者資料記錄時是否存在死鎖或者其他性能問題
應用場景
性能測試應用場景（領域）主要有：能力驗證、規劃能力、性能調優、缺陷發現、性能基準比較。
下表簡單介紹和對比了這幾個場景的各自用途和特點：
| 作用 | 主要用途 | 典型場景 | 特點 | 常用性能測試方法 |
| 能力驗證 | 關注在給定的軟硬體條件下，系統能否具有預期的能力表現 | 在要求平均響應時間小于2秒的前提下，如何判斷系統是否能夠支援50萬使用者/天的通路量？ | a)要求在已确定的環境下運作b)需要根據典型場景設計測試方案和用例，包括操作序列和并發使用者量，需要明确的性能目标 | a)負載測試 b)壓力測試 c)穩定性能測試 |
| 規劃能力 | 關注如何使系統具有我們要求的性能能力 | 某某系統計劃在一年内獲客量在到xxx萬，系統到時候是否能支援這麼多使用者量？如果不能需要如何調整系統的配置？ | a) 它是一種探索性的測試 b) 常用于了解系統性能和獲得擴充性能的方法 | a) 負載測試 b) 壓力測試 c) 配置測試 |
| 性能調優 | 主要用于對系統性能進行調優 | 某某系統上線運作一段時間後響應速度越來越慢，此時應該如何辦？ | 每次隻改變一個配置，切忌無休止的調優 | a) 并發測試 b) 壓力測試 c) 配置測試 |
| 缺陷發現 | 發現缺陷或問題重制、定位手段 | 某些缺陷隻有在高負載的情況下才能暴露出來，如線程鎖、資源競争或記憶體洩露 | 做為系統測試的補充,用來發現并發問題，或是對系統已經出現的問題進行重制和定位 | a) 并發測試 b) 壓力測試 |
| 性能基準比較 | 常用于靈活開發過程中，靈活開發流程的特點是小步快走，快速試錯，疊代周期短，需求變化頻繁 | 很難定義完善的性能測試目标，也沒有時間在每個疊代開展詳細的性能測試，可以通過建立性能基線，通過比較每次疊代中的性能表現變化，判斷疊代是否達到了目标 |
性能測試基本概念
1、響應時間
- 定義：從使用者發送一個請求到使用者接收到伺服器傳回的響應資料這段時間就是響應時間
- 關鍵路徑：下圖為一次http請求經過的路徑，請求會經過網絡發送到web伺服器進行處理，如果需要操作DB，再由網絡轉發到資料庫進行處理，然後傳回值給web伺服器，web伺服器最後把結果資料通過網絡傳回給用戶端
- 計算方法：Response time = (N1+N2+N3+N4)+ (A1+A2+a3)，即：（網絡時間 + 應用程式處理時間）
-
響應時間-負載對應關系：
圖中拐點說明：
（1）響應時間突然增加
（2）意味着系統的一種或多種資源利用達到的極限
（3）通常可以利用拐點來進行性能測試分析與定位
2、吞吐量
- 定義：機關時間内系統處理的用戶端請求的數量
-
計算機關：一般使用請求數／秒做為吞吐量的機關，也可以使用頁面數／秒表表示。
另外，從業務角度來說也可以使用 通路人數 /天 或 頁面通路量／天 做為機關。
- 計算方法：Throughput = (number of requests) / (total time).
-
吞吐量-負載對應關系：
圖中拐點說明：
（1）吞吐量逐漸達到飽和
（2）意味着系統的一種或多種資源利用達到的極限
（3）通常可以利用拐點來進行性能測試分析與定位
3、并發數：
（1）并發使用者數：某一實體時刻同時向系統送出請求的使用者數，送出的請求可能是同一個場景或功能，也可以是不同場景或功能。
（2）線上使用者數：某段時間内通路系統的使用者數，這些使用者并不一定同時向系統送出請求
（3）系統使用者數：系統注冊的總使用者資料
三者之間的關系：系統使用者數 >= 線上使用者數 >= 并發使用者數
4、資源使用率
- 定義：指的是對不同系統資源的使用程度，通常以占用最大值的百分比來衡量
-
通常需要關注的伺服器資源如下：
（1）CPU：就像人的大腦，主要負責相關事情的判斷以及實際處理的機制
（2）記憶體：大腦中的記憶塊區，将眼睛，皮膚等收集到的資訊記錄起來的地方，以供cpu進行判斷，但是是臨時的，通路速度快，如果關機或斷電這裡的資料會消失。
（3）磁盤IO：大腦中的記憶區塊，将重要的資料儲存起來（永久儲存，關機或斷電不會丢失，速度慢），以便将來再次使用這些資料。
（4）網絡：
-
資源利用-負載對應關系：
圖中拐點說明：
（1）伺服器某薦資源使用逐漸達到飽和
（2）通常可以利用拐點來進行性能測試分析與定位
其它常用概念：
- TPS：Transactions Per Second，每秒事務數
- 思考時間：使用者每個操作後的暫停時間，或者叫操作之間的間隔時間，此時間内是不對伺服器産生壓力的
-
點選數：每秒鐘使用者向WEB伺服器送出的HTTP請求數。
這個名額是WEB應用特有的一個名額:WEB應用是”請求-響應”模式,使用者發出一次申請,伺服器就要處理一次，是以點選是WEB應用能夠處理的交易的最小機關。如果把每次點選定義為一個交易，點選率和TPS就是一個概念。容易看出，點選率越大，對伺服器的壓力越大。點選率隻是一個性能參考名額，重要的是分析點選時産生的影響。需要注意的是，這裡的點選并非指滑鼠的一次單擊操作，因為在一次單擊操作中，用戶端可能向伺服器發出多個HTTP請求.
- PV：通路一個URL，産生一個PV（Page View，頁面通路量），每日每個網站的總PV量是形容一個 網站規模的重要名額。
- UV：作為一個獨立的使用者，通路站點的所有頁面均算作一個UV（Unique Visitor，使用者通路）
性能測試模型
曲線拐點模型
- X軸代表并發使用者數，Y軸代表資源使用率、吞吐量、響應時間。X軸與Y軸區域從左往右分别是輕壓力區、重壓力區、拐點區。
- 随着并發使用者數的增加，在輕壓力區的響應時間變化不大，比較平緩，進入重壓力區後呈現增長的趨勢，最後 進入拐點區後傾斜率增大，響應時間急劇增加。
- 接着看吞吐量，随着并發使用者數的增加，吞吐量增加，進入重壓力區後逐漸平穩，到達拐點區後急劇下降，說明系統已經達到了處理極限，有點要扛不住的感覺。
- 同理，随着并發使用者數的增加，資源使用率逐漸上升，最後達到飽和狀态。
- 最後，把所有名額融合到一起來分析，随着并發使用者數的增加，吞吐量與資源使用率增加，說明系統在積極處理，是以響應時間增加得并不明顯，處于比較好的狀态。但随着并發使用者數的持續增加，壓力也在持續加大，吞吐量與資源使用率都達到了飽和，随後吞吐量急劇下降，造成響應時間急劇增長。輕壓力區與重壓力區的交界點是系統的最佳并發使用者數，因為各種資源都利用充分，響應也很快；而重壓力區與拐點區的交界點就是系統的最大并發 使用者數，因為超過這個點，系統性能将會急劇下降甚至崩潰。
地鐵模型
假設：
某地鐵站進站隻有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）。
場景六：如果地鐵正好在火車站，每名乘客都拿着大小不同的包，包太大導緻卡在刷卡機堵塞，每名乘客的進站時 間就會又不一樣。刷卡機有加寬的和正常寬度的兩種類型，那麼拿大包的乘客可以通過加寬的刷卡機快速進站（增 加帶寬）。