性能测试的场景设计方法.txt

性能测试在测试中往往不被重视，而项目中由于系统性能不合格会给企业带来巨大的损失。基于场景的性能测试设计能避免性能测试的误区。

很多企业在性能测试工作中存在一些常见误区，其中部分企业选择基于场景的设计性能测试来避免这些误区，因为这样可以大幅度降低执行成本，同时提高性能测试执行效率。

性能测试常见误区

请看下面一个性能测试小案例:

某公司OA产品的新版本即将发布。为了看看系统的性能，决定安排测试工程师A君执行性能测试任务。A君做法如下:

1.找到一台PC机，CPU主频1G，内存512M，……;

2.在找到的PC机上搭建了测试环境:安装了Oracle9i、Weblogic等系统软件;

3.在工作机上安装了LoadRunner7.8;

4.然后录制了登陆、发布公告等功能;

5.开始设置30、50、100、500不同的并发用户数目进行并发;

6.最后得出结论:系统只能运行80个左右的并发用户……。

无疑上面的做法存在很多不合理的地方，例如测试内容太少、测试服务器配置太低等。现实工作中，尽管性能测试以其在测试中独特的地位越来越为软件测试人员、开发人员和用户所重视，但是不管是测试人员还是开发人员，仍然在认识上存在这样或者那样的误区。

误区1:提高硬件配置可以直接提高性能

这是以前系统规模不大时期留下来的认识。DOS时代以及后来Windows操作系统流行的初期，软件规模一般较小，而硬件的更新却是日新月异，软件性能一般不是突出问题，因为只要升级一下硬件，很容易就解决了性能问题。

现在随着软件规模的扩大，提高硬件配置只是解决性能问题的一个基本手段。因为如果软件自身存在性能问题，再多的资源可能也不够用，例如内存泄漏问题，随着时间的增加，内存终究会被耗尽，最后导致系统崩溃。

因此，如果用户对软件的性能要求较高，这意味着不但要从硬件方面来保证性能，还要从数据库、WebServer、操作系统配置等方面入手来提高性能，同时开发的软件系统本身也要进行优化，以便全面提高性能。

误区2:在其它测试完成后进行性能测试

这是目前特别普遍的一种现象，例如前面的A君的现象就是没有意识到性能测试的重要性。这种做法最严重的后果是如果性能问题是由软件系统本身产生的，可能会无法根治性能问题。例如架构设计方面的失误，可能意味着软件系统将被废掉。

当然这并不意味所有的性能测试都要尽早进行，性能测试的启动时间要由软件特点来决定。

误区3:性能测试独立于功能测试

功能测试可以发现性能问题，性能测试也能发现功能问题。性能测试和功能测试是

紧密联系在一起的，原因之一是由于很多性能问题是由软件自身功能缺陷引起的。如果应用系统功能不完善或者代码运行效率低下，通常会带来一些性能问题。功能测试通常要先于性能测试执行或者同步进行，软件功能完善可以保证性能测试进行得更加顺利。

误区4:性能测试就是用户并发测试

仍然有很多人（尤其是开发人员和部分项目实施人员）一提到性能测试，就会联想到并发用户测试，进而认为性能测试就是“测试一下多用户的并发情况”。严格地讲，性能测试是以用户并发测试为主的测试。实际性能测试还包含强度测试、大数据量测试等许多内容。

误区5:在开发环境下进行性能测试

很多时候，在软件开发完成后进行性能测试，对软件性能进行评估。实际上大多数的开发环境因为硬件条件比较差，所以反映不了过多的性能问题。

因此性能测试要尽量在高配置的用户投产环境下进行。但是有两种可以例外的情况:一种是为了发现某些功能方面的问题，例如为了发现并发算法的一些缺陷;另外一种就是有非常好的硬件资源。

误区6:系统存在瓶颈，不可以使用。

系统发现了瓶颈，的确是很让人担心的一件事情。不过不要紧，很多的瓶颈可以不必去理会。发现瓶颈的目的主要是为了掌握系统特性，为改善和扩展系统提供依据。因此在性能方面给系统留有30％左右的扩展空间就可以了。

上面列举的都是日常性能测试工作中相关人员常犯的错误，这些观点只在极其特殊的情况下才正确。希望读者了解这些常见的性能测试误区后，能在以后的工作中避免类似的情况。


基于场景的性能测试设计

由于开发环境硬件配置不高，基于用户的测试多在用户现场进行，而为了测试目的而进行的测试多在开发环境即开发团队内部进行，不过两者进行的场所没有严格的界限，例如也可以在开发团队内部模拟用户的环境进行性能测试。

“为了测试目的而设计的测试用例场景”主要根据测试设计人员的经验来进行，但是仍然要参考用户的实际场景，用户实际使用场景是设计所有测试用例的依据。例如一些业务系统，虽然备份历史数据的周期为一年，但是设计大数据量测试用例时仍然包含了系统运行一个月、半年等的数据量模拟测试，因为这些均属于用户的典型场景。

