无论是手写脚本或者录制脚本，并不能直接进行使用，需要对脚本进行加工，其加工脚本的过程和方法，在下面进行了一些介绍。当然这个过程，跟使用的工具关系不大，其思路和方法是可以借鉴的。
3.1.5.1在适当的位置插入事务、分解事务
给什么样的请求内容定义什么样的事务名称，Loadrunner中录制时插入的事务的响应时间并不一定代表“你所操作功能”的此请求真正的响应时间，需要根据请求脚本的内容进行调整和细分。调整和细分到恰当好处，可以使自己对业务进行较详细的理解，并同时对于定义响应时间在那个环节较差的问题定位也有很好的帮助，在性能调优建议方面也会有一定的启示作用。
a)、人工操作功能，注意此功能操作之后页面的加载顺序。
如：虚拟交易所登录之后，1和2号地区立即可见而3号地区经过了那么一段时间之后才加载完成。
b)、从脚本中寻找划解出来的功能代码的实际含义。
我们录制出来的代码，除掉JS、Css、JPG图片等，其请求就只有以下几个关键请求，那么怎样识别这些请求的内容和返回来的数据，成为去掉上图3号地区的关键呢？
如果经验丰富的话，使用Loadrunner的Tree视图，查看其请求和返回的信息一般就可以清楚其请求和返回的内容。推荐使用Fillder或者HTTPWatch来进行查看：
Index.asp的返回内容为：一个重定向的跳转。
Default.asp的返回内容为：从下图可知，其实登录操作的完成应该在Default.asp返回信息时已完成，而统计事务的时间却包括了其它时间的加载，显然并不能真实地反应登录这个请求的真正的时间，故脚本根据这个分析应该重新定义事务的名称。同时对于登录来说，我们插入的集合点也应该是在这个请求的前面，而不是index.aspx请求。
c) 、根据上面的分析，重新定义事务的名称以及事务所包含的请求内容。
如下面所定义的事务：登录方法、加载登录比赛信息、加载UserGuide。
d) 、根据业务信息，再次划分其操作过程的整个事务信息。
如下面所定义的事务：用户从发出登录信息到有机会进入登录比赛的时间
运行之后，我们就可以了解到对于登录至页面完全加载之后这段时间内，其主要时间受updateStudentInfo_PopWin请求的影响。
