qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

如何有效开展性能测试

 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总结

  性能测试不是一锤子买卖,随着系统不断升级,性能测试需要作为一个常态被关注。性能测试领导者也需保持对业务的关注,及时调整测试策略。

posted on 2013-07-25 10:51 顺其自然EVO 阅读(310) 评论(0)  编辑  收藏 所属分类: loadrunnerweb 前端性能测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年7月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