应用系统性能测试实践

性能测试是一种预测行为——使用测试工具模拟真实用户访问应用系统的情形，预测其在特定压力下的性能表现。应用系统真正承载的访问压力有多大，在线用户数并非唯一决定因素。性能测试通过的准则是什么，如何测试能提高测试结果的参考价值等多方面考虑使测试工作变得难以把握。通过大量实践发现，减少不确定因素，提高性能测试结果参考价值的关键在于测试前充分调研以及制定合理的测试方案。

1.1. 测试需求分析

对应用系统使用情况展开调研，分析具体性能测试需求。

表1 应用系统使用情况调研表

调研内容	内容说明	获取统计信息
用户范围	了解使用应用系统的用户范围	注册用户数、在线用户数
日常访问量	查看应用服务器的用户访问日志或数据库记录的用户操作表	工作时段服务器承受的平均压力（单位时间内客户端向服务器提交的请求数）
功能使用频率	了解使用频率较高、算法复杂、涉及大数据量的操作有哪些	使用频率较高、算法复杂、涉及大数据量的业务操作
业务数据量	统计主要功能模块日常产生的数据量	若干年内主要业务模块产生的数据量

调研工作服务于性能测试需求分析及方案设计。如上表所示，调研内容主要包括四个方面信息：用户范围、日常访问量、功能使用频率及业务数据量。通过了解应用系统的用户范围可获取注册用户数和日常工作时段在线用户数；通过统计应用服务器或数据库记录的用户操作日志可获取单位时间内服务器处理的平均请求数；通过了解用户业务可筛选出使用频率高、算法复杂、涉及大数据量的操作。通过统计主要功能模块每日或每月产生的数据量可估算1-3年内累计的数据量，为测试数据准备提供依据，以便预测未来几年内业务数据增长到一定程度后应用系统的性能表现。

与在线用户数相比，更能真实反映服务器承受多少压力的指标是单位时间内客户端提交给服务器的请求数。而在线用户数仅代表服务器当前创建的会话连接数。用户仅查看信息而不点击按钮、链接不会消耗服务器性能。而客户端单位时间内提交的平均请求数，则相对能反映服务器的繁忙程度。用户操作越频繁，提交的请求越多，服务器的工作压力就越大。但值得注意的是，点击率与服务器性能损耗并不成正比关系。算法复杂的功能执行一次，服务器处理的请求数可能会比算法简单的功能执行一次时少，但显然前者耗费更多服务器资源，服务器承受的压力更大。

总之，调研越充分越利于后续测试的执行，从而避免盲目无实效脱离客观实际的测试行为，提高测试结果的准确度及参考价值。以某企业的门户网站、业务数据统一平台和IBM DOMINO平台的协同办公系统的日常访问量调研为例，分别通过中间件WEBLOGIC访问日志、数据库表操作记录和Domino服务端日志三种不同的文档来统计系统日常承受的用户访问压力。

图1 门户系统WEBLOGIC中间件访问日志 （从左到右列值说明：客户端IP、操作时间、提交HTTP请求的方法及请求内容）

用户IP地址 访问时间 URL HTTP响应码

10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET /TECEIP/framework/skins/NWBlue/model01/css/window-model01.css HTTP/1.1" 304 0
10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET /TECEIP/framework/skins/NWBlue/model02/css/window-model02.css HTTP/1.1" 304 0
10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET /TECEIP/framework/skins/NWBlue/model03/css/window-model03.css HTTP/1.1" 304 0
10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET /TECEIP/framework/skins/NWBlue/model05/css/window-model05.css HTTP/1.1" 304 0
10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET /TECEIP/framework/skins/NWBlue/model06/css/window-model06.css HTTP/1.1" 304 0
10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET /TECEIP/framework/skins/NWBlue/model07/css/window-model07.css HTTP/1.1" 304 0
10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET /TECEIP/framework/skins/NWBlue/model08/css/window-model08.css HTTP/1.1" 304 0
10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET /TECEIP/framework/skins/NWBlue/model09/css/window-model09.css HTTP/1.1" 304 0
10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET /TECEIP/framework/skins/NWBlue/model10/css/window-model10.css HTTP/1.1" 304 0
10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET /TECEIP/framework/skins/NWBlue/model17/css/window-model17.css HTTP/1.1" 304 0
10.194.1.22 - - [07/七月/2010:17:01:46 +0800] "GET /TECEIP/appmanager/gxdwpotal/beforelogin HTTP/1.1" 200 132785
10.194.1.22 - - [07/七月/2010:17:01:48 +0800] "GET

