软件测试轻松玩转-LoadRunner性能测试（十三）性能测试过程

第九、十、十一、十二这四章是资源监控，因为目前都是开发在协助监控，所以有待后续加强学习。

13.1 性能测试过程概述

在实际的测试过程中，性能测试工具 LoadRunner 只是将性能测试策略转化为可执行的脚本并产生压力，但在进行测试前还需要确定性能测试策略，即性能测试设计和构建。整个性能测试过程主要包括4个阶段：

性能测试设计：定义待测试的事务流程、事务的平均处理量、事务处理量的最高峰值、组合事务流程、系统的整体用户和响应时间目标

性能测试构建：涉及设置和配置测试系统及基础设施、使用自动化性能测试解决方案构建测试脚本和附在方案

性能测试执行：包括运行负载方案和测量系统性能

性能测试分析、诊断、调节：主要测量系统性能并使负载测试进入下一级别，重点查找问题原因以帮助开发工程师解决问题，并实时调节系统参数以提高性能

13.2 性能测试设计

设计阶段是性能测试团队与事务领域的精力合作以收集性能要求的主要事务响应时间。可以将需要关注的问题分为4个方面：事务需求、技术需求、系统要求和团队要求，分析时主要从5个方面：需求调研、事务模型、场景模型、数据设计和环境设计，其中事务模型是该阶段中最重要的。

13.2.1 需求调研

确定本次性能测试的对象以及被测对象的一些属性，主要包括及部分工作：

（1）测试系统预研
根据被测系统的资料，了解相关知识，技术架构、业务架构等。这个阶段需要完成的工作有：
    确定被测系统的开发组织和负责人
    向项目经理申请被测试系统相关资料
    一些其他的例外情况沟通

（2）与项目经理访谈
获取性能测试实施工作开展的相关信息、当前开发状态和期望的性能目标，包括性能测试实施起止时间和被测系统所处的生命周期。

（3）与业务专家访谈
获取性能测试业务模型设计的相关数据，如：关键业务、主要用户场景、交易发生概率、期望响应时间等业务层面信息，此外还需要从业务团队获得相关业务工程师来支持后续脚本开发，避免开发失败或出现错误。

关键业务的判断：
a. 使用频率：指客户操作该业务的频率，该值越大说明失效的概率越大；
b. 优先级：指业务的等级，该值越高说明客户操作该业务的概率越大，从业务角度来说，核心业务和基本业务的优先级比较高；
c. 占用资源情况：操作一次该业务对系统资源消耗的情况，如果消耗高，那么可能让系统处于高负荷的运行状态，这样业务失效的风险就变大了；

（4）与技术专家访谈
a. 获取关键业务的技术路径；
b. 获取合适的支持工程师；
c. 请技术专家确定关键业务是否覆盖到被测试系统的所有业务请求点；
d. 确定这些业务所使用到的关键数据库表；
e. 监控阶段，技术支持人员配合实施监控配置工作；
f. 一些特殊技术的支持，如加解密等；

（5）与数据库管理员访谈
获取数据准备和测试数据建模的建议，主要包括：
a. DBA 辅助进行数据库的备份与恢复工作；
b. 为数据建模提供建议；
c. 为建基础数据模型做准备；

（6）与客户代表访谈
获取用户在业务建模上的支持，保证业务流程的正确性。

13.2.2 业务模型

主要用于指导如何将具体的业务变成可重复运行的代码，主要从以下3个方面分析：

业务流程列表：

创建关键业务流程列表，以反映最终用户在系统上执行的活动。业务流程表需要反映每个业务在高峰期时操作的用户数，主要来源于后台的历史数据。

交易列表：

交易业务流程需要确定关键业务的负载情况、交易量等相关信息。通过交易列表可以确定业务的优先级。

日常业务：可以通过后台数据来统计，可以分析3个月、半年或一年的数据，得到这些业务每小时或每秒操作的笔数。

高峰期业务：选择峰值情况下，单位时间内业务操作的笔数。

风险：是指当该业务失效或发生错误时对客户的影响。

百分比模型：

指被测试的业务交易笔数所占整个业务交易笔数的百分比

交易量评估：

通过历史数据来估算系统负载能力，通常使用80/20原理。指的是每个工作日中80%的业务在20%的时间内完成。每年业务集中在8个月，每个月集中在20个工作日完成，每个工作日8h，每天80%的业务在1.6h完成。

13.2.3 场景模型

主要用于指导在控制器中如何进行场景设计和场景监控。

场景设计需要确定的内容主要包括：使用的场景设计类型（手动场景或目标场景）、并发用户数、虚拟用户加载过程、脚本持续运行时间、虚拟用户释放过程、使用的负载机、IP欺骗技术和 RTS 的设置。

（海量免费测试资料加1140267353，群内还会有同行一起交流哦~）

场景设计

RTS设置

监控模型

13.2.4 数据设计

确定在整个性能测试过程中需要使用的数据，一是性能测试前需要准备的基础数据；二是性能测试过程中参数化所需要用到的数据。

