搜索
性能测试知识总结目录基础理论测试流程常用工具LoadRunner使用实例前言随着软件行业的快速发展，现代的软件系统越来越复杂，功能越来越多，测试人员除了需要保证基本的功能测试质量，性能也随越来越受到人们的关注。但是一提到性能测试，很多人就直接连想到Loadrunner。认为LR就等于性能测试，其实这是不对的。LR只是性能测试的一个工具，但性能测试不仅仅是LR。本文会从以下几个方面介绍基础的性能测试理论，后续也会持续更新相关文章，尽量理论结合实践，让性能测试学习不在是工具的学习。基础理论什么是软件性能.不同人眼里的性能.性能测试类型.性能测试应用场景.性能测试基本概念.做好性能测试需要掌握的知识.定义：软件的性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性。由定义可知性能关注的是软件的非功能特性，所以一般来说性能测试介入的时机是在功能测试完成之后。另外，由定义中的及时性可知性能也是一种指标，可以用时间或其它指标来衡量，通常我们会使用某些工具或手段来检测软件的某些指标是否达到了要求，这就是性能测试。性能测试定义：指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。什么是软件性能不同的人由于人生观、世界观、价值观以及教育背景、知识体系、人生阅历的不同，对于同一事物或问题的看法可能不同。对于软件性能也是如此，不同的人由于视角的不同，所关注的点也可能不同。下面来看看在不同的人群眼中性能分别是什么样的。不同用户群眼中的性能上帝视角测试眼中的性能是什么样的呢？测试人员通常是做为软件质量控制的一个角色，不仅仅是找bug，需要对整个软件的质量负责，性能也属于质量的一部分，因此测试人员眼中的性能应该是全面的，考虑的东西也需要全面：测试人员需要考虑全面的性能，包括用户、开发、管理员等各个视角的性能。测试人员在做性能测试时除开要关注表面的现象如响应时间，也需要关注本质，比如用户看不到的服务器资料利用率，架构设计是否合理？代码是否合理等言方方面面。在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考.是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等.压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力.性能测试类型基准测试负载测试压力测试在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定.性能测试类型稳定性测试测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题.并发测试1、性能测试应用场景（领域）主要有：能力验证、规划能力、性能调优、缺陷发现、性能基准比较，下表简单介绍和对比了这几个场景的各自用途和特点：性能测试应用场景（领域）性能测试应用场景（领域）主要用途典型场景特点常用性能测试方法能力验证关注在给定的软硬件条件下，系统能否具有预期的能力表现在要求平均响应时间小于2秒的前提下，如何判断系统是否能够支持50万用户/天的访问量？a)要求在已确定的环境下运行b)需要根据典型场景设计测试方案和用例，包括操作序列和并发用户量，需要明确的性能目标。a)负载测试b)压力测试c)稳定性能测试规划能力关注如何使系统具有我们要求的性能能力某某系统计划在一年内获客量在到xxx万，系统到时候是否能支持这么多用户量？如果不能需要如何调整系统的配置？a)它是一种探索性的测试b)常用于了解系统性能和获得扩展性能的方法a)负载测试b)压力测试c)配置测试性能调优主要用于对系统性能进行调优某某系统上线运行一段时间后响应速度越来越慢，此时应该如何办？每次只改变一个配置，切忌无休止的调优a)并发测试b)压力测试c)配置测试缺陷发现发现缺陷或问题重现、定位手段某些缺陷只有在高负载的情况下才能暴露出来，如线程锁、资源竞争或内存泄露。做为系统测试的补充，用来发现并发问题，或是对系统已经出现的问题进行重现和定位a)并发测试b)压力测试性能基准比较常用于敏捷开发过程中，敏捷开发流程的特点是小步快走，快速试错，迭代周期短，需求变化频繁。很难定义完善的性能测试目标，也没有时间在每个迭代开展详细的性能测试，可以通过建立性能基线，通过比较每次迭代中的性能表现变化，判断迭代是否达到了目标。2、通常在某个性能场景（领域）中需要联合使用多种性能测试方法一起进行性能测试，下表为性能测试应用领域与测试方法关联：性能测试应用场景（领域）能力验证规划能力性能调优缺陷发现性能基准比较基准测试√√负载测试√√√压力测试√√√√√并发测试√√稳定性测试√1、响应时间定义：从用户发送一个请求到用户接收到服务器返回的响应数据这段时间就是响应时间关键路径：下图为一次http请求经过的路径，请求会经过网络发送到web服务器进行处理，如果需要操作DB，再由网络转发到数据库进行处理，然后返回值给web服务器，web服务器最后把结果数据通过网络返回给客户端。性能测试基本概念计算方法：Responsetime=(N1+N2+N3+N4)+(A1+A2+a3)，即：（网络时间+应用程序处理时间）响应时间-负载对应关系：图中拐点说明：响应时间突然增加意味着系统的一种或多种资源利用达到的极限通常可以利用拐点来进行性能测试分析与定位性能测试基本概念2、吞吐量定义：单位时间内系统处理的客户端请求的数量计算单位：一般使用请求数／秒做为吞吐量的单位，出可以使用页面数／秒表表示。另外，从业务角度来说也可以使用访问人数/天或页面访问量／天做为单位。计算方法：Throughput=(numberofrequests)/(totaltime).吞吐量-负载对应关系：图中拐点说明：吞吐量逐渐达到饱和意味着系统的一种或多种资源利用达到的极限通常可以利用拐点来进行性能测试分析与定位性能测试基本概念3、并发数：并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一个场景或功能，也可以是不同场景或功能。在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求系统用户数：系统注册的总用户数据三者之间的关系：系统用户数=在线用户数=并发用户数性能测试基本概念4、资源利用率定义：指的是对不同系统资源的使用程度，通常以占用最大值的百分比来衡量通常需要关注的服务器资源如下：CPU：就像人的大脑，主要负责相关事情的判断以及实际处理的机制内存：大脑中的记忆块区，将眼睛，皮肤等收集到的信息记录起来的地方，以供cpu进行判断，但是是临时的，访问速度快，如果关机或断电这里的数据会消失。磁盘IO：大脑中的记忆区块，将重要的数据保存起来（永久保存，关机或断电不会丢失，速度慢），以便将来再次使用这些数据。网络：资源利用-负载对应关系：图中拐点说明：服务器某荐资源使用逐渐达到饱和通常可以利用拐点来进行性能测试分析与定位性能测试基本概念5、其它常用概念：TPS：TransactionsPerSecond，每秒事务数思考时间：用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的点击数：每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标:WEB应用是请求-响应模式,用户发出一次申请,服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求.PV：访问一个URL，产生一个PV（PageView，页面访问量），每日每个网站的总PV量是形容一个网站规模的重要指标。UV：作为一个独立的用户，访问站点的所有页面均算作一个UV（UniqueVisitor，用户访问）性能测试基本概念掌握一门编程语言掌握计算机原理和操作系统知识良好的网络基础掌握数据库知识中间件（apache,tomcat）常用抓包工具性能测试工具做好性能测试需要掌握的知识基础理论测试流程工具选型LoadRunner使用实例测试流程需求分析报告与总结结果分析与调优测试执行测试准备项目性能需求分析是整个性能测试工作开展的基础，如果连性能的需求都没弄清楚，后面的性能测试执行其实是没有任何意义的，而且性能需求分析做的好不好直接影响到性能测试的结果。一些性能测试人员常犯的错误就是测试一开始就直接用工具对系统进行加压，没有弄清楚性能测试的目的，稀里糊涂做完了以后也不知道结果是否满足性能需求。市面上的书籍也大都是直接讲性能测试工具如LR，jmeter如何使用，导致很多新手一提到性能测试就直接拿工具来进行录制回放，使得很多人认为会使用性能测试工具就等于会性能测试了，殊不知工具其实只是性能测试过程中很小的一部分。在需求分析阶段，测试人员需要与项目相关的人员进行沟通，收集各种项目资料，对系统进行分析，建立性能测试数据模型，并将其转化为可衡量的具体性能指标，确认测试的目标。所以性能测试需求分析过程是繁杂的，需要测试人员有深厚的性能理论知识，除此之外还需要懂一些数学建模的知识来帮助我们建立性能测试模型。一、性能需求分析明确倒底要不要做性能测试？性能测试的目的是什么？明确被测系统是什么？被测试系统的相关技术信息如：架构、平台、协议等明确被测系统的基本业务、关键业务，用户行为明确性能测试点是什么？哪些需要测，为什么？哪些不需要测，又是为什么？明确被测系统未来的业务拓展规划以及性能需求？明确性能测试策略，即应该怎么测试？明确性能测试的指标，知道测试出来的结果怎么算通过？性能需求分析需要得出的结论或目标1、系统信息调研指对被测试系统进行分析，需要对其有全面的了解和认识，这是我们做好性能测试的前提，而且在后续进行性能分析和调优时将会大有用处，试想如果连系统的架构、协议都不了解，我们如何进行准确的性能测试？如果进行性能分析与调优？需要分析的系统信息如下（包括但不仅限于如下这些）：性能需求分析的切入点2、业务信息调研指对被测试的业务进行分析，通过对业务的分析和了解，方便我们后续进行性能测试场景的确定以及性能测试指标的确定。需要分析的业务信息如下（包括但不仅限于如下这些）：性能需求分析的切入点3、性能需求评估在实施性能测试之前，我们需要对被测系统做相应的评估，主要目的是明确是否需要做性能测试。如果确定需要做性能测试，需要进一步确立性能测试点和指标，明确该测什么、性能指标是多少，测试通过or不通过的标准？性能指标也会根据情况评估，要求被测系统能满足将来一定时间段的业务压力。判断是否进行性能测试主要从下面两个方面进行思考：业务角度系统是公司内部or对外？系统使用的人数的多少？如果一个系统上线后基本没几个人使用，无论系统多大，设计多么复杂，并发性的性能测试都是没必要的，前期可以否决。当然，除非在功能测试阶段发现非常明显的性能问题，使得用户体验较差的，此时可进行性能测试来排查问题。性能需求分析的切入点系统角度：系统又可以从以下3个方面进行分析系统架构：如果一个系统采用的框架是老的系统框架（通常大公司都有自己的统一框架），只是在此框架上增加一些应用，其实是没有必要做性能测试，因为老框架的使用肯定是经过了验证的。如果一个系统采用的是一种新的框架，可以考虑做性能测试。数据库要求很多情况下，性能测试是大数据量的并发访问、修改数据库，而瓶颈在于连接数据库池的数量，而非数据库本身的负载、吞吐能力。这时，可以结合DBA的建议，来决定是否来做性能测试。系统特殊要求从实时性角度来分析，某些系统对响应时间要求比较高，比如证券系统，系统的快慢直接影响客户的收益，这种情况就有作并发测试的必要，在大并发量的场景下，查看这个功能的响应时