性能测试流程指导规范

发表于:2017-2-27 09:19

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

 作者:曹承臻    来源:51Testing软件测试网原创

  一、背景:
  当前所有同学做性能测试方法不一,没有统一的规范指导文档可以参考。
  二、目的:
  形成性能测试整个流程的指导规范,以后做性能测试的同学可以依据此规范做性能测试。
  三、具体流程:
  (1)需求评估
  目的:评估是否需要做性能测试。
  · 需要做性能测试
  新产品要上线,预估单台机器QPS峰值超过100。
  已经上线过的产品,由于接入了新的业务或者用户量增加,预估单台机器QPS峰值超过100。
  · 不需要做性能测试
  单台机器QPS峰值低于50的需求。
  有相同产品实现逻辑的产品,且已经做过性能测试。
  例如:假如一个请求,每次用户开启应用时都会发送到服务器,服务器则会返回给客户端本账号在好友中的积分排名情况。从产品的角度认为,每次应用启动,都会触发服务器查询一次数据库。这样会数据库会造成很大压力。而测试再了解了具体实现后发现:针对每个用户机器码的排序数据是从redis服务器返回的,而redis服务器会每隔一小时请求存储的mysql服务器来更新账号排名信息,这样看来mysql服务器请求频率很低,没有任何压力。由于redis服务器的性能之前已经测试过类似的,没有性能问题,所以这次并不需要对mysql服务器做压力测试
  · QPS评估方法:
  产品已经灰度或者上过线,可直接参考灰度数据来推算全量用户的QPS峰值。
  产品未上过线,可通过类似已上线的产品来评估线上QPS
  以上两种都不符合,可通过通用算法来推算QPS。
  计算模型:
  每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量。
  其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时,有80%的请求发生一天的9.6个小时当中(很适合互联网的应用,白天请求多,晚上请求少)。
  简单计算的结果:
  ((80%*500万)/(24小时*60分*60秒*40%))/1 = 115.7个请求/秒
  (2)逻辑了解:
  目的:产品、开发、测试相互认识,便于后续的沟通。
  方法:在逻辑了解时,组织产品、测试、开发做需求评审及产品实现讲解会。
  讲解会需要了解的点:
  · 了解整个性能测试的业务逻辑。一般需要了解请求个数,请求参数含义,请求参数可取值等。
  · 了解服务器部署情况,主要要和线上服务器做明确隔离。不要简单认为所有的请求都是指向测试服务器,就认为是只向测试服务器打压。主要分为三种情况:1、测试请求会经过跳转链接到线上服务器。2、测试请求的js会异步请求线上资源。3、测试服务器会经过逻辑处理后返回给客户端,而这里的逻辑处理可能包括到线上服务器处理或查询数据。
  · 了解本次性能测试的测试目标QPS及推断方法。
  · 了解本次打压的请求间和参数间比例关系,这样便于后续写脚本时能够尽量模拟线上用户行为。
  (3)测试方案:
  主要用来评估本次性能测试的排期。并以邮件通知到各方。
  发送时机:开发实现讲解之后,用例设计之前。
  模板参考:(见附录一)
  (4)环境搭建:
  1)测试服务器的搭建的搭建。测试环境可以有开发来搭建。原则上测试服务器配置不能高于线上服务器的配置,且测试服务器部署的服务要尽量接近线上服务器,比如说线上服务器上运行了3个服务,峰值时会占用30%的cpu,那么测试服务器也要运行同样类似,且打压时cpu最高只能打到70%。这样得出的结果才具有指导意义。
  2)打压环境的搭建:主要指linux打压机的部署。具体部署方法就不在此赘述了,具体可以参照:http://www.51testing.com/html/13/n-3715213.html
  3)如果没有条件来搭建测试服务器,可否直接用线上的?
  · 如果线上的服务器之前打过压力,可以直接用线上的压力指标来衡量是否满足本次需求。
  · 如果之前没有打过压力,则在确认线上使用负载均衡的前提下,保证多台服务器中有一台挂掉后,其他服务器可以做到负载均衡压力,使线上用户不受影响时。可以对其中一台进行打压,在打压时需挑选线上用户非高峰时间段进行,且密切关注打压服务器情况,一旦挂掉,迅速启动起来。
  (5)数据准备:
  主要指性能测试有效数据的准备。请注意是有效数据?
  举例:加入你手动写完脚本后,跑一下脚本,发现服务器返回没有报错。都是200的response。这是否就说明是有效的打压呢?未必!应该回放脚本时,通过抓包工具抓包看下,对比真正使用场景中返回的response。看下内容格式是否一致。如果你的打压脚本返回的是空的200请求或者仅仅有关键字,但是内容都是空的,而真正场景返回的是大小为15K的json。这说明你的打压场景是有问题的。
  如果出现问题:应该和开发沟通原因,最后让打压请求返回正确的数据。
  准备测试机的查看权限。服务器log位置及信息。主要信息包括服务器响应时间,出错log标示,具体客户端请求信息。
  (6)脚本开发:
  根据上面获取到的逻辑和数据进行脚本开发。视个人习惯,可以使用录制方式和手动写脚本。但是需要注意一点,在保证尽量模拟用户行为的前提下,尽量使脚本简单。如if语句和for循环。这类语句在高并发下,本身就可能导致压力机性能问题。
  (7)打压过程:
  打压过程并不是放那里不管,通过linux系统提供的命令,需要时刻关注被测服务器的性能指标,结合LoadRunner场景的曲线来动态判断是否存在瓶颈。LoadRunner场景曲线主要关注HPS、TPS、responsetime。服务端主要监控cpu、内存、磁盘IO、网络IO。然后从这几方面再层层深入查找问题。另外,值得强调的是,打压过程不仅需要关注被测服务器的指标,也需要关注打压agent的性能指标是否正常。比如说如果并发数一直上不去,可能是打压机本上连接数受限导致的。也可能是打压机自己出口带宽满了导致的。
  (8)问题定位&修改优化&回归:
  问题定位是一个比较考验个人综合技术能力的地方。也是整个性能测试的核心所在。需要强调的是,不是看到某个参数遇到问题了,就直接可以断定服务区的瓶颈就在这个地方。比如:
  · 大量的页调入请求导致内存队列的拥塞
  · 网卡的大吞吐量可能导致更多的CPU开销
  · 大量的CPU开销又会尝试更多的内存使用请求
  · 大量来自内存的磁盘写请求可能导致更多的CPU以及IO问题
  具体是哪个部分的问题,需要再根据具体的逻辑实现和推断来逐步缩小范围。主要的过程可以参考一下步骤层层深入。服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库,web服务器等)-〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下,系统的硬件瓶颈在哪儿就够了。
  ... ...
   查看全文内容,请点击下载http://www.51testing.com/html/15/n-3715215.html
版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号