性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、……,这么多眼花缭乱的性能测试类型名称，估计很少有人能准确的区分并说出定义来。至于如何制定合理的性能测试策略，同时把这些性能测试组织起来，并设计对应的测试用例，就更不用说了。因此，性能测试的设计、组织、实施一直不容易开展。

为了解决这些问题，本章提出了“Web全面性能测试模型”。主要讲解在企业的实际工作中，如何比较全面的开展Web性能测试工作，使Web性能测试工作更加合理、高效率的开展。

本章重点讲解全书的理论核心“Web全面性能测试模型”，主要包含如下的内容：

• Web性能测试策略制定原则
• Web性能测试用例设计模型
• Web全面性能测试模型使用方法

注：本章的Web全面性能测试模型主要是针对系统测试阶段的性能测试而提出，单元测试阶段的性能测试一般是测试人员配合开发人员进行，可以划分到单元测试阶段，不在本书研究之列。

1.1 Web全面性能测试模型简介

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

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

在“Web全面性能测试模型”中，把Web性能测试分为八个类别，然后结合测试工具把性能测试用例分为五类。后面的2.3节将会展开讨论“Web全面性能测试模型”的测试用例设计方法。下面首先介绍八个性能测试类别的主要内容。

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

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

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

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

用户并发测试是核心业务模块的重点测试内容。“并发”的主要内容是模拟一定数量的用户同时使用某一核心模块的“相同”或者“不同”的功能，并且持续一段时间。对“相同”的功能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作，例如打开同一条数据记录进行查看；另外一类是在同一时刻使用完全一样的功能，例如同时提交数据进行保存。可以看出后者是包含前前者的，前者是后者的特例。后面2.3节的测试用例中会对这部分内容进行更详细的讨论。

从微观角度讲，同时使用某一核心模块“不同”的功能，也是一种组合业务性能测试，只不过这种组合的相关业务的分类是一致的。因此在2.3.2节的“并发用户用例”设计中将会以“模块”为单位进行用例的设计，把用户并发测试分为“核心模块性能测试”和“组合模块性能测试”两种类型来进行讨论。

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

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

用户并发测试是组合业务测试的核心内容。“组合”并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来进行匹配。

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

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

第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者常用的组合业务。例如某系统的数据每年只在年底备份转移一次，则可分别选择一个季度、半年、一年作为基线，并模拟输入各个时间段的预计数据量，然后来测试系统的性能，进而预估系统的性能走向。

最后一种就是把前两种结合起来进行的大数据量测试，主要是测试在极限状态下、同时运行时产生较大数据量时的系统性能。
由于大数据量测试一般在投产环境进行，通常把它独立出来并和疲劳强度测试放在一起，在整个性能测试的后期进行。大数据量测试可以理解为特定条件下的核心业务或者组合业务测试。

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

（7） 服务器性能测试（操作系统、Web服务器、数据库服务器）：服务器性能测试分为初级和高级两种形式。“初级服务器性能测试”主要是指在业务系统工作或者进行前面其它种类性能测试的时候，监控服务器的一些计数器信息，通过这些计数器对服务器进行综合性能分析，找出系统瓶颈，为调优或者提高性能提供依据。“高级服务器性能测试”一般不由测试人员进行，而是由专门的系统管理员来进行，例如数据库服务器由专门的DBA来进行测试和调优。本书主要讨论在测试中常见的“初级服务器性能测试”，既通过工具对服务器资源进行监控的性能测试。

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

“Web全面性能测试模型”是在上面对性能测试分类和总结的基础上提出的，主要包含三部分的内容。

第一部分：Web性能测试策略模型，本部分内容是整个模型的基础。软件类型决定着Web性能测试策略，同时用户对待软件性能的态度也影响着性能测试策略的制定。本部分内容主要结合软件类型和用户对性能重视程度来讨论Web性能测试策略制定的基本原则和方法。本部分内容将在2.2节进行详细的讨论。

第二部分：Web性能测试用例设计模型，本部分内容是模型的核心部分。主要思想是结合测试工具，把上面性能测试的八项内容进一步归纳，形成五类测试用例：

（1） 预期指标的性能测试；

（2） 并发用户的性能测试；

（3） 疲劳强度和大数据量的性能测试；

（4） 服务器性能测试；

（5） 网络性能测试；

在具体的Web性能测试用例设计中，往往和测试工具结合起来，把服务器、网络性能测试的用例设计与前三种类型性能测试的用例设计结合起来进行。例如MI公司的LoadRunner就能在进行压力测试的同时，完成后面两类测试的数据采集工作，因此后面两部分的测试用例设计可以和前面融会在一起，在第5章的案例多采用了这种方式来进行设计。

