对于性能测试，经过1年学习，从开始的理论学习，到项目实践，个人觉得做基于WEB的性能测试结果会受到很多因素的影响。本人性能测试的所用的工具是LoadRuner 9.5。下面都是基于这款工具来谈的。

　　硬件环境：

　　1. 服务器

　　2. 负载机

　　3. 交换机和网线

　　4. 人

　　软件环境：

　　1. 网络

　　2. 测试脚本

　　3. 场景设计

　　4. 场景执行

　　系统基础数据：

　　1. 测试数据

　　故总结如下：

　　测试环境：包括硬件、软件、网络、测试脚本、场景设计、场景执行、系统基础数据、测试数据。

　　注：测试脚本、场景设计、场景执行 应该以性能测试需求为准则展开执行。

　　下面详细分解：

　　硬件环境：

　　1. 服务器

　　硬件配制要尽量接近真实环境。如果你们项目运行的服务器硬件成了瓶颈，好将WEB服务器与数据库服务器分开部署。这样才能定位问题。

　　2. 负载机

　　测试机的配制也要好，在场景执行时，负载机好选择已经安装了负载程序（LR中的一个插件）的负载机，好不要使用localhost。当然如果你的个人机器配制很高的话，另当别论。负载机主要任务是创建诺干线程或进程来执行脚本，来达到模拟虚拟用户的目的。一般一台负载机开100到300个线程可以了，不要再增大。如何你的测试场景虚拟用户达到1000至10000.那你要多准备几台负载机。

　　3. 交换机和网线

　　一般我们的性能测试都是在局域网中进行，相信没有谁会在共网上进行，嘿嘿！

　　有些项目性能测试的网络吞吐量相当大，100兆的交换机有时会成为测试瓶颈（在这上面我吃过很大亏哟），总之，测试环境应该在1000兆交换机下进行才好。

　　4. 人

　　嘿嘿，我开个小玩笑，人这个硬件也是关键的。

　　A. 理论一定要过关

　　B. 测试过程中一定要保证瓶颈出在我们的程序，如果是出在其它地方，而你却出报告说：程序有问题，开发人员会骂你的。

　　C.对整个过程进行测试有效性分析，测试的过程都无效，结论不用提交了。

　　软件环境：

　　●       数据库配制

　　●       数据库连接池配制

　　●       Web服务器配制

　　●       JVM与GC配制

　　●       本身项目配制

　　软件环境重在是配制，配制需要注意的地方是个大学问哟。

　　网络

　　网络注意的地方在上面的交换机那块已经谈到，另外在加一句，测试环境（网络）好独立。

　　测试脚本

　　测试脚本主要注意：A、选择系统常用的功能进行录制脚本、不要遍地开花，其实一个系统需要真正录制脚本的地方没有几处。B、测试脚本的有效性，测试数据要尽量接近真实。不要认为执行没有出错，我这个脚本算成功了。执行一次后，要确定的确对服务器产生了影响，才算成功。

　　该参数化的地方一定要参数化，还有什么关联、检查点，日志、思考时间、步进、IE缓存、连接超时、下载超时 等等设置。

　　注意：

　　在调试时，日志开启。调试通过后进行场景执行之前把日志去掉，因为日志会影响LR本身执行脚本的效率。

　　“思考时间”、“步进” 该加一定要加，不然对服务器的压务太大，也不符合真实情况，达不到测试效果。

　　场景设计

　　场景的设计是不好把握的，单场景、组合场景、加压、持续时间（注意与迭代的关系）、集合点的释放原则、需不需要进行IP欺骗，负载机需要几台（根据上面的负载机解释进行准备吧）等都需要注意。

　　场景执行

　　场景执行当然很简单了，点一下按钮行了，嘿嘿。重在执行时，对测试的监控。监控时也可以反应此次测试是否有效。总之，测试的有效性分析贯穿整个测试流程。

　　特别说明，不要为了监控而去监控。那会花费很多精力，并且还得不偿失。

　　例如：我的web服务器有8G的内存，我现在做10个用户并发登陆，在这个过程中我去监控内存的使用情况，这是不是有点多余呢。那我们什么时候进行监控，该监控什么对象呢！

　　一句话，要有怀疑精神，你估计什么地方出现问题了，大胆的进监控吧！并不是监控越多越好，监控本身也会消耗很多资源，会很大的程度上影响测试结果。

　　例如我们公司开发的项目主要是基于JAVA，在测试时，发现程序代码有问题而导致内存泄漏，于是用Jrofiler进web服务器进行监控，这时我做性能测试，发现什么操作都很慢。解决问题后，不要Jrofiler进行监控，操作都是相当快的。

　　系统基础数据：

　　一般基于web的服务的用户数都具有不确定因素。数据量往往是比较。如果数据库的设计、SQL语句、数据库配制等等有缺陷，在系统数据量很少的情况下进行性能测试，这些问题将无法暴露，系统基础数据好准备该系统正式上线后大概的数据量。

　　测试数据

　　测试的数据要尽量接近真实数据。