qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

软件测试之性能测试浅谈

性能测试种类的划分与定义这里就不说了,各有各的说法,比如性能测试、负载测试、压力测试这三个词,在网上能找到N个版本的定义,大体理解就行了,没必要在文字层面上较这个真。以下的内容也只是我个人的理解,一些名词的定义可能和其他资料有所不同,但在我的工作中,这样是比较形象和容易理解的。

  性能测试的目的,简单说其实就是为了获取待测系统的响应时间、吞吐量、稳定性、容量等信息。而发现一些具体的性能相关的缺陷(如内存溢出、并发处理等问题),我认为只是一种附加结果。从更高的层次来说,性能测试最想发现的,是瓶颈。

  在实际工作,一般的应用系统会从这么几个方面进行性能测试。

  1、基准测试

  Benchmark或者Baseline测试。一般为单用户测试,或者是零数据量环境下的测试。目的在于建立一个可度量的参考标准,为其他测试场景或者调优过程提供对比参考。也可认为是最基础的性能测试,如果基准测试的结果都不能达到预期要求,那么后续场景也就没必要测试了。

  2、日常压力测试

  在基准测试通过后,应该先进行较小压力下的测试,首先对系统在日常压力下的表现进行测试。此压力需要根据系统使用相关数据得出,如系统平均每天访问量、平均在线人数、每日完成事务数等。通过此测试,发现一些较表面的性能问题并进行处理。

  3、峰值压力测试

  在日常压力测试通过后,需要进行更大压力的测试。此处压力同样需要相关数据的支持,一般为未来几年后的预期压力。可根据历史日均压力、日最高压力等信息,估算出未来几年的日均以及日最高压力。再通过一些通用估算方法、如二八原则(80%的工作在20%时间内完成,相当于2小时完成一天8小时的工作量),将日压力转换成峰值压力。

  峰值压力为可预期到的最大负载压力,通过了此测试,则认为系统有能力满足未来增长的压力。

  4、容量测试

  验证了系统是否可满足预期的压力后,还需要知道系统能够承受的最大压力,也就是容量。一般通过“拐点法”进行测试,逐步增大系统的压力,直到性能指标不可接受或者出现了明显的拐点。如图:

  5、稳定性测试

  验证系统是否可长期稳定的运行,是否存在一些短时间内可能无法发现的缺陷(如内存溢出、数据库连接不释放等)。为了缩短测试工期,一般可将预期一天的压力集中在2小时内完成(二八原则),这样持续加压10小时,便相当于系统运行5天。注意监控各种性能指标是否平稳,有无下降。

  以上几种类型的测试,是性能测试过程中最多用到的。当然也也其他一些比较常用的类型,如绝对并发测试,测试多用户对某一功能的瞬时请求,主要用于验证系统是否存在并发逻辑上的处理问题。此测试也可划分到不同的压力测试场景中去,根据不同的用户压力,测试相应的绝对并发,一般取在线用户数的10%进行测试;突发压力测试,对一些不在预期内的突然压力进行测试(其实既然想到了,就应该是在预期内了)。以银行门户网站为例,可能会由于发布了一条重要消息(政策调整)而导致访问量激增,这种压力是否会导致系统宕机或者暂时无法提供服务,就是突发压力测试需要考虑的了。也有人将此压力定义为峰值压力,这就无所谓了,只要考虑到会有这么一个问题就够了。

posted on 2013-01-05 13:36 顺其自然EVO 阅读(264) 评论(0)  编辑  收藏 所属分类: 性能测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年1月>
303112345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