Calling a web service to read a csv file in OpenSTA

Here is an example of calling a web service to read a comma separated file into an array for later use. This technique can be used to call user defined functions coded in languages other than SCL. The web service should be running on the machine hosting opensta to minimize overhead.
 

The file can be downloaded from here

Unzip the contents into a directory and launch file_reader_service (and leave it running).

Load script filereader.htp into your repository scripts directory, create a 10 VU test executing a single iteration and run it.

I thank Cory Golberg for providing this feature to OpenSTA.

Script Modelling and capturing the ViewState

After a script is recorded, it must be edited to capture the ViewState value dynamically. The ViewState value may be found in many pages but should only be captured just before a request that needs to use it. This is performed by simply “Addressing a DOM element” which is explained in detail by the Modeller help. How that process relates to ViewState is described here, in summary only.

After recording the script, no changes should be made to the URLs. The Yellow colored arrow icon in the tool-bar of the Script Modeller will populate the Query Pane with content of the server’s response for the selected URL. The “HTML Tree” tab in the query pane displays a tree representation of the Document Object Model (DOM).

Right click on the HTML Node and choose “Search”. In the textbox that appears, enter “VIEWSTATE” (without the quotes) and hit [Return]. Then right click on the VIEWSTATE value:

From the shortcut menu that appears, select “Address” and assign a variable name, for example “TEMP_VS”.

This will automatically insert the necessary code into the script:

LOAD RESPONSE_INFO BODY ON 1 &

INTO TEMP_VS &

,WITH "HTML(0)/BODY(1)/DIV(0)/FORM(0)/INPUT(0):ATTRIBUTE:value(2);

Unfortunately, after capturing the ViewState, simply substituting the string with the new variable in the next request will result in an HTTP 500 error when played back. There is a little more to using the captured ViewState than this, hence the “TEMP” in the chosen variable-name, “TEMP_VS”.

Using the Viewstate

The format of the ViewState is issued to the browser in literal characters. There are numerous encoded values in the ViewState, each delimited by “+”. The server, however, expects to receive the ViewState back with special characters replaced with their ASCII equivalent. The only special character that is observed to be dynamic in the ViewState string is the delimiter “+”, represented in a post body or URL query string as “%2B”.

Thus, before the captured ViewState can be successfully used, each of these “+” symbols that are interspersed in the string must be substituted with “%2B”. This can be reformatted by passing the value obtained by the “LOAD RESPONSE_INFO” command to a subroutine held in an “Include” file.

This subroutine must use the SCL commands “~LOCATE” to find the position of the next “+”:

SET Len = ~LOCATE("+", TEMP_VS)

It is the text prior to that position that is of interest. Using “~EXTRACT”, that section of the ViewState can be copied to another variable, appending “%2B”:

SET VS = VS+~EXTRACT(0,Len,TEMP_VS)+"%2B"

That portion and the “+” is then removed from the temporary ViewState variable:

SET OFFSET = Len+1

SET TEMP_VS = ~EXTRACT(OFFSET,5120,TEMP_VS)

This must all be repeated until the temporary ViewState variable is empty. It is occasionally necessary to substitute trailing “=” symbols.

The VSTATE variable can then be used in the original script, instead of the ViewState string originally recorded:

,BODY"__VIEWSTATE="+VS+"%3D%3D&hdnIncomingURL=username

PDF File Verification in OpenSTA

To begin with, OpenSTA emulates browser traffic, it does not run a real browser. The only evidence you will have that the server has produced the PDF file is that a link to it, a url, will be returned as the result of a get or post. Next, when you click on that link, opensta records the browser fetching the file.

So, when playing back a script, you have to first be sure the file name of the pdf doesn't change... if it does, you need to correlate it. Next you find the GET statement that retrieves the PDF file. Consider either checking the status returned to be sure its 200 or perhaps loading the response (load response_info body on ) and verifying the first few bytes to see if it contains the right text (something like %PDF should appear in the text).

Text Verification script in OpenSTA

Consider that we need to check whether the particular page gets loaded while executing the application under test by OpenSTA..

For the above scenario let us derive a script,

Place the following code below the url where we would like to verify the text,

SET VER_STRING = "Your Search Text goes here"

LOAD RESPONSE_INFO BODY ON 2 INTO VER_BODY

Log VER_BODY

!HTML response body content will be stored in the above variable.

SET VER_LOCATION = ~LOCATE (VER_STRING,VER_BODY), CASE_BLIND
!Location of the string you searched will be stored in the above variable.
SET L2 = ~EXTRACT(VER_LOCATION, 62, VER_BODY)

Log L2

!Text searched for verification will be stored in the above variable.

IF (VER_LOCATION >= 0) THEN

LOG "Verification SUCCES - Page contained the string '", VER_STRING , "'"

ELSE

LOG "Verification FAILED - Page did not contain the string '", VER_STRING , "'"

ENDIF

Note:

2 refers to Connection Id and

62 refers to the length of yor search string.

Parameterization in OpenSTA

Consider the Scenario, parameterizing the Username and Password in Login screen,

1.Record the script

2.Create a dataset for username and password in different notepads and save it with extension .fvr
3.Copy the created files and place it in the Data Folder of OpenSTA installation directory,

Ex:C:\Program Files\OpenSTA\Repository\Data

4.Under the Definition section of the recorded script place the following lines,

CHARACTER*512 fileuser, FILE = "users", SCRIPT

CHARACTER*512 filepassword, FILE = "password", SCRIPT

CHARACTER*100 currentUsername, LOCAL

CHARACTER*100 currentPassword, LOCAL

Note:

users - filename of the file that contains the username

password - filename of the file that contains the password

5.In the script recorded, above the Post url where the login data will be passed, place the following code,

ACQUIRE MUTEX "Logn"

NEXT fileuser

NEXT filepassword

SET currentusername = fileuser

SET currentpassword = filepassword

LOG "User: ", fileuser, " - Password: ", filepassword

LOG "User: ", currentUsername, " - Password: ", currentPassword

RELEASE MUTEX "Logn"

Note:

Make sure you use the mutex, or each thread may not use a distinct value from the list/file.

6.In the Post Url section replace the values passed in login with the variables we have created i.e currentusername for Username and currentpassword for Password.

7.Run the Script, different values will be passed for different iterations from the file created.

Dynamic Cookie Generation in OpenSTA

Cookies can be automatically generated by the feature available in the tool, inorder to activate this feature goto,

Options -> Gateway -> Under the Settings frame, check the Automatic Cookie Generation checkbox.

OpenSTA

OpenSTA - Open Systems Testing Architecture
It is a distributed software testing architecture designed around CORBA, it was originally developed to be commercial software by CYRANO. The current toolset has the capability of performing scripted HTTP and HTTPS heavy load tests with performance measurements from Win32 platforms. However, the architectural design means it could be capable of much more.

Recordings are made in the tester's own browser producing simple scripts that can be edited and controlled with a special high level scripting language. These scripted sessions can then be played back to simulate many users by a high performance load generation engine. Using this methodology a user can generate realistic heavy loads simulating the activity of hundreds to thousands of virtual users.

Results and statistics are collected during test runs by a variety of automatic and user controlled mechanisms. These can include scripted timers, SNMP data, Windows Performance Monitor stats and HTTP results & timings. Much of the data logged can be monitored live during the test runs; once test runs are complete, logs can be viewed, graphed, filtered and exported for use by more sophisticated report generation software.