服务器端口测试.docx

资源描述

服务器端口测试.docx

《服务器端口测试.docx》由会员分享，可在线阅读，更多相关《服务器端口测试.docx（26页珍藏版）》请在冰豆网上搜索。

服务器端口测试.docx

服务器端口测试

实现思路

压力测试原理有两种，一种是连接测试，一种是负载测试

1.连接测试，就是多线程，不停的请求直到服务器死机或达到预期效果即可；

2.负载测试，就是一个线程的多步操作，每个线程占用服务器cpu内存是否符合节能高效的标准，如果不是，那就优化吧。

所有测试以额定用户（最大用户）为基础

这里我选用第一种连接测试。

相关知识

SOAP

简单对象访问协议（SOAP，全写为SimpleObjectAccessProtocol）是交换数据的一种协议规范，使用在计算机网络Web服务（webservice）中，交换带结构信息。

SOAP为了简化网页服务器（WebServer）从XML数据库中提取数据时，节省去格式化页面时间，以及不同应用程序之间按照HTTP通信协议，遵从XML格式执行资料互换，使其抽象于语言实现、平台和硬件。

这里之所以说是简单，是因为它是基于已经广泛使用的两个协议：

HTTP和XML，所以业界把这种技术称为“它是第一个没有发明任何新技术的技术”，之所以说是对象，是因为把访问的Web服务称为对象，既然服务是对象，那么服务肯定有相关的属性和调用行为，这些属性和行为是通过WSDL来描述的。

如果按“简单的对象访问协议”来理解，相比“简单对象访问协议”要容易些。

SOAP包括四个部分：

SOAP 封装：

它定义了一个框架 ,该框架描述了消息中的内容是什么，谁应当处理它以及它是可选的还是必须的。

SOAP编码规则：

它定义了一种序列化的机制，用于交换应用程序所定义的数据类型的实例。

SOAPRPC表示：

它定义了用于表示远程过程调用和应答的协定。

SOAP绑定：

定义了一种使用底层传输协议来完成在节点间交换SOAP封装的约定。

SOAP消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求/应答的模式。

所有的SOAP消息都使用XML编码。

一条SOAP消息就是一个包含有一个必须的SOAP的封装包，一个可选的SOAP标头和一个必须的SOAP体块的XML文档。

SOAP消息

一条SOAP消息就是一个普通的XML文档，包含下列元素：

1.必需的Envelope元素，可把此XML文档标识为一条SOAP消息

2.可选的Header元素，包含头部信息

可选的SOAPHeader元素可包含有关SOAP消息的应用程序专用信息（比如认证、支付等）。

如果Header元素被提供，则它必须是Envelope元素的第一个子元素。

3.必需的Body元素，包含所有的调用和响应信息

必需的SOAPBody元素可包含打算传送到消息最终端点的实际SOAP消息。

4.可选的Fault元素，提供有关在处理此消息所发生错误的信息

可选的SOAPFault元素用于指示错误消息。

如果已提供了Fault元素，则它必须是Body元素的子元素。

在一条SOAP消息中，Fault元素只能出现一次。

这里是一些重要的语法规则：

1.SOAP消息必须用XML来编码

2.SOAP消息必须使用SOAPEnvelope命名空间

3.SOAP消息必须使用SOAPEncoding命名空间

4.SOAP消息不能包含DTD引用

5.SOAP消息不能包含XML处理指令

SOAP消息实例

请求

xmlversion="1.0"?

Envelope

xmlns:

soap="http:

//www.w3.org/2001/12/soap-envelope"

soap:

encodingStyle="http:

//www.w3.org/2001/12/soap-encoding">

Header>

...

Header>

Body>

...

Fault>

...

Fault>

Body>

Envelope>

回应

Envelope

xmlns:

soapenv="http:

//schemas.xmlsoap.org/soap/envelope/"

xmlns:

wsa="http:

//schemas.xmlsoap.org/ws/2004/08/addressing">

Header>

ReplyTo>

Address>http:

//schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous

Address>

ReplyTo>

From>

Address>http:

//localhost:

8080/axis2/services/MyService

Address>

From>

MessageID>ECE5B3F187F29D28BC11433905662036

