How to capture the ID in URL and correlate using OpenSTA

In webapplications, session id or some user id will be encoded in urls like, http://localhost/login.jsp;jsessionid=25698FG34. In this example 25698FG34 is the session identifier.Mainly these sessionids can be found in two ways,they are as follows

1.Cookie

2.HTML body

Inorder to retrieve the sessionid from cookie use the following code,

Load Response_Info Header on 4 Into VAR_UID ,WITH "Set-Cookie,UID"

Inorder to retrieve the sessionid from html body use the following code,

LOAD RESPONSE_INFO BODY ON 5 INTO VAR_SID ,WITH  "HTML(0)/BODY(1)/FORM(2)/TABLE(4)/TBODY(0)/TR(0)/TD(0)/A(0):ATTRIBUTE:onclick(0)"
 SET VAR_STRLEN = ~LENGTH(VAR_SID)
 SET VAR_STRLEN = VAR_STRLEN - 2
 SET VAR_SID = ~LEFTSTR(VAR_STRLEN, VAR_SID)
 SET VAR_SEPPOS = ~LOCATE("','", VAR_SID)
 SET VAR_SEPPOS = VAR_SEPPOS + 3
 SET VAR_STRLEN = ~LENGTH(VAR_SID)
 SET VAR_STRLEN = VAR_STRLEN - VAR_SEPPOS
 SET VAR_SID = ~RIGHTSTR(VAR_STRLEN, VAR_SID)

Once the desired ID has been obtained, it can be concatenated into applicable URLs as shown below:

"http://localhost/login.jsp;jsessionid=" + VAR_SID

Distributed Testing in OpenSTA

Distributed testing is nothing but playing back of scripts with more than one machine.

To setup for the method of distributed testing do the following:
1. Select 1 machine that will be the master on which you will develop the tests and Run: this will be your RepositoryHost and the other machines will be the slave load generating machines.
2. On EACH of your slave machines, configure the OpenSTA Name Server by right clicking on the name server icon in the task bar and selecting Configure. Set the 'Repository Host' to the IP/Name of your master(RepositoryHost).
3. On the master(RepositoryHost) machine, create a test. Add your script to the Task group. Set the 'Host' to the IP of one of your slave machines. Set the VU to the load you want that slave to generate. Set the 'Start' to a scheduled time.
4. Now right-click on the task you've added and select 'Duplicate Task Group'. Set the 'Host in the duplicated task to another slave's IP. Optionally, you can modify the load.
5. Repeat Step 4 for all the slaves.

STOP - SEE - SUGGEST

Hello visitors,its time to get a feedback for my work,post your valuable susggestions for improving my blog

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.

Oracle Performance Monitoring in Windows

Here we will discuss about the procedure of monitoring oracle using windows perfmon.By using perfmon, you can collect Oracle data as well as OS data that might be important to your overall performance monitoring plan. By consolidating your data collection, you will find it easier to analyze data.

The Oracle Counters for Windows Performance Monitor package is not installed by default. In order to install them when you install Oracle, select the custom install option. You can also install this option later via the Oracle installer. Select custom installation and select the Oracle for Windows Performance option under Oracle Windows Interfaces. This will install this package.

Once Oracle Counters has been installed into the Windows Perfmon, you must perform one more piece of setup. The Oracle performance counters are set up to monitor one Oracle instance. Information about this instance must be configured in the registry. In order to do this, from a command prompt run orafcfg.exe with a username, password and Oracle net service name as follows:

operfcfg –U system –P password –D orcl

This will update the registry. You should now be able to monitor Oracle via perfmon. Some of the things that you can monitor are:

* The Oracle Buffer Cache. Here you can see the cache miss ratio.

* Shared Pool Stats. This collection includes the data dictionary cache, and the library cache.

Log Buffer. Provides information on log space requests.

* Database Data Files. This object provides physical read and write per second counters.

