当我们所测试的项目是Tuxedo通信，并且不能使用工具录制脚本，手头只有一些数据（比如服务器报文等等）的时候，我们只有通过手工编写测试脚本啦。
我暂且把编写Tuxedo脚本的工作分为三个重要部分吧。
一、脚本调研部分
1、了解服务器端Tuxedo版本，本地控制机安装Tuxedo客户端，配置环境变量；
2、了解WSL访问方式（IP:Port）；
3、了解研发使用的Tuxedo服务名、数据缓冲类型（如CARRAY、FML32等）、缓冲区长度（如1024*1024*3）；
4、了解这个缓冲区类型的缓冲结构（包括哪些字段、这些字段的属性（数据类型、数据长度等），以及这些字段要放置什么数据，是任意数据还是指定的死数据）；
5、了解报文（报文长度、内容、详细信息；哪些数据需要做参数化；调研报文的格式，是否可以通过在脚本中组装报文，是否可以通过从报文文件中获取报文[从文件中读取的保温不能做参数化处理]），文章最后有对报文的组装形式简要说明；
6、了解报文发送后服务器返回的数据内容、长度等，用作在脚本中判断事务是否成功。
二、脚本编写部分
1、在脚本开头书写脚本详细描述，也就是脚本的名称、脚本语言、作者、脚本编写时间，当然这些都是注释掉的，也是常识，但也是我们容易忽视的地方。
2、在脚本中设定Tuxedo环境变量。
static char *env_allow_array[] = { "WSNADDR=//163.192.1.126:90900", "FLDTBLDIR32=c:/bea/tuxedo8.1/etc", "FIELDTBLS32=ftpflds", NULL }; |
3、定义脚本中变量类型
4、初始化数据
5、lrt_tpalloc分配缓冲区空间
pFml = (FBFR32 *)lrt_tpalloc("FML32",0,4096);
6、lrt_Finitialize32初始化缓冲区
lrt_Finitialize32((FBFR32 *)pFml);
7、组装报文，lrt_Fadd32_fld根据缓冲区结构把字段信息添加到缓冲区
lrt_Fadd32_fld((FBFR32*)pFml,"id=167813666","value=/220/074""3/001/n",LRT_END_OF_PARMS);
8、发送lrt_tpcall请求
lrt_tpcall( "SVCName", (char *)pFml, 0, &MsgRcv, &rcvlen, 0 );
9、判断返回的信息是否正确（看你是不是有这个需求）
10、使用lrt_tpfree释放申请的请求和应答buffer空间（也就是对有lrt_tpalloc获取的缓冲区进行释放）
lrt_tpfree((char *)pFml);
11、对每个变量和每一步执行代码做注释，要养成写完脚本后做注释的习惯
三、脚本调试部分
对与调试部分对脚本来说是十分重要的一块，写完脚本后，必须验证脚本。运行脚本对不同的日志提示进行相应的调试即可，可以通过设置断点（F9），单步执行（F10），增加日志函数等方法调试脚本。由于脚本调试过程中遇到的问题多样化，解决的办法也各不相同，这里不再赘述。
补充：
组装报文的形式（据我知道的）：
1、在脚本中直接通过strcat（）函数和lr_eval_string（）函数组合或使用sprintf（）函数和lr_eval_string（）函数组合组装报文（在其中可以对报文做参数化操作），然后把报文串赋值给一个字符串。
2、如果本次性能测试不要求对报文做参数化，并且项目组给的报文数据是以二进制格式或其他格式的文件（如****.bin、***文件）存在的话，我们也可以写C代码读取数据文件信息（具体读取文件操作的代码可以参照VuGen帮助文档），把报文发给后端。
手工编写脚本是一项技术性要求很强的工作，更能提高测试工程师的技术水平。尽管通过纯手工编写的脚本也对服务器施加了压力，但是它忽视了用户端的处理逻辑。在尽量模拟真实环境中用户操作的原则下，这样是否更能真实模拟用户的操作，还有待进一步研究。
