1.2 全面性能测试模型
通过前面的内容可以看出，性能测试的很多内容都是关联的。这就提供了一条思路：性能测试的很多内容可以经过一定的组织来统一进行。统一开展性能测试的最大好处是，可以按照由浅入深的层次对系统进行测试，进而减少不必要的工作量，以实现节约测试成本的目的。为此，本书提出了“全面性能测试模型”。
“全面性能测试模型”提出的主要依据是：一种类型的性能测试可以在某些条件下转化成为另一种类型的性能测试，而这些测试的实施方式很类似。例如：对一个网站进行测试，模拟10个到50个用户就是常规的性能测试。当用户增加到1000乃至上万时就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了大数据量测试。
在“全面性能测试模型”中，把常见的性能测试分为8个类别，然后结合测试工具把性能测试用例归纳为5类来进行设计。下面首先介绍这8个性能测试类别的主要内容：
预期指标的性能测试
系统在需求分析和设计阶段都会提出一些性能指标，完成和这些指标相关的测试是性能测试的首要工作。本模型把针对预先确定的一些性能指标而进行的测试称为预期指标的性能测试。
这些指标主要指诸如“系统可以支持1000个并发用户”、“系统响应时间不得长于10秒”等这些在产品说明书等文档中规定得十分明确的内容。对这种预先承诺的性能要求，测试小组应该首先进行测试验证。
独立业务性能测试
独立业务实际是指一些与核心业务模块对应的业务，这些模块通常具有功能比较复杂、使用比较频繁、属于核心业务等特点。这类特殊的、功能比较独立的业务模块始终都是性能测试的重点。因此，不但要测试这类模块和性能相关的一些算法，还要测试这类模块对并发用户的响应情况。
核心业务模块在需求设计阶段就可以确定，在集成或系统测试阶段开始单独测试其性能。如果是系统类软件或特殊应用领域的软件，通常从单元测试阶段就开始进行测试，并在后继的集成测试、系统测试、验收测试中进一步进行，以保证核心业务模块的性能稳定。何时开始测试核心模块主要由性能测试策略决定，读者可以参考1.2.2节“性能测试用例模型”部分。
组合业务性能测试
通常所有的用户不会只使用一个或几个核心业务模块，一个应用系统的每个功能模块都可能被使用到。所以性能测试既要模拟多用户的“相同”操作（这里的“相同”指很多用户使用同一功能），又要模拟多用户的“不同”操作（这里的“不同”指很多用户同时对一个或多个模块的不同功能进行操作），对多项业务进行组合性能测试。组合业务测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模板的组合并发情况。
由于组合业务测试是最能反映用户使用情况的测试，因而组合测试往往和服务器（操作系统、Web服务器、数据库服务器）性能测试结合起来进行。在通过工具模拟用户操作的同时，还通过测试工具的监控功能采集服务器的计数器信息，进而全面分析系统的瓶颈，为改进系统提供有利的依据。
疲劳强度性能测试
疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试。其主要目的是确定系统长时间处理较大业务量时的性能。通过疲劳强度测试基本可以判断系统运行一段时间后是否稳定。
大数据量性能测试
大数据量测试通常是针对某些系统存储、传输、统计查询等业务进行大数据量的测试。主要测试运行时数据量较大或历史数据量较大时的性能情况，这类测试一般都是针对某些特殊的核心业务或一些日常比较常用的组合业务的测试。
由于大数据量测试一般在投产环境下进行，所以把它独立出来并和疲劳强度测试放在一起，在整个性能测试的后期进行。大数据量测试可以理解为特定条件下的核心业务或组合业务测试。
网络性能测试
网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户响应时间的。在实际的软件项目中，主要是测试应用系统的用户数目与网络带宽的关系。网络性能测试一般有专门的工具，本书不加详述。网络测试的任务通常由系统集成人员来完成。
服务器性能测试（操作系统、Web服务器、数据库服务器）
服务器性能测试主要是对数据库、Web服务器、操作系统的测试，目的是通过性能测试找出各种服务器的瓶颈，为系统扩展、优化提供相关的依据。
一些特殊测试
主要是指配置测试、内存泄漏测试等一些特殊的Web性能测试。这类性能测试或/和前面的测试结合起来进行，或者在一些特殊的情况下独立进行，本书重点讨论前一种情况。后一种情况由于投入较大往往通过特有的工具进行，可以不纳入性能测试的范畴。
“全面性能测试模型”是在以上性能测试分类和总结的基础上提出来的，主要包含3部分内容：
第1部分：性能测试策略模型，这是整个性能测试模型的基础。软件类型决定着性能测试的策略，同时用户对待软件性能的态度也影响性能测试策略的制定。本部分内容主要结合软件类型和用户特点来讨论性能测试策略制定的基本原则和方法。
第2部分：性能测试用例模型，这是整个性能测试模型的核心部分。其主要思想就是结合测试工具，把以上性能测试的8项内容进一步归纳，形成5类测试用例：
l 预期指标的性能测试；
l 并发用户的性能测试；
l 疲劳强度和大数据量的性能测试；
l 服务器性能测试；
l 网络性能测试。
在具体的测试设计中，性能测试用例往往和测试工具结合起来，把服务器、网络性能测试的用例设计与前三种类型结合起来。例如LoadRunner就可以在进行压力测试的同时，完成后面两类测试的数据采集工作。因此，后面两部分的测试用例只进行总体设计就可以了。
第3部分：模型的使用方法。本部分内容讨论如何在工作中使用“全面性能测试模型”。
1.2.1 性能测试策略模型
本节主要介绍性能测试策略的制定方法。性能测试策略一般从需求设计阶段就开始讨论如何制定了，它决定着性能测试工作将要投入多少资源、什么时间开始实施等后继工作的安排。其制定的主要依据是“软件自身特点”和“用户对性能的关注程度”两个因素，其中软件的自身特点起决定作用。
软件按照用途的不同可以分为两大类：系统类软件和应用类软件。系统类软件通常对性能要求比较高，因此性能测试应该尽早介入。应用类软件分为特殊类应用和一般类应用，特殊类应用主要指银行、电信、电力、保险、医疗、安全等领域类的软件，这类软件使用比较频繁，用户较多，一般也要较早进行性能测试；一般类应用主要指一些普通应用，例如办公自动化软件、MIS系统等。一般应用类软件多根据实际情况来制定性能测试策略，例如OA系统，既可以早开始，也可以最后进行性能测试，这类软件受用户因素影响比较大。
按对性能重视程度的不同一般可以将用户分为4类，即高度重视、中等重视、一般重视、不重视。这么划分主要是为了说明用户对性能测试的影响。实际上，用户不关注性能并不意味着测试人员就可以忽略性能测试，但是如果用户特别关注系统性能，那么测试人员也要特别重视性能测试工作。表1-1列出了性能测试策略制定的基本原则。
|
表1-1 性能测试策略制定的基本原则
|
软件类别 用户重视程度 |
系统类软件 |
应用类软件 |
|
|
一般类应用 |
特殊类应用 |
||
|
高度重视 |
从设计阶段就开始针对系统架构、数据库设计等方面进行规划，从根源来提高性能; 系统类软件一般从单元测试阶段开始进行性能测试实施工作，主要是测试一些和性能相关的算法或模块 |
设计阶段开始进行一些规划工作，主要在系统测试阶段开始进行性能测试实施 |
从设计阶段就开始针对系统架构、数据库设计等方面进行规划，从根源来提高性能; 特殊应用类软件一般从单元测试阶段开始进行性能测试实施工作，主要是测试一些和性能相关的算法或模块 |
|
中等重视/一般重视 |
可以在系统测试阶段的功能测试结束后进行性能测试 |
||
|
不重视 |
可以在软件发布前进行性能测试，提交测试报告即可 |
||
从表1-1中可以看出：（1）“系统类软件”、“特殊应用类软件”应该从设计阶段开始进行性能测试；（2）制定性能测试策略的主要依据是软件的特点，用户对待系统性能的态度影响性能测试策略，但不起决定作用。
软件的特点决定性能测试策略的另外一个重要原因是“一般应用类软件”本身对性能要求不高，发生性能问题的概率较小。因此可以通过提高硬件配置来改善运行环境，进而提高性能。不过这也不是普遍适用的原则。例如一个几千用户使用的OA系统，仍然要高度重视性能，不管客户对待系统性能是什么态度。
虽然从硬件方面解决性能问题往往更容易做到，同时还可以降低开发成本，但是也不能要求用户进行过大的硬件投入，否则会降低“客户满意度”。调整性能最好的办法还是软硬件相结合。
“用户对待系统性能的态度影响性能测试策略，但不起决定作用”的根本原因是，产品最终是要交付给用户使用的，而不是做出来给用户欣赏的。因此，不管用户是否重视性能测试，甚至根本不关心，对于性能要求较高的软件产品也应按照表1-1的策略来执行性能测试。只是如果用户特别重视产品性能，意味着测试团队可能要进行更多的成本投入。
下面是一些性能测试策略制定的案例。
|
一个银行卡审批业务系统的性能测试策略制定。这个项目的性能测试策略从立项时开始制定，贯穿整个项目的执行过程。
银行卡业务系统属于特殊应用软件，加上用户高度重视性能，因而采取的策略是从设计阶段就开始进行性能测试的准备工作。案例的详细内容如表1-2所示。
表1-2 某银行项目测试策略制定案例
|
产品类型 |
银行卡审批业务系统，使用非常频繁，业务量每年达到200万次左右，属于银行领域的特殊应用软件 |
|
项目背景 |
系统属于二次开发。前一开发商在系统开发完成后没有通过性能测试，当100个用户并发访问系统时就会造成数据库服务器崩溃。因此从项目启动开始，性能测试就已经成为用户关注的焦点 |
|
用户要求 |
用户提出性能首先要过关，否则功能再好也不会投产 |
|
性能测试策略 |
从系统设计阶段开始进行性能测试准备工作。测试人员主要参加系统的设计、评审。前一开发商失利的重要原因是数据库设计不合理，所以重点讨论了数据库的设计 系统设计阶段，完成了性能测试方案的设计 单元测试阶段，通过测试工具对一些重要模块的算法进行了测试。主要是一些并发控制算法的性能测试，测试对象是一些核心业务模块 集成测试阶段进行组合模块的性能测试 整个系统测试阶段都在进行性能测试，性能测试和功能测试同步进行。对功能测试引起的一些相关修改，立刻进行性能测试 验收测试阶段，在用户现场的投产环境进行性能测试，根据测试结果对系统运行环境进行调优，以达到更好的运行效果 |
|
一个OA系统的测试案例，其性能测试策略和案例一差别很大，具体内容如表1-3所示。
表1-3 某OA项目测试策略制定案例
|
产品类型 |
企业办公系统，用户数目在1000人以内，主要是一些信息的发布，以及公文流转、收发邮件等功能。软件系统的地位属于辅助办公功能。因此该类软件属于一般类型的应用软件，对性能要求不高，性能测试不属于重要工作 |
|
项目背景 |
已有稳定产品在工作。主要是按照客户的个性化需求进行二次开发 |
|
用户要求 |
客户提出了性能方面的需求：要求系统响应时间要加快，可以满足2000个用户使用的需要 |
|
性能测试策略 |
系统测试阶段开始进行性能测试准备工作，完成测试用例设计。其目标主要是评估系统性能，根据测试结果对系统进行一定的优化 验收测试阶段在用户现场执行性能测试用例，根据测试结果进行一定的调优工作，提交测试报告给用户以便进行系统验收 |
|
一个门户系统的测试案例，具体内容如表1-4所示。
表1-4 某门户项目测试策略制定案例
|
产品类型 |
主要用于一些单位信息的发布，用户在50人以下。因此该类软件属于一般类型的应用软件，对性能要求很低 |
|
项目背景 |
软件运行的硬件环境较好 |
|
用户要求 |
用户没有提出具体的要求 |
|
性能测试策略 |
验收测试在使用现场进行，根据测试结果进行一定的调优工作，提交测试报告给用户，以便进行系统验收 |
仅仅三个案例不足以说明所有性能测试策略制定的方法，但是通过这三个案例可以对性能测试策略的制定有更进一步的了解，能够认识到性能测试策略的制定由软件自身特点决定，同时受用户态度的影响。实际上，软件项目的背景、软件运行环境等许多方面都会影响性能测试策略的制定。因此，本节提出的只是基本的参考方案。制定测试策略是十分复杂的工作，最有效的方法就是“从实际出发”。项目的特点千差万别，只有把用户当成“上帝”，充分为用户考虑，才可以制定出合理的性能测试策略。
本节介绍了性能测试策略制定的基本思路和方法。性能测试策略是后期性能测试工作的基础，决定着性能测试工作的投入。因此，要充分意识到这一工作的重要性，认识到只有做好了前期的“路线”制定工作，才可以走对后面的“道路”。
1.2.2 性能测试用例模型
“性能测试用例模型”是“全面性能测试模型”的核心内容。限于篇幅和本书主旨，本节仅对“性能测试用例模型”做概要介绍。关于“性能测试用例模型”以及“全面性能测试模型”更详细的内容，读者可以参考作者的另一本专著《Web性能测试实战》。
在前面的内容中，已经介绍了性能测试分为8个方面。而在“性能测试用例模型”中，则融合了性能、强度、压力、负载等多方面测试内容，对性能测试进行了重新组织和分类，最终归纳出五类性能测试用例。下面介绍各类性能测试用例包含的内容以及设计方法。
预期性能指标测试用例
所谓预期或预定性能指标，就是指一些十分明确的、在系统需求设计阶段预先提出的、期望系统达到的，或者向用户保证的性能指标，这些指标是性能测试的首要任务。针对每个指标都要编写一个或多个测试用例来验证系统是否达到要求，如果达不到目标，则需根据测试结果来改进系统的性能。
预期指标的用例设计比较简单，主要参考需求和设计文档，把里面十分明确的性能要求提取出来即可。指标中通常以单用户为主，如果涉及并发用户内容，则归并到并发用户测试用例中进行设计，遇到其他内容亦可采用同样的方法处理。
用户并发性能测试用例
本节的用户并发测试融合了前面提到的“独立业务性能测试”和“组合业务性能测试”两类内容，主要是为了使性能测试按照一定的层次来开展。独立业务性能测试实际上就是核心业务模块的某一业务的并发性能测试，可以理解为“单元性能测试”；组合业务的性能测试是一个或多个模块的多项业务同时进行并发性能测试，可以理解为“集成性能测试”。“单元性能测试”和“集成性能测试”两者紧密相连，由于这两部分内容都是以并发用户测试为主，因此把这两类测试合并起来通称为“用户并发性能测试”。
用户并发性能测试要求选择具有代表性的、关键的业务来设计测试用例，以便更有效地评测系统性能。当编写具体的测试用例设计文档时，一般不会像功能测试那样进行明确的分类，其基本的编写思想是按照系统的体系结构进行编写的。很多时候，“独立业务”和“组合业务”是混合在一起进行设计的。
单一模块本身就存在“独立业务”和“组合业务”，所以性能测试用例的设计应该面向“模块”，而不是具体的业务。在性能测试用例设计模型中，用户并发测试实际就是关于“独立核心模块并发”和“组合模块并发”的性能测试。
用户并发性能测试的详细分类如图1-2所示。
图1-2 用户并发性能测试的分类示意图
独立核心模块（以下简称“核心模块”）并发性能测试的重点是测试一些系统重要模块独立运行的情况，因此可以将其理解为“单元性能测试”。只有这些决定系统性能的“核心单元”性能稳定，后面的性能测试才有意义。核心模块并发性能测试是整个性能测试工作的基础。
组合模块并发性能测试是最能反映用户实际使用情况的测试，是在前面各个核心模块运行良好的基础上、把系统的一些具有耦合关系的模块组合起来的测试，因此可以理解成 “集成性能测试”。组合模块用户并发性能测试最重要的是模拟实际用户比较常见的场景，只有这样才可以真实地反映用户使用系统的情况，进而发现系统的瓶颈和其他一些性能问题。
疲劳强度与大数据量测试
疲劳强度测试属于用户并发测试的延续，因此测试内容仍然是“核心模块用户并发”与“组合模块用户并发”。在实际工作中，一般通过工具模拟用户的一些核心或典型的业务，然后长时间地运行系统，以检测系统是否稳定。
大数据量测试主要是针对那些对数据库有特殊要求的系统而进行的测试，例如电信业务系统的手机短信业务。由于有的用户关机或不在服务区，每秒钟需要有大量的短信息保存，同时在用户联机后还要及时发送，因此对数据库性能有极高的要求，需要进行专门测试。编写本类用例前，应对需求设计文档进行仔细分析，提出测试点。
大数据量测试分为3种：
l 实时大数据量测试：模拟用户工作时的实时大数据量，主要目的是测试用户较多或某些业务产生较大数据量时，系统能否稳定地运行；
l 极限状态下的测试：主要是测试系统使用一段时间后，即系统累积一定量的数据后，能否正常地运行业务；
l 前面两种的结合：测试系统已经累积较大数据量时，一些运行时产生较大数据量的模块能否稳定地工作。
网络性能测试
网络性能测试的用例设计主要有以下两类：
l 基于硬件的测试：主要通过各种专用软件工具、仪器等来测试整个系统的网络运行环境，一般由专门的系统集成人员来负责，不在本书的研究范围之内；
l 基于应用系统的测试：在实际的软件项目中，主要测试用户数目与网络带宽的关系。通过测试工具准确展示带宽、延迟、负载和端口的变化是如何影响用户响应时间的。例如，可以分别测试不同带宽条件下系统的响应时间。
服务器性能测试
服务器性能测试主要有两种类型：
l 高级服务器性能测试：主要指在特定的硬件条件下，由数据库、Web服务器、操作系统相应领域的专家进行的性能测试。例如，数据库服务器由专门的DBA来进行测试和调优。这类测试一般不由测试工程师来完成，所以不在本书的研究范围之内；
l 初级服务器性能测试：主要指在业务系统工作或进行前面其他种类性能测试的时候，监控服务器的一些计数器信息。通过这些计数器对服务器进行综合性能分析，找出系统瓶颈，为调优或提高性能提供依据。
1.2.3 模型的使用方法
“全面性能测试模型”是针对性能测试而提出的一种方法，主要是为了比较全面地开展性能测试，使性能测试更容易组织和开展。本模型包含了测试策略制定的通用方法和测试用例设计的通用方案。其中测试用例的设计覆盖了应用软件、服务器、操作系统等多方面内容，按照由浅入深的层次对性能测试进行合理的组织。
“全面性能测试模型”是一种从很多性能测试项目抽象出来的方法论，主要用来指导测试，一般不适合具体的性能测试项目，因为任何一个项目都会有它的特定背景。要想通过“全面性能测试模型”做好性能测试工作，首先要制定好性能测试策略，同时还要按照一些基本指导原则来使用“性能测试用例模型”的内容。这些原则主要包括如下内容：
l 测试策略遵从最低成本原则。全面性能测试本身是一种高投入的测试，而很多公司在测试上的投入都比较低；性能测试同时又是全部测试工作的一部分，很多项目只能进行一些重要的性能测试内容。这就决定了测试负责人制定性能测试策略时在资源投入方面一定要遵从最低成本化原则。最低成本的衡量标准主要指“投入的测试成本能否使系统满足预先确定的性能目标”。只要经过反复的“测试—系统调优—测试”后，系统符合性能需求并有一定的扩展空间，就可以认为性能测试工作是成功的。反之，如果系统经过测试后不能满足性能需求或满足性能需求后仍须继续投入资源进行测试，则可以认为是不合理的。
l 策略为中心原则。本原则不但对性能测试工作有效，对其他类型的测试工作同样具有指导意义。测试策略不但决定了测试用例设计的主要内容，还决定着实施测试工作时如何根据项目的实际情况进行处理。例如当项目时间比较紧张时，就可以按照测试用例的优先级只执行一部分性能测试用例。因此，性能测试策略应该贯穿整个性能测试的全过程。
l 适当裁剪原则。裁剪原则主要是针对性能用例设计而言的。性能测试用例设计模型主要是针对电信、银行等特殊领域的应用而提出的，包含的测试内容比较全面，而这类项目的性能测试一般周期较长、投入较大。一些银行项目的性能测试周期可能会超过一年。要想性能测试用例设计模型在大多数测试项目中适用，就必须对测试用例模型包含的内容进行合理的裁剪。这样做主要是为了适合特定项目的测试需求，进而节约测试成本。
裁减的主要依据是性能测试策略。根据策略制定方法制定出测试策略，然后从“5类性能测试用例”中选择适当的类别来编写测试用例。例如有些要求不高的静态门户网站，用户没有提出性能方面的要求，可以只测试用户并发情况作为系统性能的参考。
l 完善模型原则。本模型只是作者工作经验的总结，由于性能测试任务都有自己的项目背景，因而需要对模型内容进行不断的调整、补充、完善，使之适合更多的性能测试工作。具体来说，不断完善就是要在工作中不断总结经验，形成自己的“全面性能测试模型”。只有“自己的”测试模型，才是最符合需要的模型。
l 模型具体化原则。模型具体化是指把模型运用到具体的项目中去，这是前面所有指导原则的终极目标。如果只记住模型的条条框框，生搬硬套框架来设计测试，只能得到适得其反的结果。要想使模型在性能测试工作中发挥作用，只有根据实际项目的特点制定合理的性能测试策略、编写适当的性能测试用例，并在测试实施中灵活地执行测试方案才是上策。
综合上面的分析可以看出，模型的使用可以概括为两个字——活用。要想真正做好性能测试工作，最有效的办法就是在掌握基本理论和方法后，在工作中不断地探索和总结，形成自己的“全面性能测试模型”。
浙公网安备 33010602011771号