Web性能测试用例设计模型在2.3节进行详细的讨论。

第三部分：模型使用方法，本部分内容讨论如何在工作中使用“Web全面性能测试模型”，具体在2.4节进行详细的讨论。

1.2 Web性能测试策略模型

本节主要介绍Web性能测试策略制定方法。性能测试策略一般从需求设计阶段开始讨论如何制定，它决定着性能测试工作将要投入多少资源、什么时间开始实施等后继工作的安排。其制定的主要依据是“软件自身特点”和“用户对性能的关注程度”两个因素，其中软件的自身特点起决定作用。

软件按照用途的不同可以分为两大类：系统类软件和应用类软件。系统类软件通常对性能要求比较高，因此性能测试应该尽早介入。应用类软件分为特殊类应用和一般类应用，特殊类应用主要指银行、电信、电力、保险、医疗、安全等领域类的软件，这类软件使用比较频繁，用户较多，一般也要较早进行性能测试；一般类应用主要指一些普通应用，例如办公自动化软件、MIS系统等，一般应用类软件多根据实际情况来制定性能测试策略，比如OA系统，可以早开始、也可以最后进行性能测试，这类软件受用户因素影响比较大。

用户按对性能的关注度的不同一般可以分为四类，即特别关注、中等重视、一般关注、不怎么关注，这么划分主要是为了说明用户对性能测试的影响。实际上，用户不关注性能并不意味着测试人员就可以忽略性能测试，但是如果用户特别关注性能，测试人员也应该特别重视性能测试。表2-1列出了性能测试策略制定的基本原则（注意：这里的用户是广义范围的用户，包括所有和产品有利害关系的群体。因而不单单指最终使用产品的用户，这些用户既可以是提出需求的产品经理，也可以是公司的董事会成员，甚至是项目的研发人员）。

表2-1性能测试策略制定基本原则

从表2-1可以看出：（1）“系统类软件”、“特殊应用类软件”应该从设计阶段开始进行性能测试；（2）制定性能测试策略的主要依据由软件的特点来决定，用户的态度对策略会有一定的影响，但不是决定因素。

软件的特点决定性能测试策略的另外一个重要原因是“一般应用类软件”本身对性能要求不高，发生性能问题概率不高，因此可以通过提高硬件配置来改善运行环境，进而来提高性能。不过这也不是绝对正确的观点，例如一个几千用户来使用的OA系统，仍然要高度重视性能，不管客户对待系统的性能是什么态度。

虽然从硬件方面解决性能问题往往更容易做到，同时还可以降低开发成本，但是也不能过分让用户进行较大的硬件投入，否则会降低“客户满意度”，调整性能最好的办法还是软硬件相结合。

“用户对待系统性能的态度影响性能测试策略，但不起决定作用”的根本原因是最终要把产品交付给用户来使用，而不是做出来给用户欣赏。因此不管用户是否重视性能测试，甚至根本不关心，对于性能要求高的软件产品也应按照表2-1的策略来执行性能测试。只是如果用户如果特别重视性能这方面，这意味着测试团队可能将要进行更多的成本投入，因为有义务使用户满意。

下面是一些Web性能测试策略制定的案例。

案例一：一个银行卡审批系统的性能测试策略制定案例。这个项目的性能测试策略从立项时开始制定，贯穿整个项目的执行过程（在5.3节将会进一步讨论本案例）。

银行卡业务系统属于特殊应用软件，加上用户高度重视性能，因而采取的策略是从设计阶段就开始进行性能测试的准备工作，案例详细信息如表2-2：

表2-2某银行项目测试策略制定案例

案例二：一个OA系统的测试案例，其性能测试策略和案例一差别很大。

表2-3某OA项目测试策略制定案例

案例三：一个门户系统的测试案例。

表2-4某门户项目测试策略制定案例

三个案例不足以说明所有的性能测试策略制定的方法，但是通过这三个案例可以对性能测试策略制定有了更进一步的了解，能够认识到到性能测试策略的制定由软件自身特点决定，同时受用户态度的影响。实际上，软件项目的背景、软件运行环境等许多方面都会影响性能测试策略的制定。因此，本节提出的只是基本的参考方案。制定测试策略是十分复杂的工作，最有效的方法就是“从实际出发”。项目的特点千差万别，只有把用户当成“上帝”，充分为用户考虑，才可以制定出合理的性能测试策略。

本节介绍了性能测试策略制定的基本思路和方法。性能测试策略是后期性能测试工作的基础，决定着性能测试工作的投入，因此要充分意识到这一工作的重要性，认识到只有做好了前期的“路线”制定工作，才可以走对后面的“道路”。