性能測試基礎
進行性能測試，我們需要關注性能測試的哪些方面，如果能回答出以下幾個問題（5W），我們就基本入門性能測試了，然後就需要我們通過實踐，運用這些性能知識理論去爲實踐服務，幫助我們剛好的檢查和定位系統的性能問題，從而改善我們的系統軟件。
- WHY：爲什麼要進行性能測試
- WHAT：關注的性能測試內容是什麼
- WHO：哪些人員需要關注性能問題
- WHERE：性能測試的關注領域
- WHEN：何時進行性能測試
以下分別回答上面的5個問題。
WHY（爲什麼進行性能測試）
當我們使用一個軟件的時候，可能在某些高峯期時段，我們發現軟件使用起來特別的卡，特別是我們提交一個表單信息，或進行其他的操作，半天才會響應。在這種高併發的場景下，極慢的響應時間就會使用戶在使用軟件的時候特別憤怒。而對於我們的系統而言，在用戶量特別大的情況下，如果我們不去測試這個併發用戶量的極限值，可能就會導致系統崩潰，進而引發更嚴重的事情。因此，進行性能測試非常重要，它是衡量我們的軟件在壓力負載情況下的承受能力。所以，我們可以從以下幾個方面思考軟件的性能問題：
- 應用程序是否能夠很快的響應用戶的要求
- 應用程序是否能夠處理預期的用戶負載並由盈餘能力
- 應用程序是否能夠處理業務所需要的事務數量
- 在預期和非預期的用戶負載下，應用程序是否穩定
- 是否確保用戶在真正使用軟件時獲得舒適的體驗
WAHT（關注什麼）
我們的性能測試需要關注哪些內容呢？可以從以下幾個方面入手：
- 併發用戶數/吞吐量
- 平均響應時間
- 服務器資源佔用情況
- 可靠性、可擴展性
- 發現引起系統問題的原因，關注採用何種技術提高系統性能
- 軟硬件配置是否合理（容量規劃/硬件選型）
WHO（誰關注）
- 開發人員
開發人員需要關注系統的架構是否合理；數據庫設計是否存在問題；代碼是否存在性能問題，會不會有內存泄漏；系統中是否存在不合理的線程同步方式和不合理的資源競爭。
- 系統管理員
系統管理員（包括操作系統管理人員、網絡管理人員、服務器管理人員等），他們需要關注：
資源利用率：應用服務器和數據庫資源使用狀況是否合理。
系統容量：系統最多能支持多少用戶的訪問，系統最大的業務處理量是多少。
系統穩定性：系統是否能支持7*24小時的業務訪問。
系統的可擴展性：系統是否能實現擴展，系統性能可能的瓶頸在哪裏，更換哪些設備能夠提高系統性能。
- 用戶
用戶最關心的是系統的響應時間，過長時間的等待會使用戶煩躁，甚至放棄使用該軟件系統。
對於一般的web網站來說，普遍的標準原則是3/5/8(2/5/10)
3：3秒用戶會覺得是一個很好的體驗。
5：5秒用戶會覺得差了一點，還好，一般用戶能夠接受。
8：8秒是用戶所能承受的最大極限。
- 業務人員
業務人員關注的是如何向用戶提供參數，例如支持多少用戶使用，響應時間是多少。
- 測試人員
測試人員需要關注以上所有層面，是否能夠發現系統中存在的瓶頸，是否真實有效的評估系統性能能力。
WHERE（關注領域）
- 能力驗證
性能測試中最簡單也是最常用的一個領域，主要關心的是“在給定的條件下，系統能否具有預期的表現”。
- 規劃能力
規劃能力領域主要關心的是“如何才能是系統具有我們要求的性能能力，或在某種可能發生的條件下，系統具有如何的性能能力”。
- 性能調優
主要應用於對系統性能進行調優。一般來說，性能調優活動會和其他領域的活動交雜一起，是一種在開發階段和測試階段都可能會涉及到的性能測試應用領域。
- 發現缺陷
該領域的主要目的是通過性能測試的手段來發現系統中存在的缺陷。
需要注意的是：性能測試並不獨立於功能測試，它是在滿足功能的情況下進一步的調優。性能測試並不只是併發用戶的測試。
WHEN（何時測試）
- 功能測試中後期
性能測試並不是簡單的在其他測試完成後測試一下就行了，它在我們的測試過程中佔有不容忽視的比重。
性能測試中的常見術語
性能測試是通過自動化測試工具模擬多種正常、峯值以及異常負載條件對系統的各項指標進行測試。系統的性能是一個廣泛的概念，對一個軟件系統而言包括執行效率、資源佔用、穩定性、安全性、兼容性、可擴展性、可靠性等等。
一般我們主要針對系統法性能指標指定性能測試方案，執行測試用，得出測試結果來驗證系統的性能指標是否滿足既定值。性能指標可能包括系統各方面的能力，如系統併發處理能力，系統響應時間，批量業務處理能力等等。性能測試主要用來保證產品上線或發佈之後系統的性能滿足用戶的需求。性能測試在軟件質量保證中起重要作用。
併發數
系統用戶數：簡單的說是該系統的註冊用戶數，這些用戶可以是活躍的，也可以是殭屍的。
在線用戶數：即登錄系統法用戶，例如，其中500個用戶的狀態爲在線狀態，但在線用戶並不一定都會對服務器產生壓力，因爲有的用戶登錄後什麼都不幹。
併發用戶數：是對服務器產生壓力的用戶。例如，在線的500個用戶中，只有20%的用戶對服務器產生壓力，這20%的用戶就是併發數。嚴格上講，併發用戶數是同一時間進行同一操作的用戶數。
響應時間（Reponse Time）
又叫請求響應時間：TTLB（time to last byte），對請求作出響應所需要的時間
網絡傳輸（請求）時間+服務器處理（一層或多層）時間+網絡傳輸（響應）時間。
事務響應時間 （Transaction Reponse Time）
事務是指一組密切相關的操作組合。例如一次登錄可能包含了多次HTTP請求，如：判斷用戶是否存在？密碼是否正確？是否已登錄？登錄？等多個HTTP請求。
每秒事務通過數（Transaction Per Second）
TPS 是指每秒系統能夠處理的事務數。它是衡量系統處理能力的重要指標。當壓力加大時，TPS曲線如果變化緩慢或者有平坦的趨勢，很有可能是服務器開始出現瓶頸了。如果環境沒有發生大的變化，對於同一系統會存在一個最大處理事務能力，它並不隨着併發用戶的增減而改變。
地鐵檢票口例子：
只有十臺進站檢票的機器，一臺機器一秒能進一個人
併發用戶數爲5，則TPS爲5
併發用戶數爲10，則TPS爲10
併發用戶數爲100，則TPS仍爲10
點擊率（Hit Per Second）
每秒點擊數代表用戶每秒向Web 服務器提交的HTTP請求數。點擊率越大，服務器壓力越大。這裏的點擊並不是鼠標的一次點擊，一次點擊可能有多次HTTP請求。
吞吐量（Throughput）
單位時間內系統處理的客戶請求的數量，直接體現軟件系統的性能承載能力，一般來說用請求數/秒或是頁面數/秒來衡量，從業務的角度，也可以用訪問人數/天或是處理的業務數/小時來衡量，從網絡的角度來說，也可以用字節數/天來衡量。
思考時間（Think Time）
思考時間就是用戶進行操作時，每個請求或者操作之間的間隔時間，是爲了更加真實地模擬用戶的操作場景。
資源利用率
不同系統資源的使用情況。CPU,Memory，磁盤，網絡。
通過了解性能測試中的常見術語，我們對性能測試的理解更加深入，接下來，我們需要繼續深入理解性能測試模型。
性能測試模型
曲線拐點模型
- 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）。
- 場景六：如果地鐵正好在火車站，每名乘客都拿着大小不同的包，包太大導致卡在刷卡機堵塞，每名乘客的進站時間就會又不一樣。刷卡機有加寬的和正常寬度的兩種類型，那麼拿大包的乘客可以通過加寬的刷卡機快速進站（增加帶寬）。
- 場景七：進站的乘客越來越多，3臺刷卡機已經無法滿足需求，爲了減少人流的積壓，需要再多開幾個刷卡機，增加進站的人流與速度（提升TPS、增大連接數）。
- 場景八：終於到了上班高峯時間了，乘客數量上升太快，現有的進站措施已經無法滿足，越來越多的人開始抱怨、擁擠，情況越來越糟。單單增加刷卡機已經不行了，此時的乘客就相當於“請求”，乘客不是在地鐵進站排隊，就是在站臺排隊等車，已經造成嚴重的“堵塞”，那麼增加發車頻率（加快應用服務器、數據庫的處理速度）、增加車廂數量（增加內存、增大吞吐量）、增加線路（增加服務的線程）、限流、分流等多種措施便應需而生。
性能測試分類
性能測試主要有以下分類：
- 基準測試
- 性能測試
- 負載測試
- 壓力測試
- 併發測試
- 配置測試
- 可靠性測試
- 失效恢復測試
- 大數據量測試
基準測試
有基礎的標準，這樣能通過對比發現系統的不同點與變化。
1）可以在制定的標準下通過基準測試建立一個性能基準，這樣以後當系統的環境、參數發生變化之後，再進行一次相同標準下的測試，即可看出變化對性能的影響。
2）系統進行基準測試可以在較早的階段發現性能問題。
3）某系統從來沒有進行過任何性能測試，需要對該系統做一次性能評估作爲後續開發調優的參考。
性能測試（Performance Testing）
是通過模擬生產運行的業務壓力量和使用場景組合，測試系統的性能能否滿足生產系統要求。Performance Testing是一種常見的測試方法，就是在特定的運行條件下驗證系統的能力情況。該測試是一種正常的測試，主要是測試系統正常使用時是否滿足要求。
負載測試（Load Testing）
負載測試是在被測系統上不斷增加壓力，直到各項指標達到飽和，例如“響應時間”超過預定指標或者某種資源使用已經達到飽和狀態。這種測試方法可以找到系統的處理極限，爲系統調優提供數據。
壓力測試（StressTesting）
壓力測試是測試系統在一定飽和狀態下，例如cpu、內存等在飽和使用狀態下，系統能夠處理的會話能力，以及系統能否會出現錯誤。壓力測試與負載測試有些類似，經常把負載測試描述成壓力測試的一種場景-例如增加用戶數對系統進行壓力測試。壓力測試的目的是爲了揭露高負載下的問題，例如資源競爭、同步問題、內存泄漏等。
注意：負載測試和壓力測試兩者可以結合進行。
負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。
壓力測試是通過確定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級別的測試。
併發測試（Concurrency Testing）
併發測試是通過模擬用戶的併發訪問，測試多用戶併發訪問同一個應用，同一個模塊或者數據記錄時是否存在死鎖
或者其他性能問題。
配置測試（ConfigurationTesting）
配置測試方法是通過被測系統的軟/硬件環境的調整，瞭解各種不同環境對系統性能影響的程度，從而找到各項資
源的最優分配原則
例如在測試執行時更換、擴充硬件設備，調整網絡環境、調整應用服務器和數據庫服務器的參數設置，比較每次測
試結果，從而確定各個因素對系統性能的影響。
可靠性測試（Reliability Testing）
可靠性測試是通過給系統加載一定的業務壓力（例如資源在70%-90%的使用率）的情況下，讓應用系統持續運行一段時間，測試系統在這種條件下是否能夠穩定運行。
失效恢復測試（Failover Testing）
1.失效恢復測試方法是針對有備份和負載均衡的系統設計的，這種測試方法可以用來檢驗如果系統局部發生故障，用戶能否繼續使用系統，以及如果這種情況發生，用戶將受到多大程度的影響。
2.一般的關鍵業務系統都會採用熱備份或是負載均衡的方式來實現。這種業務系統一般要求有一臺或幾臺服務器出現問題，應用系統仍然可以正常執行業務。該方法就是在測試中模擬設備故障，驗證預期的恢復技術是否可以正常發揮作用。
3.不是所有的系統都需要進行這種類型的測試，尤其是並沒有明確給出系統需要持續運行指標的系統。
大數據量測試
大數據量測試的兩種類型：
1.獨立的數據量測試
針對某些系統存儲、傳輸、統計、查詢等業務進行大數據量測試
2.綜合數據量測試
和壓力測試、負載測試、併發測試、可靠性測試相結合的綜合測試方案