一、業務分析：
兩種支付方式：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控制器下。在沒有瓶頸的情況下，該公式都是正確的，如果是有瓶頸，那么公式測試出來的結果不一定滿足。
