选择“General”选项卡，设置“UPS Set：Chinese（Simplified）”（如图四）

图四

　　4）脚本的录制和优化

　　设置完成后，可以根据业务流程录制测试脚本。录制脚本前要先熟悉整个流程，以免在录制过程中录入大量不必要的操作步骤（由于RTE协议是记录屏幕的光标和坐标来定位的所以会记录一些不必要的操作），录制完成后通过回放脚本来判断脚本是否正确，RTE协议在回放时会自动调用自带的终端仿真软件，完全按录制的步骤播放（类似QTP做自动化功能测试）。

　　5）关于RTE协议中有些键不起作用的解决办法

　　如果录下来的脚本中<ESC>键是：TE_TYPE（"<K-ESCAPE>"），（作用是发送<ESC>键指令），但在脚本回放到这一步后，是走不下去，达不到要到的游标点，如果可以肯定脚本正常，出现这种情况怎么解决呢？换一种思路：可以用“SOCKET”协议来录制脚本，看看在SOCKET中这些功能键（组合键）的指令是什么，然后把这些十六进制的指令拷贝过来替换。如<ESC>键，在“SCOCKET”协议中发送指令为"x1b"，所以把脚本中TE_TYPE（"<K-ESCAPE>"）直接替换成TE_TYPE（"x1b"）可以了。其他类似的问题，可用同样的方法来解决。

　　2、使用Tuxedo协议的方案（如图五）

图五

　　如图我们初步了解到Tuxedo作为中间件，主要是通过接受客户端发送的报文，服务器端程序对发送的报文进行处理并返回结果的过程。如果有前台的客户端程序那么我们可以通过录制在客户端上的操作进行性能测试脚本的开发，但是通过了解知道测试的项目是Tuxedo中间件，并且没有客户端程序，因此不能使用工具录制脚本时，手中只有一些数据（比如服务器报文等等）的时候，我们只有通过手工编写测试脚本。

　　通常编写Tuxedo脚本的工作分为三个重要部分。

　　1）脚本调研部分

　　A.了解服务器端Tuxedo版本，本地控制机安装Tuxedo客户端，配置环境变量；

　　B.了解WSL访问方式（IP:Port）；

　　C.了解开发使用的Tuxedo服务名、数据缓冲类型（如CARRAY、FML32等）、缓冲区长度（如1024*1024*3）；

　　D.了解这个缓冲区类型的缓冲结构（包括哪些字段、这些字段的属性（数据类型、数据长度等），以及这些字段要放置什么数据，是任意数据还是指定的死数据）；

　　E.了解报文（报文长度、内容、详细信息；哪些数据需要做参数化；调研报文的格式，是否可以通过在脚本中组装报文，是否可以通过从报文文件中获取报文[从文件中读取的报文不能做参数化处理]）

　　F.了解报文发送后服务器返回的数据内容、长度等，用作在脚本中判断事务是否成功。