LoadRunner 11(Vugen) application running on a secondary device bug

I came across an interesting bug in load Runner 11(no patch).

Component
Vugen
Dell monitor - Secondary device

Issue
If you try to compile(Shift+F5/F5) a code that has an error, the whole code disappears. Same behaviour is observed when you open a script. This happens if you have the Vugen application on a secondary device. This issue does not occur when vugen application is running on primary device.

I have a Dell montior(secondary device) attached to Toshiba laptop(primary device).

Before compiling the code

After compiling the code


Solution
Follow are possible workarounds:

• Resize the vugen application



• If you have multiple scripts open(different tabs) then switch back and forth between them


• Run Vugen application on a primary device

Avoid reporting just an average response time

In last 2.5yrs of performance testing, I have come across some reports that only report an average response time (also during discussion have noticed people only mentioning average response time). For example, consider following two response time data set(graph and dataset). Also assume that the SLA is 6 seconds.

The average response time for both the dataset is 5 and therefore satisfies the SLA. However, looking at the data points you will find that the variation from the mean in DataSet1 (SD=3.19) is more than that in DataSet2 (SD=0.71). You have a mininum value of 1 and maximum value of 9 for dataset1 and you have minimum of 4.5 and maximum of 6 for dataset2. Also 4 out of 10(40%) response time values for dataset1 are above the expected 6 second target. Therefore there is somekind of performance anomoly. This kind of information is missed out if you only report average and therefore may lead into making an incorrect decision by stakeholder(s).

If possible, avoid using only average. However, if you don’t have an option then along with average, I suggest you also report minimum, maximum, standard deviation and sample size. It provides bit more information about the response time.

Update: Only thing that is reported is average response time and there is no graph to show the average response time over time

Siebel Loadrunner scripting issues

If you haven't scripted a siebel application before for load testing using Load Runner then you are in for some good time. I am sure you will come across different issues which you might not have encountered before. I wanted to compile a list of issues that I/colleague have encountered and how they were solved. Therefore this blog contains some of those issues and possible solution.

Following issues were encountered by my colleague:

Issue:
Sometimes the application does not function correctly when recording with Loadrunner, but works fine without recording.
Solution:
Close all browser instances, search and delete a file called Siebel High Interactivity Framework, Log into the Siebel application and agree to 'repair' the browser configuration.


Issue:
Some "web_url" requests fail during replay and the application responds with "We detected an Error which may have occurred for one or more of the following reasons: We are unable to process your request. This is most likely because you used the browser BACK or REFRESH button to get to this point.(SBL-UIF-00335)".

The following request is a sample which generated this error:

web_url("start.swe_54",
"URL=https://{Host}/{Env}/start.swe?SWECmd=GetCachedFrame&SWEC={Siebel_SWECount}&SWEFrame=top._sweclient._swecontent._sweview._swetmp&SWESP=1",
"TargetFrame=",
"Resource=0",
"RecContentType=text/html",
"Referer=https://{Host}/{Env}/start.swe?SWECmd=ShowPopupFrames&SWEDIC=1&SWEU=/{Env}/start.swe%3fSWECmd%3dGetCachedFrame%26SWEC%3d9%26SWEFrame 3dtop._sweclient._swecontent._sweview._swetmp%26SWESP%3d1",
"Snapshot=t62.inf",
"Mode=HTML",
LAST);

Solution:
At first glance the requested URL seems to be parametrized correctly. However, the automatically correlated SWEC={Siebel_SWECount} is actually incorrect. In most cases the Siebel_SWECount parameter is incremented correctly by Loadrunner. However, when using SWECmd=GetCachedFrame, that value for the SWEC parameter must be correlated manually from the previous request.

The response from the previous request will contain something like:

URL .../xxx/start.swe?SWECmd=GetCachedFrame&SWEC=32&.......

Normally this kind of correlation is natural and intuitive, but with the Siebel protocol SWEC is a counter which is not usually correlated and therefore easily overlooked.


If you come across different issue(s) related to Siebel application scripting, I would like to hear about them as well as how you were able to solve it. If I come across more issues, I will update this blog.