早期的效能測試更關注後端服務的處理能力。

一個使用者去訪問一個頁面的請求過程，如上圖。

• 資料傳輸時間

當你從瀏覽器輸入網址，敲下回車，開始...

真實的使用者場景請不要忽視資料傳輸時間，想想你給遠方的朋友寫信，信件需要經過不同的交通運輸工具送到朋友手上；當你的朋友寫好了信，再次通過不同的交通工具送到你的手上。

效能測試過程中的請求與響應過程也類似，當我們傳送一個請求，到伺服器接收到這個請求需要時間，系統處理完後將處理結果返回給我們也需要時間。

• 客戶端處理時間

從我們的瀏覽器得到響應資料開始...

真實的使用者場景不要忽略客戶端的處理時間，你拿到信是不是就知道內容了？當然不是，你得拆開信封，把信的內容讀一篇吧。

我們的瀏覽器也是如些，瀏覽器拿到的只有一些HTML、JS、CSS、圖片... 的資源，更底層當然是二進位制資料，需要花費時間把他們渲染成我們想要的網頁。

• 系統處理時間

從當系統得到請求後開始...

這是我們的效能測試主要關心的時間，當系統得到請求後，需要對請求進行處理，可能需要查詢資料庫服務，也可能需要呼叫其它的服務，最終生成處理結果並返回給客戶端。

然而，我們在LoadRunner、JMeter進行效能測試的時候，是沒有客戶端處理時間的，你當然可以同時開100個網頁（可以用多執行緒+Selenium實現）訪問某網站試試，這沒對伺服器產生多少壓力，先把自己的電腦搞掛了。

網路傳輸時間往往也很難模擬真實的場景，因為你網站的使用者來可能來自世界各地，我們總不能在世界各地都搞一個客戶端，就算可以，我們通過什麼方式讓他們“同時”發請求給伺服器呢？

各位讀者，我們約定明天早上8點一起出發去北京全聚德買一隻烤鴨，把全聚德搞斷貨，這可能嗎？雖然，我們的出發時間是一樣的，但因為距離不一樣，到達時間肯定不一樣，根本對全聚德夠不成併發壓力嘛！。所以，我們的效能測試都是放到區域網進行的，就是為了儘量降低傳輸時間，模擬併發。

理解了這些，我們知道，我們所做的效能測試是無法模擬真實的情況，網路的傳輸時間太過複雜，客戶端處理時間取決於使用者的裝置。我們能做的就是儘量保證伺服器端的處理時間，以及在一定的時間可以支撐的併發量。

隨著，技術的發展，越來越多的系統開始做前後端分離。後端，服務只提供介面，前端在不同的裝置上以不同的方式展示。

在這樣的架構下，我們的效能測試也劃分為後端效能和前端效能。

後端效能其實就是介面效能。我們更多的時候不再設計模擬使用者場景，而是針對單個或一組關聯介面進行效能測試，這其實一定程度降低了測試的難度。

其實，不管是否為前後端分離的架構，大多時候他們走的都是HTTP協議。如果是前後端不分離，當你傳送一個請求時，它會返回一堆資料：HTML、JS、CSS、圖片、音視訊...等，如果是前後端分離的架構，那麼後端API返回的資料就單純的多了，一般為JSON格式的資料。

顯然只做後端效能是不夠的，當用戶看到一個頁面時，不單單隻有後端返回的介面資料。

這是我在訪問一個頁面時候得到的所有資料。在你的後端服務沒有達到最大併發的前提下，那麼影響使用者體驗的就兩方面，一個是請求的個數，另一個是請求的檔案大小。

這其實很好理解，你在群裡來喊了一聲，請大家吃飯，結果稀稀拉拉來了100多人，從前一天晚上喝到第二下午，你肯定受不了；而且，其中還有幾個哥們特能喝，“一直喝”就是不倒，你是不是更受不了了。 如果只來了三、五個好友，大家隨意小酌幾杯各自回家，不是很好！？

所以，減少請求的個數，比如有些JS檔案可以做合併；減少請求的大小，比如，有些圖片做壓縮處理。做好這兩點，自然使用者體驗就會好很多，前端效能其實不需要通過“併發”來測試的。

上圖為效能一款App使用的效能指標，這裡的側重點在於App拿到介面資料之後如何更快的把頁面渲染出來，以及在渲染的過程中對硬體資源的消耗情況，還有使用者在不同頁面的切換的流暢度。

誰讓手機硬體一直跟不上App的需求，所以，我們才需要關心App對移動裝置的CPU、記憶體、FPS、耗電、流量的使用情況。

~~~~
為什麼要寫這麼一篇文章，因為有一個同學說，他們老大讓他用JMeter測試系統的效能，還要計算頁面完全載入完成的時間，我想你讀了這篇文章之後應該就不會再提這樣的“要求”了