* DBWR stats. Provides information on the DB Writer processes.

* Miscellaneous. Other statistics include dynamic space management, free lists and dynamic sorts.

Unix Day5 Commands

cat
program concatenates the contents of files, reading from a list of files and/or standard input in sequence and writing their contents in order to standard output. cat takes the list of files as arguments but also interprets the argument "-" as standard input.
Example: cat filename

who
The Unix command who displays a list of users who are currently logged into a computer. The command accepts various options that vary by system to further specify the information that is returned, such as the length of time a particular user has been connected or what pseudo-teletype a user is connected to. The who command is related to the command w, which provides the same information but also displays additional data and statistics.
Example output
user19 pts/35 Apr 18 08:40 (localhost)
user28 pts/27 Apr 18 09:50 (localhost)

Unix Day4 Commands

find
program is a search utility, mostly found on Unix-like platforms. It searches through a directory tree of a filesystem, locating files based on some user-specified criteria. By default, find returns all files below the current working directory. Further, find allows the user to specify an action to be taken on each matched file. Thus, it is an extremely powerful program for applying actions to many files. It also supports regexp matching.
Examples
From current directory
This searches in the current directory (represented by a period) and below it, for files and directories with names starting with my. The backslash before the star is needed to avoid the shell expansion. Without the backslash, the shell would replace my* with the list of files whose names begin with my in the current directory. An alternative is to enclose the the arguments in quotes: find . -name "my*"
Files only find . -name "my*" -type f This limits the results of the above search to only regular files, therefore excluding directories, special files, pipes, symbolic links, etc. my* is enclosed in quotes as otherwise the shell would replace it with the list of files in the current directory starting with my echo is a command in Unix (and by extension, its descendants, such as Linux) and MS-DOS that places a string on the terminal. It is typically used in shell scripts and batch programs to output status text to the screen or a file. $ echo This is a test. This is a test. $ echo "This is a test." > ./test.txt $ cat ./test.txt This is a test.

Unix Day3 Commands

rmdir
is a command which will remove an empty directory on a Unix-system. It cannot be capitalized. Normal usage is straightforward where one types:
rmdir name_of_directory
Where name_of_directory corresponds with the name of the directory one wishes to delete. There are options to this command such as -p which removes parent directories if they are also empty.
For example:
rmdir –p foo/bar/baz
Will first remove baz/, then bar/ and finally foo/ thus removing the entire directory tree specified in the command argument.
Often rmdir will not remove a directory if there is still files present in the directory. To force the removal of the directory even if files are present usually the -rf flag can be used. For example:
rmdir -Rf for/bar/baz

cp
is the command entered in a Unix shell to copy a file from one place to another, possibly on a different filesystem. The original file remains unchanged, and the new file may have the same or a different name.
To Copy a File to another File
cp [ -f ] [ -h ] [ -i ] [ -p ][ -- ] SourceFile TargetFile

To Copy a File to a Directory
cp [ -f ] [ -h ] [ -i ] [ -p ] [ -r | -R ] [ -- ] SourceFile ... TargetDirectory

To Copy a Directory to a Directory
cp [ -f ] [ -h ] [ -i ] [ -p ] [ -- ] { -r | -R } SourceDirectory ... TargetDirectory

-f (force) – specifies removal of the target file if it cannot be opened for write operations. The removal precedes any copying performed by the cp command.
-h – makes the cp command copy symbolic links. The default is to follow symbolic links, that is, to copy files to which symbolic links point.
-i (interactive) – prompts you with the name of a file to be overwritten. This occurs if the TargetDirectory or TargetFile parameter contains a file with the same name as a file specified in the SourceFile or SourceDirectory parameter. If you enter y or the locale's equivalent of y, the cp command continues. Any other answer prevents the cp command from overwriting the file.
-p (preserve) – duplicates the following characteristics of each SourceFile/SourceDirectory in the corresponding TargetFile and/or TargetDirectory: