利用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 server 21 host NMTOKEN #REQUIRED 22 port NMTOKEN #REQUIRED 23 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>
从dtd里可以看出，session标签里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，这里的属性值决定了Tsung可以测试的相关协议的插件，从名称上来看，ts_raw可以作为我查找资料的对象，在user manual里第二章节是介绍tsung的主要功能的，其中2.11章节Raw plugin related features的说明是这样的的：
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%%<iq><sessionid>%%_sessionID%%</sessionid><login>hanhy,hanhy123<login></iq>" ack="local"></raw> </request> </transaction> <transaction name="sendmsg"> <request subst="true"> <raw data=" 124 3 %%_sessionID%%<message><sessionid>%%_sessionID%%</sessionid><content>tsungMsg</content></message>" ack="local"></raw> </request> </transaction>
业务流程模拟成功解决。