您的位置 » 首页 » 人文创业 » 性能测试怎样测?

性能测试怎样测?

发表于5年前 | 作者: seay | 分类: 人文创业 | 孵化于:2012年08月21日 | 文章热度:2,760 次 全屏阅读

显示不全请点击全屏阅读

事情的起因是这样的:

  上周三下午要出去打个电话,经过小会议室门口的时候测试负责人叫住我问有事吗?小A做的性能测试出现了点问,要我帮忙分析一下。打完电话后到小会议室与小A、测试负责人一起看小A的性能测试出现了什么问题。小A说她对X项目进行了性能测试,但是结果与现在线上的差距特别大,线上入库是10条/秒,而她测试的结果是3-4条/秒,对于她测试得出来的结果项目的负责人很不认同,认为是她做错了,而她又找不出来问题出在哪,她很郁闷。

  接下来是我们的一段对话

  我:小A,你说一下这次性能测试,是对哪几个点做的,场景都是啥样的?

  小A:主要是两个点,一个是单一场景针对短信入库的,场景设计的是30、50、100条数据并发持续2个小时,是根据线上前段时间出现的问题发3万条短信,结果处理的时间特别长这个问题设计的;另外一个是将接收到的不同类型的短信入库,是个混合场景,场景是短信2条、彩信1条、WAPPUSH1条、EMN1条,这些数据并发,持续2个小时。

  我:问一下,线上对于短信发送真实操作场景是什么样子的呢?

  小A:这个我不知道啊,反正我只知道现在线上要求1个小时内必须把这些短信发完,线上现在预计的入库量是10条/秒。

  我:好吧,换个问法,X系统小A你最熟了,线上的这个问题,有大量的数据过来,X系统 对这些数据是怎样处理然后入库的呢,是一批一批的处理,还是一条一条的处理呢,如果是一批一批的处理,对于这一批数据是怎样处理的呢,是同时处理掉,还是一条一条的数据。

  小A:这个我不清楚,要不一会儿我去问一下开发的吧。

  我:我再问一下,现在搭建的这套测试环境,各个机器的配置是怎么样的?和线网的机器配置差距有多大?线网的带宽是多少?现在测试环境的带宽是多少?线网是有负载均衡的,有VPN通道的,测试环境上有这些吗?

  小A:tomcat的机器是一台服务器,4核的,另外两台数据库还有LR加压机都是实体机。线网的机器配置我不知道,测试环境也是100兆带宽,负载均衡啥的测试环境都做不了。

  我:线网带宽是千兆的,测试环境的百兆带宽不全是给你来测试用的,公司上班时间所有同事办公还占用一部分带宽呢。线网的数据库做过一次优化的,有几个参数是调整过的。

  我觉得这次问题的分析可以从几个方面来入手查,第一,场景设计,我从开发的那里了解到线上真实的情况是没有并发的,只是一条一条的来处理,处理的数据量是3万条,1个小时处理完,是我们自己的要求。所以场景可以重新设计,设计成没有并发,处理3万条数据;第二,测试脚本的性能,测试脚本里的代码可能本身响应时间就长;第三,机器配置、网络带宽,查看现在测试机的配置与线网比相差多少,这些能不能想办法进行一下换算,结果可能有误差,如果找到依据,看看误差能控制在多少范围内。

  小A:我觉得脚本代码不是问题,我就是这样写的都能执行过去,能执行过去为啥就会有问题呢。线上真实的操作那在那台服务器上还可能有别的省发短信呢,对那台服务器还有影响呢,那台服务器的配置好可能还有别的省来占用呢,所以机器配置也不应该是问题。带宽我觉得也不是问题,公司百兆的带宽也够用了呀,我在测试的时候也没发现网络上哪里出现了问题,CPU占用率呀都非常少的。

  我:……无语

  对于性能测试,到底应该怎样做,会用了工具(最著名的是LR)就会了性能测试了吗?NO,NO,NO

  我认为:

  前期分析:

  分析业务:分析用户群,业务真实使用和操作情况。比如在哪个时间段哪个操作会多,哪个操作会少,怎样来操作,是会有很多人一起对系统发起请求呢(所谓的并发),还是数据量很大,但是都是一个请求一个请求过来的,很持续很长时间吗(比如8个小时都在做这样的操作),还是主要是对一定的数据量操作的(比如处理完几十万条数据后任务就完成了),每次只有一个场景吗,还是是个混合场景都有,如果是混合场景,那么各个场景的比例大约是多少呢。线上已经有多少数据量了?预期要达到多少数据量?

  分析环境:线上系统环境是什么样子的?有负载均衡吗?有多次转发吗?……机器配置是什么样子的,每台机器上都有哪些服务?线网的带宽是多少?是专用的吗?搭建的测试环境和线网真实的环境有多大的差距,带宽是多少,是专用的吗?测试环境不可能与线网环境是一模一样的,有办法换算吗?误差大约是多少?

  分析团队成员:给你配备的配合的开发人员了吗?与你配合的开发人员靠谱吗?你的团队里有性能测试的高手吗?团队对这个项目的性能测试支持吗?

  时间分析:测试的时间充足吗?哪些是必须测的,哪些是可以不测的。

  测试执行:

  有了前面的详细的分析之后,才能整理出测试需求、设计测试方案、编写测试用例、编写测试脚本、设计出合理的测试场景,才能执行测试。

  结果分析:

  测试出了结果,不能就算完事了,把结果丢给别人让别人分析查找原因,那不是高手,真正的高手是可以分析出问题在哪里,是什么原因产生的,怎样优化。简单的几个切入点可能从服务器系统CPU、内存等等,数据库中SQL执行速度,数据库CPU、内存等入手。查看事务平均响应时间是否在可控范围内,每秒处理的事务数怎样等等。借用一些工具查看操作数据库的SQL执行情况等等。

  总结一下,性能测试个人认为最重要的不是使用工具,而是测试前的分析和结果的分析,前面的分析够透彻才能保证后面做的是对的,而不是一上来就是用工具,就大并发,只有大量的并发才是性能测试,一定得根据现实的真实使用情况来做才可以,违背了现实做再多也是无用。每次一听到有开发的对我讲你帮我们做一下性能测试吧,弄个几万的压一下,我就特无语。

Tags:

性能测试,

如果您喜欢我的博客,欢迎点击图片定订阅到邮箱填写您的邮件地址,订阅我们的精彩内容: 也可以点击链接【订阅到鲜果】

如果我的想法或工具帮助到了你,也可微信扫下方二维码打赏本人一杯咖啡


来自 Seay互联网安全博客
本文地址:http://www.cnseay.com/674/
文章版权说明请看置顶文章,尊重作者,转载请以链接形式标明原文地址

马上分享给你的朋友吧~

发表评论

你的大名(必填)

你的邮箱(必填)

评论内容(必填)