性能測試到底是什么
這個簡單的問題很多朋友都無法完整的回答。可能知道的朋友會說性能測試就是用LoadRunner或者Jmeter工具來壓測系統，也有人會說性能測試就是同時讓很多人訪問系統看系統能否扛得住。這些回答只能說對，但不夠全面也不夠深刻，只是把表象描述了一下而已。其實真正的性能測試無法用一兩句話來簡單概括，因為它涉及的東西太多。
大部分人一說到性能測試理解的就是壓測服務器，看服務器能不能扛得住，但這只是其中一方面而已，其實性能測試可以分為多個層級，每個層級的關注點以及測試方法等都不太一樣，我們通常認為的是服務器端的性能測試。
那性能測試到底應該怎么去理解呢？我們不妨換個角度來看看，不論是大家理解的通過工具來壓測系統還是號召100個人同時去訪問系統，都不過是實現的手段或者方法而已，我們更應該關注性能測試的目的是什么，因為目的不一樣那么實現的手段或者方法就有可能不一樣。所以我們倒着來看看性能測試，不外乎就是這么幾個目的：
- 壓測系統，看系統的前端以及后端性能是否滿足預期（基准測試）；
- 壓測系統，看系統可以承受的最佳壓力和最大壓力，來判斷系統的承受極限（壓力測試）
- 壓測系統，看系統在長時間運行下是否可以正常處理請求（穩定性測試）
- 容量規划，當系統越來越穩定的時候，我們要提前考慮它的遠景規划，或者更通俗的解釋就是“人無遠慮，必有近憂”，這里的“遠慮”就是容量規划。
這樣看來我們應該就能明白性能測試其實更多的是一個過程的統稱，並不是一個具體的定義。
性能測試分層模型
性能測試分層模型是為了讓大家更容易理解和學習性能測試而總結的，即使對於有一些經驗的朋友，這個分層模型也會對你在認知上有所幫助。該分層模型並不高大上，也有可能不夠完善，只是對雜亂的知識做了總結提煉，但對於小白朋友來說是非常好的良葯，可以幫助大家快速、全面地理解性能測試。
性能測試分層模型中含義
前端層
前端層主要是指用戶看到的頁面。比如，電商網站的首頁、移動APP的各個頁面，這些才是用戶最關心的。對於用戶而言，一個系統的快慢只會通過頁面的呈現速度來判斷，並不會在意你后端處理的速度，所以我經常說即使你后端優化得很牛逼，但前端頁面性能卻非常差，那也是無用功。
另外，APP的測試也是大家經常問到的問題，APP的性能測試至少包括兩個方面：APP的前端，也是現在業界里常說的APP專項測試；APP的后端，本質上和Web端性能測試一樣。所以，在提問之前一定要明白這些概念，別人才能有針對地回答你。
網絡層
任何系統都可以粗略地分成客戶端、網絡端和服務端，其中網絡端是連接前后端的命脈，網絡質量的好壞也有很大的影響。在性能測試中可能遇到的情況大致分為兩種，一種是測試不同網絡狀況下的大流量的表現（一般接觸的比較少），另一種則是壓力機和服務器最好在同一網段，不然壓力無法完整的到達后端，會在網絡層拖垮，這樣就沒法較為准確地評測服務器端的性能情況了。如果你測試的是移動端APP，那么你可能還要考慮在不同網絡狀態下的測試。
后端層
這里分三種情況，也是絕大多數企業中應用的方向，不論是Web端還是移動APP端，在后端層性能測試的方法都是類似的。
業務級
通俗點解釋就是從頁面錄制你的場景腳本。比如，現在有一個電商網站，要通過頁面錄制腳本完成登錄、瀏覽單品頁、下單的流程。這個層級我想大家是最熟悉的，因為jmeter這個工具就是用來完成這樣的流程的，也是大部分小白同學必學的。
這種性能測試方式有個致命的缺點就是依賴於頁面，如果頁面沒有開發完畢測試就無法提前進行，而現實中測試時間往往被一味壓縮，因此我們有時候也很無奈，所以如何把測試的切入點盡可能的提前就顯得比較重要了。而接口級恰恰就解決了這個問題。
接口級
這個層級是大部分公司做性能測試的首選，也是最有效率的方式之一。比如，現在有一個登錄接口，你只需要知道入參、出參以及規則等即可編寫測試接口的代碼，不需要等待頁面的開發，大大提前了測試的切入點，但它要求測試工程師有一定的編碼能力。除此之外，接口級測試的擴展性強，可以通過完成接口的性能測試和功能自動化測試框架來提升效率，性價比較高。
單元級
這個層級恰恰和接口級相反，很多公司想做，但有心無力。單元級大家理解為類似“單元測試”即可，比如，有一個PHP代碼塊，我們可能需要測試一下核心算法函數的性能，可以通過插樁或引入單元測試框架來完成，從而獲得它的執行時間、CPU消耗以及內存占用率等信息來優化代碼性能。
那為什么很多公司做不起來單元級的測試？可能有以下幾個原因
- 業務變化太快，涉及的代碼邏輯修改也比較大，這樣做單元級測試就得不償失了。
- 開發朋友們確實沒有太多的時間寫單元測試代碼，畢竟業務邏輯代碼寫起來也很費時，沒有太多時間搞其他了。
- 測試工程師編碼能力相對來說較弱，能獨當一面完成單元測試的人少之又少，在加上時間緊迫就更無法做單元級的測試。