Web性能测试（通用9篇）
Web性能测试 篇1
0 引言
WEB应用系统性能是一个非常复杂的问题,由于WEB系统具有多层体系结构,客户、数据通信、硬件、服务器之间的依赖关系错综复杂,使得在每层内和各层之间都可能发生故障。比如浏览器的型号版本差异可能导致页面无法正常显示,服务器端可能出现超链接不可达或者根本不存在,另外服务器、数据库的负载能力有限,在访问高峰时影响甚至破坏服务结果的处理和送达,同时用户间并发处理的相互干扰等等。WEB应用系统的结构特点决定了各种WEB故障的分布。要发现、分析、排除故障和性能瓶颈,通常需要完备全面的WEB性能测试。
1 WEB系统性能测试工具
性能测试技术是软件测试中的重要一环。而WEB性能测试是为了描述WEB应用系统与性能相关的特性并对其进行评价而实施和执行的一类测试。影响WEB系统性能的因素很多。从广义上说,可以大致分为WEB服务器性能和WEB应用程序性能。后者更着重于软件性能优化技术,需要很强的软件设计技巧和方法。前者则更突出于服务器的配置和设置,以最优化的状态运行设计合理高效的应用程序,两者配合默契的共同完成WEB系统应用。根据木桶效应,即木桶装的水量是由最短的木条决定的,WEB系统性能应该从基础设施即服务器性能的提高入手,在高效的环境下构建高质的程序。
本文由南京工程学院校级基金项目(项目号:QKJC2010007)资助。
提供WEB服务的站点和服务器必须具有良好的性能和快速的事务处理能力。在WEB应用开发过程中,需要不断地测试服务器的反应和承载能力,以防止系统投入运行后出现诸如大批量访问造成系统瘫痪等问题。因此,需要一种能够真实模拟大量用户访问Web应用系统的性能测试工具进行压力测试,来测试静态HTML页面的响应时间,甚至测试动态网页(包括ASP、PHP、JSP等)的响应时间,为服务器的性能优化和调整提供数据依据。WEB服务器性能测试即需要完备的测试计划和专业的测试人员,更需要功能强大的测试工具,俗话说工欲善其事,必先利其器,选择一个好的合理的测试工具是决定测试工作成败与否的关键。
目前多数WEB服务器性能测试工具都是通过录制或者编写测试脚本,让这些脚本以多进程或者线程的方式在客户端运行并模拟多用户大量的重复的服务器并发请求,用一种自动的可控的形式得到服务器运行相关数据,并对这些数据进行分析汇总,进一步提出系统优化方案。测试工具主要包括以下几个部分:
(1)虚拟脚本产生器:通过录制客户端和服务器间的通讯包,自动产生测试脚本,用户可在脚本上进行修改,从而快速开发出一个同客户端应用一致的测试脚本程序。
(2)压力产生器:以线程或进程方式运行测试脚本程序。
(3)压力调度和控制系统:决定压力产生器如何运行脚本及对整个压力测试进行控制,是测试工具的核心。
(4)结果分析工具:根据测试数据进行数学统计和分析,提出优化建议。
测试主要指标有:
响应时间:响应时间通常作为用户视角的WEB系统性能的主要指标,一般是指“应用系统从请求发出开始到客户端接收到最后一个字节的响应所耗费的时间”(TTLB)。
并发用户数:所有用户在同一时刻对系统发出了请求或者进行了操作。这些请求和操作可以是不同业务类型的。测试工具通过对不同并发用户数的设定和测试,能模拟出真实应用环境下系统的性能表现。
吞吐量:单位时间内系统处理的客户请求数量。直接体现系统的性能承载能力。在对WEB系统的性能测试过程中,吞吐量主要以请求数(单击数)/秒、页面数/秒或字节数/秒来体现。吞吐量的限制是性能瓶颈的一种重要表现形式,因此吞吐量指标可以协助分析和快速定位系统瓶颈所在。
资源利用率:资源的实际使用/总的资源可用量。如WEB服务器的CPU使用率,磁盘使用率等。资源使用率通常进行横向对比,比如某系统资源A的使用率达到100%,而其它资源的使用率都处于比较低的水平,从而确定资源A可能是系统性能瓶颈。
目前已经存在的WEB性能测试工具数量不下一百种,从单一的开放源码的免费小工具如Aapache自带的Web性能测试工具Apache Benchmark、开源的Jmeter到大而全的商业性能测试软件如Mercury的LoadRunner等,都有各自的适用范围。专业级的大型商用测试工具由于其昂贵的价格和复杂的使用方法,使得其在WEB性能测试领域受到一定限制,而诸如Apache Benchmark和Jmeter这样的小而容易使用的开源测试工具受到普遍欢迎。
Ache Benchmark(AB)是命令行形式的工具,可以模仿单独的URL请求并且重复地执行,可以使用不同的命令行参数来控制执行迭代的次数,并发用户数等等。它的一个特点是可以周期性地打印出处理过程的信息,而其它工具只能给出一个全局的报告。例如运行Apache Benchmark的一个例子:同时处理50个并发请求并运行1000次index.php,我们可以在cmd shell中输入ab-n 1000-c 50 http://202.19.161.180:80/test/index.php,运行结束后,ab会自动显示测试结果,在并发50个请求的情况下,完成1000次的访问请求,共花了262.515秒,这个程序每秒可处理3.81个请求等信息。
AB(ApacheBench)是Apache自带的超文本传输协议(HTTP)性能测试工具。在实际应用中,ApacheBench程序中存在很多不足和缺陷。如:用户需要花费很多时间来学习使用AB,测试数据的非汉化,测试数据的不全面,对命令行参数、服务器的响应头和其他外部输入的解析也简单。请求分布过于简单,仅仅是同时建立多次连接,无法模拟真实的网络请求情况。测试结果只是针对总体测试而言,没有单个请求的测试信息。另外没有完整实现HTTP/1.x,仅接受某些“预想”的响应格式,Strstr()的频繁使用可能会带来性能问题,即你可能是在测试AB而不是服务器性能等等。针对以上问题,在Apache上基于AB系统设计开发一种新的性能测试工具势在必行。
2 AB系统的改进
在Delphi环境下我们开发了一个新的Apache性能测试工具,利用多线程技术实现多用户并发,采用管道技术实现对数据的共享。设计并实现一个新的系统,可以很好的对网站进行性能测试。整个系统是在ApacheBench的原型下进行的改进。系统设计应该考虑易用性、直观性和可控性。新系统继承了AB系统的优势,并对其不足之处进行了改进。主要表现在:用户界面可视化,系统简单易用;增加了一些新的测试指标,如往返请求/响应次数等,并且测试指标完全汉化;测试过程的可控性更加完善;对命令行参数、服务器的响应头和其他外部输入的解析更加具体细化等。
2.1 系统功能
改进后的WEB性能测试系统功能架构图如图1。
系统包括四个部分:测试模板、控制中心、测试程序、测试结果处理程序。
2.1.1 测试模板
负责为测试做数据准备,包括测试脚本的分析与生成及配置测试时用户所需要的参数,包括模拟用户数量、并发用户数等。
首先用户将浏览器设置指定的代理服务器来访问Internet,当用户访问Web服务器时,将HTTP请求发送到服务器,解析请求的目的IP和Port,并与目的IP建立Socket连接,将浏览器发来的请求转发到Web服务器,同时将全部请求传递给解析器。解析器把接收的字节流转换成字符流并对其解析,分析提取HTTP请求和每个请求中的各个域值,同时将每个请求创建一个请求对象,并传递给测试脚本。测试脚本存放请求对象集合并负责处理。以上过程完成系统的测试脚本分析和生成功能。
用户界面接收用户输入的数据和响应用户操作,输入数据包括待测Web的URL、并发数、模拟用户数等数据。用户输入的数据作为参数传递到参数配置组件中,参数配置组件将参数传递到控制中心。
2.1.2 控制中心
控制中心根据测试参数和测试脚本中传入的测试对象集来创建Socket连接池和线程池。Socket连接池的大小和每个Socket连接由测试对象集和线程数决定。线程池的大小由线程组属性参数决定。控制中心控制整个测试过程,是系统的核心部分,负责控制测试模块来模拟真实用户行为,启动和调度每个测试线程,并为每个测试线程分配Socket连接。
2.1.3 测试组件
测试组件是系统的核心组件,由线程加载并执行。测试组件在执行过程中启动两个子线程。这两个子线程分别执行发送请求和接收响应。发送请求组件从测试组件传递的Socket连接中取得输出流对象,并将请求对象集以字节流的形式发送到WEB服务器。接收响应组件在指定的Socket连接上接收HTTP响应的数据流,利用输入流对象接收数据。同时接收响应组件负责对响应信息的HTTP头进行解析,设过程响应对象,并对对象中ID、线程、时间戳属性赋值,最后将响应对象传递给测试数据组件。
2.1.4 测试结果处理程序
测试数据组件中可以将测试结果以文本的方式保存下来。我们可以在一定的推理规则下对测试结果对象集进行统计、计算、分析,并生成对Web系统测试的图形结果和报告,进一步提出系统优化建议。
2.2 系统实现
WEB性能测试系统主要包括建立测试计划、执行测试、测试结果存储等三个部分。测试计划是指在要测试之前制定的测试方案和计划,制定测试计划包括要测试的并发数、模拟用户数、测试结果的存储等。测试部分是按照测试计划来实现对系统的测试。线程组的设置是系统测试的关键内容,线程组的每个参数直接影响测试方式和测试过程。在测试系统中,用一个线程模拟一个真实用户的请求行为,一个线程组来模拟若干个用户请求的真实场景,线程数的大小表示在测试时将要模拟的用户数,而并发用户数是由用户数和启动持续时间决定的。
系统测试部分的实现是整个系统实现的关键部分,也是采用的关键技术最多、复杂程度最高的部分。其中,多线程用管道来实现通讯,并且在后台中定义了一个全局的参数,作为整个系统的接口。测试指标是通过对测试脚本的加载来实现的。如下:
在我们准备测试计划的时候,首先就得把测试脚本engtochn的测试指标设置好,也就是自己想测试Web服务器的哪几个方面的性能。
多线程用管道来实现通讯:
3 结论
WEB性能测试是一项复杂而意义重大的系统工程,我们必须针对具体的应用环境在WEB开发过程中和WEB部署过程中不断的进行性能跟踪和测试,而测试工具的选择和合理的使用及改进对我们的测试工作提供了很大的帮助。本文给出了Delphi环境下开发一个新的Apache性能测试工具的全部过程,利用了多线程、管道、DLL等技术,整个开发过程严格按照CMMI 3要求进行。
参考文献
[1]明仲.一种Web系统性能测试框架及其混合建模过程[J].计算机研究与发展.2010.
[2]彭树深,顾庆,陈道蓄.Web应用测试用例生成研究[J].计算机科学.2010.
[3]李海洋,高志坚.Web应用程序性能测试方法研究[J].电脑知识与技术.2010.
[4]刘冬,靳蓓蓓.基于Delphi7多线程技术在网络中的应用研究[J].信息技术.2007.
[5]刘雪梅.服务器端软件性能分析和诊断方法研究[D].哈尔滨工程大学.2010.
Web性能测试 篇2
1、总计架构测试
1）瘦客户端，业务逻辑规则多数在服务器端执行。如新闻站点、门户网站、信息发布网站等。
2）胖客户端，安全性要求较高、交互操作频繁、业务逻辑复杂。银行系统、网络游戏、网上办公系统等。
2、Web架构组成部分是否满足需求
成本、功能、安全性要求、容量要求、传输实时性。
3、服务器配置分布是否满足要求
Web服务器、应用服务器、数据库服务器可以分布在不同物理机器上也可以分布相同的物理机器上，一般优先考虑独立数据库服务器，Web服务器、应用服务器可以在相同的机器上。
4、客户端设计测试
1）功能设置测试：信息服务、办公自动化、Internet支持； 2）信息组织结构测试：线性结构、分层结构、非线性结构； 3）页面设计测试：a.页面一致性测试
b.用户界面友好性及导航直观性测试；、c.是否适合多种浏览器； d.页文件的命名； e.页面布局技术。
5、服务器端设计测试
1）容量规划测试：点击率、延迟和流量、服务器资源；
2）系统安全测试：a.常识性安全策略，取消不必要的协议、控制写权限、取消服务器目录浏览属性、记录日志等； b.使用加密技术；
c.构造防火墙，网络级、应用级、电路级； d.构建网络防毒体系。3）数据库设计测试。
6、Web开发测试
1）源代码分析，主要是使用检查工具来完成； 2）链接测试，主要借助工具来完成； 3）框架测试：a.自动调整窗口大小； b.是否提供滚动条；
c.打开新页面是否正常。4)表格测试，随窗体变化自动调整大小； 5）图形测试：a.颜色饱和度及对比度； b.链接标识；
c.图形显示是否正确。
1、与一般应用软件相比，Web测试有以下区别：
第一、Web测试的侧重点是性能、安全、易用性、兼容
第二、测试工具有所不同，如链接测试、表单测试、界面测试
2、功能测试
一、客户端的选择，优先测试流行的客户客户端；
二、客户端浏览器的配置
三、客户端的显示设置
四、内容测试
3、链接测试
一、该链接将用户带到它所说明的地方
二、被链接的页面是存在的
三、保证没有孤立页面
工具有WEBCHECK、LINKBOT、TESTPARTNER、XENU等
4、链接测试工具的优势：
一、简单易用
二、在实现上采用多线程技术，检查速度特别快；
三、对断开的链接可以再次测试，可以避免误判；
四、没有检查链接的数量限制，只受系统资源的约束；
五、可以分析Web应用的结构；
六、检查结果可以分类查看，自动生成HTML格式的报告；
5、Web应用链接主要测试点如下
一、测试内部链接和外部链接中成功和失败的链接点，以及应用中不被其他链接调用的页面；
二、测试链接中新网页、老网页、慢网页以及丢失的图象标题标签和属性标签等；
三、分析Web应用的结构是否合理，包括显示和某个URL相关的链接以及按照标题、描述、作者、大小、最后修改时间、类型为URL链接分类等。
6、易用性测试
易用性测试要考虑以下几个方面： 1）用户的计算机使用经验；
2）用户对浏览器以及Web的使用经验； 3）用户的业务专业知识。
7、Web系统的易用性测试分为三个方面： 1）界面测试
2）辅助功能测试 3）图形测试
一、界面测试要考虑以下几个问题 A．WEB应用系统的最终用户群是谁？ B．WEB应用界面的设计策略是什么？ C．页面中各元素布局的协调性 a.各元素位置的协调性 b.各元素颜色的协调性
c.各元素大小比例的协调性 D．不同页面风格的统一性
E．用户在界面中操作的便利性 F．界面动态操作测试
a.屏幕分辩率设置的影响
b.浏览窗口最大化/最小化的影响 c.选定目标元素的置中与缩放
二、辅助功能测试 A．使用说明，这个没有多大意义，WEB网页按F1弹出来的页面都是IE的帮助页面，除非有特定的帮助说明内容； B．导航功能 C．站点地图
Web性能测试 篇3
随着网络技术的迅速发展,以Web应用为代表的各项网络应用日益改变着人们的生活和工作方式。但随之而来的问题是网络上Web流量的激增,导致一些热门Web站点由于负载过重而变得反应迟缓。许多基于Web的管理信息系统涉及的信息量非常庞大,用户访问的频率很高,这些特点都在实时性和吞吐量上对Web系统的性能提出了很高的要求。因此基于Web系统的测试、确认和验收已经成为Web工程过程中的一个重要的组成部分。
以一个银行设备管理系统作为研究测试对象,运用LoadRunner测试工具对其进行压力测试。通过模拟真实负载,找出性能瓶颈,进行优化改进,从而保证Web系统在实际运行中能够保证良好、可靠的性能。本文的测试方案、测试方法、数据分析的方法以及相应的解决方案,同样可以应用于其他Web应用的测试和分析中。
1 Web 性能测试
1.1 Web 性能测试指标
Web应用程序通常支持多用户并发,关键是在高峰期能很好的运行程序。一个成功的Web应用程序通常具有以下3种性能特征:
(1) 短响应时间
响应时间是指客户机从请求开始到收到请求响应的延迟时间长度来衡量。在技术上,应用程序的响应时间是全部组件响应时间的和,包括Web服务器、数据库服务器、网络连接等。响应时间随客户机请求数量的增加而增加。当服务器处于低负载时,系统能够服务较多的客户请求,所以响应时间较快。当服务器处于重负载时,系统能够服务较少的客户请求,所以响应的时间较慢[1]。
(2) 高吞吐量
Web应用程序的吞吐量是指在单位时间内客户请求系统进程的数量,相应时间单位通常是秒。它测试的是实际的数字,而不是最大的能力。当系统负荷轻时,吞吐量会根据客户机请求的数量而增加。当客户的请求数量继续增加时,在一定的时间点上它会达到峰值点,然后开始下降。
(3) 强伸缩性
伸缩性是指客户请求数量增加时应用程序运行的性能以及系统升级时应用程序性能增加的程度来测量的。一个好的应用系统应该能够通过简单的升级硬件而不必重新设计新编码就能够进行扩展。
1.2 Web 性能测试工具
测试工具通常分为两类,一类是用于对服务器端的性能指标进行测试;另一类是用于对客户端的性能指标进行测试。本文所进行的基于负载的性能测试主要围绕客户端模拟并发用户来展开讨论。
对于服务器端性能指标的观测,可以利用服务器自带的工具来进行。在Windows 2000/2003 Server中自带了一个性能监视器, 可以通过菜单操作“开始|管理工具|性能”来运行。通过在性能监视器中添加所要观察的计数器(即性能指标) ,就可以获得程序运行时的性能指标变化图。在Linux操作系统中也有类似的性能监视工具。
对于客户端性能指标的测试,通常是利用测试软件模拟真实用户的操作行为来进行。许多Web服务系统测试方案采用的是Java,C++等通用编程语言控制模拟用户的行为以及模拟用户数量。这类解决方案的一个明显问题在于编写模拟程序的复杂性,即测试人员不得不在程序代码中逐个处理所要测试的页面,以及要面对Web应用的所有细节,因此完成一个测试程序往往要花费比较长的时间。
随着自动化测试工具的出现,如Rational Robot,QALoad ,LoadRunner 和微软的WAS 等客户端性能测试工具。其中Rational Robot,QALoad,LoadRunner都是比较不错的商业测试工具,但是价格也非常昂贵,而微软的WAS 是一个免费的测试工具,使用起来比较简单,但是由于不能显示和编辑所录制的测试脚本,其可控性和图形化测试结果都较弱,故造成一定的局限性。
LoadRunner是一款优秀的商业性能测试软件,是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner可以使企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。因此本文中采用LoadRunner进行客户端的性能测试[2]。
2 测试环境和测试用例设计
考虑到系统的网络并发访问情况是否能够支持大量用户。当多用户并发访问时是否会造成用户响应速度过慢,系统崩溃等问题,决定选用LoadRunner8.0 作为测试工具。
测试系统结构如图1所示,其由LoadRunner、Web Server 和DM Server 组成。
首先在Web Server上运行Tomcat,并且登陆设备管理系统。
对于系统性能测试所设计的测试用例是多用户在登陆后同时提交某项请求,每个请求的信息量不相同,即文件大小不一,例如设备维修单的提交等情况。在LoadRunner 录制需要登陆的系统时,是把登陆部分放到vuser init中;把登陆后的操作部分放到Action中;把注销关闭登陆部分放到vuser end中[3]。
可以对维修单提交做以下情况的测试:
(1) 该系统已有100个维修单
20个用户并发提交
40个用户并发提交
60个用户并发提交
80个用户并发提交
(2) 该系统已有200个维修单
20个用户并发提交
40个用户并发提交
60个用户并发提交
80个用户并发提交
设定每组测试运行所用的时间为10分钟,用来测试JSP页面,测试20个、40个、60个、80个并发用户同时访问系统时,系统的运行状态。
具体细节描述:在测试服务器上运行设备管理系统,通过LoadRunner来调节虚拟用户的数量,依次为5,10,15……每次增加5个用户,记录系统响应时间,得到对应并发用户状态下软件的平均响应时间,分别做20个、40个、60个、80个并发用户的平均响应时间的记录。
3 测试结果分析以及系统瓶颈分析
根据以上实验测得的数据,此被测Web系统在100个和200个维修单状态下系统处理维修单所得到的平均响应时间,测试数据结果(单位:秒)分别如表1-2所示。
根据测试数据显示,随着并发用户数量的增加,系统处理维修单提交这项事务的平均响应时间变长。在相同并发用户数量情况下,系统已有维修单数目越多则系统响应时间越长。
通过对设备管理系统的部分功能进行性能测试发现,并发用户在30到50之间时,其性能指标是比较理想的,系统对于事务处理的响应时间比较及时。但是在多用户并发访问的情况下,一旦在线用户数量超过此峰值,而服务器响应时间开始变慢,已经不能保证正常工作,需要更新服务器硬件或者对系统进行优化。因此可以断定,服务器端数据库和CPU为系统瓶颈,如果对数据库进行优化,就能够为系统整体的性能带来较大的提升。
4 优化方案
通过测试分析,发现系统的瓶颈主要来自于数据库和服务器的资源不足。因此从以下3个方面对系统进行了改进,以提高系统整体的性能[4]。
(1) 服务器资源的优化。
因为IIS(网际网路资讯服务)可以从缓存中完成请求,所以扩充服务器内存,增大IIS 缓存空间,可以解决部分服务器资源不足的问题,提高访问速度。
(2) 数据库设计的优化。
对于经常执行的数据库操作,使用存储过程代替SQL语句,以减少操作规模和结果集合;选择合适的索引策略,避免使用光标处理等方法来提高数据库性能。
(3) 数据库连接管理的优化。
建议系统使用数据库连接池的方法访问数据库,这样一些数据库访问行为可以共享同一数据库连接,不但减少了频繁打开、关闭数据库连接的操作,而且可以控制当前激活的数据库连接总数,防止系统过载。
5 结束语
通过运用LoadRunner对一个实际运行的银行设备管理系统进行性能测试的实例,阐述了影响Web系统性能的关键因素,并以此为基础,通过模拟大量用户的不同操作行为,对Web系统的性能进行测试。通过分析测试数据发现系统的瓶颈,并进一步提出了系统的优化方案,其意义在于对其他Web系统的性能测试活动亦有一定的借鉴作用。
参考文献
[1]易文明.基于浏览器/服务器模式的设备管理信息系统的设计与实现[D].华中科技大学硕士学位论文,2006.
[2]蔡志.LoadRunner操作入门[EB/OL].无忧测试网http://www.51testing.com.
[3]刘艳会.LoadRunner使用手册[D].测试时代,2006,2:2-16.
浅谈Web应用服务器测试 篇4
作者：中国软件评测中心 2002年11月
随着Internet 的发展壮大，新的开发模式也应运而生，即所谓的B/S（浏览器/服务器）结构、瘦客户机模式。为了方便的开发、部署、运行和管理基于三层、多层结构的应用，需要 以Web的低层技术为基础，规划一个整体的应用框架，提供相应的支撑平台，这一支撑平台实 际上是基于Internet的中间件，即应用服务器。
应用服务器通过把用户接口、商业逻辑和后台服务分割开来，向开发者提供一种创建、部 署和维护企业规模的Web应用的模块化方式，从而对要转向Web的用户提供了高性能多线程的环 境。
考虑到web应用服务器的以上应用背景和产品特点，把为功能度、性能、兼容性、安全可 靠性作为重点测试方向，并且引用SUN Mircrosystems公司的J2EE标准作为参考标准。
一、功能测试
功能测试的主要目的是验证一款产品是否是一个符合J2EE标准的企业级web应用服务器。测试前，应针对J2EE标准中的JSP、SERVLET、JDBC、EJB等主要功能编写测试用例。测试 用例应尽量覆盖典型的应用和操作，以此来证明一款产品符合J2EE标准中提到的功能。特别是 功能度测试项目，应遵循开发厂商提供的用户手册或程序员手册中有关功能部分的描述作为依 据具体制定。
二、性能测试
性能测试的主要目的是考查在大压力和大数据量情况下，应用服务器最大处理能力和系统 响应时间，同时考查不同压力情况下应用服务器处理能力和系统响应时间。
测试过程中，首先通过JDBC接口与数据库进行连接，根据被测系统的应用环境和实际情况 制定与之相适应的案例数据库。然后使用功能测试中用到的JSP、Servlet和EJB测试程序，通 过Web Application Stress Tool1.1录制相应的测试脚本，模拟在多用户并发情况下数据库的 插入、更新、查询，并记录成功点击次数、点击率等相关参数。最后通过远程监控系统对Web 应用服务器的CPU占有率、内存进行实时监控，通过对上述数据的汇总分析，得出功能服务器 的性能。
三、兼容性测试
兼容性部分的测试应分成两部分来考察：即硬件兼容性和软件兼容性。
硬件兼容性主要验证Web应用服务器的硬件配置要求。测试中，可以根据厂商提供的安装 手册承诺的配置信息，来验证功能服务器的硬件兼容性。
软件兼容性考察的方面较多，主要包括：系统兼容性、数据库兼容性、Web服务器兼容 性、开发工具兼容性、与其它中间件产品的兼容性、J2EE组件的兼容性等多个方面。
四、安全可靠性测试
Web性能测试 篇5
关键词：Web服务器,Java,性能测试,压力测试,系统响应时间
1 Web服务器性能测试工具的重要性
Web应用服务器是为创建, 部署, 运行, 集成和管理事务性Web应用, 而提供一系列运行时服务的可伸缩、高可用、高可靠, 高效的中间件平台。一般在设计开发Web应用系统的时候, 很难对其进行全面的性能测试和压力测试, 因为web应用系统在实际运行中, 用户请求经常以爆发的方式到达web服务器的高峰, 高峰时的请求率往往超过正常平均值的8~10倍。并且由于用户对于web请求的网络通信量分布是呈相似的, 也就是Web请求的通信量可以在大范围内有显著的变化, 就会使web服务器在高峰时的请求率容易处于过载状态。所以当web服务器遇到访问高峰或访问异常时, 容易产生服务器性能急剧下降, 服务器响应速度变慢, 服务中断, 甚至导致服务器的崩溃等问题。为了避免这些情况, 就需要一种能够真实模拟用户访问web应用系统的测试工具, 并及时对其进行测试, 从而及时发现缺陷, 而采取应对的措施。
2 web测试的分析和测试结果
针对大学生网上选课系统进行web测试的要求, 利用Java网络和多线程的编程特性, 研究并开发了一套基于Java的web服务器性能测试工具, 并用它进行web测试。学生通过网上浏览器进入网上选课系统, 然后在其中填入自己的数据, 再提交, 然后服务器再根据其数据进行分析和执行, 并把处理的结果返回给学生们所处的客户端。为了更准确地知道Web测试工具的性能, 就要更全面地进行各种测试, 而对于了解大量学生在相同的时间段同时访问Web动态网页的情况, 该测试工具就需要处理下面的几个问题: (1) 测试工具怎样才能模拟出大量学生同时访问Web的情况; (2) Web测试工具需要模拟出单个学生访问Web时个性化的请求参数。本套Web性能测试工具主要由四个模块构成:图形化用户界面程序、性能测试数据文件及处理程序、性能测试程序和测试结果分析程序。在测试过程中, 测试程序会开启x个线程, 而每个线程可以开设y个会话来模拟x乘以y个学生对服务器同时进行访问的情况。然后每个线程再从性能测试数据文件中读取学生的数据, 然后就可以对web服务器进行访问了。因为每个学生在数据库中的数据是不同的, 所以他们访问页面时要请求的参数也是不同的, 再发送请求时程序就会开始计时, 程序等待就会自动接受Web服务器的回复, 就会停止计时, 同时计算本次的连接时间、分析Web服务器的信息, 并把详细的测试结果发送到指定的文件。所以, 由以上可以知道Web性能测试工具能够真实准确地模拟出任意指定数目的学生同时访问Web服务器的情况。
3 内容
模拟学生进行选课的操作, 就会遇到下面的几个问题:一个就是session值的传递和怎样获取学生们准确的session值。解决这个问题, 就要利用到URL、URLConnection类, 具体的使用是:首先使用URL类建立对login.jsp页面的URL连接, 会返回一个URL类对象, 然后再获取该学生本次连接的ID, 并使用URL类把此sessionl D作为参数传递给下一个URL连接, 这样就能够使session值正确传递。
另一个难点就是对JSP动态页面进行模拟时, 如何根据不同学生选课时对课程的不同需求, 从而对于选课页面的测试。还有一个难点就是如何对多线程进行监控并在多线程下对数据保持同步。具体是:通过扩展java.1ang包的Thread类, 先生成一个监视线程, 就可以对多线程的运行进行监视, 并能够随时终止并退出测试。通过重新改写Thread类的run方法, 利用java.net包的URL、URLConnection类来实现对服务器的连接和测试。
4 测试结果
使用该测试工具对大学生网上选课系统进行Web服务器性能测试。发现在现有的条件下, 选课系统的响应时间和出错率是和测试人数成正比的, 但是当测试人员达到一定数量时服务器的响应速度就会开始变慢, 性能也开始下降, 当人数再增加时, 出错率也会提高, 系统的平均响应时间就会接近10秒, 此时系统基本就不能运行了。这也达到了这次测试的目的。
5 结语
本研究提出的是一个基于Java的Web性能测试工具, 充分地利用了Java面向对象的编程方法和它所提供的多线程机制和网络特性。该测试工具是由纯Java语言编写的, 因此具有可移植性、安全性和面向对象等优点。作为一个完整的web服务器性能测试工具, 它还具备以下功能:发送个性化的用户请求信息;可以发送GET和POST等不同类型HTTP的请求。获取和传递Sessionl D;多线程;模拟用户延迟;记录测试性能数据等功能, 从而提供丰富且有意义的测试参数。
参考文献
[1]姚念民, 鞠九滨.过载服务器的性能研究[J].软件学报, 2003, 14 (10) ;1781-1786
[2]CAY S.HORSTMANN.最新Java2核心技术 (卷1, 2) [M].北京:机械工业出版社, 2003
Web压力测试及测试工具分析 篇6
1 基本概念
1.1 安全性测试
所谓安全性测试是有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。安全性测试并不最终证明应用程序是安全的, 而是要提供证据表明, 在面对敌意和恶意输入的时候, 应用仍然能够充分地满足既定需求。
1.2 Web安全性测试
Web安全测试就是使用多种工具, 来模拟和激发Web应用活动。完整的Web安全性测试可以从部署结构、输入验证、身份验证、配置管理、敏感数据保护、会话管理、参数操作、异常管理、审核和日志记录等几个方面入手。
2 安全隐患
2.1 SQL注入攻击
所谓SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序, 而这些输入大都是SQL语法里的一些组合, 通过执行SQL语句进而执行攻击者所要的操作, 其主要原因是程序没有细致地过滤用户输入的数据, 致使非法数据侵入系统。
2.2 跨站式脚本攻击
跨站脚本攻击 (Cross Site Scripting) 是一种经常出现在web应用中的计算机安全漏洞, 它允许恶意Web用户将代码植入到提供给其他用户使用的页面中。XSS攻击分成两类, 一类是来自内部的攻击, 主要指的是利用程序自身的漏洞, 构造跨站语句, 另一类则是来自外部的攻击, 主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。
2.3 跨站点请求伪造
跨站请求伪造 (Cross-site request forgery) , 是一种依赖web浏览器的、对网站的恶意利用, 通过强迫访问主体的采用浏览器的方式向已登陆的Web应用系统发送一条伪造的HTTP请求, 包括受害者会话信息、身份信息等内容, 从而导致相关的应用程序认定该请求是受害者本人所发出的合理请求。
2.4 无效的认证及会话管理
对应用程序的访问者的认证及会话管理, 在执行过程中常常发生各种问题。导致攻击者通过数据包抓取、重放攻击等手段, 获取到密码、密钥、会话授权, 从而盗取用户身份。
2.5 不安全对象的直接引用
当某种内部私有对象的引用被公开时, 例如一个文档、目录服务结构等关键信息时, 可能发生这种情况。由于缺乏对访问者的身份检查、访问控制检查或其它安全保护措施, 攻击者们能够利用这些引用信息对那些未获授权的数据进行访问。
2.6 安全配置错误
好的安全保障体系需要一套经过精心定义及部署的设置方案, 其对象包括应用程序、系统框架、应用程序服务、页面服务、数据库服务以及运行平台等。上述这些设定应该被精确地定义、执行和保存, 然而事实上大多数情况下, 用户会直接使用安全保障系统的默认设置, 而其中有许多项目并未被正确配置, 包括全部软件的及时更新以及应用程序所要调用的全部代码库。
2.7 敏感数据明文传递
许多Web应用程序, 在信息传输、存储时, 并未采用加密或散列方法来保护这些敏感内容, 例如用户口令、证件号码、信用卡信息等。攻击者们可以窃取或修改这些数据, 从而冒用受害者身份、进行信用卡诈骗或其它犯罪行为。
2.8 URL伪造
许多Web应用程序在跳转到那些受控访问资源之前, 都会检查访问者的URL。应用程序应该在每次接收到页面访问请求时, 都进行一次这样的检查, 否则攻击者们将可以通过伪造URL的方式随意访问这类隐藏页面。
2.9 传输层数据完整性保护
应用程序常常无法实现对网络通信内容完整性的验证、加密、保护等功能。当这种情况发生时, 应用程序有时会选择支持那些低强度的加密算法、使用过期的或者无效的验证信息, 或者是无法正确应用这些安全保障功能。
2.1 0未经验证的转发与重定向
页面应用程序经常将使用者的访问请求重新指向或转发至其它网页和网站上, 并使用不受信任的数据来定位目标页面。如果没有正确的验证机制在此过程中加以制约, 攻击者完全可以将受害者的访问请求重新指向到钓鱼类或其它恶意软件网站上, 或者将访问转发至未经授权的页面。
3 常用测试工具
3.1 SQL Inject Me
SQL Inject Me是检测SQL注入攻击的一种常用工具, 它是火狐浏览器的附加组件, 通过它可以检测全部架构或选中的参数所能受到的各种攻击方式, 或者是检测该工具中预设的九种常见攻击类型。当在工具中选定攻击方式后, 再执行SQL Inject Me, 则该工具的运行状况, 包括通过在选项中添加或删除字符串的方式进行攻击。
3.2 ZAP
Zed攻击代理 (简称ZAP) , 通常用来检测跨站式脚本攻击, 它是一款“易于使用的, 帮助用户从网页应用程序中寻找漏洞的综合类渗透测试工具”。ZAP包含了拦截代理、自动处理、被动处理、暴力破解以及端口扫描等功能, 同时包含了蜘蛛搜索功能。
3.3 Hack Bar
Hack Bar是火狐浏览器插件, 可以模拟若密钥保护及散列保护。主要用来检测不具备SSL/TLS的保护的访问会话。如果应用系统对会话ID, 采用MD5码或是SHA1散列形式的密码所保护, 可以采用Hack Bar方式进行模拟, 检测是否通过中间人攻击或是通过XSS漏洞获取到会话ID。Hack Bar在对Base64, 各种URL以及HEX的编码及解码方面也非常实用。
3.4 Burp
Burp是一款Web应用程序安全漏洞分析工具, 可以对路径及目录浏览过程进行监测。Burp同样可以作为一款代理软件来使用;跟ZAP类似, 只要在Foxy Proxy上进行相应设置即可。启动Burp, 然后将你的浏览器指向要访问的目标地址。通过Web Goat, 我们能够检测到是否有规避路径的资源被非授权访问。
3.5 Tamper Data
Tamper Data是检测CSRF攻击的一种常用工具, 它是火狐浏览器的附加组件。在检测Gallery App时, 可使用Tamper Data来测定该Gallery App是否在将所有参数提交给后台脚本时会容易受到CSRF攻击。
3.6 Watobo
Watobo可以使专业的安全人员能够以高效且半自动化的方式对应用程序配置的安全性进行评估。Watobo是以代理工具的角度运行的, 并且需要调用Ruby中的部分内容, 需要在测试环境中安装Ruby解释程序。将Foxy Proxy进行设置, 以使其将网络数据流通过8081端口导入Watobo, 并完成最终分析。
3.7 Nikto/Wikto
Wikto是具备Windows图形用户界面的Nikto程序。通过Nikto或是Wikto能够检测Web应用程序对访问者的URL进行查询之后才向那些被保护的链接及按钮提交请求当然不错, 但如果应用程序并没有在每次接到类似的访问请求时都进行监控, 那么攻击者们将能够获取到这些应用程序所调用的隐藏页面。
3.8 Calomel
Calomel是对SSL连接及安全等级等信息进行验证的工具, 它是火狐浏览器的附加组件。Calomel能够检测SSL的加密强度, 并通过颜色来进行标识;并能够对SSL证书的真伪、状态、内容、自签名等细节进行查询。
3.9 Watcher
Watcher是Chris Weber开发的Fiddler附加组件, 只支持IE内核浏览器测试, 它在被动分析方面优势明显。使用Watche同时还需要运行Fiddler, Watcher将会以被动状态提供对网络数据流的监视及报警功能。
3.1 0其他综合测试工具
(1) N-Stalker。
N-Stalker Web漏洞扫描器是N-Stalker公司研发的一个顶级的安全评估工具。通过与知名的N-Stealth HTTP Security Scanner及其35 000个web攻击签名数据库合并, 以及正在申请专利的W eb应用程序安全评估技术组件, N-Stalker Web漏洞扫描器能为你的Web应用程序彻底消除大量普遍的安全隐患, 包括跨站点的脚本和SQL injection, 缓冲溢出, 篡改参数攻击等等。
(2) Netsparker。
Netsparker是一款优秀的SQL注入安全扫描器。Netsparker与其他综合性的Web应用安全扫描工具相比的一个特点是它能够更好的检测SQL Injection和Cross-sit Scripting类型的安全漏洞。Netsparker能够显示漏洞判定的准确度、支持A j a x/Javascript、采用启发式的检测模式、支持报错注入布尔注入、支持反射型、存储型跨站脚本漏洞检测。
(3) Websecurify。
Websecurify是一款开源的跨平台网站安全检查工具, 是一个强大的Web应用程序安全测试环境, 由底层向上提供了自动和手动的脆弱性测试技术的最佳组合, 能够精确的检测Web应用程序安全问题。
(4) Skipfish。
Skipfish是由google出品的一款自动化的网络安全扫描工具, 该工具可以安装在linux、freebsd、Mac OS X系统和window (cygwin) 。Skipfish与Nikto和Nessus等其他开源扫描工具有相似的功能, 但Skipfish还具备一些独特的优点。Skipfish通过HTTP协议处理且占用较低的CPU资源, 因此它的运行速度比较快。Skipfish每秒钟可以轻松处理2000个请求。
4 结语
Web应用所执行的测试中, 安全测试可能是最重要的, 但它却常常是最容易被忽略的。一般来说, 一个Web应用包括Web服务器运行的操作系统、Web服务器、Web应用逻辑、数据库几个部分, 其中任何一个部分出现安全漏洞, 都会导致整个系统的安全性问题。
对操作系统来说:最关键的操作系统的漏洞, 例如Unix上的缓冲区溢出漏洞、Windows上的RPC漏洞、缓冲区溢出漏洞、安全机制漏洞等等;对W eb服务器来说:WEB服务器从早期仅提供对静态HTML和图片进行访问发展到现在对动态请求的支持, 早已是非常庞大的系统, 即使发展多年的Apache也难逃经常被发现安全漏洞的缺陷, 更不要说千疮百孔的IIS了;对应用逻辑来说:根据其实现的语言不同、机制不同、由于编码、框架本身的漏洞或是业务设计时的不完善, 都可能导致安全上的问题;对数据库来说:数据库注入攻击一直是数据库厂商和网站开发者的噩梦。
除此之外, 安全问题还存在于管理等各个方面, 不完善的管理制度、缺乏安全意识的员工都会是内部的突破口, 同样, 一些开发工具生成的备份文件和注释也会成为Cracker发送攻击的参考资料。
对Web的安全性测试是一个很大的题目, 首先取决于要达到怎样的安全程度。不要期望网站可以达到100%的安全, 即使是美国国防部, 也不能保证自己的网站100%安全。
对于如何保证Web应用程序的安全, 首先要了解必要的安全知识, 从安全风险分析入手, 选择相应的安全检测工具, 查找安全隐患, 弥补安全漏洞, 最终达到进一步加强系统安全的目标。
参考文献
[1]霍普, 等著.傅鑫, 等译.Web安全测试[M].北京:清华大学出版社, 2010.
[2]PC Jorgensen著.韩柯, 等译.软件测试[M].北京:机械工业出版社, 2002.
[3]Ron Patton著.周予滨, 姚静, 等译.软件测试[M].北京:机械工业出版社, 2002.
[4]秦明, 薛胜军.威胁建模技术在Web应用程序中的应用[J].电脑知识与技术:学术交流, 2007 (1) .
[5]吴海燕, 苗春雨, 刘启新, 等.Web应用系统安全评测研究[J].计算机安全, 2008 (4) .
[6]霍汉强.Web应用系统安全问题的探究[J].大众科技, 2008 (3) .
Web应用测试的研究 篇7
随着Web2.0的推出,基于Web的应用越来越深入到我们工作和生活的方方面面:商业、工业、银行、财政、教育、政府和娱乐,许多传统的信息和数据库系统正在被移植到互联网上,以电子商务为典型代表的应用系统越来越普及。尤其在现代企业应用中,各种信息系统在原来的基础上,由基于C/S方式向基于B/S方式转换,逐渐过渡为基于Web的MIS、ERP、EIP乃至CIM的企业业务IT系统,从而使企业管理不再局限于企业内部,而是通过Internet扩展到遍布全球的客户、供应商、合作伙伴等各个环节。
Web应用的日益广泛、日益复杂,使得基于Web的应用系统的实施方法备受关注。目前,在大多数情况下,开发基于Web的系统具有随意性,其测试缺乏系统的方法。因此,研究Web应用的测试是十分必要的,也是十分紧迫的。
2 Web应用的属性
基于Web的系统和应用不同于其他的软件类别,它们具有自身独特的一些属性,因此Web应用的开发过程和测试方法也必将不同于传统软件工程的过程和方法。一个典型的Web应用应该具有以下属性:
(1)网络集约性[1]。一个典型的Web应用驻留于某一个网络的,它必须服务于变化多样的客户群的需要。
(2)内容驱动性。在多数情况下,一个Web应用的主要功能是使用超媒体来表示文本、图形、音频和视频内容给终端用户。
(3)即时性。基于Web的应用具有其他任何软件类型中都没有的即时性。对于某些Web应用而言,甚至是以小时和分秒为单位进行更新。
(4)安全性。由于Web应用是通过网络访问可达的,为了保护敏感的内容和提供安全的数据传输模式,整个Web应用的基础设施和应用本身必须实现强的安全措施。
(5)美学。Web比通常意义上的软件开发使艺术和技术在更大范围内得到结合。美学可能和技术设计在同样的程度上决定应用的成功。
3 Web应用的测试
正是Web应用有上述独特的属性,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试[2]。因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
3.1 界面测试
(1)整体界面测试。整体界面是指整个Web应用系统的页面结构以及页面风格的设计。主要测试整个Web系统的页面布局是否美观、合理;页面在窗口中的显示是否正确、美观。分辨率测试,页面版式在不同分辨率模式下是否显示正常,字体是否太小以至于无法浏览,,文本和图片是否对齐等;验证所有页面字体的风格是否一致;背景颜色应该与字体颜色和前景颜色相搭配。
(2)导航测试。导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口,或在不同的连接页面之间。导航测试的另一个重要方面检查是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。
(3)图形测试。在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情。
(4)内容测试。内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。
3.2 功能测试
(1)链接测试。链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。链接测试可以自动进行,一般可以使用Xenu Link Sleuth以及HTML Link Validator等工具自动进行[3]。
(2)表单测试。当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。
(3)Cookies测试。Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登录等信息。如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。
(4)设计语言测试。Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、Java Script、Active X、VBScript或Perl等也要进行验证。
(5)数据库测试。在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。
(6)应用程序特定的功能需求测试。特定功能的测试要求测试人员对于项目的需求非常熟悉,需要对应用程序特定的功能需求进行验证。
3.3 性能测试
(1)连接速度测试。用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登录。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。
(2)负载测试。负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线;如果超过了这个数量,会出现什么现象;Web应用系统能否处理大量用户对同一个页面的请求。
(3)压力测试。负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。压力测试的区域包括表单、登录和其他信息传输页面等。
3.4 兼容性测试
(1)平台测试。市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。
因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。
(2)浏览器测试。浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java、Java Script、Active X、plugins或不同的HTML规格有不同的支持。例如,Active X是Microsoft的产品,是为Internet Explorer而设计的,Java Script是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。
3.5 安全性测试
(1)目录设置。Web安全的第一步就是正确设置目录。每个目录下应该有index.html或main.html页面,这样就不会显示该目录下的所有内容。另外,要严格控制目录的权限。
(2)SSL。很多站点使用SSL进行安全传送。你知道你进入一个SSL站点是因为浏览器出现了警告消息,而且在地址栏中的HTTP变成HTTPS。如果开发部门使用了SSL,测试人员需要确定是否有相应的替代页面。当用户进入或离开安全站点的时候,请确认有相应的提示信息。是否有连接时间限制;超过限制时间后出现什么情况。
(3)登录。有些站点需要用户进行登录,以验证他们的身份。这样对用户是方便的,他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录,而能够通过有效登录。用户登录是否有次数限制;是否限制从某些IP地址登录;如果允许登录失败的次数为3,你在第三次登录的时候输入正确的用户名和口令,能通过验证吗;口令选择有规则限制吗;是否可以不登录而直接浏览某个页面;Web应用系统是否有超时的限制,也就是说,用户登录后在一定时间内没有点击任何页面,是否需要重新登录才能正常使用。
(4)日志文件。在后台,要注意验证服务器日志工作正常。日志是否记所有的事务处理?是否记录失败的注册企图,是否记录被盗信用卡的使用,是否在每次事务完成的时候都进行保存,是否记录IP地址,是否记录用户名。
(5)脚本语言。脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器,但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言,并研究该语言的缺陷。还要需要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
4 结论
无论是测试Internet、Intranet或者是Extranet应用程序,Web测试相对于非Web测试来说都是更具挑战性的工作。用户对Web页面质量有很高的期望。在很多情况下,就像业务功能一样,页面用于维护和发展公共关系,所以第一印象非常重要。本文从界面、功能、性能、兼容性、安全性等方面讨论了基于Web的系统测试方法。基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。
参考文献
[1]Jeongeun Choi,Byoundju Choi.Test Agent System Design A[].Ewha Womans University,Proceedings of 1999 IEEE Interna-tional Fuzzy System Conference Proceedings,pp326-327,1999.
[2]何友全.软件测试方法与技巧[J].微计算机信息,2000.
Web系统负载测试的实现 篇8
在软件系统日益复杂的今天,考虑到系统终端的维护以及交互问题,许多信息应用系统都采用了Web技术。当一个Web系统未上线使用时,往往不清楚将会有多少注册用户,以及系统能否承受大量用户同时访问。因此,有必要在Web系统正式使用前对其进行全面的负载测试,以检验系统能否达到预期性能。负载测试是Web系统中比较重要的性能测试,主要是在被测系统上不断增加压力,直到性能指标达到极限,如响应时间超过预定指标或某种资源已达到饱和状态。负载测试可以找到系统的处理极限,为系统调优提供依据。本文主要结合作者工作参与的实际项目对Web负载测试的实现进行研究。
2. Web负载测试设计
2.1 需求调研
经过对用户需求的调研和对被测Web系统的分析来确定系统核心业务模块,综合考虑系统角色、数据来源、系统使用习惯、用户预期性能等方面,得出被测Web系统负载测试的主要任务。根据国家软件质量检测标准和用户需求对被测Web系统进行负载测试,检测系统可承受的并发量及响应时间,验证系统是否满足用户需求。
2.2 制定测试案例
1)数据量分析
被测Web系统目标在线用户约85个。根据访问量和数据量分析,可按“并发用户数=在线用户数*30%”公式折算,则系统并发用户数约25个。考虑系统今后的推广,假定未来三至五年用户增长2至3倍,则系统并发量分别为50个、75个。
2)测试策略
采用负载测试工具HP Load Runner分别模拟25、50、75个并发用户,设计独立业务场景和混合业务场景,检测系统典型业务操作可承受的并发量及响应时间,同时监控应用服务器、数据库服务器的系统资源占用情况。
3)测试案例
根据需求分析和数据量分析,制定如下测试案例[1]:
前提条件:整个系统安装配置完成且功能正常。
网络环境:100M局域网。
测试指标:系统响应时间小于5秒。
独立业务场景:登录系统、问题上报、查询统计。
混合业务场景:根据系统实际应用情况,分别以50%、40%、10%的用户数比例执行登录系统、问题上报、查询统计操作进行混合并发。
场景执行策略:各场景分别设置三组测试,并发用户数为25、50、75个。
3. Web负载测试流程
Web负载测试流程主要包括测试环境的确认、测试脚本录制、测试脚本编写与调试、设计测试场景、执行测试、获取测试结果、结果分析等环节[2]。下面针对被测Web系统负载测试的关键环节进行介绍。
3.1 测试脚本录制、编写与调试
该Web负载测试采用测试工具HP Load Runner录制脚本,分别录制登录系统、问题上报、查询统计等三个脚本。为了模拟真实的用户操作,需要对脚本进行编辑与优化。
1)插入事务与集合点
为了获取用户并发执行时的响应时间,可通过HP Load Runner自带的函数在脚本中插入事务以及集合点。如登录系统脚本中的登录系统事务名称设为“login”,可在事务开始和结束处分别添加函数lr_start_transaction("login")和lr_end_transaction("login",LR_AUTO),测试完成后分析报告即可查看该事务最小、最大、平均响应时间以及90%以上用户的响应时间[3];为了模拟用户并发操作效果,可在“login”事务开始之前通过函数lr_rendezvous("login")设置集合点,使多个虚拟用户在此处等待所有用户到达再同时进行下一步操作。
2)进行参数化
参数化的作用是避免多个并发用户采用同一个帐户或提交相同的数据。在登录系统脚本中,首先需要批量创建测试帐号,将脚本中已录制的用户帐号替换为参数{login Name}。然后对参数值列表进行设置,使虚拟用户按一定规则获取用户帐号值。如被测系统执行75个并发用户测试,每个用户循环执行3次,那么可创建测试帐号test001至test225共225个。
3)自动关联
被测Web系统在新建问题时系统会自动生成问题编号,问题上报成功后该问题编号则不可重用。由于录制时生成的问题编号无法继续使用,导致问题上报脚本回放失败。测试工具HP Load Runner提供的数据关联功能可解决此问题,它通过web_reg_save_param函数进行参数定义并调用其参数值来替换动态数据。问题上报时需要把问题编号作为一个动态数据,再次新建问题时便获取一个新的有效的问题编号,然后通过函数保存下来。如存储问题编号的参数定义为WCSParam_Diff,在回放脚本时会产生一个新的问题编号保存为该参数的变量值。
4)检查点
为确保系统查询统计结果的正确性,需要验证查询结果页面,避免返回到“无法显示网页”或因服务器繁忙、数据问题返回错误页面。如在查询统计脚本中,可使用该页面的统计表表名进行文本检查。
3.2 设计测试场景
测试场景主要通过Load Runner控制器进行设计与实现。被测Web系统负载测试分为独立业务场景和混合业务场景,其中独立业务场景只需考虑是否需要多个负载生成器,以及配置虚拟用户的运行策略即可。而混合业务场景还要着重考虑各混合业务的用户数分配比例,这部分内容需要在测试现场进一步向用户确认,若与前期制定的测试案例有偏差,应及时调整,并最终确定系统关键业务及其对应的用户使用比例。
而设置监控点方面,该Web负载测试主要关注客户端交易处理性能指标,可通过测试工具HP Load Runner统计分析平均事务响应时间、Web请求的吞吐量、点击数、HTTP状态代码摘要、Web页面组件等。为了检验系统资源是否满足应用需求,还可以监控应用服务器、数据库服务器系统的CPU、内存、磁盘等资源。除此之外还可对数据库、中间件等进行监控,以检测其配置是否合理,是否能支撑系统的正常应用。
3.3 执行测试
Web负载测试通常安排在非繁忙时段执行,主要关注虚拟用户运行情况、事务响应情况是否正常,系统或脚本本身是否出现报错。根据测试结果及时调整测试策略,可随时停止某个Vuser组或各个Vuser,甚至直接中止场景[4]。该Web系统负载测试时查询统计响应比较慢,因此首次测试时将查询统计的各组并发量调整为25、35、40个。
3.4 结果分析
场景执行完毕后可利用Load Runner分析器获取测试结果报告,从业务处理情况、服务器资源、Web服务器资源、数据库资源等进行综合分析[5]。通过整改被测Web系统中查询统计耗时较多的页面,经回归测试表明系统可支持目前及今后推广所预计的应用要求,负载测试过程中系统响应正常,服务器资源利用合理。
4. 结束语
本文以被测Web系统贯穿全文,阐述了Web系统负载测试流程,论述Web负载测试设计与实现,重点描述了测试需求分析、测试案例的制定、测试实现等环节。本文展现的Web系统负载测试实例,有助于读者了解目前Web系统负载测试情况,使读者达到触类旁通,并可将测试需求分析、测试设计、负载测试工具的应用、自动化测试流程等经验应用到其它测试领域。
摘要：本文结合作者工作中参与的测试项目,对Web系统的负载测试进行研究;根据软件测试理论和负载测试原理,采用负载测试工具HP LoadRunner对Web系统进行负载测试;通过分析被测系统的测试需求,设计相应的测试案例。文中引入了自动化测试流程,采用专业的负载测试工具,描述整个Web系统的负载测试设计与测试实施过程。
关键词：Web系统,性能,负载测试,并发,事务
参考文献
[1]陈绍英,夏海涛,金成姬.Web性能测试实战[M].北京:电子工业出版社,2006,24:139.
[2]谈姝辰,尹军.基于负载的Web性能测试研究与应用[J].现代电子技术,2007,30(14):140.
[3]杨莲,陆际光.Web应用性能测试研究[J].电脑知识与技术,2008,2(11):247-250.
[4]柳纯录.软件评测师教程[M].北京:清华大学出版社,2005:304.
Web应用软件系统测试研究 篇9
大多数Web系统采用Browser/Server结构。一个典型的Web系统的结构示意图如图1所示, 包括客户端浏览器、Web应用服务器、数据库服务器、网络及中间件。其中客户端浏览器可以是一般浏览器、手机浏览器和平板电脑等, 例如Internet Explorer、Netscape等;Web应用服务器用于发布Web页面, 接收来自客户端的请求, 并把请求结果返回客户端, 常用的Web应用服务程序有Apache、Tomcat等;数据库服务器保存数据库, 常用的有Oracle、SQL Server等;网络及中间件则提供客户端的请求到Web服务器的通道, 网络可以是Internet/Intranet/Extranet, 也可能是局域网。对于重要的系统防火墙与CA服务器也是必不可少的。因此, Web系统的测试是一项比较复杂的测试工作。
Web应用软件的测试与传统软件相比, 既有相同之处, 又有不同的地方。文献2提出了寻找PHP应用程序中的故障的方法。文献3提出一种Web应用软件结构模型, 该模型分为函数级、函数群级、对象级、对象群级和应用级共5级。就Web应用软件的系统测试进行研究, 从Web应用软件的组成:网页和网站两个层次展开。
1 Web应用软件的网页测试
网页, 是网站中的一个页面, 由文字、图形、动画、音频、视频和超级链接等组成, 通常是HTML格式, 文件扩展名可以是.html、.htm、.asp、.aspx、.php、.jsp等。用户通过对浏览器的操作, 搜索查看所需要的信息。网页测试包括功能测试和可用性测试。
1.1 网页的功能测试
网页的功能测试包括内容测试、链接测试、表单测试和Cookies测试。
内容测试用来测试Web系统提供信息的正确性、准确性和相关性。内容测试通常使用一些文字处理软件进行自动测试, 例如Microsoft Word的“拼音与语法检查”功能, 同时还需要人工测试文本内容和网页上图片的文字描述。
链接是Web软件的一个主要特征, 它使用户实现页面之间的切换。链接测试需要测试3个方面的内容:首先是测试所有链接是否按指示的那样确实链接到了应该链接的页面;其次测试所链接的页面是否存在;最后保证Web网站上没有孤立的页面, 所谓孤立页面是指没有链接指向该页面, 只有知道正确的URL地址才能访问。链接测试可以手动进行, 也可以自动进行。链接测试必须在集成测试阶段完成, 也就是说, 在整个Web网站的所有页面开发完成之后才进行链接测试。
表单是一些需要在线显示和填写的表格, 例如用户注册、登陆、信息提交等。表单测试主要是模拟表单提交过程, 测试表单提交是否准确。表单测试主要考虑以下几个方面: (1) 表单提交应当模拟用户提交, 测试是否完成功能。例如使用表单来进行在线注册, 要测试提交按钮能否正常工作, 当注册完成后能否返回注册成功的消息。 (2) 测试提交操作的完整性, 以测试提交给服务器的信息的正确性。 (3) 如果使用表单收集配送信息, 应确保系统能够正确处理这些数据, 需要测试服务器能否正确保存这些数据, 而且后台运行的程序能否正确解释和使用这些信息。 (4) 要测试数据的正确性和异常情况的处理能力。 (5) 表单测试时, 会涉及到数据校验问题。例如, 用户注册页面中在某可选字段区中不填写内容提交表单, 在某必填字段区中不填写内容提交表单, 输入超出字段所能接受的最大长度的字符串。对于有固定操作流程的表单测试, 可以考虑自动化测试工具。
Cookies是由网页服务器发送出来存储在客户端浏览器目录的非常小的文本文件, 通常用来存储用户信息和用户在某些应用系统上的操作序列, 当一个用户使用Cookies访问了某一个应用系统时, Web服务器将发送关于用户的信息, 并把该信息以Cookies的形式存储在客户端计算机上, 这可用来创建动态和自定义页面或者存储登录等信息。B/S结构Cookies中存放的信息更多。如果Web系统是用了Cookies, 需要对它们进行测试。测试内容包括:Cookies是否能正常工作;Cookies是否按预定的时间进行保存;刷新对Cookies有什么影响等。例如:如果在Cookies中保存了注册信息, 应确认该Cookies能够正常工作而且已对这些信息进行加密。如果使用Cookies来统计次数, 需要验证次数累计正确。
1.2 网页的可用性测试
网页的可用性测试包括导航测试、图形测试和界面测试。
导航描述了用户在一个页面内操作的方式, 可以在不同的用户接口控制之间, 例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。导航测试的内容包含:导航是否直观?Web软件的主要部分是否可以通过主页访问?Web软件是否需要站点地图、搜索引擎或其他的导航器帮助?测试导航条、菜单、连接的风格是否一致?测试各种提示是否准确, 确保用户凭直觉就知道是否还有内容, 内容在什么地方。最好让最终用户参与导航测试, 效果将更加明显。
在Web软件中, 适当的图片和动画既能起到广告宣传的作用, 又能起到美化页面的功能。一个Web软件的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有: (1) 测试图形是否有明确的用途, 图片或动画不要胡乱地堆在一起, 以免浪费传输时间。 (2) 测试所有页面字体的风格是否一致。 (3) 测试背景颜色与字体颜色和前景颜色是否搭配。 (4) 图片的大小和质量也是一个很重要的因素, 一般采用JPG或GIF压缩, 最好能使图片的大小在30KB以下。 (5) 测试文字环绕是否正确。 (6) 测试图片能否正常加载。
界面测试是对整个Web系统的页面结构设计的测试, 是用户对系统的一个整体感受。例如, 当用户浏览Web网站时, 应考虑:页面各元素的位置、颜色、大小比例是否协调?是否感到舒适?用户在界面中的操作是否容易, 能否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?
2 Web应用软件的网站测试
所谓网站, 就是指在Internet上, 根据一定的规则, 使用HTML等工具制作的用于展示特定内容的相关网页的集合。用户通过网页浏览器来访问网站, 获取自己需要的信息或者享受网路服务。网站测试在网页测试的基础之上还包括功能测试、性能测试、安全性测试和兼容性测试。
2.1 网站的功能测试
网站的功能测试包括数据库测试、Web网站特定的功能需求测试和设计语言测试。
数据库在Web网站中具有十分重要的作用, 数据库为Web网站的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用软件中, 最常用的数据库类型是关系型数据库, 可以使用SQL对信息进行处理。数据库测试是Web网站测试的一个基本组成部分。测试人员需要了解后台数据库的内部结构和设计概念, 执行详细的数据库测试计划, 至少能在程序的某个流程点上并发地查询数据库。数据库测试要测试数据完整性、数据有效性、数据操作和更新。
测试人员需要依据程序需求规格说明书对Web网站特定的功能需求进行测试。例如:开发一个在线考试系统, 测试用户可能进行的所有操作:考生登录后自动组卷, 考生答题结束后自动收卷, 试卷自动分析和评阅, 考生查询成绩, 教师试题录入等。
不同的Web设计语言版本的差异可以引起客户端或服务器端严重的问题, 例如使用哪种版本的HTML;尤其在分布式环境中开发时, 开发人员都不在一起, 这个问题就显得尤为重要。除了HTML的版本问题外, 使用Java、Java Script、Active X、VBScript或Perl等开发的应用程序也要在不同的版本上进行测试。
2.2 网站的性能测试
网站的性能测试对于网站的运行而言非常重要, 主要包括负载测试、压力测试和连接速度测试。
负载测试是为了测量Web系统在某一负载级别上的性能, 以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量;也可以是在线数据处理的数量。负载测试包括的内容有:测试Web系统最多能允许多少个用户同时在线?如果超过了这个数量, 会出现什么现象?Web系统能否处理大量用户同时对同一个页面的请求?负载测试应该安排在Web系统发布以后, 在实际的网络环境中进行测试。一般使用自动化工具来进行。
压力测试是测试Web系统的限制和故障恢复能力, 也就是测试Web应用系统会不会崩溃, 在什么情况下崩溃。压力测试的区域包括表单、登录和其他信息传输页面等。压力测试应该关注:瞬间访问高峰, 每个用户传送大量数据, 长时间的使用。压力测试需要利用一些辅助工具对Web系统进行模拟测试。
连接速度测试是对打开网页的响应速度的测试。用户连接到Web应用系统的速度根据上网方式的不同而不同, 可能是电话拨号上网、宽带上网、局域网、有限电视网、光纤网、移动网络。不管用户使用哪种方式, 系统都不能让用户在访问一个页面时等太长的时间。如果访问一个页面Web系统响应时间太长 (例如超过10秒钟) , 用户就会因失去耐心而离开。有些页面有超时的限制, 如果响应速度太慢, 用户可能还没来得及浏览内容, 就需要重新登录了。而且连接速度太慢, 还可能引起数据丢失, 使用户得不到真实的页面。
2.3 网站的安全性测试
对于有交互信息的网站以及电子商务网站, 网络安全问题尤为重要, 需要对Web系统进行安全性测试, 包括目录测试、SSL套接字测试、登录验证测试、日志文件和脚本语言的测试。
目录安全是Web安全性测试中不可忽略的问题。如果Web系统处理不当, 通过简单的URL替换和推测, 会将整个Web目录暴露给用户, 这样会造成Web的安全性隐患。每个目录下应该有Index.html或严格设置Web服务器的目录访问权限, 这样就不会显示该目录下的所有内容。
SSL (Security Socket Layer) 是由Netscape首先发表的网络数据安全传输协议, 它利用公开密钥/私有密钥的加密技术, 位于HTTP层和TCP层之间, 建立用户和服务器之间的加密通信, 从而确保所传送信息的安全性。如果Web系统使用了SSL, 需要测试是否有相应的替代页面, 适用于3.0以下版本的浏览器, 这些浏览器不支持SSL。当用户进入或离开安全站点的时候, 测试是否有相应的提示信息。还要测试是否有连接时间限制, 超过限制时间后会出现什么情况等。
目前很多网站都需要用户注册后登录使用, 从而校验用户名和匹配的密码, 以验证其身份, 阻止非法用户登录。登录测试的主要测试内容有:测试用户名和输入密码是否大小写敏感?测试有效和无效的用户名和密码?测试用户登录是否有次数限制, 如果有次数限制, 超出限制是否还能通过验证?测试是否限制从某些IP地址登录?测试密码选择是否有规则限制?测试哪些网页和文件需要登录才能访问和下载?测试是否可以不登录直接浏览页面?测试Web应用系统是否有超时限制?
日志文件对于保证Web应用系统的安全性至关重要, 需要测试相关信息是否写进了日志文件, 是否可追踪。
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录, 其他脚本只允许访问邮件服务器。但有经验的黑客可以利用这些缺陷攻击和使用服务器系统。测试人员需要找出站点使用了哪些脚本语言, 并研究该语言的缺陷, 测试是否构成安全问题。
2.4 网站的兼容性测试
兼容性测试用来测试Web系统是否可以在用户使用的机器上运行。如果用户是全球范围的, 需要测试各种操作系统、浏览器以及浏览器各种设置下Web系统能否正常工作, 包括平台测试和浏览器测试。
市场上有很多不同的操作系统类型, 最常见的有Windows、Unix、Macintosh、Linux等。Web网站的最终用户究竟使用哪一种操作系统, 取决于用户系统的配置。这样就可能会发生兼容性问题。同一个应用可能在某些操作系统下能正常运行, 但在另外的操作系统下可能会运行失败。因此, 在Web系统发布之前, 需要在各种操作系统下对Web系统进行兼容性测试。而且客户端分辨率设置的不同也可能会使网页内容显示面目全非, 影响用户的正常使用, 还要测试页面版式在640x400、600x800或1024x768的分辨率模式下是否显示正常?
浏览器是Web系统客户端最核心的软件, 来自不同厂商的浏览器对Java、Java Script、Active X或不同的HTML有不同的支持, 甚至有些HTML命令或脚本只能在某些特定的浏览器上运行。例如, Active X是Microsoft的产品, 是为Interne Explorer而设计的, Netscape本身是不支持Active X的, 需要安装插件。另外, 框架和层次结构风格在不同的浏览器中也有不同的显示, 甚至根本不能显示。不同的浏览器对安全性和Java的设置也不一样。浏览器测试的一个方法是创建一个兼容性矩阵, 在该矩阵中, 测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。另外, 浏览器中许多设置也会影响Web系统功能, 例如缓存设置、Cookies设置、显示设置、安全设置等, 还需要测试浏览器不同设置是否影响Web系统的功能。
3 结语
Web应用软件的测试同传统软件的测试一样, 测试工作应贯穿其设计和开发的整个过程, 就Web应用软件的系统测试进行研究, 讨论了针对网页和网站展开的各项测试。但对于Web应用软件测试用例的设计和自动化测试还需进一步研究。
参考文献
[1]郭玉环, 高建华.Web应用程序的动态测试生成方法.计算机工程与设计, 2013, 34 (3) :930-934.
[2]柳纯录.软件评测师教程.北京:清华大学出版社, 2010.