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

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

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

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

　　性能測試常見指標

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

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

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

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

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

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

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

　　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(鐵路網上訂票系統)，雖然有很差的用戶體驗，但每天還是大把的人拼命的登錄(過年回家的人傷不起)，甚至用外掛登錄。見有網友云云點擊(請求)了幾十幾百次才訂票(響應)成功。所以，成功響應率也是很重要的一個指標?？蛻舳税l送一千個請求的成功得到響應的幾率。

原文轉自：http://www.uml.org.cn/Test/201309092.asp