1 协议概述
Modbus是一种串行通信协议，是Modicon公司(现在的施耐德电气 Schneider Electric)于1979年为使用可编程逻辑控制器(PLC)通信而发表。1996年施耐德公司推出基于以太网TCP/IP的Modbus协议：ModbusTCP。目前，modbus协议已经是工控网络中最常用的通信协议之一。
Modbus协议是一项应用层报文传输协议，包括ASCII、RTU、TCP三种报文类型。标准的Modbus协议物理层接口有RS232、RS422、RS485和以太网接口，采用master/slave方式通信。本文主要介绍基于以太网TCP/IP的ModbusTCP协议在实验室的测试方法。
2 ModbusTcp数据结构
ModbusTCP报文格式
从报文的格式中可以看出Modbus TCP是以太格式封装，上层Modbus ADU由三部分构成：Modbus应用协议头+功能码+数据，数据部分的内容和长度要根据具体的事务来定。
MBAP Header:
Modbus 应用协议头长度为7字节，含4部分。
事务处理标识符：用于区分事务对，可以理解为报文的序列号，每次通信之后就要加1以区别不同的通信数据报文。
协议标识符:对于Modbus协议为0
长度：长度域标识后续字节的个数。
单元标识符：标识不同的远端设备。
功能码及对应事件:
从列表中可以看出，功能码涉及到两大类，数据访问和诊断。在Modbus TCP中使用到的数据访问包含了线圈、离散量、输入寄存器、保持寄存器。
其中线圈和离散量的访问方式为按位访问，寄存器相关的为16位访问。
诊断中还会涉及到子功能码。
ModbusTcp的数据帧可以分为两部分MBAP+PDU，如图
MBAP为报文头，长度为7字节，结构如下：
PDU由功能码+数据组成。功能码长度为1字节，数据长度由具体功能决定。由于多数网络安全设备主要控制request方向的报文，这里只列举ModbusTcp协议request方向报文的PDU结构：
02 (0x02) Read Discrete Inputs
03 (0x03) Read Holding Registers
04 (0x04) Read Input Registers
05 (0x05) Write Single Coil
06 (0x06) Write Single Register
15 (0x0F) Write Multiple Coils
16 (0x10) Write Multiple registers
20 (0x14) Read File Record
21(0x15)写文件记录
22(0x16)Mask Write Register
23 (0x17) Read/Write Multiple registers
24 (0x18) Read FIFO Queue
43 ( 0x2B) Encapsulated Interface Transport
ModbusTcp常用测试工具及方法
3.1报文回放
实验室环境下，利用数据包回放工具将捕获的网络数据包按照测试人员的意愿回放到网络环境中，从而模拟真实的网络环境进行系统测试。
Windows环境
科来数据包播放器和数据包生成器是在Windows环境下回放和编辑数据包的常用工具。科来数据包播放器会把选取的数据包从指定的网卡发出，若选取的数据包为双向报文，则发出的也是双向报文，适用于测试旁路部署的网络安全设备对ModbusTcp协议的支持和解析能力。
测试组网：
科来数据包播放器操作页面及回放报文结果：
科来数据包生成器，可以直接编辑修改指定数据包内容，以及发送目标报文，比较适用于轻量级的数据包编辑。例如删除数据包三次握手信息、制造旁路设备中间流接入场景下首包为response方向报文的协议识别、篡改某些字节数据进行异常测试等，然后结合科来数据包播放器进行回放测试。
Linux环境
tomahawk是一款Linux环境下用于测试网桥型(串联部署)网络设备的工具。它通过分析截获的网络数据包文件，分辨出其中的Client和Server端，再通过指定的两个网卡发送出去。
tomahawk命令格式：
tomahawk [ -i interface1 ] [ -j interface2] [ -R rate ] [ -a startIpAddr ] [ -A (0|1) ] [ -t timeout ] [ -l loops ] [-f file ]
? -i interface1 从interface1网口发送client到server方向的包，必填参数；
? -j interface2 从interface2 网口发送 server到client方向的包，必填参数；
? -R rate 限制tomahawk发送测试网络速率, MB/秒, 这个数可以是浮动数, 比如100Kbps的流量，可以使用-R 0.1表示，选填参数；
? -a startIpAddress 当重写IP地址时, 可以从startIpAddress开始分配IP地址，选填参数；
? -A (0|1) 是否需要修改包中的IP地址标记，0为不修改，选填参数；
? -l loops 循环回放文件的次数，必填参数；
? -f file 要回放的数据包文件，必填参数；
操作举例:
将modbus.pcap通过tomahawk工具回放报文2次。
操作命令：./tomahawk -i p3p1 -j p3p2 -l 2 -f modbus.pcap
操作结果：
tomahawk工具在未配置 -A 和 -a 参数时，缺省配置下会修改回放报文中的IP地址，多次回放同一报文时IP地址会自动递增。图示组网方式可同时测试串联和旁路设备，适合于在已有固定报文的情况下测试网络安全产品基于不同的五元组对ModbusTcp报文的解析和处理能力，以及模拟测试网络安全设备在工业现场数千、数万条流中自动学习并生成白名单基线的完整性和准确性，大流量高速率下的协议解析和转发能力等。
功能和使用场景跟tomahawk工具类似的还有tcpreplay，tcpreplay是一系列工具的总称，包括tcpreplay、tcprewrite和tcpprep等工具，它也常用来在Unix系统或者linux系统上重放pcap格式的数据包；
1.tcpprep: 对pcap数据包进行预处理，区分pcap数据包的流向，即划分哪些包是client的，哪些包是server的，发包的时候client和server的数据包从不同的网卡发出；
2.tcprewrite：修改报文内容，主要修改2层，3层，4层报文头，即MAC地址，IP地址和port地址；
3.tcpreplay: 数据包发包工具，可以选择主网卡、从网卡、发包速度等；
仿真模拟
ModScan32工具
ModScan32是一个运行在windows下，抄作为在RTU或ASCII传输模式下的Modbus协议主设备的应用程序。把一个或多个Modbus从站设备通过网络连接到电脑上，就可以使用ModScan 读取和修改数据点。实验室模拟环境中，从站可以使用PLC或者ModSim。
测试组网：
modscan客户端界面：
界面元素及配置：
Address：起始地址；
Length：显示(读取)长度；
Device id：设备ID
Modbus Point Type：功能码类型，可选择01、02、03、04号功能码，读01功能码时写操作为05号功能码，读03号功能码时写操作为06号功能码；
Connection/connect/connect：选择连接方式；
Connection/connect/IP Address：远端从机的IP地址；
Connection/connect/rotocol Selection/Force modbus...：勾选之后，读01功能码时写操作为15号功能码，读03号功能码时写操作为16号功能码；
Setup/Display options/：选择显示的数据类型；
Setup/Display Definition：可设置读取速率(单位毫秒)以及modbus数据信息；
ModScan32可以用来测试网络安全设备对ModbusTcp的01-16号功能码的读写解析功能，包括五元组信息、功能码信息、起止地址、值域信息。
通过ModScan32工具向目标IP地址192.168.77.211模拟写16号功能码，地址15，数据类型Float单精度浮点数，点值1.0E11。(其他功能码操作基本相同)
步骤：
1.运行ModScan32程序，Address输入0001，Length输入100，Device id输入1，Modbus Point Type选择03功能码；
2.Connection/connect 页面中Connect 选择 Remote TCP/IP Server，IP Address 输入192.168.77.211，点击rotocol Selection弹出页面勾选Force modbus......，选择OK保存后会自动连接；
3.Setup/Display options/Floatin Pt 配置显示单精度浮点数，双击界面目标地址15可弹出写操作界面，Value中输入点值1.0E11点击update，即完成写操作。
操作界面如图：
wireshark抓包结果：
KEPServerEX客户端
ModScan32在测试ModbusTcp协议应用中，具有安装简单，配置快捷，操作方便等特点，但是对于浮点数的显示不够直观(数值较大时显示为???)，因此在实验室仿真测试过程中我们也可以借助于KEPServerEX软件进行ModbusTcp协议的测试。
环境安装：
KEPServerEX左侧树形表中右键添加新Channel并命名为modbus：
选择Device driver为Modbus TCP/IP Ethernet
之后默认“下一步”安装直到device driver添加完成(中间NetworkAdapter可默认也可选则指定的IP地址)。
树形表中选中modbus，右侧区域右键new device 添加device，命名为value
device model选择modbus
device id <>中的IP地址填写从机的IP，.后边填写从机的设备ID。
然后，默认“下一步”直到device添加完成。
左侧树形表中选中value，右侧区域右键new tag 添加tag(以写16号功能码，地址15，数据类型Float单精度浮点数，点值1.0E11为例，其他功能码操作基本相同)
Address可参考
添加完成后，可通过下图红圈中的快捷方式，启动OPC Quick Client进行读写操作。
如上图中显示，读取出来的value值1E+011非常直观，选中item右键即可进行读写操作。
数据包构造
前两节主要介绍通过报文回放和模拟软件对ModbusTcp的01-16号功能码进行读、写以及值域测试，本小节主要介绍使用Scapy进行16号之后功能码的数据包构造。Scapy是一个强大的，用Python编写的交互式数据包处理程序，它能让用户发送、嗅探、解析，以及伪造网络报文，从而用来侦测、扫描和向网络发动攻击。Scapy可以轻松地处理扫描(scanning)、路由跟踪(tracerouting)、探测(probing)、单元测试(unit tests)、攻击(attacks)和发现网络(network discorvery)之类的传统任务。
在scapy中可以通过ls()函数来查看scapy支持的网络协议，ls(IP())查看IP数据包参数，其他数据包同理，通过lsc()函数来查看scapy的指令集(函数)。常用的指令集(函数)包括arpcachepoison(用于arp欺骗)，arping(用于构造一个ARP的who-has包) ，send(用于发3层报文)，sendp(用于发2层报文), sr(发送+接收3层报文)，srp(发送+接收2层报文)，sniff(用于网络嗅探)等。下图截取部分指令集。
了解了报文的层次、每层的封装、scapy指令集、以及ModbusTcp的数据结构(参考第2章)，可以开始通过scapy进行ModbusTcp的报文构造。
注：
RandShort()函数会在1-65535的范围内随机生成一个TCP端口号。
scapy发送报文时可通过/将不同层次的报文拼接到一起，然后通过send()函数发送出去；
b‘x01x01...’可以把字符串进行转义
1.构造ModbusTcp协议20号功能码报文
报文构造命令：
>>>ModbusTcp20=IP(dst=’192.168.77.211’)/TCP(sport=RandShort(),dport=502)/b'x01x00x00x00x00x0ax01x14x07x06x00x01x00x00x00x00'
>>> send(ModbusTcp20)
抓包结果如图
2.构造ModbusTcp协议21号功能码报文
报文构造命令：
>>>ModbusTcp21=IP(dst=’192.168.77.211’)/TCP(sport=RandShort(),dport=502)/b'x01x00x00x00x00x0cx01x15x09x06x00x01x00x00x00x01x00x00'
>>> send(ModbusTcp21)
抓包结果如图：
3.构造ModbusTcp协议22号功能码报文
报文构造命令：
>>>ModbusTcp22=IP(dst=’192.168.77.211’)/TCP(sport=RandShort(),dport=502)/b'x01x00x00x00x00x08x01x16x00x00x00x00x00x00'
>>> send(ModbusTcp22)
抓包结果如图：
4.构造ModbusTcp协议23号功能码报文
报文构造命令：
>>>ModbusTcp23=IP(dst=’192.168.77.211’)/TCP(sport=RandShort(),dport=502) /b'x01x00x00x00x00x0dx01x17x00x00x00x01x00x00x00x01x02x00x00'
>>> send(ModbusTcp23)
抓包结果如图
5.构造ModbusTcp协议24号功能码报文
报文构造命令：
>>>ModbusTcp24=IP(dst=’192.168.77.211’)/TCP(sport=RandShort(),dport=502)/b'x01x00x00x00x00x04x01x18xffxff'
>>> send(ModbusTcp24)
抓包结果如图：
6.构造ModbusTcp协议43号功能码报文
报文构造命令：
>>>ModbusTcp43=IP(dst=’192.168.77.211’)/TCP(sport=RandShort(),dport=502)/b'x01x00x00x00x00x04x01x2bx0dx00'
>>> send(ModbusTcp43)
抓包结果如图：
除上述功能码外，还可以利用scapy构造各种违反ModbusTcp协议规约的报文来验证网络安全设备对违规报文的识别和检测能力。
数据：
数据部分可以先来看下面的Modbus TCP的事务通信模型，可以看到数据分为两种：客 户端的请求数据和服务端的响应数据。
知道了C/S的通信方式，再结合功能码表中的不同类型事务，下面就以功能码16(0x10)为例来说明“写多个寄存器”的客户端请求数据报文和服务器端的响应数据报文。
上面是“写多个寄存器”请求报文和响应报文的组成、字节数及数值范围，到此我们终于可以知道一种具体的Modbus TCP报文（请求/响应）长什么样了，而且还能给每个字段定义具体的数值。
更具体一点，现在我们可以给出“写10个寄存器”的客户端请求报文的Modbus ADU和服务器响应报文的Modbus ADU。
1）“写10个寄存器”客户端请求报文的Modbus ADU
36 33 00 00 00 1B 04 10 00 64 00 0A 14 00 0A 01 02 06 10 07 08 09 10 06 10 06 10 06 10 06 10 06 10
MBAP Header: 36 33 00 00 00 1B 04
PDU: 10 00 64 00 0A 14 00 0A 01 02 06 10 07 08 09 10 06 10 06 10 06 10 06 10 06 10
2）“写10个寄存器”服务器响应报文的Modbus ADU
36 33 00 00 00 06 04 10 00 64 00 0A
MBAP Header: 36 33 00 00 00 06 04
PDU: 10 00 64 00 0A
下图是“写多个寄存器”的报文处理逻辑图：
在详细了解了具体Modbus TCP协议后，我们现在已经可以确定某一种功能码的Modbus TCP报文格式及取值范围了，也就可以通过某种具体的方法去构建特定功能码的ModbusTCP报文和构建特定场景下的业务逻辑去验证防火墙的功能和行为了。
具体方法为借助python语言实现，按照TCP/IP协议分层模型去快速构建对应的Modbus TCP协议报文。形如Ether/IP/TCP/Raw
具体实现：
1) “写10个寄存器”的客户端请求报文
modbus_request=Ether/IP(src="100.100.100.100",dst="200.200.200.200")/TCP(dport=502)/Raw(load='x36x33x00x00x00x1Bx04x10x00x64x00x0Ax14x00x0Ax01x02x06x10x07x08x09x10x06x10x06x10x06x10x06x10x06x10')
sendp(modbus_request)
2) “写10个寄存器”的服务器端响应报文
modbus_response=Ether/IP(dst="100.100.100.100",src="200.200.200.200")/TCP(dport=502,flags=16)/Raw(load='x36x33x00x00x00x06x04x10x00x64x00x0A')
sendp(modbus_response)
注：需要自己解决网络的连通性及保证ARP报文解析的可达性.
以该功能码为基础进行场景构建，以下列出了大致涉及到的需要覆盖的场景:
协议本身场景构建
1.请求报文:
1)MBAP Header中事务处理标识符，包括范围内和超出范围的
2)MBAP Header中长度值，包括范围内和超出范围的。
3)MBAP Header中单元标识符，包括范围内和超出范围的。
4)功能码及数据
I)功能码：可识别的，不可识别的
II)起始地址：范围内的，超出范围的
III)寄存器数量：功能码16(0x10)"写多个寄存器".1-123个
IV)写入的寄存器值：在2*123的范围内
超出2*123的范围且小于256
超出2的8次方
2.响应报文:
1)MBAP Header中事务处理标识符，包括范围内和超出范围的;
2)MBAP Header中事务处理标识符，响应事务标识符与请求事务标识符不匹配;
3)MBAP Header中长度值，包括范围内和超出范围的。
4)MBAP Header中单元标识符，包括范围内和超出范围的。
5)MBAP Header中单元标识符，与请求端不一致。
6)功能码及数据
II)起始地址：范围内的，超出范围的
III)寄存器数量：功能码16(0x10)"写多个寄存器".1-123个
TCP/IP相关场景构建
0. vlan/双vlan场景
1.IP option
2.TCP option
3.IP Fragments
4.Modbus Fragments
5.TCP Segments
6.组播
7.IPv6
8. 多条流并发
9. 异常报文，两层modbus tcp封装
10. TCP 3次握手
11. 半打开
12. TCP 4次挥手
13. 半关闭
Fuzzing测试
针对某种场景，会有对单个字段值进行不同取值覆盖的需求，此时引入fuzzing测试的思想最为高效，即对python脚本进行修改，有针对性地控制报文长度及报文不同协议层中需要变换覆盖的字段值。
比如对协议报文的功能码字段，以及起始地址等去快速进行变换以验证防火墙的解析能力。
下面举例实现三个场景构造，其它场景就不详细列举了：
1.Modbus TCP报文分片
功能码16(0x10) “写多个寄存器”的客户端请求报文分片
Modbus ADU,即TCP负载为33个字节
36 33 00 00 00 1B 04 10 00 64 00 0A 14 00 0A 01 02 06 10 07 08 09 10 06 10 06 10 06 10 06 10 06 10
把负载分为3片，每片24字节。
构造报文完成后发出，使用wireshark抓包，此时发现重组后的报文chksum值报错，可以调整报文，手工修改成正确的chksum值再次发送即可。
2.Modbus TCP报文添加VLAN封装
双层VLAN封装
3.异常报文覆盖
例如双层Modbus封装（其余场景还有很多，不一一列举）
性能测试实践：
我们这里所说的性能测试不仅包括2-3层的性能，还包括客户现场具体使用的7层业务（如Modbus,Profinet,S7,IEC104等）的性能测试。涉及到的具体测试指标为吞吐、新建和并发。
业界对于性能测试的通用的、认可的做法是使用专业的硬件测试仪对网络设备进行测试，知名的测试仪厂商有思博伦 、IXIA。但是这两个厂商的设备价格都很昂贵，动辄几十万、上百万的价格对于一般的企业是很难负担的，即使是租用，一天几千块的费用，按整个项目周期核算，也是一笔不小的费用。
而公司全年的项目计划及各个项目的进度都是提前计划好的，特别是公司的重大战略项目，什么时间段开发，什么时间点转测试，什么时间点量产，什么时间点交付客户。如果我们没有从全局的视角去提前为之做准备，而是一味地按部就班按计划走，那么有很大的可能会在性能测试阶段碰到吞吐打不起来，或者即使打起来也与期望的指标相差甚远。这就会导致租用测试仪的金钱成本和整个项目的时间成本增加。
那么有没有一种方法 ，在不使用专业硬件测试仪的情况下先行对网络设备的性能进行摸底测试呢？测试的数据不一定非常精确，但是误差不大，这对实际工作具有重要意义,特别是在公司要研发的产品使用的是全新硬件平台的项目上。
注：本文所阐述的性能测试方法是指“使用硬件测试仪进行正式测试前的摸底测试的一种等价方法，而不是完全取代测试仪的方法”。意义在于可以避免项目实施过程中的进度风险和尽量减少租用仪器的金钱成本。
下面按照这一思路去找到可落地执行的具体方法，对工控网络设备的性能（本文讨论吞吐、新建和并发）进行摸底测试。以下内容是在实际工作中积累的经验、方法总结，供大家参考,涵盖以下性能测试内容：
工控网络设备2-3层性能测试_吞吐（接口）工控网络设备2-3层性能测试_吞吐（整机）工控网络设备7层性能测试_吞吐工控网络设备性能测试_新建及并发工控网络设备2-3层性能测试_吞吐（接口）
在落实具体的执行方法前，我们需要清楚测试仪的基本原理，其原理就是在双向两条流（通常取UDP协议）的条件下，测试仪发送端口发送的报文数与本端接收端口接收的报文数相等，即没有丢包，就达到了相应指标的吞吐。理解了这个基本原则，我们就可以具体执行了。
性能测试网络拓扑_透明模式
性能测试网络拓扑_路由模式
具体方法为（本文中的示例均以UDP 512 bytes为例）：
1.构造大量的UDP报文，包长为512字节。在发送前开启实体机（Windows操作系统）wireshark抓包，在发送过程中把构造的报文都抓取下来并保存为test1.pcap文件。这个操作可以利用我在《工控防火墙测试之功能测试》中介绍的报文构造方法，注意，在发送报文时，可以在脚本中使用 interval来指定发送报文的频率，即pps.在实际的工作实践中，PC机抓取200万数量级的报文并保存出来是没有问题的，当然，这取决于具体PC的硬件配置。工作中使用的笔记本配置为内存4G,CPU Intel(R) i5-4200 @1.60GHZ，供参考。2.把抓取的pcap文件使用tcpreplay进行回放，为了避免有突发流量对性能测试造成影响，要使用 -p 参数指定发送的pps。如：tcpreplay –i eth0 test1.pcap -p 50003.以上只是实现了一个方向的流量灌入，为了测试设备接口工作在全双工时的报文转发能力，还需要同时在对端有对等流量灌入。即重复上面的步骤1和步骤2的过程，然后在两台主机上同时回放报文如：tcpreplay –i eth0 test2.pcap–p 5000验证方法:
1.两台pc在使用tcpreplay回放完报文后，会显示如下信息：1)发送了总共多少个报文2)发送用时多少秒3)发送速率，包括Mbps, pps4)发送多少条流5)发送在哪个网卡6)发送结果是否成功。我们将两台发包机发送的报文数分别记为a1、a2,然后将a1、a2相加，计算出的值记为A。
2.在被测试设备上可以看到cpu总共处理了多少个报文,该数字记为B。如果是多核处理，会分别显示出每个核处理了多少报文,也可以清晰地看出不同核对报文的转发处理是否均衡，是否还有调优的空间。将B与A的值相对比，如果B与A相等，就说明没有丢包，被测试设备能够达到当前的吞吐值；反之，B不等于A,则说明被测试设备不能达到当前的吞吐值，需要降pps再次试验，直至不丢包。
3.如果被测试设备没有丢包，就把当前的pps换算成Mbps（整机吞吐换算成Gbps）得到具体的吞吐值即可。注意，pps的值为两台主机发送报文时的pps之和。
工控网络设备2-3层性能测试_吞吐（整机）
我们已经掌握了1对口的性能测试方法，那我们该如何去测试整机的吞吐性能呢？以12口型号的工控防火墙为例，如果使用测试仪测试，通过扩展板卡很容易进行测试；但是如果机械地按照上面测试1对口吞吐的方法，那么就需要很多台主机接入测试环境，这显然是不可取的。那有没有简单、高效的方法呢？答案是有的,而且可以还只用两台pc机。
1.我们先分别测试6对口，确保每对口的吞吐性能都能达到线速。
2.把6对接口从左到右依次排序为1，2，3，4，5，6.把pc1与第1对接口的入接口相连，把pc2与第6对接口的出接口连接，剩余的接口分别用1根网线依序连接，即把12个端口串起来打流量。
3.分别抓取用于回放的测试“整机吞吐”的流量报文，与测试1对口性能不同是的，此处为UDP双向12条流,包长512字节。
4.在两台pc上同时发送对等流量。
以上方法在工作实战中，测得一款网络设备整机吞吐性能为4.9 Gbps,与后来用思博伦测试仪测得数值5.2 Gbps相比，相对误差仅为5.8%，验证了该方法的可行性和准确度。
工控网络设备7层性能测试_吞吐
7层吞吐性能反映的是被测试工控网络设备对客户现场使用的特定工控协议的处理能力。测试方法与上面基本一样，只是需要把UDP中的负载换成具体的工控协议就可以了。如modbus协议写多个寄存器值
modbus_request=Ether()/IP(src="200.200.200.3",dst="200.200.200.2")/TCP(dport=502)/Raw(load='x36x33x00x00x00x1Bx04x10x00x64x00x0Ax14x00x0Ax01x02x06x10x07x08x09x10x06x10x06x10x06x10x06x10x06x10')
工控网络设备性能测试_新建、并发
构造并实时发送大量不同的数据流经过被测试设备，按照900ms的间隔读取流表内的建流数值，可以非常直观地看出新建流的能力，近乎等同于每秒新建多少条流。
在新建测试的基础上可以验证并发，具体方法为在保持现有新建速率的基础上可以保持30秒或60秒。
发包环境构造总结：
1.成功之处：在深刻理解硬件测试仪工作原理的基础上，使用等价法找到替换测试仪的替代方法。2.重点：报文构造及获取，发包速率及匀速回放。3.难点：匀速回放。解决方法:1)发送报文时指定发送频率2)回放报文时指定回放频率4.缺点：本文中构造的发包环境是依赖于软件，内存只有4G,而且是在虚拟机中发包，发包速度无法与硬件测试仪的发包速度相比。也就是说瓶颈在于PC机的性能。所以测试性能吞吐时会有5.8%的误差。如果是在一台有8G内存的真实电脑上安装Linux操作系统作为发包机，一定会再次提高测试精度，减小误差！5.改进方案：两台配有8G内存，性能好的CPU的真实电脑上安装Linux操作系统作为发包机.6.约束：该性能测试方法要求被测试设备具备可测试性和排障接口，这也是软件工程中必须具备和满足的要素。比如，CPU收发报文数及每个核各自处理多少报文数的查看接口，流表内容及总条目数查看接口等。
稳定性测试实践：
定性测试在产品级质量保证中具有重要的意义，稳定性测试的充分与否将直接影响产品在客户现场的运行表现。只有在未交付客户前对设备进行长期的、充分的稳定性测试，才能让我们对设备的功能执行情况和稳定性有个快速、感性的认知。
通常的稳定性测试过程中存在着针对性不强，并且缺乏对整个过程的量化。本篇文章就站在工程实践的角度，来有针对性地对工控网络硬件设备进行稳定性测试，并且量化整个测试过程。
在本文中，我们将产品级的稳定性分解成3部分，硬件、操作系统、应用程序（我们的主程序），这三大方面的稳定性。
三方面稳定性
硬件的稳定性：主要涵盖CPU、PCB板、闪存卡、网卡。具体测试点包含：
1)CPU温度；
2)PCB温度；
3)闪存卡读写寿命；
4)网卡大量收发包；
5)网卡PHY芯片温度。
操作系统的稳定性：
1)CPU的分配使用;
2)内存使用
应用主程序的稳定性（业务面）：
1)CPU资源申请;
2)内存资源申请；
3)CPU资源释放
4)内存资源释放；
5)crash监控；
6)主进程重启监控；
应用主程序管理面的稳定性
管理连接监控
一、“硬件稳定性”具体的测试思路及执行
1.Python自动化脚本,构造、发送大量CPU密集型报 文：分片报文（普通IP分片）
2.CPU在长时间转发分片报文的过程中，CPU温度会被打上去；
3.网卡长时间、高速转发报文，其转发报文数可以被直观地验证；PCB网卡PHY芯片温度也会被打上去！
4.CPU温度、网卡PHY芯片温度的快速升高会带动环境温度上升；
5.配置具体业务流触发大量闪存卡读写操作，对比闪存卡实际读写次数与标称寿命；
6.使用python脚本自动记录CPU温度数值；
7.使用python脚本自动记录PHY芯片温度数值；
8.使用python脚本自动记录PCB温度数值；
9.使用python脚本自动记录网卡收发包数量
10.使用python脚本分别画出CPU温度、PHY芯片温度、PCB温度的曲线图，可以直观地分析温度增长是否是符合线性预期；最高值是否符合预期。
CPU温度监控曲线图：
网卡发包曲线图：
二、“主程序稳定性”具体的测试思路及执行
1.Python自动化脚本,构造、发送大量CPU密集型报文：分片报文（普通IP分片）+ 业务层分片报文（Modbus报文分片、IEC报文分片、DNP3报文分片、S7报文分片、Fins报文分片、Profinet报文分片等。），让主程序去向操作系统申请大量CPU资源和内存资源，把CPU使用率和内存使用率打上去；
2.使用Python自动化脚本,对步骤1中设备的主程序向操作系统申请CPU资源和内存资源的过程进行全程跟踪、记录；
3.使用Python自动化脚本，分别对步骤2中记录的CPU使用率和内存使用率进行图表绘制，可以直观地看出资源的申请使用是否线性化，最高值是否超出预期；
4.使用Python自动化脚本对CPU资源释放、内存资源释放进行全程跟踪、记录并画图曲线展示，以直观地验证主程序在进行CPU和内存的资源释放时也是线性的，不会有导致crash和重启的风险；
5.使用Python自动化脚本全程记录在打CPU资源和内存资源过程中，设备是否发生了crash。如果发生，自动化脚本会捕获该事件，并且自动记录发生crash的日期时间、crash了几次和crash文件的名称；同时会自动向相关人员发送邮件通报这一事件。
6. 使用Python自动化脚本全程记录在打CPU资源和内存资源过程中，应用主程序是否发生了重启。如果发生会自动向相关人员发送邮件通报这一事件。
内存使用率和CPU使用率监控曲线图：
内存资源释放和CPU资源释放（即泄洪时）监控曲线图：
三、“系统稳定性”具体的测试思路及执行
为了验证操作系统的稳定性，可以在进行“主程序稳定性”过程中，制造些“异常”场景或事件去导致操作系统的CPU和内存使用飙升，然后去验证“系统稳定性”及对我方主程序稳定性及功能的影响。
具体为：
1.按照“主程序”稳定性中描述的使用Python自动化脚本打CPU资源和内存资源；
2.使用Python自动化脚本每隔30秒去ssh到系统，但是不要关闭连接。这样，在大概30-60分钟内系统的CPU资源就会被打到95%以上。
实际测试结果，在这种情形下，我们的系统会把占用CPU过多的SSH连接杀掉，此时自动化脚本将不能继续进行SSH连接，系统的CPU使用率迅速回到异常前水平。
同时我们的主程序在这种CPU资源极限条件下没有发生crash和重启，功能也正常执行。
四、“主程序管理面的稳定性”
1.使用Python自动化脚本发送大量能够触发业务流的报文
2.使用Python脚本监控是否有与管理面连接无法建立的情况，包括设计规格内和超出设计规格的场景，超出设计规格流量停止后应该可以自愈。如果有发生上下线的情况自动发送邮件通知。
3.业务流数据传输时的自动监控
管理面数据传输监控曲线图：
采用本自动化稳定性测试方案的好处：
1.可以在项目推进过程中，与功能测试并行进行，提前暴露、发现严重的问题（多为与CPU、内存分配使用、回收及设备crash相关）。
2.可以实现无人值守，测试是在自动化部署中进行，并且有自动化跟踪步骤，如果出现问题会第一时间通知开发和测试人员，第一时间定位问题，第一时间解决问题！
下班和周末时间都可以连续不中断运行!
结合自动化对稳定性进行高效的、充分的、高强度的测试，可以让我们对自己产品的实际运行状况有了整体、可量化的认知，也对产品在客户现场能够长时间、稳定运行有了充足的信心！同时，也为后期进行的压力测试奠定了良好的测试基础。
