电子商务之性能测试 - 精通测试的java攻城师

Z时代
2024-01-10
分类：综合

java

电子商务之性能测试

首先提供oracle性能监控的小工具：spotlight

注释：在此特别感谢

bonjoui 博主

原文地址：http://bonjoui.iteye.com/blog/1901417

1引言
互联网和电子商务技术的发展，人们可以足不出户完成在线购物、实时通讯、信息检索等操作，这些系统大部分是B/S架构。对于系统本身而言，其性能直接决定了可容纳的在线用户数和用户体验满意度，而用户数的攀升意味着广告等收入增长，所以性能测试在B/S系统中起到了一个非常关键的作用，尤其是面向公众的互联网系统。
2什么是性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试，包括负载测试，强度测试，批量测试等类型。在性能测试过程中，会发现很多系统潜在的问题，这些问题往往与一定规模的访问量有关，所以无法通过简单手工测试发现。借助于测试工具或者自己编写的脚本，模拟实际场景对目标系统进行全方位性能测试，能够将问题暴露在上线之前，减少后期维护成本。
3性能测试阶段划分
性能测试整个过程大体可以划分为测试规划、测试执行和结果分析。本文引入一个测试模型用于实例讲解，相关信息见下表1：
表1 测试模型
模型系统名称网上购物系统
模型系统架构基于MVC三层架构的B/S系统
模型系统功能商品浏览：用户随意进入网站进行商品浏览。
订单提交：注册用户登录后，下订单购买商品，系统返回成功与否。
后台处理：数据库每天晚上11点自动执行数据库脚本，清算当日的交易数据。

4性能测试规划
测试规划是整个性能测试最复杂，也最有价值的一部分。测试规划包括：确认测试目标、整理业务流程、制定量化指标、制定测试用例与场景、准备测试资源、安排测试计划。
4.1确认测试目标
针对不同被测系统，需首先明确本次测试的目标。比如设定为“检验当前系统各业务功能的并发处理能力”，由于系统参与人员的职责不同，对性能测试的目标定位也不相同，需综合实际情况来确定。在本文测试模型中，假定有产品经理和技术经理两个角色，他们对于性能测试目标简要归纳为表2所述，综合两者就能确认本次测试目标。
表2 测试目标
职责测试目标
产品经理检验系统能够支撑的最大用户访问量、最佳用户访问量、每秒钟最大事务处理数、是否能够满足预期业务量7 * 24小时运行需要。
技术经理检验系统性能瓶颈所在、有没有内存泄漏、中间件和数据库的资源利用率是否合理。
一般而言，性能测试是作为一个上线之前的验收环节。处于这个阶段的系统功能基本都已开发完成，测试目标主要是对系统整体的一个性能测验。此时发现核心组件需要修改，调整的代价是很昂贵的。我们可以在项目建设初期就可以引入性能检测，在开发过程中就对各业务模块进行测试，进一步细化各阶段的测试目标，如下图所示：
图 1. 性能测试切入点

从图1可以看出，系统本身有很多测试切入点。当用户界面层还不稳定的话，可以从业务逻辑层着手，对系统进行性能检测。如果把系统看作是一幢大楼，则至下而上的每一层就是一个组件，组件本身牢固了，房子整体才结实。
4.2整理业务流程
测试目标确认之后，就需要针对这个目标，对业务流程进行整理，对于功能复杂的系统，还需要业务和开发人员的参与，以下方面可以关注：
1：区分用户操作流程与系统的处理流程。两者都是业务流程，但是系统处理流程是后台发起，用户不可见。例如，本文测试模型中，商品浏览属于用户操作流程；数据库自动执行批处理是系统处理流程。
2：站在用户的角度模拟业务操作，要覆盖到所有的操作分支，包括容易产生的操作中断。
业务流程整理直接关系到后续的测试用例和场景设计，两者决定了性能测试数据是否能够真实反映系统状况，当遇到性能测试实施团队不熟悉业务的情况，性能测试项目经理需安排支援。
4.3制定量化指标
在性能测试报告中，系统性能状况会体现为一堆测试指标及对应的数值。被测目标不同，指标集合也不同，针对本文测试模型，可以制定以下简单的指标（更加细化的指标可参阅相关文档）。
功能层：事务平均响应时间、每秒完成的事务数、成功的事务数、失败的事务数。
中间件：JVM内存使用情况、中间件队列、线程池利用率。
数据库：队列长度、最占资源的SQL、等待时间、共享池内存使用率。
操作系统：CPU平均利用率、CPU队列、内存利用率、磁盘IO。
有了指标，我们还需要根据测试目标，设定其对应的数值范围。例如根据产品经理要求，在并发一千人访问的情况下，系统平均一次事务响应时间不超过5秒，则可以设定响应时间的数值范围是小于5秒成功，大于5秒失败。还可以指定CPU利用率、JVM内存利用率等性能指标的数值范围（表3），需要说明的是，不同测试工具支持的指标集是不同的，可利用多个测试工具进行协同收集。
表3 性能指标数值范围
指标项目测试场景合理指标值
平均CPU利用率并发一千用户 < 85%
平均JVM利用率并发一千用户 < 80%
量化的性能指标能够给系统带来优化的目标，当我们说性能符合预期，指的是所有指标的值都在理想范围以内，那么如何制定正确的数值范围呢，这个就必须靠经验和系统历史数据来进行分析。前者是类比同类型系统的性能指标，后者需要挖掘运维数据，包括用户访问峰值，每秒最高事务处理数等。
4.4制定测试用例与场景
性能测试用例是对整理过的业务流程进行再分解，描述其成为可测试的功能点，结合性能指标转换为测试执行代码。本文测试模型中，用户登录的用例简要描写如下（省略掉用例前置条件，例如系统配置和部署信息）：
表4 测试用例1
登录测试用例
1：用户打开网站首页，页面应该正常展现，超过60秒则算失败。
2：用户输入账号和密码，点击登录按钮，等待系统提示成功或失败，如果等待超过60秒，则算登录失败。
测试用例1中，用户与系统有两次交互（打开网址和点击登录按钮），需分别统计每一次交互的等待时间。考虑到用户实际操作的话，会有一定的停顿，我们可在脚本中添加思考时间来模拟（固定或随机等待时间）。不要小看这个设置，在用户量大的情况下，对系统施加的压力是完全不同的，然后在在统计的时候，去掉这部分思考时间。
性能测试用例执行需对应的场景，用于模拟系统实际运行状况。全面的系统测试在理论上是不可行的，所以设计测试场景的时候，主要定位是用户典型的应用场景。可粗略划分为两类：功能点测试场景和复杂业务测试场景。前者的目标主要是检验系统某个功能点的并发能力，后者更加贴近系统实际运行情况。对于测试模型的用户登录功能，设计功能点测试场景1如下：
表5 测试场景1
并发用户数：总共300，起始数量100，每1秒钟增加10个用户。
运行方式：每一个并发用户循环执行登录测试用例，持续15分钟。
考虑到业务流程可以交叉进行，例如测试模型中数据库批处理与用户操作混搭，我们设计一个复杂的测试场景如表6所示：
表6 测试场景2
并发用户数：总共300，起始数量100，每1秒钟增加10个用户。
运行方式：数据库启动批处理清算，同时并发200个用户进行循环登录，另外100个用户随机浏览商品。

