一、業務分析：

　　　　兩種支付方式：1.銀聯刷卡支付（線下支付）、2.微信掃碼支付（線上支付），按照公司目前的交易訂單來源，銀聯刷卡支付：微信掃碼支付=3:2，所以在執行性能測試的時候，需要按照3:2的比例來測試，也就是說10條訂單，6條是刷卡支付，4條是掃碼支付。

　　二、if控制器元件：

　　　　在jmeter工具執行性能測試時，可以用if控制器元件來實現，在條件中，添加上判斷代碼，判斷代碼是針對if控制器之下的每一個可運行測試元件單獨評估的，要求所有的請求都要發到該控制器下，判斷語句才能生效，如果是同級的元件，是沒有作用的。

　　三、條件代碼設計：　　　　

　　1.用__counter該函數可以統計執行的次數。在測試的時候，我用了1個用戶，執行1秒鐘。成功請求57次：

　2.那麽業務要求3:2，57條總的數據，既要求34條數據是銀聯刷卡、23條是掃碼支付的。很多網上的代碼條件都是${__counter(true,)}%2==1||${__counter(true,)}%3==0，這個比例不對的，如下詳細解析：

　　 1. 2. 3. 4. 5. 6. 7. 8. 9. 10

滿足條件的是1.3.5.6.7.9 余4個滿足3:2

　　11. 12. 13. 14. 15. 16. 17. 18. 19. 20

滿足條件的是11.12.13.15.17.18.19 余3個不滿足3:2

　　21. 22. 23. 24. 25. 26. 27. 28. 29. 30

滿足條件的是21.23.24.25.27.28.29.30 余2不滿足3:2

　 31. 32. 33. 34. 35. 36. 37. 38. 39. 40

滿足條件的是31.33.35.36.37.39 余4個滿足3:2

　 41. 42. 43. 44. 45. 46. 47. 48. 49. 50

滿足條件的是41.42.43.45.37.48.49 余3個不滿足3:2

　 51. 52. 53. 54. 55. 56. 57. 58. 59. 60

滿足條件的是51.53.54.55.57.48.59.60 余2不滿足3:2

通過上面的數據，我們發現該條件不滿足業務的3:2需求。所以網上提供的是錯誤的。我自己寫了一個滿足條件的，如下：

${__counter(true,)}%2==1||${__counter(true,)}%10==0

　　 1. 2. 3. 4. 5. 6. 7. 8. 9. 10

滿足條件的是1.3.5.7.9 .10 余4個滿足3:2

　　11. 12. 13. 14. 15. 16. 17. 18. 19. 20

滿足條件的是11.13.15.17.19.20 余4個滿足3:2

21. 22. 23. 24. 25. 26. 27. 28. 29. 30

滿足條件的是21.23.25.27.29.30 余4個滿足3:2

後面的數據都不用舉例了，這個條件是都能滿足的。比例是3的條件已經寫好了，那麽很容易，我們也可以得出2的條件：

${__counter(true,)}%2==0&&${__counter(true,)}%10!==0

　　 1. 2. 3. 4. 5. 6. 7. 8. 9. 10

滿足條件的是2.4.6.8 余6個滿足3:2

　　11. 12. 13. 14. 15. 16. 17. 18. 19. 20

滿足條件的是12.14.16.18 余6個滿足3:2

21. 22. 23. 24. 25. 26. 27. 28. 29. 30

滿足條件的是22.24.26.28 余6個滿足3:2

　　四、執行測試：　

場景、腳本如下：

場景設置的是10VU，運行10S，執行結果總的業務量比例是3:2，TPS得比例也是3:2，如下所示：

這裏只介紹if條件的使用，整個腳本的運行，看自己的需求，我這裏都是接口的測試，前面的文章有介紹，建議在測試的時候，使用的是同一腳本，我的2個腳本都是一樣的，腳本如下：

　　五、業務測試結果：　

我的業務最終實現的結果如下3線下if控制器代表的是銀聯刷卡，2線上if控制器代表的是掃碼支付，測試的數據是3:2。請求都放到同一個線程組中，業務請求放到if控制器下。在沒有瓶頸的情況下，該公式都是正確的，如果是有瓶頸，那麽公式測試出來的結果不一定滿足。

原文地址：http://www.cnblogs.com/feng-1314/p/6808163.html

Jmeter if控制器的使用 - 真正實現3:2的業務