一、事件背景

個人感覺自己做性能測試，可以說是輕車熟路了，而且工作多年一直都是這一套測試思路及體系，從未質(zhì)疑過自己，也許是獅子座的迷之自信吧！

也就在上周讓我對自己的測試方法及體系產(chǎn)生了質(zhì)疑！

為什么？在性能測試的時候，壓測500并發(fā)通過，人家40并發(fā)都過不去。

通俗點說，就是你測試沒問題，在人家那測試出問題了，忽略腳本問題，顯而易見因為測試方法差異導致測試結(jié)果的不同。

1、關(guān)于執(zhí)行方法的差異

• 同事的做法是直接跑10分鐘的穩(wěn)定性測試，然后上并發(fā)數(shù)；
• 我的做法一個用戶循環(huán)訪問一次，然后上并發(fā)數(shù)；

2、關(guān)于執(zhí)行結(jié)果的差異

• 同事這種方式比我的方式，對目標服務器的壓力更大；
• 體現(xiàn)在哪，如果循環(huán)次數(shù)選擇了一旦選擇了永遠，即請求次數(shù)會比我的方式多，所以自然壓力也大；

3、真的是我測試方法錯了嗎

我和同事分別測試兩個系統(tǒng)，具體還是有些區(qū)別的：

• 同事這邊業(yè)務場景有40個接口，執(zhí)行一次最多1分鐘，要不就是20秒，具體沒記清楚；
• 我這邊的業(yè)務場景有76個接口，執(zhí)行一次大約50分鐘，如果我直接上負載測試10分鐘，根本跑不完一組業(yè)務場景；
• 我去請教大周老師，老師說正常先要讓跑一定的時間，可以查看是否穩(wěn)定運行及測試結(jié)果是否一致準確，性能測試本就是多次測試的結(jié)果。

4、結(jié)論

我是在最后跑的穩(wěn)定性測試，是8小時起步，從時間上看覆蓋到了他的十分鐘，而且壓力更大。

但是，有些同學會問他測試的對嗎，他的思路是對的，因為他執(zhí)行一次業(yè)務場景，小于10分鐘，在小批量并發(fā)測試師沒問題的。

當然，如果并發(fā)量上來后，還是設置十分鐘的話，會出現(xiàn)我那種情況 業(yè)務場景接口沒執(zhí)行完的情況，此處，大家自行嘗試見分曉。

二、關(guān)于線程組的相關(guān)設置

我又去查了大量資料，終于找到了一篇我覺得比較在理的文章，并舉例給大家演示，我覺得這個同學的理論好像是對的，因為我也測試了下，發(fā)現(xiàn)也吻合我的測試結(jié)果（算求生存嗎？）！
下面我將舉例說明，該方法。

1、執(zhí)行第一次數(shù)據(jù)采樣，得到吞吐率和平均響應時間

由圖可知：

吞吐率=2.6≈3,平均響應時間：t=0.386秒；

2、計算ramp-up period

假設線程N=10，估計的吞吐率=3， 那么估計的理想ramp-up period (T)（可以理解為線程啟動的準備時間）= 10/3 = 3 秒。

3、循環(huán)次數(shù)計算

現(xiàn)在計算循環(huán)次數(shù)A。由于我們要考慮在第一個線程結(jié)束的時候，確保最后一個線程能啟動，那么至少要大于一個值，這個值定位S=T-T/N=3-3/10=2.7。

當時間到 S=（T-T/N）時，最后一個線程啟動，若要使所有線程同時運作，則需要在最后一個線程啟動的時候第一個線程仍未關(guān)閉，為達到這個要求，需滿足A > S/t
A>2.7/0.386=6.994≈7次 A>(T-T/N)/t

4、得出的測試方案

那么我們的測試方案如下：

5、關(guān)于公式

到此這篇關(guān)于詳解Jmeter線程組的設置方法的文章就介紹到這了,更多相關(guān)Jmeter線程組設置內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論