客户端与服务器是通过什么样的协议通信的？软件的网络拓展什么样的？各个服务器的配置是什么样、宽带是多少？你选取的业务是系统处理的关键业务吗？该关键业务每天处理的数据量可能有多大？预计日峰值处理是多少？预计月峰值处理是多少？你算出来的场景启动方式和持续时间是怎么来的？你的脚本构成方式是什么样的，是否在关键点的地方进行了判断？脚本里的数据是否真实的反应了用户的数据？你的脚本排除了session部分，并保证全是Post请求吗，还是想测试用户第1 次访问时的性能？
如果我一口气连续地问这么多问题，你能有理有据地回答出来吗？如果这些问题不能有理有据地回答出来，那么你度量的性能测试结果是可信的吗？
答案是我觉得不能。这就是为什么我们大多数做出的性能测试结果，总是令人怀疑的原因。当然我也很怀疑曾经我所做出来的性能测试结果，因为，上面所提到过的问题，在我做过的性能工作中我都不能回答出来。以前的性能测试，我也只能说仅仅是例行公事的做了，但做过之后我是心虚的。
我现在坚持认为，在做性能测试之前，我们应该像福尔摩斯一样，四处侦探调查一下性能测试工作的前提条件和环境。从网上搜集的信息来看，也许我们需要做下面几方面的调查。
1、测试需求可信性调查
什么是可信的测试需求呢，前辈jackie提出了以下观点，在下深以为然，在此仅简单引用，如需了解其理论依据，请前往地址（http://www.51testing.com/html/70/n-15470.html）查看。
1.1 明确的数字，而不模糊的语句
1.2 有凭有据，合理，有实际意义
1.3 相关人员达成一致
2、测试对象调查
测试对象调查，个人觉得主要从以下几个方面去深入：
2.1 关键业务是哪些，为什么这些是关键业务？
2.2 这些业务每天处理量是多少？
2.3 峰值处理量可能是多少？
2.4 峰值访问时间是在哪个时间段？
3、测试环境调查
3.1 硬件环境
主要是服务器（中间件服务器、数据库服务器）的配置情况。收集并归纳这些服务器的配置以及性能情况，可以为以后项目的服务器度量提供参考。并且，如内存、虚拟内存、CPU、磁盘IO活动频率的初始值也是结果分析一个参照点。
如下面的测试环境CheckList：
……………………
查看全文请点击下载：http://www.51testing.com/html/13/n-806213.html
4、测试脚本调查
在脚本录制完之后，也许我们还应该反反复复问问自己下面这几个问题：
4.1 测试脚本关键处是否加入了检查点（关于检查点的重要性我想这不用做太多介绍吧）？
4.2 测试脚本是否去掉了检查点所耗费的时间？
要知道是代码都会花时间，如果你加入的代码较多，那么也许你需要利用方法从lr_wasted_time（waste）LR中去掉了时间。
4.3 测试脚本是否真实的反应了测试用例的要求？
性能测试人员业务不熟，对于测试人员给出的业务场景有时理解不到位，实现了偏位的脚本，所以性能测试人员需要跟测试人员确认这一点。
4.4 测试脚本中的数据是否真实的反应了用户实际情况的数据？
数据应尽量模拟真实场景，真实的数据往往会带来一些想不到的问题。
4.5 测试脚本定义了足够的事务，以利于分析？
我觉得原则应该是一个操作动作一个事务，但令人遗憾的是至今有些人还是几个动作一个事务。一个动作一个事务的优点是，更好分析，而缺点是要多花点时间。
……
查看全文请点击下载：http://www.51testing.com/html/13/n-806213.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
