大话性能测试之性能测试的基本概念

发表于:2021-5-21 09:56

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

 作者:小菠萝测试笔记    来源:博客园

  学习前的认知
  我们在学习性能测试之前,需要有个新的认识:性能测试,不再是像功能测试一样单纯的找Bug,而是去找性能指标。
  转变思维
  在做功能测试、自动化测试的时候,我们基本都是依托界面进行测试,也称GUI测试,我们的目的就是为了跑通功能、程序,并成功找到Bug。
  但在做性能测试的时候,我们大部分是headless模式(所谓的:无头,无界面模式),目的不再是单纯的为了找到Bug,而是要分析性能指标等等(后续讲到)。
  性能测试的时间一般会比自动化、功能测试长,为啥?
  因为性能测试的步骤跟自动化、功能测试的步骤不一样,比如说前期的准备(了解系统,环境搭建),后期的压力测试(7*24h)等等。
  在后面,我们通过讲述性能测试步骤来仔细了解。
  性能测试一定要工具,手工不行吗?
  性能测试是模拟系统在被很多很多用户同时使用时,系统能不能正常使用和提供服务。
  重点:很多很多用户。
  功能测试:一个人点点点就知道功能通不通,有没有Bug了。
  性能测试:用手工的话,可以模拟几个、十几个用户,但是当需要模拟上千万个用户时,手工又怎么模拟数据量多的场景呢?
  类比,吃饭场景:一个人可以吃好几碗,但是叫你吃几百碗是不可能的。
  结论:工具就可以模拟大数据量的场景,可以做到人做不到的事情。
  大数据量测试是性能测试吗?
  大数据量测试
  简单理解:一个接口返回的数据比较多(假设:不使用分页,把所有数据同时返回)。
  结论
  返回大数据量的接口的响应时间会变长。
  这么大的数据量,我们需要考虑:网络传输数据、服务器查询这些数据、服务器处理这些数据等等分别需要多少时间。
  这已经跟响应时间挂钩,所以已经属于性能测试的范围,但不归纳于性能分析范围。
  大数据测试是性能测试吗?
  大数据测试的功能属于功能测试哦。
  性能测试过程发现问题需要立即提交吗?
  在性能测试过程中发现一些问题,假设定位到某一段代码有问题,可以截图提交Bug给开发,但这并不是我们性能测试的最终目的,最终目的是找出性能指标。
  有哪些性能指标?
  比如说响应时间:10个人、100个人、1000个人、10000个人向服务器发起请求,服务器响应请求的平均响应时间是多少,这就是一个指标。
  又好比TPS:服务器在当前的配置下,不同用户数发起请求,服务器的TPS处理能力是多少,这也是一个指标。
  后续详细介绍。
  性能测试中发现的Bug
  性能测试过程中发现的Bug属于一个衍生品,并不是最终得到的结果。
  但像功能测试,最终目的就是为了找出Bug。
  关于这个问题的总结
  做性能测试,当数据量变大后,会出现连接超时、连接拒绝、500、502等异常问题;在性能测试中,这些异常问题基本都会出现的,但不会去立即提Bug。
  对于性能测试工程师,我们要做的是分析为什么在当前数据量下会出现连接超时、连接拒绝,响应时间超时、服务器异常等异常问题。
  这就需要我们去分析性能瓶颈,并不会单独去看某个异常问题出现在哪里,而是分析为什么会出现这个异常问题,分析的是服务器或者是代码,而不是让开发人员马上来修复这些异常问题。
  我们常说的压测是指压力测试吗?
  并不是,而是指负载测试,一般都是为了找出系统的最大负载量。
  就好像你老板说:你去压测下,看看系统能支撑多少用户同时访问我们的系统。
  什么是性能测试?
  狭义理解
  通过工具,找出或获得系统在不同工况下的性能指标值。
  性能测试过程中,重点是找出性能指标,而不再是找出Bug,性能测试的产出绝对不只是Bug。
  场景类比
  跑步100米,用时多少?运动员的心跳、步伐频率是多少?
  跑步100米:业务场景
  用时多少:响应时间
  运动员的心跳、步伐:性能指标值
  性能指标值和响应时间是否满足当前业务场景的最低要求(合格线)。
  什么时候能找出性能指标值
  假设当前有一个业务
  电商系统,下单业务,目前还不知道系统支持多少人同时下单,那么我们需要找到服务器能正常支持多少人同时下单。
  性能测试初始阶段(第一次做)
  先把基础的性能指标值找出来(第一次性能测试也叫做基准测试)。
  比如:100个人同时下单系统正常,但120个人同时下单就会出现部分请求的响应时间超长,连接异常。
  那么100-120范围内的某个值就是当前服务器能达到的性能指标值(基准值)。
  版本迭代,进行第二次做性能测试,重新跑一遍之前的性能脚本
  又会得到一些性能指标值,对比上个版本的性能指标值,看是否有优化(性能变化)。
  假设这个时候120个人同时下单是正常的,150个人才有异常,那么接口已经有优化了。
  假设公司是从0开始做性能测试
  第一阶段:做好性能测试,得到性能指标值。
  第二阶段:假设性能比之前差,哪些性能指标值不满足预期值,就需要分析是哪里有问题。
  广义理解
  只要与服务器性能指标相关的测试都属于性能测试。
  比如:响应时间、并发用户数、服务器处理能力、吞吐量等性能指标。
  负载测试、压力测试、容量测试、可靠性测试都属于性能测试。
  通常嘴巴上说的做性能测试就是广义的性能测试,它包括了很多内容,并不只是针对某一个测试类型。
  “官方”解释
  以下含义来源高老的解释,比较“官方”的术语。
  性能测试针对系统的性能指标,建立性能测试模型。
  制定性能测试方案。
  制定监控策略。
  在场景条件下执行性能场景。
  分析判断性能瓶颈并调优。
  最终得出性能结果来评估系统的性能指标是否满足既定值。
  其实也算是一个简洁描述的性测试流程了。
  注意
  性能测试不像自动化测试那样很多东西大家都是公认的,性能测试没有一套标准的知识体系,只能说是相似的。
  基本每个人都有自己的一套知识体系,就好像高老也会说他给性能测试的定义很大可能会被轰炸一样。
  只要属于自己的知识体系建立起来了,那么就能助力你正确的完成性能测试。
  不用太过纠结于哪个人对性能测试概念的解释是最准确的。
  什么是负载测试?
  概念
  逐步增加系统负载,测试系统性能变化,并最终确定系统所能承受的最大负载量。
  通俗理解:看看你几斤几两。
  如何增加负载
  通过增加“用户数”,就是常说的并发数。
  场景类比
  天平秤,称东西的时候,需要逐步加砝码,最终达到砝码和物品重量的平衡点,因为它不可能一下子就达到平衡点【好比不可能一下子找到系统能承受的最大负载量】。
  称东西:业务场景
  加砝码:逐步加压
  达到平衡点:找到最大负载量
  实际场景
  有一个业务,增加到40个人的时候,服务器还能正常使用,没有异常。
  当你增加到50个人的时候,服务器已经开始有异常了,那么就能确定40-50之间某个值就是系统所能承受的最大负载量【出现性能拐点,找到了服务器性能瓶颈的范围值】。
  最后减小加压梯度(比如:从40个人开始每次增加1个人、2个人),确认最大负载量【确认性能拐点】。
  服务器又有哪些可能会出现的异常呢
  响应时间超长:正常服务器处理请求时间是1s,但现在变成3s-5s。
  服务报错:无法同时正常响应多个请求。
  服务器宕机:系统完全用不了。
  什么是压力测试?
  概念
  在较大的性能压力下,持续运行一个比较长的时间,看看系统服务是否正常及系统资源的利用率情况。
  通俗理解:鸭梨山大!
  关键字:较大压力+较长时间。
  注意:不是满负荷压力哦。
  场景类比
  问:大家什么时候会觉得工作压力大?
  答:996、007;因为你不会觉得955压力山大吧。
  结论:所以在我们日常工作中,长时间工作强度高,才会觉得压力大;如果你一周就加班一天也说压力大...(那就别干这一行了)。
  压力测试用来干嘛的
  测试系统的稳定性
  类比
  工作压力大,你还能坚持下去(那稳定性肯定好吧),那如果你很快就离职了(那稳定性肯定差,都宕机罢工了)。
  什么时候会做压力测试
  生产环境下,系统隔三差五的出现不稳定的情况。
  这个时候,就需要通过压力测试去测试系统的稳定性情况。
  啥情况算不稳定?稳定性差?
  隔三差五的出现下面的情况。
  服务异常:响应错误、响应时间超时等。
  服务器出现异常:宕机。
  怎么分析是服务异常还是服务器异常
  如果所有请求都是一片红,应用程序发送的所有请求都报红,就是服务器出现了异常。
  如果有些请求偶尔成功响应,偶尔又失败,则是服务异常,出现不稳定的情况。
  如何取压力值
  在负载测试中,我们确认了系统所能承受的最大负载量。
  压力值<最大负载量,一般取80%左右。
  灵魂拷问
  负载测试一般时间比较短,压力测试时间比较长,持续运行时间短就能正常使用,但持续运行时间长就可能崩掉了,这是什么原因呢?
  场景类比
  栗子一:电脑保持开机状态很长时间,会逐渐变卡,因为内存的东西会越来越多,得不到有效的回收,就会越来越卡。
  栗子二:当你经常工作压力很大,且你的心理所能承受的压力逐渐达到最大值时,你就可能会选择离职。
  总结
  压力测试长时间运行,可能会逐渐增加系统的内存占用空间,若得不到有效的内存回收,当达到内存最大值时,系统就会崩掉。
  压力测试持续运行时间要多久?
  标准性能测试里面,一般是7*24小时,或者是它的倍数。
  但是实际工作中,并不会这么久,否则成本太高。
  所以会以小时为单位,比如:4个小时、8个小时...晚上下班之后做,第二天早上上班看结果。
  先负载测试还是压力测试?
  先负载测试,负载测试可以找到服务器性能瓶颈的范围值,若生产环境中系统稳定性较差,再做压力测试。
  所以压力测试是可做可不做的。
  什么是可靠性测试?
  概念
  在给定的一定的业务压力下,持续运行一段时间,查看系统是否稳定。
  关键字:是否稳定,一定业务压力。
  注意:不是较大压力哦。
  业务场景栗子
  电商秒杀场景,几十个商品几十万个人同时秒杀抢购。
  如何理解可靠性测试
  编写性能脚本:假设一秒内有一万个人同时发起请求。
  有压力吗?有,一万个人同时发起请求。
  但是持续时间短,不像压力测试一样需要持续一段时间。
  目的是为了验证当这么多人同时发起请求时,成功秒杀的用户能否继续完成后续下单付款等操作【一定业务压力下,系统是否稳定运行】。
  什么是容量测试?
  概念
  在一定的软、硬件条件下,在数据库不同数据量级数据量的情况下,对系统中读/写比较多的业务进行测试,从而获得不同数据量级下的性能指标值。
  关键字:不同数据量级。
  数据库数据量对性能测试结果有没有影响?
  肯定有
  比如数据库已经有几百条数据和几百万条数据,查询的速度肯定不一样,所以肯定会影响性能测试结果。
  数据量级的差异,会影响TPS、响应时间、网络等。
  场景类比
  从一袋米中找一个绿豆,和一碗米中找一个绿豆,找的时间肯定是千差万别的。

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

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号