Testing is Rocket Science Not Brain Surgery

If you’ve never used LoadRunner let me be the first to tell you this isn’t your grandmother’s performance testing tool. As a novice I am looking to become more proficient with LoadRunner and my hope is that I can help fellow novice users navigate this testing tool.

I am reminded of something a senior performance tester once told me. He said LoadRunner is very good at generating a lot of code. As I began to work on a performance testing exercise he assigned me I quickly realized truer words were never spoken. The first part of the assignment was to navigate to the www.finance.yahoo.com site and obtain a quote for General Electric Co. If ever there was a site to cut your chops on this is the one. To give you an example of what I’m talking about, below is a snapshot of the code generated by LoadRunner for simply loading the yahoo finance website, and obtaining a stock quote for a company:

As you can see by looking at the scroll bar to the right there is more code that was generated. When I attempted to replay the script it would fail every time. The script would always hang at the code block highlighted below:

I couldn’t figure out why this code was causing an issue and I certainly didn’t want to just arbitrarily comment it out without having an understanding of the potential impact. Surely I’m not the first person to encounter this error message so I decided to Google it. I learned that LoadRunner provides functionality to increase the timeout on an http request. I thought greatly increasing this number would solve my issue, sadly it did not. No matter how high I set the timeout threshold the script would still fail. So this got me thinking, what is being requested? What I needed was a tool that would provide insight into this particular GET request…enter “HTTPWatch.” HTTPWatch is an add-in tool for IE and Firefox browsers that sniffs/monitors http traffic. I played with this tool on a number of occasions before and I remembered that it provided detailed information about HTTP traffic. Once I had the tool installed I executed the same steps used when recording the LoadRunner script. I noticed all the GET requests had a time associated with their duration; all except one. I decided to look into this particular request a little more. This is where it started to get exciting. I selected this request from HTTPWatch and used the “Time Chart” tab to look at this request in isolation:

Based on this information it would appear that this request has not been fulfilled yet. You can see from this snapshot that the number of seconds for the “receive” continues to increment…interesting. I decided to see what else I could find out. I selected the [Headers] tab, and noticed the server fulfilling this request is called a “Yahoo! Finance Push Server – v1.0.3”. This again got me thinking, what is a push server? Upon Googling this term I found out that it is responsible for sending data from a web server to a web browser. Further reading revealed that this is a common implementation for…wait for it…sites providing stock market data! Is it possible that I can just comment out this particular GET request from my LoadRunner script? After all I just want to load the site and obtain a quote. I really don’t need a continual feed of stock market data for this test right? When I selected the [Headers] tab I realized the specifics of the GET request matches the specifics contained in the LoadRunner web_url function. At this point I decided to search every web_url function for the text “streamerapi” and comment out the entire web_url entry. Upon re-running my LoadRunner script I was extremely excited to discover my script executed successfully! I’m sure a more experienced LoadRunner user may have commented out the web_url function right away simply by calling into question the text “streamerapi”. It just sounds like a continual feed from a server right? If you are learning, as I am, you owe it to yourself to take advantage of the TCP/IP traffic capture tools like HTTPWatch or WireShark to help you understand the http traffic generated between the AUT (application under test) and the web server. The other lesson learned is something of a best practice to look before you delete and to take pause of what might not be coming across in the traffic depending on the timing of your recording too. Lastly, this experience also emphasizes the fact that recording a script is only the beginning of implementing test automation.