LR的几个菜鸟级问题

隐形人

1.对于录制生成的脚本，在加载用户运行后，发现测试得出的系统的响应时间巨慢，但是在脚本加载用户在CONTROLLER里运行时，我手动操作了一下，发现响应时间比ANALYSIS里得出的响应时间要快很多，这又是怎么一回事？
2.对于纯录制生成的脚本，看起来脚本很大，里面的代码行也特别的多。这些代码是不是全都是不可少的呢？比如说对于某些代码行可以删除？
3.对于一连串的操作，如欲录制的脚本要完成的操作有A,B,C，在实现A操作之后，系统会加载很多的页面组件，那么在录制过程中是不是一定要等A操作之后的所有页面组件都出现之后才实现B操作？
4.设置场景时的RUNTIME-STETING的设置原则？个人感觉在相同的脚本，相同的并发用户数，但是不同的controller的RUNTIME-STETING会导致测试结果的差异

云层

1.对于录制生成的脚本，在加载用户运行后，发现测试得出的系统的响应时间巨慢，但是在脚本加载用户在CONTROLLER里运行时，我手动操作了一下，发现响应时间比ANALYSIS里得出的响应时间要快很多，这又是怎么一回事
什么叫做加载用户运行？是在vugen里面运行么？然后你放到controller里面去运行，时间就快了？是不是这个意思，这个应该是你的运行设置中是不是设置了think time时间导致的
2.对于纯录制生成的脚本，看起来脚本很大，里面的代码行也特别的多。这些代码是不是全都是不可少的呢？比如说对于某些代码行可以删除
关于录制出来的脚本，这个首先要看你用什么方式录制的，如果你用url_basescript肯定会很多，而且确实Lr录制出来的脚本会复杂点，这个可以做删除和优化的
3.对于一连串的操作，如欲录制的脚本要完成的操作有A,B,C，在实现A操作之后，系统会加载很多的页面组件，那么在录制过程中是不是一定要等A操作之后的所有页面组件都出现之后才实现B操作
lr应该会帮你记录下来相关的操作，最好你等a操作完成后再做b
4.设置场景时的RUNTIME-STETING的设置原则？个人感觉在相同的脚本，相同的并发用户数，但是不同的controller的RUNTIME-STETING会导致测试结果的差异
runtime-setting肯定会影响测试结果，这个没什么特别的设置原则啊，你想怎么测怎么设置

隐形人

1.是把录制好的脚本放在controller里面去运行，同时手动在页面上操作相同的操作，记下手动操作时事务A的响应时间为3秒。controller里面的脚本运行完后的结果显示事务A的响应时间为10秒（事务A中没有设置思考时间），这具10秒和3秒的时间差也太多了。想问造成这么大差距的原因可能是什么，要怎么做才可以缩短这个时间差。
2和3的问题其实是同一个问题。录制生成的脚本很大的大部分原因是页面组件太大。比如说A操作完成后要实现B操作（点击一个按键C）。那么对脚本是不是可以只留下加载C组件的代码，对于和B操作不相关的组件代码是不是可以删除掉呢？
4.对于会影响测试结果的的设置想怎么测就怎么测这样的说法好像随便了吧

云层

1.收工记录的事务时间不准确，你记录的3秒并不是真正系统的相应时间，可能后台还有数据在下载
2.可以删除但是这样就没有意义了，做性能测试要模拟用户操作，你跳过了操作做出来的性能数据就不准确了
3.设置可以改变脚本的运行方式，会导致结果的变化，比如lr_think_time,run logic,pacing,browse emu等，都会直接影响到运行时的结果

隐形人

1.也许后台的确是有数据在下载，但是我做性能测试时的事务响应时间是不是一定在记下这些后台的数据下载操作呢？我是否可以这样做：可以把lr_end_transaction的位置提到这些后台的数据下载操作之前，使得这个事务的响应时间缩短，这样就可以使测试结果更短