一、事件背景
個人感覺自己做效能測試，可以說是輕車熟路了，而且工作多年一直都是這一套測試思路及體系，從未質疑過自己，也許是獅子座的迷之自信吧！
也就在上週讓我對自己的測試方法及體系產生了質疑！
為什麼？在效能測試的時候，壓測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、關於公式
圖片來源於網路，侵刪
三、寫在最後
真的是，活到老，學到老，遇到問題，多總結，多分析就好，技術需要嚴謹，不定期覆盤。感興趣的同學，可以自己動手嘗試下。