性能測試淺談

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

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

• 數據傳輸時間

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

真實的用戶場景請不要忽視數據傳輸時間，想一想你給遠方的朋友寫信，信件須要通過不一樣的交通運輸工具送到朋友手上；當你的朋友寫好了信，再次經過不一樣的交通工具送到你的手上。

性能測試過程當中的請求與響應過程也相似，當咱們發送一個請求，到服務器接收到這個請求須要時間，系統處理完後將處理結果返回給咱們也須要時間。

• 客戶端處理時間

從咱們的瀏覽器獲得響應數據開始...

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

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

• 系統處理時間

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

這是咱們的性能測試主要關心的時間，當系統獲得請求後，須要對請求進行處理，可能須要查詢數據庫服務，也可能須要調用其它的服務，最終生成處理結果並返回給客戶端。

然而，咱們在LoadRunner、JMeter進行性能測試的時候，是沒有客戶端處理時間的，你固然能夠同時開100個網頁（能夠用多線程+Selenium實現）訪問某網站試試，這沒對服務器產生多少壓力，先把本身的電腦搞掛了。

網絡傳輸時間每每也很難模擬真實的場景，由於你網站的用戶來可能來自世界各地，咱們總不能在世界各地都搞一個客戶端，就算能夠，咱們經過什麼方式讓他們「同時」發請求給服務器呢？

各位讀者，咱們約定明天早上8點一塊兒出發去北京全聚德買一隻烤鴨，把全聚德搞斷貨，這可能嗎？雖然，咱們的出發時間是同樣的，但由於距離不同，到達時間確定不同，根本對全聚德夠不成併發壓力嘛！。因此，咱們的性能測試都是放到局域網進行的，就是爲了儘可能下降傳輸時間，模擬併發。

理解了這些，咱們知道，咱們所作的性能測試是沒法模擬真實的狀況，網絡的傳輸時間太過複雜，客戶端處理時間取決於用戶的設備。咱們能作的就是儘可能保證服務器端的處理時間，以及在必定的時間能夠支撐的併發量。

隨着，技術的發展，愈來愈多的系統開始作先後端分離。後端，服務只提供接口，前端在不一樣的設備上以不一樣的方式展現。

在這樣的架構下，咱們的性能測試也劃分爲後端性能和前端性能。

後端性能其實就是接口性能。咱們更多的時候再也不設計模擬用戶場景，而是針對單個或一組關聯接口進行性能測試，這其實必定程度下降了測試的難度。

其實，不論是否爲先後端分離的架構，大多時候他們走的都是HTTP協議。若是是先後端不分離，當你發送一個請求時，它會返回一堆數據：HTML、JS、CSS、圖片、音視頻...等，若是是先後端分離的架構，那麼後端API返回的數據就單純的多了，通常爲JSON格式的數據。

顯然只作後端性能是不夠的，當用戶看到一個頁面時，不僅僅只有後端返回的接口數據。

這是我在訪問一個頁面時候獲得的全部數據。在你的後端服務沒有達到最大併發的前提下，那麼影響用戶體驗的就兩方面，一個是請求的個數，另外一個是請求的文件大小。

這其實很好理解，你在羣裏來喊了一聲，請你們吃飯，結果稀稀拉拉來了100多人，從前一天晚上喝到第二下午，你確定受不了；並且，其中還有幾個哥們特能喝，「一直喝」就是不倒，你是否是更受不了了。 若是隻來了3、五個好友，你們隨意小酌幾杯各自回家，不是很好！？

因此，減小請求的個數，好比有些JS文件能夠作合併；減小請求的大小，好比，有些圖片作壓縮處理。作好這兩點，天然用戶體驗就會好不少，前端性能其實不須要經過「併發」來測試的。

上圖爲性能一款App使用的性能指標，這裏的側重點在於App拿到接口數據以後如何更快的把頁面渲染出來，以及在渲染的過程當中對硬件資源的消耗狀況，還有用戶在不一樣頁面的切換的流暢度。

誰讓手機硬件一直跟不上App的需求，因此，咱們才須要關心App對移動設備的CPU、內存、FPS、耗電、流量的使用狀況。

~~~~ 爲何要寫這麼一篇文章，由於有一個同窗說，他們老大讓他用JMeter測試系統的性能，還要計算頁面徹底加載完成的時間，我想你讀了這篇文章以後應該就不會再提這樣的「要求」了。