Jmeter发送SOAP请求对WebService接口压力测试

1 建立WebServiceTest Plan

1) 添加ThreadGroup

右键单击Test Plan选择Add --> ThreadGroup，配置

Number of Threads、Ramp-UpPeriod、Loop Count可随测试不同随时修改。

三种参数解释如下：

Number of Threads为发起线程总数。

Ramp-Up Period 指定了JMeter开启Number ofThreads个线程所需的时间。例如，如果待发起30个线程（即模拟用户），Ram-Up Period为15秒，则每秒增加2个线程（30个用户/15秒）。如果设置为0，则JMeter会自动启动所有模拟用户。

Loop Count为循环次数。

2 添加 WebService Requests

右键单击“WebService线程组”，Add --> Sampler --> WebService(SOAP)。

注：灰色“线程组”为其它测试使用过的线程组，此处这设置为Disabled线程组，在本次测试中不使用。

配置

将发布好的Service的 WSDL URL粘贴到WSDL URL中点击Load WSDL之后，WebMthods自动弹出，

只需自己选择Method然后单击Configure即可完成绝大部分自动配置

但是里面会涉及Soap/XML-RPC Data的编写，我编写的如下：

[plain] view plain copy

<xml version="10" encoding="utf-8">

不能，只能进行接口测试，接口返回时间倒是可以看到的

Postman接口测试

http://jingyanbaiducom/article/5552ef47f279ba518ffbc9c3html

主要内容：

http://jmeterapacheorg/download_jmetercgi

用来统一管理待测试的服务器地址和端口

这里将测试服务器地址设置为 http://127001:9999

这里的线程组来模拟登录使用只需要执行一次即可，所以单独用一个线程组。

在这个线程组下新建 HTTP请求来模拟登录

我这里登录是用的JSON格式，所以下面设置登录请求头为Content-Type:application/json

测试是否登录成功，新建 查看结果树

运行测试计划

可以看到登录已经成果返回了

1提取token

新建 JSON提取器

这里 $ 就是返回的JSON对象 $datatoken 就是获取token 然后赋值给 token 变量

2将token赋值全局变量

新建 Bean shell 后置处理程序

${__setProperty(Token,${token},)} 将token赋值给Token

类似于登录，我们新建一个线程组来测试业务接口

在线程组下有个HTTP信息头管理器，我们可以设置获取全局Token

${__P(Token,)} 获取Token

这样设置后线程组下面的所有业务接口都能复用第一次登录的token了。

前面我们已经获取到全局的Token现在只需要给线程组设置规则就好了

新建 聚合报告

运行，并查看报告

https://wwwjianshucom/p/e31b995d80e3

接口测试的目的是为了增加测试覆盖度、深入度 ，对接口的各个参数做实际场景中很难遇到的异常场景的测试，保证接口的稳定性。如果在这个前提下接口测试还是没有发现 bug，那么可以 review 下历次迭代中是不是业务测试发现的所有 bug 都是前端的。如果是，那么说明你们的后端开发工程师能力实在很强，应该恭喜你们遇到了这么给力的队友。在测试压力很大的情况下就可以酌情考虑不做接口测试，前端测试完成就上线了。

如果不是那就应该 review 你们的接口测试用例了。是不是用例设计的还不如业务测试全面？是不是用例设计的时候默认按照正常的取值范围？按照正常的业务逻辑进行的用例设计导致用例的覆盖还不如业务直接黑盒测出来的覆盖全。

自动化测试的主要目的不是发现多少 bug ，而是为了快速对接口做回归、做线上监控等，避免接口出现了低级问题、阻碍问题但是大家不能第一时间知道，等过了很长时间线上出了强反馈或者在错误接口的基础上又做了很多开发才被大家发现。当然，在接口自动化的基础上再做压力测试、稳定性测试等也会更方便。在这个前提下再评估接口自动化测试是否有必要，思路就会清楚一些。

整体上测试是为了保证业务中的 bug 能够在有限的资源下最大量、最快速的发现，业务实际情况不同、测试团队规模不同、测试与业务的合作模式、测试团队成员的技术能力等等都会影响测试方案的制定。

个人觉得如果团队有专人做接口测试，这种情况下接口测试定位到用来发现更多 bug 是没有问题的，如果没有发现 bug 那就需要仔细找找接口测试用例设计的问题。接口测试的目的不是取代业务测试，而是减少业务测试遇到阻碍问题的概率以及减轻业务测试模拟异常场景的工作量。接口自动化测试的目的是在回归场景节约业务测试的工作量，在新业务测试中实际反倒会占用更多的测试资源。

