Scripting form consists of 7 tabs and a menu bar.
Menu bar has 2 options:
• File -> Exit – closes the Scripting form
• Configuration -> open – Opens configuration
Configuration
In configuration there are 3 textbox fields showing paths to Grinder folder, Grinder analyzer plugin and Jython folder on computer. At end of each textbox there is a button that opens a dialog form for specifying the current location of each of these folders. Configuration has 2 additional buttons. Button “Save configuration” saves the current configuration to conf.xml file in GrinderParser folder and the “Exit configuration” button returns to form’s “Scripting” main view. The configuration can also be modified directly from xml file, taken no xml tags are modified. In this case restart of “Scripting” form is required.
The main view of scripting form consists of 7 tabs:
Recording
Recording tab is used for recording scripts using Grinder recorder. Recorder is called by pressing “Record” button. The name of the script can be modified before recording in “Script name” textbox. The script itself will be saved in Grinder main folder (this is taken from configuration). After Recorder is called, all console information is redirected to console element under “Record” button. Remember that in order to record, proxy has to configured!
After Grinder recorder has been stopped, a popup message box, prompting, if user wants to open the recorded script. The default program for opening *.py files is used. At the beginning of each recording console is cleaned of any text.
Cleanup
This tab is used for cleaning up all unnecessary lines in script. If the line is contained in a request, the whole request will be removed from script, unless it is the first request in page definition. Also, if the request response is being used by another function, for example, returning full request, it will not be removed. This tab might not function properly if merging has been performed beforehand. If it’s necessary to both perform cleanup and merge script, use functionality provided in merging tab.
For cleanup only selected checkboxes will be used.
Checkbox
Explanation
.jpg
Removes all requests that return jpg images
.jpeg
Removes all requests that return jpeg images
.gif
Removes all requests that return gif images
.png
Removes all requests that return png images
.css
Removes all requests that return css design files
.js
Removes all requests that return javascript files
gzip
Removes all lines that allow gzip encoded responses to be returned.
grinder.sleep
Removes all sleep timers from script (for example - grinder.sleep(100))
.swf
Removes all requests that return swf flash files
Merge
Merge is used for organizing request calls into transactions by merging them and writing entirely new page call definitions. Names of new definitions are taken from comments in script files from request definition part.
Comment is recognized as new definition tag if it starts with symbols “# S”, for example “# S01_Start”. In this case new page definition will be called S01_Start. Page names should not contain spaces and apostrophes or anything else that would cause the script to have invalid syntax. The tag is placed right above the first request of the new definition. The form contains input field for script that has tags already set and output field for the merged script. Both of these fields have buttons for picking file.
The definition merging is started by pressing “Merge” button. Please note the “Include cleanup” checkbox. This means that with the merging, cleanup will be performed - all functions (with exception of the ones in resources.txt file) will be removed as well as requests containing file extensions in resources.txt files last 2 defs. By default these extensions are:
• .jpg
• .jpeg
• .gif
• .png
• .css
• .js
• .swf
• .ico
• gzip (removes gzip coding from acceptable return list)
For more details see resources.txt file.
Get responses
This tab is used for getting request responses. It is strongly recommended that cleanup has been performed to script before, so responses would not contain images, since responses are returned in form of a text file. Inputs script must be provided, output script is only used if “Get responses only” checkbox is unchecked. In that case a script is generated, that would return responses from all requests every time it’s run. If the checkbox is checked, then temporary script is generated and executed in background. After execution, the temporary script is deleted and the response file is opened with default .txt file editor. The response file is located in grinders log directory. This can only be changed in resources.txt file in ReqToFile and PrintDefName definitions as %filepath% variable. Another option is to edit generated output script.
Validation
Validation tab is used to edit script, so it would check if the specified requests are returning responses that contain a specified string. If it is found, a success message is printed in console window, if not, an error message is printed in console and the failed response is added to failed responses file in grinders log directory, named Failed_req.txt. File name can be edited in resources.txt file or in output script.
Input and output script paths must be provided. Load from file is an option used to load request name and specified search string combinations directly to forms data grid. This is optional. The file would be read line by line. Each line should have this syntax:
RequestName$ResponseString. An example of the file would look something like this:
And so on. The data grid can also be edited manually. Please note that both request name and search string is mandatory and in case of 2 identical request names only the first search string will be used. “Write exceptions” button will generate script that has the specified requests modified. “Clear DataGrid” button will remove all data from data grid.
Randomize
This tab will add functions to given script that will provide it with randomized or parameterised inputs for script request calls. It is recommended not to add the same functions multiple times, as it does no cleanup to script and causing conflicts between the multiple functions that has the same name
Random int generation
This checkbox adds getrint function. It generates a random int number with 2 input parameters – the minimum and maximum value for the number and gives that random number as output, for example:
self.getrint(50,100)
This function would return a random number from 50 to 100, including 50 and 100. Since it is not a global function, but a function in TestRunner class, it must refer to instance of this class with self. directive.
Random string generation
This checkbox adds getrstring function that returns a random string when called. This function has one input parameter – length of the string. The resulting string contains both upper case and lower case chars as well as numbers. Here is an example of this function:
self.getrstring(10)
This would return a random string, that’s length is 10 characters, for example something like HFgpCELXQO, QJQ6LpbhB0 or daFeDQOIhX. Since it is not a global function, but a function in TestRunner class, it must refer to instance of this class with self. directive.
Parameter extraction from string
This checkbox adds findparam function to script that would extract a parameter from given string, usually a response from request. This function has 4 input parameters
• The string where parameter will be looked for
• A string that would show where parameter region starts
• A string that would shot where parameter region ends
• The occurrence number of the parameter
For example, if we would get response from request101 that would look like this:
<string>this is not what I am looking for<\string>
<string>but this is what I am looking for<\string>
In order to get the second string the function call would look like this:
Since it is not a global function, but a function in TestRunner class, it must refer to instance of this class with self. directive.
Use file content as an array
This check-box adds up to 5 string arrays that can be used while executing script. The array names are combination of files name and Matrix, so the arrays would not conflict between each other. Therefor it is recommended not to use a single file multiple times or files with the same name.
Test script
This tab is a simplified version of Execution form designed to quickly test any grinder script. It consists of input field for source script (it can also be selected using (…) button at end of the textbox), “Test script” button for executing the script provided, a read-only console window where all messages from grinder will be posted and a “Stop” button. Button “Test script” becomes inactive while a script is running while, in the meantime, “Stop” button becomes active. Each time a new script is run, the console is cleared.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Scripting
Scripting form consists of 7 tabs and a menu bar.
Menu bar has 2 options:
• File -> Exit – closes the Scripting form
• Configuration -> open – Opens configuration
Configuration
In configuration there are 3 textbox fields showing paths to Grinder folder, Grinder analyzer plugin and Jython folder on computer. At end of each textbox there is a button that opens a dialog form for specifying the current location of each of these folders. Configuration has 2 additional buttons. Button “Save configuration” saves the current configuration to conf.xml file in GrinderParser folder and the “Exit configuration” button returns to form’s “Scripting” main view. The configuration can also be modified directly from xml file, taken no xml tags are modified. In this case restart of “Scripting” form is required.
The main view of scripting form consists of 7 tabs:
Recording
Recording tab is used for recording scripts using Grinder recorder. Recorder is called by pressing “Record” button. The name of the script can be modified before recording in “Script name” textbox. The script itself will be saved in Grinder main folder (this is taken from configuration). After Recorder is called, all console information is redirected to console element under “Record” button. Remember that in order to record, proxy has to configured!
After Grinder recorder has been stopped, a popup message box, prompting, if user wants to open the recorded script. The default program for opening *.py files is used. At the beginning of each recording console is cleaned of any text.
Cleanup
This tab is used for cleaning up all unnecessary lines in script. If the line is contained in a request, the whole request will be removed from script, unless it is the first request in page definition. Also, if the request response is being used by another function, for example, returning full request, it will not be removed. This tab might not function properly if merging has been performed beforehand. If it’s necessary to both perform cleanup and merge script, use functionality provided in merging tab.
For cleanup only selected checkboxes will be used.
Merge
Merge is used for organizing request calls into transactions by merging them and writing entirely new page call definitions. Names of new definitions are taken from comments in script files from request definition part.
Comment is recognized as new definition tag if it starts with symbols “# S”, for example “# S01_Start”. In this case new page definition will be called S01_Start. Page names should not contain spaces and apostrophes or anything else that would cause the script to have invalid syntax. The tag is placed right above the first request of the new definition. The form contains input field for script that has tags already set and output field for the merged script. Both of these fields have buttons for picking file.
The definition merging is started by pressing “Merge” button. Please note the “Include cleanup” checkbox. This means that with the merging, cleanup will be performed - all functions (with exception of the ones in resources.txt file) will be removed as well as requests containing file extensions in resources.txt files last 2 defs. By default these extensions are:
• .jpg
• .jpeg
• .gif
• .png
• .css
• .js
• .swf
• .ico
• gzip (removes gzip coding from acceptable return list)
For more details see resources.txt file.
Get responses
This tab is used for getting request responses. It is strongly recommended that cleanup has been performed to script before, so responses would not contain images, since responses are returned in form of a text file. Inputs script must be provided, output script is only used if “Get responses only” checkbox is unchecked. In that case a script is generated, that would return responses from all requests every time it’s run. If the checkbox is checked, then temporary script is generated and executed in background. After execution, the temporary script is deleted and the response file is opened with default .txt file editor. The response file is located in grinders log directory. This can only be changed in resources.txt file in ReqToFile and PrintDefName definitions as %filepath% variable. Another option is to edit generated output script.
Validation
Validation tab is used to edit script, so it would check if the specified requests are returning responses that contain a specified string. If it is found, a success message is printed in console window, if not, an error message is printed in console and the failed response is added to failed responses file in grinders log directory, named Failed_req.txt. File name can be edited in resources.txt file or in output script.
Input and output script paths must be provided. Load from file is an option used to load request name and specified search string combinations directly to forms data grid. This is optional. The file would be read line by line. Each line should have this syntax:
RequestName$ResponseString. An example of the file would look something like this:
And so on. The data grid can also be edited manually. Please note that both request name and search string is mandatory and in case of 2 identical request names only the first search string will be used. “Write exceptions” button will generate script that has the specified requests modified. “Clear DataGrid” button will remove all data from data grid.
Randomize
This tab will add functions to given script that will provide it with randomized or parameterised inputs for script request calls. It is recommended not to add the same functions multiple times, as it does no cleanup to script and causing conflicts between the multiple functions that has the same name
Random int generation
This checkbox adds getrint function. It generates a random int number with 2 input parameters – the minimum and maximum value for the number and gives that random number as output, for example:
This function would return a random number from 50 to 100, including 50 and 100. Since it is not a global function, but a function in TestRunner class, it must refer to instance of this class with self. directive.
Random string generation
This checkbox adds getrstring function that returns a random string when called. This function has one input parameter – length of the string. The resulting string contains both upper case and lower case chars as well as numbers. Here is an example of this function:
This would return a random string, that’s length is 10 characters, for example something like HFgpCELXQO, QJQ6LpbhB0 or daFeDQOIhX. Since it is not a global function, but a function in TestRunner class, it must refer to instance of this class with self. directive.
Parameter extraction from string
This checkbox adds findparam function to script that would extract a parameter from given string, usually a response from request. This function has 4 input parameters
• The string where parameter will be looked for
• A string that would show where parameter region starts
• A string that would shot where parameter region ends
• The occurrence number of the parameter
For example, if we would get response from request101 that would look like this:
In order to get the second string the function call would look like this:
Since it is not a global function, but a function in TestRunner class, it must refer to instance of this class with self. directive.
Use file content as an array
This check-box adds up to 5 string arrays that can be used while executing script. The array names are combination of files name and Matrix, so the arrays would not conflict between each other. Therefor it is recommended not to use a single file multiple times or files with the same name.
Test script
This tab is a simplified version of Execution form designed to quickly test any grinder script. It consists of input field for source script (it can also be selected using (…) button at end of the textbox), “Test script” button for executing the script provided, a read-only console window where all messages from grinder will be posted and a “Stop” button. Button “Test script” becomes inactive while a script is running while, in the meantime, “Stop” button becomes active. Each time a new script is run, the console is cleared.