Web全面性能测试模型

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

　　为了解决这些问题，本章提出了“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节的“并发用户用例”设计中将会以“模块”为单位进行用例的设计，把用户并发测试分为“核心模块性能测试”和“组合模块性能测试”两种类型来进行讨论。

原文转自：http://www.uml.org.cn/Test/201106211.asp