早期的性能測試更關注后端服務的處理能力。
一個用戶去訪問一個頁面的請求過程，如上圖。
- 數據傳輸時間
當你從瀏覽器輸入網址，敲下回車，開始...
真實的用戶場景請不要忽視數據傳輸時間，想想你給遠方的朋友寫信，信件需要經過不同的交通運輸工具送到朋友手上；當你的朋友寫好了信，再次通過不同的交通工具送到你的手上。
性能測試過程中的請求與響應過程也類似，當我們發送一個請求，到服務器接收到這個請求需要時間，系統處理完后將處理結果返回給我們也需要時間。
- 客戶端處理時間
從我們的瀏覽器得到響應數據開始...
真實的用戶場景不要忽略客戶端的處理時間，你拿到信是不是就知道內容了？當然不是，你得拆開信封，把信的內容讀一篇吧。
我們的瀏覽器也是如些，瀏覽器拿到的只有一些HTML、JS、CSS、圖片... 的資源，更底層當然是二進制數據，需要花費時間把他們渲染成我們想要的網頁。
- 系統處理時間
從當系統得到請求后開始...
這是我們的性能測試主要關心的時間，當系統得到請求后，需要對請求進行處理，可能需要查詢數據庫服務，也可能需要調用其它的服務，最終生成處理結果並返回給客戶端。
然而，我們在LoadRunner、JMeter進行性能測試的時候，是沒有客戶端處理時間的，你當然可以同時開100個網頁（可以用多線程+Selenium實現）訪問某網站試試，這沒對服務器產生多少壓力，先把自己的電腦搞掛了。
網絡傳輸時間往往也很難模擬真實的場景，因為你網站的用戶來可能來自世界各地，我們總不能在世界各地都搞一個客戶端，就算可以，我們通過什么方式讓他們“同時”發請求給服務器呢？
各位讀者，我們約定明天早上8點一起出發去北京全聚德買一只烤鴨，把全聚德搞斷貨，這可能嗎？雖然，我們的出發時間是一樣的，但因為距離不一樣，到達時間肯定不一樣，根本對全聚德夠不成並發壓力嘛！。所以，我們的性能測試都是放到局域網進行的，就是為了盡量降低傳輸時間，模擬並發。
理解了這些，我們知道，我們所做的性能測試是無法模擬真實的情況，網絡的傳輸時間太過復雜，客戶端處理時間取決於用戶的設備。我們能做的就是盡量保證服務器端的處理時間，以及在一定的時間可以支撐的並發量。
隨着，技術的發展，越來越多的系統開始做前后端分離。后端，服務只提供接口，前端在不同的設備上以不同的方式展示。
在這樣的架構下，我們的性能測試也划分為后端性能和前端性能。
后端性能其實就是接口性能。我們更多的時候不再設計模擬用戶場景，而是針對單個或一組關聯接口進行性能測試，這其實一定程度降低了測試的難度。
其實，不管是否為前后端分離的架構，大多時候他們走的都是HTTP協議。如果是前后端不分離，當你發送一個請求時，它會返回一堆數據：HTML、JS、CSS、圖片、音視頻...等，如果是前后端分離的架構，那么后端API返回的數據就單純的多了，一般為JSON格式的數據。
顯然只做后端性能是不夠的，當用戶看到一個頁面時，不單單只有后端返回的接口數據。
這是我在訪問一個頁面時候得到的所有數據。在你的后端服務沒有達到最大並發的前提下，那么影響用戶體驗的就兩方面，一個是請求的個數，另一個是請求的文件大小。
這其實很好理解，你在群里來喊了一聲，請大家吃飯，結果稀稀拉拉來了100多人，從前一天晚上喝到第二下午，你肯定受不了；而且，其中還有幾個哥們特能喝，“一直喝”就是不倒，你是不是更受不了了。 如果只來了三、五個好友，大家隨意小酌幾杯各自回家，不是很好！？
所以，減少請求的個數，比如有些JS文件可以做合並；減少請求的大小，比如，有些圖片做壓縮處理。做好這兩點，自然用戶體驗就會好很多，前端性能其實不需要通過“並發”來測試的。
上圖為性能一款App使用的性能指標，這里的側重點在於App拿到接口數據之后如何更快的把頁面渲染出來，以及在渲染的過程中對硬件資源的消耗情況，還有用戶在不同頁面的切換的流暢度。
誰讓手機硬件一直跟不上App的需求，所以，我們才需要關心App對移動設備的CPU、內存、FPS、耗電、流量的使用情況。
為什么要寫這么一篇文章，因為有一個同學說，他們老大讓他用JMeter測試系統的性能，還要計算頁面完全加載完成的時間，我想你讀了這篇文章之后應該就不會再提這樣的“要求”了。