1.3.2 Analysis（分析）
本步骤的开始时间：需求分析阶段和性能测试启动阶段
本步骤的输入：性能需求
本步骤的输出：达成一致的性能指标列表，性能测试案例文档
1．分析性能需求
在这里，要定义性能测试的内容，细化性能需求。
客户、需求分析人员和测试工程师一起起草一个性能需求标准，对此标准获得一致认同。此标准将用户的需求细化、量化，并能在测试中作为判断依据。
比如，对于负载测试来说，可以从以下角度来细化需求，逐步找出测试关键点。
测试的对象是什么，例如“被测系统中有负载压力需求的功能点包括哪些？”；“测试中需要模拟哪些部门用户产生的负载压力？”等问题。
系统配置如何，例如“预计有多少用户并发访问？”；“用户客户端的配置如何？”；“使用什么样的数据库”；“服务器怎样和客户端通信？”。
应用系统的使用模式是什么，例如“使用在什么时间达到高峰期？”；“用户使用该系统是采用B/S运行模式吗？”；“网络设备的吞吐能力如何，每个环节承受多少并发用户？”等问题。
最后得出的性能测试指标标准至少要包含测试环境、业务规则、期望响应时间等。
2．分析系统架构
对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。结合性能测试指标标准，生成性能测试用例。（可参看第10章“进阶LoadRunner高手”的用例设计部分。）
1.3.3 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，即退出或通过。
1.3.4 Execution（执行）
本步骤的开始时间：软件测试执行阶段
本步骤的输入：场景、交易、虚拟用户等设置信息
本步骤的输出：测试报告
执行测试包含两个工作：
1．准备测试环境、数据和脚本
测试环境：硬件平台和软件平台。
测试数据：包括初始测试数据和测试用例数据两部分。表现为SQL脚本、Excel文件等。
提示：测试环境直接影响测试效果，所有的测试结果都是在一定软硬件环境约束下的结果，测试环境不同，测试结果可能会有所不同。需要注意：如果是完全真实的应用运行环境，要尽可能降低测试对现有业务的影响；如果是建立近似的真实环境，要首先达到服务器、数据库以及中间件的真实，并且要具备一定的数据量，客户端可以次要考虑。实施负载压力测试时，需要运行系统相关业务，这时需要一些数据支持才可运行业务，这部分数据即为初始测试数据。有时为了模拟不同的虚拟用户的真实负载，需要将一部分业务数据参数化，这部分数据为测试用例数据。
测试脚本：用性能测试工具生成脚本。
2．运行场景和监控性能
运行性能测试场景，并监控设定好的数据指标，最终生成测试报告。按照定义好的场景pass/fail标准来判断性能测试是否通过。如果未能通过，进入步骤5（Adjust）。
1.3.5 Adjust（调整）
本步骤的开始时间：第一轮性能测试结束后，而且没有通过的条件下
本步骤的输入：测试报告和测试结果数据
本步骤的输出：性能问题解决方案
调整包含两个意思：应用程序修改和中间件调优。
中间件调优可考虑如下因素操作系统调优：
数据库调优；
内存升级；
CPU数量；
代码调优；
Cache调优。
提示：解决一个性能瓶颈，往往又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。
系统运行良好的时候恰恰也是各项资源达到了一个平衡体，任何一项资源的过度使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过度使用会造成大量进程等待CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加（用于进程切换、缺页处理的CPU开销）。
从以上内容可以看出，目前GAME（A）模型有两个优势：第一，灵活，每个过程都有自己的关注点，可以根据不同的项目特点增加或删除关注点；第二，通用，不依赖于具体的工具。目前GAME（A）关注性能测试技术，比较简单，将来可以进行扩展，同样使用GAME（A）模型关注性能测试的时间、人力等资源问题。
本文选自：《51Testing软件测试作品系列》之一的《性能测试从零开始——LoadRunner入门》 ，本站经电子工业出版社和作者的授权，近期将进行部分章节的连载，敬请期待！
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
