第二篇：linux系统Jmeter性能测试笔记

jmeter性能

jmeter P函数应用

${__P__(thread,200)}

${__P__(step，20)}

${__P__(steptime，30)}

${__P__(duration，30)}

${__P__(duration，300)}

jmeter  -n -t  待执行的性能脚本.jmx  -l  结果文件（名字自己取）.jtl  -j  执行的log.log -e -o 路径/测试报告名  -Jthread=20  -Jstep=20 （参数不加则默认）

$ nvidia-smi 查看显存使用情况命令

$ watch -n 10 nvidia-smi 周期性地查看GPU使用情况 10 表示每10秒刷新一次GPU状态

vmstat interval count

      间隔时间  需要输出多少次结果

vmstat 2 10

      每隔两秒输出10次结果

top  ps（使用时间C列 time为进程持续时间）

CPU 占用率 = （进程 cpu时间/ 进程持续时间）

ps -ef -elf

ps -au -aux

%cpu %men

CPU 中央处理器 GPU图形处理器

GPU 是图形处理器，在测试手机/游戏性能会用到（模型性能也会用到），如果是测试web后台性能，应该不用

查看和杀死Jmeter进程

jps | grep ApacheJMeter | awk '{print $1}'

jps | grep ApacheJMeter | awk '{print $1}'|xargs kill -9

后台执行

nohup jmeter -n -t 执行的脚步.jmx -l 结果文档.jtl &  后台执行，即使关闭窗口后也执行

jmeter -n -t 执行的脚步.jmx -l 结果文档.jtl &后台执行，关闭窗口后不执行

linux下测试性能 不含事务控制器的情况下打印的信息：

其中主要有两种信息 summary + 和 summary = ，其它项都是类似的

summary +4386 in 00:00:30 ：在30秒内增加了4386个请求，其中时间间隔由配置文件中的interval统计频率的值决定

summary = 27455 in 00:03:12 ：在3分12秒内产生的总请求数是27455个，其中的时间段是从脚本运行开始计算到当前时间为止，一般在脚本运行过程中主要关注"summary="信息即可

146.2/s ：系统每秒处理的请求数，相当于TPS

Avg : 684 ：平均响应时间

Min:201 ：最小响应时间

Max:1499 ：最大应时间

Err : 0 (0.00%) ：错误数/率

Active :100 活动的线程数

当没有遇到性能瓶颈的时候：

F=VU * R /T

其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间

(一)各种技术应用的前提。对于在开源社区和一些开源项目中获得的测试工具，首先需要了解工具适用于哪些类型应用的测试，以及工具发布后的发布说明和FAQ。开源的工具通常不像商业工具那样成熟稳定，因此找出工具的适用范围以及探索工具的实现程度是进行自动化测试应用的前提。

(二)各种技术应用的环境需求。对于各类工具，需要关注编译和运行时对各种包和库及其版本的依赖关系以及对预先安装的应用的依赖关系。这些在用户手册中都有详尽的说明。

(三)服务器性能监视器。大部分测试工具没有提供服务器端的性能监控功能，测试工程师需要根据实际的需求编写性能监控脚本来配合工具的使用。

下面结合曾经参与进行过的Linux平台下的自动化测试的研究，面向不同类别的测试用例自动化的需求，将主要从功能测试，如GUI测试、命令行客户端的测试，以及性能测试等几个方面对Linux平台下的测试工作的自动化进行分析和说明。

GZW自动化洲试

对于GUI测试的自动化，通常的测试工具所使用的捕捉／回放技术有两种，一种是通过记录界面的鼠标事件(如点击、移动)和键盘事件来完成录制和回放，另外一种则是录制和回放都是基于控件的识别和 *** 作进行的，每个脚本的执行都是控件对象的属性改变或事件触发。我们从开源社区可以获得如上两种类型的运行于Linux平台之上的典型测试工具，如Knee和LDTP等。

(一)Xnee工具

