Loadrunner11的一些总结

性能测试的关注点：
1. 最大用户访问量
2. 最大核心业务处理量
3. 能否支持7*24h运转
4. 内存，线程等资源能否正常回收

loadrunner中并发数与迭代的区别：
1. 1个用户迭代10次，还是1个用户的压力。
2. 10个用户执行1次，就是10个用户的压力。10个用户迭代10次，还是10个用户的压力.
3. 模拟真实场景，一般不用迭代次数，而是用并发+运行时间。
参考：http://www.cnblogs.com/yunman/p/5482015.html

思考时间：
1. 如果想最大限度模拟真实场景，不要勾选忽略思考时间
2. 性能调优，需要忽略思考时间
3. 思考时间一般设置为录制时间的50%-200%比较好。
4. controller运行的时候是包含思考时间的，而analysis分析的时候默认是去掉了思考时间。所以会造成响应时间在controller和analysis的不同

关于action和事务：
我的理解是，如果是多个业务步骤，设置事务就好。
参考：http://www.51testing.com/html/43/400343-247131.html

关于集合点和并发：
1. 集合点更多的用于混合并发时，各事务的并发情况。而单一的事务没必要用集合点，因为网络延时等因素，这才是更真实的模拟场景。
2. 在VUG里设下集合点，在controller里面设置集合点释放规则
参考：http://www.cnblogs.com/Uther/p/5301958.html

并发和负载生产器：
1. 一般只有大数量并发，一台机器已经承载不了这么多数量的并发，需要用到负载生成器，即多台机器一起运行相同的脚本。
2. 新建负载生成器之后，要把所有负载生成器的状态设为ready
3. 另一台负载生产器只需启动loadrunner agent process
4. 新建负载生成器需要切换到百分比模式下，才能把新的负载生成器加入，保存成功

脚本检查：
脚本录制时的url不要写localhost，应该直接写IP地址

controller:
1. schedule by group: 每个脚本都需要各自的ramp up, ramp down,选择此模式。
2. schedule by scenario: 每个脚本的场景都相同，相同的ramp up,ramp down. 此模式也可以为各脚本设置不同的虚拟用户数，先切换到百分比模式，设置不同的百分比再切换回来即可。改变总用户数，会根据不同的百分比相应更新各个脚本加载的用户数。

Analysis:
1. Hits per second: 更准确的，应该是每秒发出的请求。
2. analysis可以右键view data, 选择导出raw data到excel，用excel的图表功能自己生成数据报表。
3. 右键合并图，能更好的分析出各个指标之间的关系
4. 在考虑运行时间的情况下，ramp up/down 越慢越好
5. 用cross with result, 可以横向比较结果。例如，不同的并发数，系统的运行情况。

检查点：
1. 检查点是用来检查脚本是否执行成功的。因为VUG是根据服务器端返回http状态200来判断脚本执行成功了。但是实际在绝大多数系统出错时会返回错误页面玛吗？ 不会，一般系统都会返回一个消息提示框，来提升用户感受。例如，“网站繁忙，请稍后”。其实这个时候网站已经无法正确响应用户请求了，但是VuGen 脚本无法识别。
2. web_reg_find的参数SaveCount是必填参数，没有赋值的话，运行会报错。

打开loadrunner自带教程webtours
1. 点击【开始】→【所有程序】→【HP Software】→【HP LoadRunner】→【Samples】→【Web】点击【Start HP Web Tours Server】启动事例网站服务;
2. 点击电脑右下角红色的X图标，右击running
3. 输入网址：http://127.0.0.1:1080/WebTours/ 或者点击【开始】→【所有程序】→【HP Software】→【HP LoadRunner】→【Samples】→【Web】点击【HP Web Tours Application】