在做性能測試之后需要知道些什么
之前寫過一篇《在做性能測試之前應該知道什么》有博文，自我感覺講的不好，舉了兩個例子，和做性能測試之前需要知道的一些要點。離我的題目有差距。二則覺得講的不全。其實，要做性能測試需要知道的東西太多了。豈是一篇博文都能說全的。在這里表示一下愧疚之情。
好多測試新手，在做完性能測試之后，不知如何對測試數據進行分析。在這里我想談談一些性能測試參數的相關知識。當然，也不是一篇博文就能說清道明的。只希望在你的測試道路上能給你一絲幫助。
不怕啰嗦的再次忠告，那想成為測試高手的新人，多學學基礎知識。別把過多的時間放在研究新工具的使用上。工具何其多，原理差不多。不要本末倒置了。也算是自我提醒吧！
性能測試常見指標
性能測試說白了就是通過工具模擬多個用戶對被測系統進行訪問。然后查看系統對于多個用戶發來請求的處理能力。
左邊的兩個小人表示兩個用戶，向右邊服務器發送請求，然后得到服務器的響應信息。
首先，我們要保證向服務器發送的請求的正確性，當然用戶向服務器發送錯誤的請求，服務器也會個客戶端響應信息，但響應的是報錯信息；所以，為了保證測試數據的有效性，我們的要保證發送請求的正確性。
為什么一般的性能測試要在局域進行？
一般我們的性能測試都是在局域網中進行的。為什么一定要在局域網中進行呢？因為局域網中不受網絡限制。這個說法不能絕對。但是一般測試工具的用戶并發量是不會受到局域網帶寬的限制，除非你做的是十萬，百萬級別的用戶并發。相信懂一點網絡知識的人都知道，當你上網很慢的時候，比如打開某某網站很慢，你肯定會罵電信的網絡不給力，而不會罵這個網站響應速度不給力。因為，請求信息的耗時大部耗在傳輸過程中。
所以，剛做測試時，我們群里熱議論，如果我們每個人都開一個壓力工具對百度網站進行加壓。百度，服務器會不會掛掉。有測友說這樣是不道德人。呵呵！其實，完全不必有這個擔心。就一般人家用的帶寬，我確保，你向百度服務器發送的請求大部分都死在半路上，就算不死到了百度服務器已經不能叫并發了。何況百度服務器的集群技術以及其他各種分壓技術。所以，做性能測試不了解被測系統的架構，以及各種技術的性能。很難做出有效的測試報告。
下面我們看看性能測試的一些技術指標。
Work Load = Virtual Users
工作負荷 = 虛擬用戶數
對服務器產生多大壓力，可以由多少用戶同時對服務器發送請求來衡量。也就是服務器的性能可以看它同時處理多少用戶發送來的請求來衡量。
虛擬用戶數可以用進程或線程的方式進行模擬。
response time 響應時間
從客戶端將數據包發出，到接收到服務器端發來的請求。這個過程的總體時間叫response time
這個時間用來衡量的處理請求的速度（拋出網速限制的前提下）
throughput ~Ti & To
這個表示，吞吐量，吞吐量越大表示系統性能越強。1個用戶跑100天和10個用戶跑1分鐘。當然是1個用戶跑100天的吞吐量大。所以，我們要想看系統的性能應該用“吞吐率”，就是單位時間的吞吐量，比如吞吐量/秒。
站在服務器端，T-in表示“吞”；T-out表求“吐”
Ti：T-in 主要衡量客戶端的能力，看客戶端往服務器發送的請求數據包的吞吐率。
To： T-out 主要衡量的服務器端的能力，看服務器處理返回請求數據包的吞吐率。
Hits/Request
網頁點擊數/請求
Response/Successful Response
響應/成功的響應
Request與Response是對應，一個請求對應一個響應。但當客戶端對服務器的壓力達到一直程度后，不是每一請求都能得到響應的。去年末火了個最牛B的“電子商務”網站。12306（鐵路網上訂票系統），雖然有很差的用戶體驗，但每天還是大把的人拼命的登錄（過年回家的人傷不起），甚至用外掛登錄。見有網友云云點擊（請求）了幾十幾百次才訂票（響應）成功。所以，成功響應率也是很重要的一個指標。客戶端發送一千個請求的成功得到響應的幾率。
Hits Per Second
每秒中點擊次數
和吞吐量一樣，單單用點擊數（hits）來衡量系統也是不合理的。所以，用每秒鐘的點擊數才能衡量出服務器的處理能力。
響應時間圖分析
橫坐標表示用戶數
縱坐標表示時間
紅色虛線，表求的是一種系統的理想狀態。
當服務器處理10個用戶請求時所用的時間是2秒（假設），當服務器處理200用戶請求時所用的時間也是2秒。所以說這種狀態是一種理想的狀態。現實中，不管是如何超級強的服務器當用戶數達到一定數量時，響應時間必會變慢。
藍色斜線，是服務器常見的一種曲線狀態。
服務器的響應時間雖然用戶數量的增加逐漸變慢。
當系統出現這種斜線，應該說系統性能是相當健壯的。隨著用戶的增長響應時間逐漸變長。
黑色曲線，個人覺得是服務器處理能力的真實曲線狀態。
為什么說黑線才是真實服務器處理能力的曲線呢？當用戶處理一個用戶請求是2秒（假設），當處兩個用戶請求是馬上變成3秒（假設），當處理3個用戶請求時變成4秒（假設）。再差的服務器也有個處理范圍，比如是，100用戶同時并發，服務器可以輕松應對，不管是10個用戶還是80個用戶同時請求，服務器都可以即可響應（請參考理發店模式）。只有當用戶數量達到某個數量點后，服務器性能急劇下降。如上圖黑色十字星處就是系統的拐角點。
我們假設有一個門，在一個時間點上可同時過10個人，不管你是同時來3個還是10個都可以在同一時間點過門，假如來了11個人，必然有一個人要等10個人過門之后才能過。那么當超過10人來過門時，過門的速度就開始變慢。那么10就是服務器性能的拐角點。我們通常做壓力測試找服務器的拐角點是很重要的任務之一。
關藍色曲線與黑色區線只是我們常見兩種曲線。現實的測試中可能出現各種樣式的曲線。當然還要看你做測試的細度，比如，10個用戶是系統的拐點，如果你做完5個用戶的一輪測試后，就是20用戶的測試。那么畫出來的曲線就變成斜線，拐點將被護忽略掉。
吞吐率圖分析
橫坐標虛擬用戶數
縱坐標有吞吐率（服務器端）
紅色虛線，表示一種理想的狀態。
隨著用戶數量的增加吞吐率也在持續增加。
黑色曲線，表示現實系統的吞吐率狀態。
剛開始吞吐率隨著用戶數量的增加逐漸變大，當大到一定程度時，逐漸平緩直到變成一條平線。
如果用戶還在持續增加中，那么吞吐率有可能下降，直到系統掛掉。
為什么會是這樣呢？我們通過另一個例子來說，大家都在城市生活，相信上下班高峰期都會遇到堵車。在比較重要的紅綠燈路口常會見到堵車現象。假如每個綠燈可以通過10輛，前期來三五輛車，遇到綠燈，一次都過去了。到了下班高峰期，車子變多，一下來了20輛，但這個路口的綠燈每天只能通過10輛，所以，這個時候，路口的通過率不會根據車輛的增加而繼續增加。
好的系統好像好有個好的交警在位置秩序，雖然車輛還在增加，但每個車輛都有條不紊等待通過路口。
不好的系統如路口趕上交警拉肚子，車輛在增加，后面車輛等得不耐煩就往前擠，結果稿得互不相讓。好嘛！之后還每個綠燈可通過10輛，現在只能有一輛車從夾縫中脫離苦海了。
響應時間圖與吞吐率圖并不是我們一輪性能測試下來就能得到結果。需要經過多輪測試才能得到。設置不同的用戶數量，得到每次的測試數據，將每次數據連接，從而得到最終系統性能曲線。關于用戶數量每次增加的數量自己把握。如果，想精確，可以每次增加1個用戶的方式來做，不過這樣勢必加大工作量，也沒必要。這個需要每做完一輪測試后對數據進行分析，然后確定下輪測試所要設置的虛擬用戶數。
關于，性能指標的分析，就先談到這里。關于內容，我反復經過思考，但難免有理解有誤之處。還望高手點撥。共同進步。