关于性能测试需要重视的两个要点

发表于:2020-8-26 10:23

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:张逸    来源:51CTO

分享:
  性能测试已经是一个老生常谈的话题了,不同的项目或多或少都会涉及到,但是每个人的经验肯定有所不同。今天我想从两个方面分享一下我认为关于性能测试需要重视的要点。
  一、性能测试的需求
  1. 看似很明确的需求
  当问到性能测试的需求,我们的客户有时候会回答,“我们要支持20000个用户同时在线”,或者“每天有10000个用户同时访问这个网站”,更有甚者“我们也不知道,越多越好吧”。这种情况下我们应该怎么办呢?
  当用户说“我们有10000个用户同时访问这个网站”的时候,看似我们的需求已经很“明确”了。真的很明确了吗?就拿这个例子来说,这10000个用户都在干什么呢?假想下,可能有5000个用户在浏览静态页面,2000个在创建表单,1000个在做查询,还有... 真正产生压力的用户是谁呢?这恐怕不能单单从10000个用户同时访问这个网站得到结果。
  之前做过一个项目,客户为某机场,他们为用户提供免费的WiFi服务,但是提供在WiFi的同时,会在不同的页面播放广告。后台有一个广告管理系统,可以做一些配置,根据优先级来投放广告。这其中涉及到一些复杂的算法,主要是投放广告的比例。当然机场还有很多物料服务器,主要是用来存放广告的图片等等。当时用户给的性能需求也就一句话,“我们每天大概有xxxxxx个用户连接我们的WiFi”。那怎样来做性能测试呢?
  “多少个用户连接WiFi”其实只是一个最表面的现象,在连接WiFi的同时,其实系统做了很多事情。首先连接WiFi的时候会去访问分发服务器,确定要播放哪几个广告,其次会根据分发的广告,去物料服务器上找相应的资源,然后打点把广告访问的历史数据记录数据库中。这是能联想到的一些最基本的后台操作,每一个行为都有可能成为一个瓶颈,都需要去认真考虑。
  所以在考虑性能需求的时候,一定要清楚背后的逻辑是什么,同时需要分析用户活动,从而确认系统的性能测试目标。
  2. 历史数据
  “性能现在的需求也不是很明确,但我们有原来的老系统,能帮我们看下吗?”
  对于性能测试来说,如果有很详细的历史数据,这将是一个非常珍贵的数据源,我们可以从中分析出很详细用户行为。之前我们做过一个项目,性能测试的需求基本上就是从历史数据中得到的。我们对数据库进行了很详细的分析,从而设计性能测试用例,这其中主要包含系统的哪些service承受了压力、压力是多大、用户量是多大等等。
  需要特别注意的是,如果对于业务的了解不够深,很容易导致场景的设计缺失,从而导致测试的场景和实际的场景有所偏差。比如分析某张表,分析出系统有10000个插卡拔卡记录,有的人可能直接就开始写脚本了,模拟一个用户每天做10000次插卡拔卡的操作。殊不知,这10000次插卡和拔卡的操作是4000个用户完成的...而性能的瓶颈很有可能就在用户的管理,而不是插卡拔卡产生的压力。
  所以建议在做历史数据分析的时候,一定尽量把场景分析全面,并且需要去了解真正的业务,才可以尽量减少分析的错误。
  3. 不明确的需求
  “我们也不知道需求是什么,你们看着办吧。”
  这种情况通常出现在一个新的项目,客户对上线后的用户体量并没有很好的认知。我们应该怎么做呢?
  通常我们会对系统进行负载测试,就是在被测系统上不断增加压力,直到性能指标(如响应时间)超过预期或者某种资源已经快达到饱和状态,这个时候我们基本就可以确定系统的瓶颈是什么、支持多大的吞吐量。再通过一段时间的稳定性测试,让系统在一定的时间内(比如一周)维持一定的压力,去查看相应的性能指标。
  这样,我们就可以告诉我们的用户,系统现在支持多大的用户访问量、吞吐量是多少。
  当然,现在提到的都是客户的需求,对于性能测试本身来说,我们也有一些明确的需求,也就是我们通常提到的index,下面我会继续深入讨论这个问题。
  二、定义性能测试的指标
  1. 性能测试指标
  通常来说我们会关注如下的性能测试指标。
  响应时间:比较熟悉的就是2-5-8原则(据统计当网站慢一秒就会流失十分之一的客户),通常来说,2到5秒,页面体验会比较好,5到8秒还可以接受,8秒以上基本就很难接受了。但是有的项目也会例外,比如从海量的数据中去查询某些数据,或者生成报告(年度报告),这种可能就不太适合2-5-8原则,但是前提是要管理好客户的期望。
  吞吐量:指的是在单位时间内客户端和服务器成功传送数据的数量
  并发:客户/服务端同一批用户同时执行一个操作的数量
  资源使用率:通常来说,我们关注的资源就是几大块:内存、CPU、I/O和网络
  成功率:比如在某些情况下,API调用的成功率
  当了解了我们所需要关注的性能指标,就可以来定义具体的性能测试指标了。
  我之前做一个比较大的项目的性能测试,系统提供很多服务,有web service,有windows的services,基本上每个services都是单独部署在一台window的服务器上,所有的services都连到同一个数据库。由于这个系统并不存在网页,所以我们并没有把页面加载这些考虑在内。我们从历史数据中首先了解到了系统需要满足的并发量,针对每个service去做相应的压力测试,并且定义对应的性能测试指标。如下图:
  上图就是对于web service性能测试的指标和结果,这个结果是我们基于每秒有7个Post请求+3个get请求而产生的。
  这其中的性能指标包含了我们对这个service的单独的内存监控、CPU监控,以及成功率的监控,还有相应的原因分析。通常来说,对于内存、CPU等的占用率,业界都有很共识的标准,大家可以拿来作为参考,由于我们服务器是8g内存,8核CPU,所以表现还是相当不错的。
  其他的service也是类似的,我们考察的点主要在于CPU,内存的占用率,还有成功率。
  由于网络一开始我们就认为不是瓶颈(都在内网),所以我们并没有把网络相应的指标加进去。
  需要特别注意的数据库server,和其他windows service或者web service不一样,对于DB server我们需要特别关注的是I/O,数据库的瓶颈一般都是出现在I/O上面。
  2. 自定义指标
  在项目中我们往往还要自定义一些其他的指标,来查看某些特定的性能。比如:
  为了分析方便,我们在一些service的关键方法上都加上时间戳,便于去做trouble shooting。于是我们有了一下的指标,图一是某个方法的平均调用时间,图二是我们计算出的最慢调用方法的top10:
  总体来说,性能测试的指标可以从不同的方面去定义,比如响应时间、资源利用、并发数、吞吐量、并发数...

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号