性能测试是一件非常严谨的事情，就像我以前写过的一样，很多用户的=性能测试的问题在于测试本身。以下列举几条LoadRunner测试Web的常见问题。
网络带宽问题
对Web进行压力测试时，通常百兆网络是不够的，当网络带宽不够的时候server端没有足够压力。用LoadRunner所在的Windows的性能管理器看一下网络利用率就知道了。
Vuser脚本的检查虽然Loadrunner提供了方便的脚本录制功能，但由于录制时可能出现的操作偏差，也应手工检查生成的Vuser脚本。去除某些与压力测试无关的东西。否则可能会出现Loadrunner测试结果有误或压力上不去的情况（比如vuser访问一些不存在的资源）。
在创建Loadrunner scenario时，每台机器的vuser的runtime setting都应该分别设置并检查，不能只对第一个vuser的runtime setting进行设置。通常你会关掉think time，以便能用较少的机器达到较大的压力。另外，如果返回页面里包含了一些访问 其它资源的链接比如图片服务器，这时应关掉 download non-html resources。
没有检查返回页面当server端出错时应用程序有可能返回错误信息，但对HTTP来讲仍是成功的响应，返回码为200 O.K. 这样在Loadrunner就被记为成功的transaction。于是，server端出错越多，Loadrunner测出的性能越好。解决办法：开启并检查应用的错误nt, '%C8%D5%D6%BE');" 日志；或者启用Loadrunner的返回内容检查功能。
当心Loadrunner所在机器的磁盘空间缺省情况下Loadrunner会把运行结果的详细信息放在C盘的Documment and Settings的用户目录下，当大压力长时间运行或有大量出错时，Loadrunner会生成大量的数据到该目录下。当磁盘空间满了后，机器的响应将变得很慢。
结语还是那句话，性能测试是一件非常严谨的事情。本身在实验室里的性能测试就很难模拟真实情况，另外世界上没有两个一模一样的系统，要做到apple-apple的比较很难。 所以做性能测试一定要仔细，测试条件一定要定义清楚。否则，最后的结果是：上了生产系统后被最终客户折磨地吃不下饭睡不着觉。这不是开玩笑，我在别人那里见过了太多的这种情况。