图2 “业务数据统一平台”用户操作记录表（从左到右列值说明：登录用户名，操作时间，具体操作）

用户ID 操作时间 操作名称

A电厂 2010-4-2 7:55:35 导出Excel(期号:4201003,ITEMID:154,名称:XXXXX)
A电厂 2010-4-2 7:57:59 导入Excel
C电厂 2010-4-2 7:58:26 用户保存从Excel导入的数据(期号:4201003,ITEMID:154,名称:XXXXX)
A制糖厂 2010-4-2 8:06:17 导入Excel
A制糖厂 2010-4-2 8:06:40 用户保存从Excel导入的数据(期号:4201003,ITEMID:25,名称XXXXXX )

图3 DOMINO应用服务器日志（从左到右列值说明：采样时间点、处理的HTTP请求总数、处理HTTP请求耗费总时间）



1.2 测试方案设计

方案设计是整个测试流程的核心，在方案中应描述性能测试内容、测试环境，测试策略、测试用例等。

⑴ 性能测试内容

以培训管理系统性能测试为例，测试内容描述为：

“ 性能测试包括两项内容：负载测试和稳定性测试。

① 负载测试：利用负载测试工具模拟100、300、500个用户同时访问系统执行指定业务操作约30分钟，考察系统在不同负载量下的响应时间。

② 稳定性测试：模拟通过前一项测试的最大用户数连续访问系统若干个工作日（通常为

7X24小时），考察系统能否运行正常及常见性能指标（如响应速度、消耗硬件资源等）。

特殊情况说明：无法对培训管理系统的“在线视频学习模块”执行性能测试。当用户点击视频观看按钮，客户端会从服务器下载视频流文件。而负载生成器部署在单台机子，模拟多个用户观看学习视频，该机子会重复下载视频流文件，最终导致本机因网络拥塞而无法连接资源服务器，与实际情况不符。 ”

本例中执行两项测试：负载测试与稳定性测试。两者侧重点不同：前者是逐次增加用户负载，每次负载持续的时间较短（通常半小时以内），初步判断系统能否承受预期的用户数。后者是对系统施加特定压力,时长至少一个工作日，观察系统响应速度变化以及能否稳定运行。实践证明，执行稳定性测试相当有必要，系统能通过短时间的负载测试，但可能经受不起时间考验：在指定负载下运行几个小时后因资源逐渐殆尽（如中间件服务器的JVM与数据库连接池资源、CPU或内存资源）而出现响应缓慢甚至中间件服务崩溃，或因数据库归档日志空间满而导致数据库无法连接等严重故障。

当然，测试工具并非万能，测试人员在分析测试需求的同时应理智排除不可测试点。如本例鉴于测试工具原理，视频学习模块性能测试与现实情况不符，可不纳入测试内容中。下图为某应用系统因存在性能缺陷从而未能通过稳定性测试的现象图，说明系统需做调优。

图4 某应用系统运行5.5小时后，点击率趋于0表明服务器逐渐丧失处理能力。同时，多项业务操作的响应时间逐渐升高



⑵ 性能测试策略

描述执行性能测试采用的策略，包括时间策略、测试环境准备策略、测试数据准备策略、测试工具选取策略等。

⑶ 测试用例

测试用例是体现具体测试行为的重要文档，它将测试步骤、输入数据、前置条件与预期输出等多项内容有条理地组织起来。结合Loadrunner工具的使用，测试步骤描述了虚拟用户脚本如何录制、测试场景如何设置等内容。

a. 测试脚本录制

从系统所有功能中选取有代表性的功能进行录制，建议选择使用频率高、涉及复杂算法、复杂数据结构或大数据量处理的功能操作，模拟现实中发生的混合业务场景。

b. 测试场景设置

