性能测试步骤(一)??熟悉应用

　　这是整个性能过程关键的步骤之一，毋庸质疑。

　　我们必须了解：应用的架构

　　以我熟悉的应用类型为例。了解了应用架构，我们才能知道，我们需要模拟的是：一般的html静态文件请求、一般的servlet和jsp请求、AJAX请求、还是远程调用请求等。

　　我们必须了解：应用的功能逻辑

　　性能测试步骤(二)??测试需求

　　我们得到的测试需求往往是这么描述的：这个系统能否支撑100万的uv(每天登录系统的人次)。

　　言下之意是：按照目前的硬件性能和数量，系统能否支撑100万的uv。

　　然而，我们了解的是吞吐量、响应时间等指标

　　吞吐量：系统每秒能处理的请求数，这个指标从服务器的视角，表征系统容量

　　响应时间：从请求发出到第一个字节返回所需要的时间，这个指标从用户的视角，表征系统响应速度。

　　那么，请问开发同事：能把测试需求转化成我们熟悉的吞吐量和响应时间吗?

　　......

　　答案常常是否定的

　　怎么办：只能由我们根据经验，把100万uv转化成一系列的指标。

　　响应时间：根据国外的一些资料，一般操作的响应时间不能高于3~5秒;重要操作，如结账操作的响应时间不能高于15秒。

　　吞吐量：可以根据已经上线的类似产品进行估计。或者，采用80/20原则进行估计。我们经常使用的是80/20原则。

　　虽然已经有了响应时间和吞吐量指标，但是测试需求还是不明确的。

　　我们的测试目的是什么?

　　是验证当前硬件和软件配置能否支撑100万uv?是测试当前的硬件和软件配置多能支撑多少uv?是帮助开发寻找性能瓶颈?

　　答案往往是：都要!

　　根据我们的经验，开发的需求往往是这样的(当然开发一般不会说得那么详细，^_^)：

　　首先，请你们验证能否支撑100万uv。如果不能支撑，请找一下性能瓶颈。主要性能瓶颈解决后，请估计能支撑多少uv，如果不到100w，请估计要加多少机器。如果能支撑100万，请再加压，看看达到300万uv的时候，系统的性能。这么一细化，需求基本明确了。

　　性能测试步骤(三)??测试准备