之前寫過一篇《在做效能測試之前應該知道什麼》有博文，自我感覺講的不好，舉了兩個例子，和做效能測試之前需要知道的一些要點。離我的題目有差距。二則覺得講的不全。其實，要做效能測試需要知道的東西太多了。豈是一篇博文都能說全的。在這裡表示一下愧疚之情。
好多測試新手，在做完效能測試之後，不知如何對測試資料進行分析。在這裡我想談談一些效能測試引數的相關知識。當然，也不是一篇博文就能說清道明的。只希望在你的測試道路上能給你一絲幫助。
不怕囉嗦的再次忠告，那想成為測試高手的新人，多學學基礎知識。別把過多的時間放在研究新工具的使用上。工具何其多，原理差不多。不要本末倒置了。也算是自我提醒吧！
效能測試說白了就是通過工具模擬多個使用者對被測系統進行訪問。然後檢視系統對於多個使用者發來請求的處理能力。
左邊的兩個小人表示兩個使用者，向右邊伺服器傳送請求，然後得到伺服器的響應資訊。
首先，我們要保證向伺服器傳送的請求的正確性，當然使用者向伺服器傳送錯誤的請求，伺服器也會個客戶端響應資訊，但響應的是報錯資訊；所以，為了保證測試資料的有效性，我們的要保證傳送請求的正確性。
為什麼一般的效能測試要在局域進行？
一般我們的效能測試都是在區域網中進行的。為什麼一定要在區域網中進行呢？因為區域網中不受網路限制。這個說法不能絕對。但是一般測試工具的使用者併發量是不會受到區域網頻寬的限制，除非你做的是十萬，百萬級別的使用者併發。相信懂一點網路知識的人都知道，當你上網很慢的時候，比如開啟某某**很慢，你肯定會罵電信的網路不給力，而不會罵這個**響應速度不給力。因為，請求資訊的耗時大部耗在傳輸過程中。
下面我們看看效能測試的一些技術指標。
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個使用者的方式來做，不過這樣勢必加大工作量，也沒必要。這個需要每做完一輪測試後對資料進行分析，然後確定下輪測試所要設定的虛擬使用者數。
關於，效能指標的分析，就先談到這裡。關於內容，我反覆經過思考，但難免有理解有誤之處。還望高手點撥。共同進步。
在開始效能測試之前，我們需要知道什麼
當客戶或老闆把你叫來，對你說，去給我們系統做個效能測試，千萬別傻傻的說 好！然後，就走了，我以前這麼幹過 那時不懂，打腫了臉充胖子 回到座位後，不知從何下手了。那麼，我們需要知道什麼呢？1.效能測試的目的 首先要知道客戶的要求。我把效能測試按目的分以下幾種 1 客戶有明確要求 這是乙個好的結果，這說...
rem布局需要知道些什麼
查詢 media query 是css3新語法 media mediatype and not only media feature 值 解釋說明 all用於所有裝置 print 用於印表機和列印預覽 screen 用於電腦螢幕，平板電腦，智慧型手機等 關鍵字將 型別或多個 特性連線到一起作為 查詢...
大資料需要知道，Hadoop是什麼！
隨著近幾年計算機技術和網際網路的發展，大資料 這個名詞越來越多進入我們的視野。大資料的快速發展也在無時無刻影響著我們的生活。那大資料究竟是什麼呢？首先，看看專家是怎麼解釋大資料的 大資料就是多，就是多。原來的裝置存不下 算不動。啪菠蘿 畢卡索 大資料，不是隨機樣本，而是所有資料 不是精確性，而是混雜...