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