性能測試知多少---響應時間

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

　　從使用者角度來說，軟體性能就是軟體對使用者操作的響應時間。說得更明确一點，對使用者來說，當使用者單擊一個按鈕，發出一條指令或在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分鐘後才給出“處理成功”的消息，我們也覺得是可以接受的。

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