综合上面可以看出，性能测试用例设计首先要分析出用户现实中的典型场景，然后参照典型场景进行设计。实际项目中分析场景一般不会孤立的分析某一特定类型场景，而是把两种或者几种类型场景结合起来进行分析设计，这样做主要是为了选择更典型的场景和

节省一些测试成本。

下面将以图1所示的某视频点播网站做为示例，开始逐一讨论各类测试用例设计的细节。其中图1显示了该视频点播网站的主要业务及使用场景。

确定用户使用系统情况的方法

确定用户对系统的使用情况是设计用例具体数据的基础，后面并发用户数据设计、疲劳强度设计、以及各种场景设计都要依赖对用户使用系统情况的分析结果。分析用户使用情况经常采用现场调查和分析系统日志两种方法。

用户现场调查。实际就是通过和用户进行沟通，进而确定用户的人员组成情况。这类方法适用于用户群体固定且目标测试系统没有投产前的情况。

分析系统日志。很多时候，通过和用户沟通不能掌握其使用系统的详细情况，尤其是诸如图1的网站业务系统，因为目标用户使用系统的情况是不确定的。当用户比较分散、现场调查比较困难时，可以采用对系统日志进行分析的方法，以此作为对用户现场调查信息的补充。

大多数的系统都会对用户使用系统的情况进行日志管理，因此可以对日志进行分析，日志分析方法适用于已经投产或者试运行的系统。

在具体设计过程中，一般是两种方法结合使用。图1的网上视频点播系统就是通过两种方法得到的测试数据:通过和用户进行沟通得到全国各地维护人员使用系统的大概情况，然后通过对系统一个月的日志进行分析得出其它用户使用系统的情况，最后综合在一起就得到了系统的使用情况图。

也许有人会问:为什么不通过日志分析得出全部的用户使用情况？主要原因有两个:一是日志分析不一定能得出全部的使用情况，可能产生偏差，例如用户反复登陆系统、注册多个帐号都会影响统计结果;二是日志分析往往较用户调研成本大，因为多会涉及开发工作。


并发用户数量设计

并发用户尤其是最大并发用户数量的设计一直是网上很多测试论坛津津乐道的话题。

在设计并发用户数量前，首先要了解确定系统最大并发用户数量的方法。下面举一个估计最大并发用户数量的例子。

某OA系统的使用用户为600，预计使用周期内不会发生大的变化，通过分析日志得出系统的最大在线数目为200左右，分析其最大并发用户数量。

步骤一:OA系统的最大并发用户数目一般在系统使用人数的5～20％之间，此系统使用频度不高，因此我们估计最大并发用户数量为总使用人数的15％，根据经验得出第一个最大并发用户数90（600×15％＝90）;

步骤2:通常OA系统的并发数为在线数的30％左右，我们根据经验得出第二个最大并发用户数60（200×30％＝60）;

步骤3:比较前面的结果，最后取9

0作为最大并发用户数目。

完成最大并发用户数量的评估后，接下来就可以设计每个用例要模拟的用户数量。

通过表1可以看出并发用户数量的设计很简单，基本是按照最大并发用户数量的百分比来设计，例如可以按照最大用户的20％不断增加来设计并发用户数量，直到达到最大并发用户数量。

综合上面的内容，可以看出用户并发数量设计是很灵活的，不用拘泥于公式和形式，只要充分考虑到用户现在和未来的增长趋势就可以了。

系统不同时间段场景的设计

不同时间段的场景更接近用户使用情况，也是设计核心模块和组合模块并发性能测试用例的基础。例如图1的网上电影点播系统，每两个小时使用系统的情况都是不同的，因此需要设计一些典型的场景。

不同时间段场景分析的数据来源主要是前面的需求分析和日志分析结果。通过图1，很容易看出各个时间段不同模块的用户是如何并发的。有了上面的资料，就可以设计各个时间段的组合模块测试用例。下面是图1所示的网上电影点播系统“0～2点” 场景的一个测试用例。

上面场景的并发人数只是一个实际例子，如何设计最大并发用户可以参考本节“并发用户数量设计”和“业务模式设计”的相关内容。

不同时间段场景设计的基本原则有两个:一是选择典型的场景进行测试，尤其要选择场景中并发用户数目较大的场景;二是要覆盖全面，即设计出的用例要覆盖到压力可能较大的时间段。


业务模式的设计

业务模式的设计是不同时间段场景设计的特例，也是设计核心模块和组合模块并发性能测试用例的基础，设计业务模式的目的是专注于某些功能模块的组合。通常按时间段来设计场景会涉及很多模块，如果系统存在由应用软件引起的瓶颈则很难对定位，因此抽象出特定的业务模式来进行用例的设计。

以图1的网上视频点播系统为例，就需要对系统维护、电影欣赏、页面查询浏览三种模式进行用例的设计。

