性能测试的很多内容都是关联的。这就提供了一条思路：性能测试的很多内容可以经过一定的组织来统一进行。统一开展性能测试的最大好处是，可以按照由浅入深的层次对系统进行测试，进而减少不必要的工作量，以实现节约测试成本的目的。为此，提出“全面性能测试模型”。

　　“全面性能测试模型”提出的主要依据是：一种类型的性能测试可以在某些条件下转化成为另一种类型的性能测试，而这些测试的实施方式很类似。例如：对一个网站进行测试，模拟10个到50个用户就是常规的性能测试。当用户增加到1000乃至上万时就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了大数据量测试。

　　在“全面性能测试模型”中，把常见的性能测试分为8个类别，然后结合测试工具把性能测试用例归纳为5类来进行设计。下面首先介绍这8个性能测试类别的主要内容：

　　预期指标的性能测试

　　系统在需求分析和设计阶段都会提出一些性能指标，完成和这些指标相关的测试是性能测试的首要工作。本模型把针对预先确定的一些性能指标而进行的测试称为预期指标的性能测试。

　　这些指标主要指诸如“系统可以支持1000个并发用户”、“系统响应时间不得长于10秒”等这些在产品说明书等文档中规定得十分明确的内容。对这种预先承诺的性能要求，测试小组应该首先进行测试验证。

　　独立业务性能测试

　　独立业务实际是指一些与核心业务模块对应的业务，这些模块通常具有功能比较复杂、使用比较频繁、属于核心业务等特点。这类特殊的、功能比较独立的业务模块始终都是性能测试的重点。因此，不但要测试这类模块和性能相关的一些算法，还要测试这类模块对并发用户的响应情况。

　　核心业务模块在需求设计阶段就可以确定，在集成或系统测试阶段开始单独测试其性能。如果是系统类软件或特殊应用领域的软件，通常从单元测试阶段就开始进行测试，并在后继的集成测试、系统测试、验收测试中进一步进行，以保证核心业务模块的性能稳定。何时开始测试核心模块主要由性能测试策略决定，读者可以参考1.2.2节“性能测试用例模型”部分。

　　组合业务性能测试

　　通常所有的用户不会只使用一个或几个核心业务模块，一个应用系统的每个功能模块都可能被使用到。所以性能测试既要模拟多用户的“相同”操作（这里的“相同”指很多用户使用同一功能），又要模拟多用户的“不同”操作（这里的“不同”指很多用户同时对一个或多个模块的不同功能进行操作），对多项业务进行组合性能测试。组合业务测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模板的组合并发情况。

　　由于组合业务测试是最能反映用户使用情况的测试，因而组合测试往往和服务器（操作系统、Web服务器、数据库服务器）性能测试结合起来进行。在通过工具模拟用户操作的同时，还通过测试工具的监控功能采集服务器的计数器信息，进而全面分析系统的瓶颈，为改进系统提供有利的依据。

　　疲劳强度性能测试

　　疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试。其主要目的是确定系统长时间处理较大业务量时的性能。通过疲劳强度测试基本可以判断系统运行一段时间后是否稳定。

　　大数据量性能测试

　　大数据量测试通常是针对某些系统存储、传输、统计查询等业务进行大数据量的测试。主要测试运行时数据量较大或历史数据量较大时的性能情况，这类测试一般都是针对某些特殊的核心业务或一些日常比较常用的组合业务的测试。

　　由于大数据量测试一般在投产环境下进行，所以把它独立出来并和疲劳强度测试放在一起，在整个性能测试的后期进行。大数据量测试可以理解为特定条件下的核心业务或组合业务测试。

　　网络性能测试

　　网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户响应时间的。在实际的软件项目中，主要是测试应用系统的用户数目与网络带宽的关系。网络性能测试一般有专门的工具，本书不加详述。网络测试的任务通常由系统集成人员来完成。

　　服务器性能测试（操作系统、Web服务器、数据库服务器）

　　服务器性能测试主要是对数据库、Web服务器、操作系统的测试，目的是通过性能测试找出各种服务器的瓶颈，为系统扩展、优化提供相关的依据。

　　一些特殊测试

　　主要是指配置测试、内存泄漏测试等一些特殊的Web性能测试。这类性能测试或/和前面的测试结合起来进行，或者在一些特殊的情况下独立进行，我们重点讨论前一种情况。后一种情况由于投入较大往往通过特有的工具进行，可以不纳入性能测试的范畴。