误区4:性能测试就是用户并发测试
仍然有很多人(尤其是开发人员和部分项目实施人员)一提到性能测试，就会联想到并发用户测试，进而认为性能测试就是“测试一下多用户的并发情况”。严格地讲，性能测试是以用户并发测试为主的测试。实际性能测试还包含强度测试、大数据量测试等许多内容。
误区5:在开发环境下进行性能测试
很多时候，在软件开发完成后进行性能测试，对软件性能进行评估。实际上大多数的开发环境因为硬件条件比较差，所以反映不了过多的性能问题。
因此性能测试要尽量在高配置的用户投产环境下进行。但是有两种可以例外的情况:一种是为了发现某些功能方面的问题，例如为了发现并发算法的一些缺陷;另外一种就是有非常好的硬件资源。
误区6:系统存在瓶颈，不可以使用。
系统发现了瓶颈，的确是很让人担心的一件事情。不过不要紧，很多的瓶颈可以不必去理会。发现瓶颈的目的主要是为了掌握系统特性，为改善和扩展系统提供依据。因此在性能方面给系统留有30%左右的扩展空间就可以了。
上面列举的都是日常性能测试工作中相关人员常犯的错误，这些观点只在极其特殊的情况下才正确。希望读者了解这些常见的性能测试误区后，能在以后的工作中避免类似的情况。
基于场景的性能测试设计
由于开发环境硬件配置不高，基于用户的测试多在用户现场进行，而为了测试目的而进行的测试多在开发环境即开发团队内部进行，不过两者进行的场所没有严格的界限，例如也可以在开发团队内部模拟用户的环境进行性能测试。
“为了测试目的而设计的测试用例场景”主要根据测试设计人员的经验来进行，但是仍然要参考用户的实际场景，用户实际使用场景是设计所有测试用例的依据。例如一些业务系统，虽然备份历史数据的周期为一年，但是设计大数据量测试用例时仍然包含了系统运行一个月、半年等的数据量模拟测试，因为这些均属于用户的典型场景。
综合上面可以看出，性能测试用例设计首先要分析出用户现实中的典型场景，然后参照典型场景进行设计。实际项目中分析场景一般不会孤立的分析某一特定类型场景，而是把两种或者几种类型场景结合起来进行分析设计，这样做主要是为了选择更典型的场景和节省一些测试成本。
下面将以图1所示的某视频点播网站做为示例，开始逐一讨论各类测试用例设计的细节。其中图1显示了该视频点播网站的主要业务及使用场景。
图1 网上视频点播系统使用情况图
文章来源于领测软件测试网 https://www.ltesting.net/
