基于场景的性能测试设计
“为了测试目的而设计的测试用例场景”主要根据测试设计人员的经验来进行，但是仍然要参考用户的实际场景，用户实际使用场景是设计所有测试用例的依据。例如一些业务系统，虽然备份历史数据的周期为一年，但是设计大数据量测试用例时仍然包含了系统运行一个月、半年等的数据量模拟测试，因为这些均属于用户的典型场景。
综合上面可以看出，性能测试用例设计首先要分析出用户现实中的典型场景，然后参照典型场景进行设计。实际项目中分析场景一般不会孤立的分析某一特定类型场景，而是把两种或者几种类型场景结合起来进行分析设计，这样做主要是为了选择更典型的场景和节省一些测试成本。
例子
下面将以图1所示的某视频点播网站做为示例，开始逐一讨论各类测试用例设计的细节。其中图1显示了该视频点播网站的主要业务及使用场景。
确定用户使用系统情况的方法
确定用户对系统的使用情况是设计用例具体数据的基础，后面并发用户数据设计、疲劳强度设计、以及各种场景设计都要依赖对用户使用系统情况的分析结果。分析用户使用情况经常采用现场调查和分析系统日志两种方法。
* 用户现场调查。实际就是通过和用户进行沟通，进而确定用户的人员组成情况。这类方法适用于用户群体固定且目标测试系统没有投产前的情况。
* 分析系统日志。很多时候，通过和用户沟通不能掌握其使用系统的详细情况，尤其是诸如图1的网站业务系统，因为目标用户使用系统的情况是不确定的。当用户比较分散、现场调查比较困难时，可以采用对系统日志进行分析的方法，以此作为对用户现场调查信息的补充。
大多数的系统都会对用户使用系统的情况进行日志管理，因此可以对日志进行分析，日志分析方法适用于已经投产或者试运行的系统。
在具体设计过程中，一般是两种方法结合使用。图1的网上视频点播系统就是通过两种方法得到的测试数据:通过和用户进行沟通得到全国各地维护人员使用系统的大概情况，然后通过对系统一个月的日志进行分析得出其它用户使用系统的情况，最后综合在一起就得到了系统的使用情况图。
也许有人会问:为什么不通过日志分析得出全部的用户使用情况？主要原因有两个:一是日志分析不一定能得出全部的使用情况，可能产生偏差，例如用户反复登陆系统、注册多个帐号都会影响统计结果;二是日志分析往往较用户调研成本大，因为多会涉及开发工作。
并发用户数量设计
并发用户尤其是最大并发用户数量的设计一直是网上很多测试论坛津津乐道的话题。
在设计并发用户数量前，首先要了解确定系统最大并发用户数量的方法。下面举一个估计最大并发用户数量的例子。
某OA系统的使用用户为600，预计使用周期内不会发生大的变化，通过分析日志得出系统的最大在线数目为200左右，分析其最大并发用户数量。
步骤1:OA系统的最大并发用户数目一般在系统使用人数的5～20％之间，此系统使用频度不高，因此我们估计最大并发用户数量为总使用人数的15％，根据经验得出第一个最大并发用户数90（600×15％＝90）;
步骤2:通常OA系统的并发数为在线数的30％左右，我们根据经验得出第二个最大并发用户数60（200×30％＝60）;
步骤3:比较前面的结果，最后取90作为最大并发用户数目。
完成最大并发用户数量的评估后，接下来就可以设计每个用例要模拟的用户数量。
通过表1可以看出并发用户数量的设计很简单，基本是按照最大并发用户数量的百分比来设计，例如可以按照最大用户的20％不断增加来设计并发用户数量，直到达到最大并发用户数量。
综合上面的内容，可以看出用户并发数量设计是很灵活的，不用拘泥于公式和形式，只要充分考虑到用户现在和未来的增长趋势就可以了。
系统不同时间段场景的设计
不同时间段的场景更接近用户使用情况，也是设计核心模块和组合模块并发性能测试用例的基础。例如图1的网上电影点播系统，每两个小时使用系统的情况都是不同的，因此需要设计一些典型的场景。
不同时间段场景分析的数据来源主要是前面的需求分析和日志分析结果。通过图1，很容易看出各个时间段不同模块的用户是如何并发的。有了上面的资料，就可以设计各个时间段的组合模块测试用例。下面是图1所示的网上电影点播系统“0～2点” 场景的一个测试用例。
上面场景的并发人数只是一个实际例子，如何设计最大并发用户可以参考本节“并发用户数量设计”和“业务模式设计”的相关内容。
不同时间段场景设计的基本原则有两个:一是选择典型的场景进行测试，尤其要选择场景中并发用户数目较大的场景;二是要覆盖全面，即设计出的用例要覆盖到压力可能较大的时间段。
业务模式的设计
业务模式的设计是不同时间段场景设计的特例，也是设计核心模块和组合模块并发性能测试用例的基础，设计业务模式的目的是专注于某些功能模块的组合。通常按时间段来设计场景会涉及很多模块，如果系统存在由应用软件引起的瓶颈则很难对定位，因此抽象出特定的业务模式来进行用例的设计。
以图1的网上视频点播系统为例，就需要对系统维护、电影欣赏、页面查询浏览三种模式进行用例的设计。
按业务模式和时间段的场景来设计性能测试用例时，会涉及到如何设计每个模块并发用户数目的问题。通常会取各个相关模块在24小时内最大的并发用户数目进行组合。例如电影浏览模式在12～14点场景设计的测试用例如下:仍然取了24小时内最大值280而不是210，理由是系统登陆用户在 10～12点内达到了高峰280。这条原则看似和前面测试最大并发用户的方法有些冲突，实际思想还是一致的，只是这里关注每个业务模块的最大并发用户数。
从这里可以看出并发用户数目的设计一定不能拘泥于形式。注意这里没有考虑用户数目在软件生存期内增加的情形，读者可以结合前面最大用户评估方法来确定最大用户并发数目，然后自己练习一下如何设计这两个性能测试用例的并发用户数目。
大数据量测试用例的设计
大数据量测试主要分为历史数据引起的大数据量测试和运行时大数据量测试两种。下面讨论一下如何来设计大数据量性能测试用例中的数据。
历史数据相关的大数据量测试设计主要以历史场景作为依据，通常首先确定系统数据的最长迁移周期，这个周期值的使用情况就是一个典型场景。
运行时大数量测试主要是通过模拟系统运行时可能产生的大数据量来进行测试。例如图2的网上视频点播系统，可以模拟大量用户同时下载或者播放电影的情况。这类测试用例通常根据实际情况自己去分析设计。
大数据量测试设计时可以借用前面的设计成果，因此相对容易。
一些特定测试用例设计
疲劳强度测试、最大用户测试、容量测试等一些特殊测试的用例设计，会根据用户的需求进行设计，因为这类用例的相关要求通常十分明确。
通过分析场景来设计性能测试，可以使性能测试用例更接近用户实际使用情况，更容易发现系统瓶颈。这种方法抓住了性能测试的关键点，做到有的放矢，大大降低了测试成本。
性能测试分类
性能测试按照场景不同一般可以分为两大类，一类是为了测试目的而进行的场景测试，另外一类是基于用户实际情况而进行的场景测试。因此，性能测试用例的设计应该面向性能测试场景来进行。
常见的三类用户场景
一天内不同时间段的使用场景。在同一天内，大多数系统的使用情况都会随着时间发生变化。例如对于新浪、网易等门户网站，在周一到周五早上刚一上班时，可能邮件系统用户比较多，而上班前或者中午休息时间则浏览新闻的用户较多。
系统运行不同时期的场景。系统运行不同时期的场景是大数据量性能测试用例设计的依据。随着时间的推移，系统历史数据将会不断增加，这将对系统响应速度产生很大的影响。
不同业务模式下的场景。同一系统可能会处于不同的业务模式，例如很多电子商务系统在早上8点到10点以浏览模式为主，10点到下午3点以定购模式为主，而在下午3点以后可能以混合模式为主。
