LoadRunner之性能测试基本概念

在一些软件项目中，项目经理或测试经理经常会安排测试工程师进行下面的工作：

　　用 LoadRunner 测试系统的最大并发用户数。
　　用 LoadRunner 测试系统 8 小时的最大业务吞吐量。
　　用 LoadRunner 测试系统的稳定性与健壮性。
　　用 LoadRunner 测试系统在数据达到 100 万条记录时的性能。
　　用 LoadRunner 测试核心事务响应时间是否满足用户的需求。

一、什么是性能测试

　　狭义的性能测试主要用于描述常规的性能测试，是指通过模拟生产运行的业务压力或用户使用场景来测试系统的性能是否满足生产性能的要求。
　　广义的性能测试则是压力测试、负载测试、强度测试、并发（用户）测试、大数据量测试、配置测试、可靠性测试等和性能相关的测试统称。

 二、各类测试的主要内容和特点介绍
　　压力测试：对系统不断施加压力的测试，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个 Web 站点在大量的负荷下，系统的事务响应时间何时会变得不可接受或事务不能正常执行。压力测试的目的是发现在什么条件下系统的性能变得不可接受，并通过对应用程序施加越来越大的负载，直到发现应用程序性能下降的拐点。压力测试和负载测试有些类似，但是通常把负载测试描述成一种特定类型的压力测试——例如增加用户数量或延长压力时间以对应用程序进行压力测试。
　　负载测试：对系统不断地增加压力或增加一定压力下的持续时间，直到系统的一些性能指标达到极限，例如响应时间超过预定指标或某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供依据。压力测试侧重压力大小，而负载测试往往强调压力持续的时间。在实际工作中，没有必要严格区分这两个概念。
　　强度测试：强度测试主要是为了检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如：
　　　　当正常的用户点击率为“1000 次/秒”时，运行点击率为“2000 次/秒”的测试用例；
　　　　运行需要最大存储空间（或其他资源）的测试用例；
　　　　运行可能导致操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。
强度测试是一种特别重要的测试，对测试系统的稳定性，以及系统未来的扩展空间均具有重要的意义。在这种异常条件下进行的测试，更容易发现系统是否稳定以及性能方面是否
容易扩展。
　　疲劳强度测试：是一类特殊的强度测试，主要测试系统长时间运行后的性能表现，例如 7× 24 小时的压力测试。
　　并发（用户）测试：主要指当测试多个用户并同时访问同一个应用程序、同一个模块或数据记录时是否存在死锁或其他性能问题，几乎所有的性能测试都会涉及并发测试。在具体的性能测试工作中，并发用户往往都是借助工具来进行模拟的， LoadRunner 中称之为并发虚拟用户。
　　大数据量测试：大数据量测试分为两种：一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试；另一种是与并发测试相结合的极限状态下的综合数据测试。如专项的大数据量测试主要针对前者，后者尽量放在并发测试中。此外，也可以把大数据量测试分为“运行时大数据量测试”与“历史大数据量测试”来进行测试用例设计。
　　配置测试：配置测试主要指通过测试找到系统各项资源的最优分配原则。配置测试是系统调优的重要依据。例如，可以通过不停地调整 Oracle 的内存参数来进行测试，使之达到一个较好的性能。可以看出，配置测试本质上是前面提到的某些种类的性能测试组合在一起而进行的测试。
　　可靠性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。例如，可以施加让 CPU 资源保持 70%～90%使用率的压力，连续对系统加压 8 个小时，然后根据结果分析系统是否稳定。
　　这么多类型的性能测试看起来很吓人，实际上它们大多是密切相关的。例如，运行 8 个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性测试、强度测试、并发（用户）测试、负载测试，等等。

三、性能测试应用领域

　　性能测试往往是为了实现下面的一个或几个目标：
　　　　判定软件是否满足预期的性能需求；
　　　　根据测试结果判定软件的性能表现；
　　　　查找系统可能存在的性能问题，如果有，则找出并加以解决；
　　　　发现一些应用程序在功能实现方面的缺陷；
　　　　对一些存在性能问题的系统，找出瓶颈并加以解决；
　　　　为用户部署系统提供性能参考；
　　　　……

　　通过分析性能测试的种种目标，不难总结出性能测试主要应用在几个领域中，下面分别予以介绍。
　　系统的性能瓶颈定位：系统的性能瓶颈定位是性能测试最常见的应用领域。借助 LoadRunner 等工具，可以在测试场景运行过程中监控系统资源、 Web 服务器资源等运行数据，与响应时间进行同步分析，可以在一定程度上进行性能瓶颈的分析与定位。
　　系统的参数配置：通过性能测试可以测试系统在不同参数配置下的性能表现，进而找出令系统表现更优的系统配置参数，为应用系统投产提供最佳配置建议。实际上，操作系统、数据库、中间件服务器等的参数配置是应用系统发生性能问题的重要原因。例如分配给 Oracle 的内存大小与系统自身的业务特点有极大关系，配置不同的数据库，性能表现就会不同；而即使在内存一定的情况下， SGA 的分配也会对性能产生很大的影响。因此，要通过测试，以确定内存的最佳配置。发现一些软件算法方面的缺陷一些多线程、同步并发算法在单用户模式下测试是很难发现问题的，只有通过模拟多用户的并发操作，才能验证其运行是否正常与稳定。例如作者就经历过在一次性能测试过程中，测试人员模拟多个用户并发时发现的一个明显的缺陷：测试对象是一个随机分配任务的模块，只要有用户申请，就会给用户分配任务。这个算法在单用户情况下调试没有任何问题，但是当多个用户同时申请任务时，就发生了把同一任务分配给多个不同用户的现象。经证实，这个缺陷就是“同步算法”发生了问题而引起的。
　　系统的验收测试：系统验收测试经常会验证一些预期的性能指标，或者验证系统中一些事务指标是否符合用户期望，这时就需要借助性能测试来完成验证工作。随着用户对性能的重视，现在性能测试几乎是系统验收测试中必不可少的内容之一。用户甚至自己进行专门的性能测试来验证系统上线前的性能，以保证运行时的性能稳定。因此，性能测试在用户验收测试中越来越重要。
　　系统容量规划：通过总结系统在不同硬件环境下的性能表现，可以为系统部署时提供非常好的参考。对于一些性能要求较高的系统，性能测试可以为硬件规划提供很好的参考数据，使用户在购买硬件时“有据可依”。例如同一系列机型：两颗 CPU 系统支持 500 用户并发、四颗 CPU 支持800 用户并发，这些都是用户根据自身需求来规划硬件的重要依据。
　　产品评估/选型：产品评估/选型是性能测试的又一应用领域。通过性能测试，可以对产品的软硬件性能进行更全面的评估，选出更适合自己的产品类型。

