一、事件背景
個人感覺自己做性能測試，可以說是輕車熟路了，而且工作多年一直都是這一套測試思路及體系，從未質疑過自己，也許是獅子座的迷之自信吧！
也就在上週讓我對自己的測試方法及體系產生了質疑！
爲什麼？在性能測試的時候，壓測500併發通過，人家40併發都過不去。
通俗點說，就是你測試沒問題，在人家那測試出問題了，忽略腳本問題，顯而易見因爲測試方法差異導致測試結果的不同。
1、關於執行方法的差異
- 同事的做法是直接跑10分鐘的穩定性測試，然後上併發數；
- 我的做法一個用戶循環訪問一次，然後上併發數；
2、關於執行結果的差異
- 同事這種方式比我的方式，對目標服務器的壓力更大；
- 體現在哪，如果循環次數選擇了一旦選擇了永遠，即請求次數會比我的方式多，所以自然壓力也大；
3、真的是我測試方法錯了嗎
我和同事分別測試兩個系統，具體還是有些區別的：
- 同事這邊業務場景有40個接口，執行一次最多1分鐘，要不就是20秒，具體沒記清楚；
- 我這邊的業務場景有76個接口，執行一次大約50分鐘，如果我直接上負載測試10分鐘，根本跑不完一組業務場景；
- 我去請教大周老師，老師說正常先要讓跑一定的時間，可以查看是否穩定運行及測試結果是否一致準確，性能測試本就是多次測試的結果。
4、結論
我是在最後跑的穩定性測試，是8小時起步，從時間上看覆蓋到了他的十分鐘，而且壓力更大。
但是，有些同學會問他測試的對嗎，他的思路是對的，因爲他執行一次業務場景，小於10分鐘，在小批量併發測試師沒問題的。
當然，如果併發量上來後，還是設置十分鐘的話，會出現我那種情況 業務場景接口沒執行完的情況，此處，大家自行嘗試見分曉。
二、關於線程組的相關設置
我又去查了大量資料，終於找到了一篇我覺得比較在理的文章，並舉例給大家演示，我覺得這個同學的理論好像是對的，因爲我也測試了下，發現也吻合我的測試結果（算求生存嗎？）！
下面我將舉例說明，該方法。
1、執行第一次數據採樣，得到吞吐率和平均響應時間
由圖可知：
吞吐率=2.6≈3,平均響應時間：t=0.386秒；
2、計算ramp-up period
假設線程N=10，估計的吞吐率=3， 那麼估計的理想ramp-up period (T)（可以理解爲線程啓動的準備時間）= 10/3 = 3 秒。
3、循環次數計算
現在計算循環次數A。由於我們要考慮在第一個線程結束的時候，確保最後一個線程能啓動，那麼至少要大於一個值，這個值定位S=T-T/N=3-3/10=2.7。
當時間到 S=（T-T/N）時，最後一個線程啓動，若要使所有線程同時運作，則需要在最後一個線程啓動的時候第一個線程仍未關閉，爲達到這個要求，需滿足A > S/t
A>2.7/0.386=6.994≈7次 A>(T-T/N)/t
4、得出的測試方案
那麼我們的測試方案如下：
5、關於公式
圖片來源於網絡，侵刪
三、寫在最後
真的是，活到老，學到老，遇到問題，多總結，多分析就好，技術需要嚴謹，不定期覆盤。感興趣的同學，可以自己動手嘗試下。