Actually, this is more like 1.1. In as much as it ties into the previous post. I was blogging about building audit logs and data files via an “audit” script. That’s what I call them, not sure if there’s a full blown technical name but I use them to verify, validate and build data to be used in actual test scripts.
So let’s suppose you have an array of data you’ve captured with web_reg_save_param (x,y,z,"ord=all",last); this is how to handle that code into an audit log.

vuser_init{

// write file header once

WriteToOutputFile(lr_eval_string(“card,psn,status”));

return 0;
}
The function as defined in the previous post.
int WriteToOutputFile(char * string)
{

char *filename = “c:\\gemalto_audit.txt”;
long file_streamer;

if ((file_streamer = fopen(filename, “a+”)) == NULL)
//open file in append mode
{
lr_error_message (“Cannot open %s”, filename);
return -1;
}

fprintf (file_streamer, “%s\n”, string);
fclose(file_streamer);
return 0;
}

And finally, the function in use…

action
{
char szParamName1[128];
char szParamName2[128];
char szParamName3[128];
...
// get number of matches from ord=all

for (i=1; i<=nCount; i++ )
{
j = i * 2;
sprintf(szParamName1, "{available_cards_%d}", j);
sprintf(szParamName2, "{available_cards_psn_%d}", i);
sprintf(szParamName3, "{available_cards_status_%d}", j);
strcpy(strToOutput,lr_eval_string(szParamName1));
strcat(strToOutput,",");
strcat(strToOutput,lr_eval_string(szParamName2));
strcat(strToOutput,",");
strcat(strToOutput,lr_eval_string(szParamName3));
WriteToOutputFile(strToOutput);
}
}


I find more often than anything else, capturing the data is easy enough, but getting at that data in a structured way in order to use it effectively at a later point can be painful. The above is a real-life example – Developers implementing the content management inconsistently meant that there was nothing uniquely identifying 2 of the fields I needed. If I tightened the left boundary or the right boundary, elements were missed.
I’m not criticizing developers per se, they can’t really be expected to think about a performance tester a year down the life-cycle of the project looking at source-code structure.
The workable solution was to capture the 11 values I needed for one element, the 22 value-pairs for the other elements, and just skip every other element in 2 of the arrays. Inelegant perhaps, it works though and I built that today so it may become beatified over time.

So, I’m working at a new client, back doing the Loadrunner thing. One of the nice things about that is I get to re-use and refine code I’ve written previously for other clients. This article is going to contain some of these code snippets that I’ve used time and time again.

I’ve re-visited this code recently and found that a) it wasn’t very good, and b) I can do it better now – presented below is the better version. There will be an update inviting formatting etc.
And there’s no guarantee this is perfect.

Output to Text file

int WriteToOutputFile(char * string)
{

fprintf (file_streamer, "%s\n", string);
fclose(file_streamer);
return 0;
}


Called like this:

WriteToOutputFile(lr_eval_string("bban_count: {bbanNumber_count} blah {bbanNumber_count}"));


I just added the function beneath vuser_init rather than creating a header file. For multiple vusers, it’s a good idea to parameterise the filename as they can’t all share. I recommend a vuser identification parameter as thats built in.
Or Timestamps for uniqueness.

I also have a dos script for joining them all back up again since I tend to use this function for creating custom audit logs to track test data states as it moves through a scenario / test cycle.