《性能测试原理及实例分析》由会员分享,可在线阅读,更多相关《性能测试原理及实例分析(11页珍藏版)》请在金锄头文库上搜索。
1、性能测试原理及实例分析作者:柳胜【摘要】 在大型软件系统投入生产之前进行性能测试已经成为趋势,本文结合一个性能测试案例对性能测试的过程和原理进行了介绍。【关键字】 性能测试并发测试 负载测试 软件测试中的性能测试软件测试是保证软件质量的重要手段,也是软件过程中一个必不可少的环节。而性能测试则隶属于软件测试中的系统级测试,它对软件在集成系统中运行的性能行为进行测试,旨在及早确定和消除软件中与构架有关的性能瓶颈。 性能测试的含义目前对性能测试没有明确的定义,一般地,它主要是针对系统的性能指标制定性能测试方案,执行测试用例,得出测试结果来验证系统的性能指标是否满足既定值。性能指标里可能包括系统各个方
2、面的能力,如系统并发处理能力,批量业务处理能力等。 性能测试的分解在性能测试的执行中,可以根据具体的性能指标,分解为几种测试,根据其关系,可以在不同的时间和空间内执行。这些子测试通常包括以下几种:并发测试:验证系统的并发处理能力。一般是和服务器端建立大量的并发连接,通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试:验证系统的负载工作能力。系统配置不变的条件下,在一定时间内,服务器端在高负载情况下的性能行为表现。这里的负载可以是用户数,交易数,事务数等。配置测试:核实在操作条件保持不变的情况下,系统在使用不同配置时其性能行为的可接受性。健壮性测试:核实
3、被测系统的性能行为在异常或极端条件之下的可接受性。这里的异常或极端条件指的是资源过少,用户数过多,突发故障等。随着软件系统的规模日益庞大,结构日趋复杂,对软件系统的性能测试已经成为必须和趋势。尤其大型的分布式软件系统更要在正式运行前进行性能测试,因为这样的系统在投入生产之后,往往要接受大批量的业务量,这对应用程序本身,操作系统, 中心数据库服务器,中间件服务器,网络设备的承受力都是一个严峻的考验。在其中任意一个环节出现的问题都可能给用户带来巨大的商业损失。预见软件系统的并发承受能力以避免商业风险,这是在软件测试阶段就应该解决的。例如中国人民银行的现代化支付系统和上海外汇交易中心的本币交易系统都
4、在投入生产之前进行了多轮的第三方性能测试,起到了很好的作用。下面我就介绍一个性能测试案例。 一个 性能测试实例 被测系统1)被测系统介绍本系统应我国金融信息化发展设计,采用当今比较先进和流行的技术,是运行在城域网上的大型分布式应用系统。本系统遵循 J2EE 规范,采用 B/S 体系结构进行设计和开发。业务主要分为交易业务和查询业务,查询业务采用 J2EE 规范,交易业务以 J2EE 体系架构为基础,进行进一步的处理,采用了 TCP 的四层结构。系统体系结构图如下:图表 1 被测系统体系结构设计图* 表示层: 运行在终端上。运行 java applet 程序,提供协议控制和用户界面,与系统最终用
5、户实现直接交互,通过 TCP/HTTP 与前置系统通讯。向前置系统发送请求报文,并接收前置系统返回的回应报文。* 商业逻辑层:作为中间层实现核心业务逻辑服务。交易应用服务:运行在交易主机上。在 tuxedo 中间件上运行业务处理程序,按交易规则处理前置机发来的交易指令,通过 tuxedo jolt 与前置机连接,通过 DB2 C API 与数据库连接。交易前置服务和查询前置服务:运行在前置机上。交易前置服务运行服务程序接收终端请求报文并通过 tuxedo jolt 客户端将其转发给交易主机,再通过轮询和同步反馈接收交易主机返回的报文,将其转发给业务终端;查询前置服务运行在 weblogic 应
6、用服务器上并调用 Jreport 组件,通过 JDBC 完成对查询流指令的发送并接受数据库返回的结果给业务终端。* 数据层:运行在数据库主机上。负责整个系统中数据信息的存储、访问及其优化。运行 DB2 数据库服务程序。通过 DB2 C API 与交易主机通讯,JDBC 与查询前置服务通讯。数据库主机和交易主机运行在交易中心城市,前置机运行在各个分中心城市,终端是各个城市参加交易的单位,整个系统覆盖城域网。2) 被测系统的性能要求和性能指标金融系统是业务处理十分频繁、数据交换吞吐量很大的系统,业务处理的速度直接关系到公司的经济效益和客户对公司的评价。在客观条件下,整个广域网系统必须在大业务量的情
7、况下同时保持快速的实时响应能力,以保证整个业务系统的通畅运行。用户对此提出如下性能指标:表格 1 用户要求性能指标表下面我们会根据此系统和给定的性能指标来进行性能测试: 对被测系统进行性能测试性能测试的目的是最大程度地模拟真实业务场景,来验证系统的性能指标,并发现可能存在的性能瓶颈。1)对被测系统进行系统分析我们可以看到本系统大体上由终端、前置机、交易主机、数据库主机节点组成。在整个业务流程中,业务终端前置机交易主机数据库主机形成了一个压力流串,每个节点在压力下能够正常工作是整个系统正常运转的基础。也就是说,如果其中任意一个节点在业务压力下发生了拥塞、处理不力等不正常情况,那整个系统都无法正常
8、运转。我们来看一下业务流程。首先,从终端到前置机,终端产生业务报文发送至前置机,前置机上运行查询前置服务和交易前置服务,查询前置服务向下通过 HTTP协议以 WEB 服务形式和终端连接,向上通过 JDBC 直接与数据库系统相连。交易前置服务向下通过基于 TCP 协议的 socket 连接和终端通讯,向上通过 tuxedo jolt 客户端和交易应用服务连接。交易应用服务进行业务逻辑计算,并操作数据库系统。由以上分析,我们可以整理出整个系统的两条压力流程线来,之所以我们把其分为两条流程线,是因为交易前置服务和查询前置服务的工作原理完全不同,下与终端的连接,上与交易主机的连接也完全是独立的两个通路
9、。终端交易前置机交易主机数据库系统终端查询前置机数据库系统下面我们先独立分析两条流程线,之后我们将再次综合分析,以考虑二者之间的相互影响作用。第一条路线上主要运行的是登陆指令和交易指令信息。当系统运作时,多个交易终端与交易前置服务建立 socket 连接,完成登陆,之后发送交易指令,造成对交易前置服务的压力。交易前置服务通过运行服务程序接收到交易指令,并检验其合法性,然后通过交易中间件 tuxedo 的客户端把业务的压力传递给交易主机进行处理。交易主机进行必要的金融计算和业务逻辑运行,得出反馈结果,生成消息,一方面顺原路返回到各个终端上去,一方面记录入数据库。在本条流程线上的加压主要考验交易前
10、置服务程序的 socket 多连接建立能力,tuxedo 交易中间件的即时响应能力,交易主机的计算能力,以及 DB2 数据库的 DML 语句加锁机制。第二条路线上主要运行的是查询指令信息。查询指令产生时,通过 http 协议访问 weblogic 上的 web 服务器和应用服务器上的相应组件,以 JDBC 接口访问后台的 DB2 数据库,并把数据库返回的结果发送至终端界面。在本条流程线上的加压主要验证 weblogic 处理能力,数据库中索引是否创建合理。两条流程线相对独立,但又是互相依赖的。由于是对同一个数据库系统进行读操作和写操作,查询流程的结果依赖于交易流程数据的产生,交易流程的产生的数
11、据又通过查询流程得到验证。在进行压力测试时,两者的协同会对数据库形成压力的冲击。鉴于以上分析,结合用户性能指标,我们决定把本次性能测试分解为如下几个子测试来进行。A: 并发登陆测试:750 个终端一分钟内并发登陆系统,并且响应时间在 30 秒之内。B: 业务负载测试此下又有三个子测试。* 交易流程测试:多个终端发起交易请求,逐渐加压,以达到 300 笔/秒的压力为限。* 查询流程测试:多个终端进行查询,逐渐加压,以达到 400 笔/秒的压力为限。查询成功与否以所请求的 web 页面完全展现为标准。(查询响应能力其实和数据库中的数据量有关系,后来和用户进一步确认,基础数据为 30 万条)* 综合
12、测试:在上面两种测试都通过的情况下,进行综合测试。2)性能测试的执行过程,性能测试依照下面的步骤来进行:* 第一步:测试脚本的开发本次压力测试采用 MI 公司的 loadrunner 工具,脚本编辑和编译工作在 VU Generator(脚本作坊)中进行。理想的脚本是对现实世界的业务行为进行了完全无误的模拟,这其实是不可能的。我们的目标是使模拟的误差在我们认可的范围之内,并能有方法加以控制。针对并发登陆测试和交易流程测试,由于两者运行机理相同,都是终端调用 socket client,和交易前置的 socket server 建立连接,将请求消息发送至交易前置机。我们考虑采用将此部分 java
13、 socket 程序编入测试脚本程序,生成登陆和交易业务脚本,通过loadrunner 来执行。这样做的好处是绕过终端 IE 界面复杂的处理逻辑,直接施压在前置机上(这种方式同时也带来了偏差,在执行测试场景时通过其它方法得到了一定的弥补)。脚本除了要实现与前置机的 socket 连接,业务发送等功能,还要建立用户信息数据池,设置检测点、异常退出点,为脚本执行后的结果统计和分析提供正确的依据。交易业务脚本内容略。部分如下:public class Actions /*登陆变量初始化*/ProtocolManager protocol;/ProtocolManager 为实现 socket 连接的
14、类 ServiceName service; /ServiceName 对服务端的信息进行了封装,包括 IP 地址和端口号。LoginMessage login;/LoginMessage 为登陆时需要向服务器发送的消息,待服务器确认并返回回应消息时,登陆成功。 protocol = new ProtocolManager(); /创建 ProtocolManager 类的 protocol 对象 service = ServiceName.getInstance();/获得ServiceName 的实例 login=new LoginMessage();/创建 LoginMessage 类的
15、 login 对象 service.setIP(200.31.10.18);/设置服务端的 IP 地址 service.setPort(17777);/设置服务端的端口号/*设置登陆消息*/ login.serUserName(lr.eval.string(“loginName”);/从数据池里读出用户名,设置在 login 成员变量里login.setPasswd(“1234”);/数据库中添加的用户密码都为 1234/*发送登陆消息*/protocol.login(login);/发送登陆消息lr_start_transaction(trade);/交易开始点 TradeMessage t
16、rademessage;/生成交易消息/*设置交易消息*/./*发送交易消息*/.if(sendfail)lr_end_transaction(trade, LR_FAIL);/如果发送交易消息失败,交易结束,返回。/*循环回收主机返回的处理信息*/if(recievefail)lr_end_transaction(trade, LR_FAIL);/如果不能接收到主机处理回应消息,交易结束,返回。if(recievesuccess)lr_end_transaction(trade, LR_PASS);/如果接收到主机成功处理的回应消息,交易结束,返回。.在上面的例子中,我们主要对每笔交易进行了 transaction 化。在交易开始时设置开始检测点,交易结束时设置结束检测点