测试场景涉及多个重要参数，比如运行模式、虚拟用户数、停歇时间（思考时间thinktime、迭代间隔pacingtime）、负载持续时间、虚拟用户启停频率等。因此，测试场景设置应考虑这些参数如何设置。

其中，虚拟用户数与停歇时间两个参数共同决定服务器承受的负载压力。

● 虚拟用户数

虚拟用户由Loadrunner 负载生成器产生（负载生成器安装于某台主机，须与控制器互连）。每个虚拟用户运行指定脚本，每个脚本分配多少个虚拟用户来执行取决于相关操作的发生频率，此处需体现分配原则。

若忽略停歇时间（thinktime、pacingtime），则虚拟用户数=并发用户数，即所有虚拟用户同时向服务器提交请求，这相当于一种极端情形：所有用户每分每秒都在点击鼠标不停执行操作，对服务器造成极大压力。而现实情况往往是，用户操作间有所停歇，如点击新闻链接后会花费几分钟查看新闻内容，随后再进行其他操作。停歇时间段内用户不会向服务器提交任何请求。

综上所述，虚拟用户数同等的两个测试场景，服务器承受的压力与停歇时间长短成反比。若忽略停歇时间，服务器承受的压力最大。可见虚拟用户数并非决定服务器负载的唯一因素。

● 停歇时间

停歇时间是为调节服务器承受的负载压力而设。它包括思考时间（thinktime）和迭代间隔时间（pacingtime）。区别在于前者嵌于测试脚本中，后者是脚本两次循环运行间隔的时间。常见的负载测试方法通常有两种：

① 忽略停歇时间，所有用户并发操作。测试人员根据经验值或特定的概率学公式设置并发用户数。比如OA系统并发人数的经验值是在线人数的10%-20% ；计算平均并发用户数的数学公式为 nL/T（n是用户会话数，L是用户会话的平均时长，T是一天内用户使用系统的时长），公式中的L是不确定因素，较难获取固定数值。因此公式的计算结果与实际情况的相符度难以明确。

② 根据系统日常访问量调研结果设置合理的停歇时间，模拟真实用户访问系统的情形，服务器承受的访问压力稍大于实际情况（考虑未来1-3年内访问量扩展）。

对比两种方式，第一种略显极端和盲目。若系统能通过最恶劣的测试条件，性能自然过硬。倘若无法通过，是否判断系统性能存在不足？关键在于参考点的选取。极端情形下服务器承受的压力通常比实际情况大得多，若选择极端情形作为性能达标的参考点，大多数系统性能难以合格。若选择未来1-3年用户的使用需求作为参考点则比较合理。

● 负载持续时间

Controller模拟虚拟用户逐一登录系统，循环执行脚本长达指定的时间段，称为负载持续时间。在这个时间段需注意观察点击率曲线与事务响应时间曲线的变化是否平稳，判断应用系统是否出现性能瓶颈。若点击率较低，响应时间较高则表明服务器不能承受当前负载量，应酌情减少。若两者曲线变化平稳，则说明服务器可以承受。

c. 监控对象选取

在controller（中央控制台）组件里还可按需添加性能计数器加以监控。测试过程中，性能指标的实时变化曲线会呈现在监控窗里。目前允许设置的最大监控窗口数=1 6个。测试结束后我们可通过工具记录下的性能指标数据评估系统性能表现。测试场景常选的基本性能计数器有四类：

① 虚拟用户运行情况图。

② 反映系统响应速度的事务响应时间图。

③ WEB资源图，包括点击率曲线、网络吞吐量曲线、每秒HTTP响应数曲线、每秒TCP/IP连接数曲线等。

④ 反映主机资源使用情况的操作系统资源图，包括WINDOS、UNIX、LINUX等主流操作系统。

结束语

尽管应用系统性能测试充满诸多难以确定的因素，我们也能通过科学方法把握测试流程的每个环节——测试前调研、测试需求分析、测试方案设计、测试实施与测试分析。这些环节既独立又紧扣，共同决定着性能测试整体工作质量。同时，现代化企业级应用系统架构也决定了性能测试与调优是一项技术综合性强且分工细致的工作，需要具备各技术领域的专业人员共同参与。