1.性能测试技能树

   开发语言

   操作系统

   数据库    

   测试工具(常用的jmeter、roadrunner)

   网络知识(网络宽带大小、数据大小)

   业务知识

2.性能测试的目的

   目的:发现性能瓶颈

   发现应用系统的短板在哪里,如果爆发了性能问题,一定要知道首先是哪个点被击溃了,可能是代码问题,系统有问题改系统配置,或者是数据库有问题就改数据库架构也好、数据库配置也好,总之必须要解决你所发现的性能瓶颈问题。

3.性能测试的分类

   概念:性能测试是一个非常广泛的概念,包括的很多方面的测试,也称非功能测试。

              自动化测试属于功能测试的范畴,由于其测试方法要求测试人员拥有一定的代码能力,所以被单独分成一个测试模块。

   

面试题:移动端的性能怎么做?

  一个是传统的性能,就是多并发下我们的应用系统的表现能力,多用户访问,耗电量、稳定性,弱网下程序的反应,空数据、程序崩溃等等的测试

4.性能测试具体分类(测试范围)

     负载测试:通过逐步加压的方法,达到既定的性能阈值的目标。阈值的设定应是小于等于某个值,如cpu使用率小于等于80%。

     这个逐步加压是什么呢,就是它呈一个斜线,这个斜线就是比如说我们这个虚拟用户数,虚拟用户数一点一点儿往上加,逐步加压嘛,逐步加大压力后看既定的性能目标当中的一些阈值有没有达到,如果达到了就是说有可能性能瓶颈了,需要分析是哪些原因造成的性能瓶颈;如果不是性能瓶颈的话就是说我们这个虚拟用户已经超过了当初预定的虚拟用户数。比如前15分钟用50个虚拟用户跑,如果没问题,那我再加50个虚拟用户,然后看性能指标,一点点往上加。

     压力测试:通过逐步加压的方法,使得系统的某些资源去达到饱和,甚至失效的状态,简单粗暴的解释就是什么条件下能把系统压崩溃。

     这个就是一点点加虚拟用户数,知道某一项崩溃了,不管是中间件也好,应用程序也好,数据库也好,给它压爆了,它就达到性能瓶颈了。

     并发测试:在同一时间内,多个虚拟用户同时访问同一模块、同一功能,通常的测试方法是设置集合点。

     举个应用场景的例子,就是我们登录成功之后,有的人浏览服饰商品,有的人浏览零食商品,这多用户进行操作的话也是一种性能测试的场景,这种多用户并发操作你要看服饰,那所有的用户都看服饰,同时访问同一模块同一功能,设置集合点就是等待所有的虚拟用户到这个时间都满足这个集合点条件,比如说100并发,那我必须得等80%的用户全都到这儿了,80个并发一起浏览服饰,同一时间触发同一动作。

     容量测试:通常是指数据库层面的,目标是获取数据库的最佳容量的能力。又称之为容量预估。具体测试方法为在一定的并发用户,不同的基础数据量下,观察数据库的处理能力,即获取数据库的各项性能指标。

     什么情况下做容量测试?就是所有的性能测试都做完了,然后性能指标也满足我们现在既定的性能指标,满足这些要求了,那未来我们的业务会飞速发展,未来三个月、未来六个月的增长速度有可能推断未来的数据增长是多少,不同的基础数据,相同的用户,假设在一个表里面有500万条数据和1000万条数据,那你即便是同样的100并发用户,它的数据库的表现也是不同的,那这个也是一个预估未来的动作,未来假如数据是100万,后来变成1000万,那这样的话系统就扛不住了,预估未来,什么时候我们系统能达到性能瓶颈

     可靠性测试:又称之为稳定性测试或疲劳测试。是指系统在高压情况下,长时间的运行系统是否稳定,如CPU使用率在80%以上,7*24小时运行,系统是否稳定。

     可靠性测试最容易发现的问题,比如内存溢出(OOM),为什么内存泄漏在这里容易发现?因为内存泄漏的基本原因是系统长时间运行,然后底层垃圾回收,回收不彻底然后导致内存泄漏了。可靠性就是跑的时间长,观察系统性能。

     异常测试:又称之为失败测试。是指系统架构方面的测试。如在负载均衡架构中,要测试宕机、节点挂掉等情况系统的反应。

     具体例子:在我们做系统测试的时候,这种负载均衡架构是非常常见的,比如说我用ngix做这种负载均衡,下面挂3个tomcat,这就是一种负载均衡架构,那你在测试的时候,不如我弄死一个tomcat,剩两个,看看系统是怎么样的,怎么反应。正常来说正常的反应,挂掉一个tomcat并不影响我的整个应用系统,不影响的表现就是ngix能检测到tomact的死亡状况,就不把请求往这台tomcat上发了,发到剩下两台,然后再把挂掉的tomact启动起来,此时ngix能检测tomcat到复活了,又把请求接着往这个tomcat上发。这就是异常测试,其实主要就是检测各个节点挂掉、宕机等等一些情况,我们的系统能不能正常运行。节点测试,如果说根本没检测到死亡,请求还在发,最后展现的效果是假如100次访问,如果有3台,30%完全均衡的,就是说有33个请求是失败的,节点宕机,有一个节点挂掉了。

5.性能测试的工作流程

架构设计与集成测试验证 测试架构的目的_jmeter

需求分析:熟悉项目是做什么的?用户如何使用我们的软件?业务流程是什么样的?