4.5准备测试资源
测试资源包括4个方面：
1：硬件资源。性能测试环境应该采用与生产环境一致的硬件条件，严格来说，如果硬件环境不一致，性能测试报告是不具备说服力的。
2：软件资源。性能测试目标系统需要部署与生产一致的软件，在系统上生产之后，往往会增加一个监控软件，但监控软件也是有资源损耗的，尤其是B/S系统，频繁的抓取JVM数据，会造成较大的压力。
3：数据资源。数据量对性能的影响非常大，分两种情况考虑测试数据，第一种是已经运行的系统做改造，则可以把生产环境的数据备份到测试环境。另外一种是首次上线的系统，这个时候业务数据是空的，需要造一些测试数据。至于数据量的级别，可以预测两年后，业务数据量会有多少，性能测试需要有一定的前瞻性。
4：人力资源。性能测试会发现很多问题，而问题的定位和解决，需要更加专业的人来完成，包括商业软件提供商。测试过程中，保持与开发团队的紧密沟通，是顺利开展项目的关键。
4.6安排测试计划
当测试资源、可执行代码准备好之后，就需制定一个测试计划并分阶段实施，简单示例如表7所示。
表7 测试计划
测试项描述测试类型/测试目标（简要）
基准测试收集系统基准测试性能指标强度测试，获取基准测试数据数据。
开发调试开发修复性能测试发现的Bug
功能点测试对各业务功能点进行性能测试强度测试，获取系统最大并发值等数据。
复杂业务测试复杂业务场景性能测试容量测试，获取最佳用户访问值等数据。
开发调试开发修复性能测试发现的Bug
长时间负载测试系统在一定负载的情况下，长时间运行。疲劳测试，发现内存泄漏等情况。
表7测试计划说明如下：
1：表7中省略掉了测试项目的起止时间，包括了开发调试的工作。这是因为在实施过程中，如果遇到性能问题，开发是需要时间去修复的，性能测试有可能需要暂停。
2：首先进行功能点测试，通过之后再进行复杂业务测试，这是因为单个功能点相对简单，业务逻辑复杂度不高，资源竞争与数据锁等问题不太容易暴露。
3：基准测试是系统日后升级的性能比较对象，例如在硬件升级后，同样的测试场景，是否会得到更优的结果，系统新技术的引进或版本升级，对性能的影响是正面还是负面，都可以通过与基准测试比较得出。
4：每一个测试阶段都有相应的测试目标，采用的测试类型也不同，具体需根据之前的测试规划来制定。

5性能测试执行
执行过程需要注意以下事项：
1：注意保存测试运行过程的数据，作为测试结果的佐证。
2：有问题尽快反馈，系统的修改可能导致测试返工。
3：基准功能点测试过程中，需清理测试现场后再进行后续的测试，因为系统可能存在缓存。
4：按优先级测试各业务场景。
6测试结果分析
每次执行完测试后，会得到一个测试结果。先别着急完成后续的测试任务，可以先简要的分析一下本次测试结果，看看数据是否符合逻辑。例如，对于同一个测试场景，增加并发用户数（强度测试中常见），却发现响应时间反而变短，这就不符合逻辑。当所有的测试任务完成后，分析数据并提交测试报告，注意以下方面：
1：针对不同角色的人员出具不同的测试报告，对于技术人员，可以有较多的性能数据和分析。
2：进行一些前瞻性的预测，综合本次测试的资源情况和指标数据，分析系统性能扩展的瓶颈。
7总结
性能测试不是一锤子买卖，随着系统不断升级，性能测试需要作为一个常态被关注。性能测试领导者也需保持对业务的关注，及时调整测试策略。