鎮
代理錄制
看到ie瀏覽器就煩，想用Chrome瀏覽器來錄制腳本，遂選擇代理錄制模式。
在錄制設置里面的代理設置中新增一個代理，輸入目標IP,端口，協議類型，以及loadruunner的端口如8888；
然后在chrome瀏覽器里設置好代理，127.0.0.1 8888；
錄制時在Application type中選擇默認，據我測試，選win32結果一樣；
錄制的項目里選擇LD的bin目錄下的wplus_init_wsock，點擊OK開始錄制。
一開始我用Chrome瀏覽器訪問網頁時錄制沒腳本，后來將谷歌瀏覽器設置為默認瀏覽器后有了腳本。
Recording Options 錄制選項
Script
Scripting Options
1.當VuGen停止錄制時，自動關閉所有活動的應用程序進程
Close all AUT processes when recording stops
2.在每個事務結束后都生成一個固定的思考時間
Generate fixed think time after end transaction
3.描述所有捕獲的事件並生成報告
Generate recorded events log
4.如果用戶超過指定的界限，那么插入用戶思考時間
Generate think time greater than threshold
5.如果一個action錄制的行數超過指定的界限，那么創建一個新的文件
Maximum number of lines in action file
6.如果錄制的一個應用程序的子進程創建為一個COM本地服務器，追蹤它的活動
Track processes created as COM local servers
Protocols
協議列表，在這里列出錄制前所選的協議，圖為Web的HTTP協議。
Recording
有兩種錄制模式，基於HTML的和基於URL的，以打開百度首頁為例，來對比一下：
1、HTML-based script：這種方式錄制的代碼只生成了兩個打開頁面的函數，比較簡潔。
Base_html() { web_add_cookie("BAIDUID=5CA75D7E4804139ED1381595FE964220:FG=1; DOMAIN=www.baidu.com"); web_add_cookie("BIDUPSID=5CA75D7E4804139EE3924BB8D7130653; DOMAIN=www.baidu.com"); web_add_cookie("PSTM=1580452306; DOMAIN=www.baidu.com"); web_url("www.baidu.com", "URL=http://www.baidu.com/", "TargetFrame=", "Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t65.inf", "Mode=HTML", LAST); web_url("百度首頁", "URL=https://www.baidu.com/", "TargetFrame=", "Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t66.inf", "Mode=HTML", LAST); return 0; }
2、URL-based script：這種方式會生成很多函數，它將每個請求都單獨成一個函數，這種方式更接近請求-響應的本質。
Base_url() { web_add_cookie("BAIDUID=5CA75D7E4804139ED1381595FE964220:FG=1; DOMAIN=www.baidu.com"); web_add_cookie("BIDUPSID=5CA75D7E4804139EE3924BB8D7130653; DOMAIN=www.baidu.com"); web_add_cookie("PSTM=1580452306; DOMAIN=www.baidu.com"); web_url("www.baidu.com", "URL=http://www.baidu.com/", "Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t67.inf", "Mode=HTTP", LAST); web_url("百度首頁", "URL=https://www.baidu.com/", "Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t68.inf", "Mode=HTTP", LAST); web_concurrent_start(NULL); web_url("pcpad_e247c0f9a461b6394da20e308588818f.png", "URL=https://www.baidu.com/img/pcpad_e247c0f9a461b6394da20e308588818f.png", "Resource=1", "RecContentType=image/png", "Referer=https://www.baidu.com/", "Snapshot=t69.inf", LAST); web_url("baidu_jgylogo3.gif", "URL=https://www.baidu.com/img/baidu_jgylogo3.gif", "Resource=1", "RecContentType=image/gif", "Referer=https://www.baidu.com/", "Snapshot=t70.inf", LAST); web_url("pcpad_e247c0f9a461b6394da20e308588818f.png_2", "URL=https://www.baidu.com/img/pcpad_e247c0f9a461b6394da20e308588818f.png", "Resource=1", "RecContentType=image/png", "Referer=https://www.baidu.com/", "Snapshot=t71.inf", LAST); web_url("baidu_resultlogo@2.png", "URL=https://www.baidu.com/img/baidu_resultlogo@2.png", "Resource=1", "RecContentType=image/png", "Referer=https://www.baidu.com/", "Snapshot=t73.inf", LAST); web_concurrent_end(NULL); web_url("baidu_jgylogo3.gif_2", "URL=https://www.baidu.com/img/baidu_jgylogo3.gif", "Resource=1", "RecContentType=image/gif", "Referer=https://www.baidu.com/", "Snapshot=t72.inf", LAST); web_url("baidu_resultlogo@2.png_2", "URL=https://www.baidu.com/img/baidu_resultlogo@2.png", "Resource=1", "RecContentType=image/png", "Referer=https://www.baidu.com/", "Snapshot=t74.inf", LAST); return 0; }
注意：
基於瀏覽器的應用程序推薦使用HTML-based Script；
不是基於瀏覽器的應用程序推薦使用URL-based Script；
如果基於瀏覽器的應用程序中包含了JavaScript 並且該腳本向服務器產生了請求，比如DataGrid 的分頁按鈕等，flash等，也要使用URL-based 方式錄制；
基於瀏覽器的應用程序中使用了HTTPS 安全協議，使用URL-based 方式錄制。
在HTML下面也有兩個選項：
1、A script. describing user actions(web_link,web_submit_form)
基於解釋用戶行為的腳本，注重描述用戶做了什么操作，腳本簡潔，基於用戶操作模擬，淺顯易懂，並且自身就包含了對象檢查過程，無需校驗；
2、A script. containing explicit URLs only(web_url,web_submit_data)
基於URL請求的腳本錄制類型，這種方式不考慮用戶的操作，只考慮客戶端發送的請求，注重於實際上系統做了什么。
以系統給的購票網站為例：
第一種在注釋掉第一個web_url函數之后，web_submit_form是無法登錄成功的，里面沒有地址。
第二種即使注釋掉web_url函數，web_submit_data依舊可以登錄，里面有登錄的地址。
總結：
web_submit_form: 上下文相關的，依賴上下文才能提交，比較符合人們的操作習慣。
web_submit_data: 上下文不相關，每個函數都指定了具體的url地址，可以直接提交成功，如果只關注協議，不需要關注頁面，可使用這種方式錄制。
Port Mapping
這里面是設置代理的，上面有涉及。但是有個Capture level選項：
- Socket level data. Capture data using trapping on the socket level only. Port mappings apply in this case (default).
- WinINet level data. Capture data using hooks on the WinINet.dll API used by certain HTTP applications. The most common application that uses these hooks is Internet Explorer. Port mappings are not relevant for this level.
- Socket level and WinINet level data. Captures data using both mechanisms. WinINet level sends information for applications that use WinINet.dll. Socket level sends data only if it determines that it did not originate from WinINet.dll. Port mapping applies to data that did not originate from WinINet.dll.
對這幾個的區別我不太理解，有時用socket錄制腳本時沒有內容的話換第二個或第三個就有了。
Advanced
Reset context for each action：錄制過程中每個action之間是否需要重置context,context中存放請求發送返回后的數據信息，比如服務器返回的html,cookie,session等。
Save snapshot resources locally：在本地保存快照
Generate web_reg_find functions for page titles：是否需要自動為每個標題生成web_reg_find檢查點函數
Generate web_rege_find functions for sub-frames：為子框架也生成檢查點函數
Add comment to script. for HTTP errors while recording：錄制過程中出錯了添加相關的注釋內容
Support charset：編碼規則選項，建議選上，解決中文亂碼情況
Recording Engine：錄制的兼容性選項，可以使用以前的錄制引擎來錄制腳本
Recording schemes：錄制內容的過濾
Headers：對於Headers錄制內容的過濾
Content Types：對於錄制的正文內容進行過濾
Non-Resource：對於非資源的內容進行過濾
Correlation
關聯，勾上Enable就自動關聯了。
Run time setting運行時設置
Run Logic:
在loadrunner的vugen中，action是可以被迭代的,在init和end中也可以插入action，在action中也可以插入塊Block，塊中加入action。
在Properties屬性欄里可以改變Run和Block里的action的執行方式，順序或者指定概率，也可直接雙擊Run或Block或action。
我們跑出的腳本中的行為方式如果跟用戶實際的行為方式不一致，那么基於這個腳本的性能測試的結果將是毫無意義的。比如說某個論壇，我們錄的腳本是登錄論壇首頁，然后去發個帖，然后退出。而實際上用戶的使用行為可能並非如此，用戶可能登錄論壇后先看看自己的個人中心，看看是否有關於自己的動態，再去查看置頂的熱門帖子，再去搜搜自己感興趣的某些內容，然后再發個帖子，最后退出。這就要在LD的運行時設置里面構造運行邏輯了。雖然Properties屬性可以構造一些簡單的運行邏輯，但是復雜些的還是要靠c語言代碼直接實行。
例如下面的邏輯，訪問京東首頁后有的人會是第一次訪問，先去注冊；
有的老客戶先去登錄，再去查找商品，添加購物車，支付；
有的人在沒登錄的情況下先去查找瀏覽，找到滿意的商品后再去登錄，添加購物車，支付。
用c先產生一個1-100之間的隨機數，然后根據隨機數的大小實現概率性的邏輯運行。
腳本如下：
運行結果：
Pacing:
Pacing，定義的是兩個迭代之間的步長。有三個模式：
1、前面的迭代一結束后面的迭代就開始；
2、在前面的迭代結束后，等待一個固定的或者隨機的時間延遲，才開始新的迭代；
3、是指前一次Starting Iteration到下一次Starting Iteration之間的時間，包含了前一次迭代執行的時間。在該模式下，一次迭代執行的時間若大Pacing的時間，則系統會提示無法達到Pacing的時間設置，腳本不做等待立即運行下一次迭代，可以用來驗證下一次迭代的處理時間是否在期望的閥值內。
可以看出第一種選擇對服務器的壓力最大，因為這個選項在單位時間內所做的業務數最多，即單位時間內提交的請求數最多，所以服務器的壓力最大。因此如果進行壓力測試時，可以需要該選項。
補充：
性能需求經常都是這樣定義的： “要求系統支持 100 個並發用戶”。換個角度，“要求系統的事務處理能力達到 100 個 / 秒” ( 這里為了理解的方便，假定在測試腳本中的一個事務僅僅包含一次請求 )，面對以這樣方式提出的性能需求，在 LoadRunner 中，我們又該如何去設置它的並發用戶數呢？千萬不要想當然地以為設置了 100 個並發用戶數，它就會每秒向服務器提交 100 個請求（只限於1次迭代），這是兩個不同的概念，因為 LoadRunner 模擬客戶端向服務器發出請求，必須等待服務器對這個請求做出響應，並且客戶端收到這個響應之后，才會重新發出新的請求，而服務器對請求的處理是需要一個時間的。我們換個說法，對於每個虛擬用戶來說，它對服務器發出請求的頻率將依賴於服務器對這個請求的處理時間。而服務器對請求的處理時間是不可控的，如果我們想要在測試過程中維持一個穩定的每秒請求數（ RPS ），只有一個方法，那就是通過增加並發用戶數的數量來達到這個目的。這個方法看起來似乎沒有什么問題，如果我們在測試場景中只執行一次迭代的話。然而有經驗的朋友都會知道，實際情況並不是這樣，我們通常會對場景設置一個持續運行時間（duration，即多次迭代），通過多個事務 (transaction) 的取樣平均值來保證測試結果的准確性。測試場景以迭代的方式進行，如果不設置步進值的話，那么對於每個虛擬用戶來說，每一個發到服務器的請求得到響應之后，會馬上發送下一次請求。同時，我們知道， LoadRunner 是以客戶端的角度來定義“響應時間”的 ，當客戶端請求發出去后， LoadRunner 就開始計算響應時間，一直到它收到服務器端的響應。這個時候問題就產生了：如果此時的服務器端的排隊隊列已滿，服務器資源正處於忙碌的狀態，那么該請求會駐留在服務器的線程中，換句話說，這個新產生的請求並不會對服務器端產生真正的負載，但很遺憾的是，該請求的計時器已經啟動了，因此我們很容易就可以預見到，這個請求的響應時間會變得很長，甚至可能長到使得該請求由於超時而失敗。等到測試結束后，我們查看一下結果，就會發現這樣一個很不幸的現象：事務平均響應時間很長，最小響應時間與最大響應時間的差距很大，而這個時候的平均響應時間，其實也就失去了它應有的意義。也就是說，由於客戶端發送的請求太快而導致影響了實際的測量結果。因此，為了解決這個問題，我們可以在每兩個請求之間插入一個間隔時間，這將會降低單個用戶啟動請求的速度。間歇會減少請求在線程中駐留的時間，從而提供更符合現實的響應時間。這就是 Pacing 這個值的作用。
Log:
主要用於設置腳本回放時的日志格式。LR一共包括4類日志文件，即
replay log（回放日志）：是腳本回放時lr記錄的日志信息，包括客戶端與服務器之間的通信日志和HTML源碼錄制時的快照信息，但該日志信息的內容取決於log選項卡中extended log選項的設置情況。
recording log（錄制日志）：是錄制腳本時產生的日志，主要是客戶端和服務器端通信時的一些交互信息。
correlation results（關聯結果）：是當腳本需要關聯時，在回放腳本過程中會記錄錄制和回放時需要關聯內容的值。
generation log（生成日志）：腳本生成時產生的日志。
Enable Logging:是否啟動日志功能 ，即在場景運行過程中是否收集日志信息。
Log message at the detail level of 日志的詳細內容：
Additional attributes:
添加一些不是系統本來就有的屬性參數，可以獲得不同客戶端的值。
Think Time:
用來設置用戶操作的思考時間（思考時間是指每個HTTP請求之間的時間間隔）
ignore think time：運行腳本時忽略思考時間，即上一個HTTP請求結束后，直接運行下一下HTTP請求，不等待。
replay think time：設置腳本回放時思考時間，包括as recorded、multiply record think time by 和use random percentage of recorded think time三種方式。
as recorded：按錄制時的思考時間來回放，即如果錄制時間思考時間為9s，那么回放時也按9s來計算（如圖6所示）：
multiply record think time by ：根據錄制時思考時間的整數倍來運行（如圖7所示）：
use random percentage of recorded think time：分別設置一個最大值和一個最小值，並從中選出一個隨機值，在實際使用過程中一般會選擇這種模式，設置最小值為50%，最大值為150%（如圖8）：
limit think time to：設置think time的最大值。如果上面的設置項，在回放時使用的思考時間超過所限制的時間，那么以該限制時間為准進行回放（如圖9所示）：
綜合上面的情況，設置為忽略思考時間時，對服務器的壓力最大，因為在同樣的場景執行時間內，HTTP請求之間的時間縮短說明向服務器提交的請求數增多了，所以服務器的壓力增加，如果進行壓力測試時，可以選擇該項設置。
思考時間的設置，多大為宜？
抽樣，獲取100個人的think time 時間分布，去掉最高值和最低值，對留下的80%核心數據做平均，比如得到的結果是3.8，那么取比3.8小一些的數據來作為腳本的思考時間，如3.5。思考時間越小則在某種程度上對服務器造成的壓力就越大，測試時大的壓力都扛得住，那么生產環境里的實際壓力也應該沒問題。但也不能過小，如2.5。過壓也沒有意義，浪費資源浪費錢。
Miscellaneous混合項:
是一個混合項，包括3個設置項：
Error Handing （表示腳本運行出現錯誤時所采取的措施，默認使用缺省值）：
continue on error:即使遇到錯誤也繼續執行腳本.
Fail open transactions on lr_error_message: 當lr_error_message這個函數被transaction內部的腳本調用的時候,無法打開所有的transaction
Generate snapshot on error:當遇到error的時候就自動產生快照.
Multithreading （表示運行時把虛擬用戶當作進程還是線程來處理）：
Automatic Transactions（設置事務的模式）:
Speed Simulation 帶寬模擬 :
Browser Emulation瀏覽器仿真:
User-Agent中默認是win7的內核。可以更改。
Simulate browser cache:配置Vuser模擬帶緩存的瀏覽器。缺省緩存是被允許的，可以通過禁止該選項來使得所有VUser模擬的瀏覽器都不帶緩存。
Cache URLs requiring content(HTMLs):設置瀏覽器緩存URL的上下文(比如，HTML語法，認證或校驗等)，其他的URL的上下文不會被緩存，以減少內存使用。可以通過點擊Advance來定義需要上下文的URLs。
Check for newer versions of stored pages every visit to the page:通過在header中添加If-Modified-Sinces屬性來設置瀏覽器檢查緩存中的資源是否是最新的頁面資源。缺省情況下，瀏覽器不會自動檢測。
Simulate a new user on each iteraton:設置VuGen在每個迭代的init會話結束時，刪除所有的cookie。這樣使得Vuse更加真實的模擬一個新user開始一個瀏覽會話。迭代的過程是指一個操作的完整流程，新的一次迭代就是一個新的用戶在新的電腦上重新做一次業務。
Clear cache on each iteration：迭代后清空緩存。當每次迭代模擬一個最新訪問站點的user時，則要選中該選項。當每一個迭代模擬一個最近訪問過站點的user，瀏覽器仍為該用戶保留網頁（從前面的迭代中使用緩存頁面）的情況則不要選中該選項。
例如，訪問如下網頁兩次，因為有緩存，第二次很多東西就不下載了，直接在緩存里面取：
回放日志：
關閉緩存后，所有頁面上的資源都要下載兩次：
迭代緩存關閉：
迭代緩存開啟：
問題：登錄和退出是放在init和end里面還是run里面呢？
假如對應的是在京東買東西的業務，登錄和退出放在init和end里面多次迭代加上100個並發，則100個人同時在京東上買買買，買完電視買冰箱，買完冰箱買空調，然后退出。若放在run里面，每個用戶買完電視后退出再登錄買冰箱再退出登錄買空調，有這種情況嗎？難道是幫別人買？所以我覺得還是要放在init和end里面。
Proxy代理：
No proxy（direct connection to the Internet）：所有的Vusers不使用代理，直接方式連接到互聯網。
Obtain the proxy setting from the default browser:所有的Vusers使用機器上運行的瀏覽器的缺省代理設置。該選項為缺省選項。
Use custom proxy:所有Vusers使用自己設置的代理方式連接到互聯網。
Preferences首選項：
Enable Image and text check：允許Vuser執行期間通過執行web_find和web_image_check函數來做檢查。該選項僅適用於Html類型的腳本。另外，使用該選項會使用更多的內存。因此，系統默認該項是不選的。
Hits Per Second and HTTP Codes：該選項用來顯示每秒點擊率以及每秒HTTP相應圖。選中后，可以在場景運行的時候動態看到該圖，也可以在Analysis分析中看到該圖。
Pages Per Second（Html Mode Only）：選擇該項后，可以產生每秒頁面圖，可以在場景運行或者在Analysisi中看到該圖。
Response Byte per Second：選擇該項后，可以產生每秒接收字節圖，可以在場景運行或者在Analysisi中看到該圖。
Winlnet Replay Instead of Sockets（Windows only）：僅僅用於Windows操作系統，選中該項后，使用Wininet Replay 引擎。注意：該選項在Socket Replay引擎失敗后才可以使用。
File and Line in Automatic Transcation names：用文件名和行號給自動化的Transction命名，該選項默認是選中的，注意該項選中會使用更多的內存。
Non-critical Resource Errors As Warnings：當非關鍵性的Fail發生時返回Warning。例如：頁面非關鍵的圖片沒有顯示，或者某個非關鍵的JavaScript沒有運行。該選項默認是選中的。
Save Snapshot Resources Locally：本地保存場景的運行狀況。該選項可以使用戶更快更精確的看到場景運行狀況。
Options：
響應超時也沒必要改這個時間，沒意義：
其他的一些東西沒必要動它。
DNS Catching：保存DNS的IP地址。
Http Version：表明你的程序使用的Http版本。
Keep Alive Http Connections：允許長期保存Http連接，這樣可以使多個需求通過相同的TCP連接。
Step Timeout Caused by Resources is a Warning：對於資源申請超時發布Warning而不是Error。
Parse HTMLContent－Type：對於HTML，當反饋內容是text/html（HTML），’text/’(TEXT)或者Content-type（ANY）時才進行解析。注意：text/xml不會被解析為XML類型。
Accept Server-Side Compression: 表明回放的時候Server端可以接收壓縮數據的情況。注意，接收壓縮數據會引起額外的開銷。
Accept-Language request header: 可以接受語言,以逗號分隔。
HTTP –Request Connect Timeout（Sec）：對HTTP要求的連接操作時間限制，或者連接失敗的時間限制。
HTTP –Request Receive Timeout（Sec）：對HTTP要求的接收時間限制，或者失敗時間限制。
Step download timeout(sec)：一個完成的Script功能的完成時間限制，或者失敗時間限制。
Network buffet size：Vuser可以使用的最大網絡buffer大小，默認為12288。
Fixed think time upop authentication retry(mesc)：模仿用戶輸入用戶名和密碼的時間。注意，這個作為事務時間的一部分。
Request Zlib Headers：當送到Server的需求數據是壓縮的時，包含Zlib壓縮庫的頭部。
Max Number of <META Refresh> to the same page：同一個頁面可以打開的個數。
GUI-Mode default block size for DOM memory allocations：默認的DOM Blocak內存分配大小，太小會出現一些額外的內存調用失敗以及操作，太大會造成內存浪費。
GUI-Mode single setTimeout/setInterval thresh hold：超過了SetTimeout設置的值，SetInterval的設置無效。該設置模擬了用戶在等待超過一定時間后會點擊下一個元素。
GUI-Mode Accumulative setTimeout/setInterval threshold：超過了SetTimeout設置的值，忽略SetInterval。
GUI-Mode fail on javascript error：對於Javacript的錯誤，如果選擇Yes，提交一個Fail；如果選擇No，提交一個Warning。
GUI-Mode History Support：是否支持歷史記錄。如果選擇Auto，則僅僅記錄第一次循環的情況。
GUI-Mode Maximum history size：最到可以保存在歷史記錄中的步驟。
Download Filters：
如果選擇Include Only Addresses In List， 表示重放只能限制在列出的WebSite或者是hosts中。
Exclude Address in lists：重放地址要排除列出的Website或者是hosts。 有些頁面中存在一些響應時間很長的鏈接如外網的，可以把它過濾掉。
ContentCheck：
Enable ContentCheck During Replay：選擇該項可以是用戶得到Web Server發送回的Error。
參數化
單參
假設一個dat文件中有多列值，Select column中設置取值的標識：
by number是按第一列、第二列、第三列的方式取列值；
by name是按列名取值。
File format中column定義分列方式，是按逗號，tab還是空格；First data定義取值從列表的第幾行開始取值，默認是第一行。
與參數取值方式相關的設置有兩個：
1、Select next row：
（1）Sequential：按照順序一行行的讀取。每一個虛擬用戶都會按照相同的順序讀取；
（2）Random：在每次迭代里隨機的讀取一個，但是在迭代中一直保持不變；
（3）Unique ：每個VU取唯一的值。
2、Update value on：
（1）once ：在所有的反復中都使用同一個值；
（2）eachiteration ：每次反復都要取新值；
（3）eachoccurrence ：則只要發現該參數就要重新取值，即如果一個action中有多個該參數，每遇到一個就要重新取一個值。
組合方式如下：
Sequential + Each iteration：每迭代一次取一行值；當所有的值取完后，再從第一行開始取。
Sequential + Each occurrence：每調用一次取一行值；當所有的值取完后，再從第一行開始取。
Sequential + once：每次調用都是同一個值，即設置的第一個取值。
Random+Each iteration：每次迭代隨機選擇一行數據進行賦值。
Random + Each occurrence：每次調用隨機選擇一行數據進行賦值。
Random + once：第一次迭代時隨機取一行數據，后面每次都用第一次的數據。
問題：
1、把lr_eval_string函數放在init和end里面，action里面為空，迭代一次的最后取值是多少？
2、腳本加for循環，迭代里嵌套塊，參數屬性里選擇順序和每次調用，則最后一次取值是多少？
不用多想，是丁，被4整除啦！
現在來個最簡單的情況，放在場景里面跑，10個虛擬用戶，運行模式換成basic：
10個pass，打開log，十個日志，每個里面都是甲乙丙丁甲：
Unique實際上是壓力測試中更為常用的設置。如果選擇unique的設置，每個數據只會用一次，當調用的次數或迭代次數超過值的個數時就可能會報錯。
下方的when out of value可以選擇當數值個數不夠的情況系統改如何取值。
（1）abort Vuser：停止測試
（2）continue in a cyclic manner：循環取值
（3）continue with last value：沿用最后一個值
唯一取值是以用戶為基礎的，希望用戶之間是唯一的。
在Vuser中參數取值在壓力測試中是不同的，以下簡單列舉常用的2個壓力類型：
（1）50個用戶壓力測試，要求測試時間內，用戶登錄的賬號沒有重復：
取值選擇unique，each interaction；由於需要全部為不重復賬號，一定要保證參數化文件中的賬號充足，或者設置好合理的缺值處理方式。
（2）50個用戶壓力測試，且要求每個用戶用一個固定賬號，在整個測試周期中，各個用戶之間的賬號不重復：
取值選擇unique，once；每個用戶用一個賬號，一定要保證參數化文件中的賬號大於50個。
注：要用於壓力測試的場景中的腳本的用戶賬號等信息使用each interaction的情況更為普遍，賬號信息很少會使用each occurrence。測試中需要每個虛擬用戶都不同的情況就需要用到unique，其他兩種取值方式（順序、隨機）都可能出現重復。
跑場景：
1、跟上面一樣，10個用戶，basic，不過這里用的是Unique+Each iteration+取最后值：
10個都報錯了：
看日志，只有一個，里面甲乙丙丁丁，有個錯誤：
2、Unique+once：
3、Unique + occurrence，每個用戶只能用兩個值：
24個錯誤，前兩個用戶每個8個共16個，后面8個用戶直接報錯，共24個。
多參
如下，參數aaa和bbb共用一個文件，分為兩列，逗號隔開，取值可以按列號也可以按列名，行值的變化可以選擇aaa跟bbb一樣，這樣如果bbb隨機變化，aaa也會跟隨它取同一行的值，兩者對應起來了。
這樣在登錄的測試中用戶名和密碼就對應起來了。
至於如何生成參數中的值，可以用excel表格cvs格式的文件，復制到參數文本中，也可以使用c語言腳本生產數據或者使用數據源Data Wizard.
另外，參數與變量之間的轉化，基本的幾個函數要會用：
