Highlighted
Super Contributor.
Super Contributor.
900 views

Time parameter parsed incorrectly during replay in TruClient Develop Script mode

Jump to solution

Hi,

 

I am stumbling into a strange problem. I am using two time parameters with a certain offset in the past:

aTime = Current time minus 5 minutes

bTime = Current time minus 30 minutes

 

Both parameters are in the format %H:%M.

 

Whenever I replay in Develop script mode it happens frequently that one or more of the time digits are parsed incorrectly to the UI of IE. For instance, the current time is 07:33 and then I see that the bTime parameter is parsed as 07:)3 while it should have been 07:03. This happens to one or both parameters by the way, but not all the time.

See also attached screenshot.

 

I can reproduce this only in Develop script mode, not in load mode. It never occurs in load mode, so I cannot add a trace file for it, since I do not know how to switch on logging when being in develop script mode (if that can be done at all...)

 

All in all this is very annoying.

Has anyone encountered this problem using TruClient? Is this a bug?

 

My environment is:

Windows 7 SP1 Enterprise edition, region format is set to English (UK)

VUgen 11.52

IE10, TruClient using IE10 in IE9 standard mode

 

Peet

0 Likes
1 Solution

Accepted Solutions
Highlighted
Super Contributor.
Super Contributor.

Hi Guy,

 

I finally managed to tackle the problem. It's not a Vugen or TruClient issue. When I tried parsing fixed time values to the webpage I also encountered the same problems. When increasing the typing interval to say 200ms (I always make the typing interval a very low value when being in develop script mode), the problem dissapears.

 

Another workaround seems to be to enter the time in the format %H%M rather then %H:%M (so leave out the semicolon), the webpages javascript will then convert it to the %H:%M format when moving to the next field. By doing it this way I can keep the typing interval at a low value, which is neat for script development.

Of course in a real load test I will stick to a realistic typing interval.

 

Thanks for your help end hints, eventually it brought me on the right path.

 

Regards,

 

Peet

View solution in original post

0 Likes
11 Replies
Highlighted
Absent Member.
Absent Member.

Hi Peet,

Can you describe how the parameters were configured?

Guy Rosenthal
Network Virtualization PM
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Hi Guy,

 

The parameter configuration is pretty straight forward. I attached two screenshots wher you can see how they are configured. Note that where I talk about parameters aTime and bTime above, I am actually using parameter names aTijd and bTijd (Dutch), but the problem is the same.

 

Hope to hear from you soon.

 

Peet

0 Likes
Highlighted
Absent Member.
Absent Member.

OK. thanks. I will check it and update.

In the meanwhile, you can use JS code to obtain the needed functionality without using LR parameters.

Since those parameters has dynamic values it is legit to use JS code for that.

 

Guy Rosenthal
Network Virtualization PM
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Hi Guy,

 

Thanks for looking into this. As far as using javascript in stead of parameters. I guess I could do that, but I am not familiar enough with javascript programming to come up with a function like that myself. Any examples or other workarounds?

 

Peet

0 Likes
Highlighted
Absent Member.
Absent Member.

Sure Peet.

First of all here is a useful link for Date object in JS: http://www.w3schools.com/jsref/jsref_obj_date.asp

Here is a code example I have executed in Eval JS step in TC:

 

//current time print
var d = new Date();
LR.log(d.getHours() + ":" + d.getMinutes());


//current time + 40 minutes offset
d.setMinutes(d.getMinutes() + 40);
LR.log(d.getHours() + ":" + d.getMinutes());

 

 

Guy Rosenthal
Network Virtualization PM
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Hi Guy,

 

Thanks, I will give it a try. As far as the issue is concerned I also tried storing the parameters first as a string as an intermediate step. However this gave the same (erroneous) results.

 

Peet

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Hi Guy,

 

One more update: I tried using the following javascript:

 

var Time = new Date();

Time.setMinutes(Time.getMinutes() - 5);
var aMinutes = '' + Time.getMinutes();
var aHours = '' + Time.getHours();

if (aMinutes < 10) {
  aMinutes = 0 + aMinutes;
}

if (aHours < 10) {
  aHours = 0 + aHours;
}

var aTime = aHours + ":" + aMinutes;

Time.setMinutes(Time.getMinutes() - 25);
var bMinutes = '' + Time.getMinutes();
var bHours = '' + Time.getHours();

if (bMinutes < 10) {
  bMinutes = 0 + bMinutes;
}

if (bHours < 10) {
  bHours = 0 + bHours;
}

var bTime = bHours + ":" + bMinutes;

The script works, however... when the values for aTime and bTime are parsed to the UI of IE in develop script mode, I still have the same problem as when using the time parameters with offset in the past. Very strange....

When I add a window.alert() to display the values of aTime and bTime the format is correct, but when parsed to the UI during runtime it is getting malformed for some reason.

 

Peet

 

0 Likes
Highlighted
Absent Member.
Absent Member.

Peet,

Can you share the script? 

Guy Rosenthal
Network Virtualization PM
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Well certainly not in this forum, better to make this a formal support request I suppose?

 

Peet

0 Likes
Highlighted
Absent Member.
Absent Member.

I guess. I can't repro it in-house in order to file a defect...

Guy Rosenthal
Network Virtualization PM
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Hi Guy,

 

I finally managed to tackle the problem. It's not a Vugen or TruClient issue. When I tried parsing fixed time values to the webpage I also encountered the same problems. When increasing the typing interval to say 200ms (I always make the typing interval a very low value when being in develop script mode), the problem dissapears.

 

Another workaround seems to be to enter the time in the format %H%M rather then %H:%M (so leave out the semicolon), the webpages javascript will then convert it to the %H:%M format when moving to the next field. By doing it this way I can keep the typing interval at a low value, which is neat for script development.

Of course in a real load test I will stick to a realistic typing interval.

 

Thanks for your help end hints, eventually it brought me on the right path.

 

Regards,

 

Peet

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.