效能測試入門（二） 做個最簡單的效能測試

之前在《效能測試中的各項指標告訴我們什麼》簡單介紹了一些基本的效能指標的含義，明確了我們效能測試的目標是在保證請求成功率及不超過目標請求時間的情況下，找出我們系統的最大併發量。在這篇文章中我們做些實踐，以程式設計師小張的視角來做一次效能測試。

首先我們把問題簡單化一些，假設小張從業務經理接到的乙個**開發任務，這個**只設計了乙個網頁，內容是每天公司都會更新發布的10條資訊。

好了，因為我們的假設，任務很簡單，小張三下五除二就把功能實現做完了，把程式部署到了一台伺服器上，然後告知經理做完了。經理說，這個**很重要，是董事長她小姨子親手抓的專案，是公司的臉面，董事長一再強調不能做成12306**那樣一點就掛，你這程式能不能撐得住。小張說那我做下效能測試吧

小張先問了問業務經理，說我們的最大響應時間latency

qps：10000個請求/32秒=312.5請求/秒

*併發量：312.5*32=100

第二次測試

啟動1000個執行緒，每個執行緒訪問乙個頁面100次，進行壓測，

結果313秒完成10萬請求，沒有失敗，每個請求平均時長3.1秒，請問在這次測試中，qps是多少，併發量是多少？

qps：100000個請求/313秒=319請求/秒

併發量：319*3.1=990

因為第二次測試時平均響應時長已經超過了3秒，小張看了看990這個數字，覺得系統目前最大的併發量應該在1000附近。於是跑去告訴業務經理，**效能是最高支援1000個併發。業務經理撓了撓頭，說可是我們公司內部就有3000人啊，所有人都去看一眼豈不是掛了。小張說你覺得使用者重新整理過一次會隔多久重新整理第二次，業務經理說全部看完網頁應該是5秒，就會重新整理第二次了。小張說那就是思考時間大概是5秒，思考時間為5秒的情況下，併發1000的意思就是就是支援5000個使用者重新整理。業務經理點點頭，很滿意的走了。

這是最為簡單的乙個效能測試過程的模擬。

上面的那個例子，只是為了簡單體會下效能測試的大概的流程，忽略掉了很多的東西，但是現實工作中接觸到的效能測試，我們需要考慮更多：

1、系統的瓶頸

效能測試的乙個重要目的就是找出系統的效能瓶頸，找到瓶頸的目的其實是為了優化或者保證能優化的可能性。從軟體開發角度來講，我們對系統瓶頸是有期望的，我們期望瓶頸出現在硬體層面，而不要出現在軟體層面。如果在效能測試中你發現伺服器的cpu、記憶體等硬體指標一直都沒有什麼變化，那就意味著肯定是瓶頸出現在網路頻寬和軟體上，那我們的工作可能就是需要調整db連線池、os操作控制代碼數等指標，我們的工作就是調整這些好調整的，最後調整那些不好調整的。

所以，在實際的測試過程中，不會像小張一樣只關心了測試客戶端的資料，必須時刻監測伺服器及中介軟體的各項效能指標，以找出系統瓶頸並分析優化以保證瓶頸出現在我們期望他出現的位置。

2、壓測的粒度

小張面臨的其實是最簡單的一種壓力測試，單機單應用測試，也就是只有乙個主機，只有乙個應用，效能非常好估算。但是實際生產環境中往往是多主機多應用的環境，還有就是存在大量的鏈條式的呼叫關係，比如必須先呼叫下單服務後再呼叫支付服務。這種情況下就需要從單機單應用出發，逐漸擴充套件到集群的測試，針對鏈條式的呼叫關係也要從單應用的測試，變為鏈路的測試，比如先單獨測試下單服務和支付服務，找到他們的最大併發數後，再構建兩個都測試的場景，測試鏈條的最大併發數。不同的軟體型別往往有不同的壓測方案，各家公司不太一樣，沒有放之四海皆準的標準。

3、壓測資料流量

當壓測的粒度定下來，真正進行壓測的時候，實際往往要進行模擬真實的資料流量。比如說要真的模擬使用者登入（壓測環境往往要針對壓測改些**），模擬使用者下單，這部分往往是壓測工作中工作量最大的部分，因為要準備虛擬的使用者資料，撰寫壓測指令碼，還往往要針對壓測要修改下目標系統的**以保證壓測可以正常進行（比如跳過密碼登入，關閉ip驗證等）。在傳統軟體領域，往往找一台或者幾台效能還不錯的測試機，執行下測試指令碼，往往也就能構建出相對應的流量。即使對使用者資料有要求，上萬條使用者資料模擬也基本夠用了。但是對於網際網路領域的大型**來說，壓測流量資料的獲取往往是個大問題，沒有那麼多流量資料咋辦。通常的做法就是兩種：

4、前端效能

僅僅針對web頁面測試的話，小張的測試中其實還忽略了乙個要素，前端。乙個網頁的訪問往往不是單純的乙個請求，而是一組請求，除了html的請求還有介面請求，靜態資源請求等。如果要考慮效能損耗的話小張應該把所有請求都考慮在內對伺服器進行壓測才對。筆者現實生活中就見到過專案因為前端請求過多大量占用頻寬導致整個**無法訪問的情況發生。當然如果在實際專案上已經做了動靜分離，可以單獨針對前端資源獲取進行服務壓力測試。但是前端效能測試還要考量的是，使用者體驗的方面，比如首屏載入時間等，這個屬於前端的領域了，與伺服器關係不大，筆者不贅述，可以點此鏈結了解

前端效能優化和測試工具總結

效能測試入門

效能測試 在拜讀了段念的 軟體效能測試過程詳解與案例剖析 一書後，對各種效能測試型別有了豁然開朗的感覺。網上關於效能測試型別方面一直都討論不休並有多種見解，以下是根據書上描述和個人經驗對測試側重點做了進一步探索，不對之處請指正。我們所說的效能測試是一種廣義上的說法，包括了以下各種不同的效能測試型別，...

jemter入門 簡單的效能測試案例

1.新增執行緒組 在新增的執行緒組中，設定資訊如紅框 併發使用者數 2 迴圈次數 5次，迴圈完畢停止測試。2 新增乙個http sample 測試指令碼的主體 選中 執行緒組 右鍵新增 取樣器 http請求 3 新增結果樹 用來debug指令碼，遇到效能測試錯誤排查錯誤等，預設不會新增，所以需要手動...

效能測試（二）

下面分別介紹下每個階段具體需要做什麼 一 效能需求分析 效能需求分析是整個效能測試工作開展的基礎，如果連效能的需求都沒弄清楚，後面的效能測試執行其實是沒有任何意義的，而且效能需求分析做的好不好直接影響到效能測試的結果。一些效能測試人員常犯的錯誤就是測試一開始就直接用工具對系統進行加壓，沒有弄清楚效能...