來自：http://www.cnblogs.com/fnng/archive/2012/07/01/2571990.html    作者：蟲師

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

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

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