Tsung测试Tcp协议的应用或接口

本文主要是介绍Tsung测试Tcp协议的应用或接口，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

利用Tsung模拟基于Tcp的业务流程，实属无奈。因ConnectManager部署在linux下，其中，Loadrunner的winsocket因不支持linux platform而无法使用，而Jmeter 又因本身太耗机器的资源，所以，最后决定探索一下Tsung--这个神奇而又让人感到很无奈的工具。

说它无奈主要是它的易用性，一切设置，一切脚本处理都要在xml文档里编写，对于一个使用loadrunner和Jmeter的人，这是相当的残酷的。原因有以下：

1、user manual是英文版的，虽然对我来说没所谓，但是，相信大部分人都会感到整个人都不好了

2、目前网上的资料，基本都是浅浅的

3、tsung脚本的语法是tsung-1.0.dtd，只有元素和属性的值，但是，没有任何说明

虽然，有各种原因，但是，我还是踏上了这条不归路。下面我主要记录一下，我解决这个问题的路程：

首先，我想到了看tsung-1.0.dtd，因为我相信脚本的正确性绝对是依赖于这个dtd文档的，其实，用过tsung的朋友可以发现，tsung脚本运行起来以后，客户端与服务端建立的连接有三种方式，下面贴一下Tsung脚本的位置和dtd文档中，对这个的定义：

  <servers><server host="192.168.14.101" port="9284" type="tcp"></server></servers>

我们看一下，<server>标签里的type属性在dtd文档里的定义：

<!ATTLIST server21      host   NMTOKEN #REQUIRED22      port   NMTOKEN #REQUIRED23      weight NMTOKEN "1"24      type (ssl | tcp | udp | erlang | ssl6 | tcp6 | udp6 |bosh | bosh_ssl | websocket) #REQUIRED>

从而可以看出，客户端与服务端建立的连接方式支持多种，我要建立的是Tcp连接，所以，我选择type="tcp"，接下来就是session里建立连接，发消息的业务流程了，而问题也出在了这里，下面贴一下脚本里对session部分的定义：

<session probability="100" name="raw" type="ts_raw">

probability和name属性就不用介绍了，刚才的server标签定义了底层的连接方式，而这里的type要定义的则是通信时使用的协议类型，我们在dtd里看一下这个type属性的定义：

<!ATTLIST session
133     name         CDATA #REQUIRED
134     bidi         CDATA #IMPLIED
135     persistent   (true | false) #IMPLIED
136     probability   NMTOKEN #IMPLIED
137     weight        NMTOKEN #IMPLIED
138     type         (ts_jabber | ts_http | ts_raw | ts_pgsql | ts_ldap | ts_webdav |ts_mysql| ts_fs | ts_shell | ts_job | ts_websocket | ts_amqp | ts_mqtt) #REQUIRED>

2.11. Raw plugin related features

TCP / UDP / SSL compatible
raw messages
no_ack, local or global ack for messages

当我看到TCP/UDP/SSL compatible，raw message，我好开心。于是，我决定去github:github.com/processone/tsung上看一下tsung的源码以及tsung目前的bug库https://github.com/processone/tsung/issues，从gihub的examples文件夹处，我看到了：，进入这个文件夹我看到了

同时，我在bug库里看到了#115bug，于是，我更加坚信Tsung对基于Tcp协议的业务流程的测试。于是，根据开发给的接口设计文档，开始业务流程的第一步：从服务器获取sessionID

<transaction name="open"><request><raw data="00520005150805134521f84409ba6f5f317c6613dc201018caeb" ack="local"></raw></request>

从tsung.dump中，成功看到send和recv：其中，recv中这串618...数字是sessionID

开始业务流程的第三步：登录，但是，有一个问题是登录时需要用到刚才的sessionID,这就用到了关联，与loadrunner和Jmeter一样，在Tsung里模拟时，也同样需要用到关联将响应中动态数据取出来，作为下一人请求的请求内容。这里，需要参考user manual的Advanced Feature章节，我在这里第一时间想到的是用正则表达式，从user manual里这句话，“the regexp engine uses the re module, a Perl like regular expressions module for Erlang.”明显觉察出，此处的正则表达式或许跟之前在Linux下用的正则表达式有一些区别。但是，不知道有什么区别，所以，一如既往的用linux下的语法写正则表达式，于是，写成：re="[6][0-9]{18}"，具体代码贴下：

<request><dyn_variable name="sessionID"  re="6[0-9]{18}"/><raw data="00520005150805134521f84409ba6f5f317c6613dc201018caeb" ack="local"></raw></request>

运行后，无果，取出来的值为空。抓狂，抓狂，抓狂，重要的事情我要说三遍。我一直觉得是因为我把正则表达式放在请求前，正则表达式匹配是字节流，而正则表达式的作用范围是字符串，所以取的值为空（后来，证明我是错误的）。后来，于绝望中看了Erlang，决定利用Erlang函数处理请求，然后利用字符串截取获取我要的sessionID，但是，苦于获取请求这个阶段就很无望。于绝望中，在一个群里说了一下这个问题，一朋友指出有可能是正则表达式的问题，于是，提醒在要匹配的模式用“（）”括起来，即：re="(6[0-9]{18})"死马当活马医，但是，奇迹真的发生了，我成功的取到了sessionID.事实证明，此正则表达式非彼表达式。　　

接下来，进行登录，发消息流程，贴代码说话：

<transaction name="login"><request subst="true"> <raw data=" 119   1             %%_sessionID%%&lt;iq>&lt;sessionid>%%_sessionID%%&lt;/sessionid>&lt;login>hanhy,hanhy123&lt;login>&lt;/iq>" ack="local"></raw></request></transaction><transaction name="sendmsg"><request subst="true"> <raw data=" 124   3             %%_sessionID%%&lt;message>&lt;sessionid>%%_sessionID%%&lt;/sessionid>&lt;content>tsungMsg&lt;/content>&lt;/message>" ack="local"></raw></request></transaction>