性能场景之发起策略二

2018-03-09   出处:7DGroup  作/译者: 高楼(Zee)  

昨天写的那个发起策略是对单个业务来说的。

每次在做项目和做培训的时候,我都说起过,要先做基准测试。

之前我看到有人把基准测试定义为脚本的基本验证。从概念上说,这种描述是完全错误的。这个问题可以留待后面再展开来说明。


对于多业务脚本混合的场景来说,每个业务脚本的设置就成了必然要考虑的事情。

所以在这之前需要的是对单个业务特点进行分析,分析到可以设置出符合真实业务场景为止。这一点非常关键,非常关键。 如果做不到和真实业务场景符合的话,性能测试分析优化的整个过程也仅是查查系统的代码问题、环境问题、配置问题、数据问题、架构问题等等。

有人说,这样已经足够了呀。

可是,性能项目的实施仅仅是为了找问题吗?即使找出问题,能让系统支撑得住真实业务场景吗?这个问题是大部分做性能测试的人不敢回答的。

所以场景设计的重要点在于可以把真实业务场景重现出来,进而分析系统容量是否满足业务要求。


混合场景在不同的工具中有不同的设置方法。

对于LoadRunner来说,在设计思路上,它对场景的设定是全局的。有种所有业务都由我掌控的感觉,就是很霸道的全局设置思路,每个业务脚本可自己发挥的空间。

我是很认可这种设计思路的,就是对整个场景要有明确的掌控感。

只是缺乏灵活性。

还好在LoadRunner中有Group可以弥补这个灵活性的欠缺。

对Jmeter来说,各个设置都是松散的,线程组的设置也都是单独的,想怎么玩怎么玩。

所以对混合的场景设置来说,Jmeter这样的工具才是对个人素质要求更高的。

像上图中所展示的,每个线程组可以有不同的发起、持续、停止策略。


不管工具上如何设置,最核心的内容还是如何把真实场景复现出来,而这一点是工具不可能告诉你的。不管是现在的云性能测试工具还是单独的性能测试工具,在这些内容的深化上都存在着很大的发展空间。

性能测试之所以人在其中的作用很大,也就是在这些灵活的部分。

之前我看到有些自研发的工具中给一个简单的脚本,即可以发出上万上亿的请求,并且称之为场景。那是非常片面的一种场景,或者说目标不是复现真实业务场景。


后面再写具体的业务场景到性能测试工具场景的转化过程。


在细节的控制中才见真功夫。

性能是一门艺术。


欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
163°|1635 人阅读|0 条评论

登录 后发表评论
最新文章