1、log的设置方式 。
在 runtime setting中可以设置log的生成方式：
默认的log方式：
Enable logging选中，log option是Send messages only when an error occurs.
可以修改日志的方式：
Always send messages（这种方式会一直打印输出日志，不仅在错误时）
standard log——记录所有的请求反馈的日志，包括successful和fail的日志。
Extended log——可提供扩展的日志信息，包括
Parameter subsititution——日志中打印所有中使用的参数值。
Data returned by server——日志中打印每个客户端请求服务器返回的数据值
Advanced trace——日志中打印所有的消息信息和函数执行信息
2、log的存储方式
log的存储路径在res文件夹下。
如果是从脚本中直接关联create scenario则在脚本的目录下的res下。如果是直接create
scenario然后再选择脚本的话，则存储在c盘，如“C:Documents and SettingsUSERNAMELocal
SettingsTemp
eslog”
具体该场景的日志结果存哪，可以查看controll的result界面的result setting定义的目录。
根据不同的log记录级别，在log文件中记录日志。
3、log信息的分析
1）从log中得到虚拟用户失败的原因。
通常如果场景在运行时出现用户失败，则先要查看错误原因，可直接查看日志，从日志中查看ERROR的信息；
从outputdb中可以查看到错误代码ERROR CODE
2）从日志中确认每次分配给虚拟用户的参数值
想判断是否在场景中每个用户使用不同的或预定义规则的参数，可以通过在log生成规则处设定为parameter
subsititution，然后查看每个日志文件中的对应行参数值是否为预计的参数值。可从此判断出是否同用户的实际使用类似，是否达到对服务器的压力
策略。
3）从日志中确认服务器端返回的值是什么。
在脚本中通常设定了检查点，检查点策略是否生效，如果对此产生怀疑则可以考虑从日志中查看一下。查看服务器返回的值来验证是不是所期待得到的值。
思考问题
log的输出 会不会影响到客户端，会不会使客户端成为瓶颈？（认为是会的，任何程序都是要消耗资源的，loadrunner也一样，所以选取日志输出的模式是要谨慎考虑尽量以适用为前提）