MessageID>

Header>

Body>

echoxmlns:

req="http:

//localhost:

8080/axis2/services/MyService/">

category>classifieds

category>

echo>

Body>

Envelope>

XML-RPC

XML-RPC的全称是XMLRemoteProcedureCall，即XML远程方法调用。

它是一套允许运行在不同操作系统、不同环境的程序实现基于Internet过程调用的规范和一系列的实现。

这种远程过程调用使用http作为传输协议，XML作为传送信息的编码格式。

Xml-Rpc的定义尽可能的保持了简单，但同时能够传送、处理、返回复杂的数据结构。

XML-RPC是工作在Internet上的远程过程调用协议。

一个XML-RPC消息就是一个请求体为xml的http-post请求，被调用的方法在服务器端执行并将执行结果以xml格式编码后返回。

区别

web服务有两个主要的专用术语即soap和xml-rpc。

虽然它们都是可以执行rpc，但是SOAP是面向对象和有状态的，而xml-rpc则是面向过程和无状态的。

也就是说，soapweb服务可以由几个对象组成，每个对象都处理该用户的rpc调用，允许对象在请求服务之间存储用户的信息。

另一方面，xml-rpc服务处理所有独立的请求，而且在两次请求之间不存储信息。

xml-rpc应用程序的示例之一就是专用数据库的只读web服务接口。

由于该应用程序中不需要事务处理，xml-rpc的局限是互不相关。

测试工具

这里主要使用两种测试工具

1.JMeter

这里之所以选择使用JMeter，是因为这个软件一个开源软件，提供丰富的API。

2.soapUI

soapUI用于生成JMeter测试时所需的Soap/XML-RPCData

JMeter

什么是JMeter

ApacheJMeter是Apache组织开发的基于Java的压力测试工具。

用于对软件做压力测试，它最初被设计用于Web应用测试但后来扩展到其他测试领域。

它可以用于测试静态和动态资源例如静态文件、Java 小服务程序、CGI 脚本、Java对象、数据库，FTP服务器,等等。

JMeter可以用于对服务器、网络或对象模拟巨大的负载，来在不同压力类别下测试它们的强度和分析整体性能。

另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。

为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。

ApacheJMeter可以用于对静态的和动态的资源（文件，Servlet，Perl脚本，java对象，数据库和查询，FTP服务器等等）的性能进行测试。

它可以用于对服务器，网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。

你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。

JMeter的作用

1.能够对HTTP和FTP服务器进行压力和性能测试，也可以对任何数据库进行同样的测试（通过JDBC）。

2.完全的可移植性和100%纯java。

3.完全Swing和轻量组件支持（预编译的JAR使用javax.swing.*）包。

4.完全多线程框架允许通过多个线程并发取样和通过单独的线程组对不同的功能同时取样。

5.精心的GUI设计允许快速操作和更精确的计时。

6.缓存和离线分析/回放测试结果。

JMeter的高可扩展性

1.可链接的取样器允许无限制的测试能力。

2.各种负载统计表和可链接的计时器可供选择。

3.数据分析和可视化插件提供了很好的可扩展性以及个性化。

4.具有提供动态输入到测试的功能（包括Javascrīpt）。

5.支持脚本变成的取样器（在1.9.2及以上版本支持BeanShell）。

在设计阶段，JMeter能够充当HTTPPROXY（代理）来记录IE/NETSCAPE的HTTP请求，也可以记录apache等WebServer的log文件来重现HTTP流量。

当这些HTTP客户端请求被记录以后，测试运行时可以方便的设置重复次数和并发度（线程数）来产生巨大的流量。

JMeter还提供可视化组件以及报表工具把量服务器在不同压力下的性能展现出来。

相比其他HTTP测试工具,JMeter最主要的特点在于扩展性强。

JMeter能够自动扫描其lib/ext子目录下.jar文件中的插件，并且将其装载到内存，让用户通过不同的菜单调用。

JMeter主要组件介绍

1.测试计划（TestPlan）是使用JMeter进行测试的起点，它是其它JMeter测试元件的容器。

2.线程组（ThreadGroup）代表一定数量的并发用户，它可以用来模拟并发用户发送请求。

