一、业务分析：
两种支付方式：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控制器下。在没有瓶颈的情况下，该公式都是正确的，如果是有瓶颈，那么公式测试出来的结果不一定满足。
