加事物目的：就是为了分析测试结果。想分析谁就给谁加事物，事物是从技术层面为了统计数据看结果分析而加的一个技术判断
事物不能跨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中回放脚本时，没事物，最后结果有好多图是出不来的，比如响应时间，响应时间是事物响应时间，还有吞吐量，没有事物哪来吞吐量。
如果问你，登录这个业务花了多长时间？你怎么回答。
登录、刷新加起来看看多长时间吗？你可以去问问他说的这个业务都包括什么，然后在我们知道每个业务花的时间的情况下，把他说的加一下就可以了。