How to Work With Environment Variable in UFT?
Environment Variable comes into picture when you try to parameterize data. In all Unix and Unix-like systems, each process has its own private set of environment variables.
By default, when a process is created it inherits a duplicate environment of its parent process, except for explicit changes made by the parent when it creates the child. At the API level, these changes must be done between fork and exec.
Alternatively, from shells such as bash, you can change environment variables for a particular command invocation by indirectly invoking it via env or using the ENVIRONMENT_VARIABLE=VALUE
PATH – lists directories the shell searches, for the commands the user may type without having to provide the full path.
HOME (Unix-like) and user profile (Microsoft Windows) – indicate where a user’s home directory is located in the file system.
TERM (Unix-like) – specifies the type of computer terminal or terminal emulator being used (e.g., vt100 or dumb).
PS1 (Unix-like) – specifies how the prompt is displayed in the Bourne shell and variants.
MAIL (Unix-like) – used to indicate where a user’s mail is to be found.
Shell scripts and batch files use environment variables to communicate data and preferences to child processes.They can also be used to store temporary values for reference later in the script, although in Unix other variables are usually used for this. In Unix, an environment variable that is changed in a script or compiled program will only affect that process and possibly child processes.
The parent process and any unrelated processes will not be affected. In DOS changing a variable’s value (or removing it) inside a BATCH file will change the variable for the duration of command.com’s existence.In Unix, the environment variables are normally initialized during system startup by the system init scripts,and hence inherited by all other processes in the system.
Users can, and often do, augment them in the profile script for the shell they are using. In Microsoft Windows, environment variables defaults are stored in the windows registry or set in autoexec.bat.
Till now you have learnt that the environment is kind of Global variable. Now think about the Global variable in any programming language. The scope of the global variable is inside the test while the test or the program is running. If you look at machine view architecture it is nothing but a memory allocation to store some value.
So when the program ends the memory allocation is also released. Now say you have used many global variables inside your test. You will be doing some operations on that Environment variable comes to rescue us.
Environment parameters are useful for localization testing when we want to test an application where the user interface strings change, depending on the selected language. Environment parameters can be used for testing the same application on different browsers.
We can also vary the input values for each language by selecting a different Data Table file each time we run the test. The BPT components are like independent scripts. That is why you need to use Input/Output parameters or External data storage (Excel/Flat/XML files).
How to create output parameters for BPT components:
UFT – Component 1
1. File –> Settings –> Parameters. Add output parameter
2. In Expert View: Parameter(“yourOutputParameter”) = something
UFT Component 2
1. File –> Settings –> Parameters. Add input parameter
2. In Expert View: yourVar = Parameter(“yourInputParameter”)
QC -> Test Plan view
1. Create a script by drag and drop your components
2. Component 2: Click on inputs
3. Table with input parameters will appear
4. Click on “Output from Previous Component” Checkbox
5. Select the Output parameter from Component 1
Types of Environment Variables in UFT:
Variables that we define within the test. we can create them and these variables are used only a test where they were created. Once we created that variable, we can not modify the name of variable and u can modify the value.
They are saved with the test and accessible only within the test in which they were defined. we can create them and these variables are used only as a test where they were created. Once you created that variable you can not modify the name of variable and u can modify the value. If u want to use this variable in many tests you can export them in the XML file. There you can modify the name of the variable.
Variables that you predefined in the active external environment variables file. The variables which are Imported from XML file are called External variables. These variables are read-only in this context. We can create a list of variable-value pairs in an external file in .xml format.
We can then select the file as the active external environment variable file for a test and use the variables from the file as parameters. The variables which are Imported from XML file are called External variables. These are read-only variables. u can modify name and value of these variables.
If you want to modify them..go to an XML file which is stored and right-click on that file click n edit. The script will open, there you can edit name and value.
We can set up your environment variable files manually, or we can define the variables in the Environment tab of the Test Settings dialogue box and use the Export button to create the file with the correct structure.
Environment.Value("name")= "abc" //'calling that veriable-- msgbox Environment.Value("name")
Steps to add user-defined environment variables in the script:
- Go to File
- Go to settings
- Go to Environment
- Select variable type as user-defined
- Click add icon (+)
- Enter variable name
- Enter variable Value
- Click ok
We can create any number of variables we want.
How to save environment variables in XML?
- Click export
- Provide path
- Provide file name
- Save with .xml extension
- Click ok.
You have done Built-In Variables are activated at runtime only. By using these variables we can know test execution or platform information. Variables that represent information about the test and the computer on which the test is run, such as Test path and Operating system. In other words, they are system variables. These variables are accessible from all tests but read-only It is activated during runtime. Test execution information can be retrieved through this variable
osVersion=Environment.Value("OSVersion") osName=Environment.Value("OS") toolName=Environment.Value("ProductName") toolVersion=Environment.Value("ProductVer") testName=Environment.Value("TestName")
There are so many on the list. commonly used Environment variable in UFT to track the iterations.
Good use of “TestIteration” built-in environment variable would be if you want to execute a specific section of Script based on the number of Iteration. For example, if the test runs the first iteration we want to execute Function A and 2nd iteration Function B.
How to Associate Environment Variable with our Script?
We need to follow the below steps in order to associate the environment variable to our script.
- Click File
- Go to settings
- Go to Environment
- Select variable type as user-defined
- Check “load variables and values from the external file”
- Provide the path of the XML file
- click apply
- Click on ok.
How to Associate Environment Variable with our Script dynamically?
The syntax for dynamic loading is as follows:
How to modify the Environment Variables?
As the environment variables stay in .xml file, we can use notepad or notepad++ or any XML editor to change the values.
How to read the runtime Test Iteration?
TestIteration is a built-in environment variable in Quick Test Professional, so we can read it using the Environment keyword. The syntax is below:
tIteration = Environment("TestIteration")
example of TestIteration use:
Using the If-Else statement
tIteration = Environment(?TestIteration?) If tIteration = 1 Then Call FunctionABC() ElseIf tIteration = 3 Then Call FunctionXYZ() End If
Note: Quick Test Pro (UFT) also have “ActionIteration” environment variable to read action iteration.
How can I check if an environment variable exists or not?
When we use Environment(“Param1”).value then UFT expects the environment variable to be already defined. But when we use Environment.value(“Param1”) then UFT will create a new internal environment variable if it does not exists already. So to be sure that variable exist in the environment try using Environment(“Param1”).value
Now you have configured the test and run on your machine …it is running fine. You have delivered your test to the client or the internal automation team for a QA review or a person is doing a review of the script. Will, it run properly? Or will he be able to check the script in his machine?
No…what went wrong…It will throw an error on this environment variable. This machine requires the variable to be configured and set as per your machine. Or else you need to document the entire variables used as an environment variable. Now go back to the 3 types of operations for the environment variable.
The last two operations is very much important for portability. If you export the variable list from your machine and hand it over, along with your script. The second person or whoever is running the script can make use of this. You are free from the documentation.
So here what exactly you are doing is ..you are saving the variable for future use. So you need to save those variable inside your permanent memory, not like a global variable used in program and vanishes after execution. Hence creating this lightweight .xml file.
Also, these variables can be added to the .txt file. Those are basically .ini file.
.ini stands for Initialization/Configuration File Various programs use this extension; Take clues from the location of the file as a possible pointer to exactly which program is producing the file. These files are typically ASCII text with various configuration options set into them.
Dim App ‘As Application ‘ Launch UFT Set App = CreateObject(“QuickTest.Application”) App.Launch App.Visible = True ‘ Load an INI file with user-defined parameters App.Test.Environment.LoadFromFile “C:Testenvironment_file1.ini” ‘ Set the value of a specific user-defined Environment variable App.Test.Environment.Value(“a_variable”) = “new value” '//As you can see from the example, the Environment variable file is actually an .ini file. // The structure would be: [Environment] variable1=value1 variable2=value2
Use of .INI file in UFT
It’s used to store user-defined external environment variables in 5x and 6x versions of UFT.
Because of the increased XML usage in all technologies from 8x, UFT has given a facility to store user-defined external environment variables in XML files. UFT is having backward compatibility so that it will support .INI files in latest versions of UFT.
How to store environment variables in INI files?
step1: open a notepad file
step2: on top of the file write [Environment]
step3: specify variable names and values
step4: Save it as .ini file
step5: Associate environment file in UFT
'************************************************************ [Environment] URL=www.google.com ScriptsPath=D:AutomationProject
We can load environment variables from an XML file.
File –> Settings and click the “Environment” tab
You can see a check box “Load environment variables ” check it and give the path of the XML file.
when u run UFT, the variables in the XML file will be available. And you can retrieve those values using Environment.value
(“variable_name”) from any actions. You can retrieve data from database(XML formet)..
Read more UFT related article here
We can use SQL like-
Select * FROM TableName For XML Type, AUTO
Dynamically you can access the XLM file as well….
Const XMLDataFile = "your file path"> Set xmlDoc = CreateObject("Microsoft.XMLDOM") xmlDoc.Async = False xmlDoc.Load(XMLDataFile) Set nodes = xmlDoc.SelectNodes(<provide hierarchy of node>) MsgBox "Total Students in class 10 " & nodes.Length Set nodes = xmlDoc.SelectNodes("<node hierarchy text()>") ' get their values For i = 0 To (nodes.Length - 1) Title = nodes(i).NodeValue MsgBox "Name #" & (i + 1) & ": " & Title Next
Inside your xml you will see the structure..
<name>No of student in class 10</name>
If this XML format is like this then we can write the script :
Environment.LoadFromFile("c:\data.xml") dataToCompare = Environment.Value("No of student in class 10") XMLpath =Environment.Value("UFTxmlPath") Environment.LoadFromFile =(XMLpath&"data.xml") TestCaseID=Environment.Value("No of student in class 10”)
The following example retrieves information from an external INI file using GetPrivateProfileString, and uses it in the test. Note the use of the micByRef flag to indicate the out argument
Extern.Declare micInteger,"GetPrivateProfileStringA", "kernel32.dll","GetPrivateProfileStringA", micString, micString, micString, micString+micByRef, micInteger, micString Dim key, i, key2 key = String(32, "-") i = Extern.GetPrivateProfileStringA("WREnv","addons","xxx", key, 32, "wrun.ini") key2 = Left(key,i) msgbox key2
Keyword Driven Framework and Environment Variable
In the keyword-driven framework, environment variable plays a bigger role to control the execution of UFT.
Some important settings are:
- Object synchronization timeout determination.
- When to define dynamically occurrence of an error during runtime.
- Ways to associate libraries with the main script.
- Define user variables to work as a global.
- How to associate the recovery scenarios.