在做性能测试之前需要知道什么
以下是我自己錄制的關于這篇文章的一小段視頻，有興趣的可以下載看看
https://yunpan.cn/cPQc4mm2DjbMu ?訪問密碼 a76f
?
//此篇摘抄于蟲師博客，個人覺得通俗易懂
關于理解性能，記得我那時是看了“《LoadRunner沒有告訴你的》之三---理發店模式”不管你有沒有看過，我這重提一下理發店模式。
前提：
1.?一個理發店有三位理發師傅
2.?每位理發師傅理一個發需要一小時
3.?顧客都很忙，從進理發店起最多只等三小時（等待時間+理發時間），如果三小時后還沒輪到自己理發，立馬走人。
???思考：
???這里我們來理解“最佳用戶數”和“最大用戶數”。
最佳用戶數：
????理發店的最佳狀態，理發店收入最多（理發師傅沒有休息時間，一直在理發），顧客滿意度最高（顧客隨時到隨時理，無需要等待）。在一個時間點來說，三個理發師傅服務于三位顧客，那么這個最佳用戶數是三。
最大用戶數：
理發店的最大承受狀態，理發店收入最多（理發師傅沒有休息時間，一直在理發），顧客的最大忍耐度（來的顧客等待+理發需要等上三個小時）。
假如理發店生意非常好，早上一開門一下子來了一群顧客（很多），A、B、C三位顧客先理，D、E、F顧客需要等待一小時才能得到理發師傅的服務，G、H、I三位顧客等待了兩小時才得到服務，后面排隊的J、K、L.....等顧客，已經等了三小時還沒得到服務，因為這已經得達到了他們等待的極限，所以后他們氣憤和無奈離開。
當然，理發店還會不斷的來新的顧客，不斷有等了三小時而沒有得到服務的顧客離開，但對于理發店而言，他們在一個時間點上，能服務的最大用戶數是九（三位正在接受服務、三位已經等待一小時，三們已經等待兩小時）。
對于最大用戶數，需要注意的兩點：
1.?在理發店里很大，可以容納很多位顧客（大于9），總有一部分在這里等待了三小時而沒有得到服務離開，不要把等待了三小而沒有得到服務的顧客納入最大用戶數里。
2.?假如理發店很小，最多只能容納六位顧客，當第七個顧客來時，雖然，我們知道他只需要等待兩小時就可得到服務（這個時間是他可以接受的等待時間），但由于理發店容量有量，這第七個顧客只有改天再來了。
關于理發店原理，詳細請瀏覽http://www.cnblogs.com/jackei/archive/2006/11/20/565527.html?
?
?????不知道通過上面對理發店的分析，你對性能有了一些眉目。假如理發店相當于我們的系統的話，顧客就我們向服務器所發送的請求，最佳用戶數和最大用戶數是我們衡量一個系統的處理能力的一種方法。
?
?
這個是我在給一朋友說瀏覽器與服務器之間交流時用到的例子，感覺比容易理解，所以拿來分享一下。
???假設：
??1.??A、B、C三個人。
??2.??C欠A錢（這里不考慮多少）
??3.??B是專門要賬
???思考：
瀏覽器與服務器的信息傳遞次數：
???A對B說，C欠我錢，你幫我去要。B接到指令后就去找C要錢。
???B對C說，給我20塊錢。
???C說，沒有。
???B對C說，給我10塊錢。
???C說，沒有。
???B對C說，給我5塊錢。
???.........
???最后，B回來對A說，哎呀媽呀，C那丫的忒摳門了，一分錢沒有。
???對于A來講，只是來說，它只是讓B問C要錢，具體的B與C之間交互了幾次，A是不知道的，它所知道的就是B返回給它的結果，C一分錢沒有。
???
???瀏覽器與服務器傳遞數據的大小：
???還是上面的過程，A對B說，C欠我錢，你幫我去要。B接到指令后就去找C要錢。
???B對C說，給我20萬塊錢。
???C說，沒問題，沒支票，只有1元硬幣。
???..........
???B終于把錢拿回來給A。A很納悶，怎么去了那么久，B委屈的說，丫的，C給我整了一堆硬幣，太重了，路上走的慢，都快累死我了。
???對于A來講，只是來說，它只是讓B問C要錢，誰知道C給的是支票還是硬幣。所以，B去要錢消耗的時間就很長。
?
???所以，要想提高瀏覽器對服務器的訪問速度，應該減少數據傳遞次數與數據傳遞的大小。
這樣就很自然的引出了瀏覽器的cookie?
???A在C哪里存了5毛錢。
???A對B說，我在C哪里存了5毛錢，你去拿來我看看。B跑去問C要了5毛錢回來給A看。
??過了一會，A又對B說，我在C哪里存了5毛錢，你去拿來我看看。B跑去問C要了5毛錢回來給A看。
??過了一會，A又對B說，我在C哪里存了5毛錢，你去拿來我看看。這次C煩了，對B說，你把錢放自己口袋里吧，等A要的時候，你來問我5毛的人民幣有沒有改版，沒有改版的話，你就直接把口袋里的5毛錢給A看就行了。
???
?
??在這里A就相當于我們用戶，B相當于瀏覽器，C是服務器。而cookie就是B的口袋，當然了cookie的用處還很多。比如我們登陸一個系統，提示我們是否保存密碼（有的還有期限比如，一個星期或一個月），如果我們保存了，下次再訪問登陸時，瀏覽器就已經幫我們填寫好了賬戶密碼或直接幫我們登陸。那這個賬戶密碼就放在我們瀏覽器的cookie中。
?
???為什么要說上面的例子呢？因為我們大部分的一部分性能測試是基于B/S架構系統的，理解了瀏覽器與服務器之間的數據傳遞，有助于我們理解性能測試。
?
----//在開始性能測試之前，我們需要知道什么?當客戶或老板把你叫來，對你說，去給我們系統做個性能測試，千萬別傻傻的說“好！”然后，就走了，我以前這么干過（那時不懂，打腫了臉充胖子），回到座位后，不知從何下手了。
???那么，我們需要知道什么呢？
?
?1.?性能測試的目的
??首先要知道客戶的要求。
??我把性能測試按目的分以下幾種
?
? ?1）客戶有明確要求
???這是一個好的結果，這說明客戶對性能測試有一定的了解，知道他們需要的系統要達到一個什么樣的標準。如：系統要求同時滿足100用戶登陸，平均每個用戶登陸時間不能超過5秒。這個需求很明確，當然也不排除一些不懂裝懂的用戶，提一些不現實的要求。
???不管怎么說，用戶提要求了，這個比較容易，你可以對現系統做一次性能測試，至于，是通過優化系統還是增加硬件設備才能達到要求。就不是我們考慮的問題了。
? ?2）只是想知道目前系統性能（容量測試）
???可以把我們的目的就是求得最大用戶數和最佳用戶數。但是，這仍然是比較含糊的一個需求，我們需要對系統做出分析，找出系統的壓力點。
? ?3）找出系統性能瓶頸
???這個同樣需要分析可能對系統造成瓶頸的邏輯業務，然后才能進行性能測試。
?? 4）了系統在長時間的壓力下性能狀況（強度測試）
???這個一般驗證系統的穩定性，因為系統一旦上線，就有可能會長期處在大用戶的訪問狀態，可能以前沒發現的一些問題就會暴漏出來。比較典型的就是內存溢出。
?
?2.?性能測試的環境
?
? 確定了我們的測試目的，當然需要測試環境。這里的環境，我們需要考慮一下幾點
?
? 1）硬件環境
我們需要了解被測服務器硬件配置，用于加壓客戶端的機子配置，CPU?內存??等
?
? 2）軟件環境
???我們需要了解被測系統的架構，前端、中間件、服務器（這里指運行系統軟件服務器，如tomcat）、數據庫，以及他們的部署位置。
???用于加壓的客戶端采用什么性能測試工具進行加壓。
?
? 3）網絡環境
???網絡環境很重要。在上面的幾個目的中，除了找出系統性能瓶頸可以在廣域網進行，因為這個目的可以不用設置太多的虛擬用戶，只要找出系統哪個地方影響了整個系統的性能就行。?
???其他目的的測試都需要在，局域網進行，不然你壓力工具所發送的請求都會卡死在網絡的傳輸過程中。
?
??3.?尋找系統的壓力點
?
??我們需要對系統的哪個頁面或業務進行加壓。這個不是自己想出來的，需要與開發人員的溝通。系統的首頁？系統的登錄？還是系統的交易過程？各個業務的用戶比例是多少？
??只有獲得有效的性能需求，才容易尋找和定位壓力點。
? 獲得有效的需求：http://www.cnblogs.com/jackei/archive/2006/12/12/589473.html
?
----//在開始性能測試之前，我們需要知道的性能測試常見指標性能測試常見指標
?
性能測試說白了就是通過工具模擬多個用戶對被測系統進行訪問。然后查看系統對于多個用戶發來請求的處理能力。
? ? ?左邊的兩個小人表示兩個用戶，向右邊服務器發送請求，然后得到服務器的響應信息。
? ? 首先，我們要保證向服務器發送的請求的正確性，當然用戶向服務器發送錯誤的請求，服務器也會個客戶端響應信息，但響應的是報錯信息；所以，為了保證測試數據的有效性，我們的要保證發送請求的正確性。
? ? ?為什么一般的性能測試要在局域進行？
? ? ?一般我們的性能測試都是在局域網中進行的。為什么一定要在局域網中進行呢？因為局域網中不受網絡限制。這個說法不能絕對。但是一般測試工具的用戶并發量是不會受到局域網帶寬的限制，除非你做的是十萬，百萬級別的用戶并發。相信懂一點網絡知識的人都知道，當你上網很慢的時候，比如打開某某網站很慢，你肯定會罵電信的網絡不給力，而不會罵這個網站響應速度不給力。因為，請求信息的耗時大部耗在傳輸過程中。
? ? ?所以，剛做測試時，我們群里熱議論，如果我們每個人都開一個壓力工具對百度網站進行加壓。百度，服務器會不會掛掉。有測友說這樣是不道德人。呵呵！其實，完全不必有這個擔心。就一般人家用的帶寬，我確保，你向百度服務器發送的請求大部分都死在半路上，就算不死到了百度服務器已經不能叫并發了。何況百度服務器的集群技術以及其他各種分壓技術。所以，做性能測試不了解被測系統的架構，以及各種技術的性能。很難做出有效的測試報告。
下面我們看看性能測試的一些技術指標。??
Work Load = Virtual Users
工作負荷 = 虛擬用戶數
? ? ?對服務器產生多大壓力，可以由多少用戶同時對服務器發送請求來衡量。也就是服務器的性能可以看它同時處理多少用戶發送來的請求來衡量。 虛擬用戶數可以用進程或線程的方式進行模擬。 ? response time??響應時間 ? ? ? ?從客戶端將數據包發出，到接收到服務器端發來的請求。這個過程的總體時間叫response time? ? ? ? ?這個時間用來衡量的處理請求的速度（拋出網速限制的前提下） throughput ~Ti & To ? ? ? ?這個表示，吞吐量，吞吐量越大表示系統性能越強。1個用戶跑100天和10個用戶跑1分鐘。當然是1個用戶跑100天的吞吐量大。所以，我們要想看系統的性能應該用“吞吐率”，就是單位時間的吞吐量，比如吞吐量/秒。 ? ? ? 站在服務器端，T-in表示“吞”；T-out表求“吐” 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、這種方法的主要目的是驗證系統是否有系統宣稱具有的能力。
2、這種方法要事先了解被測試系統經典場景，并具有確定的性能目標。
3、這種方法要求在已經確定的環境下運行。
也就是說，這種方法是對系統性能已經有了解的前提，并對需求有明確的目標，并在已經確定的環境下進行的。
負載測試
通過在被測系統上不斷加壓，直到性能指標達到極限，例如“響應時間”超過預定指標或都某種資源已經達到飽和狀態。
特點：
1、這種性能測試方法的主要目的是找到系統處理能力的極限。
2、這種性能測試方法需要在給定的測試環境下進行，通常也需要考慮被測試系統的業務壓力量和典型場景、使得測試結果具有業務上的意義。
3、這種性能測試方法一般用來了解系統的性能容量，或是配合性能調優來使用。
也就是說，這種方法是對一個系統持續不段的加壓，看你在什么時候已經超出“我的要求”或系統崩潰。
壓力測試（強度測試）
壓力測試方法測試系統在一定飽和狀態下，例如cpu、內存在飽和使用情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤
?
特點：
1、這種性能測試方法的主要目的是檢查系統處于壓力性能下時，應用的表現。
2、這種性能測試一般通過模擬負載等方法，使得系統的資源使用達到較高的水平。
3、這種性能測試方法一般用于測試系統的穩定性。
也就是說，這種測試是讓系統處在很大強度的壓力之下，看系統是否穩定，哪里會出問題。
?
并發測試
并發測試方法通過模擬用戶并發訪問，測試多用戶并發訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或其者他性能問題。
特點：
1、這種性能測試方法的主要目的是發現系統中可能隱藏的并發訪問時的問題。
2、這種性能測試方法主要關注系統可能存在的并發問題，例如系統中的內存泄漏、線程鎖和資源爭用方面的問題。
3、這種性能測試方法可以在開發的各個階段使用需要相關的測試工具的配合和支持。
也就是說，這種測試關注點是多個用戶同時（并發）對一個模塊或操作進行加壓。
配置測試
配置測試方法通過對被測系統的軟\硬件環境的調整，了解各種不同對系統的性能影響的程度，從而找到系統各項資源的最優分配原則。
特點：
1、這種性能測試方法的主要目的是了解各種不同因素對系統性能影響的程度，從而判斷出最值得進行的調優操作。
2、這種性能測試方法一般在對系統性能狀況有初步了解后進行。
3、這種性能測試方法一般用于性能調優和規劃能力。
也就是說，這種測試關注點是“微調”，通過對軟硬件的不段調整，找出這他們的最佳狀態，使系統達到一個最強的狀態。
可靠性測試
在給系統加載一定業務壓力的情況下，使系統運行一段時間，以此檢測系統是否穩定。
特點：
1、這種性能測試方法的主要目的是驗證是否支持長期穩定的運行。
2、這種性能測試方法需要在壓力下持續一段時間的運行。（2~3天）
3、測試過程中需要關注系統的運行狀況。
也就是說，這種測試的關注點是“穩定”，不需要給系統太大的壓力，只要系統能夠長期處于一個穩定的狀態。
上面的分類絕非全面，還有失效性測試，就是系統局部發生問題時，其它模塊是否可以正常的運行。這個在極少數情況下進行，這里就不介紹了。
?
?
性能測試分類之我見 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
上面的類分完了，似乎得到不少專家的認同，并無不妥。但我們在性能測試過程中真的能把它們區別分的很清楚么?你能嚴格區分出你這次的測試到底并發測試還是壓力測試。
筆者第一點不太贊同的是對“性能測試”的定義。筆者認為性能測式測試包含了上面的所有分類。而這種性能測試的定義只是一種狹義上的“性能測試”，屬于性能測試的一種。
性能測試是相對功能測試來說的。他們之間最本質的區別就是對系統有處理能力是否夠成壓力。如果一個用戶的一個操作（比如超大數據量的查詢）對系統夠成了壓力，我也可以視其為性能測試。
?
?
其實，可以這樣來劃分性能測試
上面定交了那么多分類，是不是有點暈了。其實，以筆者認為我們進行性能測試時關注的就兩點。耐力和爆發力。
初高中時練過幾年體育，最好時代表學校參加縣體育比賽，不過是去墊底的。哈哈！哈一個體育運動員來說，那么多的體育項目，其實，考核他的就兩方面。一是爆發力。二是耐力。
爆發力：拿一個舉重選手來說，他的重點在重量上，因為你只要能舉起三秒就算你成功了。關鍵是看你能舉起一個什么樣的重量。
耐力：拿一個馬拉松運動員來說，你百米速度跑得再快沒用。關鍵是這40公里路程中，最先跑到終點的人才是贏家。
整體協調性：當然，身為一個教練員，我在選拔選手的時候，除了看這個運動員的耐力和爆發力，身體的整體協調性也是我考核的一個很重要的指標。比如一個運行員身體各位部位練得非常強壯，但右臂先天性萎縮。他的跑步成績雖然不錯。但他在跑的過程中，身體有各個部分都在分擔右臂的不足。右臂影響了整個體能的發揮。
再到系統的性能上說，爆發力就是這個系統能承受的最大壓力，沒準這個系統承受的壓力很大。但過半個小時之間就掛掉了。耐力就是這個每系統長時間處于壓力下的穩定性，這系統超級穩定，跑個幾十年都不用重啟服務器。那么整體協調性就是看系統有沒系統瓶頸，需不需要進行系統調優。
在做性能測試時請忘掉分類
這里只是告訴在做性能測試時不要想這個測試是屬于性能測試的哪一類呢？是并發性測呢？還是壓力測試？
我們還拿上面的教練員選拔選手做例子。
記得我進校體隊的時候，教練說讓我跑兩圈。然后，我就開始圍繞著操場跑起來。你說教練讓我跑兩圈是想看我的什么能力？
1、雙腿的考核，一個是步幅，就是步與步之間的距離。一個是頻率，兩腿交替的頻率。如果你一步拉得很大的話，那么頻率一定會下降。如果想提高頻率的話，那么一定會影響到步幅的大小。
2、雙臂的考核，肩膀是否放松，擺臂是否有力，雙臂的擺動與雙腿的擺動是否協調。
3、呼吸是否勻稱，目前的速度可以跑幾圈。
我只做了一項體育運行，就考核了我這么多內容。我們在做一個性能測試時也不局限在某一分類上，也可能我們的一個測試包含多個分類。
《web性能測試實戰》：
么多類型的性能測試看起來很嚇人，實際上它他們大多是密切相關的。例如，運行8個小時來測試系統是否可靠，而這個測試極有可能包含了可靠性能測、強度測試、并發測試、負載測試，等等。因此，在實施性能測試時決不能割裂它們的內部聯系去進行，而應該分析它們之間的關系，以一種高效率的方式來設計性能測試。
轉載于:https://www.cnblogs.com/xiaoqingSister/p/5425779.html
總結
以上是生活随笔為你收集整理的在做性能测试之前需要知道什么的全部內容，希望文章能夠幫你解決所遇到的問題。
