今天需要用fiddler抓iphone上安装的app包，ios 12.3.1 电脑端用的360浏览器，手机端用的safari 具体步骤如下 1、电脑连入wifi，记下电脑端的ip地址备用 2、手机与电脑连入同一个wifi，代理服务器IP填电脑IP，端口8888 3、打开fiddler，菜单栏依次点击Tools -->Options -->HTTPS 按下图操作，完成电脑端证书的安装 4、Tools -->Options -->Connections如下图设置，完成后重启fiddler。 5、iphone手机端用safari浏览器访问 http://192.168.100.66:8888， 点击连接下载证书到手机 6、手机设置 -->通用 -->描述文件与设备管理，安装证书 7、设置 -->通用 --> 关于本机 -->证书信任设置，打开开关 网上文章都没说到iphone需要打开这个开关才能抓到app中的https数据 否则抓包显示Tunnel to，无法获取数据，手机浏览器打开https网址报非私人连接 from:https://blog.csdn.net/dandanben/article/details/102703034
View Details一开始知道Airtest大概是在年初的时候，当时，看了一下官方的文档，大概是类似Sikuli的一个工具，主要用来做游戏自动化的，通过截图的方式用来解决游戏自动化测试的难题。最近，移动端测试的同事尝试用它的poco库来做自动化，看样子还不错，所以，这里推荐给各位同学。 官方网站 http://airtest.netease.com/ ### Airtest IDE 这是Airtest测试工具标配的IDE，目的是方便我们用于录制/编写自动化测试。 你可以使用账号登录或直接点击左下角“skip”按钮跳过。 启动Android模拟器或者用PC连接一台手机。通过adb命令检查移动设备。
|
1 2 3 |
> adb devices List of devices attached emulator-5554 device |
当我在Android模拟器中操作时，Airtest IDE右侧的界面是同步的，这一点比很多移动测试工具做的优秀，例如，appium desktop必须手动刷新才能获取最新的界面。 #### Airtest Airtest IDE支持Airtest脚本的录制，用法非常简单，你甚至可以先不用看它的API，通过录制来熟悉它的API。 右侧Airtest窗口以及API，点击右上角录制按钮，然后，就可以在映射的Android模拟器界面上点点点了。 以下是我点点点，生成的脚本。 过程非常简单，点击桌面上的计算器图标，打开编辑器输入1+1= ，然后，点击工具栏上的 “运行”按钮，就可以回放了。 这种脚本更适合游戏，因为游戏界面很难定位，图片识别（截图）的方式确实是不错的选择。 ###Poco Poco是另外一种形式的脚本，它与一般的自动化工具一样，通过元素本身的属性来定位元素，并且它同样支持录制。\ 点击右上角第一个的录制按钮。然后，继续在android映射的界面上点点点。 因为脚本里面没截图，我就单独拿出来了。
|
1 2 3 4 5 6 7 8 9 10 |
__author__ = "fnngj" from poco.drivers.android.uiautomation import AndroidUiautomationPoco poco = AndroidUiautomationPoco(use_airtest_input=True, screenshot_each_action=False) poco("计算器").click() poco("com.android.calculator2:id/digit_1").click() poco("com.android.calculator2:id/op_add").click() poco("com.android.calculator2:id/digit_1").click() poco("com.android.calculator2:id/eq").click() |
从poco的API来看比appium更为简洁。 如果你要做的是非游戏的APP的话，poco应该是我们后面学习的重点。这样的代码不管是和单元测试框架结合还是使用PO设计模式都是没有问题的。 而且，同样提供元素的属性展示，又有录制功能加持，在开发效率上应该会提高不少。 如果，你刚好又会Python，那么这将是一个不错的选择。 from:https://www.cnblogs.com/fnng/p/10247339.html
View Details简单来说就是，多台机器同时安装jmeter，选择一台机器作为调度机，其他作为压力机。进行相应的配置后，就可以用调度机操控压力机发起请求。 分布式执行原理 负载机配置 安装JAVA 下载并解压JDK
|
1 2 3 4 |
mkdir /usr/lib/jvm/ cd /usr/lib/jvm/ tar -zxvf jdk1.8.0_121.tar.gz |
配置jdk的环境变量
|
1 2 3 4 5 6 7 |
#vi /etc/profile export JAVA_HOME=/usr/lib/jvm/jdk1.8.0_121 export JRE_HOME=/usr/lib/jvm/jdk1.8.0_121/jre export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib export PATH=$PATH:$JAVA_HOME/bin |
再执行source /etc/profile刷新配置文件 通过java -version查看是否设置成功 安装Jmeter 下载jmeter.tgz文件，并将文件上传至/data/
|
1 2 3 4 5 6 7 8 9 |
#将jmeter文件解压,并将解压后的文件拷贝至指定路径/data/ tar xvf apache-jmeter-4.0.tgz 配置jmeter的环境变量，将下述内容复制粘贴 #vi /etc/profile export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib/rt.jar:$JMETER_HOME/lib/ext/ApacheJMeter_core.jar:$JMETER_HOME/lib/jorphan.jar:$JMETER_HOME/lib/logkit-2.0.jar: export PATH=$PATH:$JAVA_HOME/bin:$JMETER_HOME/bin: export JMETER_HOME=/data/apache-jmeter-4.0 |
再执行source /etc/profile刷新配置文件 通过jmeter -v查看是否设置成功 在jmeter目录创建testplan testresult子目录 , 将测试脚本login.jmx上传至testplan，进入bin文件下执行测试输出测试结果命令
|
1 2 3 |
cd /data/apache-jmeter-4.0/bin jmeter -n -t ./testplan/login.jmx -l ./result/test.jtl -e -o ./testresult/ |
分布式配置 调度机Controller 在多台机器中按照上述步骤配置jmeter，选择其中一台为调度机，其他为执行机 在调度机上修改bin/jmeter.properties, 添加执行机的IP及端口 , 1099是默认的rmi通信端口
|
1 2 |
remote_hosts=192.168.174.130:1000,192.168.3.148:1888 |
案例中 , 192.168.174.130:1000即是执行机IP和端口号 取消server.rmi.ssl.disable=false的中注释并将false改为ture
|
1 2 3 4 5 6 |
# Remote Hosts - comma delimited remote_hosts=192.168.5.95:1099,192.168.5.103:1099 server.rmi.ssl.disable=true |
开启执行脚本机器上的server服务，bin/jmeter-server 在控制机执行分布式命令
|
1 2 3 4 5 6 |
#使用 -r 启动所有从机执行脚本 jmeter -n -t testplan/comic.jmx -r -l testResult/result1.jtl #指定从机IP jmeter -n -t testplan/comic.jmx -R 10.15.243.53,10.15.230.78 -l testResult/result1.jtl |
执行机Agent 修改jmeter.properties
|
1 2 3 4 |
server_port=1000 server.rmi.localport=1000 server.rmi.ssl.disable=true |
然后执行命令 , 启动服务
|
1 2 |
sudo jmeter-server -Djava.rmi.server.hostname=192.168.174.130 #从机自身IP |
遇到的问题及解决 An error occurred: Cannot start. localhost is a loopback address In latest version, you can run your script with:指定本地IP 解决方案:
|
1 2 |
sudo jmeter-server -Djava.rmi.server.hostname=192.168.174.130 #从机自身IP |
java.io.FileNotFoundException: rmi_keystore.jks 1、Jmeter4.0，启动slave报错java.io.FileNotFoundException: rmi_keystore.jks image 解决方法一：slave的jmeter.properties中，设置server.rmi.ssl.disable=true 原因：jmeter4.0以上的版本，默认启用RMI连接的安全通信，需要创建密钥库。所以将SSL禁用即可。 解决方法二：手动生成秘钥和证书。执行create-rmi-keystore.bat（Windows适用）或create-rmi-keystore.sh（Linux适用） Neither the JAVA_HOME nor the JRE_HOME environment variable is defined 在使用java远程启动linux服务器上的jmeter服务是报Neither […]
View Details|
1 2 3 4 5 6 7 8 9 10 |
吞吐率（Requests per second） 概念：服务器并发处理能力的量化描述，单位是reqs/s，指的是某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。 计算公式：总请求数 / 处理完成这些请求数所花费的时间，即 Request per second = Complete requests / Time taken for tests QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的常用量化指标，另外还有HPS（每秒HTTP请求数）。 跟吞吐量有关的几个重要是：并发数、响应时间。 QPS（TPS），并发数、响应时间它们三者之间的关系是： QPS（TPS）= 并发数/平均响应时间 对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。 对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。 这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时， 如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统， 如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。 |
|
1 2 |
并发连接数（The number of concurrent connections） 概念：某个时刻服务器所接受的请求数目，简单的讲，就是一个会话。 |
|
1 2 3 |
并发用户数（The number of concurrent users，Concurrency Level） 概念：要注意区分这个概念和并发连接数之间的区别，一个用户可能同时会产生多个会话，也即连接数。 并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。 一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。 这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。 相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。 |
|
1 2 3 |
用户平均请求等待时间（Time per request） 计算公式：处理完成所有请求数所花费的时间/ （总请求数 / 并发用户数），即 Time per request = Time taken for tests /（ Complete requests / Concurrency Level） |
|
1 2 3 4 5 |
服务器平均请求等待时间（Time per request: across all concurrent requests） 计算公式：处理完成所有请求数所花费的时间 / 总请求数，即 Time taken for / testsComplete requests 可以看到，它是吞吐率的倒数。 同时，它也=用户平均请求等待时间/并发用户数，即Time per request / Concurrency Level |
|
1 2 |
QPS每秒查询率(Query Per Second) 每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量） |
|
1 2 3 |
响应时间(RT) 响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同， 甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。 对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的， 响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。 |
安装ab测试工具
|
1 |
yum install httpd-tools -y |
ab工具帮助 ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
命令格式： ./ab [options] [http://]hostname[:port]/path 命令参数： -A：指定连接服务器的基本的认证凭据； -c：指定一次向服务器发出请求数； -C：添加cookie； -g：将测试结果输出为“gnuolot”文件； -h：显示帮助信息； -H：为请求追加一个额外的头； -i：使用“head”请求方式； -k：激活HTTP中的“keepAlive”特性； -n：指定测试会话使用的请求数； -p：指定包含数据的文件； -q：不显示进度百分比； -T：使用POST数据时，设置内容类型头； -v：设置详细模式等级； -w：以HTML表格方式打印结果； -x：以表格方式输出时，设置表格的属性； -X：使用指定的代理服务器发送请求； -y：以表格方式输出时，设置表格属性。 参数很多,一般我们用 -c表示并发数 -n 表示请求数即可 如果只用到一个Cookie，那么只需键入命令： ab －n 100 －C key＝value http://test.com/ 如果需要多个Cookie，就直接设Header： ab -n 100 -H “Cookie: Key1=Value1; Key2=Value2” http://test.com/ |
使用举例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
[root@c75 ~]# ab -n 1000 -c 1000 http://192.168.255.209/monitor This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 192.168.255.209 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: nginx/1.14.0 Server Hostname: 192.168.255.209 Server Port: 80 Document Path: /monitor Document Length: 185 bytes Concurrency Level: 1000 //并发请求数 Time taken for tests: 2.252 seconds //整个测试持续的时间 Complete requests: 1000 //完成的请求数 Failed requests: 0 //失败的请求数 Write errors: 0 //写入失败数 Non-2xx responses: 1000 //非2xx状态请求数 Total transferred: 386000 bytes //传输的总字节数大小 HTML transferred: 185000 bytes //传输的总文档字节数大小 Requests per second: 444.05 [#/sec] (mean) //每秒处理的请求数 Time per request: 2252.008 [ms] (mean) //每个请求花费的平均时间 Time per request: 2.252 [ms] (mean, across all concurrent requests) Transfer rate: 167.39 [Kbytes/sec] received //转移率 Connection Times (ms) min mean[+/-sd] median max Connect: 6 40 14.2 36 69 //创建TCP连接到服务器或者代理服务器所花费的时间 Processing: 40 738 722.9 302 2138 //写入缓冲区消耗+链路消耗+服务端消耗 Waiting: 11 546 595.8 293 1930 //写入缓冲区消耗+链路消耗+服务端消耗+读取数据消耗 Total: 45 778 733.0 344 2207 //总花费时间 Percentage of the requests served within a certain time (ms) 50% 344 66% 752 75% 1668 80% 1799 90% 1957 95% 2073 98% 2161 99% 2191 100% 2207 (longest request) |
from:https://www.e-learn.cn/content/linux/1134148
View Details写在前面 在学习ab工具之前，我们需了解几个关于压力测试的概念 吞吐率（Requests per second） 概念：服务器并发处理能力的量化描述，单位是reqs/s，指的是某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。 计算公式：总请求数 / 处理完成这些请求数所花费的时间，即 Request per second = Complete requests / Time taken for tests 并发连接数（The number of concurrent connections） 概念：某个时刻服务器所接受的请求数目，简单的讲，就是一个会话。 并发用户数（The number of concurrent users，Concurrency Level） 概念：要注意区分这个概念和并发连接数之间的区别，一个用户可能同时会产生多个会话，也即连接数。 用户平均请求等待时间（Time per request） 计算公式：处理完成所有请求数所花费的时间/ （总请求数 / 并发用户数），即 Time per request = Time taken for tests /（ Complete requests / Concurrency Level） 服务器平均请求等待时间（Time per request: across all concurrent requests） 计算公式：处理完成所有请求数所花费的时间 / 总请求数，即 Time taken for / testsComplete requests 可以看到，它是吞吐率的倒数。 同时，它也=用户平均请求等待时间/并发用户数，即 Time per request / Concurrency Level ab工具简介 ab全称为：apache bench 在官网上的解释如下： ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求。 其他网站解释： ab是apache自带的压力测试工具。ab非常实用，它不仅可以对apache服务器进行网站访问压力测试，也可以对或其它类型的服务器进行压力测试。比如nginx、tomcat、IIS等。 下载ab工具 进入apache官网 http://httpd.apache.org/ 下载apache即可 启动ab工具 […]
View DetailsSelenium 是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE（7, 8, 9, 10, 11），Mozilla Firefox，Safari，Google Chrome，Opera等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建回归测试检验软件功能和用户需求。支持自动录制动作和自动生成 .Net、Java、Perl等不同语言的测试脚本。 from:https://baike.baidu.com/item/selenium/18266
View Detailsjmeter是apache公司基于java开发的一款开源压力测试工具，体积小，功能全，使用方便，是一个比较轻量级的测试工具，使用起来非常简单。因为jmeter是java开发的，所以运行的时候必须先要安装jdk才可以。jmeter是免安装的，拿到安装包之后直接解压就可以使用，同时它在linux/windows/macos上都可以使用。 jmeter可以做接口测试和压力测试。其中接口测试的简单操作包括做http脚本（发get/post请求、加cookie、加header、加权限认证、上传文件）、做webservice脚本、参数化、断言、关联（正则表达式提取器和处理json-json path extractor）和jmeter操作数据库等等。 接口测试 Jmeter-http接口脚本 一般分五个步骤:（1）添加线程组 （2）添加http请求 （3）在http请求中写入接入url、路径、请求方式和参数 （4）添加查看结果树 （5）调用接口、查看返回值 jmeter 发get请求 jmeter 发post请求 jmeter 添加cookie 需要在线程组里添加配置元件—HTTP Cookie 管理器 jmeter 添加header 需要在线程组里面添加配置元件—HTTP信息头管理器 jmeter 上传文件 jmeter 参数化 入参经常变化的话，则可以设置成一个变量，方便统一修改管理；如果入参要求随机或可多种选择，则通过函数生成器或者读取文件形成一个变量。所以参数化有三种方式：用户定义的变量、函数生成器、读取文件。 （1）用户定义的变量 需要添加配置元件-用户定义的变量。 （2）函数生成器 需要用到函数助手功能，可以调用函数生成一些有规则的数据。常用的几个函数有_uuid、_random、_time。_uuid会生成一个随机唯一的id，比如在避免java请求重发造成未处理数据太多的情况，接口请求可加一个唯一的请求id唯一的响应id进行一一对应；随机数_random，可以在你指定的一个范围里取随机值；取当前时间_time，一些时间类的入参可以使用,如{__time(,)} 是生成精确到毫秒的时间戳、{__time(/1000,)}是生成精确到秒的时间戳、${__time(yyyy-MM-dd HH:mm:ss,)} 是生成精确到秒的当前时间。 （3）从文件读取 需要在线程组里面添加配置元件-CSV Data Set Config 其中Recycle on EOF:设置True后，允许循环取值 具体的例子如下所示： jmeter 断言 jmeter断言用来检测响应返回的结果和我们预期的是否一致。若针对整个线程组的话，则在线程组下添加断言-响应断言；若只是针对某个请求的话，则在请求下添加断言-响应断言。 jmeter关联 接口请求之间存在参数调用，为了保存这个参数，建立jmeter关联。比如登陆接口和购买商品接口，购买商品接口就需要登陆接口返回的token等登陆信息，jmeter关联就可以保存这个token信息，方便购买商品接口使用。 jmeter关联可以通过二种方式来完成，获取到返回结果中指定的值。它们分别是正则表达式提取器、 json path extractor。 （1）正则表达式提取器 若想获取的返回值未匹配到，可以把正则表达式两边匹配的数据扩大点。 a. 关于正则表达式 ()：括起来的部分就是要提取的。 .：匹配除换行外的任何字符串。 +：代表+号前面的字符必须至少出现一次（一次或多次）。 ?：代表？前面的字符最多可以出现一次，在找到第一个匹配项后停止（0次或1次）。 ：代表号前面的字符可以不出现，也可以出现一次或者多次（0次、1次或者多次） (.*)：贪婪模式，匹配尽可能多的字符 （.*?）或（.+?）：匹配尽可能少的字符，一旦匹配到第一个就不往下走了。 b. 关于模板 若想提取多个值的话，比如是a和b这两个值，则可以写成：$1$$2$。无论要提取多少个值，引用名称就是一个的，比如名称为id，${id_go}:获取整个字符串ab，${id_g1}：获取的是a，${id_g2}：获取的是b。 下面有一个具体的实例，如下图所示： （2）json path extractor jmeter通过安装json path extractor插件来处理json串，提取json串中的字段值。插件的下载地址：https://jmeter-plugins.org/?search=jpgc-json，下载完成，解压后，直接把lib文件夹放到jmeter相应目录下面。特别说明：jmeter 2.xx左右的版本尝试过无法使用该插件，在jmeter 3.xx左右的版本装完插件后能正常使用。 需要在请求下创建后置处理器-jp@gc-JSON Path Extractor，具体的实例如下所示： 关于json path相关插件的方法和使用，推荐可以看这篇博客： http://www.jianshu.com/p/56a607fc0d8f jmeter 操作数据库 操作数据库基本有四个步骤：（1）导入mysql的jdbc的jar包 （2）创建数据库的连接配置，线程组里添加配置元件-JDBC Connection Configuration （3）线程组里添加jdbc […]
View Details前言：很多人都想学习压力测试，但是一开始手动写脚本着实蛋疼，所以今天我教大家的是利用badboy来录制压测脚本，然后用Jmeter来做压力测试。 流程：badboy导出Jmeter压测脚本->Jmeter进行压力测试（特别适用于本次潘sir大作业–电影售票系统web版本的压力测试） 第一步：下载badboy和Jmeter badboy：http://www.badboy.com.au/ Jmeter：http://jmeter.apache.org/ 安装特别简单，笔者罗炜劲也没遇到什么困难。这里就不赘述了，真的没坑的，也不需要配置什么。可能唯一需要注意的是Jmeter的运行，需要打开bin目录下的批处理文件：看下面截图。 会首先出现一个命令行，然后出现以下图形化界面 第二步，用badboy录制脚本并导出.jmx格式 笔者这里随便拿某讯的网站来示范，当然，人家的机制肯定是会防止别人ddos攻击，所以频繁发出请求的话，肯定是会返回拒绝访问的结果，但是我们不关注返回结果，我么关注录制和压测的流程。 首先在地址栏输入要压测的地址然后跳转 这时候badboy左侧脚本已经录制一条了，可以看到页面已经跳转到了QQ邮箱，并且script多了一条记录 然后输入账号密码，点击登录，页面跳转，同时脚本多一个步骤 然后我就退出了QQ邮箱。并且，脚本多了一行 录制完成之后，点击左上角的导出jmeter，保存脚本到指定目录。 第三步：Jmeter出场 首先打开刚刚从badboy哪里保存的脚本 可以看到测试计划多了一个，然后线程组就是定义并发数目，step就是压测的步骤，意思就是比如1000个并发，就会模拟1000个人，不断重复刚刚我录制的操作，登录邮箱，退出邮箱这样。 双击Thread Group线程组，就可以定义线程数，循环次数，随机间隔时间。想做压力测试，当然线程数越多压力越大，间隔越小越大。 第四步：压测步骤已经写好，是不是可以直接运行呢？我们还需要添加监听器！来查看压测返回的结果啊！ 监听器的种类好多，可以全部加进去试试，各有各的看点！我加了三个监听器： 最后，运行！查看结果 查看结果树 表格查看 聚合报告：我喜欢看这个，可以看出错误率，最大吞吐量。可以反映出服务器性能。 小结：希望大家有所收获。
View Details一、运行Jmeter （1） 去官方网站下载jmeter(版本为3.3)并解压。点击bin/jmeter.bat启动jmeter （2） 新建线程组。 （3） 在线程组中新建WebSocket Sample 二、WebSocket Sampler简介 1、WebServer （1）Server Name or IP：WebSocket发送的目标服务器的地址或者名称 （2）Port Number：WebSocker服务器监听的端口号。（一般是HTTP 80端口，可以通过WireShark数据包得到） 2、Timeout: （1）Connection – 发送一个连接请求后，Jmeter等待连接完成的最长时间，单位是毫秒。 （2）Response – 对响应消息的最大等待时间。 3、WebSocket Request （1）Implementation – 只支持RFC6455(v13) ，WebSocket协议标准的最新版。 （2）Protocol – 有ws与wss之分， ws前缀是WebSocket连接的辨别标识，wss前缀是WebSocket安全连接的辨别标识。根据自己的实际情况填写 （3）Streaming Connection – 选择这个TCP session要不要保持，如果勾上标识连接会一直存在，如果没有勾上，那么得到第一次响应后该链接就会被关闭。 （4）Request data：填入将要发送的请求，要跟开发沟通好，这个是什么格式的消息。 4.WebSocket Response （1）Response Pattern – 采样器将等待含有该标识的消息并继续通信（或者直到timeout，该连接关闭） （2）Close Connection Pattern – 如果服务器返回的消息含有这样的字符，就结束会话。 （3）Message Backlog – 定义服务器返回消息保留的最大长度。 三、试验 按照网上的例子，可以用http://www.websocket.org/echo.html这个网站做一些试验，网站会将收到的数据（你的request数据）在服务器响应中原样返回。 将网站提供的host等信息填入即可与网站通信，下面是我的实验，用于理解Jmeter中websocket sampler 1、streaming选项的影响 （1）不勾选streaming test plan设置如下： 不勾选streaming connection结果如下： 可以看出发送的Ground control to Major Tom被返回，这个实验是成功的，从result tree的sampler result中Execution FLow中可以看出测试的结果与上面我们的设置之间的关系：用了5000毫秒的时间等待服务器的连接，用了20000毫秒的时间等待服务器的消息，且在接受到第一条消息后，关闭了这个websocket会话。 （2）勾上streaming connection 可以看到在结束测试的时候，勾上streaming那个小勾后，测试结束时streaming connection还是开着的。 （3）发送两条消息 只发送一条消息可能看不出什么区别，将Websocket sampler复制一下，发送两条信息。这样就可以看出第二条消息发送时是直接用的第一条消息打开的连接，服务器的响应被归类到一次会话的响应窗口。 （4）、参照参考文档设置一个测试（添加一个loop controller，设置循环次数为3） 结果如下： 循环中的sampler都勾选了streaming，最后一个sampler没有勾选此选项，结果中可以看出：在loop […]
View Details