按业务模式和时间段的场景来设计性能测试用例时，会涉及到如何设计每个模块并发用户数目的问题。通常会取各个相关模块在24小时内最大的并发用户数目进行组合。例如电影浏览模式在12～14点场景设计的测试用例如下:仍然取了24小时内最大值280而不是210，理由是系统登陆用户在10～12点内达到了高峰280。这条原则看似和前面测试最大并发用户的方法有些冲突，实际思想还是一致的，只是这里关注每个业务模块的最大并发用户数。

从这里可以看出并发用户数目的设计一定不能拘泥于形式。注意这里没有考虑用户数目在软件生存期内增加的情形，读者

可以结合前面最大用户评估方法来确定最大用户并发数目，然后自己练习一下如何设计这两个性能测试用例的并发用户数目。


大数据量测试用例的设计

大数据量测试主要分为历史数据引起的大数据量测试和运行时大数据量测试两种。下面讨论一下如何来设计大数据量性能测试用例中的数据。

历史数据相关的大数据量测试设计主要以历史场景作为依据，通常首先确定系统数据的最长迁移周期，这个周期值的使用情况就是一个典型场景。

运行时大数量测试主要是通过模拟系统运行时可能产生的大数据量来进行测试。例如图2的网上视频点播系统，可以模拟大量用户同时下载或者播放电影的情况。这类测试用例通常根据实际情况自己去分析设计。

大数据量测试设计时可以借用前面的设计成果，因此相对容易。


一些特定测试用例设计

疲劳强度测试、最大用户测试、容量测试等一些特殊测试的用例设计，会根据用户的需求进行设计，因为这类用例的相关要求通常十分明确。

通过分析场景来设计性能测试，可以使性能测试用例更接近用户实际使用情况，更容易发现系统瓶颈。这种方法抓住了性能测试的关键点，做到有的放矢，大大降低了测试成本。




图1网上视频点播系统使用情况图

性能测试分类

性能测试按照场景不同一般可以分为两大类，一类是为了测试目的而进行的场景测试，另外一类是基于用户实际情况而进行的场景测试。因此，性能测试用例的设计应该面向性能测试场景来进行。


常见的三类用户场景

一天内不同时间段的使用场景。在同一天内，大多数系统的使用情况都会随着时间发生变化。例如对于新浪、网易等门户网站，在周一到周五早上刚一上班时，可能邮件系统用户比较多，而上班前或者中午休息时间则浏览新闻的用户较多。

系统运行不同时期的场景。系统运行不同时期的场景是大数据量性能测试用例设计的依据。随着时间的推移，系统历史数据将会不断增加，这将对系统响应速度产生很大的影响。

不同业务模式下的场景。同一系统可能会处于不同的业务模式，例如很多电子商务系统在早上8点到10点以浏览模式为主，10点到下午3点以定购模式为主，而在下午3点以后可能以混合模式为主。

表1 性能测试用例并发用户设计示例

功 能 系统支持多个用户同时进行登录邮件系统的操作。

目 的 测试多用户访问邮件模块时系统的处理能力。

方 法 模拟多个用户在不同客户端登录邮件，然后进行并发进入邮件系统的操作

并发用户数与事务执行情况

并发用户数

事务平均响应时间 事务最大响应时间 事务成功率 平均流量（字节/秒）













前段时间有幸收到珠海X公司性能题目，呵呵，接合之前的公司产品性能测试做以下总结。

个人认为有关性能测试场景问题，其实更佳着重于对性能测试目的考究。

以下也是我回复该公司邮件的一些择选：

验证测试是用于验证在特定的场景、时间、压力、环境和操作方式下系统能够正常的运行，服务器、应用系统和网络环境等软硬件设施还能否良好的支撑这些情况下用户的使用。验证性测试主要针对有明确的压力目标和预期结果，验证系统在这种压力下的各方面反映能够达到预期结果。

主要分以下几种：

　压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。

Ramp Up 增量设计 如并发用户为75人 系统注册用户为1500人 已5％－7％作为并发用户参考值。

一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。

已事务通过率与错误率衡量实际加载方式。

Ramp Up增量设计目标 寻找已增量方式加压系统性能瓶颈位置 抓住出现的性能拐点时机 一般常用参考

Hits点击率与吞吐量、CPU、内存使用情况综合判断。

模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。

另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。

加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same");）

在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser.

稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。

根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。

仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。

场景设计思想：从稳定性测试场景的设计意义，应分多种情况考虑：

针对同一个场景为例，以下已公文附件上

传为例简要分析场景设计思想：

1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。

2）场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

测试方法：采用1)Ramp Up-Load all Vusers simultaneously

2)Duration-Run Indefinitely

3)在Sechedule-勾选Initalize all Vusers before Run

容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA（自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等）

评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。

评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）

评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。

评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务

性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。

问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。
该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。