基础数据的不同直接影响到性能测试的结果，如查询功能，数据库中已存在100条记录和已存在100万条记录，查询的响应时间肯定是不同的，所以这需要在测试前确定。

基础数据表格式

参数化需要使用到的数据也分两种：一是为自己构建的数据；二是历史数据。构建数据是测试过程中通过一些方法生成批量数据，通常用 Ultraedit 结合 Excel 制作、数据库获取、Shell 编程和 Java 编程，目前我们只用到前两种方法。

历史数据则是真实存在的数据，可调用客户的真实数据，也可以事先制作，它们一般都是存储在 DB 里的，所以需要用 SQL 关联参数的方式来获取。

（海量免费测试资料加1140267353，群内还会有同行一起交流哦~）

数据设计模型

不管是哪种数据，我们都应该遵循几个原则：

1、全面性

指设计的数据应该包含所有类型的数据，需要覆盖客户操作过程中所有类型的数据。

2、无约束性

指数据与数据之间不能存在相互约束的现象。

3、正确性

指设计的数据应该保证业务能被正确地运行，因为性能测试的目的是测试业务的响应时间，而非测试功能测试，所以设计数据时，不能因为人为的原因导致业务操作失败，如果是数据导致业务失败，那么在结果分析过程中分析事务的成功率就不准确了，导致影响整个性能测试的结果。

4、数据量充足

准备的数据是否充足也会影响到性能测试结果，比如在一些业务场景中，因为数据量不够，导致准备的数据比脚本迭代的次数少，那么将会重新循环或一直使用最后一个数据，这样就容易导致一些业务失败。

5、无敏感数据

安全性是软件特性中的一个很重要的维度，在设计数据进行性能测试时，需要注意避免一些敏感数据，即使使用，也应该用密文显示而非明文。

13.2.5 环境设计

环境设计主要是确定性能测试执行过程中服务器和测试机所处的环境，包括三部分内容：

系统运行的拓扑结构图：用于指导如何搭建测试环境

拓扑图

服务器和测试机环境：一是服务器和测试机的硬件配置；二是服务器和测试机的软件配置；服务器的硬件配置是一个基准环境，而负载机的硬件测试配置则受每个VUser 运行时所消耗的内存资源的影响；

配置表

环境的备份与恢复：需要这么做有两个原因：

（1）测试前如果环境不确定，可能会导致一些数据运行失败，进而导致一些业务运行失败；

（2）如果不及时恢复环境，会影响到手工测试的数据，所以建议性能测试环境和手工测试环境剥离开来，我们目前就是用虚拟机作为手工测试环境，物理机环境用于性能测试；

13.3 性能测试构建

性能测试设计完成后，需要将设计的策略变成现实，这样才能执行性能测试。构建阶段需要完成以下几个方面的工作：

13.3.1 脚本开发

脚本开发过程

下面这个表是脚本开发检查点，在实际应用中，可以将它与脚本规范检查合二为一。

脚本开发检查点

13.3.2 场景设计

场景设计就是将场景模型转化为场景策略的过程。主要包括：场景策略、负载机、RTS、集合点设置。该过程也可以采用 Checklist 方式保证质量。

（海量免费测试资料加1140267353，群内还会有同行一起交流哦~）

场景设计检查点

13.3.3 搭建测试环境

根据环境设计策略搭建需要执行测试时的环境，一是搭建环境，二是审核环境。

13.3.4 准备数据

指根据数据设计的策略生成测试过程中需要的数据，其中包含两类数据：一是基础数据；二是测试过程中需要参数化的数据。基础数据一般都存在数据库中，但对于参数化过程中需要使用的数据则不一定是存储在数据库中，可能存储在不同的载体中，那么在存储这些参数化过程中使用的数据时，选择的载体很重要，因为不同的载体会影响到参数化的技术。

13.4 性能测试过程执行

根据性能测试的策略不同，性能测试执行策略也有所不同，并且一般需要执行多次才能达到目的。

13.5 性能测试分析、诊断、调节

在完成负载测试的设计、构建和执行阶段后，项目将进入分析、诊断和调节阶段，这一阶段是实时和反复进行的，负载测试解决方案应该提供有关最终用户、系统级别和代码性能数据的全面信息，同时查找导致性能降低的可能原因，这些信息能使你确定是否已经达到性能目标。

（1）监控。可显示基础设备每个层上所发生的一切，同时会更清晰地提供有关测试中数据库服务器、Web服务器、应用程序服务器、单个应用程序或流程的信息。

（2）分析。将各种指标关联起来，以获取有关应用程序行为的其他信息。

（3）诊断。高效的性能测试解决方案应该向性能工程师提供有关层、组件、SQL语句是如何影响负载业务流程整体性能的单个统一视图，性能工程师能看到由最终用户交易所接触到的所有组件，然后确定各组件使用的处理时间及调用次数。

（4）有些自动化性能测试解决方案可系统地识别并分离基础设施性能瓶颈，然后通过修改系统配置设定来解决它们，通过反复解决基础设施性能瓶颈，可以不断改进配置。