【IT168 技术文档】一个项目要取得成功是困难的，因为成功的项目需要多个因素和条件来支持;而一个项目失败却很容易，只要若干因素之中的一个出现问题，就有可能导致项目失败。比如中途测试人员发生变化，性能指标未和用户达成统一理解等。笔者还曾看过一个例子，因为测试报告的格式与用户要求的格式不一致，而不得不重新再执行一次所有的性能场景，来采集用户要的数据。

　　实际上，当我们做过的性能测试项目越多，就会发现越多的因素可能会影响性能测试项目的成败，甚至可以是千奇百怪的。

　　在本节中，我们主要是寻找出不同性能测试项目的共性，而总结出一个具有普遍意义的性能测试过程。遵循过程做性能测试，在大多数情况下可以有效地规避风险，并能取得比较好的性能测试结果。这当然不是意味着我们有了这个过程，就不考虑其他因素了，只是说每个项目都会有自己的独特因素要考虑，尽管这些因素可能很重要，但它们并不在本节的讨论范围内。

　　在给出此过程模型之前，我们要澄清两点事实：

　　第一，性能测试过程从何时开始，又在何时结束?

　　这是一个基本而重要的问题。

　　在各种书籍和资料中，有关性能测试过程的描述不尽一样：

　　比如LoadRunner手册中提供的过程是：计划测试→测试设计→创建VU脚本→创建测试场景→运行测试场景→分析结果。

　　而在Segue中提供的性能测试过程，是一个try-check过程，即：评估需求→开发测试→建立基线→执行测试→分析结果→回归测试→测试结束。

　　上面LoadRunner和Segue描述各自的性能测试过程最大的区别不在于工具部分，而是在于两者过程的入口和出口条件不一致。这使得它们其实在描述两件事情，或者说是在描述一个事情的两个部分。

　　在CMM中，软件测试和软件设计、编码一样，隶属于软件工程过程，而需求分析过程在软件工程过程之前。这就隐含着一个默认的先决条件：在CMM这个体系下，产品在进入软件测试阶段的时候，软件需求是已经明确下来并文档化了的。

　　实际情况却经常并非如此，同样是软件需求，软件功能需求在进入测试阶段就已经产生了各种文档，包括需求文档和设计文档，确保功能需求是详细、明确、无二义性的;而软件性能需求往往进入了性能测试阶段还不明确(可参见Controller一章开篇的例子)。这会给性能测试项目带来很大的风险。

　　因此，我们应该突破已有的理论束缚，寻找更合适的性能测试过程模型。经过对多个性能测试项目的实践经验总结，我们在本节提出GAME(A)性能测试过程模型，其开始于软件需求分析阶段，非常符合目前国内的性能测试实践。

　　第二，性能测试本身有没有质量?

　　以前我们总是讨论软件产品的质量、开发代码的质量，但对软件测试的质量却鲜有提及。我们知道“一个好的测试用例是发现了一个原先未发现的bug”，这其实是对用例质量的度量。软件性能测试项目也有质量，并可以度量。下面是部分度量的方法：

　　(1)性能测试耗费的资源，包括时间、人力、物力。

　　(2)性能测试中发现的bug数目，以及各自的级别。

　　(3)软件系统交付用户，在生产环境运行后发现的性能bug数目、级别。

　　而一个好的性能测试过程模型对提高性能测试质量是很有帮助的。

　　GAME(A)性能测试过程模型：

　　G：Goal，目标

　　A：Analysis，分析　

　　M：Metrics，度量　

　　E：Execution，执行

　　(A)：Adjust，调整。E执行失败后才进入A阶段，并且涉及的大多是有关开发和系统管理工作，因此A设为隐式。

　　性能测试过程模型如图1-5所示。

　　图1-5 性能测试GAME(A)模型

　　Goal(定义目标)

　　制定一个明确而详细的测试目标是性能测试开始的第一步，也是性能测试成功的关键。

　　本步骤的开始时间：需求获取阶段

　　本步骤的输入：性能需求意向

　　本步骤的输出：明确的性能测试目标和性能测试策略

　　常规的性能测试目标有以下几种：

　　(1)度量最终用户响应时间

　　查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设我们想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。图1-6显示了一个银行应用程序的负载和响应时间度量之间的关系。

　　图1-6 用户数-响应时间关系图

　　(2)定义最优的硬件配置

　　检测各项系统配置(内存、CPU速度、缓存、适配器、调制解调器)对性能的影响。了解系统体系结构并测试了应用程序响应时间后，您可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。

　　例如，您可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异：

　　配置1：1.2GHz、1GB RAM?

　   配置2：1.2GHz、2GB RAM

　　配置3：2.4GHz、1GB RAM

　　(3)检查可靠性

　　确定系统在连续的高工作负载下的稳定性级别。强制系统在短时间内处理大量任务，以模拟系统在数周或数月的时间内通常会遇到的活动类型。

　　(4)查看硬件或软件升级

　　执行回归测试，以便对新旧版本的硬件或软件进行比较。您可以查看软件或硬件升级对响应时间(基准)和可靠性的影响。注意：此回归测试的目的不是验证升级版的新功能，而是查看新版本的效率和可靠性是否与旧版本相同。

　　(5)确定瓶颈

　　您可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。将LoadRunner与新的网络和计算机监视工具结合使用以生成负载，并度量系统中不同点的性能，最终找出瓶颈所在的位置。

　　(6)度量系统容量

　　度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。如图1-7所示，要查看容量，您可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。

 

　　图1-7 用户数-响应时间拐点图

　　我们根据不同的测试目标去选择合适的性能测试设计策略。比如，“度量最终用户响应时间”可以采用负载测试策略，“检查可靠性”就可以用压力测试策略，等等。

