性能測試知多少---響應時間    《轉載》

在上一節中，我們講到吞吐量，做為一個用戶你可以對吞吐量毫不關心，但響應時間卻是用戶感受系統性能的主要體現。

　　從用戶角度來說，軟件性能就是軟件對用戶操作的響應時間。說得更明確一點，對用戶來說，當用戶單擊一個按鈕，發出一條指令或在web頁面上單擊一個鏈接，從用戶單擊開始到應用系統把本次操作的結果以用戶能察覺的方式展示出來，這個過程所消耗的時間就是用戶對軟件性能的直觀印象。

　　響應時間過程分析

　　我們需要對這個過程進行分解，才能得到你真正想要的響應時間。我把整個過程分三個部分，呈現時間，數據傳輸時間和系統處理時間。

　　呈現時間

　　其實主要說的瀏覽器對接收到數據的一個處理展示的過程。幾年前大家都在用IE，如果頁面顯示比較慢，我們肯定不會怪罪IE，只會怪罪電信運營商的網速或被訪問的系統（其實，大多情況我們不會考慮是被訪問系統的問題）。現在chrome來了，我們會發現同一臺電腦同一個網站，通過chrome去訪問，頁面的呈現速度會比IE略快。這是各種評測及大眾用戶的整體感受。當然，我個人感覺，opera瀏覽器的呈現速度最快，但它的顯示效果一直不太好。

　　當然，我說這個呈現時間總不能全怪罪與瀏覽器的身上吧！當然還和承載它的操作系統有關，以及電腦硬件（比如cpu 內存）。假如你有超快的瀏覽器，如果是一臺極其垃圾的電腦，我想你多打開兩個網頁就有可能使電腦卡掉。

　　數據傳輸時間

　　千萬不要忽視數據傳輸時間。如果你要寄信給你一個遠方的朋友，你想是什么影響你將信息傳遞給遠方的朋友？不是你寫信的過程（如果你寫的信不像書一樣厚的話），也不是你朋友讀信的過程，而是送信的過程。（ps， 我10天前在china-pub訂購的一本書現在還沒到貨！XXX）

　　拿我們系統的數據傳輸過程來說，我們發送一個請求需要時間，系統處理完后返回給我們也需要時間。初學性能測試工具的同學喜歡拿工具去測試互聯網上的一些系統，甚至不懂性能的同學認為可以用性能測試工具將互聯網上的一些網站壓崩潰。貌似這一招比任何黑客攻擊厲害多去。

　　那么，我覺得這些同學應該補補網絡知識了，你的帶寬是多少？互聯網是個網，就是算是相同的起點與終點，它有可能走的不同的路線。有沒有考慮網絡延遲？就算你的并發請求都能成功的發出，但到目的地的時候，已經不能叫并發了。

　　這也是為什么我們在一般做性能測試時，一般要強調要在局域網中進行。當然，也有特殊的性能測試需要在互聯網中時行。它們重點不是求用戶的最大的并發量。

　　系統處理時間

　　系統得到請求后對請求進行處理并將結果返回。那我進行性能測試主要就是驗證系統的處理時間，因為前面的呈現時間和數據傳輸時間都我們不可控制的，用戶使用的電腦及瀏覽器千差萬別，用戶的網絡狀況千差萬別。我們唯一能控制的就是將系統的處理請求的時間縮到最短暫。

　　如果我們對系統的的處理進行分析和講解的話，它會是一個非常龐大與復雜的過程。語言、語言框架、中間件，數據庫、系統架構以及服務器系統。所以，想成為一個優秀的性能測試工程師我們的路還很長。

　　實際性的能測試

　　聽了上面的分析，貌似每個過程都挺“浪費”時間，那么我們如何只測試系統的處理時間呢？

　　其實現在的測試工具都屏蔽呈現過程，只是模擬多用戶并發請求，計算用戶得到響應的時間，頁不會將服務器的每個響應都向客戶端呈現。

　　對于數據傳輸的問題，這也是我要強調的性能測試要在局域網中進行，在局域網中一般不會受到數據帶寬的限制。所以，可以對數據的傳輸時間忽略不計。

　　響應時間的定義：

　　響應時間

　　指的是客戶發出請求到得到響應的整個過程的時間。在某些工具中，請求響應時間通常會被稱為“TTLB”（Time to laster byte） ，意思是從發起一個請求開始，到客戶端收到最后一個字節的響應所耗費的時間。

　　系統響應時間

　　應用系統從發出請求開始到客戶端接收到響應所消耗的時間。需要注明的是，這樣的定義完全是個人喜好。你可以提異議。

　　我們來看兩種情況：

　　我要訪問百度首頁，發出了一個請求，百度開始給我返回頁面數據，當搜索框與搜索按鈕都已經返回到頁面上了，但那個圖標還在發送中。我不認為這個響應是完整的。必須把頁面上的所有信息都返回給我才是完整的，我要的也是所有結果返回給我的時間。這種情況更符合“相應時間”的定義

　　某系統有一個信息查詢功能，當我輸入某條件查詢時，可能要查詢幾百萬條數據，如果數據庫，要查詢所有的數據并把所有的數據全部完整的返回給我。可能服務器要查詢很久，而我的電腦全部接收這些數據也可能只直接掛掉。那么服務器可能只查詢100條數據并把數據返回給我，當我點擊“下一頁”時，服務器再次查詢并將第二頁的數據返回給我。這種情況更符合“系統響應時間”的定義。

　　關于響應時間，要特別說明的一點是，對客戶來說，該值是否能夠被接受是帶有一定的用戶主觀色彩，也就是說，響應時間的“長”和“短”沒有絕對的區別。

　　合理的響應時間

　　在互聯網上對于用戶響應時間，有一個普遍的標準。2/5/10秒原則。

　　也就是說，在2秒之內給客戶響應被用戶認為是“非常有吸引力”的用戶體驗。在5秒之內響應客戶被認為“比較不錯”的用戶體驗，在10秒內給用戶響應被認為“糟糕”的用戶體驗。如果超過10秒還沒有得到響應，那么大多用戶會認為這次請求是失敗的。

　　這里我們還要考慮一個使用頻率的概念。

　　我最早安裝windows系統可能要1個小時，我們為什么覺得這很正常，因為我們要很久才裝一次系統，如果系統使用得當，可能一個系統用幾年不用重裝，假如，我們在系統上裝個任何小軟件都要這么長時間，那我們一定是無法忍受的。對于軟件控來說，他們會時常安裝各種新鮮有趣的軟件進行使用。

　　對于一個稅務報賬系統，該系統的用戶每月使用一次，一次花費3小時進行數據的錄入，

　　當用戶單擊“提交”按鈕后，即使系統在10分鐘后才給出“處理成功”的消息，我們也覺得是可以接受的。

　　因此，在進行性能測試時，“合理的響應時間”取決于用戶的需求，而不能依據測試人員自己設想來決定。