Friday, September 20, 2013

Performance Testing - Scripting - Part 1

Web applications will typically follow n-tier architecture, i.e. presentation layer, business logic layer, data access layer, data layer, external interfaces etc. But a website will mostly static pages, may be with javscript. The entry and exit to websites is unpredictable, as every page is a potential entry and/or exit, they are all independent. I a web application (webapp), the sequence of tasks one does is very important, to complete a business transaction. Hence there is a difference between load testing a website and load testing a webapp. As we saw in the previous post, the very first step is to identify the most frequently used scenarios and the steps for those scenarios. From that point, we need to focus on scripts.

Every load test tool provides recording feature. This is the most economical, easy and powerful way of scripting. First the tester must record the sequence of operations, as one user does. This means, start recording, start doing the business transaction steps on the application. The tool will record all the requests and responses, going to server and coming back from the server, using an internal proxy. Ideally every load test tool sniffs the request/response between the browser and the server. The request may be a get or post or ajax request. The tool will identify the url, the query string parameters for the request and will identify the server response data and redirection pages. Soon after recording, if we replay the script, the tool must be in a position to send the request to the server.

Mere recording and replaying will not solve many business rules. Some apps will require unique data, some need random data, some need advanced correlation and that is what we must do as the next step with the recorded script. Also, it is better we organize the requests under folders/containers. This will help towards easy maintenance of the scripts. For example, if our sequence of operations look like the following,
  • Go to home page
  • Fill userid and password, login
  • Navigate to items page
  • Load items list grid
  • Select an item and edit
  • Enter new details and save
  • Refresh items grid
  • Logout
It is better to organize the same like this.

  • Initialize
    • Initialization
    • Go to home page
    • Fill userid and password, login
  • Items Grid Load
    • Navigate to items page
    • Load items list grid
  • Modify Item
    • Select an item and edit
    • Enter new details and save
  • Items Grid Refresh
    • Refresh items grid
  • Finalize
    • Logout
Once the requests/steps are organized, the next step is to provide proper data to the script. We cannot use the same data we gave during recording. There are 2 parts to the data  - static data, dynamic data. Static data is different data supplied/typed by the user on the screen, dynamic data is the data that server sends back to the screen. Providing static data is called parameterization and handling dynamic data is called correlation. 

Static data can be provided thru variables. Tools provide variable manager module. We can create a variable and load the variable with different values, at run time. Some data that we may often use, can be obtained from the system itself, such as current date and time, user name, machine name, random number, random text, etc. 

Some data will be application specific. This data will have dependencies on other application data as well. For this, we usually create a file to have such data and modify the hard coded data values in the script, to use the data variables. The variables will be mapped to the file and specific column in that file. This is very similar to data driven tests in functional test automation.

For example if item creation page requires item code, item name, UOM, price as user supplied data, create a csv file like this.

ITEMCODE,ITEMNAME,UOM,PRICE
1001,Maxx Soap,NOS,18.90
1002,Vixor Biscuits,PCK,12.60
..
1099,Brainee Rice,KGS,14.50

Create a variable in the tool (say myItemData) and map that to this file.
In the script, replace the hard coded values with
myItemData.ITEMCODE, myItemData.ITEMNAME, myItemData.UOM,
myItemData.PRICE. During run time, the tool will read the data from this file and supply the values from the respective columns to the right variables. Usually, the tools will read lines sequentially and send that to the script. This can be changed as well. We will see these in the next post. Stay tuned.

For free lessons on automation tools, visit us at http://www.openmentor.net.



 

Tuesday, September 10, 2013

Performance Testing - Protocol Selection, Script Recording



If you know one load testing tool, it is easy to learn another. You need to be clear in the load testing fundamentals, in order to learn a new tool and to master it. We will help you step by step in achieving that mastery over load testing tools. Let us take the first part of the tools, protocol selection.

Protocol is nothing but the format in which the client and server communicate with each other. Eg., http, https, ftp, smtp, wap, tcpip, rdp, etc. Every application developer must first freeze the protocol and architecture, as changing these at a later stage will mess up a whole lot of things. But for a load testing person, all it needs is to understand what goes as request and what comes as response. Ultimately every thing will go as a stream of bytes; but to operate on the requests for parameterization etc., the load tester must know the parts of the requests and parts of the response. 

It is difficult to manage too many protocols and learning them at the bits and bytes level. Instead, if the tool can parse the request and response, and display the same in a clear user interface, most of the problems for the load tester are solved. The tester must refer to the design documents as well as consult with the development team to identify and choose the right protocols. A few applications may use multiple protocols to carry out a specific transaction; in that case, the tester must select all those protocols before recording the script.

The catch here is, that the load testing tools will charge you based on the protocol modules you want to buy! There will be a base license cost and there will be an add-on cost for every protocol module. You may be thinking that it is a simple web application, but that app may use Google Web Toolkit (GWT) or Flex related formats; without having those protocols as part of the tool, you cannot get a clean script. Hence one needs to be careful why purchasing the tool and add-on licenses.

Once you freeze the protocol, the you need to focus on scripts. We must create load testing script by recording a typical business scenario, as though one user is doing it on the application. For example, a user logs into an HR application, submits a travel request and logs out. The actual load test will send 100s of such requests (simulating 100s of users). The key point here is what scenarios we must record as part of scripting?

Identify the most frequently used user scenarios. All said and done, you and I go to google and do search 80% of the times.  Some other person may go to google stocks page to get stock quotes. So, the user priorities vary. Though google has 1000s of pages, only a small set of pages are more frequently used, by  most of the users. In the same manner, in your application, identify which are the most frequent ones and tabulate the same. How many users will execute those scripts, how long the users will run etc., we will deal with those in subsequent sections.

If you take any ecom site, the most frequently used scenarios are:

  1. Go to home page, type a keyword, do a search, load search results, view an item from the results
  2. Go to home page, type a keyword, do a search, load search results, view an item from the results, add to cart
  3. Go to home page, type a keyword, do a search, load search results, view an item from the results, add to cart, provide payment details, buy
In the above 3 scenarios, many activities are common, but for every one customer actually buying, 100s of other customers, just "surf" and "window-shop" without adding to cart. Though they do not contribute to revenue, they occupy your system and network space. After attracting a customer to the site, thru marketing, it is very hard to see the customer abandoning the shopping cart without a buy! Usually these things happen due to slow response. So, buckle up, and make it faster!


For free lessons on automation tools, visit us at http://www.openmentor.net.