«

Mar 16 2017

How to Use Test Parameters Dynamically with AOM

UFT enables the use of test parameters, which in order to be used in an action they must be passed when called. The best practice, in my view, is to first add the parameters to the test and assign them default values, and then to create the action parameters and assign them the values from the corresponding test parameters (via the Action Call Properties dialog). Hence, if values are passed to the test, the actions would get these values; if not, then the actions would use the default values defined at the test level.

On a personal note, I must admit that until a couple of years ago I avoided totally using test and action parameters on the grounds that passing values to a test can be done with a wide variety of coding techniques. Indeed, in the past I tried to avoid some of UFT’s GUI-managed features (like the horrendous recovery scenario!), having in mind a kind of “automation is coding” agenda. However, with time I came to realize that this mechanism has a real added value:

  1. Test and action parameters appear on the corresponding properties pane with type (String, Password, Number, etc.) and a description, making it easy to get the information on the relevant data used by the test, rather than having to dig into the intricacies of function libraries.
  2. Test and action parameters support default values (not supported by VBScript) which are very useful especially when developing and debugging a test.
  3. Test parameters default values can be easily overridden using the dialog that opens-up at the beginning of a run session (after pressing F5)
  4. Test and action parameters come handy for test-specific data that does not change across test or action iterations. For that purpose, we would use the DataTable.
  5. Test and action parameters are a better option than environment variables (which when loaded from an external XML file are actually environment constants), which should be used for defining key-value pairs that are relevant for all the tests in a particular setting (hence the name “Environment”).

In one of my recent projects the customer requested me to build a mechanism that would enable him to run all the tests in a suite on multiple servers (URLs). This led me to build a mechanism that reads the parameters (including the URL) and corresponding values from an XML (I might write a separate post on the mechanism itself) and pass them to each test. In this project this was a relatively easy feat, as all the tests needed the same parameters, so I could put them hardcoded in the AOM script that launched UFT and managed the whole run session.

But with another customer, acting as lead of an automation team with the task of developing hundreds of UFT tests for tens of different systems under test – each test not necessarily requiring the same parameters as others – I asked myself how this can be achieved. The quality of the documentation on the parameters in the UFT help is very lacking. So I first made a list of what I already know. The following snippet assigns two values to two parameters which names are already known.

On Error Resume Next
Dim qtApp, pDefColl, qtParams, qtResults, item
Set qtApp = CreateObject(“Quicktest.Application”)
Set pDefColl = qtApp.Test.ParameterDefinitions
Set qtParams = pDefColl.GetParameters()
qtParams.Item(“Param1”).Value = “Value1”
qtParams.Item(“Param2”).Value = “Value2”
qtResults.ResultsLocation = qtApp.Test.Environment(“TestDir”) & “Res1”
qtApp.Test.Run qtResults, True, qtParams
Set qtParams = Nothing
Set pDefColl = Nothing
Set qtApp = Nothing

However, with a multitude of tests, each having different numbers and types of parameters, it was clear to me that I should seek a solution that:

  1. Gets the test parameters dynamically.
  2. Assigns the test parameters the corresponding values as defined in the source (e.g., an XML file).
  3. Prevents the error prone practice of coding the parameter names in the AOM script, which is also inflexible and difficult to maintain.

The ParameterDefinitions object provides only with the Count and Item properties and the GetParameters method. The item property makes evident that the object implements a HashTable or Dictionary structure, so it requires the name of the parameter as argument (for example: pDefColl.item(“Param1”)).

ParameterDefinitions Picture

I fiddled a bit with the intellisense in UFT’s editor to see what are the properties of a Parameter:

and quickly found out that the following code would provide the parameter name and default value:

For each item in pDefColl
Msgbox item.Name & ” = ” & item.DefaultValue
Next

And so it took virtually no-time to learn that the following code would do the trick (of course that the value should not be hardcoded as done here for illustration purposes):

For each item in pDefColl
qtParams.item(item.Name).Value = “My new value”
Next

So that’s it. Replace the assigned value with that taken from another source and voilà! You got the test parameters truly set dynamically.

About Meir Bar-Tal

Meir Bar-Tal is an Automation Architect with extensive technical, educational and leadership experience in Software Design, Development and Testing. For many years Meir has helped companies establish solid foundations for their testing activities with a wide variety of software applications and systems and across different technologies and platforms. Meir is a well-known expert in Data-Driven, Keyword Driven and Hybrid methodologies and has published a number of influential articles on the applications of Design Patterns to Test Automation. For the last five years, he has been pushing forward an ambitious program towards the development of an Object Oriented automation framework named Sunscrit, a huge project which is still underway. Meir is the owner of www.AdvancedQTP.com of which he was a co-founder in 2007 and served as its Editor in Chief, Author and Forums Administrator ever since. Meir lives in Israel and cooperates closely with HP R&D and other colleagues to improve the user experience and productivity with HP Software tools.