软件性能测试流程(PPT).ppt

软件性能测试流程由安博测试空间技术中心http:/,编写目的,本文档从性能工程的角度提出开展性能测试工作的流程，和进行性能测试工作的策略，下面我们讨论性能工程的需求阶段、设计阶段、实施阶段、产品部署阶段、维护阶段所要开展的工作，和相应要采取的策略。,我现在调研的这个项目，一个内网网站，前台包括：新闻，公告，资料上传和下载，视频播放，留言，投票，专题活动，后台包括：用户管理，权限管理，布局设置，系统设置对于投票来说，会要求省和地市的用户在某个时间段进行投票。,我想问用户的是：1）网站的在线访问人数估计有多少人，并发人数有多少人 2）功能的系统响应时间可接受的范围 3）系统支持的最大吞吐量是多少 4）用户频繁使用的功能模块是什么 5）用户一般习惯的场景操作有什么 6）网站的高峰时段是何时？,为什么进行性能测试？,性能测试致力于减少应用程序、升级程序或修补程序部署中的风险。性能测试的核心原理是通过将生产时的工作量应用于部署系统来衡量系统性能和最终用户体验。,构造严密的性能测试可回答如下问题：应用程序是否能够很快地响应用户的要求？应用程序是否能处理预期的用户负载并具有盈余能力？应用程序是否能处理业务所需的事务数量？在预期和非预期的用户负载下，应用程序是否稳定？是否能确保用户在真正使用软件时获得积极的体验？通过回答以上问题，性能测试可以量化改变业务指标所产生的影响。进而可以说明部署的风险。有效的性能测试过程将有助于您做出更明智的发布决策，并防止系统出现故障和解决可用性问题。,性能测试流程,性能测试通常由五个阶段组成：测试计划、脚本创建、场景定义、场景运行和结果分析。测试计划：定义性能测试要求，例如并发用户的数量、典型业务流程和所需响应时间。脚本创建：将最终用户活动捕获到Vuser自动脚本中。场景定义：使用 LoadRunner Controller 设置性能测试环境。场景运行：通过 LoadRunner Controller 驱动、管理和监控性能测试。结果分析：使用 LoadRunner Analysis 创建图和报告并评估性能。,性能测试问题及对应人员,性能测试需求的来源,性能测试需求的来源有三个方面：需求文档设计文档与客户沟通,确定性能测试需求的解决方法,在没有需求文档和设计文档的情况下，我们需要对客户业务使用情况进行分析，提出我们所关注的性能测试需求，并告知业务人员。让业务人员来判断我们的性能需求是否能满足客户的真实要求。,1、确定当前系统的业务使用状况：通过日志记录客户端模块使用情况了解在某个时间段内，客户执行某个操作的具体情况。2、了解不同视角的用户性能：）用户视角：响应时间：用户所能感受到的响应时间，也是用户最重视的性能体验。确立响应时间的原则：2/5/10原则 2：2秒钟用户会觉得是一个很好的体验。5：5秒钟用户可能会觉得差了一点，还行，比较好。10：10秒钟是用户所能承受的最大极限。鉴于不同地区的网络环境，将用户所能承受的响应时间极限定为1215秒。此部分需与业务人员讨论。稳定性：系统长时间运行不会出现错误的能力。验证方法：系统在满负载的运行8小时，系统是否会出现服务不可用，Connection Refused HTTP 404,500错误。）系统视角：延迟，系统资源使用状况 延迟：包括数据库延迟和网络延迟此部分需与DBA及系统部人员讨论。系统资源使用状况：服务器的CPU使用率是否长期高于80，达到90，100的程度，整个磁盘的I/O是否达到极限。内存的使用数是否只剩下极少的几兆，几十兆。）开发者视角：从代码实现和数据库实现来考虑性能。看看这两方面得到实现是否足够好。3、了解真正的性能测试需求方法：）识别项目干系人：指的是和项目相关的人，开发人员，设计人员，需求人员，业务人员，上层领导，了解他们对性能测试的考虑。）隐藏在“性能测试”之后的实际想法，比如：是因为开发人员对所完成的代码没有信心，又不愿意做修改，要求我们对其所作的程序进行性能测试，还是设计人员使用了一项新技术，心里没低，所要求作的性能测试，等等。,确立性能测试目标,1、以“需求”为本考虑系统需不需要作性能测试，性能测试的内容和范围。2、测试目标确定的经济性考虑）投入到性能测试的人员是多少？）具备可以确定性能测试需求，制定性能测试方案的人员是多少？可以执行性能测试的人员是多少？）这些人员需要投入多长时间？）所要开发系统的运行环境和设备，这些设备的配置对于性能测试的影响，比如说：tomcat4.1的应用服务器，它的配置文件缺省的jvm的使用空间是64M，一个机器的内存为1G，我们将jvm的使用空间设置为512M对性能测试的影响。）内部的人员无法满足性能测试的要求，通过外聘，采用外聘的方式，公司所能承受的成本是多高。3、基于风险的测试目标确定）系统如果不做性能测试，会有多大的风险，如果在性能指标上达不到用户的要求会有多大的风险。需要进行评估。）如果做性能测试会有多大的风险，性能测试的投入会有多大，会有多大的风险需要进行评估。,确定性能测试目标的方法,我们要确定系统的吞吐量和并发用户数的设计目标可以采用以下三种方式：确定在某个特定时间端内，估计系统会有多少用户同时访问在某个特定的时间端内，正在访问系统的用户的典型操作是什么？哪个页面的访问量最大？在某个特定的时间端内，系统需要处理多少种用户场景这些数据可以在系统服务器的日志文件、TSP监视数据种找到，也可以通过监视数据库的活动情况来获得。,不同阶段的性能测试目标,设计阶段的性能测试目标设计阶段的性能测试目标为考察系统是否满足预期的性能要求。开发阶段的性能测试目标）将开发阶段的性能测试目标作为对系统进行调优的参考：考虑在每个开发阶段，性能是否能够达到标准，考虑当前阶段的性能瓶颈，及其性能瓶颈出现的原因是在于数据库访问（SQL语句或者存储过程写的不够好）还是其他的原因。）用性能测试手段发现系统存在的问题：通过模拟真实场景，发现在现场测试中可能存在的问题，比如说：用户数的突然增加，导致的应用程序崩溃，服务器崩溃的问题。产品部署阶段的性能测试目标提供部署方案的参考，确定合适的硬件设备，虽然更高的设备可以获取商业上的利益，但应考虑客户的具体情况。系统维护阶段的性能测试目标考察系统的可扩展性：从系统的视角考虑,在用户数扩大，在业务量增大的情况下，是一个怎样的表现。,性能测试方案的确立,在确立性能测试方案之前，需要作的工作1、确定测试目标和需求这里的灵活性比较大，与性能测试成败有很大的关系。2、了解现状）业务使用状况通过日志记录，在某个时间段内，用户的操作。）了解环境：包括网络条件，服务器条件，软硬件条件，应用服务器环境及各种配置信息。3、确定需要监控的指标：）CPU使用率）内存使用情况 在此应优先监控应用服务器的性能指标。对于Tomcat或者Weblogic来说，监控他的JVM使用状况，连接池的连接数量，内存使用状况等信息。对于数据库来说监控cache的命中率，索引的使用状况，数据库的连接数。,用例和场景设计,用例和场景设计的步骤：1、对业务的分析和分解2、根据业务确定用例3、不同用例按照不同的发生比例组成场景 4、了解每个场景的实际意义（对场景执行测试，收集结果）5、了解业务的分布情况，根据业务确定用例，在设计用例的时候，根据前期收集的数据，设计不同的场景来组成用例，并了解每个场景的实际意义，执行场景，收集结果数据。,设定需要监控的资源,设定需要监控的资源主要有一下几个方面：1、CPU利用率2、内存使用情况3、数据库监控4、JVM使用状况监控应优先监控应用服务器的性能指标。对于Tomcat或者Weblogic来说，监控他的JVM使用状况，连接池的连接数量，内存使用状况等信息。对于数据库来说，cache的命中率，索引的使用状况，数据库的连接数，具体的监控指标请性能测试工程师，根据性能需求确定。,性能测试的应用领域,系统性能测试的主要应用领域是验证能力、性能调优。1、验证能力包括）验证新的系统，新的架构能否满足用户的需求。）向用户提供性能测试报告，说明系统的性能达到了预期设计的标准。）确定新平台的产品架构，假设以前用ASP，现在用.net，或者换到j2ee平台上，验证新系统架构是否满足性能要求，这个要求不是用户提出来的，也不是直接用户体验的，而是在架构设计过程中要确定的指标。2、性能调优在系统开发过程中，通过性能测试，了解当前系统瓶颈（比如说在于数据库访问，SQL语句或者存储过程写的不够好，或者说数据库设计的问题，索引做的不够好），所选择的应用服务器有问题，或者说代码这一层，业务逻辑实现的不够好，导致它性能的缺陷。以确定问题出现在应用层，数据库层，代码层。,实施阶段,将影响性能的因素按照以下顺序进行判断：1、网络状况2、硬件设备3、系统/应用服务器/数据库配置4、数据库设计和数据库访问实现（SQL）5、业务的程序实现但是在开发阶段做性能调优时关注的顺序：请更多的关注SQL 一级和代码一级。若是对于一个实际在线上运行的系统，请直接按照以上5点的顺序。注：很多的性能问题，是由于应用服务器的配置完全不合理，比如：tomcat4.1的应用服务器，没有修改它的配置文件中缺省的jvm的使用空间。,各阶段所要进行的性能测试,设计阶段的性能测试在设计阶段的性能测试主要的目的是验证你的架构。验证的方式有两种：1、在对于系统架构有一个预期的性能目标的情况下，去验证当前架构能否满足预期的性能目标。2、系统架构是基于以前的架构修改过来的，对于两者进行一个对比测试，了解两种架构各有什么优势。实施阶段的性能测试在实施阶段进行性能测试的目的是为了阶段性的验证系统性能，进行性能调优，并通过系统调优发现系统缺陷。产品部署阶段的性能测试在产品部署阶段，将性能测试作为验收测试的一部分。维护阶段的性能测试在维护阶段考察系统的可扩充性/定位系统缺陷，考察系统的可扩充性用来定位系统的缺陷。,系统稳定性的度量,为了验证系统的稳定性，我们需要对系统进行一个可靠性度量，在目前没有一个行业或者国际标准进行可靠性度量的前提下，我们又无法获得确切的用户需求（用户提不出系统稳定性的量化标准），我们可以采用如下方式来验证系统的稳定性。通过在做性能测试的过程中得到系统稳定性数据的方式来验证系统的稳定性手段：对一个系统进行一个长时间的运行，观察它的可用内存，cpu使用率有无显著的变化，如果在长时间使用的情况下，cpu，内存无显著变化，则可以认为系统具有稳定性。,性能测试的基本概念,1、响应时间：客户端从发送请求的那一刻起到收到应用程序响应的最后一个字节时止而不得不等待的时间长度。2、点击数：对每一个对象的请求，比如说：一个页面有五个部分组成，一个框架，四张图片，这样算做5个点击数。3、页面请求：请求了一个页面，不管这个页面包括了多少对象。4、吞吐量：i）按照流量来计算的吞吐量，用来衡量网络状况或者应用服务器的处理能力，在指定的时间内，每秒钟字节的出入.ii）用点击数来衡量吞吐量，每个固定的时间段内有多少点击数，用于银行系统。5、并发用户：从业务上的并发：200人同时在线。从服务器上的并发：200人同时向服务器发出请求。200人同时做一个提交的操作，服务器接受到多少请求。6、资源利用率：cpu利用率，内存利用率，磁盘I/O状况等,在性能测试中需要注意的问题,1、环境设计的问题2、其他需要注意的地方,环境设计的问题,1、网络环境2、软硬件环境3、环境的维护方案4、时间同步问题5、“镜像”环境时间同步问题：各种服务器部署在不同的机器上，在进行性能测试分析响应时间的时候就需要进行时间同步，通过日志来对比时间，但日志上记录的是本地时间，让日志记录的时间有可比性，需要做时间同步。同步的方法：在UNIX操作系统上用NTP协议可以做时间同步，在windows系统上可以通过加入域来时间同步，“镜像”环境的问题：做能力验证的测试的时候，一般要求在现场做，因为这种测试结果和应用服务器网络环境本身会有很大的关系，如果不能做现场测试，采用的两个解决办法：i）尽可能的模拟出用户环境：包括网络状况，服务器状况，ii）和用户去协商：去做现场测试。,其他需要注意的地方,1、应用服务器的Warm up问题J2ee应用或者.net应用现在都会涉及本地编译的过程，在第一次做运行的时候，在第一次访问的时候速度会很慢，第二次访问才会快起来，因为从本地Cache中读取信息，所以在应用服务器重启了以后，都必须多测几次，等服务器Warm up后再测试，否则的话，前面的结果没有有效性。整个的结果还会有误差。2、应用服务器的Cache在多次测试的过程中，把Cache功能给去掉，或者把cache给清空。3、浏览器或客户端应用的Cache客户端和浏览器的cache在录制脚本的时候都应该去掉。,确定最小用户负载,确定最小用户负载的目的为了全面掌握应用程序的性能不仅是重压条件下，而且是在更为理想的条件下。这是很重要的，因为应用程序通常将大部分的时间花费在这些低负载条件下。峰值操作通常很少发生。确定最小用户负载的方法从需求上解决，了解业务分布情况，将业务分布情况划分成不同的场景，确定一个负载使用状况最小的场景。执行此场景，观察系统在此场景下的运行状况。,性能测试的两个基本类别,预备测试预备测试：最初的试探性测试，让我们能够感受一下应用程序的性能并优化测试环境。正式测试有四个正式的性能测度，我们的分析就建立在这些测度上。可以将这些正式测试按照类型分成如下几个子类：单实例压力测试、持久测试、体系结构测试一旦按照初步测试结果设置好了环境和测试参数（测试脚本、思考时间、采样方法等等），这些因素就必须对任何特定的性能测试都保持不变。如果在某个特定的性能测试中修改任何参数，那么我们就破坏了结果的可比较性，将不得不重新执行测试。,性能测试生存周期,规划性能分析创建有效的压力脚本执行压力测试分析性能测试数据来确定和解决性能瓶颈,规划性能分析阶段的工作包括收集重要的原始数据，然后根据这些信息制订测试方案。规划阶段收集到的信息至少应该描述两个方面的内容：用来复制一个接近生产环境的测试环境的细节。对该应用程序的使用方式的理解，以及临界性能表现的迹象等。这些信息可以来源于市场预测报告、站点的WEB日志、站点的性能日志和站点功能说明等。创建高效的压力测试脚本 在收集了所需信息并搭建了测试环境后，下一步就是创建测试脚本，它应该能够准确地模拟站点期望地流量。最有效地方式是根据实况网站中的历史数据结合市场调查或商业分析而得到这些期望数据。,执行压力测试 创建可以模拟最大用户负载的压力测试脚本。分析性能测试结果(i)确定性能瓶颈影响终端用户响应时间的瓶颈包括应用程序和服务器的吞吐量、终端到终端的Internet连接速度以及网络涌塞等。（ii）检验性能优化结果分析结果了解系统的性能状况并能够对性能进行提高。,用户思考时间的问题,创建测试脚本的时候，可以选择使用用户思考时间，主要考虑到用户在访问系统过程中的思考时间，因此能帮助我们更好地模拟实际情况下的应用程序使用情况，但在对新框架的测试中，因为只需验证框架的稳定性和框架所能承受的并发用户数及页面响应时间就不需考虑用户的业务使用情况。另外，使用用户思考时间会降低客户端能够产生的最大负载量，会影响到对最大负荷下系统的性能表现的计算结果。而且，如果客户端发送请求的能力本身就存在不足的话，将更加难以发现性能瓶颈，因为瓶颈往往是在系统承担最大负载时表现出来的。,确定负载增加的标准,确定压力测试需要进行的程度，首先需要指定一个标准，确定何时达到适当的压力级别。我在这里举一些可能的测试标准的例子：当一定数量的错误出现在事件或Web服务器的日志中时，停止继续增加负载。不断增加负载，直到吞吐量开始下降。给CPU利用率设置一个极限值（框架中考虑8090）给内存的利用率设置一个极限值。给页面响应时间设置一个极限值根据业务需要事先确定Web应用程序能够处理的每秒请求数或同时连接数,