LoadRunner_測試Tuxedo.doc

用LoadRunner測試Tuxedo中間件系統(tǒng)河北移動BOSS1.5公司： 作者：張 翼日期：2005年6月22日修訂紀錄日期修訂版本修改描述 作者2005-7-141.00初稿完成 張翼1概述隨著軟件行業(yè)的發(fā)展，測試作為軟件生命周期中特別重要的一個步驟，已經被越來越多的軟件開發(fā)單位所重視。隨著客戶對軟件認識的不斷深入，對測試的要求也越來越高?？蛻粢呀洸辉賰H僅滿足于軟件功能的完成。而更注重的是軟件的性能和能夠承受的壓力。很多人容易把軟件性能測試和軟件壓力測試混淆，甚至包括一些已經從事軟件測試工作多年的專業(yè)人員。其實，二者之間確有關聯(lián)，但也有比較明顯的區(qū)別。按照我個人的理解，軟件性能測試主要關注的是軟件在規(guī)定正常的條件下，其處理能力的體現。比如對軟件響應速度的測試和對服務器資源占用情況的檢測；而壓力測試，顧名思義，既是對軟件的運行環(huán)境施加壓力，來觀測軟件的運行情況。它關注的不是軟件的響應速度或占用了多少系統(tǒng)資源。而是以高出正常負載20%30%的情況下，觀測系統(tǒng)是否能夠成功正確的響應請求。其失敗率是多少。在做軟件性能測試的時候如何去檢測系統(tǒng)的響應速度？又如何去觀測系統(tǒng)資源占用的情況呢？在做軟件壓力測試的時候，如何構造一個高于正常負載的一個測試環(huán)境呢？又如何統(tǒng)計業(yè)務的失敗率呢？目前，業(yè)界中有不少能夠做性能和壓力測試的工具，Mercury Interactive公司的LoadRunner是其中的佼佼者，也已經成為了行業(yè)的規(guī)范。它完全能夠幫助完成以上所需要的工作。2編寫目的河北移動BOSS1.5是以Tuxedo為中間件的C/S三層結構系統(tǒng)。作為測試員，我被安排做賬務這個模塊的性能和壓力測試。由于以前從來沒有使用過LoadRunner，這次工作遇到了很大的困難。瘋狂K書的結果是發(fā)現LoadRunner對B/S系統(tǒng)的性能和壓力測試支持得如此之好。凡是網上有的資料十之八九的都是介紹如何用LR對B/S系統(tǒng)的測試。此外就是一些喜歡玩底層的高手，弄一大堆英文資料來介紹Winsock的測試。我只能說，對不起，Winsock的英文資料我看不懂，B/S的資料我暫時不需要。還有一篇網上流傳的文章，介紹的是用LR對BEA（Tuxedo、Weblogic）的測試，只簡單描述了LoadRunner測試步驟，其介紹太留于表面，掃盲尚可，作為使用的說明，那就差的太遠了。對于我們的系統(tǒng)來說，很明顯應該使用Tuxedo協(xié)議去錄制測試腳本。由于不能找到相關的介紹文檔。我在著名的51testing論壇上和深圳測試協(xié)會的論壇上都發(fā)帖求助。居然5天過去了，看的人不少，回復的人一個也沒有。氣憤之余，決心要在這次測試搞定以后一定記錄下步驟和心得，亦是本文形成的緣由。3本文討論的范圍本文是針對LoadRunner對Tuxedo中間件系統(tǒng)測試的一個專題文檔。通過實例描述的方式介紹LR對Tux中間件系統(tǒng)進行測試的方法，主要介紹對腳本的處理，順帶介紹一下LoadRunner基本功能和測試步驟，但是不會以此為主。本文不會對Tuxedo中間件的詳細配置進行介紹。4測試腳本的準備我打算以繳費的性能測試作為例子，通過我是怎樣一步步實現這個測試腳本的，來介紹這個過程。4.1腳本的錄制萬事開頭難？當接到測試繳費性能的任務時，我已經看過了一些關于用LR測試B/S的文章。所以毫不猶豫的開始了用Tuxedo協(xié)議錄制腳本的工作。4.1.1協(xié)議的選擇打開VuGen，選擇單協(xié)議錄制方式，采用Tuxedo6協(xié)議:圖表 1 協(xié)議選擇由于系統(tǒng)的服務端采用的Tuxedo8.0服務，所以剛開始的時候我使用Tuxedo7協(xié)議進行錄制。在錄制到第8個事件的時候報錯（如圖2）。后來考慮到錄制的客戶端是tuxedo6.5的，可能不包含Tuxedo7的部分dll文件，所以改用Tuxedo6協(xié)議，就能夠成功錄制了。圖表 2 協(xié)議選錯了4.1.2開始錄制選單設置當打開Tuxedo6協(xié)議開始錄制以后，系統(tǒng)彈出一個開始錄制對話框。由于測試對象是C/S結構的，所以我選擇“Win32應用程序”為應用程序類型。然后在要錄制的程序里面通過選擇按鈕選到要運行的客戶端程序。將“錄制到操作”定位到vuser_init中。詳細的信息如圖。圖表 3 開始錄制對話框 注意：1、 LR的腳本基本上分成三個結構，vuser_init、action、vuser_end。對于Web協(xié)議的腳本來說action可以是多個的。對于選用的Tuxedo6協(xié)議，經過觀察，好像不能添加多個action。通常vuser_init是用來放置登錄腳本的，vuser_end是用來放置退出腳本的，這兩部分的腳本不參與迭代和循環(huán)，也不需要定義事務。如果需要在登錄的時候添加集合點，驗證多用戶登錄的壓力測試方案，則需要將登錄腳本放在action中，讓vuser_init留空。因為在vuser_init區(qū)域內是不允許添加集合點的。2、 “工作目錄”通常是根據“要錄制的程序”的選擇而自動填充的，不需要做修改。4.1.3錄制登錄“開始錄制”對話框設置完成，點擊OK鍵，錄制正式開始。LR會根據設置的“要錄制的程序”打開對應的客戶端程序（如圖4）。按照正常步驟登錄即可。圖表 4 正常登錄輸入工號和口令點擊確定，成功登錄系統(tǒng)。LR的錄制控制條會顯示錄制過程中發(fā)生的事件，比如在登錄窗口打開過程中共做了24個事件（如圖4），登錄成功后共做了112個事件（如圖5）。4.1.4插入集合點登錄完成后，將要做繳費操作，所以需要更換錄制腳本的區(qū)域。直接在錄制控制條上將vuser_init換成action即可(如圖5)。圖表 5 更換錄制區(qū)域 然后繼續(xù)腳本的錄制。打開繳費的界面，輸入一個要繳費的服務號碼（電話號碼）。輸入完成后添加集合點。添加集合點的方式為點擊錄制控制條上的添加集合點按鈕（如圖6）。然后彈出“插入集合點”對話框，輸入集合點的名字，就成功了。圖表 6 添加集合點 注意：1、集合點：當通過controller虛擬多個用戶執(zhí)行該腳本時。用戶的啟動或運行步驟不一定都是同步的。集合點是在腳本的某處設置一個標記。當有虛擬用戶運行到這個標記處時，停下等待，直到所有的用戶都達到這個標記處時，再一同進行下面的步驟，這樣能夠用最大的用戶并發(fā)去做下面的操作，就像集合再前進一樣。集合點之名由此而得。集合點主要用于對關鍵步驟的加壓。所以常用在事務定義之前。4.1.5插入事務點集合點插入完畢，點擊錄制控制條上的“事務開始定義”按鈕定義事務。“開始事務”對話框彈出，輸入事務名稱，點擊確定就完成了開始事務的標記。（如圖7）圖表 7 插入事務開始點 注意：1、事務：對于一個錄制好的腳本，在回放的時候怎么去關注它的具體性能呢？當然不是全局的去觀察。測試需要注意的其實是腳本中的關鍵點。比如圖書館的新書入庫，其實測試人員關注的只是在圖書入庫的那個步驟的性能值，通常都不會去研究填寫這些入庫圖書信息的那些過程。所以LR的事務添加操作就是把測試所需要關注的操作定義成事務告訴LR，這個是我想要重點檢測性能的操作。LR就會在運行過程中記錄事務內操作的響應事件等性能數據。并在Analysis中以報告的形式給出統(tǒng)計結果。4.1.6插入事務結束點事務開始點插入完成后，點擊Enter鍵，對輸入的服務號碼進行查詢。查詢出號碼對應的賬戶信息。當查詢完成后，點擊錄制控制條中的插入事務結束點按鈕。彈出“結束事務”對話框，點擊OK結束定義的事務。（如圖8）圖表 8 插入事務結束點現在來回顧一下4.1.4到4.1.6做了什么。其實我的目的是讓LR關注查詢輸入的電話號碼對應的賬戶信息這個步驟，因為它是一個要和數據庫交互的動作，并且會被客戶經常使用。所以應該把查詢賬戶信息的操作定義成一個事務。在做這個事務之前，為了給這個事務正常加壓。所以定義了集合點。4.1.7完成腳本錄制賬戶信息查詢的過程完成后，在“實交”區(qū)域內輸入實際要交的金額。然后效仿前面的步驟為繳費提交的操作添加集合點、事務開始點。然后點擊確定按鈕。等提交完成后加入事務結束點。事務結束點加入過后，需要的基本操作就完成了。最后錄入退出腳本。此時需要將腳本錄制區(qū)域修改為Vuser_end（如圖9）圖表 9 更換腳本錄制區(qū)域然后點擊關閉客戶端的按鈕。在系統(tǒng)提示確認過后，成功退出客戶端。然后點擊錄制控制條上的結束控制按鈕，就能夠成功生成錄制的腳本。至此我的繳費性能測試腳本就制作完成了。誰說萬事開頭難？就錄腳本來說，我認為是LoadRunner操作中最簡單也最容易上手的。 注意：在錄制腳本的過程中，需要選擇數據。建議最好能夠選擇比較有代表性的數據。比如我的腳本中，選擇的服務號碼。該號碼對應的賬號和用戶號碼最好不要相同。因為這兩個號碼在后面動態(tài)關聯(lián)或參數替換的地方需要用到。如果不能區(qū)別的話，到時候從Reply CARRY buffer中找到的數據就不知道哪些應該替換成賬號，哪些應該替換成用戶號碼了。后面會對參數替換和動態(tài)數據的關聯(lián)詳細介紹。4.2腳本的修改增強腳本功能關于Tuxedo6協(xié)議的LoadRunner錄制腳本的增強，費了我不少功夫。主要是到處都找不到資料。上網求助也無門。后來發(fā)現高手就在身邊，通過不斷的請教，終于順利完成了這次的工作任務。再次特別的感謝這位高手。腳本錄制完成了，我在Vugen中回放了兩邊，都能夠順利通過。但是如果就用這個腳本去做性能測試顯然是不能測試到真正的性能的。4.2.1錄制的原始腳本不能直接用做性能測試為什么錄制的原始腳本不能直接用做性能測試呢？這里先簡單講述一下controller的用途。LoadRunner8.0以前的版本主要包含了3個應用VUGenerator、Controller和Analysis。VUGenerator用于對測試腳本的錄制、編譯和調試；Analysis用于對性能測試結果的分析和給出報表結果；LoadRunner8.0還包含一個叫做Tuning Console的應用，是用作系統(tǒng)優(yōu)化方案的（我沒有用過，連相關資料都沒看過，就不吹這個了）；Controller是用于虛擬場景的構建、提供虛擬用戶方案的模擬，對測試腳本的分配，以及提供監(jiān)視器實時監(jiān)控系統(tǒng)資源。簡單點講，就是用VuGen錄制完腳本了，用Controller去生成一個場景，然后產生大量的虛擬用戶，把腳本分配給這些虛擬用戶在場景中去執(zhí)行，對服務器來說就好像同時有很多用戶都在訪問自己，實際上都是一臺或數臺機器虛擬出來的?，F在來討論一下為什么原始腳本不行。拿我錄制的腳本來說，首先，登錄系統(tǒng)以后，要用一個電話號碼查詢賬戶信息，然后給這個賬戶繳費。當虛擬了大量用戶以后，每個用戶都同時去執(zhí)行這個腳本，就會造成所有的虛擬用戶同時在為同一個賬戶繳費。由于系統(tǒng)有concurrence constraint機制，是不允許兩個操作員同時操作同一條數據的。所以用原始腳本運行是肯定會報錯的。所以，為了避免這個問題，就需要對當前的腳本增強，使其更加通用化。能夠讓不同的虛擬用戶為不同的賬號繳費。具體的實施主要有參數化替換和動態(tài)數據關聯(lián)兩個操作。要做這兩個操作，就一定要熟悉錄制出來的腳本的結構。4.2.2 Tuxedo協(xié)議錄制生成的腳本結構簡介在VuGen中可以發(fā)現錄制完成的腳本中，除了包括3個腳本區(qū)域外還有1個Replay.vdf文件。如圖：圖表 10 Replay.vdf這個Replay.vdf是用來做什么的呢？首先從錄制腳本的結構說起。在vuser_init、action、vuser_end中腳本的結構都十分類似。結構大概為多個request carry buffer和對應的reply carry buffer。圖表 11 腳本實例圖11是從錄制腳本的action區(qū)域中截取的一段。從注釋信息中可以看出，它包含了一個/* Request CARRY buffer 12 */和一個/* Reply CARRAY buffer 12 */?，F在具體介紹一下各個語句，先從圖中紅框內/* Request CARRY buffer 12 */以前的語句開始。l lr_rendezvous(queryCustInfo);該語句是我在錄制過程中定義的第一個集合點。l lr_start_transaction(queryCustInfo);該語句是我在錄制過程中定義的第一個事務開始點。l lrt_tpfree(data_1);該語句是將data_1內的數據清空。l lrt_tpfree(data_0);該語句是將data_0內的數據清空。l lr_think_time(24);設置思考事件，當腳本運行到此處，暫停24秒。l data_0 = lrt_tpalloc(CARRAY, , 253);給data_0分配一個新的緩存空間，類型為CARRAY，子類型為空，長度為253個字節(jié)。/* Request CARRY buffer 12 */l lrt_memcpy(data_0, sbuf_12, 252);從sbuf_12中拷貝252個字節(jié)到data_0。l lrt_display_buffer(sbuf_12, data_0, 252, 252);該命令是將data_0指向的sbuf_12緩存中的數據拷貝到一個.out文件當中。第1個252是“在回放中將使用的實際數據長度”。第2個252是“期望的長度和在錄制過程中觀測到的一樣”。l data_1 = lrt_tpalloc(CARRAY, , 2); 給data_1分配一個新的緩存空間，類型為CARRAY，子類型為空，長度為2個字節(jié)。l tpresult_int = lrt_tpcall(DISPATCHER,data_0,252,&data_1,&olen,0);lrt_tpcall函數的作用是發(fā)送一個服務請求但后等待回復。上面語句是向DISPATCHER發(fā)送請求，data_0是請求的數據部分，252是指data_0的長度，&data_1是返回的數據，&olen是返回數據的長度，0是有效性標記。/* Reply CARRY buffer 12 */l lrt_display_buffer(rbuf_12, data_1, olen, 11594);該命令是將data_1指向的rbuf_12緩存中的數據拷貝到一個.out文件當中。olen是“在回放中將使用的實際數據長度”。11594是“期望的長度和在錄制過程中觀測到的一樣”。l lrt_abort_on_error();如果上一步tuxedo功能遇到錯誤，就中止當前正進行的事務?，F在再來看Replay.vdf。打開Replay.vdf,可以發(fā)現下面的語句寫在開頭處：/*This file is generated by LoadRunner. You may edit it carefully!*/#ifndef TUXVDF_H#define TUXVDF_Hchar* data_0;char* data_1;現在終于知道data_0和data_1是從哪里來的了。再往下看，可以發(fā)現原來Replay.vdf 中的結構也大體是多個request carry buffer和對應的reply carry buffer。并且注意，所有的reply carry buffer都是被注釋的。在這里可以找到action中被使用的sbuf_12和rbuf_12。其實Replay.vdf就是一個大的數據倉庫。在和服務器交互的過程中，所有緩存中的數據最終都會按照格式寫進Replay.vdf。拿我錄制的腳本舉例，登錄用的txjhs，查詢賬戶用的服務號碼都能夠在Replay.vdf中對應的sbuf中找到；而輸入服務號碼后獲取的賬戶信息（賬號、流水號等等）信息也能從Replay.vdf中對應的rbuf中找到。如此以來就可以對這些數據進行參數化和動態(tài)綁定了。 注意：1、腳本中各個函數的具體含義其實不必深究。對于測試員來講，如果不是打算用手工方式編寫完整的腳本，那么知道函數的大意已經足夠了。不會影響性能測試的進行。2、有沒有發(fā)現Replay.vdf里面有很多亂碼？這是因為數據被加密了。比如我第一次錄制完成后，發(fā)現了大段的亂碼。而且有類似下面的語句：圖表 12 Replay.vdf亂碼有compress做標記，表示該段代碼被加密。從腳本中看，因為加密是發(fā)生在Request段中，所以應該是客戶端向服務器端發(fā)送的請求被加密，請開發(fā)的同事提供了解密版本的客戶端解決了這個問題。在軟件中，如果重要的數據或請求需要在網絡上傳輸，為了避免被破壞性的截取，往往會將這些數據或請求加密以后再放在網上傳輸，接收方接到加密數據后經過解密程序解密再做后續(xù)響應。4.2.3參數化替換關于為什么要做參數化替換已經在本節(jié)的前面部分有較詳細的描述，這里就不再贅敘了。直接進入如何參數化的部分。同樣拿我錄制的腳本開刀。首先回想一下腳本錄制過程。錄制的腳本中，主要包含下面幾個流程。1、 首先用txjhs用戶登錄系統(tǒng)。2、 然后輸入服務號去獲取賬號等信息。3、 對賬號進行繳費操作。4、 退出?？梢杂^察到在整個流程中需要參數化的是用戶（包括對應密碼）和服務號碼。因為它們是操作員向服務器發(fā)出請求的數據。在Replay.vdf中找到用戶和服務號碼第一次出現的地方。選中這個字段，點擊右鍵，彈出右鍵菜單。（如圖13）圖表 13 參數替換右鍵菜單選擇“替換為新參數”打開“選擇或創(chuàng)建參數”對話框。（對于英文版LR應該是選擇“Replace with new parameter”）。圖表 14 選擇或創(chuàng)建參數參數名可以任意命名，最好和實際參數的意義匹配，便于以后維護。參數類型這里選擇File，意為從文件中讀取。然后點擊“屬性”按鈕打開“參數屬性”頁面，如圖15。頁面中參數類型和選擇或創(chuàng)建參數頁面中的參數類型等效。文件路徑為文件保存路徑。點擊“創(chuàng)建表”按鈕。確認后，能夠創(chuàng)建一個一行一列的數據表，數據為“txjhs”，就是登錄用戶（該用戶沒有設置密碼，所以沒有參數化密碼），然后可以通過點擊添加行和添加列按鈕，添加記錄，并輸入新的登錄用戶名，最后LR會將這些數據形成一個文件保存在指定的路徑中。圖表 15 參數屬性頁面點擊數據向導按鈕，能夠打開數據庫查詢向導頁面，如圖16。圖表 16 數據庫查詢向導建議在查詢定義中選擇“手動指定SQL語句”，點擊下一步，可以打開指定SQL語句頁面。如圖17圖表 17 手動指定SQL語句點擊創(chuàng)建，打開Select Data Sourc頁面，開始創(chuàng)建連接字符串。如圖18圖表 18 Select Data Sourc頁面點擊“New”按鈕，打開“Create New Data Source”頁面，選擇Oracle ODBC Driver數據源類型（因為我的后臺數據庫是Oracle），點擊“下一步”圖表 19 Create New Data Source頁面新頁面中要求輸入數據源的名稱，可以隨意鍵入，如圖20。然后點擊下一步。圖表 20 輸入數據源名稱 確認信息頁面彈出，并列出目前該數據源的設置，直接點擊完成即可，會彈出一個連接窗口，輸入數據庫連接的服務名，用戶名和密碼，點擊OK，如圖21：圖表 21 數據庫連接窗口如果連接通過，ODBC數據源就被成功創(chuàng)建，可以在“手動指定SQl語句”的窗口中看到連接串。然后在SQL語句窗口輸入自己定義的SQL語句，點擊完成后，就能夠成功按照提供的數據源和SQL語句在指定的數據庫中查詢到指定的數據存放于數據文件中。如圖22：圖表 22 填入SQL通過創(chuàng)建表方式和數據向導方式都可以成功創(chuàng)建數據文件，操作員可以隨意選擇自己習慣的方式?？傊?，能堅守數據文件放數據的原則，就不會出問題了。當回到“參數屬性頁面”中后，發(fā)現數據已經準備好了，而且原來灰色的區(qū)域目前也可以選擇了。如圖23。選擇列中的內容，不再贅述。主要介紹一下“選擇下一行”和“更新值的時間”的幾個選項。圖表 23 參數屬性頁面2“選擇下一行”共有下面幾個選項：u Sequential： 按照順序一行行的讀取。每一個虛擬用戶都會按照相同的順序讀取。u Random： 任意選擇。但是在每一次迭代中，將不發(fā)生變化。u Unique：唯一的數。當使用該選項時，需要保證準備的數據文件中有足夠的數據。比如要做20個虛擬用戶，每個用戶要進行5次迭代，第一個用戶在5次迭代中分別使用數據文件中的數據1數據5，第二個用戶在5次迭代中分別使用數據文件中的數據6數據10，類推以后20個用戶將使用到100個數據。那么必須保證準備的數據文件中有100個以上的數據，否則運行時會出錯。u Same line as 某個參數：和前面定義的參數取同行的記錄。通常用在有關聯(lián)性的數據上面。比如當我做登錄密碼的參數化時，由于它和UserID是有關聯(lián)的，所以會用到這種選擇方式?！案轮档臅r間”共有下面幾個選項：u Each iteration：每次迭代更新一個新的值。u Each occurrence：每次出現時該參數時更新一個新的值。u Once不管迭代多少次該參數的值一直保持不變?？紤]到我錄制腳本的實際情況，這里我將“選擇下一行”設為“Unique”，將“更新值的時間”設為“Each iteration”。既是說，每次迭代的時候讀取一次數據文件中的數據且文件中的數據不會被多用戶重復使用。這樣參數的定義就完成了，可以發(fā)現Replay.vdf中原來選中的“txjhs”變成了“UserID”。如圖24。說明該數據已經被參數替換了。接著將Replay.vdf文件中所有在Request CARRY buffer里出現的“txjhs”全部替換為“UserID”。參數替換的工作就完成了?？梢詤⒄毡敬尾僮鞯牟襟E同樣替換服務號碼。圖表 24 參數化替換成功 注意：1、 參數類型：在創(chuàng)建參數的時候，我選擇了參數類型為File。參數類型共有9種，現在來簡單介紹一下所有的參數類型以及意義。1.1、 DateTime：在需要輸入日期/時間的地方，可以用DateTime 類型來替代。其屬性設置也很簡單，選擇一種格式即可。當然也可以定制格式。1.2、 Group Name：很少用到。在實際運行中，LoadRunner使用該虛擬用戶所在的Vuser Group 來代替。但是在VuGen 中運行時，Group Name將會是None。1.3、 Load Generator Name：在實際運行中，LoadRunner 使用該虛擬用戶所在LoadGenerator 的機器名來代替。1.4、 Iteration Number：在實際運行中，LoadRunner 使用該測試腳本當前循環(huán)的次數來代替。1.5、 Random Number：隨機數。很簡單。在屬性設置中可以設置產生隨機數的范圍。1.6、 Unique Number：唯一的數。在屬性設置中可以設置第一個數以及遞增的數的大小。注意：使用該參數類型必須注意可以接受的最大數。例如：某個文本框能接受的最大數為99。當使用該參數類型時，設置第一個數為1，遞增的數為1，但100 個虛擬用戶同時運行時，第100 個虛擬用戶輸入的將是100，這樣腳本運行將會出錯。這里說的遞增意思是各個用戶取第一個值的遞增數，每個用戶相鄰的兩次循環(huán)之間的差值為1。舉例說明：假如起始數為1，遞增為5，那么第一個用戶第一次循環(huán)取值1，第二次循環(huán)取值2；第二個用戶第一次循環(huán)取值為6，第二次為7；依次類推。1.7、 Vuser ID：設置比較簡單。在實際運行中，LoadRunner 使用該虛擬用戶的ID 來代替，該ID 是由Controller 來控制的。但是在VuGen 中運行時，Vuser ID 將會是 1。1.8、 File：需要在屬性設置中編輯文件，添加內容，也可以從現成的數據庫中取數據（就是我用到的那種類型）。1.9、 User Defined Function：從用戶開發(fā)的dll 文件提取數據。有關各種參數類型屬性的詳細設置這里就不多介紹了，到用到的時候大家可以多看看幫助文檔。4.2.4動態(tài)數據關聯(lián)什么是動態(tài)數據關聯(lián)？哪些是動態(tài)數據？怎么關聯(lián)？什么是動態(tài)數據關聯(lián)動態(tài)數據可以理解為從服務器返回給客戶端的數據。比如當你向服務器發(fā)送了一個請求 (Request CARRY buffer)，在服務器的響應（Reply CARRY buffer）中會給出一些數據。并且在后續(xù)的程序中，這些被服務器返回的數據將被頻繁的使用。對于不同的請求數據來說，服務器處理后會返回不同的響應數據。操作員在得到這些數據返回之前無法預測到這些數據，所以無法用參數化的方式去處理這些數據。比如當我輸入服務號碼查詢賬戶信息。輸入的服務號碼是我可以控制的，這個是發(fā)送的信息。發(fā)送這個信息以后，服務端會處理我發(fā)送的服務號碼，然后返回給我這個服務號碼對應的賬戶信息，這個是處理在Reply CARRY buffer中的。而且后面的程序會對這個賬戶號碼進行繳費操作。輸入不同的服務號碼，其返回的賬號信息都不想同。像這樣的數據就需要用到關聯(lián)了。關聯(lián)的做法是預先定義一個變量，當從服務器截獲到Reply CARRY buffer時，把其中相關的值保存在這個變量中，當系統(tǒng)中有用到這個返回值的時候就用這個變量去替換。這樣以來，不管輸入什么樣的服務號碼，那個變量中保存的值永遠是對應的賬號信息。確定需要關聯(lián)的值怎樣去確定要關聯(lián)的值？有兩種方式。一個很有經驗的操作員，根據他對系統(tǒng)業(yè)務的了解，可以很清楚的知道哪些請求操作會讓服務器返回一些將在后面操作中用到的數據。以及這些數據包括哪些內容。然后就可以輕松的寫腳本關聯(lián)這些返回的數據；另外一種方式是用不同的請求輸入錄制兩份相同操作的腳本。然后用VUGen自帶的WDIFF工具比較兩次腳本的不同之處，以得到需要關聯(lián)的地方。比如我分別錄制兩次繳費業(yè)務的腳本，兩次使用的服務號碼不同，在返回的buffer里面就可以看出這兩次腳本返回的不相同的地方，就可以做這些數據的關聯(lián)了。但是并不是所有的不同之處都需要關聯(lián)。比如某些指明執(zhí)行時間的Reply CARRY buffer中的數據就不必關聯(lián)。第二種方式比第一種要麻煩，但是操作條理比較清楚，而且不容易遺漏需要關聯(lián)的數據，很適合初學者。我是按照第二種方法來做的。首先我錄制了兩個繳費的腳本（Fee1和Fee2）。操作步驟完全一樣，僅僅是登錄的用戶和輸入的服務號碼不同。當Fee2錄制完成后，選中左邊導航欄中的Replay.vdf，點擊“工具”“與Vuser比較”，如圖25：圖表 25 與Vuser比較在對話框中選擇剛才錄制的腳本Fee1，然后點擊確定。打開如圖26：圖表 26 打開WDIFF如圖中所示，兩個Replay.vdf腳本中的差異用黃色高亮顯示（在頁面中雙擊可以在查看全文和查看差異模式間切換）。然后關注其中一個文件，統(tǒng)計出除了執(zhí)行日期和16進制代碼段以外的所有差異數據。比如我統(tǒng)計的是Fee2的Replay.vdf中的差異數據，包括txjhs等。接著回到Fee2的腳本，研究Replay.vdf。在Replay.vdf文件中查找剛才統(tǒng)計出來的差異數據。其規(guī)則是看這些數據的第一次出現是否在Reply CARRY buffer區(qū)域內，并且該數據是否在后面的Request Request CARRY buffer中有用到。如果兩個條件都滿足，則說明該數據需要關聯(lián)。 注意：1、 差異分兩種，一種是兩個文件的相同的行中，有不一樣的數據；另一種是在相同的行中，一個文件有數據，另一個文件沒有數據。我們的研究對象不考慮后者。關聯(lián)數據下面以accountoid的關聯(lián)來說明關聯(lián)的具體步驟。在我的差異數據統(tǒng)計中，我找到的需要關聯(lián)的數據其中一個是3180800249409，它第一次出現在Reply CARRY buffer 14中（如圖27），然后在Request CARRY buffer15，19，23，24中都有用到。圖表 27 Reply CARRY buffer 14然后開始計算它的offset數值。offset數值是指，從Reply CARRY buffer14開始，到出現3180800249409總共有多少個字節(jié)。16進制按分段，算一個字節(jié)，雙引號和段的標題不算在內，因此，這個數據的offset值應該是68，長度是13。接下來在錄制的腳本中（vuser_init，Action，vuser_end）找到Reply CARRY buffer14的段，插入關聯(lián)語句段。如圖28：圖表 28 插入關聯(lián)語句圖中所示lrt_save_parm()函數就是LR中tuxedo協(xié)議腳本專用的關聯(lián)函數。data_1表示Reply CARRY buffer 14中的數據是從data_1中的來的，68是offset值，13是需關聯(lián)數據的長度。accountoid是定義的變量名稱。這個函數的意思是，從data_1中68位以后，取13位數據保存在變量accountoid中。關聯(lián)定義完成以后，再修改Replay.vdf。把Request CARRY buffer 15，19，23，24中的3180800249409全部替換成accountoid。如圖29：（Reply CARRY buffer中的不必替換了）圖表 29 替換Request CARRY buffer至此，該數據的關聯(lián)就已經完成了。其他數據的替換按照同樣的操作進行。動態(tài)數據關聯(lián)就可以成功的完成。錄制過程中我對腳本的修改也止于此。像加入流程控制語句之類的其他修改方式在我的測試中并沒有用到。請參閱其他資料。 注意： 按照文中描述的方法二去尋找需要關聯(lián)的數據也不是絕對的。在我錄制腳本的過程中就遇到了一個不能關聯(lián)的數據。下面以此為例，加以說明。 在錄制的過程中，依照方法二，我發(fā)現了一個需要關聯(lián)的數據3180800158122。在數據庫中，查詢到這個號碼其實是用戶的oid。它在Reply CARRY buffer 14中第一次出現（如圖30），并在Request CARRY buffer15和19中使用。按照前面的描述，這個數據是應該被關聯(lián)的。 但是我們再注意看這個buffer段。在3180800158122出現以前，有一段數據德順。有姓名字段的存在導致這個數據無法被關聯(lián)。因為對于不同的服務號，會有不同的客戶名稱，有兩個字的，三個字的，四個字的，甚至英文字串。這樣以來通過這個“孟德順”計算出來的offset值就不一定適用于其他服務號碼的請求。因此這里不能用關聯(lián)的方式。我在這里的處理方式是將這個值參數化，并且和另一個參數化的數據服務號碼綁定在一起。當選擇服務號碼的時候，就能夠準確綁定對應的用戶ID。詳細方法請參看前面的參數化替換。圖表 30 oid的第一次出現4.3腳本的調試驗證腳本的正確性腳本完成后可以在Generator中對腳本進行調試。選中某行，點擊F9可以設置斷點。點擊F10可以在斷點以后進行單步運行。F5是運行。操作和微軟系的IDE工具類似，這里不再贅述。開始調試前需要對Run Time Setting進行一些簡單的設置，下面簡單介紹一下。4.3.1 Run Time Setting設置點擊Generator頁面中的“Runtime Setting”（中文版為“運行時設置”）按鈕，可以打開運行時設置頁面。它包括了步（Step）的設置，日志（Log）的設置，思考時間（ThinkingTime）設置，以及其他（Etc）設置。首先來看步的設置。步的設置如圖31中所示即為運行時設置步的設置界面。它包括“迭代計數”的設置和“開始新迭代”的設置。通常我只設置了“迭代計數”，沒有修改過“開始新迭代”的默認設置?！暗嫈怠钡脑O置其實就是腳本Action區(qū)域循環(huán)次數的設置。需要注意的是當設置了“迭代計數”后，腳本運行時只有Action區(qū)域的腳本會參與循環(huán)。還記得在參數化替換中設置參數屬性的“更新值的時間”有一個“Each Iteration”選項。其中的Iteration就是在這里設置的。通常對于調試腳本來說，這里的迭代次數不需要設置得太大。其實在調試腳本的時候設置迭代次數的目的是為了檢驗迭代調試運行時，腳本中的參數以及關聯(lián)函數是否會隨著腳本的迭代而發(fā)生變換，以證明參數替換和動態(tài)關聯(lián)是否成功。所以設置3到5次迭代，以保證能夠看出規(guī)律來就可以了。那么如何才能看得出，每次迭代的過程中究竟參數被替換成什么值了呢？下面簡單說一說日志的設置，就明白了。圖表 31 運行時設置步日志的設置圖表 32 運行時設置日志日志的設置包含了一個日志記錄的開關。當開關打開時，LR會按日志選項的設置記錄腳本運行日志。當日志選項為“僅在出錯時發(fā)送消息”時，LR會自動記錄出錯日志。但是這種選項對腳本的調試來說不太適合，因為如果腳本中的參數替換或動態(tài)關聯(lián)不成功時很有可能不會發(fā)生錯誤。也就不會記錄日志。操作員也就無法從日志得知對腳本的修改是否成功。我一般都選擇“始終發(fā)送消息”，并且采用“擴展日志”方式，打印出參數替換。方便檢查。但是很少要求打印“服務器返回數據”和“高級跟蹤”，除非遇到無法定位的腳本錯誤。因為當要求打印“服務器返回數據”或“高級跟蹤”時 ，由于服務器返回的數據非常多，會導致調試花費時間過長。思考時間的設置圖表 33 運行時設置思考時間在錄制腳本的過程中，測試人員操作的時候多少會有一些停頓或者是延時。有些是無意的，有些可能是有目的的。這些延時在腳本中以lr_think_time()函數表示。括號中輸入正整數，表示延時時長，以秒為單位。思考時間設置就是為了控制這些延時。在思考時間的設置中，可以設置忽略這些思考時間，即不需延時。也可以重播這些延時。并且提供了四種重播的方式：u “按錄制時記錄的時間”是完全按照錄制時的延時來重播。u “將錄制思考時間乘以”方式提供了一個讓用戶定義的系數，重播延時時長由錄制的實際時間乘以這個系數來決定。u “使用錄制思考時間的隨機百分比”提供了Min和Max這兩個下限和上限百分比設置，重播時Generator會從實際錄制時間乘以下限百分比到實際錄制時間乘以上限百分比這個區(qū)間內隨機讀取一個值來作為重播延時的時長。u “將思考時間限制為”直接讓用戶重新定義所有的延時時長，單位為秒。個人認為用得最多的，可能還是忽略思考時間。至少在我遇到的腳本中，大多數的思考時間都不具備什么特別意義的。其他設置其他設置包括了“錯誤處理”、“多線程”、“自動事務”。錯誤處理是只當有錯誤發(fā)生時怎樣處理。我通常會要求出錯后跳過錯誤繼續(xù)往下執(zhí)行。因為有些錯誤是不會影響事務成功通過的。所以沒有必要遇到錯誤就停止運行。對Tuxedo6協(xié)議來說“多線程”只能選擇“按進程運行Vuser”。在4.1.5 插入事務點里面，我解釋了事務這個概念。這里的自動事務是LR自動對事務的創(chuàng)建。在默認情況下“自動事務”中的“將每個Action定義為一個事務”是被選中的。即是說LR默認將整個Action看作一個事務，在運行過程中會自動記錄Action的響應時間。如果不需要關注Action，可以將此處的勾去掉。圖表 34 運行時設置其他 注意：對于不同協(xié)議的腳本，其運行時設置包含的項或可選的項都會有所不同。因此本文中介紹的這方面的內容并不一定適用于其它協(xié)議的運行時設置。4.3.2調試腳本運行時設置完成，就可以開始從Generator中調試腳本了。點擊運行開始的按鈕或者F5，腳本會按照Runtime Setting的設置開始運行，并在輸出窗口打印關鍵日志。當腳本運行完成，沒有錯誤，并且從關鍵日志來看所有參數替換和動態(tài)關聯(lián)都成功的話，證明腳本已經完全通過調試，可以使用了。至此對腳本的研究已經告一段落。 注意：在腳本調試的過程中，所執(zhí)行的腳本都是有效的。比如錄制的是一個增加用戶信息的腳本。當調試腳本的時候，如果調試成功的話，新增用戶信息的操作是會真正加入到數據庫中的,請注意。5運行測試5.1添加虛擬場景讓測試腳本在此運行腳本制作完成，數據文件準備妥當，需要添加一個虛擬場景，在場景中模擬負載，運行腳本。LR的Cotroller用來完成這個功能。5.1.1創(chuàng)建場景在Generator中，創(chuàng)建好腳本后，點擊工具創(chuàng)建Controller方案，可以打開一個新的Controller。從開始菜單也可以打開Controller。圖表 35 打開場景創(chuàng)建系統(tǒng)會彈出一個“新建方案”窗口，如圖36。（從Generator打開和從開始菜單打開有些許不同，大體一樣。這里主要介紹從開始菜單打開的。）可以選擇兩種創(chuàng)建方案的類型。一種是面向目標的方案，一種是手動方案。手動方案又分為按數量分配負載和按比例分配負載兩種。如果選擇了“使用百分比模式在腳本間分配Vuser”那么就會打開按比例分配的場景模式。其實各種模式的選擇取決與測試的目的。手動方案，讓測試人員決定需要加載的負載量，用于在標準負載下測試系統(tǒng)的性能。目標方案，讓測試人員定義一個目標，和添加負載的最小值和最大值。運行時LR會按照用戶給定的負載最小值開始添加，試探系統(tǒng)性能是否能夠達到定義的目標。如果不能達到，就繼續(xù)添加，直到達到目標或者設置的最大值。這種方案對于定位當前系統(tǒng)能夠承受的最大負載量非常有用。圖表 36 創(chuàng)建方案窗口現在來分別介紹兩種方案的具體設置。手動方案在“新建方案”窗口中選擇手動方案（按數量分配負載），從“可用腳本”中選中一個腳本添加到“方案中的腳本”或者通過“瀏覽”按鈕選擇可用的腳本。然后點擊確定打開手動方案（按數量分配負載）頁面，如圖37：圖表 37 手動方案（按數量分配負載）可以看見選擇的可用腳本已經列在了方案組中，默認的“數量”是10個，默認的負載生成器是Localhost。數量是指負載數量，即是虛擬用戶數?？梢愿鶕y試的設計而由操作員更改。負載生成器是指生成這些虛擬用戶的機器。如果添加了多個負載生成器，在方案組中可以從下拉框中為每個組選擇屬于自己的負載生成器。在方案組的右側，有一列控制按鈕：u 開始方案：當所有場景設置完成后，點擊該按鈕可以開始運行。u 生成器：用于負載生成器的添加，點擊后彈出窗口如圖38：圖表 38 負載生成器頁面中所顯示的，表示當前僅有一個負載生成器，是本機Localhost，其狀態(tài)是向下（down，其實就是沒有拉起的意思，這里中文包的翻譯有點生硬），平臺是Windows。若選中該負載生成器，點擊右邊的“連接”按鈕，可以測試該負載生成器是否正?？捎谩Ｈ艨捎?，在連接完成后，狀態(tài)會改為“就緒”，否則顯示為“連接失敗”。點擊添加可以新增負載生成器，點擊刪除，可以刪除選定的負載生成器。當點擊添加時，系統(tǒng)彈出添加窗口：圖表 39 添加新的負載生成器在名稱中填寫指定負載生成器的IP地址，選擇負載身成器的操作系統(tǒng)，點擊確定就可以完成添加。默認情況下“使負載生成器參與方案”是選中的，表示當改生成器添加以后自動加到方案中?？梢愿鶕枰O置為空?！案噙x項”這里不再一一介紹了。詳細信息按鈕可以查看某個負載生成器的具體設置。選中某個負載生成器，點擊禁用按鈕，可以禁用負載生成器。u Vuser：點擊Vuser按鈕，彈出Vuser的監(jiān)控頁面。如圖40：圖表 40 Vuser監(jiān)控頁面 該頁面中可以監(jiān)視各個Vuser的狀態(tài)，所屬的腳本，所屬的負載生成器，和已用時間。并且能夠控制某個或某些Vuser的運行，逐漸停止，停止。還可以在線添加新的虛擬用戶。是在線監(jiān)控虛擬用戶的有效工具。u 添加組：可以理解為添加一個的腳本。點擊該按鈕能夠彈出組添加頁面，如圖41圖表 41 添加組 該頁面中提供了，組命名、Vuser數量定義，負載生成器選擇和腳本選擇。設置完成后，會向方案組列表中增加一條新的記錄。u 刪除組：在方案組列表中選中一條組記錄，點擊刪除組按鈕，能夠刪除該選定組。u 運行時設置：在4.3.1Run Time Setting設置中，介紹過Generator中調試腳本的運行時設置。這里的運行時設置內容和前面介紹的完全一樣。但不同的是，這里設置的運行時設置是控制場景中腳本運行的，而不是用于腳本調試的。u 詳細信息：點擊可查看某選中方案組的詳細配置信息。u 查看腳本：點擊可打開Generator查看某選中方案組所包含的測試腳本。在方案組的上方，有“編輯計劃”的按鈕，點擊彈出編輯計劃窗口，如圖42：圖表 42 計劃生成器生成器中包含“按方案”和“按組”兩種計劃模式。但兩種計劃模式都包含“加壓”，“持續(xù)時間”，“減壓”三個Tab頁?！凹訅骸敝械脑O置，是設置各虛擬用戶運行的次序和方式。一種方式為同時加載所有Vuser；一種方式為指定時間和數量，表示在每隔指定的時間，加載指定的虛擬用戶數?！俺掷m(xù)時間”是所有的虛擬用戶全部加壓后的運行時長設置。其中“運行直到完成”是指當虛擬用戶全部啟動后，讓虛擬用戶運行方案組中腳本在運行時設置里定義好的“迭代次數”直到完成；“運行時間在加壓完成后”是讓測試員自己定義完全加壓后腳本運行的時間，可以驗證系統(tǒng)在完全負載的情況下運行指定時間的性能表；“無限期運行”是讓員工手工控制腳本的停止，否則就一直運行下去?！皽p壓”是指虛擬用戶運行結束退出運行狀態(tài)的方式設置。可以“同時停止”，也可以設置時間和數量，指定每隔多少時間停止多少用戶。但是“減壓”的所有設置項必須要“持續(xù)時間”選擇