　　Analysis(分析)

　　本步骤的开始时间：需求分析阶段和性能测试启动阶段

　　本步骤的输入：性能需求

　　本步骤的输出：达成一致的性能指标列表，性能测试案例文档

　　1.分析性能需求

　　在这里，要定义性能测试的内容，细化性能需求。

　　客户、需求分析人员和测试工程师一起起草一个性能需求标准，对此标准获得一致认同。此标准将用户的需求细化、量化，并能在测试中作为判断依据。

　　比如，对于负载测试来说，可以从以下角度来细化需求，逐步找出测试关键点。

　　测试的对象是什么，例如“被测系统中有负载压力需求的功能点包括哪些?”;“测试中需要模拟哪些部门用户产生的负载压力?”等问题。

　　系统配置如何，例如“预计有多少用户并发访问?”;“用户客户端的配置如何?”;“使用什么样的数据库”;“服务器怎样和客户端通信?”。

　　应用系统的使用模式是什么，例如“使用在什么时间达到高峰期?”;“用户使用该系统是采用B/S运行模式吗?”;“网络设备的吞吐能力如何，每个环节承受多少并发用户?”等问题。

　　最后得出的性能测试指标标准至少要包含测试环境、业务规则、期望响应时间等。

　　2.分析系统架构

　　对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。结合性能测试指标标准，生成性能测试用例。

　　Metrics(度量)

　　本步骤的开始时间：性能测试设计阶段

　　本步骤的输入：细化的性能指标和性能测试案例

　　本步骤的输出：和工具相关的场景度量、交易度量、监控器度量和虚拟用户度量等

　　度量是非常重要的一步，它把性能测试本身量化。这个量化的过程因测试工具的不同而异。

　　(1)场景的定义，pass/fail的标准

　　测试场景包含了性能测试的宏观信息，有测试环境、运行规则和监控数据等。具体可表现为历史数据记录数、虚拟用户数、虚拟用户加载方式、监控指标等。

　　(2)事务(Transaction)的定义，pass/fail的标准

　　事务用来度量服务器的处理能力。事务定义应该从性能指标标准而来，是性能指标的具体体现。事务的定义是很重要的，不同的定义会导致不同的TPS结果。

　　使用性能测试工具执行性能测试之后，我们能看到的是pass/fail的用户数、pass/fail的事务数。而这些pass/fail的标准应该在执行性能测试之前就应该被定义好。比如，LoadRunner默认的pass/fail标准是基于协议层的，而我们要的pass/fail可能是业务级的，需要在业务层上进行判断来决定是pass还是fail。另外，还可能由于案例的关联性引起的pass/fail，如果两个案例之间有关联，A脚本负责向数据库插入数据，B脚本负责查询数据，A要是fail了，导致B也会fail，虽然B本身不一定有错。解决这个问题，一方面可以削弱脚本之间的关联性，另一方面也可以通过增强脚本的健壮性来达到。

　　(3)虚拟用户pass/fail的标准

　　虚拟用户是性能测试工具中的一个普遍的概念，虚拟用户负责执行性能测试脚本，在这里应该定义虚拟用户遇到何种情况，选择fail或pass，即退出或通过。

　　Execution(执行)

　　本步骤的开始时间：软件测试执行阶段

　　本步骤的输入：场景、交易、虚拟用户等设置信息

　　本步骤的输出：测试报告

　　执行测试包含两个工作：

　　1.准备测试环境、数据和脚本

　　测试环境：硬件平台和软件平台。

　　测试数据：包括初始测试数据和测试用例数据两部分。表现为SQL脚本、Excel文件等。

　　测试环境直接影响测试效果，所有的测试结果都是在一定软硬件环境约束下的结果，测试环境不同，测试结果可能会有所不同。需要注意：如果是完全真实的应用运行环境，要尽可能降低测试对现有业务的影响;如果是建立近似的真实环境，要首先达到服务器、数据库以及中间件的真实，并且要具备一定的数据量，客户端可以次要考虑。实施负载压力测试时，需要运行系统相关业务，这时需要一些数据支持才可运行业务，这部分数据即为初始测试数据。有时为了模拟不同的虚拟用户的真实负载，需要将一部分业务数据参数化，这部分数据为测试用例数据。

　　测试脚本：用性能测试工具生成脚本。

　　2.运行场景和监控性能

　　运行性能测试场景，并监控设定好的数据指标，最终生成测试报告。按照定义好的场景pass/fail标准来判断性能测试是否通过。如果未能通过，进入步骤5(Adjust)。

　　 Adjust(调整)

　　本步骤的开始时间：第一轮性能测试结束后，而且没有通过的条件下

　　本步骤的输入：测试报告和测试结果数据

　　本步骤的输出：性能问题解决方案

　　调整包含两个意思：应用程序修改和中间件调优。

　　中间件调优可考虑如下因素操作系统调优：

　　数据库调优；

　　内存升级;

　　CPU数量;

　　代码调优;

　　Cache调优。

　　解决一个性能瓶颈，往往又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。

　　系统运行良好的时候恰恰也是各项资源达到了一个平衡体，任何一项资源的过度使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过度使用会造成大量进程等待CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加(用于进程切换、缺页处理的CPU开销)。

　　从以上内容可以看出，目前GAME(A)模型有两个优势：第一，灵活，每个过程都有自己的关注点，可以根据不同的项目特点增加或删除关注点;第二，通用，不依赖于具体的工具。目前GAME(A)关注性能测试技术，比较简单，将来可以进行扩展，同样使用GAME(A)模型关注性能测试的时间、人力等资源问题。