Wednesday, August 28, 2013

Auto-Correlating Session IDs in Oracle Application Test Suite (OATS)

Similar to HP LoadRunner, Oracle Application Test Suite (OATS)[1] is an automated performance and test automation product from Oracle for monitoring system behavior and application performance. It's especially useful for Oracle Fusion Application's performance evaluation.

Oracle Open Script (or Oracle Functional Testing) is one of the components in OATS, which is integrated with Oracle Load Testing and Oracle Test Manager. It is also a load testing script generator, which is integrated with Eclipse to support script development and debugging. In the current offering, it only runs on Windows.

Correlation


Correlation of dynamic session values is a major task for load test scripting[2]. When a server in AUT (application under test) exchanges dynamic session values with the browser. OpenScript can auto-correlate dynamic session values—For example session IDs.

What's Session ID?


Session ID is used in session tracking.  Session tracking enables you to track a user's progress over multiple servlets or HTML pages, which, by nature, are stateless. A session is defined as a series of related browser requests that come from the same client during a certain time period. Session tracking ties together a series of browser requests—think of these requests as pages—that may have some meaning as a whole, such as a shopping cart application.

Session ID is a piece of data that is exchanged between the application's web server and the user agent (or browser). It is typically used to identify a specific user logged on to the application for a particular duration of his/her visit (or session).

Session ID is given per Session. It is often destroyed when the user logs off from the application. Next time you visit the same site, you will have a different session ID. The correlation task is to identify these dynamic values and substitute variables for them in the load testing scripts.

As you know, Oracle Fusion Applications maintain a rich set of dynamic session values. Correlation done manually requires in-depth knowledge of the application itself and can also be error prone. Fortunately, most correlations needed for successful playbacks can be done automatically by Oracle Open Script. For example, it auto-correlates Session IDs.

Different Ways of Storing Session IDs


There are multiple ways for a web page to pass session ID to a web server. Session ID can be stored in:
  • Cookie[6]
  • URL
  • HTML page

Storing Session ID in Cookies


Cookie is the text information that application places in the client's hard disk. Browser sends the cookie back to the application to keep the state. On WebLogic Server, use of session cookies is enabled by default and is recommended, but you can disable them by setting cookies-enabled property[3] to false.
If cookie is enabled on the browser, you often find the following entry in the HTTP headers:
  • JSESSIONID=HDe6IhnMFZFtKrVsNi0eUsZ0NWaaIaw_OT2vW7CDpZ8sfz9v4Hqf!-777642468!-553692576;
Note that JSESSIONID is the default session tracking cookie name used by WLS. You can configure WebLogic Server session tracking by defining properties in the WebLogic-specific deployment descriptor,weblogic.xml. For a complete list of session attributes, see session-descriptor[3].

Storing Session ID in URL


Session ID can be sent back to the server as a string appended to URL following a question mark (i.e., "?")
On WLS, you can enable URL rewriting by setting url-rewriting-enabled property, which encodes the session ID into the URL and provides session tracking if cookies are disabled in the browser. However, storing Session ID in URLs is less secure than storing it in cookies[5].

Storing Session ID in HTML Page


Finally, session ID can also be stored in the hidden field of a HTML page and submitted by the Post Command:

  • <input type="hidden" name="sessionID" value="54321abcd">

Most user agents (or browsers) allow you to store information in a HiddenField control, which renders as a standard HTML hidden field. A hidden field does not render visibly in the browser, but you can set its properties just as you can with a standard control. When a page is submitted to the server, the content of a hidden field is sent in the HTTP form collection along with the values of other controls. A hidden field acts as a repository for any page-specific information (including Session ID) that you want to store directly in the page.

References

  1. Oracle Application Testing Suite
  2. OpenScript for Load Testing Script Troubleshooting (Tutorial)
  3. weblogic.xml Deployment Descriptor Elements
  4. Extended Session ID format in WebLogic Server (12.1.1)
    • A server startup flag, -Dweblogic.servlet.useExtendedSessionFormat=true, retains the information that the load-balancing application needs for session stickiness. 
    • The extended session ID format will be part of the URL if URL rewriting is activated, and the startup flag is set to true.
  5. Why is passing the session id as url parameter insecure?
  6. OAM 11g Single Sign-On and OAM 11g Cookies
    • Note that the cookie model is different between 10g and 11g.
  7. OATS: Tie All Processes Together — from OpenScript to Scenario (Xml and More)

1 comment:

Unknown said...

It was so nice article.I was really satisified by seeing this article and we are also giving Testing online training.The Testing online Training is one of the best QA online training institute in worldwide.