3.取样器（sampler）定义实际的请求内容，被线程组包含，我们主要用HTTP请求。

4.监听器（Listener）

5.逻辑控制器（LogicController）

6.断言（Assertions）

7.配置元件（ConfigElement）

8.前置处理器（PreProcessors）和后置处理器（PostProcessors）

9.定时器（Timer）

测试计划

测试计划（TestPlan）是使用JMeter进行测试的起点，它是其它JMeter测试元件的容器。

名称：

你可以为你的测试计划取一个有意义的名字。

注释：

对测试计划的注释。

用户定义的变量：

用户可以自己定义变量，在用到此变量的时候直接用${变量名}引用即可。

例：

变量名＝url，值＝，在需要时直接用${url}即可。

Adddirectoryorjartoclasspath：

向类路径即%JMETER-HOME%\lib中添加目录及jar包。

线程组

线程组是任何测试计划的起点，所有的逻辑控制器和采样器都必须放在线程组之下。

其他的测试元件（如监听器）可以被直接放在测试计划之下，这些测试元件对所有线程组都生效。

线程组就像它的名字所描述的那样，被用来管理执行性能测试所需的JMeter线程。

用户通过线程组的控制面板可以：

设置线程数量。

设置线程启动周期。

设置执行测试脚本的循环次数。

每一个JMeter线程都会完整地执行测试计划，而且它们之间是完全独立运行的。

这种多线程机制被用来模拟服务器应用的并发连接。

参数Ramp-UpPeriod告诉JMeter达到最大线程数需要多长时间。

假定共有10个线程，Ramp-UpPeriod为100秒，那么JMeter就会在100秒内启动所有10个线程，并让它们运转起来。

每一个测试线程都会在上一个线程启动10秒之后才开始运行。

假定共有30个线程，Ramp-UpPeriod为120秒，那么线程启动的间隔就为4秒。

Ramp-Up参数不能设定得太短，否则在测试的初始阶段会给予服务器过大的压力。

Ramp-Up参数也不能设定得太长，否则就会发生第一个线程已经执行完毕，而最后一个线程还没有启动的情况（除非测试人员期望这种特殊情况发生）。

如何找到一个合适的Ramp-Up参数值？

作者建议初始值可以设定为Ramp-Up=总线程数，后续再根据实际情况适当增减。

默认情况下，JMeter线程组被设定成只执行一遍，用户可以根据实际需要设定参数“循环次数”。

用户可以选中“调度器”选项，以便展开额外的调度器控制面板，如图3-5所示。

在调度器控制面板中，可以设定测试运行的“启动时间”和“结束时间”。

测试启动后会一直等待，直到用户设定的启动时间。

测试运行期间，JMeter会在每一次循环结束后，检查是否已经达到结束时间。

如果已经达到了结束时间，JMeter就会终止测试运行，否则JMeter会继续下一个测试循环。

另外，用户还可以设定“持续时间”和“启动延迟”两项参数。

需要注意的是，“启动延迟”会使“启动时间”无效，而“持续时间”会使“结束时间”无效。

定时器

默认情况下，JMeter线程在发送请求之间没有间歇。

建议为线程组添加某种定时器，以便设定请求之间应该间隔多长时间。

如果测试人员不设定这种延迟，JMeter可能会在短时间内产生大量访问请求，导致服务器被大量请求所淹没。

定时器会让作用域内的每一个采样器都在执行前等待一个固定时长。

如果测试人员为线程组添加了多个定时器，那么JMeter会将这些定时器的时长叠加起来，共同影响作用域范围内的采样器。

定时器可以作为采样器或者逻辑控制器的子项，目的是只影响作用域内的采样器。

要在测试计划中的某个位置添加暂停，测试人员可以使用“TestAction”采样器。

采样器——WebService（SOAP）Request

我们需要对发送到服务器的SOAP请求参数进行设置。

如果指向WSDL文件的链接（URL）可用，将该链接粘贴到WSDLURL字段并单击LoadWSDL。

可用的方法将显示在WebMethods组合框中。

接下来，需要单击Configure以便填充ServerName或IP、PortNumber、Path和SOAPAction。

监听器

样本数目：

运行时得到的取样器响应结果个数。