性能测试模型

A.预期指标的性能测试；

B.并发用户的性能测试；

C.疲劳强度和大数据量的性能测试；

D.服务器性能测试；

E.网络性能测试。

 

在具体的测试设计中，性能测试用例往往和测试工具结合起来，把服务器、网络性能测试的用例设计与前三种类型结合起来。例如LoadRunner就可以在进行压力测试的同时，完成后面两类测试的数据采集工作。因此，后面两部分的测试用例只进行总体设计就可以了。

 

展开来有以下八项:

 

1、预期指标的性能测试

 

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

 

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

 

2、独立业务性能测试

 

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

 

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

 

3、组合业务性能测试

 

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

 

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

 

4、疲劳强度性能测试

 

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

 

5、大数据量性能测试

 

大数据量测试通常是针对某些系统存储、传输、统计查询等业务进行大数据量的测试。主要测试运行时数据量较大或历史数据量较大时的性能情况，这类测试一般都是针对某些特殊的核心业务或一些日常比较常用的组合业务的测试。由于大数据量测试一般在投产环境下进行，所以把它独立出来并和疲劳强度测试放在一起，在整个性能测试的后期进行。大数据量测试可以理解为特定条件下的核心业务或组合业务测试。

 

6、网络性能测试

 

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

 

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

 

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

 

8、一些特殊测试

 

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