做性能测试时，把脚本录制下来之后，如果从头到尾只留着一整段Action，等拿到测试报告，就很难一眼看出来到底是登录的时候慢了，还是提交订单那一步卡住了。所以，搞清楚LoadRunner VuGen里的脚本该怎么去合理地拆分事务，关键就是要把一条完整的业务流程，切成好几个可以独立观察的动作。在VuGen里面，用来标记事务开始的函数叫lr_start_transaction，用来标记结束的叫lr_end_transaction，这一前一后包起来的范围里，每一步消耗的时间都会被单独记录下来。

　　一、LoadRunner VuGen脚本怎么拆分事务

　　拆分事务的时候，不要机械地照着代码行数来切，也别走向另一个极端，把每一个HTTP请求都包装成一条事务。更实用的办法，是顺着用户真正在页面上的一连串操作，还有我们最关心的那几个性能目标来拆。

　　1、先把关键的业务动作列出来

　　在动手录制之前，就可以把流程先拆成几个清晰的节点，比如：登录、打开商品列表、搜索商品、提交订单，还有查询订单。这每一个节点，恰好就能对应一条可以独立分析的事务。至于那些静态资源的加载、页面之间无关紧要的跳转，还有专门的日志上报请求，一般就用不着单独为它们去建事务了。

　　2、录制的过程中直接把事务插进去

　　当录制的脚本正在生成的时候，可以利用VuGen录制工具栏上的那个开始事务按钮，在某个操作开始前点一下，然后把事务的名字给填好；等这一步操作完成了，再去点一下旁边的结束事务按钮。这样一来，等脚本生成出来，相应的开始和结束函数就已经自动出现在代码里了。

　　3、录完以后再用手工把事务补上

　　已经录好的脚本，事后也是能往里补事务的。在编辑器里头，先把光标挪到想加事务的那个目标请求的前面，然后顺着【Design】里的菜单，找到【Insert in Script】，再点一下【Start Transaction】；接着，再把光标挪到这一组目标请求的尾巴上，用同样的办法去选一下【End Transaction】。这里要特别留心，开始和结束的地方，必须用同一个事务名称，不然报告那边就没有办法替我们把耗时给正确地归拢到一起。

　　4、统一事务的命名规矩

　　给事务起名字的时候，最好能带上顺序号还有具体的动作，比如“TR01_Login”，表示登录，“TR02_SearchProduct”就是搜索商品，再比如“TR03_SubmitOrder”对应提交订单。千万不要用test1、step2这种模糊的叫法。等脚本一多，在Controller执行和分析报告里面，会一下子冒出密密麻麻的事务名字，只有当初把名字起清楚了，后面才能很快地找出要找的那条。

　　二、LoadRunner VuGen事务边界放错会带来什么影响

　　事务的边界放在哪里，直接决定了响应时间统计出来的那个范围。边界一旦放错了，脚本回放也许照样能成功，可报表里面算出来的那些数字，就已经没法再准确地反映业务的真实性能了。

　　1、开始的位置太早，会把准备动作也给算了进去

　　就拿查询订单来说，本来只需要统计从点击查询按钮，到结果返回的这一段时间，如果把前面的登录校验、页面的初始化，还有下拉框的加载时间，都一起包进了这个事务里，那最后看到的响应时间就会偏高。分析的人一看这个数字，很可能就误以为是查询接口本身慢，可真正的瓶颈，其实是出在了前面的那几个请求上。

　　2、结束的位置太晚，就会把后面的请求也混进来

　　当提交订单这个动作已经完成了，如果事务没有及时地结束，紧接着又继续去执行订单列表的刷新、做埋点数据的上报，还有页面的跳转，那么报告里面记录的提交耗时，就会被拖得很长，性能问题看起来好像被放大了，而且这个数据也很难和服务器端的处理日志准确地对上。

　　3、把等待的思考时间一块儿包了进去

　　脚本里面很可能会包含一段表示用户停顿思考的时间。最终统计事务响应时间的时候，到底要不要把这段思考时间给排除掉，得看我们运行时的设置。一旦相关的设置，在不同的测试轮次里不一致，那么同一条事务在这些轮次里得到的响应时间，就不适合直接拿来做比较了。

　　4、漏掉了结束函数，统计就会出乱子

　　一条事务只有开始，却没有对应的结束，或者开始和结束用的名字不一致，系统就没办法得到一条完整的耗时信息。官方对这两个函数的说明，也明确提出来，要在目标操作的前后，分别把开始和结束给放好。

　　三、LoadRunner VuGen事务拆分后怎么复核

　　事务拆分这件事干完之后，可别直接就向被测系统丢一个高并发的场景。稳妥的路子，是先让脚本在VuGen里面单跑一次回放看看，接着再到Controller执行和分析报告里面，去核实一下拿到的数据，是不是真的符合业务上的逻辑。

　　1、单用户回放一遍

　　回放的时候，把详细日志打开，挨个确认每一条事务都有明确的开始、结束和通过的标记。要是碰到了登录失败、关联的那些参数报错，或者检查点没通过这类情况，就不要再继续往压力场景里跑了，否则统计上来的，只不过是一堆错误页面的响应时间而已。

　　2、看一看事务响应时间的曲线图

　　等到正式执行完场景之后，可以去翻一翻事务监控图，这类图会把每一条事务的响应时间和它的处理速率都给展示出来，很适合用来观察某一个具体的业务动作，在系统负载被加上去以后，是不是开始变慢了。

　　3、结合系统处理的请求量一起判断

　　当发现某一条事务的响应时间突然飙高时，还要去对照着看一看每秒钟系统的点击量、吞吐量，还有同时跑着的用户数是什么水平。官方的分析手册也建议，要把响应时间的图，跟其他几项指标的图关联起来看，这样才能判断，负载的变化是不是真的影响到了这条事务的性能。

　　4、边界固定下来以后再做趋势上的对比

　　同一个项目后面的复测，千万不能随随便便就去改变事务的范围，边界一旦变了点，历史的曲线也就跟着失去了可比的意义。如果因为业务变更，真的不得不去调整，那就把旧的事务名字保存下来，同时留下变更的记录，然后再去重新建立一条新的基线。

　　总结

　　总而言之，LoadRunner VuGen里的脚本怎么去拆分事务，比较建议的做法是按照用户真实的业务动作，来建立起事务的边界，可以在录制的时候就插入事务，也可以在录制完之后通过设计菜单里的插入选项去把它补上。而LoadRunner VuGen事务边界一旦放错，带来的影响，主要就是响应时间的数值被算得偏高、统计的请求范围乱掉了、等待时间被错误地计了进去，还有事务统计信息直接缺失。只要能把事务拆得明明白白，后面再想去看究竟是哪一步拖慢了速度，做性能优化的时候，也才不至于把力气使错地方。