每一个性能测试计划中第一步都会制定目标和分析系统构成

每一个性能测试计划中第一步都会制定目标和分析系统构成。只有明确目标和了解系统构成才会澄清测试范围，知道在测试中要掌握什么样的技术。目标：1. 确定客户需求和期望2. 实际业务需求3. 系统需求系统组成系统组成这里包含几方面含义：系统类别，系统构成，系统功能等。了解这些内容的本质其实是帮助我们明确测试的范围，选者适当的测试方法来进行测试。系统类别：分清系统类别是我们掌握什么样的技术的前提，掌握相应技术做性能测试才可能成功。例如：系统类别是bs结构,需要掌握 http协议，java，html等技术 。或者是cs结构，可能要了解操作系统，winsock，com等。所以甄别系统类别对于我们来说很重要。系统构成：硬件设置，操作系统设置是性能测试的制约条件，一般性能测试都是利用测试工具模仿大量的实际用户操作，系统在超负荷情形下运作。不同的系统构成性能测试就会得到不同的结果。系统功能：系统功能指系统提供的不同子系统，办公管理系统中的公文子系统，会议子系统等，系统工能是性能测试中要模拟的环节，了解这些是必要的。选择测试度量的方法经过第一步，将会对系统有清醒的认识。接下来我们将把精力放在软件度量上，收集系统相关的数据。度量的相关方面：* 制定规范* 制定相关流程, 角色，职责* 制定改进策略* 制定结果对比标准学习的相关技术和工具性能测试是通过工具，模拟大量用户操作，对系统增加负载。所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能测试工具一般通过winsock,http等协议纪录用户操作。而协议选择是基于软件的系统架构实现(web一般选择http协议,cs选择winsock协议)，不同的性能测试工具，脚本语言也不同，比如rational robot中vu脚本用类c语言实现。开展性能测试需要对各种性能测试工具进行评估，因为每一种性能测试工具都有自身的特点，只有经过工具评估，才能选择符合现有软件架构的性能测试工具。确定测试工具后，需要组织测试人员进行工具的学习，培训相关技术。制定评估标准任何测试的目的都是确保软件符合预先规定的目标和要求。性能测试也不例外。所以必须制定一套标准。通常性能测试有四种模型技术可用于评估：*线性投射：用大量的过去的，扩展的或者将来可能发生的数据组成散布图，利用这个图表不断和系统的当前状况对比。*分析模型：用排队论公式和算法预测响应时间，利用描述工作量的数据和系统本质关联起来*模仿：模仿实际用户的使用方法测试你的系统*基准：定义测试和你最初的测试作为标准，利用它和所有后来进行的测试结果进行对比设计测试用例设计测试用例是在了解软件业务流程的基础上。设计测试用例的原则是受最小的影响提供最多的测试信息，设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试用例，尽可能把性能测试用例设计的复杂，才有可能发现软件的性能瓶颈。运行测试用例通过性能测试工具运行测试用例。同一环境下作的性能测试得到的测试结果是不准确的，所以在运行这些测试用例的时候，需要用不同的测试环境，不同的机器配置上运行。分析测试结果运行测试用例后，收集相关信息，进行数据统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。不同的体系结构分析测试结果的方法也不同，bs结构我们会分析网络带宽，流量对用户操作响应的影响，而cs结构我们可能更关心会系统整体配置对用户操作的影响。本文介绍的性能测试方法不依赖任何测试工具，对于如何开展性能测试起到一个指导作用。如何编写性能测试用例发布: 2009-12-10 13:38 | 作者: 网络转载 | 来源: 领测软件测试网 | 查看: 77次 | 进入软件测试论坛讨论 领测软件测试网 由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别。性能测试的目的：为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。性能测试指标的来源：用户对各项指标提出的明确需求;如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。(需求+经验)主要的性能指标：服务器的各项指标(CPU、内存占用率等)、后台数据库的各项指标、网络流量、响应时间。BUG观点：1、性能测试就象人在无风情况下跑步(正常情况下的性能指标);2、压力测试就象人在微风中跑步(在正常的基础上加大多少百分比压力的性能指标);3、负载测试就象人在强风中跑步(不断加压，直到系统崩溃)。HTTP观点：1、 负载测试是正常情况下持续的加压;2、 压力测试是直接加压达到一个极限值。大家统一的观点：性能测试、压力测试、负载测试密不可分，可统称为性能测试。性能测试要点：1、 性能测试是在功能测试完成之后进行。2、 性能测试计划、方案一般与测试用例统一在一个文档里。3、 测试环境应尽量与用户环境保持一致。4、 性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。 5、 性能测试的重点在于前期数据的设计与后期数据的分析。6、 性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。(说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计用例。但是如果某个功能有较大的修改，性能测试也应该进行重新测试。)性能测试的指标及其所需注意的地方(一)性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。b一、概述/b性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。应用在客户端性能的测试应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。并发性能测试是重点并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候，尤其是以后在生产环境中实际使用起来，用户往往会产生疑问，这套系统能不能承受大量的并发用户同时访问？ 这类问题最常见于采用联机事务处理（OLTP）方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。举例说明：电信计费软件众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生费用，然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤，但当成百上千的终端，同时执行这样的操作时，情况就大不一样了，如此众多的交易同时发生，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力， 预见软件的并发承受力， 这是在软件测试阶段就应该解决的问题。目前，大多数公司企业需要支持成百上千名用户，各类应用环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。如何模拟实际情况呢？ 找若干台电脑和同样数目的操作人员在同一时刻进行操作，然后拿秒表记录下反应时间？这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况，这样就需要压力测试工具的辅助。测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力，就为最终用户规划整个运行环境的配置提供了有力的依据。并发性能测试前的准备工作测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。测试工具：并发性能测试是在客户端执行的黑盒测试，一般不采用手工方式，而是利用工具采用自动化方式进行。目前，成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。 测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。性能测试的指标及其所需注意的地方2作者：佚名来源：51testing2008年10月13日进入社区 并发性能测试的种类与指标并发性能测试的种类取决于并发性能测试工具监控的对象，以QALoad自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java scrpt等不同的监控对象，支持Windows和UNIX测试环境。最关键的仍然是测试过程中对监控对象的灵活应用，例如目前三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都采用了国产中间件，选择Java scrpt监控对象，手工编写脚本，可以达到测试目的。采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。并发性能测试监控的对象不同，测试的主要指标也不相同，主要的测试指标包括交易处理性能指标和 UNIX资源监控。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最小服务器响应时间；Mean：平均服务器响应时间；Max：最大服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大，偏差越大；Median：中值响应时间；90：90事务处理的服务器响应时间）、虚拟并发用户数。应用实例：“新华社多媒体数据库 V1.0”性能测试中国软件评测中心（CSTC）根据新华社技术局提出的多媒体数据库（一期）性能测试需求和GB/T 17544软件包质量要求和测试的国家标准，使用工业标准级负载测试工具对新华社使用的“新华社多媒体数据库 V1.0”进行了性能测试。性能测试的目的是模拟多用户并发访问新华社多媒体数据库，执行关键检索业务，分析系统性能。性能测试的重点是针对系统并发压力负载较大的主要检索业务，进行并发测试和疲劳测试，系统采用 B/S运行模式。并发测试设计了特定时间段内分别在中文库、英文库、图片库中进行单检索词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳测试案例为在中文库中并发用户数200，进行测试周期约8小时的单检索词检索。在进行并发和疲劳测试的同时，监测的测试指标包括交易处理性能以及 UNIX（Linux）、Oracle、Apache资源等。测试结论：在新华社机房测试环境和内网测试环境中，100M带宽情况下，针对规定的各并发测试案例，系统能够承受并发用户数为200的负载压力，最大交易数/分钟达到78.73，运行基本稳定，但随着负载压力增大，系统性能有所衰减。系统能够承受200并发用户数持续周期约8小时的疲劳压力，基本能够稳定运行。通过对系统UNIX（Linux）、Oracle和Apache资源的监控，系统资源能够满足上述并发和疲劳性能需求，且系统硬件资源尚有较大利用余地。当并发用户数超过200时，监控到HTTP 500、connect和超时错误，且Web服务器报内存溢出错误，系统应进一步提高性能，以支持更大并发用户数。建议进一步优化软件系统，充分利用硬件资源，缩短交易响应时间。疲劳强度与大数据量测试疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。疲劳强度测试可以采用工具自动化的方式进行测试，也可以手工编写程序测试，其中后者占的比例较大。一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。速度测试目前主要是针对关键有速度要求的业务进行手工测速度，可以在多次测试的基础上求平均值，可以和工具测得的响应时间等指标做对比分析。应用在网络上性能的测试 应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。网络应用性能分析网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，例如Application Expert，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间；利用Application Expert调整应用在广域网上的性能；Application Expert能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。用门的概念理解响应时间和吞吐量之间的关系发布: 2008-6-12 12:08 | 作者: 老徐 | 来源: 测试时代采编 | 查看: 126次 | 进入软件测试论坛讨论 领测软件测试网 性能测试的目的是检查软件的平均响应时间或者吞吐量是否符合指定的标准。例如，当测试前已经获知在线人数为10000，可以设定性能测试的目的是检测软件典型交易的平均响应时间是否符合小于5秒的指标值。例如，当测试前不知道在线人数是多少，但是已经获知该软件在一定的时间周期内（t）必须处理N笔交易，可以设定性能测试的目的是检测软件典型交易的吞吐量是否符合大于25笔交易/秒的指标值。但是，在第二种情况出现时，还应该考虑若软件的吞吐量符合指定的指标值时，软件典型交易的平均响应时间是否符合小于5秒的指标值。为什么呢？我们可以利用“门”的概念来理解这里面的偏差！首先，我们假设如下的情况：共有5个人；有1扇门；一个人通过这扇门需要花费1秒的时间； 此时，这扇门的吞吐量为1人/秒。5个人通过这扇门的平均响应时间为（1+2+3+4+5）/5=3秒。如何才能提高人的通过效率呢？即，如何才能提高门的吞吐量呢？有两种方法：（1）减小通过门的时间；（2）增加门的数量例如，（1）将一个人通过门的时间减小为0.5秒，门的吞吐量变成了2人/秒；（2）增加一个门，门的吞吐量也变成了2人/秒结果是：（1）5个人通过改善通过时间的门的平均响应时间为（0.5+1+1.5+2+2.5）/51.5秒；（2）5个人通过两扇门的平均响应时间为（1+1+2+2+3）/51.8秒此时，你可以发现，软件开发员改进软件处理并发交易请求的方法有两个，第一种是提高单个请求的处理速率，第二种是增加处理请求的线程的数量；或者是两种方法的组合。但是，不同方法的使用并不代表吞吐量得到了提高，而同时软件典型交易的平均响应时间也获得了相同值的改善。因此，在性能测试以吞吐量为检测指标的时候，不光要评估吞吐量是否符合了性能指标的要求，同时也必须考虑响应时间是否符合性能指标的要求。假设，在测试前，规定了吞吐量为大于25笔交易/秒，平均响应时间为小于5秒，在测试后，若实际吞吐量等于27笔交易/秒，不能仅凭这个27笔交易/秒就确定该软件的性能符合要求了，还要看平均响应时间是否符合要求。这时的平均响应时间可能大于5秒。而，如果测试前，规定了在线人数为10000，平均响应时间为小于5秒，在测试后，仅凭实际平均响应时间等于4秒就可以判断该软件的性能符合要求。LoadRunner参数分析Transactions（用户事务分析）用户事务分析是站在用户角度进行的基础性能分析。1、Transation Sunmmary（事务综述）对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。2、Average Transaciton Response Time（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。3、Transactions per Second（每秒通过事务数/TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。4、Total Transactions per Second（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。5、Transaction Performance Sunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。6、Transaction Response Time Under Load（事务响应时间与负载）“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。7、Transaction Response Time(Percentile)（事务响应时间(百分比)）“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。8、Transaction Response Time(Distribution)（事务响应时间(分布)）“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。Web Resources（Web资源分析）Web资源分析是从服务器入手对Web服务器的性能分析。1、Hits per Second（每秒点击次数）“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。2、Throughput（吞吐率）“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用户在任何给定的每一秒从服务器获得的数据量。可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。“吞吐率”图和“点击率”图的区别：“吞吐率”图，是每秒服务器处理的HTTP申请数。“点击率”图，是客户端每秒从服务器获得的总数据量。3、HTTP Status Code Summary（HTTP状态代码概要）“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。4、HTTP Responses per Second（每秒HTTP响应数）“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。5、Pages Downloader per Second（每秒下载页面数）“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。6、Retries per Second（每秒重试次数）“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。在下列情况将重试服务器连接：A、初始连接未经授权B、要求代理服务器身份验证C、服务器关闭了初始连接D、初始连接无法连接到服务器E、服务器最初无法解析负载生成器的IP地址7、Retries Summary（重试次数概要）“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。8、Connections（连接数）“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。借助此图，可以知道何时需要添加其他连接。例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。9、Connections Per Second（每秒连接数）“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。10、SSLs Per Second（每秒SSL连接数）“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。Web Page Breakdown（网页元素细分）“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的元素。1、Web Page Breakdown（页面分解总图）“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。“页面分解”图可以按下面四种方式进行进一步细分：1)、Download Time Breaddown（下载时间细分）“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。2)、Component Breakdown(Over Time)（组件细分(随时间变化)）“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。3)、Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。4)、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。2、Page Component Breakdown（页面组件细分）“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。3、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)）“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。4、Page Download Time Breakdown（页面下载时间细分）“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。5、Page Download Time Breakdown(Over Time)（页面下载时间细分(随时间变化)）“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。6、Time to First Buffer Breakdown（第一次缓冲时间细分）“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。7、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。8、Downloader Component Size(KB)（已下载组件大小）“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。LoadRunner对ezFas消防监控软件性能测试的数据分析摘 要：本文介绍了同方ezFas消防监控软件的主要性能数据，论述了各种性能指标在测试中的用途。关键词： 场景 性能数据 性能分析Abstract: The article introduces the main performance datas of TongFang ezFas software and the use of datas in testing.Keywords: Scene ,Performance Data ,Performance Analysis1ezFas消防监控软件网页的基本概况 ezFAS消防监控软件是同方股份公司开发的一个功能强大的城市火灾远程监控管理平台，主要面向大型火灾监控管理中心如省市、大型厂矿企业、石油、各类区域和行业内部的消防管理部门，为主管部门提供实时报警、视频监听、故障检测、统计分析等功能。 该系统包括报警受理系统，用户服务系统，信息查询系统，火警信息终端四部分组成。报警受理系统主要为监控中心提供实时报警，用户管理，视频查看，人员考勤，报表生成等各大主要功能。下面就对这套主要的报警受理系统的性能数据进行分析。2测试环境服务器：CPU 型号：Inter(R) Core(TM)2 Duo T5450主频：1.66GHZ内存容量：1.00GB操作系统：Microsoft Windows Server 2003 Enterprise Edition SP2客户端：CPU 型号：Intel Pentium III主频:930MHZ内存容量：640MB操作系统：Microsoft Windows XP Professional SP2 网络环境：在测试网络中有且仅有两台测试计算机，测试机之间通过1个Hub连接。3 测试场景 用户进入登陆模块，总共登陆500个用户，每分钟登陆10个用户。用户点击“ASE管理”，用户在查询的区县里面选择“石河子市”然后点击查找。查找结束后点击“退出”按钮，退出系统。4 性能数据分析 我们对500个用户的同时登陆进程，进行每5分钟增加10个用户的加压测试。此次测 试在250分钟后结束。4.1 Transactions Sunmmary(事务综述) 用户事务分析是站在用户角度进行的基础性能分析。此次测试一共运行的事务数为9690145，成功 968750，失败250。 观察发现随着用户数量的不断增加，失败的事务开始出现，并且出现的频率逐步升高。当程序运行到200个用户同时登陆时，失败事务开始出现。由此可以直接判断出当200个用户同步登陆时系统运行出现异常。此系统最大承受压力为200个用户同步登陆。 但考虑到此套系统主要用于省级市的监控，对于最大的省份，监控中心数量不会超过50个，所有监控中心的用户同时登陆数量也不会超过100个。此套系统最大承受压力为200，所以性能已经大大超过要求，并不需要花费时间和精力优化系统的运行稳定性。4.2 Average Transaciton Response Time(事务平均响应时间) 事务平均响应时间显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间系统性能的走向。如果随着测试时间的变化，系统处理事务的速度开始逐渐变慢就说明应用系统随着投产时间的变化整体性能将会有下降的趋势。在这次250分钟的测试中，事务相应平均时间没有大幅度的变化，但这不能说明系统就是稳定的，250分钟的测试时间很短，所以我们针对这个结果单独进行了5天持续不断的测试，发现性能也没有变化。说明整体性能过关。 将它与Transactions per Second(每秒通过事务数/TPS)进行对比，来分析事务数目对执行时间的影响。如果当压力加大时，点击率/TPS曲线变化缓慢且有了平坦的趋势，则可能是服务器开始出现瓶颈。但是在这次测试中TPS曲线随着压力的加大曲线变化成正比增加，这此台测试服务器完全能满足要求。在工程施工中只要服务器配置达到此台服务器配置即可。*Transactions per Second (每秒通过事务数/TPS):显示在场景运行的每一秒钟，每个事物通过、失败以及挺直的数量，是考察系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。4.3 Transaction Response Time(Distribution)(事务相应时间分布) “事务相应时间分布”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同相应时间的事物数量。如果我们预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围呢。此次测试定义了登陆时间3秒，查询时间5秒，退出时间2秒。从图片上看出登陆和退出时间完全符合要求，但是查询时间随着用户的不断增多以密指数的比例变大，当用户超过200个同时查询时，反映时间已经达到10秒以上。不能满足系统需要。经过对程序的分析发现，查询时需要调用的表过多，设计太过复杂。将表单的设计简单化即可解决问题。以前表结构的设计： 现在将所有内容统一到一张表格中：经过对程序的修改后再次进行测试，问题已经解决，所有用户同时查询时反映时间也在要求之下。4.4 Hits per Second(每秒点击次数) “每秒点击次数”是运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。同uota可以评估虚拟用户长生的负载量。 下面我们将它和“平均事务响应时间”图比较，来查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。图1 红色为平均响应时间，黑色线为点击率 由这两个合并的图肯出点击率随着用户的增加在正比的增长，平均相应时间也没有大幅度的波动，可以判断出系统是稳定的。如果系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，再寻找系统瓶颈所在。 如果发现系统点击率下降，那我们将进一步和“吞吐率”图进行比较，来寻找系统地瓶颈。此比较可以看出服务器在流量方面的处理能力以及是否存在瓶颈。 “吞吐量”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用户在任何给定的每一秒从服务器获得的数据量。可以依据服务器的吞吐量来评估虚拟用户长生的负载量。图2 服务器在流量方面存在瓶颈图 3 服务器流量方面不存在瓶颈4.5 单用户系统登陆和查询报警信息资源特性表资源特性表 最小值 平均值 最大值 服 务 器 资 源 特 性 内存 Memory%Committed Bytes In Use32.2832.3332.53Available Mbytes2777.002806.702819.00Page Faults/sec0.00931.1013132.41Pages/sec0.000.5131.01网络Network InterfaceBytes Total/sec0.0067176.29542971.81Packets/sec0.0072.23365.31磁盘PhysicalDiskAvg.Disk Queue Length0.000.000.00Current Disk Queue Length0.000.000.00Disk Read Bytes/sec0.004763.27169783.70Disk Write Bytes/sec0.0063037.90877130.31处理器Processor%Processor Time0.001.4614.11%User Time0.000.607.07系统SystemProcessor Queue Length0.000.000.00表1单用户执行系统登陆 资源特性表 最小值 平均值 最大值 服 务 器 资 源 特 性 内存 Memory%Committed Bytes In Use31.5631.6031.79Available Mbytes2583.002590.812592.00Page Faults/sec0.001113.938505.05Pages/sec0.000.000.00网络Network InterfaceBytes Total/sec0.00178899.04485509.91Packets/sec0.00143.32376.32磁盘 PhysicalDiskAvg.Disk Queue Length0.000.000.00Current Disk Queue Length0.000.000.00Disk Read Bytes/sec0.003355.48157707.59Disk Write Bytes/sec0.0056338.18377564.00处理器 Processor%Processor Time0.001.686.08%User Time0.000.702.78系统SystemProcessor Queue Length0.000.000.00表2单用户查询ASE信息 以上是对于测试性能的一些最基本的数据分析，如果测试性能涉及到SQL Server,我在下面列出比较关键的几个数据。ObjectCountersDescriptionProcessor%Processor timeCPU使用率 SQL Server:Logins/sec这是每秒登陆到SQLServer 的计数 SQL Server:CacheManageCache Hit Ratio(all instances)显示在高速缓存中找到数据的命中率。如果数值持续小于85%，则表示内存有问题。 SQL Server:General StatisticsUser Connevtions显示当前SQL用户数。与Active Server Pages:Requests/Sec计数器进行比较，可帮助了解脚本对 SQL Server 的影响程度。如果差别过大，则表示测试脚本不能有效地对 SQL Server进行应力 测试 SQL Server: LocksLock Waits/sec显示在当前进程完成之前强制其他进程等待的每秒锁定请求的数量。如果该值始终大于0，则表示事务有问题。 SQL Server: BuffeManageBuffer Manager Hit Ratio计数器值依应用程序而定，但比率最好为90%或更高。增加内存直达这一数值持续高于90%，表示90%以上的数据请求可以从数据缓冲区中获得所需数据。 SQL Server:SQL StatisticsBatch Requests/sec每秒收到 Transact-SQL命令批数。这一统计信息所有约束（如 I/O、用户数、高速缓存大小、请求I/O、用户数、高速缓存大小、请求的复杂程度等）影响。批请求数值高意味着吞吐量很好。 SQL Server:DatabasesTransactions/sec每秒位数据库启动的事务数 表3 SQL Sever 数据5结论 测试结果表明，500个用户在并发登陆系统，查询ASE信息，退出系统的响应时间分别不超过2秒和5秒。服务器资源占用情况正常。系统在模拟测试环境中运行稳定，可以通过。web性能测试 1.1基本概念并发用户：用户并发一般发生在使用比较频繁的模块中，而且遇到异常通常都是程序的问题。用户并发数量：在线用户数量是计算并发用户数量的主要依据之一。=使用系统的用户数量*(5%20%)并发主要针对WEB服务器而言，是否并发的关键是看用户的操作是否对服务器产生了影响。吞吐量：一次性能测试过程中网络上传输的数据量的总和。吞吐率:吞吐量/传输时间，单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量。吞吐率用“请求数/秒”或者“页面数/秒”来衡量。点击率：每秒钟用户向web服务器提交的HTTP请求数。点击率越大，对服务器的压力也越大。重要的是分析点击时产生的影响。点击不是指鼠标的一次“单击”操作，因为在一次“单击”操作中，客户端可能向服务器发出多个HTTP请求。1.2WEB性能测试种类压力测试：确定一个系统的瓶颈或者不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。负载测试：在被测系统上不断增加压力，直到性能指标达到极限，响应时间超过预定指标或者某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供依据。大数据量测试：针对某些系统存储、传输、统计查询等业务进行大数据量的测试。配置测试：通过测试找到系统各资源的最优分配原则。可靠性测试：可以施加cpu资源保持70%-90%使用率的压力，连续对系统加压运行8小时，然后根据结果分析系统是否稳定。即加载一定压力的情况下，使系统运行一段时间。并发测试：多以发现一些算法设计上的问题。性能测试以用户并发测试为主的测试。性能测试主要是为了发现软件问题和硬件瓶颈。对于性能方面给系统留有30%左右的扩展空间即可。 1.3Web全面性能测试模型1.3.1预期指标的性能测试主要指需求分析和设计阶段提出的一些性能指标。针对每个指标都要编写一个或者多个测试用例