在大家的眼裡效能測試一種高逼格的測試，那麼咱們今天就來學習一下效能測試核心原理相關的知識點；效能測試涉及的領域及最本質的內容包含什麼呢？咱們首先來學習一下關於"效能測試原理"相關的知識點。效能測試主要從三個核心要素上來講解：第一個它是基於網路協議的；第二個基於多執行緒；第三個模擬真實的使用者場景，基於這三個核心原理詳細講解。

首先：基於"網路協議"層面來說，為什麼效能測試中其中有一個核心原理是基於協議的呢？大家都知道不管是web系統也好，app應用程式也好，他們之間是怎麼樣建立連線的？其實都是基於網路協議來建立連線的；講到網路連線我們首先應該聯想到OSI參考模型與TCP/IP五層模型,那什麼是OSI?OSI（Open System Interconnect），即指互聯, 一般都叫OSI參考模型，是組織在1985年研究的模型。該標準定義了網路互聯的七層由高到低依次包括（應用層、表示層、會話層、傳輸層、網路層、資料鏈路層和物理層）即稱為開放式系統互聯引數模型，平時我們應用最多是基於TCP/IP五層模型基於上是基於應用層面的內容，其它關於物理層、資料鏈路層、網路層、資料傳輸層簡單了解一下就好。OSI七層參考模型與TCP/IP五層結構模型如下圖所示：

下面簡單講解一下關於TCP/IP五層模型原理過程：

應用層：一般就是指編寫的應用程式，決定了給使用者提供的應用服務。可以通過系統呼叫，與傳輸層進行通訊。我們平時基於windows作業系統開啟的web網站或者APP應用大部分是基於應用層的HTTP或者HTTPS協議來進行傳輸資料從而達到通訊的目的。位於該層的協議都是一種標準化協議，如：FTP檔案傳輸、DNS域名解析、POP3、SMTP、HTTP超文字傳輸協議或者HTTPS超文字傳輸加密協議。那什麼是協議？很多同學可能聽著有點暈，在這裡我舉個例子：我們平時進公司是不是都有簽訂合同協議，在簽訂合同協議之前我們是不是經過企業的面試。然後與企業達成合作。我們將自己的時間賣給公司，公司每月按時給我們薪水，但是在簽訂協議之前我們的薪水都經過雙方同意才達成一致的，其實這個過程就是一個協議通過過程，它是有標準規範的，在做這件事的過程中我們一定要遵守公司的規章制度按照公司的安排完成相關工作任務，公司給付相應的薪水，達成一致的協議。

傳輸層：建立主機端到端的連結，這裡的端指的是埠號，傳輸層通過系統呼叫嚮應用層提供網路連線的資料傳輸功能。例如：TCP/UDP協議位於傳輸層協議，可以理解成負責公司快遞郵件收發人，公司的投遞員，負責將其它公司的資料投遞到郵件或者快遞公司郵寄。

網路層：處理網路上流動的資料包，資料包就是網路傳輸的最小資料單位。定義傳輸路徑和方法。

鏈路層：處理連線網路的硬體部分，簡單了解即可因為我們不是搞網路的專業人員無需太深入研究。

基於協議的七層架構是怎麼進行工作的我們都理解了，那站在測試的角度，如何來理解web前端系統和app客戶端程式是位於那一個層次的呢？其實就是基於應用層來進行資料互動的，如何進行資料互動的？其實是通過介面來進行的，那介面測試是在那個階段進行的？我們都知道基於軟體品質模型過程，其中有一個模型叫V模型，它包括了開發過程和測試過程依次由高到低是開發過程，由低到高是測試過程依次分為：單元測試、整合測試、系統測試、確認測試、驗收測試五個階段。其實在不同的測試階段，其中介面測試就是在整合測試階段進行的，在此階段大家從模型過程中可以看出，還沒有到系統測試階段是沒有介面的，那我們怎麼去測試？通過介面協議，所以在學習效能測試之前我們需要具備一定的介面測試基礎，不然的話這堂課程大家可能會聽得一頭霧水。但是咱們今天這堂課主要針對性能測試核心原理展開講解，第一基於協議我們需要學習相關的介面測試工具，目前市場上比較流行的介面測試工具有：jmeter/SoapUI/LR/Postman/poster/httpclient等等，藉助這些工具就可以完成介面的自動化測試，那麼基於效能測試的協議與功能介面測試類似，所以介面測試在單元測試階段後進行，我們只需要有一個介面需求文件就可以開展介面測試，但是效能測試是在系統測試階段進行的，但是效能測試是不基於介面的，基於協議的，所以為什麼協議非常重要。大家做介面測試的時候有沒有發現需求文件並沒有介面UI原型圖，意思不需要介面，我只需要知道一個URL地址、引數型別、輸入引數、狀態碼等介面相關這就能完成介面測試。那麼效能測試其實就是在單個介面測試的基礎上增加大量使用者對介面進行加壓測試。案例如下圖所示：介面整合自動化測試結果基於Jmeter+ANT+郵件傳送。

