LoadRunner之編寫Tuxedo指令碼

loadrunner之編寫tuxedo指令碼

當我們所測試的專案是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=",

"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幫助文件），把報文發給後端。

手工編寫指令碼是一項技術性要求很強的工作，更能提高測試工程師的技術水平。儘管通過純手工編寫的指令碼也對伺服器施加了壓力，但是它忽視了使用者端的處理邏輯。在盡量模擬真實環境中使用者操作的原則下，這樣是否更能真實模擬使用者的操作，還有待進一步研究。