　　性能测试的应用领域越来越广，因此在实际工作中，性能测试往往会一次应用在一个或多个领域。对于软件性能测试设计人员，应该根据测试的具体应用领域、测试原则和目标来进行性能测试的规划与设计。

四、性能测试常见术语
　　并发：狭义的并发一般分两种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务。例如在信用卡审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交（操作的不是同一记录）；还有一种是特例，即所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。另外一种并发是广义的并发。这种并发与狭义的并发的区别是尽管多个用户对系统发出了请求或进行了操作， 但是这些请求或操作可以是相同的，也可以是不同的。对整个系统而言，仍然有很多用户同时对系统进行操作，因此，仍然属于并发的范畴。可以看出，广义的并发是包含狭义的并发的，而且广义的并发更接近用户的实际使用情况，因为对大多数系统而言，只有数量很少的用户进行“严格意义上的并发”。对于性能测试而言，这两种并发一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的并发一般发生在使用比较频繁的模块中，尽管发生的概率不是特别高，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为只要并发功能遇到异常通常都是程序的问题，这种测试也是健壮性和稳定性测试的一部分。
　　并发用户数量：关于并发用户的数量，有两种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把用户在线数量理解为并发用户数量。实际上，在线用户不一定会和其他用户发生并发，例如正在浏览网页信息的用户，对服务器是没有任何影响的。但是，用户在线数量是统计并发用户数量的主要依据之一。并发主要针对服务器而言，是否并发的关键是看用户的操作是否对服务器产生了影响。因此，并发用户数量的正确理解是，在同一时刻与服务器进行交互的在线用户数量。这些用户的最大特征是和服务器发生了交互，这种交互既可以是单向传送数据的，也可以是双向传送数据的。并发用户数量的统计方法目前还没有准确的公式，因为不同的系统会有不同的并发特点。例如 OA 系统统计并发用户数量的经验公式为：使用系统的用户数量×（5％～20％）。对于这个公式，没有必要拘泥于计算出的结果，因为为了保证系统的扩展空间，测试时的并发用户数量都会稍稍大一些，除非要测试系统能承受的最大并发用户数量。举例说明：如果一个 OA 系统的期望用户为 1 000 个，只要测试出系统能支持 200 个并发用户就可以了。
　　请求响应时间：请求响应时间是指从客户端发出请求到得到响应的整个过程的时间。这个过程从客户端发送一个请求开始计时，到客户端接到从服务器端返回的响应结果计时结束。在某些工具中，请求响应时间通常会被称为“TTLB”，即“Time to last byte”，意思是从发送一个请求开始，到客户端收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位一般为“秒”或“毫秒”。请求响应时间的分解如图 1-1 所示。

从图 1-1 可以看出，请求响应时间为“网络响应时间”和“应用程序与系统响应时间”之和，具体由 7 个部分组成，即(N1+N2+N3+N4)+(A1+A2+A3)。
　　事务响应时间：事务可能由一系列请求组成，事务的响应时间主要针对用户而言，属于宏观上的概念，是为了向用户说明业务响应时间而提出的。例如：跨行取款事务的响应时间就是由一系列的请求组成的。事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数。
　　吞吐量：指在一次性能测试过程中网络上传输的数据量的总和。吞吐量/传输时间，就是吞吐率。
　　吞吐率（Throughput）：通常用来指单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量。它是衡量网络性能的重要指标。但是从用户或业务角度来看，吞吐率也可以用“请求数/秒”或“页面数/秒”、 “业务数/小时或天”、 “访问人数/天”、 “页面访问量/天”来衡量。例如在银行卡审批系统中，可以用“千件/每小时”来衡量系统的业务处理能力。
　　TPS(Transaction Per Second)：每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。 TPS 是LoadRunner 中重要的性能参数指标。
　　点击率（Hit Per Second）：每秒钟用户向 Web 服务器提交的 HTTP 请求数。这个指标是 Web 应用特有的一个指标：Web 应用是“请求-响应”模式，用户发出一次申请，服务器就要处理一次，所以“点击”是 Web 应用能够处理交易的最小单位。如果把每次点击定义为一次交易，点击率和 TPS 就是一个概念。不难看出，点击率越大， 对服务器的压力也越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为在一次“单击”操作中，客户端可能向服务器发出多个 HTTP 请求。
　　资源利用率：资源利用率指的是对不同系统资源的使用程度，例如服务器的 CPU 利用率、磁盘利用率等。资源利用率是分析系统性能指标进而改善性能的主要依据，因此，它是 Web 性能测试工作的重点。资源利用率主要针对 Web 服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主要参数。在性能测试中，要根据需要采集具体的资源利用率参数来进行分析。