在做性能測試之后需要知道些什么

第第頁在做性能測試之后需要知道些什么在做性能測試之后需要知道些什么

發(fā)表于：2023-07-16來源：博客園：蟲師點擊數(shù)：標簽：性能測試

之前寫過一篇《在做性能測試之前應該知道什么》有博文，自我感覺講的不好，舉了兩個例子，和做性能測試之前需要知道的一些要點。離我的題目有差距。二則覺得講的不全。其實，要做性能測試需要知道的東西太多了。豈是一篇博文都能說全的。在這里表示一下愧疚之

之前寫過一篇《在做性能測試之前應該知道什么》有博文，自我感覺講的不好，舉了兩個例子，和做（性能）（測試）之前需要知道的一些要點。離我的題目有差距。二則覺得講的不全。其實，要做（性能）（測試）需要知道的東西太多了。豈是一篇博文都能說全的。在這里表示一下愧疚之情。

好多測試新手，在做完（性能測試）之后，不知如何對測試數(shù)據(jù)進行分析。在這里我想談談一些（性能測試）參數(shù)的相關(guān)知識。當然，也不是一篇博文就能說清道明的。只希望在你的測試道路上能給你一絲幫助。

不怕啰嗦的再次忠告，那想成為測試高手的新人，多學學基礎(chǔ)知識。別把過多的時間放在研究新工具的使用上。工具何其多，原理差不多。不要本末倒置了。也算是自我提醒吧!

性能測試常見指標

性能測試說白了就是通過工具模擬多個用戶對被測系統(tǒng)進行訪問。然后查看系統(tǒng)對于多個用戶發(fā)來請求的處理能力。

左邊的兩個小人表示兩個用戶，向右邊服務器發(fā)送請求，然后得到（服務器）的響應信息。

首先，我們要保證向服務器發(fā)送的請求的正確性，當然用戶向服務器發(fā)送錯誤的請求，服務器也會個客戶端響應信息，但響應的是報錯信息;所以，為了保證測試數(shù)據(jù)的有效性，我們的要保證發(fā)送請求的正確性。

為什么一般的性能測試要在局域進行?

一般我們的性能測試都是在局域網(wǎng)中進行的。為什么一定要在局域網(wǎng)中進行呢?因為局域網(wǎng)中不受網(wǎng)絡限制。這個說法不能絕對。但是一般測試工具的用戶并發(fā)量是不會受到局域網(wǎng)帶寬的限制，除非你做的是十萬，百萬級別的用戶并發(fā)。相信懂一點網(wǎng)絡知識的人都知道，當你上網(wǎng)很慢的時候，比如打開某某網(wǎng)站很慢，你肯定會罵電信的網(wǎng)絡不給力，而不會罵這個網(wǎng)站響應速度不給力。因為，請求信息的耗時大部耗在傳輸過程中。

所以，剛做測試時，我們?nèi)豪餆嶙h論，如果我們每個人都開一個壓力工具對百度網(wǎng)站進行加壓。百度，服務器會不會掛掉。有測友說這樣是不道德人。呵呵!其實，完全不必有這個擔心。就一般人家用的帶寬，我確保，你向百度服務器發(fā)送的請求大部分都死在半路上，就算不死到了百度服務器已經(jīng)不能叫并發(fā)了。何況百度服務器的集群技術(shù)以及其他各種分壓技術(shù)。所以，做性能測試不了解被測系統(tǒng)的架構(gòu)，以及各種技術(shù)的性能。很難做出有效的測試報告。

下面我們看看性能測試的一些技術(shù)指標。

WorkLoad=VirtualUsers

工作負荷=虛擬用戶數(shù)

對服務器產(chǎn)生多大壓力，可以由多少用戶同時對服務器發(fā)送請求來衡量。也就是服務器的性能可以看它同時處理多少用戶發(fā)送來的請求來衡量。

虛擬用戶數(shù)可以用進程或線程的方式進行模擬。

responsetime響應時間

從客戶端將數(shù)據(jù)包發(fā)出，到接收到服務器端發(fā)來的請求。這個過程的總體時間叫responsetime

這個時間用來衡量的處理請求的速度(拋出網(wǎng)速限制的前提下)

throughput~TiTo

這個表示，吞吐量，吞吐量越大表示系統(tǒng)性能越強。1個用戶跑100天和10個用戶跑1分鐘。當然是1個用戶跑100天的吞吐量大。所以，我們要想看系統(tǒng)的性能應該用"吞吐率'，就是單位時間的吞吐量，比如吞吐量/秒。

站在服務器端，T-in表示"吞';T-out表求"吐'

Ti：T-in主要衡量客戶端的能力，看客戶端往服務器發(fā)送的請求數(shù)據(jù)包的吞吐率。

To：T-out主要衡量的服務器端的能力，看服務器處理返回請求數(shù)據(jù)包的吞吐率。

Hits/Request

網(wǎng)頁點擊數(shù)/請求

Response/SuccessfulResponse

響應/成功的響應

Request與Response是對應，一個請求對應一個響應。但當客戶端對服務器的壓力達到一直程度后，不是每一請求都能得到響應的。去年末火了個最牛B的"電子商務'網(wǎng)站。12306(鐵路網(wǎng)上訂票系統(tǒng))，雖然有很差的用戶體驗，但每天還是大把的人拼命的登錄(過年回家的人傷不起)，甚至用外掛登錄。見有網(wǎng)友云云點擊(請求)了幾十幾百次才訂票(響應)成功。所以，成功響應率也是很重要的一個指標?？蛻舳税l(fā)送一千個請求的成功得到響應的幾率。

HitsPerSecond

每秒中點擊次數(shù)

和吞吐量一樣，單單用點擊數(shù)(hits)來衡量系統(tǒng)也是不合理的。所以，用每秒鐘的點擊數(shù)才能衡量出服務器的處理能力。

響應時間圖分析

橫坐標表示用戶數(shù)

縱坐標表示時間

紅色虛線，表求的是一種系統(tǒng)的理想狀態(tài)。

當服務器處理10個用戶請求時所用的時間是2秒(假設)，當服務器處理200用戶請求時所用的時間也是2秒。所以說這種狀態(tài)是一種理想的狀態(tài)?，F(xiàn)實中，不管是如何超級強的服務器當用戶數(shù)達到一定數(shù)量時，響應時間必會變慢。

藍色斜線，是服務器常見的一種曲線狀態(tài)。

服務器的響應時間雖然用戶數(shù)量的增加逐漸變慢。

當系統(tǒng)出現(xiàn)這種斜線，應該說系統(tǒng)性能是相當健壯的。隨著用戶的增長響應時間逐漸變長。

黑色曲線，個人覺得是服務器處理能力的真實曲線狀態(tài)。

為什么說黑線才是真實服務器處理能力的曲線呢?當用戶處理一個用戶請求是2秒(假設)，當處兩個用戶請求是馬上變成3秒(假設)，當處理3個用戶請求時變成4秒(假設)。再差的服務器也有個處理范圍，比如是，100用戶同時并發(fā)，服務器可以輕松應對，不管是10個用戶還是80個用戶同時請求，服務器都可以即可響應(請參考理發(fā)店模式)。只有當用戶數(shù)量達到某個數(shù)量點后，服務器性能急劇下降。如上圖黑色十字星處就是系統(tǒng)的拐角點。

我們假設有一個門，在一個時間點上可同時