完成最大并发用户数量的评估后，接下来就可以设计每个用例要模拟的用户数量。表1是上面OA系统的一个性能测试用例。

　　通过表1可以看出并发用户数量的设计很简单，基本是按照最大并发用户数量的百分比来设计，例如可以按照最大用户的20％不断增加来设计并发用户数量，直到达到最大并发用户数量。对于某一特定的用例，设计用户数量需要注意下面三点：

　　（1） 按照各类用户同时递增的方式来设计用户数量。按照递增的顺序设计测试用例是为了按照由浅入深的方法来发现系统的瓶颈，因此系统的各类用户应该同时增加。

　　（2） 并发用户数的最大值一般不会超过前面计算的最大并发用户数量的20％，除非是为了测试系统能支持的最大并发用户数量。

　　（3） 设计用户数量时要考虑成本，因为每组用户数都意味着至少执行一次测试。

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

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

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

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

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

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

　　用户场景的设计一般和后面的业务模式结合起来进行，下面会进一步讨论两者如何结合在一起进行用例设计。

　　4、 业务模式的设计

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

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

　　按业务模式和时间段的场景来设计性能测试用例时，会涉及到如何设计每个模块并发用户数目的问题。通常会取各个相关模块在24小时内最大的并发用户数目进行组合。例如电影浏览模式在12～14点场景设计的测试用例如下：

　　这里需要注意虽然在图2中12～14点内系统并发用户数目最多，但是系统登陆用户仍然取了24小时内最大值280而不是210，理由是系统登陆用户在10～12点内达到了高峰280。这条原则看似和前面测试最大并发用户的方法有些冲突，实际思想还是一致的，只是这里关注每个业务模块的最大并发用户数。实际加大用户数量没有太大的影响，尤其对于这类用户数目逐渐增加的Web系统，多测试一些并发用户然后进行调优，更能保证系统的扩展性。

　　从这里可以看出并发用户数目的设计一定不能拘泥于形式。注意这里没有考虑用户数目在软件生存期内增加的情形，读者可以结合前面最大用户评估方法来确定最大用户并发数目，然后自己练习一下如何设计这两个性能测试用例的并发用户数目。

　　5、 大数据量测试用例的设计

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

　　历史数据相关的大数据量测试设计主要以历史场景作为依据，通常首先确定系统数据的最长迁移周期，这个周期值的使用情况就是一个典型场景。例如历史数据只保留一年，设计用例时就可以把一年作为周期，然后分别设计系统在三个月、半年、一年历史数据量情况下的测试用例。确定了系统的最大数据量后，接下来选择一些前面的核心模块或者组合模块的并发用户测试用例作为其主要内容即可。

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

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

　　6、 一些特定测试用例设计

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

　　总结

　　本文首先介绍了性能测试的常见误区，接下来重点讨论了如何基于场景来设计性能测试用例的数据。通过分析场景来设计性能测试，可以使性能测试用例更接近用户实际使用情况，更容易发现系统瓶颈。这种方法抓住了性能测试的关键点，做到有的放矢，大大降低了测试成本。