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)

    Next
'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}"));


    lr_log_message(commandstring);

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

Next
'	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

	Loop

	myFile.Close

	myTemp.Close

	objFSO.DeleteFile(filePath)

	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); system(commandstring);

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.

Leave a Reply Cancel reply