| || |
We are having a problem loading more than one VU in a script, unless we are using iterations. Is there anyway we can script this to not use iterations? BTW: the documentation really is not inclusive on variables, its rather vague imo.
Please try this -
- Create a New Test.
- Drag your script under a task group.
- Now click the VU(virtual user) cell.
- Now an interface appears beneath the Configuration tab where you can set the number of Virtual Users you want.
Open STA allows you to create more than one VU without actually scripting it . There is a option in the Test setup where you can setup the number of different VU that will run the sript.
If you give more specifications on what exactly it is you are trying to achieve I will be able to help you.
To put it in the box first think out of the box
To put it in the box first think out of the box
Follow as devendra had said ,
you might also be interested in assigning different username and password to each user,
for that you can refer to scl reference guide or
Create a Variable
Note: For more information on creating variables see Variables.
Open a Script, then select Variable > Create.
Shortcut: Click in the Variable Toolbar.
In the Variable Creation dialog box, enter a name for your new variable. In this example the name is USERNAME.
Note: The name you give must be a OpenSTA Datanames.
Select the Scope of your variable. In this example the selection is Script. Click and choose from:
Local: Only accessible to the Virtual User running the current Script.
Script: Accessible to any Virtual User running the current Script.
Thread: Accessible to any Script run by a specific Virtual User.
Global: Accessible to any Script and any Virtual User.
Note: The scope of a variable relates to which Virtual Users and Scripts can make use of the variables you create.
Select the Value Source of your variable. In this example the selection is Value List. Click and choose from:
Value list: Enter your own variable values.
File: Use existing variable values from file.
Database: Use existing variable values stored on a database.
Select the order in which the variable values are selected when a Test is run. In this example the selection is Sequential. Choose from:
Sequential: Assigns variable values will be consecutively from your value list.
Random: Assigns variable values randomly from your value list.
Select the data types of the variable. In this example the selection is Character. Choose from:
Character: Text variable.
Integer: Numeric variable.
Click Next when you have made your selections.
In the Value List dialog box you need to enter the variable values, or names that will represent the Virtual Users you need when the Test is run. In this example there are five values or user names entered manually within the Value List dialog box, as described below.
You can enter the variable values you need freehand, by double-clicking inside the Value text box or click the , and enter your variable value.
Or, click Generate Values to automate the process. In the generation Parameters dialog box, give your values a prefix, then specify the number of Virtual Users you want by entering a number range in the From and To text boxes. The Step function controls
Note: If you select File or Database as your Value Source, clicking Generate Values takes you to different dialog boxes from where you can locate your value sources.
After you have created your variable values, click OK to return to the Value List dialog box and use the Value List toolbar buttons to manipulate your entries.
Click on a value in the list, click to delete it, click to move the item up the list and click to move the item down.
Click Finish when the setup process is complete.
Repeat this process to create the PASSWORD variable, which your five Virtual Users will need in order to access the Which US President? WAE.
Note: This WAE requires a password to be the reverse spelling of the login name.
The variables you have created are represented as text strings within the Definitions section of the Script, as illustrated below:
CHARACTER*512 USERNAME ( "phillip", "allan", "david" &
, "robert", "donna" ), SCRIPT
CHARACTER*512 PASSWORD ( "pillihp", "nalla", "divad" &
, "trebor", "annod" ), SCRIPT
The variables are now ready to be substituted for the original login identity recorded in the Script. But before you can do so you must apply MUTEX locking SCL code to ensure there are no sharing violations between Virtual Users during a Test-run.
Select Capture > Syntax Check or click , in the Capture/Replay Toolbar, to compile the Script.
Compilation results are reported in the Output Pane. If compilation is unsuccessful, you may need to re-model to resolve the problem.
It is a good idea to replay the Script to check the activity you have recorded before you incorporate it into a Test.
Select Capture > Replay or click , in the Capture/Replay Toolbar. The replay activity is displayed in the Output Pane.
Click , to save the Script, or click File > Save.
A good workman is known by his tools.
If the only tool you have is a hammer, you tend to see every problem as a nail.
What I was talking about was having individual logins and passwords, as well as individual tasks for each user to run. I must say now we figured it out. The whole problem was gettting the Session ID as well as the guid from the proper source. To be usable more than once. We tested this on two different servers and all went well. Thank you though for your input. We checked Test-Wide Mutex. btw. -thanks
[This message has been edited by Sparta1966 (edited 12-11-2002).]