全面性能测试模型

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

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

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

　　预 期指标的性能测试

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

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

　 　独立业务性能测试

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

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

　　组合业务性能测试

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

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

　　疲劳强度性能测试

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

　　大数据 量性能测试

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

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

　 　网络性能测试

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

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

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

　　一 些特殊测试

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

　　“全面性能测试模型”是在以上性能测试分类和总结的基础上提出来的，主要包含3部分内容：

　　第1部分：性能测试策略模型，这是整个性能测试模型的基础。软件类型决定着性能测试的策略，同时用户对待软件性能的态度也影响性能测试策略的制 定。本部分内容主要结合软件类型和用户特点来讨论性能测试策略制定的基本原则和方法。

　　第2部分：性能测试用例模型，这是整个性能测试模型的核心部分。其主要思想就是结合测试工具，把以上性能测试的8项内容进一步归纳，形成5类测 试用例：

　　●  预期指标的性能测试；

　　●  并发用户的性能测试；

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

　　●  服务器性能测试；

　　●  网络性能测试。

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

　　第3部分：模型的使用方法。本部分内容讨论如何在工作中使用“全面性能测试模型”。

　　一、性能测试策略模型

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

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

　　按对性能重视程度的不同一般可以将用户分为4类，即高度重视、中等重视、一般重视、不重视。这么划分主要是为了说明用户对性能测试的影响。实际 上，用户不关注性能并不意味着测试人员就可以忽略性能测试，但是如果用户特别关注系统性能，那么测试人员也要特别重视性能测试工作。表1-1列出了性能测 试策略制定的基本原则。

　　注意：这里的用户是广义范围的用户，包括所有和产品有利害关系的群体。因而不单单指最终使用产品的用户，这些用户既可以是提出需求的产品经理， 也可以是公司的董事会成员，甚至是项目的研发人员。

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

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

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

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

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

　　二、性能测试用例模型

　　“性能测试用例模型”是“全面性能测试模型”的核心内容。限于篇幅和本书主旨，本节仅对“性能测试用例模型”做概要介绍。

　　在前面的内容中，已经介绍了性能测试分为8个方面。而在“性能测试用例模型”中，则融合了性能、强度、压力、负载等多方面测试内容，对性能测试 进行了重新组织和分类，最终归纳出五类性能测试用例。下面介绍各类性能测试用例包含的内容以及设计方法。

　　预期性能指标测试用例

　　所谓预期或预定性能指标，就是指一些十分明确的、在系统需求设计阶段预先提出的、期望系统达到的，或者向用户保证的性能指标，这些指标是性能测 试的首要任务。针对每个指标都要编写一个或多个测试用例来验证系统是否达到要求，如果达不到目标，则需根据测试结果来改进系统的性能。

　　预期指标的用例设计比较简单，主要参考需求和设计文档，把里面十分明确的性能要求提取出来即可。指标中通常以单用户为主，如果涉及并发用户内 容，则归并到并发用户测试用例中进行设计，遇到其他内容亦可采用同样的方法处理。

　　用户并发性能测试用例

　　本节的用户并发测试融合了前面提到的“独立业务性能测试”和“组合业务性能测试”两类内容，主要是为了使性能测试按照一定的层次来开展。独立业 务性能测试实际上就是核心业务模块的某一业务的并发性能测试，可以理解为“单元性能测试”；组合业务的性能测试是一个或多个模块的多项业务同时进行并发性 能测试，可以理解为“集成性能测试”。“单元性能测试”和“集成性能测试”两者紧密相连，由于这两部分内容都是以并发用户测试为主，因此把这两类测试合并 起来通称为“用户并发性能测试”。

　　用户并发性能测试要求选择具有代表性的、关键的业务来设计测试用例，以便更有效地评测系统性能。当编写具体的测试用例设计文档时，一般不会像功 能测试那样进行明确的分类，其基本的编写思想是按照系统的体系结构进行编写的。很多时候，“独立业务”和“组合业务”是混合在一起进行设计的。

　　单一模块本身就存在“独立业务”和“组合业务”，所以性能测试用例的设计应该面向“模块”，而不是具体的业务。在性能测试用例设计模型中，用户 并发测试实际就是关于“独立核心模块并发”和“组合模块并发”的性能测试。

　　用户并发性能测试的详细分类如图1-2所示。

图1-2  用户并发性能测试的分类示意图

　　独立核心模块（以下简称“核心模块”）并发性能测试的重点是测试一些系统重要模块独立运行的情况，因此可以将其理解为“单元性能测试”。只有这 些决定系统性能的“核心单元”性能稳定，后面的性能测试才有意义。核心模块并发性能测试是整个性能测试工作的基础。

　　组合模块并发性能测试是最能反映用户实际使用情况的测试，是在前面各个核心模块运行良好的基础上、把系统的一些具有耦合关系的模块组合起来的测 试，因此可以理解成 “集成性能测试”。组合模块用户并发性能测试最重要的是模拟实际用户比较常见的场景，只有这样才可以真实地反映用户使用系统的情况，进而发现系统的瓶颈和 其他一些性能问题。

　　疲劳强度与大数据量测试

　　疲劳强度测试属于用户并发测试的延续，因此测试内容仍然是“核心模块用户并发”与“组合模块用户并发”。在实际工作中，一般通过工具模拟用户的 一些核心或典型的业务，然后长时间地运行系统，以检测系统是否稳定。

