性能測試到底是什么

　　這個簡單的問題很多朋友都無法完整的回答?？赡苤赖呐笥褧f性能測試就是用LoadRunner或者Jmeter工具來壓測系統(tǒng)，也有人會說性能測試就是同時讓很多人訪問系統(tǒng)看系統(tǒng)能否扛得住。這些回答只能說對，但不夠全面也不夠深刻，只是把表象描述了一下而已。其實真正的性能測試無法用一兩句話來簡單概括，因為它涉及的東西太多。

　　大部分人一說到性能測試理解的就是壓測服務器，看服務器能不能扛得住，但這只是其中一方面而已，其實性能測試可以分為多個層級，每個層級的關注點以及測試方法等都不太一樣，我們通常認為的是服務器端的性能測試。

　　那性能測試到底應該怎么去理解呢？我們不妨換個角度來看看，不論是大家理解的通過工具來壓測系統(tǒng)還是號召100個人同時去訪問系統(tǒng)，都不過是實現(xiàn)的手段或者方法而已，我們更應該關注性能測試的目的是什么，因為目的不一樣那么實現(xiàn)的手段或者方法就有可能不一樣。所以我們倒著來看看性能測試，不外乎就是這么幾個目的：

　　壓測系統(tǒng)，看系統(tǒng)的前端以及后端性能是否滿足預期（基準測試）；

　　壓測系統(tǒng)，看系統(tǒng)可以承受的最佳壓力和最大壓力，來判斷系統(tǒng)的承受極限（壓力測試）

　　壓測系統(tǒng)，看系統(tǒng)在長時間運行下是否可以正常處理請求（穩(wěn)定性測試）

　　容量規(guī)劃，當系統(tǒng)越來越穩(wěn)定的時候，我們要提前考慮它的遠景規(guī)劃，或者更通俗的解釋就是“人無遠慮，必有近憂”，這里的“遠慮”就是容量規(guī)劃。

　　這樣看來我們應該就能明白性能測試其實更多的是一個過程的統(tǒng)稱，并不是一個具體的定義。

　　性能測試分層模型

　　性能測試分層模型是為了讓大家更容易理解和學習性能測試而總結的，即使對于有一些經(jīng)驗的朋友，這個分層模型也會對你在認知上有所幫助。該分層模型并不高大上，也有可能不夠完善，只是對雜亂的知識做了總結提煉，但對于小白朋友來說是非常好的良藥，可以幫助大家快速、全面地理解性能測試。

　　性能測試分層模型中含義

　　前端層

　　前端層主要是指用戶看到的頁面。比如，電商網(wǎng)站的首頁、移動APP的各個頁面，這些才是用戶最關心的。對于用戶而言，一個系統(tǒng)的快慢只會通過頁面的呈現(xiàn)速度來判斷，并不會在意你后端處理的速度，所以我經(jīng)常說即使你后端優(yōu)化得很牛逼，但前端頁面性能卻非常差，那也是無用功。

　　另外，APP的測試也是大家經(jīng)常問到的問題，APP的性能測試至少包括兩個方面：APP的前端，也是現(xiàn)在業(yè)界里常說的APP專項測試；APP的后端，本質上和Web端性能測試一樣。所以，在提問之前一定要明白這些概念，別人才能有針對地回答你。

　　網(wǎng)絡層

　　任何系統(tǒng)都可以粗略地分成客戶端、網(wǎng)絡端和服務端，其中網(wǎng)絡端是連接前后端的命脈，網(wǎng)絡質量的好壞也有很大的影響。在性能測試中可能遇到的情況大致分為兩種，一種是測試不同網(wǎng)絡狀況下的大流量的表現(xiàn)（一般接觸的比較少），另一種則是壓力機和服務器最好在同一網(wǎng)段，不然壓力無法完整的到達后端，會在網(wǎng)絡層拖垮，這樣就沒法較為準確地評測服務器端的性能情況了。如果你測試的是移動端APP，那么你可能還要考慮在不同網(wǎng)絡狀態(tài)下的測試。

　　后端層

　　這里分三種情況，也是絕大多數(shù)企業(yè)中應用的方向，不論是Web端還是移動APP端，在后端層性能測試的方法都是類似的。

　　業(yè)務級

　　通俗點解釋就是從頁面錄制你的場景腳本。比如，現(xiàn)在有一個電商網(wǎng)站，要通過頁面錄制腳本完成登錄、瀏覽單品頁、下單的流程。這個層級我想大家是最熟悉的，因為jmeter這個工具就是用來完成這樣的流程的，也是大部分小白同學必學的。

　　這種性能測試方式有個致命的缺點就是依賴于頁面，如果頁面沒有開發(fā)完畢測試就無法提前進行，而現(xiàn)實中測試時間往往被一味壓縮，因此我們有時候也很無奈，所以如何把測試的切入點盡可能的提前就顯得比較重要了。而接口級恰恰就解決了這個問題。

　　接口級

　　這個層級是大部分公司做性能測試的首選，也是最有效率的方式之一。比如，現(xiàn)在有一個登錄接口，你只需要知道入?yún)?、出參以及?guī)則等即可編寫測試接口的代碼，不需要等待頁面的開發(fā)，大大提前了測試的切入點，但它要求測試工程師有一定的編碼能力。除此之外，接口級測試的擴展性強，可以通過完成接口的性能測試和功能自動化測試框架來提升效率，性價比較高。

　　單元級

　　這個層級恰恰和接口級相反，很多公司想做，但有心無力。單元級大家理解為類似“單元測試”即可，比如，有一個PHP代碼塊，我們可能需要測試一下核心算法函數(shù)的性能，可以通過插樁或引入單元測試框架來完成，從而獲得它的執(zhí)行時間、CPU消耗以及內存占用率等信息來優(yōu)化代碼性能。

　　那為什么很多公司做不起來單元級的測試？可能有以下幾個原因

　　業(yè)務變化太快，涉及的代碼邏輯修改也比較大，這樣做單元級測試就得不償失了。

　　開發(fā)朋友們確實沒有太多的時間寫單元測試代碼，畢竟業(yè)務邏輯代碼寫起來也很費時，沒有太多時間搞其他了。

　　測試工程師編碼能力相對來說較弱，能獨當一面完成單元測試的人少之又少，在加上時間緊迫就更無法做單元級的測試。