首页 > 代码库 > Jmeter if控制器的使用 - 真正实现3:2的业务
Jmeter if控制器的使用 - 真正实现3:2的业务
一、业务分析:
两种支付方式: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控制器下。在没有瓶颈的情况下,该公式都是正确的,如果是有瓶颈,那么公式测试出来的结果不一定满足。
Jmeter if控制器的使用 - 真正实现3:2的业务