閱讀本文大概需要 6 分鐘。
來自：http://t.cn/ES7KBkW
本文將從負載測試的角度，描述了做一次流暢的 5 萬用戶併發測試需要做的事情。
你可以在本文的結尾部分看到討論的記錄。
快速的步驟概要：
編寫你的腳本
使用 JMeter 進行本地測試
BlazeMeter 沙箱測試
使用一個控制檯和一個引擎設置 Users-per-Engine 的數量
設置並測試你的集合 (1 個控制檯和 10-14 引擎)
使用 Master / Slave 特性來達成你的最大 CC 目標
步驟 1 : 編寫你的腳本
開始之前，請確定從 JMeter 的 Apache 社區 jmeter.apache.org 獲得了最新的版本。
你也會要下載這些附加的插件 ，因爲它們可以讓你的工作更輕鬆。
有許多方法可以獲得腳本:
使用 BlazeMeter 的 Chrome 擴展 來記錄你的方案
使用 JMeter HTTP(S) 測試腳本記錄器 來設置一個代理，那樣你就可以運行你的測試並記錄下所有的東西
從頭開始全部手工構建(可能是功能/ QA 測試)
如果你的腳本是一份記錄的結果(像步驟 1&2 ), 請牢記：
你需要改變諸如 Username & Password 這樣的特定參數，或者你也許會想要設置一個 CSV 文件，有了裏面的值每個用戶就可以是不同的。
爲了完成諸如“添加到購物車”，“登錄”還有其它這樣的請求，你也許要使用正則表達式，JSON 路徑提取器，XPath 提取器，來提取諸如 Token 字符串，表單構建 ID 還有其它要素。
保持你的腳本參數化，並使用配置元素，諸如默認 HTTP 請求，來使得在環境之間切換時你的工作更輕鬆。
步驟 2 : 使用 JMeter 進行本地測試
在 1 個線程的 1 個迭代中使用查看結果樹要素，調試樣本，虛擬樣本還有打開的日誌查看器（一些 JMeter 的錯誤會在裏面報告），來調試你的腳本。
遍歷所有的場景(包括 True 或者 False 的迴應) 來確保腳本行爲確如預期...
在成功使用一個線程測試之後——將其提高到 10 分鐘 10 到 20 個線程繼續測試:
如果你想要每個用戶獨立——是那樣的麼?
有沒有收到錯誤?
如果你在做一個註冊過程，那就看看你的後臺 - 賬戶是不是照你的模板創建好了? 它們是不是獨立的呢?
從總結報告中，你可以看到對測試的統計 - 它們有點用麼? (平均響應時間, 錯誤, 每秒命中率)
一旦你準備好了腳本:
通過移除任何調試和虛擬樣本來清理腳本，並刪除你的腳本偵聽器
如果你使用了偵聽器(諸如 "將響應保存到一個文件")，請確保你沒有使用任何路徑! ，而如果他是一個偵聽器或者一個 CSV 數據集配置——請確保你沒有使用你在本地使用的路徑 - 而只要文件名(就好像跟你的腳本在同一個文件夾)
如果你使用了自己專有的 JAR 文件，請確保它也被上傳了。
如果你使用了超過一個線程組（不是默認的那個) - 請確保在將其上傳到 BlazeMeter 之前設置了這個值。
步驟 3 : BlazeMeter 沙箱測試
如果那時你的第一個測試——你應該溫習一下 這篇 有關如何在 BlazeMeter 中創建測試的文章。
將沙箱的測試配置設置成，用戶 300，1 個控制檯, 時間 50 分鐘。
對沙箱進行這樣的配置讓你可以在後臺測試你的腳本，並確保上的 BlazeMeter 的一切都運行完好。
爲此，先按下灰色的按鈕: 告訴 JMeter 引擎我想要完全控制! - 來獲得對你的測試參數的完全控制
通常你將會遇到的問題：
防火牆 - 確保你的環境對 BlazeMeter 的 CIDR 列表 (它們會實時更新)開發，並把它們放入白名單中
確保你所有的測試文件, 比如: CSVs, JAR, JSON, User.properties 等等.. 都可以使用
確保你沒有使用任何路徑
如果仍然有問題，那就看看錯誤日誌吧(你應該可以把整個日誌都下載下來)。
一個沙箱的配置可以是這樣的:
引擎: 是能使控制檯( 1 個控制檯 , 0 個引擎)
線程: 50-300
產能提升: 20 分鐘
迭代: 一直測試下去
時間: 30-50 分鐘
這可以讓你在產能提升期間獲得足夠多的數據(以防你遇到問題) ，而你將可以對結果進行分析，以確保腳本的執行確如預期。
你應該觀察下 Waterfall / WebDriver 選項卡來看看請求是否正常，你不應該在這一點上出任何問題（除非你是故意的)。
你應該盯着監控選項卡，觀察期內存和 CPU 消耗 - 這對你在步驟 4 中嘗試設置每一個引擎的用戶數量。
步驟 4 : 使用 1 個控制檯和 1 個引擎來設置每個引擎用戶的數量
現在我們可以肯定腳本能在 BlazeMeter 中完美運行了——我們需要計算出要多少用戶放到一個引擎中。
如果你能用戶沙箱中的數據來做這個決定，那就太棒了!
在這裏，我會給出一種不用回頭去查看沙箱測試數據就能計算出這個數的方法。
設置你的測試配置:
線程數: 500
產能提升：40 分鐘
迭代: 永久
時長: 50 分鐘
使用一個控制檯和一個引擎。
運行測試並(通過監視選項卡)對你的測試引擎進行監視。
如果你的引擎對於 75% 的 CPI 使用率和 85% 的內存使用率都沒有達到(一次性的峯值可以忽略) 的話:
將線程數調整到 700 在測試一次
提交線程的數量直到線程數達到 1000 或者 60% 的 CPU 或內存使用
如果你的引擎過了 75% 的 CPU 使用率或者 85% 的內存使用，一次性的峯值可以忽略 :
看看你第一次達到 75% 的點，在那個點有多少併發用戶。
在運行一次測試, 而不是提高你之前 500 個用戶數量的產能
這一次將產能提升放到真實的測試中( 5-15 分鐘是一個好的開始) 並將時長設置爲 50 分鐘。
確保整個測試過程中沒有超過 75% 的 CPU 使用率或者 85% 的內存使用率...
爲安全起見，你可以把每個引擎的線程數降低 10% 的。
步驟 5：安裝並測試集羣
我們現在知道了從一個引擎中我們得到了多少線程，在該章節的最後，我們將會知道一個集羣能給我們提供多少用戶。
一個集羣是指具有一個控制檯（僅有一個）和 0-14 個引擎的邏輯容器。
即使你可以創建一個使用超過 14 個引擎的測試案例——但實際上是創建了兩個集羣（你可以注意到控制檯的數量增加了），並且克隆了你的測試案例……
每個集羣具有最多 14 個引擎，是基於 BlazeMeter 自己本身的測試，以確保控制檯可以控制這 14 臺引擎對新建的大量數據處理的壓力。
所以在這一步驟中，我們會用步驟 4 種的測試，並且僅僅修改引擎數量，將其增加到 14。
將該測試按照最終測試的全部時長運行。當測試在運行時，打開監聽標籤，並且檢驗：
1，沒有一個引擎超過 CPU 75% 的佔有率和內存 85% 佔有率的上限；
2，定位你的控制檯標籤（你可以通過一次點擊 Logs Tab->Network Information，查看控制檯私有 IP 地址來找到它的名字）——它不應該達到 CPU75% 佔有率和內存 85% 佔有率的上限。
如果你的控制檯達到了該上限——減少引擎數量並重新運行直到控制檯在該上限之下。
在這個步驟的最後，你會發現：
每個集羣的用戶數量；
每個集羣的命中率。
查看 Aggretate Table 中的其他統計信息，並找到本地結果統計圖來獲得有關你集羣吞吐量的更多信息。
步驟 6 : 使用 Master / Slave 特性來達成你的最大 CC 目標
我們到了最後一步了。
我們知道腳本正在運行，我們也知道一個引擎可以支持多少用戶以及一個集羣可以支持多少用戶。
讓我們做一下假設：
一個引擎支持 500 用戶
一個集羣可以用戶 12 個引擎
我們的目標是 5 萬用戶測試
因此爲了完成這些，我們需要 8.3 個集羣..
我們可以用 8 個 12 臺引擎的集羣和一個 4 太引擎的集羣 - 但是像下面這樣分散負載應該會更好：
每個集羣我們用 10 臺引擎而不是 12，那麼每個集羣可以支持 10*500 = 5K 用戶並且我們需要 10 個集羣來支持 5 萬用戶。
這樣可以得到如下好處：
不用維護兩個不同的測試類型
我們可以通過簡單的複製現有集羣來增加 5K 用戶（5K 比 6K 更常見）
只要需要我們可以一直增加
現在，我們已經準備好創建最終的 5 萬用戶級別的 Master / Slave 測試了：
將測試的名稱從 "My prod test" 改爲 "My prod test - slave 1"。
我們回到步驟 5，將高級測試屬性(Advanced Test Properties)下的Standalone修改爲Slave。
按保存按鈕——現在我們有了一個Master和9個Slave中的一個。
返回你的 "My prod test -slave 1"
按複製按鈕
接下來重複步驟 1-5 直到你創建了 9 個 slave
回到你的 "My prod test -salve 9" 並按複製按鈕
將測試的名稱改爲 "My prod test -Master"
將高級測試屬性(Advanced Test Properties) 下的 Slave 改爲 Master。
檢查我們剛纔創建的所有的 Slave(My prod test -salve 1..9) 並按保存。
你的 5 萬用戶級別的 Master-Slave 測試已經準備好了。通過按 master 上的開始按鈕來運行 10 個測試，每個測試 5 千用戶。
你可以修改任意一個測試（salve或master），讓它們來自不同的區域，有不同的腳本/ csv /以及其他文件，使用不同的網絡模擬器，不同的參數等。
你可以在一個叫 “Master load results” 的 master 報告中的一個新 tab 頁中找到生成的聚合結果的報告，你還可以通過打開單個的報告來獨立的查看每一個測試結果。
·END·
程序員的成長之路
路雖遠，行則必至
本文原發於 同名微信公衆號「程序員的成長之路」，回覆「1024」你懂得，給個讚唄。
回覆 [ 520 ] 領取程序員最佳學習方式
回覆 [ 256 ] 查看 Java 程序員成長規劃