當我們所測試的項目是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幫助文檔），把報文發給後端。
手工編寫腳本是一項技術性要求很強的工作，更能提高測試工程師的技術水平。儘管通過純手工編寫的腳本也對服務器施加了壓力，但是它忽視了用戶端的處理邏輯。在儘量模擬真實環境中用戶操作的原則下，這樣是否更能真實模擬用戶的操作，還有待進一步研究。