Loadrunner to interact with a VB6 Application as a test stub

So, following on from the previous article / rant…

I managed to re-build the excel spreadsheet & macro functionality within VB6. I’d provide more details but it’s largely bespoke and unlikely to aid anyone, including me, in the future.

The app makes a call to openssl in order to generate, encrypt and/or decrypt a user certificate.
It’s all called from the command line, and that was interesting to build and a pain to test.

In any case, for reference, to build an application in VB6 without any forms:

Go to project properties (for the entire project, not just a module) and select startup object as a sub – in my case SUB MAIN.

Define SUB MAIN as a standard module and either call all your code within it, or add you code within it directly.

Public Sub Main()

'Store command line arguments in this array
Dim sArgs() As String
Dim iLoop As Integer

'Assuming that the arguments passed from
'command line will have space in between,
'you can also use comma or otehr things...
sArgs = Split(Command$, " ")
For iLoop = 0 To UBound(sArgs)
'this will print the command line
'arguments that are passed from the command line
'MsgBox iLoop & "-" & sArgs(iLoop)

'This is an example of the call, vb'd for testing
'Call MobileLogon("ECEEEJBUHEJUASDMCTBUFSFBEPIVEGAYDCFSDRAD", "pO5uDaWU", "C:\Temp\0057525949_____________UDID__EXCEL__TEST_MattLea0101.pem", "0057525949")

'This is the real thing.
Call MobileLogon(sArgs(0), sArgs(1), sArgs(2), sArgs(3))

End Sub

Testing is a pain because once you’ve made the executable, it only accepts the command line variables passed in (sArgs). So you end up putting a duplicated call in with hard-coded values – like the above.
And then you forget, make the executable and run it. It works – of course – because it’s using the hard coded variables.
And then you have to fire up the IDE, fix it, recompile, rebuild and retest.

And if you’re using loadrunner and the system command to test this, it can take a while:

The call:

strcpy(commandstring, lr_eval_string("C:\\Matt\\TestStubATE{vUserID}.exe "));
strcat(commandstring, lr_eval_string(" {sessionId}"));
strcat(commandstring, lr_eval_string(" {randomSalt}"));
strcat(commandstring, lr_eval_string(" {path_to_certificate}"));
strcat(commandstring, lr_eval_string(" {IngID}"));


rc = system(commandstring);

This particular script uses a certificate generated by OpenSSL from Loadrunner. Only the certificate was missing a newline / carriage return, line feed. Easy enough to fix in code I thought. Well in C in Loadrunner it was a pain – seriously I spend half my life battling with string manipulations in C, why isn’t there a mid function, an instring, a substring function etc? And don’t get me started with StrTok.
So I built that in VBS:

Const ForReading=1
Const ForWriting=2

Set args = Wscript.Arguments 'Command line arguments

For Each arg In args
' Wscript.Echo arg 'For debugging
strFile = arg

' Call edit_pem_file_workaround("0057525949_____________UDID__EXCEL__TEST_MattLea0101.pem")

Set objFSO = CreateObject("Scripting.FileSystemObject")
' folder = "c:\temp\"
'strFile = "0057525949_____________UDID__EXCEL__TEST_MattLea0101.pem"

filePath = strFile

Set myFile = objFSO.OpenTextFile(filePath, ForReading, True)
Set myTemp= objFSO.OpenTextFile(filePath & ".tmp", ForWriting, True)

Do While Not myFile.AtEndofStream
myLine = myFile.ReadLine

If InStr(myLine, "DEK-Info:") Then
myLine = myLine & vbCrLf
End If

myTemp.WriteLine myLine
objFSO.MoveFile filePath&".tmp", filePath

It looks for a line with DEK-Info on it and appends a new line onto it.
LR calls that in much the same way:

strcpy(commandstring, "C:\\Matt\\TestStub_Repo\\EditPemFile.vbs ");
strcat(commandstring, buffer);

Buffer contains the path to the certificate file.

So 2 test stubs to workaround issues identified, no great problem there. Except the vb6 one is an executable, and I have no idea how threadsafe or reliable that’s going to be. It’s command line only so the memory and cpu footprint is minimal but better safe than sorry. Especially when performance testing so I created another VBS to copy the teststubAte executable and rename it an teststubAteN.exe where N will represent the vUser ID within the injector.
I find out tomorrow if that works when my POC for this project is built.

Is it sad that I’ve enjoyed the complexity of all this? It’s not. Is it going to be annoying when someone tells me it was all unnecessary, that I could have done it another better way. Well, yes, it will be. IF it happens.

Loadrunner with Excel, DLLs and Exe’s, also a Little bit of test stubbing

So, I’ve spent the last couple of weeks trying in vain to make Loadrunner interact with OpenSSL.
I managed to get the DLL declared, and recognised and was able to turn 50% of the existing VBA code into operational C.
This took a long time because partly my knowledge of the process is not where it should be, but then I reached a point where the VBA passes a byte array as an input to a function.
My Loadrunner doesn’t recognise bytes, just about understands arrays and certainly wasn’t about to do this.

So… I figured well, it’s in excel anyway lets just have LR launch the excel process, grab the data it needs and get out again. TOO SLOW. As I knew it would be.

So now I’m rebuilding it as a standalone VB app. I have no idea if this will work, let alone if it will work quickly but I’m running out of ideas so here we are.

Ultimately, this is stage 2 of an interaction upon a webservice, whereby the user (actually the users phone) says HELLO, and then performs a LOGIN.

HELLO or MobileHello to give it the full name of the webservice is just a call to a server and an xml response. Loadrunner can fire the url at the server and read the response.
Bits of that response, session identifiers essentially, are reused in the LOGIN with encryption based upon public and private keys and certificates.

My task is to emulate MobileLogin following a successful HELLO, I’ve captured the values and now I need LR to fire against a VB executable with the parameters it has captured, perform the encryption and derive the next url. It then needs to fire against that url to exercise the server. I’ll make it work, but this has proven to be one of the more difficult tasks I’ve dealt with.


Hello world!

and so it begins…

This will be the development diary for all things Automation Solutions – I have much to do just to make it look like my site. I’ll be making images and picking themes

Then we’ll have some posts

For example: I have 2 projects in mind – the Loadrunner batch scheduler (multi-version), the Execution scheduler (which is just a booking system with a fancy name) and there will also be snippets of code in multiple languages as I get up to speed in perl, ruby, java et al.