性能指标指定:性能测试中的吞吐量、tps、满足多少个并发等等这些指标就在这个环节定义了,什么样的标准          满足我们现阶段的业务需求。。

脚本开发:在知道了业务流程、了解了性能指标的前提下,接下来进行脚本开发

场景设置:脚本开发完后不能应用于性能测试,就会有调试、设置这个过程,结合具体业务设置业务场景。

监控部署:一个应用软件它的构成,首先是应用程序是一部分,还有我们要运行到一些服务器上,还有数据存储的部分,这些都要把它监控起来,只有监控起来了我们才能看得到系统的运行状态,才能发现后面的性能瓶颈,然后才能够进行性能调优等等的一些列工作。监控部署,能够看到整个应用程序、服务器、数据库等等的运行状态。

测试执行:

测试执行怎么跑?一般来说,第一个阶段,基准测试,随便拿10个或20个用户,少量的先跑一下,比如跑个15分钟,这是第一轮。

第一轮能发现哪些问题?

就是多并发下,这应用程序对多线程它的一个逻辑处理问题。有的时候应用程序开发,会发现一种什么状况,就是1个用户跑的好好的,啥事没有,但是当多个用户同时去操作一个功能点的时候,就会出现问题,这就是多并发逻辑问题,解决完这一轮问题再进行下一轮测试。

第二轮测试

长时间跑一跑,看看系统稳定性,比如跑个几个小时或者几天,系统会发生哪些问题?

性能分析:基于监控部署,根据监控反应的日志或者其他情况进行分析

性能调优:在性能调优之后发现一些问题,在下一轮再进行测试执行,其实测试执行-性能分析-性能调优是一个循环的过程,最多最常见的问题,就是开发同学在做程序开发的时候对某一个自己应用的变量或者是类的声明等等生命周期控制的不严格,就会出现比如说内存泄漏,内存溢出等等问题

测试报告:当性能指标满足既定的要求,不再进行调优了,出具测试报告给相关领导及同事,告诉我们应用程序满足了一个什么样的条件,可以具备上线的基础。

还有就是很多公司都是敏捷开发模式,比如2个星期一个迭代,这种在测试执行这个过程的时候不会有太多时间,这个时候怎么办?这个就分阶段来进行了,比如第一个阶段版本满足什么样的性能指标;下一阶段满足什么样的性能指标,作为文档输出给相关人员。以便于领导知道你下一步的工作目标是什么。

6.常见的系统应用分层架构

架构设计与集成测试验证 测试架构的目的_jmeter_02

逻辑控制层:应用程序大部分的逻辑处理都在Api层,Api层就是我们后端开发主要的控制业务逻辑代码产生的部分,就是你要把你的应用程序部署到服务器上,部署的是什么

数据存储层:

        mysql是关系型数据库里面应用最为广泛的一个数据类型

        mongoldb是文档存储的,是nosql类型应用比较广泛的,适用于存储相当大的数据量

        mysql和mongodb的一个最大区别,就是事务上的一个区别,mysql是支持事务的,mongodb并不支持,但mongodb的单表数据量会比mysql的大

        redis也是一个nosql类的数据库,特点是数据首先是存储到内存里面的,读写速度非常快,因为从内存里面直接读

其实一个应用程序摆在你面前的时候啊,这个应用程序应该是分块的

比如现在拿电商类的项目举例:网页(web)能打开我们的应用程序,然后API层能够控制我们业务逻辑,然后用mysql来进行存储,那这个时候我们应该在性能测试前期的准备工作当中应该怎么做?首先我们要能够监控mysql,一系列的开发工具以及命令能够监控mysql,把它部署到我们的服务器上对mysql的状态进行监控,然后实时反馈到我们眼前,很直观的看到mysql现在处于一个什么样的运行状态;其次,就是我们要进行监控Api层,就是这个代码层面,代码运行的怎么样,它的处理速度是什么情况,并且还要监控的是什么,就是mysql的数据库以及Api的代码它是运行到服务器上,我们要监控linux服务器的本身运行的状态,有的时候我们的代码或者是数据库本身并没有出现什么瓶颈,但是服务器扛不住了,比如说服务器配置太低,却运行高并发的,那服务器肯定是扛不住;最后是web层面的分析,因为web层面主要是进行哪些方面,web首先要有渲染的过程,渲染的过程就是图片的加载以及js加载,比如说首先加载js后加载图片会产生什么样的效果,就是你能感觉到页面有停顿,应该先加载图片再加载js,因为js是控制业务逻辑的,假设有一个登录页面,你控制用户名和密码的输入规则这些是js进行控制的,显示的框就是图片控制的,如果打开一个网页,很慢,呈现的样式,一定是先加载样式后加载脚本,这样的速度会显示的快一点,再一个比如说图片的大小,图片大小是如何进行格式压缩然后不会失真等等这些情况。

比如说首先进行数据库的测试,mysql的测试,我把开发的代码拿过来,把代码里边跟数据库产生交互的sql语句抽离出来,然后开发成我们的性能测试的脚本,对mysql数据库进行一个性能测试,这个时候它的好处是什么,没有其他因素干扰,如果发生问题了,那一定是mysql本身的问题,要么进行mysql语句调优,要么进行mysql配置调整,要们进行服务器层面的硬件调整,将范围缩小,性能分析性能调优比较容易。数据库层调优之后就进行Api层接口测试了,要么就是并发逻辑问题,要么就是代码哪里没写好,通过监控具体问题具体分析。然后再做前端的性能测试。自底向上一点一点测试,分层分块的去处理。