以上是作者拉拉肥对接口测试以及接口自动化测试的理解。你怎么看？欢迎点击 原文链接 在原帖共同讨论。

介绍个http_load压力测试工具,http_load，类似的工具还有webbench、ab、Siege。

1、下载

官方网站：http://acmecom/software/http_load/

复制代码

代码如下:

cd /root

wget http://acmecom/software/http_load/http_load-12mar2006targz

tar xzf http_load-12mar2006targz

2、安装

复制代码

代码如下:

cd http_load-12mar2006

make

执行完make,会在当前目录生成一个http_load二进制文件。

3、使用方法

复制代码

代码如下:

root@www:~/http_load-12mar2006# /http_load --help

usage: /http_load [-checksum] [-throttle] [-proxy host:port] [-verbose] [-timeout secs] [-sip sip_file]

-parallel N | -rate N [-jitter]

-fetches N | -seconds N

url_file

One start specifier, either -parallel or -rate, is required

One end specifier, either -fetches or -seconds, is required

主要参数说明:

-parallel 简写-p ：含义是并发的用户进程数。

-rate 简写-r ：含义是每秒的访问频率

-fetches 简写-f ：含义是总计的访问次数

-seconds简写-s ：含义是总计的访问时间

选择参数时，-parallel和-rate选其中一个，-fetches和-seconds选其中一个。

示例：

http_load -parallel 50 -s 10 urlstxt

这段命令行是同时使用50个进程，随机访问urlstxt中的网址列表，总共访问10秒。

http_load -rate 50 -f 5000 urlstxt

每秒请求50次，总共请求5000次停止。

4、基本的返回值

（1）．49 fetches, 2 max parallel, 289884 bytes, in 100148 seconds

说明在上面的测试中运行了49个请求，最大的并发进程数是2，总计传输的数据是289884bytes，运行的时间是100148秒

（2）．5916 mean bytes/connection

说明每一连接平均传输的数据量289884/49=5916

（3）．489274 fetches/sec, 289455 bytes/sec

说明每秒的响应请求为489274，每秒传递的数据为289455 bytes/sec

（4）．msecs/connect: 288932 mean, 44243 max, 24488 min

说明每连接的平均响应时间是288932 msecs，最大的响应时间44243 msecs，最小的响应时间24488 msecs

（5）．msecs/first-response: 635362 mean, 81624 max, 57803 min

（6）HTTP response codes: code 200 -- 49

说明打开响应页面的类型，如果403的类型过多，那可能要注意是否系统遇到了瓶颈。

特殊说明：这里，我们一般会关注到的指标是fetches/sec、msecs/connect

他们分别对应的常用性能指标参数Qpt-每秒响应用户数和response time，每连接响应用户时间。测试的结果主要也是看这两个值。当然仅有这两个指标并不能完成对性能的分析，我们还需要对服务器的cpu、men进行分析，才能得出结论

5、如果你需要测试https，你必须将 Makefile中

复制代码

代码如下:

# CONFIGURE: If you want to compile in support for https, uncomment these

# definitions You will need to have already built OpenSSL, available at

# <a href="http://wwwopensslorg/">http://wwwopensslorg/</a> Make sure the SSL_TREE definition points to the

# tree with your OpenSSL installation - depending on how you installed it,

# it may be in /usr/local instead of /usr/local/ssl

SSL_TREE = /usr

SSL_DEFS = -DUSE_SSL

SSL_INC = -I$(SSL_TREE)/include

SSL_LIBS = -L$(SSL_TREE)/lib -lssl -lcrypto

由于使用到openssl，你必须安装openssl和相应的开发环境

复制代码

代码如下:

apt-get install openssl

apt-get install libssl-dev</p> <p>find -name sslh

/usr/include/openssl/sslh

性能测试就是压力测试，手机方面的其实和PC方面的差距不大，重点就是大量手机调用接口对服务器的压力，所以测试的重点还是在服务器上，你可以用Jmeter模拟接口报文，来并发压服务器，看服务器的响应和处理能力。单个手机毕竟是一个人在用，所以一般不用关心手机端的问题。手机端主要的就是功能没什么问题，只要app玩着玩着不要崩溃掉就行了