　　大数据量测试主要是针对那些对数据库有特殊要求的系统而进行的测试，例如电信业务系统的手机短信业务。由于有的用户关机或不在服务区，每秒钟需 要有大量的短信息保存，同时在用户联机后还要及时发送，因此对数据库性能有极高的要求，需要进行专门测试。编写本类用例前，应对需求设计文档进行仔细分 析，提出测试点。

　　大数据量测试分为3种：

　　●  实时大数据量测试：模拟用户工作时的实时大数据量，主要目的是测试用户较多或某些业务产生较大数据量时，系统能否稳定地运行；

　　●  极限状态下的测试：主要是测试系统使用一段时间后，即系统累积一定量的数据后，能否正常地运行业务；

　　●  前面两种的结合：测试系统已经累积较大数据量时，一些运行时产生较大数据量的模块能否稳定地工作。

　　网络性能测试

　　网络性能测试的用例设计主要有以下两类：

　　●  基于硬件的测试：主要通过各种专用软件工具、仪器等来测试整个系统的网络运行环境，一般由专门的系统集成人员来负责，不在本书的研究范围之内；

　　●  基于应用系统的测试：在实际的软件项目中，主要测试用户数目与网络带宽的关系。通过测试工具准确展示带宽、延迟、负载和端口的变化是如何影响用户响应时间 的。例如，可以分别测试不同带宽条件下系统的响应时间。

　　服务器性能测试

　　服务器性能测试主要有两种类型：

　　●  高级服务器性能测试：主要指在特定的硬件条件下，由数据库、Web服务器、操作系统相应领域的专家进行的性能测试。例如，数据库服务器由专门的DBA来进 行测试和调优。这类测试一般不由测试工程师来完成，所以不在本书的研究范围之内；

　　●  初级服务器性能测试：主要指在业务系统工作或进行前面其他种类性能测试的时候，监控服务器的一些计数器信息。通过这些计数器对服务器进行综合性能分析，找 出系统瓶颈，为调优或提高性能提供依据。

　　三、模型的使用方法

　　“全面性能测试模型”是针对性能测试而提出的一种方法，主要是为了比较全面地开展性能测试，使性能测试更容易组织和开展。本模型包含了测试策略 制定的通用方法和测试用例设计的通用方案。其中测试用例的设计覆盖了应用软件、服务器、操作系统等多方面内容，按照由浅入深的层次对性能测试进行合理的组 织。

　　“全面性能测试模型”是一种从很多性能测试项目抽象出来的方法论，主要用来指导测试，一般不适合具体的性能测试项目，因为任何一个项目都会有它 的特定背景。要想通过“全面性能测试模型”做好性能测试工作，首先要制定好性能测试策略，同时还要按照一些基本指导原则来使用“性能测试用例模型”的内 容。这些原则主要包括如下内容：

　　●  测试策略遵从最低成本原则。全面性能测试本身是一种高投入的测试，而很多公司在测试上的投入都比较低；性能测试同时又是全部测试工作的一部分，很多项目只 能进行一些重要的性能测试内容。这就决定了测试负责人制定性能测试策略时在资源投入方面一定要遵从最低成本化原则。最低成本的衡量标准主要指“投入的测试 成本能否使系统满足预先确定的性能目标”。只要经过反复的“测试—系统调优—测试”后，系统符合性能需求并有一定的扩展空间，就可以认为性能测试工作是成 功的。反之，如果系统经过测试后不能满足性能需求或满足性能需求后仍须继续投入资源进行测试，则可以认为是不合理的。

　　●  策略为中心原则。本原则不但对性能测试工作有效，对其他类型的测试工作同样具有指导意义。测试策略不但决定了测试用例设计的主要内容，还决定着实施测试工 作时如何根据项目的实际情况进行处理。例如当项目时间比较紧张时，就可以按照测试用例的优先级只执行一部分性能测试用例。因此，性能测试策略应该贯穿整个 性能测试的全过程。

　　●  适当裁剪原则。裁剪原则主要是针对性能用例设计而言的。性能测试用例设计模型主要是针对电信、银行等特殊领域的应用而提出的，包含的测试内容比较全面，而 这类项目的性能测试一般周期较长、投入较大。一些银行项目的性能测试周期可能会超过一年。要想性能测试用例设计模型在大多数测试项目中适用，就必须对测试 用例模型包含的内容进行合理的裁剪。这样做主要是为了适合特定项目的测试需求，进而节约测试成本。

　　裁减的主要依据是性能测试策略。根据策略制定方法制定出测试策略，然后从“5类性能测试用例”中选择适当的类别来编写测试用例。例如有些要求不 高的静态门户网站，用户没有提出性能方面的要求，可以只测试用户并发情况作为系统性能的参考。

　　●  完善模型原则。本模型只是作者工作经验的总结，由于性能测试任务都有自己的项目背景，因而需要对模型内容进行不断的调整、补充、完善，使之适合更多的性能 测试工作。具体来说，不断完善就是要在工作中不断总结经验，形成自己的“全面性能测试模型”。只有“自己的”测试模型，才是最符合需要的模型。

　　●  模型具体化原则。模型具体化是指把模型运用到具体的项目中去，这是前面所有指导原则的终极目标。如果只记住模型的条条框框，生搬硬套框架来设计测试，只能 得到适得其反的结果。要想使模型在性能测试工作中发挥作用，只有根据实际项目的特点制定合理的性能测试策略、编写适当的性能测试用例，并在测试实施中灵活 地执行测试方案才是上策。

　　综合上面的分析可以看出，模型的使用可以概括为两个字——活用。要想真正做好性能测试工作，最有效的办法就是在掌握基本理论和方法后，在工作中 不断地探索和总结，形成自己的“全面性能测试模型”。