|
|
知识路径： > 测试技术的分类 > 应用负载压力测试 > 负载压力测试实施 >
|
|
相关知识点：77个
|
|
|
|
|
制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程，包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。在任何类型的系统测试中，制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于：
|
|
|
|
①构建能够精确地模拟工作环境的测试方案。负载测试指在典型的工作条件下测试应用程序，并检测系统的性能、可靠性和容量等。
|
|
|
|
②了解测试需要的资源。应用程序测试需要硬件、软件和人力资源。开始测试之前，应了解哪些资源可用并确定如何有效地使用这些资源。
|
|
|
|
③以可度量的指标定义测试成功条件。明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标（如检测重负载情况下的服务器响应时间）是不够的。明确的成功条件应类似于“50个客户能够同时查看他们的账户余额，并且服务器响应时间不超过1分钟”。
|
|
|
|
|
|
|
|
负载测试计划的第一步是分析应用程序。应该对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。应用程序分析可以确保使用的测试环境能够在测试中精确地反映应用程序的环境和配置。
|
|
|
|
|
|
绘制一份应用程序结构示意图。如果可能，从现有文档中提取一份示意图。如果要测试的应用程序是一个较大的网络系统的一部分，应该确定要测试的系统组件。确保该示意图包括了所有的系统组件，例如客户机、网络、中间件和服务器等。
|
|
|
|
如下图所示说明了一个由许多Web用户访问的联机银行系统。各Web用户连接到同一数据库以转移现金和支票余额。客户使用不同的浏览器，通过Web方式连接到数据库服务器。
|
|
|
|
|
|
|
|
|
|
增加更多详细信息以完善示意图。描述各系统组件的配置。应当掌握以下信息：
|
|
|
|
|
|
. 应用程序客户端计算机的配置情况（硬件、内存、操作系统、软件、开发工具等）；
|
|
|
|
. 使用的数据库和Web服务器的类型（硬件、数据库类型、操作系统、文件服务器等）；
|
|
|
|
|
|
. 前端客户端与后端服务器之间的中间件配置和应用程序服务器；
|
|
|
|
. 可能影响响应时间的其他网络组件（调制解调器等）；
|
|
|
|
. 通信设备的吞吐量以及每个设备可以处理的并发用户数。
|
|
|
|
例如，在如上图所示的示意图中，多个应用程序客户端在访问系统。客户端的配置如下表所示。
|
|
|
|
|
|
|
|
|
|
定义系统的典型使用方式，并确定需要重点测试的功能。考虑哪些用户使用系统、每种类型用户的数量，以及每个用户的典型任务。此外，还应考虑任何可能影响系统响应时间的后台负载。
|
|
|
|
例如，假设每天上午有200名员工登录记账系统，并且该办公室网络有固定的后台负载：50名用户执行各种字处理和打印任务。可以创建一个200个虚拟用户登录访问记账数据库的方案，并检测服务器的响应时间。要了解后台负载对响应时间的影响，可以在运行方案的网络中再模拟员工执行字处理和打印活动的负载。
|
|
|
|
|
|
除定义常规用户任务外，还应该查看这些任务的分布情况。例如，假设银行用户使用一个中央数据库为跨越多个州和时区的客户提供服务。250个应用程序客户端分布在两个不同的时区，全都连接到同一个Web服务器中。其中150个在芝加哥，另外100个在底特律。每个客户端从上午9点开始工作，但由于处于不同的时区，因此在任何特定时间内都不会有超过150个的用户同时登录。可以分析任务分布，以确定数据库活动峰值期的发生时间，以及负载峰值期间的典型活动。
|
|
|
|
|
|
|
|
|
|
确定了负载测试的一般性目标后，应该以可度量指标制定更具针对性的目标。为了提供评估基准，应精确地确定、区分可接受和不可接受测试结果的标准。
|
|
|
|
|
|
|
|
. 明确目标产品评估：在一台HP服务器和一台NEC服务器上运行同一个包含300个虚拟用户的组。当300个用户同时浏览Web应用程序页面时，确定哪一种硬件提供更短的响应时间。
|
|
|
|
|
|
①度量最终用户的响应时间，完成一个业务流程需要多长时间；
|
|
|
|
②定义最优的硬件配置，哪一种硬件配置可以提供最佳性能；
|
|
|
|
③检查可靠性，系统无错误或无故障运行的时间长度或难度；
|
|
|
|
|
|
|
|
⑥度量系统容量，在没有显著性能下降的前提下，系统能够处理多大的负载；
|
|
|
|
|
|
|
|
负载测试应贯穿于产品的整个生命周期。如下表说明了在产品生命周期的各个阶段有哪些类型的测试与之相关。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
可以度量应用程序中不同点的响应时间。根据测试目标确定在哪里运行Vuser（虚拟用户）以及运行哪些Vuser。
|
|
|
|
|
|
可以在前端运行GUI Vuser（图形用户界面用户）或RTE Vuser（终端用户）来度量典型用户的响应时间。GUI Vuser可以将输入提交给客户端应用程序并从该应用程序接收输出，以模拟实际用户；RTE Vuser则向基于字符的应用程序提交输入，并从该应用程序接收输出，以模拟实际用户。
|
|
|
|
可以在前端运行GUI或RTE Vuser来度量跨越整个网络（包括终端仿真器或GUI前端、网络和服务器）的响应时间。如下图所示为端到端的响应时间。
|
|
|
|
|
|
|
|
|
|
可以通过在客户机运行Vuser（非GUI或RTE Vuser）来度量网络和服务器的响应时间（不包括GUI前端的响应时间）。Vuser模拟客户端对服务器的进程调用，但不包括用户界面部分。在客户机运行大量Vuser时，可以度量负载对网络和服务器响应时间的影响。如下图所示为网络和服务器的响应时间。
|
|
|
|
|
|
|
|
|
|
可以通过减去前两个度量值，来确定客户端应用程序界面对响应时间的影响。GUI响应时间=端到端响应时间-网络和服务器响应时间。如下图所示为GUI响应时间。
|
|
|
|
|
|
|
|
|
|
可以度量服务器响应请求（不跨越整个网络）所花费的时间。通过在与服务器直接相连的计算机上运行Vuser，可以度量服务器性能。如下图所示为服务器响应时间。
|
|
|
|
|
|
|
|
|
|
如果可以访问中间件及其API，便可以度量服务器到中间件的响应时间。可以使用中间件API创建Vuser，来度量中间件到服务器的性能。如下图所示为中间件到服务器响应时间。
|
|
|
|
|
|
根据对Vuser类型的分析以及它们的典型任务和测试目标来创建Vuser脚本。由于Vuser模拟典型最终用户的操作，因此Vuser脚本应包括典型的最终用户任务。例如，要模拟联机银行客户端，应该创建一个执行典型银行任务的Vuser脚本。需要浏览经常访问的页面，以转移现金或支票余额。
|
|
|
|
|
|
|
|
根据测试目标确定要衡量的任务，并定义这些任务的事务。这些事务度量服务器响应Vuser提交的任务所花费的时间（端到端时间）。例如，要查看提供账户余额查询的银行Web服务器的响应时间，则应在Vuser脚本中为该任务定义一个事务。
|
|
|
|
此外，可以通过在脚本中使用集合点来模拟峰值期活动。集合点指示多个Vuser在同一时刻执行任务。例如，可以定义一个集合点，以模拟70个用户同时更新账户信息的情况。
|
|
|
|
|
|
确定用于测试的硬件配置之前，应该先确定需要的Vuser的数量和类型。要确定运行多少个Vuser和哪些类型的Vuser，请综合考虑测试目标来查看典型的使用模型。以下是一些一般性规则：
|
|
|
|
. 使用一个或几个GUI用户来模拟每一种类型的典型用户连接；
|
|
|
|
|
|
. 运行多个非GUI或非RTE Vuser来生成每个用户类型的其余负载。
|
|
|
|
例如，假设有五种类型的用户，每种用户执行一个不同的业务流程，如下表所示。
|
|
|
|
|
|
|
|
|
|
硬件和软件应该具有强大的性能和足够快的运行速度，以模拟所需数量的虚拟用户。
|
|
|
|
在确定计算机的数量和正确的配置时，请考虑以下事项。
|
|
|
|
|
|
. 在一台Windows计算机只能运行一个GUI Vuser；而在一台UNIX计算机上则可以运行几个GUI Vuser。
|
|
|
|
. GUI Vuser测试计算机的配置应该尽量与实际用户的计算机配置相同。
|
|
|
|
关于每个测试组件的硬件要求，请参考下表一和下表二。要获得最佳性能，应满足表中所列要求。
|
|
|
|
|
|
|
|
注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。
|
|
|
|
|
|
http://www.mercuryinteractive.com/products/loadrunner/technical/
|
|
|
|
|
|
|
|
注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。
|
|
|
|
|
|
测试计划应该基于明确定义的测试目标。下面概述了常规的测试目标。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。如下图显示了一个银行应用程序的负载和响应时间度量之间的关系。
|
|
|
|
|
|
|
|
|
|
检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。
|
|
|
|
例如，可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异。
|
|
|
|
|
|
|
|
|
|
|
|
确定系统在连续的高工作负载下的稳定性级别。可以创建系统负载：强制系统在短时间内处理大量任务，来模拟系统在数周或数月的时间内通常会遇到的活动类型。
|
|
|
|
|
|
执行回归测试，以便对新旧版本的硬件或软件进行比较。可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。应用程序回归测试需要查看新版本的效率和可靠性是否与旧版本相同。
|
|
|
|
|
|
可以运行测试，以评估单个产品和子系统在产品生命周期中的计划阶段和设计阶段的表现。例如，可以根据评估测试来选择服务器的硬件或数据库套件。
|
|
|
|
|
|
可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。使用负载压力测试工具，以及网络和计算机监视工具以生成负载，并度量系统中不同点的性能。如下图所示为系统不同点的性能。
|
|
|
|
|
|
|
|
|
|
度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量，可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定了当前容量后，便可以确定是否需要增加资源以支持额外的用户。如下图所示为响应时间与负载关系。
|
|
|
|
|
|
|
