性能測試分層模型

以下內容選自《小強軟件測試瘋狂講義》一書

這里我特別提前說一句：任何東西都有一定的受眾群體，世界上也沒有任何東西可以讓所有人100%滿意。So，本書也是。只要本書中有一個篇章的內容給你帶來了影響那就是這本書的價值！感謝大家的支持。

引子

我為什么會把這個話題放到最開始呢？就是因為這些年在企業工作中、在教育領域培訓中接觸過不少朋友，在這個過程中我發現居然有95%以上的朋友不明白什么是性能測試，什么是自動化測試，這都不要緊，但更可怕的是還對這些概念有巨大的誤解，從而導致學習的時候走了很多彎路，看的我也是萬般無奈，所以我們就先來好好聊聊性能測試和自動化測試到底是什么，希望能幫助大家更加全面、深刻的理解它們。千萬不要小瞧這些，如果你的認知都是錯的，你怎么可能學的對呢？

另外，我也必須在開篇中指出一點：所有人的學習都需要一個過程，也許你身邊有同事已經經歷了A階段到達了B階段，他或許會從技術層面鄙視你或者批判你，但是你不要氣餒，誰都不是從娘胎里出來就會說話、就會跑步的，都需要經歷這個特別“低級”的階段，這是必然。我們會一直堅持正能量帶領“新人”成長，幫助你完成階段性的蛻變。

性能測試到底是什么

這個看似簡單的問題我相信很多朋友都無法全面地回答上來。可能知道的朋友會說性能測試就是用LoadRunner或者Jmeter工具搞個并發來壓測系統，也可能會說性能測試就是同時讓很多人訪問系統看系統能否扛得住。這些回答我只能說對，但不夠全面，也不夠深刻，只是把表象描述了一下而已。其實真正的性能測試無法用一兩句話來簡單概括，因為它涉及的東西太多了。

大部分小白朋友一說性能測試理解的就是壓測服務器，看服務器能不能扛得住，但這只是其中一方面而已，其實性能測試可以分為多個層級，每個層級的關注點以及測試方法等都不太一樣，我們常認為的是服務器端側的性能測試。至于性能測試的分層我們會在后面的章節中給大家講解。

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

1) 壓測系統看系統的前端以及后端是否滿足預期（類似功能測試用例中的預期結果和實際結果的概念）；

2) 壓測系統看系統可以承受的最佳壓力和最大壓力，來判斷系統的承受極限；

3) 壓測系統看系統在長時間運行下是否可以正常處理請求（類似疲勞測試）

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

這樣看來我們應該就能明白性能測試其實更多的是一個過程的統稱，并不是一個具體的定義，同時在學習性能測試的時候要暫時拋開功能測試的思想，否則很容易掉進陷阱，這也是大部分小白朋友最容易犯的錯誤。

性能測試分層模型

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

下面我們就來看看這個性能測試分層模型中每層所代表的含義。

前端層

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

以前這個層級是很多企業和測試工程師并不關注的，但近幾年對于前端性能的要求也越來越高，也是大家應該了解的知識。本書將在后面的章節中詳細講解前端性能方面的知識和實踐經驗。

另外，APP的測試也是大家經常問到的問題，我有時候特別無奈，大家張口就問：“APP性能測試怎么做啊？”，這樣的問題真的沒法回答。APP的性能測試至少包括兩個方面：APP的前端，也是現在業界里常說的APP專項測試；APP的后端，本質上和Web

側性能測試一樣。所以，在問之前一定要明白這些知識別人才能有針對地回答你。

網絡層

任何系統都可以粗略地分成客戶端、網絡和服務器端，其中網絡是連接前后端的命脈，網絡質量的好壞也有很大的影響。在性能測試中可能遇到的情況大致分為兩種，一種是測試不同網絡狀況下的大流量的表現（一般接觸的比較少），另一種則是壓力機和服務器最好在同一網段，不然壓力無法完整的到達后端，會在網絡層拖垮，這樣就沒法較為準確地評測服務器端的性能情況了。如果你測試的是移動端APP，那么你可能還要考慮在不同網絡狀態下的測試。對于網絡層的性能測試我接觸的非常少，為了不誤人子弟這里就不班門弄斧了。大家的重點是了解這個分層模型，對于理解性能測試很重要。

后端層

這里我分成了三種情況，也是絕大多數企業中應用的方向，是大家必須了解和掌握的。同時大家也要明白，不論是Web端還是移動APP端，在后端層性能測試的方法都是類似的。

第一，業務級：通俗點解釋就是從頁面錄制你的場景腳本。比如，現在有一個小強電商網站，你要通過頁面錄制腳本完成登錄、瀏覽單品頁、下單的流程。這個層級我想大家是最熟悉的，因為LoadRunner這個工具就是用來完成這樣的流程的，也是大部分小白同學必學的。至于怎么去完成我們在后面的章節中會詳細講解到。

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

第二，接口級：這個層級是大部分公司做性能測試的首選，也是最有效率的方式之一。比如，現在有一個登錄接口，你只需要知道入參、出參以及規則等即可編寫測試接口的代碼，不需要等待頁面的開發，大大提前了測試的切入點，但它要求測試工程師有一定的編碼能力。除此之外，接口級測試的擴展性強，可以通過完成接口的性能測試和功能自動化測試框架來提升效率，性價比較高。具體如何去完成將在后面的章節中詳細講解。

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

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

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

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

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

我們聊完這些分層后，也許有的朋友會感覺其中有些技術很厲害，感覺很高大上。可是我個人覺得不是你用多么厲害的技術就牛逼，只有用合適的技術帶來較高的性價比才是王道，有句話說的好：“最好的不一定是合適的，只有合適的才能發揮最好的效果”。

看完這些不知道大家是不是對性能測試有了不一樣的了解。當然，這個模型不見得是最好的，只是根據經驗總結而來，也有很大的改進空間，我希望的是能和大家一起交流來完善，并不希望來爭論對與錯，世間本身沒有絕對的對與錯，只有更多的交流你才能吸收更多的知識來武裝提升自己，俗話說的好：“你一個想法，我一個想法，我們交流一下就彼此擁有了兩個想法”，何樂而不為呢。