读书笔记之LoadRunner性能测试巧匠训练营(十）

《LoadRunner性能测试巧匠训练营》第9章 java项目性能测试全程实践

1.项目目标分析

1）水平扩展：支持数据库、应用服务器水平扩展，支持明年150万PV及后续增长率目标（按100%计算，即2015年600万PV）。
2）低耦合性：降低Uncle AP及其相关依赖系统的耦合性，在接口不变的情况下，支持各部分组件单独演化，支持未来的服务化。
3）可用性：保证大量用户访问时的可用性，降低响应时间。
4）服务化：提供服务层接口，减少目前控制层逻辑，为服务化做准备。
5）模块化：提供独立的/可共用的分库组件，支持Oracle、MySQL以及Hibernate/MyBatis的迁移。
6）热迁移：支持不停机迁移数据，支持按照客户ID的方式进行迁移，数据迁移仅对该用户可感知，对其他用户仍正常提供服务。

1.1 系统架构

从上图中可以看出，Uncle AP项目的业务复杂度比之前的.NET项目高。
1）数据库种类复杂：数据库有MySQL、Oracle、MongoDB，物料库还按照拆库分表策略进行了水平拆分。
2）业务调度复杂：Uncle AP项目不仅仅有本身的广告发布系统，还要依赖一些外围支撑系统，如审核系统、计费系统报文系统等。
3）性能要求较高：因为数据库数据量和业务量增长迅速，所以对系统性能提出了较高的要求。

1.2 业务流程

Uncle AP项目的主要功能点有登录、发布广告管理、报告管理三大核心模块，广告发布管理又分为计划/组/广告词管理、生效管理等几大核心功能。

2.性能测试需求获取以及确定

2.1 性能测试环境需求描述

性能测试需求的描述是需要有一定的规范的，否则提取到的需求就是无效需求。性能测试需求满足以下要求。
1）准确：如系统必须在不超过10秒的时间内完成200个用户的登录，再比如50个并发查询报告的响应时间最大不超过3秒。
2）一致：开发工程师、用户和性能测试工程师对有关术语的理解要一致，如并发用户数、在线用户、注册用户。例如，系统支持300用户并发操作、系统的在线用户为3500、系统的注册用户是120万。
3）特定：性能测试的需求一定是有条件的，不同逻辑复杂程度、不同数据量传输下的性能肯定是不一致的，一个单笔往数据库进行5000个插入（insert）操作的功能与一个单笔只往数据库进行10个插入操作的性能要求肯定是不一样的。同样，一个一次性下载1000万笔数据的下载操作同一个一次性只下载1笔数据的下载操作性能要求同样是相差巨大的，所以这就要求在需求获取的时候，对场景进行特定的描述。例如，检查系统在200个用户的负载下，所有业务是否正常可用及稳定；检查系统在300个用户的负载下，连续运行72小时过程中，订单上传、转单、详情单查询、发运等业务动作是否可用及稳定；检查系统在9.0GB业务数据、500个并发用户运行的负载下，连续运行72小时过程中，以上业务动作是否可用及稳定。因此，性能测试需求必须包含多少用户（who），在什么时间（when）或者持续多久（when），在多大数据量的基础上（how much），进行了什么业务（what），最终需要关注怎样的指标（how）。除此以外，需要根据项目性质和性能测试的目标来获得性能测试需求的来源（where）。
2.2 性能测试环境需求获取

性能测试需求来源和分析方法：

• 开发过程相关文档
• 相似项目性能需求
• 业界公认标准
• 用户使用模型
• 80/20原则
• 业务分布图
• 系统日志

性能测试需求来源对应的应用场景

• 日志分析
• 80/202/8原则
• 业务分布图
• 用户使用模型
• 业务公认标准
• 相似项目性能需求
• 开发过程相关文档

2.3 性能测试需求确定

在根据业务增长量进行计算后，制定了满足系统2年后的最终性能测试目标。
1）登录：要求最少支持70个并发用户，响应时间在2s内。
2）数据库单条写操作：要求最少支持180个并发用户，响应时间在2s内。
3）数据库批量写操作（系统批量操作，一次往数据库写200条数据）：要求至少支持191并发，响应时间在5s内。
4）数据库读操作（默认查询，分页显示20）：要求最少支持220并发，响应时间在2s以内。
5）数据库读操作（分页显示200）：要求最少支持110个并发用户，响应时间在3s以内。
6）数据库聚合以及排序操作：要求最少支持160个并发用户，响应时间在3s以内。
7）系统1s内最大的并发用户数为612个，对应混合场景；在进行混合场景测试时，不同功能按照比例分配612个并发用数。
到这里就确定了Uncle AP项目的性能测试目标，该目标满足2年以后的性能要求。有一点需要注意的是：只对并发量做了增长，但是响应时间没有变化，因为现在的响应时间是满足用户要求的，所以响应时间是不需要增长的。

3.性能测试场景获取以及用例设计

3.1 性能测试场景获取以及制定

性能测试选取方法如下：
1）用户量访问比较大的功能，应该优先纳入性能测试场景。
2）与金钱相关比较重要的场景，应该优先纳入性能测试场景。
3）影响业务主流程的场景，应该优先纳入性能测试场景。
4）开发人员认为可能存在性能问题的场景，应该优先纳入性能测试场景。
5）应该考虑综合场景，防止线程争用导致现场死锁以及数据库死锁。
6）应该做稳定性场景测试，防止长时间运行导致的内存泄露情况发生。

3.2 性能测试数据确定

一些不恬当的专家观点
1）性能测试需求很重要，大家应该好好重视。之前看到的网上绝大多数性能测试人员包括一些所谓的性能测试专家对需求的描述就是来源于需求文档，或者是随便拍脑袋决定，如果测试后达不到预定需求，就对性能测试需求进行降级。这是一种很不负责的行为，既然从事性能测试这一行业，就应该热爱这一行业，好好地想想如何把性能测试这件事情做得更加规范化，让开发人员/产品人员信服，从而提高自己的价值。不应该是随波逐流、故步自封，在没有做过的前提下，否决现在大数据时代为性能测试带来的变革和冲击，所有事情只有在做过之后，才会知道它的意义，就像日志分析和容量规划一样，它们不是停留在表面的说辞，而是需要性能测试人员去尝试，然后根据自己公司的现状并结合自己的理解去实践和完善。
2）应该好好设计性能测试场景，而不应该是自己拍脑袋的事情。同样在很多性能测试群里看到很多性能测试人员，包括一些专家，基本上都是拍脑袋凭经验得出性能测试场景。性能测试场景同样需要性能测试人员好好地设计规划，引入较为合理的和让人信服的手段去设计性能测试场景，从而不遗漏场景。
3）性能测试场景设计中很重要的一点就是场景数据的设计。比如设计一个数据查询场景，如果该场景对应的数据库表只有10条数据，那么查询结果肯定相对较快；但是如果这个查询场景对应的数据库表有1000万条数据，那么查询结果肯定会比只有10条数据的查询结果要慢一些。如果测试时不考虑数据量，那么性能测试结果数据是不准确的，上线后由于未考虑数据量的因素，而引发性能问题的几率会很大。
4）希望测试界的各位有自己的见解和想法，然后去实践，别做“只说不做”的大话家，要做思考总结实践的实干家。只有做过之后，才会有自己的见解，然后形成自己的知识体系。

3.3 性能测试用例设计

4.性能测试环境准备与搭建

4.1 性能测试环境

性能测试环境包括软件环境、硬盘环境和网络环境。这三大环境不仅仅是指应用服务器环境，还包括数据库服务器环境、缓存服务器、文件服务器以及其他中间应用服务器环境。
硬件环境包括：CPU、内存、硬盘等基本因素。
软件环境包括：软件版本号、软件位数、配置文件等。比如JDK的版本以及位数、数据库软件版本、Tomcat的版本。配置文件包括JVM配置、线程池配置、数据库配置文件等。
网络环境包括：网络协议以及网络带宽等。
集群环境包括：应用相关服务器（包括文件服务器等）的负载均衡环境、数据库（包括缓存数据库等）的热备或者主从环境、集群环境等。
4.2 搭建仿真性能测试环境

4.3 Mock Server的准备

5. 操作系统性能监控分析工具的选择及使用

5.1 Windows性能监控工具选择及监控详解

常用的Windows性能监控工具有Windows自带的Perfmon和Quest公司的Spotlight on Windows工具。下面分别介绍这两种Windows性能监控工具。
1.Perfmon
Perfmon是Windows自带的性能监控工具，在Windows命令行中输入Perfmon就能打开该工具，如下图所示。Perfmon主要可以提供操作系统的一些基本数据，如内存、CPU、I/O、网络相关的信息，同时提供图形化报表，具有日志、跟踪和警报等功能。
（1）Perfmon使用说明
Perfmon的计数器主要分为4种：处理器性能计数器、内存性能计数器、磁盘性能计数器以及网络性能计数器。这里的对象是指性能监视器对象。任何一个对象都会有多个计数器，并且可能会有多个实例。在系统中，有多个处理器或系统有多个硬盘时就是这样的。

下面介绍几个常见的计数器：

• CPU监控
• 内存监控
• I/O监控
• 网络监控

（2）Perfmon性能监控分析方法

• 内存分析方法：内存分析用于判断系统有无内存瓶颈，是否需要通过增加内存等手段提高系统性能表现。内存分析需要使用Memory类别和Physical Disk类别的计数器。
• 处理器分析法
• 磁盘I/O分析方法
• 进程分析方法
• 网络分析方法