性能测试的步骤

发布: 2010-12-18 11:50 作者: webmaster 来源: 本站原创 [浏览次数:38 ]

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

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

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

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

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

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

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

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

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

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

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

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

  ......

  答案常常是否定的

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

  响应时间:根据国外的一些资料,一般操作的响应时间不能高于3~5秒

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

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

  我们的测试目的是什么?

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

  答案往往是:都要!

  根据我们的经验,开发的需求往往是这样的:

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

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

  测试准备包括测试客户端机器准备、测试数据准备、测试脚本准备。

  客户端机器:要足够,否则,如果瓶颈在客户端,就无法评估服务端。要和服务器保持网络通畅,否则,如果瓶颈在网络。

  测试数据

  如果被测功能涉及数据库和高速缓存,通常需要预设很大的数据量才能凸显性能瓶颈,这通常是挺困难的一个环节。

  如果是已经上线的应用,数据可以从线上拷贝得到;如果还没有上线,那需要构造类似于线上的数据量。

  比如,要测试群聊性能,我们首先需要注册大量用户;然后把测试用户都加入到聊天群中。

  测试数据准备的脚本,有时候比测试脚本本身还要多。

  对于实在没有办法构造大数据量的情况,我们有时候会按数据量的比例减少高速缓存,以使测试结果尽量准确。

  测试脚本

  Grinder脚本用jython实现

  测试脚本的实现往往会花费比较长的时间

  因为涉及到应用实现的细节。这也是需要了解应用架构的原因之一。

  关于sleep time

  基于真实模拟的考虑,sleep time还是尽量按照真实时间

  不过对于测试客户端来说,浪费客户端系统资源。

  Sleep time越小,客户端能模拟的吞吐量就越大 。




文章“性能测试的步骤”由 软件测试 整理发布
转载请注明 http://www.testtimes.net/html/13/n-5413.html


 

评分:0

我来说两句:


培训  课程
师资  联系我们

1694083235@QQ.Com

北京市通州区弘祥文化园A座