Find the last modified file in a directory - vbscript

Function FindLastModified(strDir)
    Set objFSO = CreateObject("Scripting.FileSystemObject")
    Set oFolder = objFSO.GetFolder(strDir)

    Date = CDate("1/1/1950")

    For Each oFile In oFolder.Files
        If oFile.DateLastModified > Date Then
            NewestFile = oFile.Name
            Date = oFile.DateLastModified
        End If
    Next
    FindLastModified = NewestFile
End Function 

Schedule/execute testset run in Quality Center from Windows (VBScript)

You want to schedule and execute an automated test run every day at a certain hour. You need your results saved in QC. Here's a simple solution for scheduling by using following script in the windows scheduler.

-----------------
VBScript:

Dim QCConnectionSet
QCConnection = CreateObject("TDApiOle80.TDConnection")

QCConnection.InitConnectionEx "server_address" ' <--------------- Fill in server addressQCConnection.login "user", "pwd" '<------------------- FILL in user/pwd

QCConnection.Connect "domain_name", "project_name" '<----------- FILL Domain/Project

Set TSetFact = QCConnection.TestSetFactory
Set tsTreeMgr = QCConnection.TestSetTreeManager
nPath = "Root\test" '<------------- FILL IN PATH TO TESTSET

Set tsFolder = tsTreeMgr.NodeByPath(nPath)
If tsFolder Is Nothing Then
msgbox "error"

End If

Set tsList = tsFolder.FindTestSets("name_of testset") '<------- FILL IN NAME OF TESTSET
If tsList.Count > 1 Then
MsgBox "FindTestSets found more than one test set: refine search"
ElseIf tsList.Count <>
MsgBox "FindTestSets: test set not found"
End If

Set theTestSet = tsList.Item(1)
Set Scheduler = theTestSet.StartExecution("")
Scheduler.RunAllLocally = True
Scheduler.HostTimeOut = 100000
Scheduler.runSet execStatus = Scheduler.ExecutionStatus

RunFinished = False
while RunFinished = False
execStatus.RefreshExecStatusInfo "all", True
RunFinished = execStatus.Finished

wend

QCConnection.Disconnect
QCConnection.Logout
Set QCConnection = Nothing

---------------

Very crude! but it does the job! You just need an existing testset, the script will execute it at any time you want using your windows scheduler.
I'm sorry for the absolute lack of comments, but you're smart, you can figure it out. :)

Accessing IExplore from VBScript

So you want to access a Iexplore window that's already opened and on the desktop. Here's some sample code (VBScript):

This code will give a msgbox showing the URL for every open IExplore window.

----------

Set objShell = CreateObject("Shell.Application")
Set IEWindows = objShell.Windows

Dim IEWindow()
ReDim IEWindow(IEWindows.Count)
Dim i
msgbox IEWindows.Count

For i = 1 To IEWindows.Count

Set IEWindow(i) = IEWindows.Item(i - 1)

Next

For i = 1 To UBound(IEWindow)

msgbox IEWindow(i).LocationURL

Next

----------

Now you know how to connect to a IExplore window you can access all controls inside by programming the DOM (Document object model). It's a fairly easy model, look it up, google is your friend! :)

Test automation for terminal emulators

This is an article for beginning Quick Test Pro users. Quick Test Pro is a test automation tool from HP (former mercury). It is sold as a record/playback tool for making test cases. I’ll describe how to automate terminal based applications. Why? Because there’s a good way and a bad way. The problem is you’ll only discover exactly how bad the bad way is after you see the good way. So if no senior automation engineers are present there’s a very good change you’ll be going the bad direction.

Forget record and playback. I’ll repeat: FORGET RECORD AND PLAYBACK. But you’ll say: “but it is working for me!”. Well yes, it is, in the beginning. Standard use of QTP works by using a repository in which a objects in your AUT (application under test) are stored, so that when replaying QTP can access them. The problem is not making the tests. It will work perfectly, but the problem lies in maintaining the tests. Most beginning engineers will have a script for each terminal emulator screen and a central repository (I do hope you’re using a central repository, otherwise you can look forward to a full-time job in test maintenance.) and a datasheet (excel).
Now here’s the problem: when a field is added to a screen, you’ll have to update the repository, the script for this particular screen and the datasheet. So you’ll need to uses the application, QTP and excel. Sounds like a lot of work? Well it is!

So what can we do? The good thing about terminal emulators is the fact that objects are very clearly and easily defined. So would it be nice if we could skip the whole repository, skip the ‘one script per screen’ and be able to customize our complete flow and screen setup from within excel. Wouldn’t that mean we could have business users write the tests? Yes it would! J

How? Make a terminal emulator framework in QTP! The explanation below is a very very very basic flow of how we could do this, but it will give you an idea:

** Make an excel sheet. Make 1 tab that will contain the flow, make one more for each screen in your application. In the first tab, have a test case on each row, so make each row a series of screens (each column is a screen). On the other tabs (screens) each row contains the data for the fields on that screen related the the row of your flow, the names of the columns are the field names of the screen in your UAT.

Tab 1 – row 1: screen1 screen2 screen3
Tab 2 (name=screen1) – row1: dataforfield1 dataforfield2 dataforfield3

** Now where going to make a driver script in QTP. In it’s most basic form it’ll do this:

Loop1 – loop every row on tab 1 (every test case)
Loop2 – loop every column on tab 1 (every screen)
Goto the right tab
Loop3 – loop every column on the screen tab (field in AUT)
Find the field in the application
Fill in the field
Submit
(check reply)
End loop3
End loop2
End loop1

** How are we going to make the driver script in QTP? Descriptive programming!! Descriptive programming is not nearly used enough in QTP. For Terminal emulators it’s perfect. With descriptive programming there’s no need for a repository anymore, you can access any object from within the script. A little example syntax:

TestObject("PropertyName1:=PropertyValue1", "..." , "PropertyNameX:=PropertyValueX")

Look it up in the help file if you’ve never heard of it. It’ll change your life. The important thing is to keep your PropertyValues out of your script and into your datasheet (for example as the names of the columns on your screen tabs).

So that’s about it. Implement the loops, add some checking code and error handling and there you have it: your automated solution in 500 lines of code or less for terminal emulators that’s practically maintenance free and can be updated by adding data,tabs and columns in an excel sheet.
I’d say have a go at it, a very basic test could be easily implemented in a day, a full blow 1000 testcase suite in a week.