加事物目的:就是为了分析测试结果。想分析谁就给谁加事物,事物是从技术层面为了统计数据看结果分析而加的一个技术判断
事物不能跨action。不能跨函数
如打开首页花多长时间?提交帖子花多长时间?登录花多长时间?:我们需要加个计时器来统计时间,只是在lr中不叫计时器,叫事物
脚本加不加事物对系统的功能业务没什么影响、对系统的性能也没什么影响、对服务器没影响。所以你的脚本失败了和事物是没关系的。
1、手动事务
提交帖子花费的时间,我就要在提交帖子前面添加一个事物,开始事物
提交完后加一个-结束事物
事物的状态包括AUTO自动的,其实我们有3个状态,pass,意思是事物通过了;Fall是事物失败了;stop是事物意外终止了。AUTO的意思是,它会自动去判断事物的状态,来产生这三种结果(pass、fall、stop)。
接下来我们来回放一下这个脚本。从日志中我们可以看到事物提交的状态是Pass,已pass状态介绍,用时:0.5018s 浪费0.0200s
一个烂的系统一般是压不死服务器的。压不死意味着CPU很闲,CPU很闲意味着没事干,说明吞吐量上不去。无论你怎么压也是百分之2、3,会出现超时timeout。
我的事物可大可小,一个事物可包含多个业务。也可只包括一个业务。
2、自动事物
事物大的时候我们很难去定位是谁的问题。
我们可以把每个请求设置成一个事物,这样事物量可能很大,但是能方便我们去分析。脚本一跑,我就能很清晰的看出每个步骤花了多长时间。
1)把每个请求设置成一个事物的话,就没必要一个个手动添加,可以在lr中设置自动事物。
做事物最好把每个步骤作为一个事物,这样看报告的时候更容易看明白
备注:一旦你把每个步骤作为一个事物的时候,事物的名字非常重要,最好和你的业务流程名称保持一致,这样你就知道你的事物是哪个业务的事物。所以前面我们说业务名字一定要修改,且要起的有意义。
2)把每个Action做为一个事物,会产生5个事物,事物比较大。
把每个步骤做为一个步骤请求做为一个事物,每个web_url、web_subtic都是一个事物,产生的事物会很多。
如果在controller中回放脚本时,没事物,最后结果有好多图是出不来的,比如响应时间,响应时间是事物响应时间,还有吞吐量,没有事物哪来吞吐量。
如果问你,登录这个业务花了多长时间?你怎么回答。
登录、刷新加起来看看多长时间吗?你可以去问问他说的这个业务都包括什么,然后在我们知道每个业务花的时间的情况下,把他说的加一下就可以了。