在Linux *** 作系统的xll环境下，Xnee能够录制、回放和分发用户的动作。Xnee的捕捉／回放技术是记录鼠标事件和键盘事件。进入录制模式时，Xnee记录发送至和来自X server之间的协议数据拷贝，并生成Xneesession文件。在回放模式下，Xnee读取Xnee Session中的事件，模仿整个录制过程(即用户 *** 作过程)完成和x server之间的通讯，被录制的应用软件(Xclient)则接收来自xserver的消息，完成预设的动作。

(二)LDTP测试工具／框架

Linux Desktop Testing Project(LDTP)测试工具／框架能够基于用户在应用界面的选择进行脚本的录制。LDTPI具使用了Gnome环境下的Accessibility库即辅助选项库(at-spi)。使用辅助选项能够获得应用通过AT-SPI协议提供的关于用户界面的信息和界面控件的当前状态或者属性。LDTPI具／框架的体系结构如下：

AT-SPI的基础思想就是为用户界面的可视化元素提供对应的辅助对象，而录制完成的每个脚本的执行都是基于这些辅助对象进行的。对于希望利用LDTPI具进行测试的应用，需要激活辅助选项。

(三)GUI自动化测试工具的应用

在实际的GUI自动化测试中，LDTPI具应用的场景会更广泛一些。LDTPI具可以识别窗口中的对象(如按钮)，测试脚本使用LDTP的API接口，每个API接口对UI对象进行 *** 作存在两个最基本的入口，即窗口和对象，窗口通过窗口的类型和名称(即标题)识别，对象通过希望 *** 作的控件的类型和名称(标签或者关联的标签)识别。我们同样可以通过at-pokel具展现激活了辅助选项的应用程序窗口的对象及对象属性。在测试Linux桌面产品和服务器产品的过程中，使用LDTPI具可以测试任何启用辅助选项的Gnome应用，如Mozilla，OpenOffice.org、Evolution邮件客户端，Nautilus文件浏览器等等，此外还可以测试UI界面基于Swing的Java应用，以及KDE4.O上基于QT4.0的应用等等。

而Xneel具所针对的应用程序类型就没有特别的限制，对于一些简单的窗口验证测试和界面的稳定性测试等则比较有效。Xnee相对于基于控件方式捕获和回放的工具而言，不用担心存在控件不能被识别的问题。

从使用的情况来看，各个工具也都因为实现技术而存在一定的缺陷，如两个工具均不能插入验证点，从而不能实现用例级别的结果验证；LDTP对于界面的个别元素捕获不到以及不能对不支持辅助选项的应用进行测试等等；而Xneel具生成的脚本可编辑性差，同时由于录制生成的脚本中的事件和屏幕坐标相关，因此当出现窗口d出位置发生变化等问题时，就需要考虑回放时应该如何来处理这些变化。

在工作中有很多时候都在去测试一下服务器端口是否能连通是否正常的情况，下面小编与大家分享一下在linux环境下如何测试端口的连通性，分别测试tcp端口与udp端口，希望可以给大家带来帮助，谢谢。

1、这个需要linux服务器里边支持nc命令，如果还没有装的情况会显示如下

2、我们可以使用yum命令直接安装，我的是centos

6.5系统

3、如果不会用，直接打nc命令就会显示出它的使用方法

4、如果需要测试某个服务器的端口在能不能正常在外面访问，例如我测试一下

180.97.33.107

这个ip

的80

端口有没有开启可以使用命令：nc

-z

-w

1

180.97.33.107

80

5、可以看到默认是使用tcp进行测试的，如果要测试udp端口有没有开放的可以添加-u

一起使用。例如我测试一下202.96.128.86

这个ip的udp

53端口：nc

-u

-z

-w

1

202.96.128.86

53

6、上面可以看到成功的会显示相关的信息，但是如果测试到端口是不开放的或者被防火墙拦截的就不会返回相关的信息。

注意事项：本文是根据自己的实情来测试端口的连通性，厉害可以使用其测试下，但具体的ip

以及端口要根据自己的实际填写测试哦。

---