其次：基於"多執行緒"，什麼是多執行緒呢？例如：我們人類的大腦，大部分都是單執行緒，為什麼大部分人的大腦是單執行緒？因為人類一般沒有太多精力同時做多件事情；但是電腦可以做到同時一邊上網，一邊聽歌、一邊寫文章、一邊上網課同時進行，這其實就是一種多執行緒。那基於web系統與app應用程式層面分析多執行緒是如何形成的呢？接下來我將簡單跟大家分享一下，大家都知道我們每天都會遊走在網際網路上，那瀏覽網頁的是不是你一個人？答案肯定不是的，全世界只要有手機與電腦有網路都可以上網，這就意味著我們釋出的一些web系統和app應用程式，在同一時間可能被很多人同時訪問，但是我們在做功能測試的時候可能僅僅基於需求功能點進行覆蓋，我們並不會基於多使用者來測試這個功能，這樣就會導致產品釋出到線上環境可靠性差，如果使用者數量達到一定的數量，由於本身我們沒有做過效能測試就會導致系統承受壓力的能力與資源無法預估，那有沒有可能達到一定數量的壓力瓶頸點系統會產生奔潰？其實都有可能，為什麼會出現這種情況呢？隨著使用者數量的增加，伺服器處理請求的速度逐漸變慢，佇列可能會排得很長，達到資源耗盡的情況，這時候如果再來一波使用者系統已經承受不住， 就會導致系統崩潰。通過這個例子相信大家對基於多執行緒已經有了一個深入的理解，也就是說一個功能在少用使用者訪問的時候不會有問題，但是批量使用者同時訪問系統的時候如果沒有做效能測試就有帶來嚴重的問題，例如：伺服器掛掉，系統崩潰、記憶體溢位等問題。那麼我們如何來模擬這種多使用者的真實場景呢？接下來我們將講解基於多執行緒作業系統。

基於多執行緒案例圖詳解：

效能測試多執行緒場景設計

再次:模擬"真實的使用者"場景

大家都知道我們要模擬真實的使用者來訪問這個系統需要大量的人力與物力資源，就從全中國範圍來看，大公司的軟體訪問量大部分都上億，那麼這麼多人訪問系統，我們如何來模擬真實的使用者操作？以前沒有測試工具的時候我們是使用人工來模擬，但是成千上萬個人不可能配備成千上萬臺電腦來模擬，一般企業也很少存在上萬個員工，至少在網際網路企業來說還是比較少，這樣會不會浪費人力與物力資源呢？有沒有方法可以解決這個問題呢？答案是有的，可以通過效能測試工具來解決這個問題，使用LR或者Jmeter工具來幫助我們完成模擬真實使用者的效能測試。這兩款工具可以達到模擬單業務與混合業務基於多使用者作業系統的目的，從而更好的滿足效能需求。多使用者操作發貼例子案例結果如下圖所示：

利用LR模擬真實的使用者場景

總結：關於效能測試三個核心概念，基於原理及過程給大家做了一個詳解的分享，希望大家通過本次課程的學習，能夠對效能測試有一個更深層次的理解，首先我們再來回顧一下本次課程的核心內容：效能測試是基於協議的、基於多執行緒、模擬真實的使用者場景而開展工作，只要我們掌握好這三個核心概念，咱們後面的效能測試課程就更好開展，希望同學們通過今天的學習能夠站在更高的層次，學會分析問題從而更好的解決問題，本次課程到此結束，我們下一期見。