160 x 600 Ad Section

MotherBoard Tips


A.) GENERAL TESTING TIPS.

Before you begin, download a few of our Diagnostic Software Tools to pinpoint possible problem areas in your PC. Ideally, troubleshooting is best accomplished with duplicate parts from a used computer enabling "test" swapping of peripheral devices/cards/chips/cables. In general, it is best to troubleshoot on systems that have been leaned-out. Remove unnecessary peripherals (soundcard, modem, harddisk, etc.) to check the unworking device in as much isolation as possible. Also, when swapping devices, don't forget the power supply. Power incompetency (watts and volts) can cause intermittent problems at all levels, but especially with UARTS and HD's.

Inspect the motherboard for loose components. A loose or missing CPU, BIOS chip, Crystal Oscillator, or Chipset chip will cause the motherboard not to function. Also check for loose or missing jumper caps, missing or loose memory chips (cache and SIMM's or DIMM's). To possibly save you hours of frustration i'll mention this here, check the BIOS Setup settings. 60% of the time this is the cause of many system failures. A quick fix is to restore the BIOS Defaults. Next, eliminate the possibility of interference by a bad or improperly set up I/O card by removing all cards except the video adapter. The system should at least power up and wait for a drive time-out. Insert the cards back into the system one at a time until the problem happens again. When the system does nothing, the problem will be with the last expansion card that was put in.

B.) RESETTING CMOS.

Did you recently 'flash' your computers BIOS, and needed to change a jumper to do so? Perhaps you left the jumper in the 'flash' position which could cause the CMOS to be erased.

If you require the CMOS Reset and don't have the proper jumper settings try these methods: Our Help Desk receives so many requests on Clearing BIOS?CMOS Passwords that we've put together a standard text outlining the various solutions.


C.) NO POWER.

Switching power supplies (the most common used PC's), cannot be adequately field-tested with V/OHM meters. Remember: for most switching power supplies to work, a FLOPPY and at least 1 meg of memory must be present on the motherboard. If the necessary components are present on the motherboard and there is no power:

1) check the power cable to the wall and that the wall socket is working. (You'd be surprised!)
2) swap power supply with one that is known to work.
3) if the system still doesn't work, check for fuses on the motherboard. If there are none, you must replace the motherboard.


D.) PERIPHERAL WON'T WORK.

Peripherals are any devices that are connected to the motherboard, including I/O boards, RS232/UART devices (including mice and modems), floppies and fixed-disks, video cards, etc. On modern boards, many peripherals are integrated into the motherboard, meaning, if one peripheral fails, effectually the motherboard has to be replaced.* On older boards, peripherals were added via daughter boards.

*some MB CMOS's allow for disabling on-board devices, which may be an option for not replacing the motherboard -- though, in practicality, some peripheral boards can cost as much, if not more, than the motherboard. Also, failure of on-board devices may signal a cascading failure to other components.
1. New peripheral?

a) Check the MB BIOS documentation/setup to ensure that the BIOS supports the device and that the MB is correctly configured for the device.
(Note>> when in doubt, reset CMOS to DEFAULT VALUES. These are ) (optimized for the most generalized settings that avoid some of) (the conflicts that result from improper 'tweaking'. )
b) Check cable attachments & orientation (don't just look, reattach!)
c) If that doesn't work, double-check jumper/PnP (including software and/or MB BIOS set) settings on the device.
d) If that doesn't work, try another peripheral of same brand & model that is known to work.
e) If the swap peripheral works, the original peripheral is most likely the problem. (You can verify this by testing the non-working peripheral on a test MB of the same make & bios.)
f) If the swap periphal doesn't on the MB, verify the functionality of the first peripheral on a test machine. If the first peripheral works on another machine AND IF the set-up of the motherboard BIOS is verified AND IF all potentially conflicting peripherals have been removed OR verified to not be in conflict, the motherboard is suspect. (However, see #D below.)
g) At this point, recheck MB or BIOS documentation to see if there are known bugs with the peripheral AND to verify any MB or peripheral jumper settings that are necessary for the particular peripheral to work. Also, try a different peripheral of the same kind but a different make to see if it works. If it does not, swap the motherboard. (However, see #D below.)


2. Peripheral that worked before?

a) If the hood has been opened (or even if it has not), check the orientation and/or seating of the cables. Cables sometimes 'shake' loose or are accidentally pulled out by end-users, who then misalign or do not reattach them.
b) If that doesn't work, try the peripheral in another machine of the same make & bios that is known to work. If the peripheral still doesn't work, the peripheral is most likely the problem. (This can be verified by swapping-in a working peripheral of the same make and model AND that is configured the same as the one that is not working. If it works, then the first peripheral is the problem.)
c) If the peripheral works on another machine, double-check other peripherals and/or potential conflicts on the MB, including the power supply. If none can be found, suspect the MB.
d) At this point, recheck MB or BIOS documentation to see if there are known bugs with the peripheral AND to verify any jumper settings that might be necessary for the particular peripheral. Also, try another peripheral of the same kind but a different make to see if it works. If not, swap the motherboard!


E.) OTHER INDICATIONS OF A PROBLEM MOTHERBOARD.

1. CLOCK that won't keep correct time. >>Be sure to check/change the battery.

2. CMOS that won't hold configuration information. >>Again, check/change the battery.

Note about batteries and CMOS: in theory, CMOS should retain configuration information even if the system battery is removed or dies. In practice, some systems rely on the battery to hold this information. On these systems, a machine that is not powered-up for a week or two may report improper BIOS configuration. To check this kind of system, change the battery, power-up and run the system for several hours. If the CMOS is working, the information should be retained with the system off for more than 24 hours.


F.) BAD MOTHERBOARD OR OBSOLETE BIOS?

1. If the motherboard cannot configure to a particular peripheral, don't automatically assume a bad motherboard, even if the peripheral checks out on another machine -- especially if the other machine has a different BIOS revision. Check with the board manufacturer to see if a BIOS upgrade is available. Many BIOS upgrades can be made right on the MB with a FLASH RAM program provided by the board maker.

Mandira BEDI IPL season 2



MANDIRA BEDI IN BIKINI (IPL SEASON 2)

Qtp Tutorials


Qtp Tutorials

QTP Tutorials 1 - Familarizing with Recording Process

QTP Tutorial 2 - Using Data Table

QTP Tutorial 3 - Accessing Data Table values through Script

QTP Tutorial 4 - Standard Checkpoint

QTP Tutorial 5 - Page Checkpoint

QTP Tutorial 6 - Database Checkpoint (using Oracle 9)

QTP Tutorial 7 - Bitmap Checkpoint

QTP Tutorial 8 - Image Checkpoint

QTP Tutorial 9 - Text Checkpoint

QTP Tutorial 10 - Table Checkpoint

QTP Tutorial 11 - Checkpoint Return Values

QTP Tutorial 12 - Reusable Actions

QTP Tutorial 13 - Importing Database Table

QTP Tutorial 14 - Script to create file

QTP Tutorial 15 - QTP Regular Expressions

QTP Tutorial 16 - QTP Recovery Scenarios

QTP Tutorial 17 - On Error Resume Next, Err Object

QTP Tutorial 18 - QTP Optional Step

QTP Tutorial 19 - Learn about QTP Menus

QTP Tutorial 20 - QTP Actions or Functions

QTP Tutorial 21 - QTP Object Repository or Descriptive Programming

QTP Tutorial 22 - QTP Virtual Objects

QTP Tutorial 23 - QTP Syntax Error

QTP Tutorial 24 - QTP SystemUtil Vs InvokeApplication with example

QTP Tutorial 25 - QTP Object Properties

QTP Tutorial 26 - Example of Existing Checkpoint

QTP Tutorial 27 - QuickTest Shortcut Keys Cheatsheet

QTP Tutorial 28- QTP API

QTP Tutorial 29 - Sharing Action Information

QTP Tutorial 30 - Software Automation Famework With Examples

QTP Tutorial 31 - Quicktest Debug Options Here

QTP Tutorial 32 - QTP Maintenance Run Mode - A new feature in QTP 9.5

QTP Tutorial 33 - Important Points About QTP Run Results (including ways to export QTP run results

QTP Tutorial 34 - Learn How to Use QTP Data Driver

WinRunner Faq's


WinRunner automated software functionality test tool from Mercury Interactive for functional and regression testing

Q: For new users, how to use WinRunner to test software applications automately ?
A: The following steps may be of help to you when automating tests
1. MOST IMPORTANT - write a set of manual tests to test your application - you cannot just jump in with WR and expect to produce a set of meaningful tests. Also as you will see from the steps below this set of manual tests will form your plan to tackle automation of your application.
2. Once you have a set of manual tests look at them and decide which ones you can automate using your current level of expertise. NOTE that there will be tests that are not suitable for automation, either because you can't automate them, or they are just not worth the effort.
3. Automate the tests selected in step 2 - initially you will use capture/replay using the steps in the manual test, but you will soon see that to produce meaningful and informative tests you need to add additional code to your test eg. use tl_step() to give test results. As this process continues you will soon see that there are operations that you repeatedly do in multiple tests - these are then candidates for user-defined functions and compiled modules
4. Once you have completed step 3 go back to step 2 and you will find that the knowledge you have gained in step 3 will now allow you to select some more tests that you can do.
If you continue going through this loop you will gradually become more familiar with WR and TSL, in fact you will probably find that eventually you do very little capture/replay and more straight TSL coding.

Q: How to use WinRunne to check whether the record was updated or the record was delelte or the record was inserted or not?
Using WinRunner check point features: Create->dDB checkpoint->Runtime Record check
Q: How to use WinRunner to test the login screen
A: When you enter wrong id or password, you will get Dialog box.
1. Record this Dialog box
2. User win_exists to check whether dialog box exists or not
3. Playback: Enter wrong id or password, if win_exists is
true, then your application is working good.
Enter good id or password, if win_exists is false,
then your application is working perfectly.

Q: After clicking on "login" button, they opens other windows of the web application, how to check that page is opened or not
When your expecting "Window1" to come up after clicking on Login...
Capture the window in the GUI Map. No two windows in an web based
application can have the same html_name property. Hence, this would
be the property to check.

First try a simple win_exists("window1", ) in an IF condition.

If that does'nt work, try the function,

win_exists("{ class: window, MSW_class: html_frame,
html_name: "window1"}",);

Q: Winrunner testscript for checking all the links at a time
location = 0;
set_window("YourWindow",5);

while(obj_exists((link = "{class: object,MSW_class: html_text_link,location: "
& location & "}"))== E_OK)
{
obj_highlight(link); web_obj_get_info(link,"name",name);
web_link_valid(link,valid);
if(valid)
tl_step("Check web link",PASS,"Web link \"" & name & "\" is valid.");
else
tl_step("Check web link",FAIL,"Web link \"" & name & "\" is not valid.");
location++;
}

Q: How to get the resolution settings
Use get_screen_res(x,y) to get the screen resolution in WR7.5.
or
Use get_resolution (Vert_Pix_int, Horz_Pix_int, Frequency_int) in WR7.01

Q: WITHOUT the GUI map, use the phy desc directly....
It's easy, just take the description straight out of the GUI map squigglies and
all, put it into a variable (or pass it as a string)
and use that in place of the object name.

button_press ( "btn_OK" );
becomes
button_press ( "{class: push_button, label: OK}" );

Q: What are the three modes of running the scripts?
WinRunner provides three modes in which to run tests: Verify, Debug, and Update. You use each mode during a different phase of the testing process.
Verify
Use the Verify mode to check your application.
Debug
Use the Debug mode to help you identify bugs in a test script.
Update
Use the Update mode to update the expected results of a test or to create a new expected results folder.

Q: How do you handle unexpected events and errors?
WinRunner uses exception handling to detect an unexpected event when it occurs and act to recover the test run.
WinRunner enables you to handle the following types of exceptions:
Pop-up exceptions: Instruct WinRunner to detect and handle the appearance of a specific window.
TSL exceptions: Instruct WinRunner to detect and handle TSL functions that return a specific error code.
Object exceptions: Instruct WinRunner to detect and handle a change in a property for a specific GUI object.
Web exceptions: When the WebTest add-in is loaded, you can instruct WinRunner to handle unexpected events and errors that occur in your Web site during a test run.

Q: How do you handle pop-up exceptions?
A pop-up exception Handler handles the pop-up messages that come up during the execution of the script in the AUT. TO handle this type of exception we make WinRunner learn the window and also specify a handler to the exception. It could be
Default actions: WinRunner clicks the OK or Cancel button in the pop-up window, or presses Enter on the keyboard. To select a default handler, click the appropriate button in the dialog box.
User-defined handler: If you prefer, specify the name of your own handler. Click User Defined Function Name and type in a name in the User Defined Function Name box.

Q: How do you handle TSL exceptions?
Suppose you are running a batch test on an unstable version of your application. If your application crashes, you want WinRunner to recover test execution. A TSL exception can instruct WinRunner to recover test execution by exiting the current test, restarting the application, and continuing with the next test in the batch.
The handler function is responsible for recovering test execution. When WinRunner detects a specific error code, it calls the handler function. You implement this function to respond to the unexpected error in the way that meets your specific testing needs.
Once you have defined the exception, WinRunner activates handling and adds the exception to the list of default TSL exceptions in the Exceptions dialog box. Default TSL exceptions are defined by the XR_EXCP_TSL configuration parameter in the wrun.ini configuration file.
Q: How to write an email address validation script in TSL?
public function IsValidEMAIL(in strText)
{
auto aryEmail[], aryEmail2[], n;


n = split(strText, aryEmail, "@");
if (n != 2)
return FALSE;

# Ensure the string "@MyISP.Com" does not pass...
if (!length(aryEmail[1]))
return FALSE;

n = split(aryEmail[2], aryEmail2, ".");
if (n < 2)
return FALSE;
# Ensure the string "Recipient@." does not pass...
if (!(length(aryEmai2[1]) * length(aryEmai2[1])))
return FALSE;

return TRUE;
}

Q: How to have winrunner insert yesterdays date into a field in the application?
1) Use get-time to get the PC system time in seconds since 01/01/1970

2)Subtract 86400 (no seconds in a day) from it

3)Use time_str to convert the result into a date format

4)If format of returned date is not correct use string manipulations to get
the format you require

5) Insert the date into your application


Alternatively you could try the following :

1) In an Excel datasheet create a column with an appropriate name, and in
the first cell of the column use the excel formula 'today() - 1'

2) Format the cell to give you the required date format

3) Use the ddt- functions to read the date from the excel datasheet

4) insert the reteived date into your application
Q: How can withwin runner to make single scripts which supports multiple languages?
Actually, you can have scripts that run for different locales.I have a set of scripts that run for Japanese as well as English Locales. Idea is to have objects recorded in GUI Map with a locale independent physical description. This can be achieved in two ways.
1. After recording the object in the GUI Map, inspect the description and ensure that no language specific properties are used. For ex: html_name property for an object of class: html_text_link could be based on the text. You can either remove these language dependent properties if it doesnt really affect your object recognition. If it does affect, you need to find another property for the object that is locale independent. This new property may be something thats already there or you need to create them. This leads to the next option.
2. Have developers assign a locale independent property like 'objname' or something to all objects that you use in your automated scripts. Now, modify your GUI Map description for the particular object to look for this property instead of the standard locale dependent properties recorded by WR (these default properties are in GUI Map Configuration).
or
You could also use a GUI map for each locale. Prefix the GUI map name with the locale (e.g. jpn_UserWindow.gui and enu_UserWindow.gui) and load the correct map based on the current machine locale. Specifically, you can use the get_lang() function to obtain the current language setting, then load the appropriate GUI map in your init script. Take a look at the sample scripts supplied with WinRunner (for the flight application). I think those scripts are created for both English and Japanese locales.

After taking care of different GUIs for different locales, the script also needs some modification. If you are scripting in English and then moving on to any other language (say Japanese), all the user inputs will be in English. Due to this the script will fail as it is expecting a Japanese input for a JPN language. Instead of using like that, assign all the user inputs to a variable and use the same wherever the script uses it. This variables has to be assigned (may be after the driver script) before you call the script which you want to run. You should have different variable scripts for different languages. Depending on the language you want to run, call the appropriate variable script file. This will help you to run the same script with different locale

Q: How to use a regular _expression in the physical description of a window in the GUI map?
Several web page windows with similar html names - they all end in or contain "| MyCompany" The GUI Map has saved the following physical description for one of these windows:
{
class: window,
html_name: "Dynamic Name | MyCompany"
MSW_class: html_frame
}

The "Dynamic Name " part of the html name changes with the different pages.

Replace:

{
class: window,
html_name: "!.*| MyCompany"
MSW_class: html_frame
}

Regular expressions in GUI maps always begin with "!".

Q: How to force WR to learn the sub-items on a menu...?
If WR is not learning sub-items then the easy way id to add manually those sub items in to GUI map.. of course you need to study the menu description and always add the PARENT menu name for that particular sub-menu..
Q: How to check property of specific Icon is highlighted or not?
set_window("Name of the window");
obj_check_info("Name of the object ","focused",0ut_value);

check for out_value & proceed further

Q: BitMap or GUI Checkpoints
DO NOT use BitMap or GUI Checkpoints for dynamic verification. These checkpoints are purely for static verifications. There are ofcourse, work-arounds, but mostly not worth the effort.

Q: How to to get the information from the status bar without doing any activity/click on the hyperlink?
You can use the "statusbar_get_text("Status Bar",0,text);" function
"text" variable contains the status bar statement.

or

web_cursor_to_link ( link, x, y );

link The name of the link.
x,y The x- and y-coordinates of the mouse pointer when moved to a link,
relative to the upper left corner of the link.

Q: Object name Changing dynamically?
1.
logicalname:"chkESActivity"
{
class: check_button,
MSW_class: html_check_button,
html_name: chkESActivity,
part_value: 90
}
2.
logical name "chkESActivity_1"

{
class: check_button,
MSW_class: html_check_button,
html_name: chkESActivity,
part_value: 91
}


Replace with:

Logical:"CheckBox" # you give any name as the logical name
{
class: check_button,
MSW_class: html_check_button,
html_name: chkESActivity,
part_value: "![0-9][0-9]" # changes were done here
}

you can use any of the checkbox command like
button_set("CheckBox",ON); # the above statement will check any check
box with part value ranging from 00 to 99

Q: Text Field Validations
Need to validate text fields against
1. Null
2. Not Null.
3. whether it allows any Special Characters.
4. whether it allows numeric contents.
5. Maximum length of the field etc.

1) From the requirements find out what the behaviour of the text field in
question should be. Things you need to know are :
what should happen if field left blank
what special characters are allowed
is it an alpha, nemeric or alphanumeric field etc.etc.

2) Write manual tests for doing what you want. This will create a structure
to form the basis of your WR tests.

3) now create your WR scripts. I suggest that you use data driven tests and
use Excel spreadsheets for your inputs instead of having user input.
For example the following structure will test whether the text field will
accept special characters :

open the data table
for each value in the data table
get value
insert value into text field
attempt to use the value inserted
if result is as expected
report pass
else
report fail
next value in data table

in this case the data table will contain all the special charcaters

Q: Loads multiple giumaps into an array
#GUIMAPS-------------------------------------------------------------------
static guiname1 = "MMAQ_guimap.gui";
static guiname2 = "SSPicker_guimap.gui";
static guiname3 = "TradeEntry.gui";
static guiLoad[] = {guiname1, guiname2, guiname3}

Then I just call the function:
#LOAD GUIMAP FILES VIA THE LOAD GUIMAP FUNCTION (this closes ALL open guimaps)
rc = loadGui(guiLoad);
if (rc != "Pass") #Check success of the Gui_Load
{
tl_step("Guiload",FAIL,"Failed to load Guimap(s)for "&testname(getvar));
#This line to test log
texit("Failed to load Guimap(s)for "&testname(getvar));
}

public function loadGui(inout guiLoad[])
{
static i;
static rc;

# close any temp GUI map files
GUI_close("");
GUI_close_all();

for(i in guiLoad)
{
rc = (GUI_load(GUIPATH & guiLoad[i]));
if ((rc != 0) && (rc != E_OK)) #Check the Gui_Load
{
return ("Failed to load " &guiLoad[i]);
}
}
return ("Pass");
}
Q: Read and write to the registry using the Windows API functions
function space(isize)
{
auto s;
auto i;
for (i =1;i<=isize;i++)
{
s = s & " ";

}
return(s);
}

load_dll("c:\\windows\\system32\\ADVAPI32.DLL");
extern long RegDeleteKey( long, string<1024> );
extern long RegCloseKey(long);
extern long RegQueryValueExA(long,string,long,long,inout string<1024>,inout long );
extern long RegOpenKeyExA(long,string,long ,long,inout long);
extern long RegSetValueExA(long,string,long,long,string,long);

MainKey = 2147483649; # HKEY_CURRENT_USER
SubKey = "Software\\TestConverter\\TCEditor\\Settings";
# This is where you set your subkey path
const ERROR_SUCCESS = 0;

const KEY_ALL_ACCESS = 983103;
ret = RegOpenKeyExA(MainKey, SubKey, 0, KEY_ALL_ACCESS, hKey); # open the
key
if (ret==ERROR_SUCCESS)
{
cbData = 256;
tmp = space(256);
KeyType = 0;
ret = RegQueryValueExA(hKey,"Last language",0,KeyType,tmp,cbData); # replace
"Last language" with the key you want to read
}
pause (tmp);
NewSetting = "SQABASIC";
cbData = length(NewSetting) + 1;
ret = RegSetValueExA(hKey,"Last language",0,KeyType,NewSetting,cbData);
# replace "Last language" with the key you want to write

cbData = 256;
tmp = space(256);
KeyType = 0;
ret = RegQueryValueExA(hKey,"Last language",0,KeyType,tmp,cbData);
# verifies you changed the key

pause (tmp);

RegCloseKey(hKey); # close the key

Q: How to break infinite loop
set_window("Browser Main Window",1);
text="";
start = get_time();
while(text!="Done")
{
statusbar_get_text("Status Bar",0,text);
now = get_time();
if ( (now-start) == 60 ) # Specify no of seconds after which u want
break
{
break;
}
}

Q: User-defined function that would write to the Print-log as well as write to a file
function writeLog(in strMessage){
file_open("C:\FilePath\...");
file_printf(strMessage);
printf(strMessage);
}
Q: How to do text matching?
You could try embedding it in an if statement. If/when it fails use a tl_step statement to indicate passage and then do a texit to leave the test. Another idea would be to use win_get_text or web_frame_get_text to capture the text of the object and the do a comparison (using the match function) to determine it's existance.

Q: the MSW_id value sometimes changes, rendering the GUI map useless
MSW_Id's will continue to change as long as your developers are modifying your application. Having dealt with this, I determined that each MSW_Id shifted by the same amount and I was able to modify the entries in the gui map rather easily and continue testing.
Instead of using the MSW_id use the "location". If you use your GUI spy it will give you every detail it can. Then add or remove what you don't want.

Q: Having the DB Check point, its able to show the current values in form but its not showing the values that saved in the table
This looks like its happening because the data has
been written to the db after your checkpoint, so you
have to do a runtime record check Create>Database
Checkpoint>Runtime Record Check. You may also have to
perform some customization if the data displayed in
the application is in a different format than the data
in the database by using TSL. For example, converting
radio buttons to database readable form involves the
following:

# Flight Reservation
set_window ("Flight Reservation", 2);
# edit_set ("Date of Flight:", "06/08/02");

# retrieve the three button states
button_get_state ( "First", first);
button_get_state ( "Business", bus);
button_get_state ( "Economy", econ);

# establish a variable with the correct numeric value
based on which radio button is set
if (first)
service="1";

if (bus)
service="2";

if (econ)
service="3";

set_window("Untitled - Notepad",3);

edit_set("Report Area",service);

db_record_check("list1.cvr", DVR_ONE_MATCH,record_num);
Increas Capacity Testing
When you begin your stress testing, you will want to increase your capacity testing to make sure you are able to handle the increased load of data such as ASP pages and graphics. When you test the ASP pages, you may want to create a page similar to the original page that will simulate the same items on the ASP page and have it send the information to a test bed with a process that completes just a small data output. By doing this, you will have your processor still stressing the system but not taking up the bandwidth by sending the HTML code along the full path. This will not stress the entire code but will give you a basis from which to work. Dividing the requests per second by the total number of user or threads will determine the number of transactions per second. It will tell you at what point the server will start becoming less efficient at handling the load. Let's look at an example. Let's say your test with 50 users shows your server can handle 5 requests per seconf, with 100 users it is 10 requests per second, with 200 users it is 15 requests per second, and eventually with 300 users it is 20 requests per second. Your requests per second are continually climbing, so it seems that you are obtaining steadily improving performance. Let's look at the ratios:
05/50 = 0.1
10/100 = 0.1
15/200 = 0.075
20/300 = 0.073
From this example you can see that the performance of the server is becoming less and less efficient as the load grows. This in itself is not necessarily bad (as long as your pages are still returning within your target time frame). However, it can be a useful indicator during your optimization process and does give you some indication of how much leeway you have to handle expected peaks.

Stateful testing
When you use a Web-enabled application to set a value, does the server respond correctly later on?

Privilage testing
What happens when the everyday user tries to access a control that is authorized only for adminstrators?

Speed testing
Is the Web-enabled application taking too long to respond?

Boundary Test
Boundary tests are designed to check a program's response to extreme input values. Extreme output values are generated by the input values. It is important to check that a program handles input values and output results correctly at the lower and upper boundaries. Keep in mind that you can create extreme boundary results from non-extreme input values. It is essential to analyze how to generate extremes of both types. In addition. sometime you know that there is an intermediate variable involved in processing. If so, it is useful to determine how to drive that one through the extremes and special conditions such as zero or overflow condition.

Boundary timeing testing
What happens when your Web-enabled application request times out or takes a really long time to respond?

Regression testing
Did a new build break an existing function? Repeat testing after changes for managing risk relate to product enhancement.
A regression test is performded when the tester wishes to see the progress of the testing processs by performing identical tests before and after a bug has been fixed. A regression test allows the tester to compare expeted test results with the actual results.
Regression testing's primary objective is to ensure that all bugfree features stay that way. In addition, bugs which have been fixed once should not turn up again in subsequent program versions.
Regression testing: After every software modification or before next release, we repeat all test cases to check if fixed bugs are not show up again and new and existing functions are all working correctly.
Regression testing is used to confirm that fixed bugs have, in fact, been fixed and that new bugs have not been introduced in the process, and that festures that were proven correctly functional are intact. Depending on the size of a project, cycles of regression testing may be perform once per milestone or once per build. Some bug regression testing may also be performed during each accceptance test cycle, forcusing on only the most important bugs. Regression tests can be automated.

CONDITIONS DURING WHICH REGRESSION TESTS MAY BE RUN
Issu fixing cycle. Once the development team has fixed issues, a regression test can be run t ovalidate the fixes. Tests are based on the step-by-step test casess that were originally reported:
• If an issue is confirmeded as fixed, then the issue report status should be changed to Closed.
• If an issue is confirmed as fixed, but with side effects, then the issue report status should be changed to Closed. However, a new issue should be filed to report the side effect.
• If an issue is only partially fixed, then the issue report resolution should be changed back to Unfixed, along with comments outlining the oustanding problems

Open-status regression cycle. Periodic regression tests may be run on all open issue in the issue-tracking database. During this cycle, issue status is confirmed either the report is reproducible as is with no modification, the report is reproducible with additional comments or modifications, or the report is no longer reproducible
Closed-fixed regression cycle. In the final phase of testing, a full-regression test cycle should be run to confirm the status of all fixed-closed issues.
Feature regression cycle. Each time a new build is cut or is in the final phase of testing depending on the organizational procedure, a full-regression test cycle should be run to confirm that the proven correctly functional features are still working as expected.

Database Testing
Items to check when testing a database
What to test Environment toola/technique
Seach results System test environment Black Box and White Box technique
Response time System test environment Sytax Testing/Functional Testing
Data integrity Development environment White Box testing
Data validity Development environment White Box testing

Q:How do you find an object in an GUI map?
The GUI Map Editor is been provided with a Find and Show Buttons.
To find a particular object in the GUI Map file in the application, select the object and click the Show window. This blinks the selected object.
To find a particular object in a GUI Map file click the Find button, which gives the option to select the object. When the object is selected, if the object has been learned to the GUI Map file it will be focused in the GUI Map file.

Q:What different actions are performed by find and show button?
To find a particular object in the GUI Map file in the application, select the object and click the Show window. This blinks the selected object.
To find a particular object in a GUI Map file click the Find button, which gives the option to select the object. When the object is selected, if the object has been learned to the GUI Map file it will be focused in the GUI Map file.

Q:How do you identify which files are loaded in the GUI map?
The GUI Map Editor has a drop down GUI File displaying all the GUI Map files loaded into the memory.

Q:How do you modify the logical name or the physical description of the objects in GUI map?
You can modify the logical name or the physical description of an object in a GUI map file using the GUI Map Editor.

Q:When do you feel you need to modify the logical name?
Changing the logical name of an object is useful when the assigned logical name is not sufficiently descriptive or is too long.

Q:When it is appropriate to change physical description?
Changing the physical description is necessary when the property value of an object changes.

Q:How WinRunner handles varying window labels?
We can handle varying window labels using regular expressions. WinRunner uses two hidden properties in order to use regular expression in an object’s physical description. These properties are regexp_label and regexp_MSW_class.
i. The regexp_label property is used for windows only. It operates behind the scenes to insert a regular expression into a window’s label description.
ii. The regexp_MSW_class property inserts a regular expression into an object’s MSW_class. It is obligatory for all types of windows and for the object class object.

Q:What is the purpose of regexp_label property and regexp_MSW_class property?
The regexp_label property is used for windows only. It operates behind the scenes to insert a regular expression into a window’s label description.
The regexp_MSW_class property inserts a regular expression into an object’s MSW_class. It is obligatory for all types of windows and for the object class object.

Q:How do you suppress a regular expression?
We can suppress the regular expression of a window by replacing the regexp_label property with label property.
Q:How do you copy and move objects between different GUI map files?
We can copy and move objects between different GUI Map files using the GUI Map Editor. The steps to be followed are:
1. Choose Tools - GUI Map Editor to open the GUI Map Editor.
2. Choose View - GUI Files.
3. Click Expand in the GUI Map Editor. The dialog box expands to display two GUI map files simultaneously.
4. View a different GUI map file on each side of the dialog box by clicking the file names in the GUI File lists.
5. In one file, select the objects you want to copy or move. Use the Shift key and or Control key to select multiple objects. To select all objects in a GUI map file, choose Edit - Select All.
6. Click Copy or Move.
7. To restore the GUI Map Editor to its original size, click Collapse.

Q:How do you select multiple objects during merging the files?
Use the Shift key and or Control key to select multiple objects. To select all objects in a GUI map file, choose Edit - Select All.

Q:How do you clear a GUI map files?
We can clear a GUI Map file using the Clear All option in the GUI Map Editor.

Q:How do you filter the objects in the GUI map?
GUI Map Editor has a Filter option. This provides for filtering with 3 different types of options.
1. Logical name displays only objects with the specified logical name.
2. Physical description displays only objects matching the specified physical description. Use any substring belonging to the physical description.
3. Class displays only objects of the specified class, such as all the push buttons.

Q:How do you configure GUI map?
1. When WinRunner learns the description of a GUI object, it does not learn all its properties. Instead, it learns the minimum number of properties to provide a unique identification of the object.
2. Many applications also contain custom GUI objects. A custom object is any object not belonging to one of the standard classes used by WinRunner. These objects are therefore assigned to the generic object class. When WinRunner records an operation on a custom object, it generates obj_mouse_ statements in the test script.
3. If a custom object is similar to a standard object, you can map it to one of the standard classes. You can also configure the properties WinRunner uses to identify a custom object during Context Sensitive testing. The mapping and the configuration you set are valid only for the current WinRunner session. To make the mapping and the configuration permanent, you must add configuration statements to your startup test script.

Q:What is the purpose of GUI map configuration?
GUI Map configuration is used to map a custom object to a standard object.

Q:How do you make the configuration and mappings permanent?
The mapping and the configuration you set are valid only for the current WinRunner session. To make the mapping and the configuration permanent, you must add configuration statements to your startup test script.

Q:What is the purpose of GUI spy?
Using the GUI Spy, you can view the properties of any GUI object on your desktop. You use the Spy pointer to point to an object, and the GUI Spy displays the properties and their values in the GUI Spy dialog box. You can choose to view all the properties of an object, or only the selected set of properties that WinRunner learns.
Q:What is the purpose of different record methods 1) Record 2) Pass up 3) As Object 4) Ignore.?
1) Record instructs WinRunner to record all operations performed on a GUI object. This is the default record method for all classes. (The only exception is the static class (static text), for which the default is Pass Up.)
2) Pass Up instructs WinRunner to record an operation performed on this class as an operation performed on the element containing the object. Usually this element is a window, and the operation is recorded as win_mouse_click.
3) As Object instructs WinRunner to record all operations performed on a GUI object as though its class were object class.
4) Ignore instructs WinRunner to disregard all operations performed on the class.

Q:How do you find out which is the start up file in WinRunner?
The test script name in the Startup Test box in the Environment tab in the General Options dialog box is the start up file in WinRunner.

Q:What are the virtual objects and how do you learn them?
• Applications may contain bitmaps that look and behave like GUI objects. WinRunner records operations on these bitmaps using win_mouse_click statements. By defining a bitmap as a virtual object, you can instruct WinRunner to treat it like a GUI object such as a push button, when you record and run tests.
• Using the Virtual Object wizard, you can assign a bitmap to a standard object class, define the coordinates of that object, and assign it a logical name.
To define a virtual object using the Virtual Object wizard:
1. Choose Tools > Virtual Object Wizard. The Virtual Object wizard opens. Click Next.
2. In the Class list, select a class for the new virtual object. If rows that are displayed in the window. For a table class, select the number of visible rows and columns. Click Next.
3. Click Mark Object. Use the crosshairs pointer to select the area of the virtual object. You can use the arrow keys to make precise adjustments to the area you define with the crosshairs. Press Enter or click the right mouse button to display the virtual object’s coordinates in the wizard. If the object marked is visible on the screen, you can click the Highlight button to view it. Click Next.
4. Assign a logical name to the virtual object. This is the name that appears in the test script when you record on the virtual object. If the object contains text that WinRunner can read, the wizard suggests using this text for the logical name. Otherwise, WinRunner suggests virtual_object, virtual_push_button, virtual_list, etc.
5. You can accept the wizard’s suggestion or type in a different name. WinRunner checks that there are no other objects in the GUI map with the same name before confirming your choice. Click Next.

Q:What are the two modes of recording?
There are 2 modes of recording in WinRunner
1. Context Sensitive recording records the operations you perform on your application by identifying Graphical User Interface (GUI) objects.
2. Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen.

Q:What is a checkpoint and what are different types of checkpoints?
Checkpoints allow you to compare the current behavior of the application being tested to its behavior in an earlier version.
You can add four types of checkpoints to your test scripts:
1. GUI checkpoints verify information about GUI objects. For example, you can check that a button is enabled or see which item is selected in a list.
2. Bitmap checkpoints take a snapshot of a window or area of your application and compare this to an image captured in an earlier version.
3. Text checkpoints read text in GUI objects and in bitmaps and enable you to verify their contents.
4. Database checkpoints check the contents and the number of rows and columns of a result set, which is based on a query you create on your database.

Q:What are data driven tests?
When you test your application, you may want to check how it performs the same operations with multiple sets of data. You can create a data-driven test with a loop that runs ten times: each time the loop runs, it is driven by a different set of data. In order for WinRunner to use data to drive the test, you must link the data to the test script which it drives. This is called parameterizing your test. The data is stored in a data table. You can perform these operations manually, or you can use the DataDriver Wizard to parameterize your test and store the data in a data table.

Q:What are the synchronization points?
Synchronization points enable you to solve anticipated timing problems between the test and your application. For example, if you create a test that opens a database application, you can add a synchronization point that causes the test to wait until the database records are loaded on the screen.
For Analog testing, you can also use a synchronization point to ensure that WinRunner repositions a window at a specific location. When you run a test, the mouse cursor travels along exact coordinates. Repositioning the window enables the mouse pointer to make contact with the correct elements in the window.
Q:What is parameterizing?
In order for WinRunner to use data to drive the test, you must link the data to the test script which it drives. This is called parameterizing your test. The data is stored in a data table.

Q:How do you maintain the document information of the test scripts?
Before creating a test, you can document information about the test in the General and Description tabs of the Test Properties dialog box. You can enter the name of the test author, the type of functionality tested, a detailed description of the test, and a reference to the relevant functional specifications document.

Q:What do you verify with the GUI checkpoint for single property and what command it generates, explain syntax?
You can check a single property of a GUI object. For example, you can check whether a button is enabled or disabled or whether an item in a list is selected. To create a GUI checkpoint for a property value, use the Check Property dialog box to add one of the following functions to the test script:
button_check_info
scroll_check_info
edit_check_info
static_check_info
list_check_info
win_check_info
obj_check_info
Syntax: button_check_info (button, property, property_value );
edit_check_info ( edit, property, property_value );

Q:What do you verify with the GUI checkpoint for object/window and what command it generates, explain syntax?
• You can create a GUI checkpoint to check a single object in the application being tested. You can either check the object with its default properties or you can specify which properties to check.
• Creating a GUI Checkpoint using the Default Checks
• You can create a GUI checkpoint that performs a default check on the property recommended by WinRunner. For example, if you create a GUI checkpoint that checks a push button, the default check verifies that the push button is enabled.
• To create a GUI checkpoint using default checks:
1. Choose Create - GUI Checkpoint - For Object/Window, or click the GUI Checkpoint for Object/Window button on the User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR OBJECT/WINDOW softkey in order to avoid extraneous mouse movements. Note that you can press the CHECK GUI FOR OBJECT/WINDOW softkey in Context Sensitive mode as well. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens on the screen.
2. Click an object.
3. WinRunner captures the current value of the property of the GUI object being checked and stores it in the test’s expected results folder. The WinRunner window is restored and a GUI checkpoint is inserted in the test script as an obj_check_gui statement Syntax: win_check_gui ( window, checklist, expected_results_file, time );
• Creating a GUI Checkpoint by Specifying which Properties to Check
• You can specify which properties to check for an object. For example, if you create a checkpoint that checks a push button, you can choose to verify that it is in focus, instead of enabled.
• To create a GUI checkpoint by specifying which properties to check:
• Choose Create - GUI Checkpoint - For Object/Window, or click the GUI Checkpoint for Object/Window button on the User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR OBJECT/WINDOW softkey in order to avoid extraneous mouse movements. Note that you can press the CHECK GUI FOR OBJECT/WINDOW softkey in Context Sensitive mode as well. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens on the screen.
• Double-click the object or window. The Check GUI dialog box opens.
• Click an object name in the Objects pane. The Properties pane lists all the properties for the selected object.
• Select the properties you want to check.
1. To edit the expected value of a property, first select it. Next, either click the Edit Expected Value button, or double-click the value in the Expected Value column to edit it.
2. To add a check in which you specify arguments, first select the property for which you want to specify arguments. Next, either click the Specify Arguments button, or double-click in the Arguments column. Note that if an ellipsis (three dots) appears in the Arguments column, then you must specify arguments for a check on this property. (You do not need to specify arguments if a default argument is specified.) When checking standard objects, you only specify arguments for certain properties of edit and static text objects. You also specify arguments for checks on certain properties of nonstandard objects.
3. To change the viewing options for the properties of an object, use the Show Properties buttons.
4. Click OK to close the Check GUI dialog box. WinRunner captures the GUI information and stores it in the test’s expected results folder. The WinRunner window is restored and a GUI checkpoint is inserted in the test script as an obj_check_gui or a win_check_gui statement. Syntax: win_check_gui ( window, checklist, expected_results_file, time ); obj_check_gui ( object, checklist, expected results file, time );
Q:What do you verify with the GUI checkpoint for multiple objects and what command it generates, explain syntax?
To create a GUI checkpoint for two or more objects:
• Choose Create GUI Checkpoint For Multiple Objects or click the GUI Checkpoint for Multiple Objects button on the User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR MULTIPLE OBJECTS softkey in order to avoid extraneous mouse movements. The Create GUI Checkpoint dialog box opens.
• Click the Add button. The mouse pointer becomes a pointing hand and a help window opens.
• To add an object, click it once. If you click a window title bar or menu bar, a help window prompts you to check all the objects in the window.
• The pointing hand remains active. You can continue to choose objects by repeating step 3 above for each object you want to check.
• Click the right mouse button to stop the selection process and to restore the mouse pointer to its original shape. The Create GUI Checkpoint dialog box reopens.
• The Objects pane contains the name of the window and objects included in the GUI checkpoint. To specify which objects to check, click an object name in the Objects pane. The Properties pane lists all the properties of the object. The default properties are selected.
1. To edit the expected value of a property, first select it. Next, either click the Edit Expected Value button, or double-click the value in the Expected Value column to edit it.
2. To add a check in which you specify arguments, first select the property for which you want to specify arguments. Next, either click the Specify Arguments button, or double-click in the Arguments column. Note that if an ellipsis appears in the Arguments column, then you must specify arguments for a check on this property. (You do not need to specify arguments if a default argument is specified.) When checking standard objects, you only specify arguments for certain properties of edit and static text objects. You also specify arguments for checks on certain properties of nonstandard objects.
3. To change the viewing options for the properties of an object, use the Show Properties buttons.
• To save the checklist and close the Create GUI Checkpoint dialog box, click OK. WinRunner captures the current property values of the selected GUI objects and stores it in the expected results folder. A win_check_gui statement is inserted in the test script.
Syntax: win_check_gui ( window, checklist, expected_results_file, time );
obj_check_gui ( object, checklist, expected results file, time );

Q:What information is contained in the checklist file and in which file expected results are stored?
The checklist file contains information about the objects and the properties of the object we are verifying.
The gui*.chk file contains the expected results which is stored in the exp folder

Q:What do you verify with the bitmap check point for object/window and what command it generates, explain syntax?
• You can check an object, a window, or an area of a screen in your application as a bitmap. While creating a test, you indicate what you want to check. WinRunner captures the specified bitmap, stores it in the expected results folder (exp) of the test, and inserts a checkpoint in the test script. When you run the test, WinRunner compares the bitmap currently displayed in the application being tested with the expected bitmap stored earlier. In the event of a mismatch, WinRunner captures the current actual bitmap and generates a difference bitmap. By comparing the three bitmaps (expected, actual, and difference), you can identify the nature of the discrepancy.
• When working in Context Sensitive mode, you can capture a bitmap of a window, object, or of a specified area of a screen. WinRunner inserts a checkpoint in the test script in the form of either a win_check_bitmap or obj_check_bitmap statement.
• Note that when you record a test in Analog mode, you should press the CHECK BITMAP OF WINDOW softkey or the CHECK BITMAP OF SCREEN AREA softkey to create a bitmap checkpoint. This prevents WinRunner from recording extraneous mouse movements. If you are programming a test, you can also use the Analog function check_window to check a bitmap.
• To capture a window or object as a bitmap:
1. Choose Create - Bitmap Checkpoint - For Object/Window or click the Bitmap Checkpoint for Object/Window button on the User toolbar. Alternatively, if you are recording in Analog mode, press the CHECK BITMAP OF OBJECT/WINDOW softkey. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens.
2. Point to the object or window and click it. WinRunner captures the bitmap and generates a win_check_bitmap or obj_check_bitmap statement in the script. The TSL statement generated for a window bitmap has the following syntax: win_check_bitmap ( object, bitmap, time );
3. For an object bitmap, the syntax is: obj_check_bitmap ( object, bitmap, time );
4. For example, when you click the title bar of the main window of the Flight Reservation application, the resulting statement might be: win_check_bitmap ("Flight Reservation", "Img2", 1);
5. However, if you click the Date of Flight box in the same window, the statement might be: obj_check_bitmap ("Date of Flight:", "Img1", 1);
Syntax: obj_check_bitmap ( object, bitmap, time [, x, y, width, height] );

Q:What do you verify with the bitmap checkpoint for screen area and what command it generates, explain syntax?
• You can define any rectangular area of the screen and capture it as a bitmap for comparison. The area can be any size: it can be part of a single window, or it can intersect several windows. The rectangle is identified by the coordinates of its upper left and lower right corners, relative to the upper left corner of the window in which the area is located. If the area intersects several windows or is part of a window with no title (for example, a popup window), its coordinates are relative to the entire screen (the root window).
• To capture an area of the screen as a bitmap:
1. Choose Create - Bitmap Checkpoint - For Screen Area or click the Bitmap Checkpoint for Screen Area button. Alternatively, if you are recording in Analog mode, press the CHECK BITMAP OF SCREEN AREA softkey. The WinRunner window is minimized, the mouse pointer becomes a crosshairs pointer, and a help window opens.
2. Mark the area to be captured: press the left mouse button and drag the mouse pointer until a rectangle encloses the area; then release the mouse button.
3. Press the right mouse button to complete the operation. WinRunner captures the area and generates a win_check_bitmap statement in your script.
4. The win_check_bitmap statement for an area of the screen has the following syntax: win_check_bitmap ( window, bitmap, time, x, y, width, height );
Q:What do you verify with the database checkpoint default and what command it generates, explain syntax?
• By adding runtime database record checkpoints you can compare the information in your application during a test run with the corresponding record in your database. By adding standard database checkpoints to your test scripts, you can check the contents of databases in different versions of your application.
• When you create database checkpoints, you define a query on your database, and your database checkpoint checks the values contained in the result set. The result set is set of values retrieved from the results of the query.
• You can create runtime database record checkpoints in order to compare the values displayed in your application during the test run with the corresponding values in the database. If the comparison does not meet the success criteria you
• specify for the checkpoint, the checkpoint fails. You can define a successful runtime database record checkpoint as one where one or more matching records were found, exactly one matching record was found, or where no matching records are found.
• You can create standard database checkpoints to compare the current values of the properties of the result set during the test run to the expected values captured during recording or otherwise set before the test run. If the expected results and the current results do not match, the database checkpoint fails. Standard database checkpoints are useful when the expected results can be established before the test run.
Syntax: db_check(checklist_file, expected_restult);
• You can add a runtime database record checkpoint to your test in order to compare information that appears in your application during a test run with the current value(s) in the corresponding record(s) in your database. You add runtime database record checkpoints by running the Runtime Record Checkpoint wizard. When you are finished, the wizard inserts the appropriate db_record_check statement into your script.
Syntax: db_record_check(ChecklistFileName,SuccessConditions,RecordNumber );
ChecklistFileName ---- A file created by WinRunner and saved in the test's checklist folder. The file contains information about the data to be captured during the test run and its corresponding field in the database. The file is created based on the information entered in the Runtime Record Verification wizard.
SuccessConditions ----- Contains one of the following values:
1. DVR_ONE_OR_MORE_MATCH - The checkpoint passes if one or more matching database records are found.
2. DVR_ONE_MATCH - The checkpoint passes if exactly one matching database record is found.
3. DVR_NO_MATCH - The checkpoint passes if no matching database records are found.
RecordNumber --- An out parameter returning the number of records in the database.

Q:How do you handle dynamically changing area of the window in the bitmap checkpoints?
The difference between bitmaps option in the Run Tab of the general options defines the minimum number of pixels that constitute a bitmap mismatch

Q:What do you verify with the database check point custom and what command it generates, explain syntax?
• When you create a custom check on a database, you create a standard database checkpoint in which you can specify which properties to check on a result set.
• You can create a custom check on a database in order to:
• check the contents of part or the entire result set
• edit the expected results of the contents of the result set
• count the rows in the result set
• count the columns in the result set
• You can create a custom check on a database using ODBC, Microsoft Query or Data Junction.

Q:What do you verify with the sync point for object/window property and what command it generates, explain syntax?
• Synchronization compensates for inconsistencies in the performance of your application during a test run. By inserting a synchronization point in your test script, you can instruct WinRunner to suspend the test run and wait for a cue before continuing the test.
• You can a synchronization point that instructs WinRunner to wait for a specified object or window to appear. For example, you can tell WinRunner to wait for a window to open before performing an operation within that window, or you may want WinRunner to wait for an object to appear in order to perform an operation on that object.
• You use the obj_exists function to create an object synchronization point, and you use the win_exists function to create a window synchronization point. These functions have the following syntax:
obj_exists ( object [, time ] ); win_exists ( window [, time ] );

Q:What do you verify with the sync point for object/window bitmap and what command it generates, explain syntax?
You can create a bitmap synchronization point that waits for the bitmap of an object or a window to appear in the application being tested.
During a test run, WinRunner suspends test execution until the specified bitmap is redrawn, and then compares the current bitmap with the expected one captured earlier. If the bitmaps match, then WinRunner continues the test.
Syntax:
obj_wait_bitmap ( object, image, time );
win_wait_bitmap ( window, image, time );

Q:What is the purpose of obligatory and optional properties of the objects?
For each class, WinRunner learns a set of default properties. Each default property is classified obligatory or optional.
1. An obligatory property is always learned (if it exists).
2. An optional property is used only if the obligatory properties do not provide unique identification of an object. These optional properties are stored in a list. WinRunner selects the minimum number of properties from this list that are necessary to identify the object. It begins with the first property in the list, and continues, if necessary, to add properties to the description until it obtains unique identification for the object.

Q:When the optional properties are learned?
An optional property is used only if the obligatory properties do not provide unique identification of an object.

Q:What is the purpose of location indicator and index indicator in GUI map configuration?
In cases where the obligatory and optional properties do not uniquely identify an object, WinRunner uses a selector to differentiate between them. Two types of selectors are available:
A location selector uses the spatial position of objects.
The location selector uses the spatial order of objects within the window, from the top left to the bottom right corners, to differentiate among objects with the same description.
An index selector uses a unique number to identify the object in a window.
The index selector uses numbers assigned at the time of creation of objects to identify the object in a window. Use this selector if the location of objects with the same description may change within a window.

Q:How do you handle custom objects?
A custom object is any GUI object not belonging to one of the standard classes used by WinRunner. WinRunner learns such objects under the generic object class. WinRunner records operations on custom objects using obj_mouse_ statements.
If a custom object is similar to a standard object, you can map it to one of the standard classes. You can also configure the properties WinRunner uses to identify a custom object during Context Sensitive testing.

Q:What is the name of custom class in WinRunner and what methods it applies on the custom objects?
WinRunner learns custom class objects under the generic object class. WinRunner records operations on custom objects using obj_ statements.

Q:In a situation when obligatory and optional both the properties cannot uniquely identify an object what method WinRunner applies?
In cases where the obligatory and optional properties do not uniquely identify an object, WinRunner uses a selector to differentiate between them. Two types of selectors are available:
i. A location selector uses the spatial position of objects.
ii. An index selector uses a unique number to identify the object in a window.

Q:What do you verify with the sync point for screen area and what command it generates, explain syntax?
For screen area verification we actually capture the screen area into a bitmap and verify the application screen area with the bitmap file during execution Syntax: obj_wait_bitmap(object, image, time, x, y, width, height);

Q:How do you edit checklist file and when do you need to edit the checklist file?
WinRunner has an edit checklist file option under the create menu. Select the Edit GUI Checklist to modify GUI checklist file and Edit Database Checklist to edit database checklist file. This brings up a dialog box that gives you option to select the checklist file to modify. There is also an option to select the scope of the checklist file, whether it is Test specific or a shared one. Select the checklist file, click OK which opens up the window to edit the properties of the objects.
Q:How do you edit the expected value of an object?
We can modify the expected value of the object by executing the script in the Update mode. We can also manually edit the gui*.chk file which contains the expected values which come under the exp folder to change the values.

Q:How do you modify the expected results of a GUI checkpoint?
We can modify the expected results of a GUI checkpoint be running the script containing the checkpoint in the update mode.

Q:How do you handle ActiveX and Visual basic objects?
WinRunner provides with add-ins for ActiveX and Visual basic objects. When loading WinRunner, select those add-ins and these add-ins provide with a set of functions to work on ActiveX and VB objects.

Q:How do you create ODBC query?
We can create ODBC query using the database checkpoint wizard. It provides with option to create an SQL file that uses an ODBC DSN to connect to the database. The SQL File will contain the connection string and the SQL statement.

Q:How do you record a data driven test?
We can create a data-driven testing using data from a flat file, data table or a database.
Using Flat File: we actually store the data to be used in a required format in the file. We access the file using the File manipulation commands, reads data from the file and assign the variables with data.
Data Table: It is an excel file. We can store test data in these files and manipulate them. We use the ‘ddt_*’ functions to manipulate data in the data table.
Database: we store test data in the database and access these data using ‘db_*’ functions.

Q:How do you convert a database file to a text file?
You can use Data Junction to create a conversion file which converts a database to a target text file.

Q:How do you parameterize database check points?
When you create a standard database checkpoint using ODBC (Microsoft Query), you can add parameters to an SQL statement to parameterize the checkpoint. This is useful if you want to create a database checkpoint with a query in which the SQL statement defining your query changes.

Q:How do you create parameterize SQL commands?
A parameterized query is a query in which at least one of the fields of the WHERE clause is parameterized, i.e., the value of the field is specified by a question mark symbol ( ? ). For example, the following SQL statement is based on a query on the database in the sample Flight Reservation application:
SELECT Flights.Departure, Flights.Flight_Number, Flights.Day_Of_Week FROM Flights Flights WHERE (Flights.Departure=?) AND (Flights.Day_Of_Week=?)
SELECT defines the columns to include in the query.
FROM specifies the path of the database.
WHERE (optional) specifies the conditions, or filters to use in the query. Departure is the parameter that represents the departure point of a flight.
Day_Of_Week is the parameter that represents the day of the week of a flight.
When creating a database checkpoint, you insert a db_check statement into your test script. When you parameterize the SQL statement in your checkpoint, the db_check function has a fourth, optional, argument: the parameter_array argument. A statement similar to the following is inserted into your test script:
db_check("list1.cdl", "dbvf1", NO_LIMIT, dbvf1_params);
The parameter_array argument will contain the values to substitute for the parameters in the parameterized checkpoint.
Q:What check points you will use to read and check text on the GUI and explain its syntax?
• You can use text checkpoints in your test scripts to read and check text in GUI objects and in areas of the screen. While creating a test you point to an object or a window containing text. WinRunner reads the text and writes a TSL statement to the test script. You may then add simple programming elements to your test scripts to verify the contents of the text.
• You can use a text checkpoint to:
• Read text from a GUI object or window in your application, using obj_get_text and win_get_text
• Search for text in an object or window, using win_find_text and obj_find_text
• Move the mouse pointer to text in an object or window, using obj_move_locator_text and win_move_locator_text
• Click on text in an object or window, using obj_click_on_text and win_click_on_text

Q:How to get Text from object/window ?
We use obj_get_text (logical_name, out_text) function to get the text from an object
We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.

Q:How to get Text from screen area ?
We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.

Q:Which TSL functions you will use for Searching text on the window
find_text ( string, out_coord_array, search_area [, string_def ] );
win_find_text ( window, string, result_array [, search_area [, string_def ] ] );

Q:What are the steps of creating a data driven test?
The steps involved in data driven testing are:
Creating a test
Converting to a data-driven test and preparing a database
Running the test
Analyzing the test results.

Q: How to use data driver wizard?
You can use the DataDriver Wizard to convert your entire script or a part of your script into a data-driven test. For example, your test script may include recorded operations, checkpoints, and other statements that do not need to be repeated for multiple sets of data. You need to parameterize only the portion of your test script that you want to run in a loop with multiple sets of data.
To create a data-driven test:
• If you want to turn only part of your test script into a data-driven test, first select those lines in the test script.
• Choose Tools - DataDriver Wizard.
• If you want to turn only part of the test into a data-driven test, click Cancel. Select those lines in the test script and reopen the DataDriver Wizard. If you want to turn the entire test into a data-driven test, click Next.
• The Use a new or existing Excel table box displays the name of the Excel file that WinRunner creates, which stores the data for the data-driven test. Accept the default data table for this test, enter a different name for the data table, or use
• The browse button to locate the path of an existing data table. By default, the data table is stored in the test folder.
• In the Assign a name to the variable box, enter a variable name with which to refer to the data table, or accept the default name, table.
• At the beginning of a data-driven test, the Excel data table you selected is assigned as the value of the table variable. Throughout the script, only the table variable name is used. This makes it easy for you to assign a different data table
• To the script at a later time without making changes throughout the script.
• Choose from among the following options:
1. Add statements to create a data-driven test: Automatically adds statements to run your test in a loop: sets a variable name by which to refer to the data table; adds braces ({and}), a for statement, and a ddt_get_row_count statement to your test script selection to run it in a loop while it reads from the data table; adds ddt_open and ddt_close statements
2. To your test script to open and close the data table, which are necessary in order to iterate rows in the table. Note that you can also add these statements to your test script manually.
3. If you do not choose this option, you will receive a warning that your data-driven test must contain a loop and statements to open and close your datatable.
4. Import data from a database: Imports data from a database. This option adds ddt_update_from_db, and ddt_save statements to your test script after the ddt_open statement.
5. Note that in order to import data from a database, either Microsoft Query or Data Junction must be installed on your machine. You can install Microsoft Query from the custom installation of Microsoft Office. Note that Data Junction is not automatically included in your WinRunner package. To purchase Data Junction, contact your Mercury Interactive representative. For detailed information on working with Data Junction, refer to the documentation in the Data Junction package.
6. Parameterize the test: Replaces fixed values in selected checkpoints and in recorded statements with parameters, using the ddt_val function, and in the data table, adds columns with variable values for the parameters. Line by line: Opens a wizard screen for each line of the selected test script, which enables you to decide whether to parameterize a particular line, and if so, whether to add a new column to the data table or use an existing column when parameterizing data.
7. Automatically: Replaces all data with ddt_val statements and adds new columns to the data table. The first argument of the function is the name of the column in the data table. The replaced data is inserted into the table.
• The Test script line to parameterize box displays the line of the test script to parameterize. The highlighted value can be replaced by a parameter. The Argument to be replaced box displays the argument (value) that you can replace with a parameter. You can use the arrows to select a different argument to replace.
Choose whether and how to replace the selected data:
1. Do not replace this data: Does not parameterize this data.
2. An existing column: If parameters already exist in the data table for this test, select an existing parameter from the list.
3. A new column: Creates a new column for this parameter in the data table for this test. Adds the selected data to this column of the data table. The default name for the new parameter is the logical name of the object in the selected. TSL statement above. Accept this name or assign a new name.
• The final screen of the wizard opens.
1. If you want the data table to open after you close the wizard, select Show data table now.
2. To perform the tasks specified in previous screens and close the wizard, click Finish.
3. To close the wizard without making any changes to the test script, click Cancel.
Q: How do you handle object exceptions?
During testing, unexpected changes can occur to GUI objects in the application you are testing. These changes are often subtle but they can disrupt the test run and distort results.
You could use exception handling to detect a change in property of the GUI object during the test run, and to recover test execution by calling a handler function and continue with the test execution

Q: What is a compile module?
A compiled module is a script containing a library of user-defined functions that you want to call frequently from other tests. When you load a compiled module, its functions are automatically compiled and remain in memory. You can call them directly from within any test.
Compiled modules can improve the organization and performance of your tests. Since you debug compiled modules before using them, your tests will require less error-checking. In addition, calling a function that is already compiled is significantly faster than interpreting a function in a test script.

Q: What is the difference between script and compile module?
Test script contains the executable file in WinRunner while Compiled Module is used to store reusable functions. Complied modules are not executable.
WinRunner performs a pre-compilation automatically when it saves a module assigned a property value of Compiled Module.
By default, modules containing TSL code have a property value of "main". Main modules are called for execution from within other modules. Main modules are dynamically compiled into machine code only when WinRunner recognizes a "call" statement. Example of a call for the "app_init" script:
call cso_init();
call( "C:\\MyAppFolder\\" & "app_init" );
Compiled modules are loaded into memory to be referenced from TSL code in any module. Example of a load statement:
reload (C:\\MyAppFolder\\" & "flt_lib");
or load ("C:\\MyAppFolder\\" & "flt_lib");

Q:How do you write messages to the report?
To write message to a report we use the report_msg statement
Syntax: report_msg (message);

Q:What is a command to invoke application?
Invoke_application is the function used to invoke an application.
Syntax: invoke_application(file, command_option, working_dir, SHOW);

Q:What is the purpose of tl_step command?
Used to determine whether sections of a test pass or fail.
Syntax: tl_step(step_name, status, description);

Q:Which TSL function you will use to compare two files?
We can compare 2 files in WinRunner using the file_compare function. Syntax: file_compare (file1, file2 [, save file]);

Q:What is the use of function generator?
The Function Generator provides a quick, error-free way to program scripts. You can:
Add Context Sensitive functions that perform operations on a GUI object or get information from the application being tested.
Add Standard and Analog functions that perform non-Context Sensitive tasks such as synchronizing test execution or sending user-defined messages to a report.
Add Customization functions that enable you to modify WinRunner to suit your testing environment.

Q:What is the use of putting call and call_close statements in the test script?
You can use two types of call statements to invoke one test from another:
A call statement invokes a test from within another test.
A call_close statement invokes a test from within a script and closes the test when the test is completed.
Q:What is the use of treturn and texit statements in the test script?
The treturn and texit statements are used to stop execution of called tests.
i. The treturn statement stops the current test and returns control to the calling test.
ii. The texit statement stops test execution entirely, unless tests are being called from a batch test. In this case, control is returned to the main batch test.
Both functions provide a return value for the called test. If treturn or texit is not used, or if no value is specified, then the return value of the call statement is 0.
The syntax is: treturn [( expression )]; texit [( expression )];

Q:What does auto, static, public and extern variables means?
auto: An auto variable can be declared only within a function and is local to that function. It exists only for as long as the function is running. A new copy of the variable is created each time the function is called.
static: A static variable is local to the function, test, or compiled module in which it is declared. The variable retains its value until the test is terminated by an Abort command. This variable is initialized each time the definition of the function is executed.
public: A public variable can be declared only within a test or module, and is available for all functions, tests, and compiled modules.
extern: An extern declaration indicates a reference to a public variable declared outside of the current test or module.

Q:How do you declare constants?
The const specifier indicates that the declared value cannot be modified. The class of a constant may be either public or static. If no class is explicitly declared, the constant is assigned the default class public. Once a constant is defined, it remains in existence until you exit WinRunner.
The syntax of this declaration is: [class] const name [= expression];

Q:How do you declare arrays?
The following syntax is used to define the class and the initial expression of an array. Array size need not be defined in TSL.
class array_name [ ] [=init_expression]
The array class may be any of the classes used for variable declarations (auto, static, public, extern).

Q:How do you load and unload a compile module?
In order to access the functions in a compiled module you need to load the module. You can load it from within any test script using the load command; all tests will then be able to access the function until you quit WinRunner or unload the compiled module.
You can load a module either as a system module or as a user module. A system module is generally a closed module that is invisible to the tester. It is not displayed when it is loaded, cannot be stepped into, and is not stopped by a pause command. A system module is not unloaded when you execute an unload statement with no parameters (global unload).
load (module_name [,1|0] [,1|0] );
The module_name is the name of an existing compiled module.
Two additional, optional parameters indicate the type of module. The first parameter indicates whether the function module is a system module or a user module: 1 indicates a system module; 0 indicates a user module.
(Default = 0)
The second optional parameter indicates whether a user module will remain open in the WinRunner window or will close automatically after it is loaded: 1 indicates that the module will close automatically; 0 indicates that the module will remain open.
(Default = 0)
The unload function removes a loaded module or selected functions from memory.
It has the following syntax:
unload ( [ module_name | test_name [ , "function_name" ] ] );

Q:Why you use reload function?
If you make changes in a module, you should reload it. The reload function removes a loaded module from memory and reloads it (combining the functions of unload and load).
The syntax of the reload function is:
reload ( module_name [ ,1|0 ] [ ,1|0 ] );
The module_name is the name of an existing compiled module.
Two additional optional parameters indicate the type of module. The first parameter indicates whether the module is a system module or a user module: 1 indicates a system module; 0 indicates a user module.
(Default = 0)
The second optional parameter indicates whether a user module will remain open in the WinRunner window or will close automatically after it is loaded. 1 indicates that the module will close automatically. 0 indicates that the module will remain open.
(Default = 0)

Q:Write and explain compile module?
Write TSL functions for the following interactive modes:
i. Creating a dialog box with any message you specify, and an edit field.
ii. Create dialog box with list of items and message.
iii. Create dialog box with edit field, check box, and execute button, and a cancel button.
iv. Creating a browse dialog box from which user selects a file.
v. Create a dialog box with two edit fields, one for login and another for password input.

Q:How you used WinRunner in your project?
Yes, I have been using WinRunner for creating automated scripts for GUI, functional and regression testing of the AUT.
Q:Explain WinRunner testing process?
WinRunner testing process involves six main stages
Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested
Create test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where you want to check the response of the application being tested.
Debug Test: run tests in Debug mode to make sure they run smoothly
Run Tests: run tests in Verify mode to test your application.
View Results: determines the success or failure of the tests.
Report Defects: If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window.

Q:What is contained in the GUI map?
WinRunner stores information it learns about a window or object in a GUI Map. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested. Each of these objects in the GUI Map file will be having a logical name and a physical description. There are 2 types of GUI Map files. Global GUI Map file: a single GUI Map file for the entire application. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.

Q:How does WinRunner recognize objects on the application?
WinRunner uses the GUI Map file to recognize objects on the application. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested.

Q:Have you created test scripts and what is contained in the test scripts?
Yes I have created test scripts. It contains the statement in Mercury Interactive’s Test Script Language (TSL). These statements appear as a test script in a test window. You can then enhance your recorded test script, either by typing in additional TSL functions and programming elements or by using WinRunner’s visual programming tool, the Function Generator.

Q:How does WinRunner evaluate test results?
Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window.

Q:Have you performed debugging of the scripts?
Yes, I have performed debugging of scripts. We can debug the script by executing the script in the debug mode. We can also debug script using the Step, Step Into, Step out functionalities provided by the WinRunner.

Q:How do you run your test scripts?
We run tests in Verify mode to test your application. Each time WinRunner encounters a checkpoint in the test script, it compares the current data of the application being tested to the expected data captured earlier. If any mismatches are found, WinRunner captures them as actual results.

Q:How do you analyze results and report the defects?
Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window. If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window. This information is sent via e-mail to the quality assurance manager, who tracks the defect until it is fixed.

Q:What is the use of Test Director software?
TestDirector is Mercury Interactive’s software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create a database of manual and automated tests, build test cycles, run tests, and report and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software release.

Q:Have you integrated your automated scripts from TestDirector?
When you work with WinRunner, you can choose to save your tests directly to your TestDirector database or while creating a test case in the TestDirector we can specify whether the script in automated or manual. And if it is automated script then TestDirector will build a skeleton for the script that can be later modified into one which could be used to test the AUT. What are the different modes of recording? - There are two type of recording in WinRunner. Context Sensitive recording records the operations you perform on your application by identifying Graphical User Interface (GUI) objects. Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen.
Q:What is the purpose of loading WinRunner Add-Ins?
Add-Ins are used in WinRunner to load functions specific to the particular add-in to the memory. While creating a script only those functions in the add-in selected will be listed in the function generator and while executing the script only those functions in the loaded add-in will be executed else WinRunner will give an error message saying it does not recognize the function. What are the reasons that WinRunner fails to identify an object on the GUI? - WinRunner fails to identify an object in a GUI due to various reasons. The object is not a standard windows object. If the browser used is not compatible with the WinRunner version, GUI Map Editor will not be able to learn any of the objects displayed in the browser window.

Q:What is meant by the logical name of the object?
An object’s logical name is determined by its class. In most cases, the logical name is the label that appears on an object.

Q:If the object does not have a name then what will be the logical name?
If the object does not have a name then the logical name could be the attached text.

Q:What is the different between GUI map and GUI map files?
The GUI map is actually the sum of one or more GUI map files. There are two modes for organizing GUI map files. Global GUI Map file: a single GUI Map file for the entire application. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created. GUI Map file is a file which contains the windows and the objects learned by the WinRunner with its logical name and their physical description.

Q:How do you view the contents of the GUI map?
GUI Map editor displays the content of a GUI Map. We can invoke GUI Map Editor from the Tools Menu in WinRunner. The GUI Map Editor displays the various GUI Map files created and the windows and objects learned in to them with their logical name and physical description.

Q:How do you view the contents of the GUI map?
If we are learning a window then WinRunner automatically learns all the objects in the window else we will we identifying those object, which are to be learned in a window, since we will be working with only those objects while creating scripts.

Q:How to compare value of textbox in WinRunner?
the problem: textbox on page 1. then after clicking 'Submit' button, value of textbox will be display on page 2 as static. How to compare value of textbox from page 1 if it is equal to on page 2?
Capture the value from textbox in page 1 and store in a variable (like a). Then after clicking on submit button when the value is diplaying on page 2 as static. From here using screen area (get text) text point, capture the value and store in second variable (like b). Now compare two variables.
Winrunner with combo box
Problem: Application has combo box which has some values need to select item 4 in first combo box to run the test Scenario. How to get the value of the selected combo box?

Answer1:
Use the GUI spy and compare the values in the SPY with the values in the GUI map for the physical attributes of the TComboBox_* objects. It appears to me that WinRunner is recording an attribute to differentiate combobox_1 from _0 that is *dynamic* rather than static. You need to find a physical property of all the comboboxes that is constant and unique for each combobox between refreshes of the app. (handle is an example of a BAD one). That's the property you need to have recorded in your GUI map (in addition to those physical properties that were recorded for the first combobox that was recorded.

Answer2:
Go through the following script, it will help .....

function app_data(dof)
{
report_msg ("application data entry");
set_window ("Flight Reservation", 6);
list_get_items_count ("Fly From:" , flyfromc);
list_get_items_count ("Fly To:" , flytoc);
report_msg (flyfromc);
report_msg (flytoc);
for (i =0; i < flyfromc; i++)
{
#for (j=0;j < flytoc-1; j++)
for (j=0;j < flytoc-1; j++)
{
m=0;
do
{
menu_select_item("File;New Order");
edit_set ("Date of Flight:", dof);
obj_type ("Date of Flight:","");
list_select_item ("Fly From:","#"i);
# Item Number 0;
obj_type ("Fly From:","");
list_select_item ("Fly To:", "#"j);
# Item Number 0;
obj_mouse_click ("FLIGHT", 42, 20,LEFT);
set_window ("Flights Table", 1);
list_get_items_count ("Flight" ,flightc);
list_activate_item ("Flight", "#"m);
# Item Number 1;
set_window ("Flight Reservation",5);
edit_set ("Name:", "ajay");
button_press ("Insert Order");
m++;
}while ( a < flightc);
report_msg (j);
}
report_msg (i);
}
}

WinRunner: How to Set GUI file's searchpath?
[GUI file at d:\1\2\3\4\windows.gui
How to use the script bellow to load the GUI file successfully.?
#load gui file
GUI_unload_all;
if(GUI_load("windows.gui")!=0)
{
pause("can not open \"windows.gui\" File");
texit;
}
#end loading gui

Put all the scripts at localmachine but GUI files at TD Server ,Used command line to run my scripts(successfully).
When update Winrunner 7.6 Version to 8.2 and connect to TD Server,now it seems that wrun.exe couldn't find localmachine's scripts, anyone knows wrun.exe command-line mode's new parameters(in WINRUNNER 8.2 Ver.)?

Answer1:
GUI_load("C:\\Program Files\\Mercury
Interactive\\WinRunner\\EMR\\EMR.gui");
in your winrunner startup file, you can set the path for this startup file in general options->startup
#load gui file
GUI_unload_all;
if(GUI_load("C:\\Program Files\\Mercury Interactive\\WinRunner\\EMR\\EMR.gui")!=0)
{
pause("unable to open C:\\Program Files\\Mercury
Interactive\\WinRunner\\EMR\\EMR.gui");
texit;
}
#end loading gui
you cant set path for GUI map file in winruner other than Temporary GUI Map File

Answer2:
Might suggest to your boss that the GUI is universal to all machines in spite of the fact that all machines must have their own local script in his view. Even if you are testing different versions of the same software, you can have the local machine "aware" of what software version it is running and know what GUI to load from you server. I run a lab with 30 test machines, each with their own copy of the script(s) from the server, but using one master GUI per software roll.
As far as how to set search path for the local machine, you can force that in the setup of each machine. Go to Tools=>Options=>General Options=> Folders. Once there, you can add, delete or move folders around at will. WinRunner will search in the order in which they are listed, from top down. "Dot" means search in the current directory, whatever that may be at the time.

Q: WinRunner: How to check the tab order?
winrunner sample application
set_window ("Flight Reservation", 7);
if(E_OK==obj_type ("Date of Flight:","")){
if(E_OK==obj_type ("Fly From:","")){
if(E_OK==obj_type ("Fly To:","")){
if(E_OK==obj_type ("Name:","")){
if(E_OK==obj_type ("Date ofFlight:","")) { report_msg("Ok");
}
}
}
}

Q:WinRunner: Why "Bitmap Check point" is not working with Framework?
Bitmap chekpoint is dependent on the monitor resolution. It depends on the machine on which it has been recorded. Unless you are using a machine with a screen of the same resolution and settings , it will fail. Run it in update mode on your machine once. It will get updated to your system and then onwards will pass.

Q: How to Plan automation testing to to impliment keyword driven methodology in testing automation using winrunner8.2?
Keyword-driven testing refers to an application-independent automation framework. This framework requires the development of data tables and keywords, independent of the test automation tool used to execute them and the test script code that "drives" the application-under-test and the data. Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.
Suppose you want to test a simple application like Calculator and want to perform 1+3=4, then you require to design a framework as follows:

Window->Calculator ; Control->Pushbutton ; Action-> Push; Argument->1
Window->Calculator ; Control->Pushbutton ; Action-> Push; Argument->+
Window->Calculator ; Control->Pushbutton ; Action-> Push; Argument->3
Window->Calculator ; Control->Pushbutton ; Action-> Push; Argument->=
Window->Calculator ; Action-> Verify; Argument->4

Steps are associated with the manual test case execution. Now write functions for all these common framework required for your test caese. Your representation may be different as per your requirement and used tool.
Q: How does winrunner invoke on remote machine?
Steps to call WinRunner in remote machine:
1) Send a file to remote machine particular folder (this may contains your test parameters)
2) write a shell script listener & keep always running the remotehost (this script will watching the file in folder mentioned in step 1)
3) write a batch file to invoke the winrunner, test name & kept it in remote machine
4) call the batch file thru shell script whenever the file exist as mentioned in step1

Q: WinRunner: How to connect to ORACLE Database without TNS?

The following code would help the above problem.
tblName = getvar("curr_dir")&table;
ddt_close_all_tables();
resConnection = "";
db_disconnect("session");
rc = ddt_open(tblName, DDT_MODE_READ);
if (rc != E_OK)
pause("Unable to open file");
else
{
dvr = ddt_val(tblName,"DRIVERNAME");
tnsName = ddt_val(tblName,"SERVER");
user = tolower(ddt_val(tblName,"UID"));
pass = tolower(ddt_val(tblName,"PWD"));
host = ddt_val(tblName,"HOSTNAME");
port = ddt_val(tblName,"PORT");
pro = toupper(ddt_val(tblName,"PROTOCOL"));
resConnection = db_connect("session", "driver="dvr";Database="tnsName";hostname="host";port="port";protocol="pro";
uid="user"; pwd="pass";");

if (resConnection != 0)
{
report_msg("There is a problem in connecting to the Database = "&tnsName&", Check it please..");
treturn;
}
else
{
report_msg("Connection to the Database is successful..");
rsEQ1 = db_execute_query("session","your database query",record_number1);
}
db_disconnect("session");
}
How to use this:
Assume you have saved the script in c:\winrunner as dbconnect
Save data table at same location, ie c:\winrunner as dbdetails.xls

give call to dbconnect from other script which aslo saved at same location
c:\winrunner as ==>call dbconnect("dbdetails.xls");
Because the above script is using getvar("curr_dir") function to get the current directory, looks at the same location for data table.

Q: WinRunner: How to Verify the data in excel spread sheet
[ A list box which is displaying report names and below that there is a multi line text box provided which is displaying the description of the report corresponding to each report. Able get all the descriptions by using below for loop. But have to verify against excel spread sheet where report descriptions are stored . please guide "how to proceed?"

list_get_info("Listbox1","count",count);
for(num = 1; num < count; num++)
{
row = num + 1;
list_select_item("Listbox1", "#"&num);
list_get_info("Listbox1","value",val);
report_msg(val);
edit_get_text("Textarea1",s) ;
report_msg(s);
}
#Open the excel spread sheet
# suppose spread sheet having 2 fields, Report_name and report_des
table = "E:\\test\\Datadriven\\default.xls";
rc = ddt_open(table, DDT_MODE_READ);
if (rc!= E_OK && rc != E_FILE_OPEN)
{
#loop the list box items
for(num = 0; num < count; num++)
{
list_get_info("Listbox1","value",val);
ddt_get_row_count(table,table_RowCount);
for(table_Row = 1; table_Row <= table_RowCount; table_Row ++)
{
ddt_set_row(table,table_Row);
report_name = ddt_val(table, "report_name");
if ( val == report_name)
{
report_des = ddt_val(table, "report_des");
# Compare the report description
}
}
}
}

Q: WinRunner: While invoking Win Runner, the error message displays
"The testing tool will be terminated because an error has occured.
Please look at the file:
C:\DOCUME~1\ADMI~1\LOCALS~1 \Temp\wrstderr
for more details."
Go to processes TAB on Task Manager panel and kill following processes
wrun.exe
crvw.exe
six_agnt.exe and wowexec.exe
Kill NTVDM.EXE and CRVW.EXE processes from task manager.

Once you have killed the winrunner process you need to remove the icon from the windows task bar which causes this error.Once done you can safely restart winrunner

Q: WinRunner: How to use data driven technology in GUI Check points for Objects ?
Here is a sample code which writen for web enviourment
web_obj_get_text("Client Name","#1","#3",text," "," ",1);
if(text==ddt_val(table,"WaveDesc")){
report_msg("done");
}
else
{
report_msg("Not Done");
}
so in each recursion it will check the text with data stored in the excell sheet. And the report's result will give a progress.

Q: How to handle 'Timeout expired' problem in WinRunner when dealingwith Complex SQL Queries??
While creating DSN which option you have selected for authenticity. If you have selected Windows NT authentication then no need to Enter userId and password or if you have selected SQL Server authentication then you need to enter userID and password during DSN creation it self.
Enter database user name and password while creating DSN. the script as follows:-
dbstatus = db_connect("GetRecs", "DSN=dsn name", 30);
if (dbstatus !=0)
{
report_msg ("GetRecs-FAILED-Could not open Database");
treturn("Stop");
}
Q: WinRunner: How to generate user name uniquely?
There are a couple of ways of dealing with this problem. One way is to maintain a file with the 'last value used' in it and just keep it up to date. If it's a data driven test, this value could even be in the data table. Alternately, you can always use the 'time' element as the value added to your string. That way you're always assured of a new number.

Q: Unable to print a newline character [\n] in file, any solution?
file_printf (, "%s\r\n", text);

Q: How to define the variable in script that have stored in excel sheet using winrunner?
[In A1 field contains {Class:push button, lable:OK.....}
In B1 field Contains OK = button_press(OK);
where OK contains the value of field A1
OK should act as a variable which has to contain value of field A1]

Answer1:
There is no need to define any variable that is going to use in the Testscript. You can just start using it directly.
So, if you want to assign a value to the dynamic variable which is taken from Data Table, then you can use the "eval" function for this.
Example:
eval( ddt_val(Table,"Column1") & "=\"water\";" );
# The above statement takes the variable name from Data table and assigns "water" as value to it.


Answer2:
Write a function that looked down a column in a table and then grabbed the value in the next cell and returned it. However, you would then need to call
button_press(tbl_convert("OK"));
rather than
button_press("OK");
where tbl_convert takes the value from the A1 (in your example) and returns the value in B1.
One other difficulty you would have would be if you wanted to have the same name for objects from different windows (e.g., an "OK" button in multiple windows). You could expand your function to handle this by having a separate column that carries the window name.

Q: WinRunner: How to Change physical description? [problem: the application containes defferent objects , but the location property is different/changing. Suppose for example, there is one html table and it contains objects and it's phisical properties,
for one object
{
class: object,
MSW_class: html_text_link,
html_name: "View/Edit"
location:0
}
and for other objects.
{
class: object,
MSW_class: html_text_link,
html_name: "View/Edit"
location:1
}
When record the scripts its gives viwe/edit as logical name,
Code: web_image_click("view/edit", 11, 7);
When run the script win runner cannot identifies which object to click and it gives an error Msg.
P.S. WinRunner 7.5 with Java and web addins on Windows XP operating system and IE 6.0 browser(SP2).

Answer1:
In dynamically changing the name of the html_table, we have to interchange the physical description. while recording the clicked name inside the table will be the name of the html_table in GUI Map. Change the logical name alone in GUI map. then in coding using the methods in gui_ get the logical name of this html_table.get its physical description.delete the Object thru coding from the Gui map.Then with the logical name and physical description you got previously , add these description using Gui_add methods.

Answer2:
Just change the logical names to unique names.
winrunner will recognize each object separately using the physical name and the location property.


Answer3:
i = 0;
web_link_click("{ class: object, MSW_class: html_text_link, html_name: \"View/Edit\", location:" & i & "}";
i = 1;
web_link_click("{ class: object, MSW_class: html_text_link, html_name: \"View/Edit\", location:" & i & "}";

Q: Is there any function in winrunner which will clear the history of the browser?
[Actually the script is working fine when you execute for the first time. But when you execute in the second time it is directly going inside the application without asking for login credentials by taking the path from the browser history. So the script fails. It is working fine if I clear the history of the browser before each run. ]
This is not the matter of clearing the history. In any case it should not allow you to login to application with entering login credentials. I think this is application bug.
To clear history:
DOS_system with
del "C:\Documents and Settings\%USERNAME%
\Cookies"\*your_cookie\site_name*

Q: WinRunner: How to read dynamic names of html_link

Answer1:
Use the following steps:
1) Using the Function, web_tbl_get_cell_data read the link.
2) use GUI_add function to add to the Map editor.
3) use GUI_save function to save the same link.
4) Now, web_link_click() and pass the variable that you got in step

Answer2:
Can try this method. It will reduce the complexity and there is no need to update the GUI Map File. Use web_tbl_get_cell_data() function to get the Description of the link and use the variable name in web_link_click() function.
web_tbl_get_cell_data("Tablename","#Rowno","#columnnumber",0,cell_value,cell_val\ ue_len);
web_link_click(cell_value);

Answer3:
1.get number of row in your table: tbl_get_rows_count ("tableName",rows);
2.write a for loop: for(i=0;i<=row;i++)
3.get text of specified cell with column and row:tbl_get_cell_data ("Name","#"&i,column,var1);
4.compare with the if condition
5.if true : make any flage and take row number in variable m
6.now end the loop and write
tbl_set_selected_cell ( "tableName", "#"& m,column);
type ("");
Example:
tbl_get_cols_count("Name",cols);
tbl_get_rows_count("Name",rows);
for(i=2;i<=rows;i++)
{
for(j=1;j<=cols;j++)
{
tbl_get_cell_data("Name","#"&i,"#"&j,var1);
if(var1 == Supplier)
{
m=i;
}
}
}
tbl_set_selected_cell ( "Name", "#"&m,"#"&j type ("");
Q: Is it possible to use winrunner for testing .aspx forms or dotnet forms?
You can't test dot net application using winrunner 7.6 and also from prior version. Because winrunner do not have addin for dot net.
ASP.NET forms it is a code for server side part of an application, if it generates on the front end normal HTML/JavaScript/Java/ActiveX it shouldn't be a problem to test the application using WR.

Q: Can WinRunner put the test results in a file?
Yes, You can put the results into the file format. (the file extension is .txt) In Test Results window, you can select one option:
tools menu text report then we can get a text file.
Another option is to write out the results out into a html file.

WinRunner: What is the difference between virtual object and custom object?

Answer1:
The virtual object is an object which is not recognized by Winrunner. The virtual object class like obj_mouse_click which works for that instance only. To work at any time, then we should forcibly to instruct the winrunner to recognize the virtual object with the help of Virtual Object Wizard.
Note: the virtual object must be mapped to a relavant standard classes only avail in winruuner. Ex: button (which is avail on the toolbar in a app. window) which is to be mapped to the standard class callled PUSH_BUTTON. when its completed then u can observe the TSL statment would be button_press("logicalName") which is permanent one in u r winrunner.
GUI map Configuration:
It helps when winrunner is not able locate the object by winruuner. for ex : two or more objects will have same logical name and its physical properties then how winrunner locate the specific object. In which case that should instruct the winrunner to unquely identify the specific object by setting obligatory, optional and MS_WID with the help of GUI Map config.

Answer2:
we use the virtual object wizard in winrunner to map the bitmap object while recording winrunner generates the obj_mouse_click.
Custom object is an object which do not belong to one of the standard class of winrunner. We use the gui map configuration to map the custom object to standard object of the winrunner.

Answer3:
virtual object - image or portion of the window are made virtual object to use functions available for the object just for convenience in scripting.
virtual object captures the cordinates of the object.
custom object - general object which does not belong to winrunner class, we map this general object to winrunner standard object, i.e. custom object.

Q: How to create an Object of an Excel File in WinRunner?
The object part, or actual Excel table is created via the WinRunner Data Table and it is stored inside the same directory that the WinRunner script is stored in. Of course you may create the Excle spreadsheet yourself and reference it from your script manually. This is also mentioned in the User Guide.
The Data Table Wizard mentioned earlier will link this object to the script and assist in parameterizing the data from the Excel table object.

Q: How to use values returned by VB script in winrunner?
From your VB script create a file system object to write output to a text file:
Dim fso, MyFile
Set fso = CreateObject("Scripting.FileSystemObject")
Set MyFile = fso.CreateTextFile("c:\testfile.txt", True)
MyFile.WriteLine("This is a test.")
MyFile.Close
Then use file_open and file_getline functions in WinRunner to read the file.

Q: WinRunner: What tag is required to allow me to identify a html table?

.
Indeed, it is better to ask developer to put ID every place where it is possible. It will avoid lots of trouble and help the resuable of your script (consider localization).

Q: WinRunner: How to work with file type using WinRunner functions?
When recording, WinRunner does not record file-type objects. However, you can manually insert file-type statements into your test script using the web_file_browse and web_file_set functions.
Q: WinRunner: Do Java Add-Ins required for Web based Application?
You do not need any Java add-in to tests simple JSP pages. If you are using Java applets with some swing or awt components drawn on the applet then you need java add-in otherwise simple web add-in will server the purpose.

Q: How to generate unique name?
function unique_str()
{
auto t, tt, leng, i;
t = get_time();
leng = length(t);
tt = "";
for (i = 1; i <= leng; i++)
{
tt = tt & (sprintf("%c", 97 + i + substr(t, i, 1)) );
}
return tt;
}

Q; WinRunner: How to access the last window brought up? [set_window("{class: window, active: 1}");
rc = win_get_info("{class: window, active: 1}", property, result);
Is there something or some script that can determine the LAST WINDOW DISPLAYED or OPENED on the desktop and in order to use that information to gather the label.
there are a couple of solutions, depending on what you know about the window. If you know distinguishing characteristics of the window, use them and just directly describe the gui attributes. I assume that you do not have these, or you would likely have already done so.
If not, there is a brute force method. Iterate over all of the open windows prior to the new window opening and grab their handles. After your new window opens, iterate again. The 'extra' handle points to your new window. You can use it in the gui description directly to manipulate the new window. As I said, a bit brutish, but it works. You can use the same technique when you have multiple windows with essentially the same descriptors and need to iterate over them in the order in which they appeared.
Any object (or window) can be described by it's class and it's iterator. Ask yourself, if I wanted to address each of the individuals in a room and had no idea what their names were, but would like to do so in a consistent way would it not be sufficient to say - 'person who came into the room first', 'person who came into the room second', or alternately 'person who is nearest the front on the left', 'person who is second nearest the front on the left'. These are perfectly good ways of describing the individuals because we do two things: limit the elements we want to describe (people) and then give an unambiguous way of enumerating them.
So, to apply this to your issue - you want to do an 'exist' on a dynamically described element (window, in your case). So you make a loop and ask 'window # 0, do you exist', if the answer is yes, you ask for the handle, store it and repeat the loop.
Eventually you get to window n, you ask if it exists, the answer is no and you now have a list of all of the handles of all of the existing windows.. You should note that there will be n windows ( 0 to n-1, makes a count of n).
You may need to brush up on programmatically describing an object (or window), the syntax is a little lengthy but extremely useful once you get the feel for it. It really frees you from only accessing objects that are already described in the gui map.
Try this as a starting point, you'll need to add storing & sorting the handles yourself:
i = 0;
finished = FALSE;
while (finished == FALSE)
{
if (win_exists("{class: window, location: \"" & i & "\"}\"") == E_OK )
{
win_get_info("{class: window, location: \"" & i & "\"}\"", "handle", handle);
printf(" handle was " & handle);
i ++;
}
else
{
finished = TRUE;
}
}
Q: WinRunner: How to identifying dynamic objects in web applications ?
Check whether the object is present inside the table. If yes then the get the table name and the location of that object. Then by using web_obj_get_child_item function you can get the description of the Object. Once you get the Description then you can do any operation on that object.

Q: WinRunner: How to delete files from drive?
Here is a simple method using dos.
where speech_path_file is a variable.
example:
# -- initialize vars
speech_path_file = "C:\\speech_path_verified.txt";
.
.
dos_system("del " & speech_path_file);

Q: WinRunner: Could do we start automation before getting the build?
The manual test cases should be written BEFORE the application is available, so does the automation process. automation itself is a development process, you do start the development BEFORE everything is ready, you can start to draw the structure and maybe some basic codes. And there are some benefits of having automation start early, e.g., if two windows have same name and structure and you think it is trouble, you may ask developer to put some unique identifiers, for example, a static which has different MSW_id). If you (& your boss) really treat the automation as the part of development, you should start this as early as possible, in this phase it likes the analyse and design phase of the product.

Q: How to create a GUI map dynamically?
gmf = "c:\\new_file_name.gui";
GUI_save_as ( "", gmf );

rc = GUI_add(gmf, "First_Window" , "" , "");
rc = GUI_add(gmf, "First_Window" , "new_obj" , "");
rc = GUI_add(gmf, "First_Window" , "new_obj" , "{label: Push_Me}");
Q: WinRunner script for Waitbusy
# only need to load once, best in startup script or wherever load( getenv("M_ROOT") & "\\lib\\win32api", 1, 1 );
# returns 1 if app has busy cursor, 0 otherwise public function IsBusy(hwnd) {const HTCODE=33554433;
# 0x2000001 const WM_SETCURSOR=32;

return SendMessageLong(hwnd, WM_SETCURSOR, hwnd, HTCODE);

# wait for app to not be busy, optional timeout public function WaitBusy(hwnd, timeout) {const HTCODE=33554433;

# 0x2000001 const WM_SETCURSOR=32;
if(timeout) timeout *= 4;
while(--timeout)
{
if (SendMessageLong(hwnd, WM_SETCURSOR, hwnd, HTCODE) == 0) return E_OK;
wait(0,250);

# 1/4 second }
return -1;

# timeout error code }

# wait busy, provide window instead of hwnd public function WinWaitBusy(win, timeout){auto hwnd
; win_get_info(win, "handle", hwnd);
return WaitBusy(hwnd, timeout); }

# example of how to use it... set_window(win); WinWaitBusy(win);

Q: WinRunner script to get Min and Max
public function fnMinMaxWinrunner (in action)
{
auto handle;
const SW_MAXIMIZE = 3;
const SW_MINIMIZE = 6;
load_dll("user32.dll");
#extern int ShowWindow(long, int);
win_get_info("{class: window, label: \"!WinRunner.*\"}", "handle", handle);
switch(action)
{
case "SW_MINIMIZE" :
{
# Maximizing WinRunner
ShowWindow(handle, SW_MINIMIZE);
wait(2);
break;
}
case "SW_MAXIMIZE" :
{ # Maximizing WinRunner
ShowWindow(handle, SW_MAXIMIZE);
wait(2);
break;
}
}
unload_dll("user32.dll");
};

Q: Type special chars in WinRuneer
type special chars as they are, instead of interpreting them
# data can be read from a data file and then typed into an app
#
# escape the following chars: <> - +
# in a string, quote " and backslash \ will already be escaped
#
# generally won't be a lot of special chars, so
# use index instead of looping through each character
#
function no_special(data )
{
auto esc_data, i, p;
esc_data = "";
while(1)
{
p=32000;
i=index(data,"-");
p=i?(ii=index(data,"+");
p=i?(ii=index(data,"<");
p=i?(ii=index(data,">");
p=i?(iif (p<32000)
{
esc_data = esc_data substr(data,1,p-1) "\\" substr(data,p,1);
data = substr(data,p+1);
}
else break;
}
esc_data = esc_data data;
return esc_data;
}
# trial run here
data = "This -- is +the+ new test sample";
win_activate("Untitled - Notepad");
win_type("Untitled - Notepad", no_special(data));

Q: Clean up script/function from WinRunner
public function cleanup(in win)
{
auto i;
auto edit;
auto atti;
set_window(win);
for (i = 0 ; ; i++)
{
edit = "{class:edit,index:"i"}";
if (obj_exists(edit) != E_OK)
break;
obj_get_info(edit,"displayed",atti);
if (atti == 0)
break;
obj_get_info(edit,"enabled",atti);
if (atti == 0)
continue;
edit_get_text(edit,atti);
if (atti != "")
edit_set_text(edit,"");
}
}


Q: How to convert variable from ascii to string?
If you want to generate characters from their ascii codes, you can use the sprintf() function, example:
sprintf("%c",65) will generate "A"
If you want to add a number onto the end of a string, you can simply stick it next to the string, example:
ball=5;
print "and the winning number is: " ball;
Putting them together can get some interesting effects, example:
public arr[] = {72,101,108,108,111,32,102,114,111,109,32,77,105,115,104,97};
msg = "";
for(i in arr) msg = msg sprintf("%c",arr[i]);
print msg;
Hmmm, interesting effect from the elements not being in order. I'll try it again:
msg = "";
for(i=0;i<16;i++) msg = msg sprintf("%c",arr[i]);
print msg;

The script for WinRunner Database Functions
==========================================
The script for WinRunner Database Functions
by Amit Kulkarni
# Pre-requisites:
# ---------------
# Requires a Variable / Constant "gstrConnString" defined in your
# calling script / startup which holds the ODBC connection string
# How To Use:
# -----------
# Save this file as a compiled module in your search path.
# use load() OR reload() for using this script in the test or another function.
# define a variable/constant gstrConnString in your calling script/
# startup and put the ODBC connection string in this variable. eg.
# gstrConnString ="DRIVER={Oracle in OraHome92};SERVER=MANOJ; UID=BASECOLL;PWD=BASECOLL;DBA=W;APA=T;EXC=F; XSM=Default;FEN=T;QTO=T;FRC=10;FDL=10;LOB=T;RST=T;GDE=F;FRL=Lo; BAM=IfAllSuccessful;MTS=F;MDI=Me;CSR=F;FWC=F;PFC=10;TLO=O;";
# This is the string that I use; declaration is in Startup Script and get the value
# from configuration.xls
#
# public const gstrConnString = ddt_val(gstrConfigFilePath, "gstrConnString");
#
# Description:
# -----------
# Contains following functions
# 1. GetDBColumnValue(in strSql, in strColumn, out strVal)
# Use this function when you want only first /single value of strColumn.
# Usage:
# strSQL = "Select PRODUCT_CODE from PRODUCT_MASTER where PRODUCT_NAME = 'WINE'";
# strColumn = "PRODUCT_CODE";
# rc = GetDBColumnValue(strSql, strColumn, strVal);
# pause (strVal);
#
# 2. GetDBRow(in strSql, out strHeader, out nHeaderCount, out strRow )
# Use this function when you require entire first row of the result set.
# strSql = Query to execute
# strHeader = Header Names seperated by tab. (It will hold only 1024 char)
# Hence not so reliable
# nHeaderCount = Count of Columns in the result set.
# strRow = Row Tab seperated string.
#
# 3. GetDBColumnAllValues(in strSql, in strColumn, out strVal[], out nRecord)
# Use this function when you require entire content of a Column
# strSQL = Query to execute
# strColumn = Column form the Query for which values are required
# strVal[] = Array that holds the Values
# nRecord = Gives the Number of values retreived.
#
# 4. GetDBAllRows(in strSql,out strHeader, out nHeaderCount, out strRow[], out nRecord)
# Use this function when you require to get entire result set. This returns all the
# result set in an array each row in array is a tab seperated string.
# strSql = Query to execute
# strHeader = Header Names seperated by tab. (It will hold only 1024 char)
# Hence not so reliable
# nHeaderCount = Count of Columns in the result set.
# strRow[] = Array of Row Tab seperated string.
# nRecord = Count of values in strRow.
# # Notes:
# ------
# I have observed that I get correct results only when I use UPPER case while building the
# query.
# In case you find any defects in the script please communicate so that I am aware
# of the same and could enhance it further.
#-----------------------------------------------------------
public function GetDBColumnValue(in strSql, in strColumn, out strVal) #-----------------------------------------------------------
{
# Reference to the Connection String Constant
extern gstrConnString;

# Holds The result 0 is success any thing other
than 0 is failed
auto rc;

# Holds the Error that is returned by the ODBC...
auto strLastError;

# Holds the Number of rows that is returned by strSQL
auto nRecord;

# Setting strLastError to Null
strLastError ="";

# Setting the rc to unsuccessfull
rc = -9999;

# Attempt to connect...
rc = db_connect("obDatabase",gstrConnString);
if (rc!=0)
{
# If failed then return...error_code
report_msg("Could not Connect To database.");
return rc;
}

# Attempt the query execution....
rc = db_execute_query("obDatabase", strSql,nRecord);
if (rc!=0)
{
# If failed then return code
db_disconnect("obDatabase");
report_msg("db_execute_query returned error.");
return rc;

}
if (nRecord == 0)
{
# If the records returned is 0 then....
rc = 1;
db_disconnect("obDatabase");
report_msg ("SQL: " & strSql & ". Returned Zero Rows !!!");
return rc;
}

# Attempt to get the field value...
strVal = db_get_field_value ("obDatabase","#0",strColumn);
if (strVal=="")
{
# Case strVal is null ... Check whether any error has occured
db_get_last_error("obDatabase", strLastError);
if (strLastError!="")
{
# If error has occured then... return
db_disconnect("obDatabase");
rc = 2;
report_msg("Last DB Error: " & strLastError);
return rc;
}
# if there is no error then the field is having null as value
}
# Attempt to disconnect
rc = db_disconnect("obDatabase");
if (rc!=0)
{
# If error then return...
report_msg("Could not disconnect.");
return rc;
}
# Empty every thing and quit...
strSql = "";
strColumn ="";
strLastError ="";
return rc;
}

#--------------------------------------------------
public function GetDBRow(in strSql, out strHeader,
out nHeaderCount, out strRow )
#---------------------------------------------------
{
# Reference to the Connection String Constant
extern gstrConnString;

# Holds the result set
auto rc;

# Holds the Error that is returned by the ODBC...
auto strLastError;

# Holds the Number of records that are
returned by query....
auto nRecord;

# Set the strLastError to null.
strLastError ="";

# Set rc as unsuccessful
rc = -9999;

# Attempt to establish a connection
rc = db_connect("obDatabase",gstrConnString);
if (rc!=0)
{
# On error return the error code.

report_msg("Could not Connect To database.");
return rc;
}

# Attempt to execute the query...
rc = db_execute_query("obDatabase", strSql, nRecord);
if (rc!=0)
{
# On error return the error code
db_disconnect("obDatabase");
report_msg("db_execute_query returned error.");
return rc;
}
# Case the number of records returned is zero then
if (nRecord == 0)
{
rc = 1;
db_disconnect("obDatabase");
report_msg ("SQL: " & strSql & ". Returned Zero Rows !!!");
return rc;
}
# Attempt to get the Row
rc = db_get_row("obDatabase", "#0", strRow);
if (rc!=0)
{
# Case error
db_disconnect("obDatabase");
report_msg("db_get_row returned error.");
return rc;
}
# Attempt to get Headers
rc = db_get_headers("obDatabase",nHeaderCount, strHeader);
if (rc!=0)
{
# Case error then
db_disconnect("obDatabase");
report_msg("db_get_headers returned error.");
return rc;
}
# if strRow is null then check if any error has occured
if (strRow =="")
{
db_get_last_error("obDatabase", strLastError);
if (strLastError!="")
{
# If strLastError is not null then return the error.
rc = 2;
db_disconnect("obDatabase");
report_msg("Last DB Error: " & strLastError);
return rc;
}
}
# Disconnect the db
rc = db_disconnect("obDatabase");
if (rc!=0)
{
report_msg("Could not disconnect.");
return rc;
}
strSql = "";
strLastError ="";
return rc;
}


#-------------------------------------------------------
public function GetDBColumnAllValues(in strSql, in
strColumn, out strVal[], out nRecord)
#-------------------------------------------------------
{
# Reference to the Connection String Constant
extern gstrConnString;

# Holds The result 0 is success any thing other
# than 0 is failed
auto rc;

# Holds the Error that is returned by the ODBC...
auto strLastError;

# Holds index of the strVal array.
auto i;

# Setting strLastError to Null
strLastError ="";

# Setting the rc to unsuccessfull
rc = -9999;

# Attempt to connect...
rc = db_connect("obDatabase",gstrConnString);
if (rc!=0)
{
# If failed then return...error_code
report_msg("Could not Connect To database.");
return rc;
}

# Attempt the query execution....
rc = db_execute_query("obDatabase", strSql,nRecord);
if (rc!=0)
{
# If failed then return code
db_disconnect("obDatabase");
report_msg("db_execute_query returned error.");
return rc;

}
if (nRecord == 0)
{
# If the records returned is 0 then....
rc = 1;
db_disconnect("obDatabase");
report_msg ("SQL: " & strSql & ". Returned Zero Rows !!!");
return rc;
}

i = 1;
do
{
# Attempt to get the field value...
strVal[i] = db_get_field_value ("obDatabase","#" &
(i-1),strColumn);
if (strVal[i]=="")
{
# Case strVal is null ... Check whether any error has occured
db_get_last_error("obDatabase", strLastError);
if (strLastError!="")
{ # If error has occured then... return
db_disconnect("obDatabase");
rc = 2;
report_msg("Last DB Error: " & strLastError);
return rc;
}
# if there is no error then the field is having null as value
}
i++;
}
while (i <= nRecord);

# Attempt to disconnect
rc = db_disconnect("obDatabase");
if (rc!=0)
{
# If error then return...
report_msg("Could not disconnect.");
return rc;
}
# Empty every thing and quit...
strSql = "";
strColumn ="";
strLastError ="";
return rc;
}


#-----------------------------------------------------
public function GetDBAllRows(in strSql,out strHeader,
out nHeaderCount, out strRow[], out nRecord)
#----------------------------------------------------
{
# Reference to the Connection String Constant
extern gstrConnString;

# Holds the result set
auto rc;

# Holds the Error that is returned by the ODBC...
auto strLastError;

# Holds the index of Array strRow[]
auto i;
# Temporary string
auto strTmp;
# Set the strLastError to null.

strLastError ="";
strTmp = "";

# Set rc as unsuccessful
rc = -9999;

# Attempt to establish a connection
rc = db_connect("obDatabase",gstrConnString);
if (rc!=0)
{
# On error return the error code.
report_msg("Could not Connect To database.");
return rc;
}

# Attempt to execute the query...
rc = db_execute_query("obDatabase", strSql, nRecord);
if (rc!=0)
{
# On error return the error code
db_disconnect("obDatabase");
report_msg("db_execute_query returned error.");
return rc;
}
# Case the number of records returned is zero then
if (nRecord == 0)
{
rc = 1;
db_disconnect("obDatabase");
report_msg ("SQL: " & strSql & ". Returned Zero Rows !!!");
return rc;
}
i = 1;

do
{
strTmp = "";
# Attempt to get the Row
rc = db_get_row("obDatabase", (i-1), strTmp);
if (rc!=0)
{
# Case error
db_disconnect("obDatabase");
report_msg("db_get_row returned error.");
return rc;
}
# Push the strTmp in the array
strRow[i] = strTmp;
# Increment i
i++;
}while (i <= nRecord);

# Attempt to get Headers
rc = db_get_headers("obDatabase", nHeaderCount,
strHeader);
if (rc!=0)
{
# Case error then
db_disconnect("obDatabase");
report_msg("db_get_headers returned error.");
return rc;
}

# Disconnect the db
rc = db_disconnect("obDatabase");
if (rc!=0)
{
report_msg("Could not disconnect.");
return rc;
}
strSql = "";
strLastError ="";
strTmp="";
return rc;
}

public function getConnection( inout strConn)
{
# Reference to the Connection String Constant
extern gstrConnString;

# Holds the result set
auto rc;
# Set rc as unsuccessful
rc = -9999;

# Attempt to establish a connection
rc = db_connect(strConn,gstrConnString);
if (rc!=0)
{
# On error return the error code.
report_msg("Could not Connect To database.");
return rc;
}
return rc;
}
Q: How to get time duration in millisecond in WinRunner?
All you have to do is save the start time (get_time())
at the start and at the end of the test and then format
the difference in terms of the seconds passed between.

The code below will do what you want and more -

const SECOND = 1;
const MINUTE = 60 * SECOND;
const HOUR = MINUTE * 60;
const DAY = HOUR * 24;
const YEAR = DAY * 365;


public function dddt_CalculateDuration(in oldTime,
in newTime, out strDuration, out years, out months,
out days, out hours, out minutes, out
seconds)
{
auto timeDiff, plural = "s, ", singular = ", ", remainder;

timeDiff = oldTime - newTime;

if(timeDiff >= YEAR)
{
remainder = timeDiff % YEAR;
years = (timeDiff - remainder) / YEAR;
timeDiff = remainder;
}

if(timeDiff >= DAY)
{
remainder = timeDiff % DAY;
days = (timeDiff - remainder) / DAY;
timeDiff = remainder;
}

if(timeDiff >= HOUR)
{
remainder = timeDiff % HOUR;
hours = (timeDiff - remainder) / HOUR;
timeDiff = remainder;
}

if(timeDiff >= MINUTE)
{
remainder = timeDiff % MINUTE;
minutes = (timeDiff - remainder) / MINUTE;
timeDiff = remainder;
}

seconds = timeDiff;

strDuration = "";

if (years)
{
strDuration = years & " Year";
if (years > 1)
strDuration = strDuration & plural;
else
strDuration = strDuration & singular;
}

if (days)
{
strDuration = strDuration & days & " Day";
if (days > 1)
strDuration = strDuration & plural;
else
strDuration = strDuration & singular;
}

if (hours)
{
strDuration = strDuration & hours & " Hour";
if (hours > 1)
strDuration = strDuration & plural;
else
strDuration = strDuration & singular;
}

if (minutes)
{
strDuration = strDuration & minutes & " Minute";
if (minutes > 1)
strDuration = strDuration & plural;
else
strDuration = strDuration & singular;
}

if (seconds)
{
strDuration = strDuration & seconds & " Second";
if (seconds > 1)
strDuration = strDuration & "s.";
else
strDuration = strDuration & ".";
}

return E_OK;
}

Q: Working with QTP and work on web application which is developed on .Net. Trying to prepare scripts but , when record and run the script most of the liks are not recognizing by qtp,that links are dynamically generating and also into diff place. what should we do for it ?
Try changing the Web Event Recording Configurations. Go to Tools > Web Event Recording Configurations, and change the setting to high.
If the links are dynamically generated, try changing the recorded object properties. After recording, right click on the recorded object and select object properties. From this screen you can add/remove attributes for playback that were previously recorded. Focus on attributes of the object that are not specific to location and do not change (html ID maybe).

How to verify the animations(gif files) present in the applications using WinRunner?
WinRunner doesn't support testing that technology. You will need to find another tool to do that. QuickTest may be a possible choice for you. Go to the Mercury site and look at the list of supported technologies for QuickTest Pro 6.5 & above (not Astra).

WinRunner: Should I sign up for a course at a nearby educational institution?
When you're employed, the cheapest or free education is sometimes provided on the job, by your employer, while you are getting paid to do a job that requires the use of WinRunner and many other software testing tools.
If you're employed but have little or no time, you could still attend classes at nearby educational institutions.
If you're not employed at the moment, then you've got more time than everyone else, so that's when you definitely want to sign up for courses at nearby educational institutions. Classroom education, especially non-degree courses in local community colleges, tends to be cheap.

How important is QTP in automated testing, does only with manaul testing (Test Director) is enough for testing. Or do we require automated tools in each and every projects. What are the different advantages of the QTP?
Most projects that are being automated should not be because they're not ready to be. Most managers assume that automated functional QUI testing will replace testers. It won't. It just runs the same tests over, and over, and over. When changes are made to the system under test, those changes either break the existing automated tests or they are not covereb by the changes.
Automated functional GUI testing is usually a waste of time.
TestDirector is not used for executing any actual test activity but it is a test management tool used for Requirements Management, Test Plan, Test Lab, and Defects Management. Even if the individual test cases are not automated, TestDirector can make life much easier during the test cycles.
These two are also good reads on the topic:
Automation Myths
Test Automation Snake Oil
You can find information about QTP here:
http://www.mercury.com/us/products/quality-center/functional-testing/...

Tell me about the TestDirector®
The TestDirector® is a software tool that helps software QA professionals to gather requirements, to plan, schedule and run tests, and to manage and track defects/issues/bugs. It is a single browser-based application that streamlines the software QA process.
The TestDirector's "Requirements Manager" links test cases to requirements, ensures traceability, and calculates what percentage of the requirements are covered by tests, how many of these tests have been run, and how many have passed or failed.
As to planning, the test plans can be created, or imported, for both manual and automated tests. The test plans then can be reused, shared, and preserved.
The TestDirector’s "Test Lab Manager" allows you to schedule tests to run unattended, or run even overnight.
The TestDirector's "Defect Manager" supports the entire bug life cycle, from initial problem detection through fixing the defect, and verifying the fix.
Additionally, the TestDirector can create customizable graphs and reports, including test execution reports and release status assessments.

What is a backward compatible design?
The design is backward compatible, if the design continues to work with earlier versions of a language, program, code, or software. When the design is backward compatible, the signals or data that has to be changed does not break the existing code.
For instance, a (mythical) web designer decides he should make some changes, because the fun of using Javascript and Flash is more important (to his customers) than his backward compatible design. Or, alternatively, he decides, he has to make some changes because he doesn't have the resources to maintain multiple styles of backward compatible web design. Therefore, our mythical web designer's decision will inconvenience some users, because some of the earlier versions of Internet Explorer and Netscape will not display his web pages properly (as there are some serious improvements in the newer versions of Internet Explorer and Netscape that make the older versions of these browsers incompatible with, for example, DHTML). This is when we say, "Our (mythical) web designer's code fails to work with earlier versions of browser software, therefore his design is not backward compatible".
On the other hand, if the same mythical web designer decides that backward compatibility is more important than fun, or, if he decides that he does have the resources to maintain multiple styles of backward compatible code, then, obviously, no user will be inconvenienced when Microsoft or Netscape make some serious improvements in their web browsers. This is when we can say, "Our mythical web designer's design is backward compatible".

Q: How to get the compiler to create a DLL ?
In the Borland compiler, Creating "Console DLL's".
A console application is one that does not have a GUI windows queue component. This seems to work well and has a very small footprint.

Q: How to export DLL functions so that WinRunner could recognise them?
Created the following definition in the standard header file:
#define WR_EXPORTED extern "C" __stdcall __declspec(dllexport)
and write a function it looks something like this:
WR_EXPORTED UINT WrGetComputerName( )
{
. . .
}

Q: How to pass parameters between WinRunner and the DLL function?
Passing Strings (a DLL function):
In WinRunner,
extern int WrTestFunction1( in string );
In the DLL,
WR_EXPORTED int WrTestFunction1( char *lcStringArg1 )
{
. . .
return( {some int value} ); }
And then to use it in WinRunner,
WrTestFunction1( "Fred" );
Receiving Strings:
In WinRunner,
extern int WrTestFunction1( out string <10>); #The <10> tells WinRunner how much space to use for a buffer for the returned string.
In the DLL,
WR_EXPORTED int WrTestFunction1( char *lcStringArg1 )
{
. . .
{some code that populates lcStringArg1};
. . .
return( {some int value} );
}
And then to use it in WinRunner,
WrTestFunction1( lcString1 );
# lcString1 now contains a value passed back from the DLL function

Passing Numbers (a DLL function)
In WinRunner,
extern int WrTestFunction1( in int );
In the DLL,
WR_EXPORTED int WrTestFunction1( int lnIntegerArg1 )
{
. . .
return( {some int value} );
}
And then to use it in WinRunner,
WrTestFunction1( 2 );
Recieving Numbers
In WinRunner,
extern int WrTestFunction1( out int );
In the DLL,
WR_EXPORTED int WrTestFunction1( int *lnIntegerArg1 )
{
. . .
*lnIntegerArg1 = {some number};
return( {some int value} );
}
And then to use it in WinRunner,
WrTestFunction1( lnNum );
# lnNum now contains a value passed back from the DLL function

Here are some example functions.
#define WR_EXPORTED extern "C" __stdcall __declspec(dllexport)
#define WR_SUCCESS 0
#define WR_FAILURE 100000
#define FAILURE 0
#define WR_STAGE_1 10000
#define WR_STAGE_2 20000
#define WR_STAGE_3 30000
#define WR_STAGE_4 40000
#define WR_STAGE_5 50000
#define WR_STAGE_6 60000
#define WR_STAGE_7 70000
#define WR_STAGE_8 80000
#define WR_STAGE_9 90000
#define MAX_USERNAME_LENGTH 256
#define HOST_NAME_SIZE 64
WR_EXPORTED UINT WrGetComputerName( LPTSTR lcComputerName )
{
BOOL lbResult;
DWORD lnNameSize = MAX_COMPUTERNAME_LENGTH + 1;
// Stage 1
lbResult = GetComputerName( lcComputerName, &lnNameSize );
if( lbResult == FAILURE )
return( WR_FAILURE + WR_STAGE_1 + GetLastError() );
return( WR_SUCCESS );
}
WR_EXPORTED UINT WrCopyFile( LPCTSTR lcSourceFile, LPCTSTR lcDestFile, BOOL lnFailIfExistsFlag )
{
BOOL lbResult;
// Stage 1
lbResult = CopyFile( lcSourceFile, lcDestFile, lnFailIfExistsFlag );
if( lbResult == FAILURE )
return( WR_FAILURE + WR_STAGE_1 + GetLastError() );
return( WR_SUCCESS );
}
WR_EXPORTED UINT WrGetDiskFreeSpace( LPCTSTR lcDirectoryName,
LPDWORD lnUserFreeBytesLo,
LPDWORD lnUserFreeBytesHi,
LPDWORD lnTotalBytesLo,
LPDWORD lnTotalBytesHi,
LPDWORD lnTotalFreeBytesLo,
LPDWORD lnTotalFreeBytesHi )
{
BOOL lbResult;
ULARGE_INTEGER lsUserFreeBytes,
lsTotalBytes,
lsTotalFreeBytes;
// Stage 1
lbResult = GetDiskFreeSpaceEx( lcDirectoryName,
&lsUserFreeBytes,
&lsTotalBytes,
&lsTotalFreeBytes );
if( lbResult == FAILURE )
return( WR_FAILURE + WR_STAGE_1 + GetLastError() );
*lnUserFreeBytesLo = lsUserFreeBytes.LowPart;
*lnUserFreeBytesHi = lsUserFreeBytes.HighPart;
*lnTotalBytesLo = lsTotalBytes.LowPart;
*lnTotalBytesHi = lsTotalBytes.HighPart;
*lnTotalFreeBytesLo = lsTotalFreeBytes.LowPart;
*lnTotalFreeBytesHi = lsTotalFreeBytes.HighPart;
return( WR_SUCCESS );
}
Q: Why Have TSL Test Code Conventions
TSL Test Code conventions are important to TSL programmers for a number of reasons:
. 80% of the lifetime cost of a piece of software goes to maintenance.
. Hardly any software is maintained for its whole life by the original author.
. TSL Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
. If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

Q: Test Script Naming
Test type + Project Name + Version Number + Module name + Test script Function .
For example:
Test type = UAT
Project Name = MHE
Version of the Project = 3.2
Module Name = Upload
Function Name = Excel_File
So the entire file name would be UAT_MHE_3.2_Upload_Excel_File
Note & Caution :
. Make sure the entire file name saved is below 255 characters.
. Use the underscore "_" character instead of hyphen "-" or " " character for separation.
. Highly recommended to store the test scripts remotely in a common folder or in the Test director repository , which are accessible and can be accessed by the test team at any time.
. Do not use any special characters on the test script name like "*&^ #@!" etc .,
. In this document - script or test script(TSL) means the same , pls don't get confused

Q: Test script Directory structure:
Winrunner recognizes the testscript as a file which is stored as a directory in the Operating system. The script 's TSL code , header information , checklist files , results , expected results etc are stored in these directories for each and every script.
. Do not modify or delete anything inside these directories manually without consulting an expert.
. Try to have scripts, which have lines less than or equal to 500
. While creating multiple scripts make sure they follow the directories and subdirectory structure (ie) Every script is stored in their respective modules under a folder and a main script which call all these scripts in a Parent folder above these scripts.In a nutshell "All the scripts must be organized and should follow an hierarchy ".
. If a module contains more than 2 scripts , a excel file is kept in the respective folder , which gives details of the testscripts and the functionality of these scripts in a short description E.g the excel sheet can contain fields like TestPlan No, Test script No, Description of the Testscript, Status of Last run, Negative or a non-negative test.
. Also make sure that evert script has a text file , which contains the test results of the last run.
. Maintenance of script folder that has unwanted files and results folder must be cleaned periodically.
. Backup of all the scripts (zipped) to be taken either in hard drive, CD-ROM, zip drives etc and kept safely.

Q: Comments
All the TSL script files should begin with a comment that lists the Script name, Description of the script, version information, date, and copyright notice:

#################################################################
# Script Name: #
# #
# Script Description: #
# #
# Version information: #
# #
# Date created and modified: #
# #
# Copyright notice #
# #
# Author: #
#################################################################
Comments generated by WinRunner.
WinRunner automatically generates some of the comments during recording..If it makes any sense leave them, else modify the comments accordingly
Single line comment at the end of line.
Accessfile = create_browse_file_dialog ("*.mdb"); # Opens an Open dialog for an Access table.
It is mandatory to add comment for your test call
Call crea_org0001 (); #Call test to create organization
It is mandatory to add comments when you are using a variable which is a public variable and is not defined in the present script.
Web_browser_invoke (NETSCAPE, strUrl); #strUrl is a variable defined in the init script
Note:The frequency of comments sometimes reflects poor quality of code. When you feel compelled to add a comment, consider rewriting the code to make it clearer. Comments should never include special characters such as form-feed.

Q: Creating C DLLs for use with WinRunner
These are the steps to create a DLL that can be loaded and called from WinRunner.
1. Create a new Win32 Dynamic Link Library project, name it, and click .
2. On Step 1 of 1, select "An empty DLL project," and click .
3. Click in the New Project Information dialog.
4. Select File New from the VC++ IDE.
5. Select "C++ Source File," name it, and click .
6. Close the newly created C++ source file window.
7. In Windows Explorer, navigate to the project directory and locate the .cpp file you created.
8. Rename the .cpp file to a .c file
9. Back in the VC++ IDE, select the FileView tab and expand the tree under the Projects Files node.
10. Select the Source Files folder in the tree and select the .cpp file you created.
11. Press the Delete key; this will remove that file from the project.
12. Select Project Add To Project Files from the VC++ IDE menu.
13. Navigate to the project directory if you are not already there, and select the .c file that you renamed above.
14. Select the .c file and click . The file will now appear under the Source Files folder.
15. Double-click on the .c file to open it.
16. Create your functions in the following format:

#include "include1.h"
#include "include2.h"
.
.
.
#include "includen.h"
#define EXPORTED __declspec(dllexport)
EXPORTED ( ,
,
…,
)
{

return ;
}
.
.
.
EXPORTED ( ,
,
…,
)
{

return ;
}
17. Choose Build .DLL from the VC++ IDE menu.
18. Fix any errors and repeat step 17.
19. Once the DLL has compiled successfully, the DLL will be built in either a Debug directory or a Release directory under your project folder depending on your settings when you built the DLL.
20. To change this setting, select Build Set Active Configuration from the VC++ IDE menu, and select the Configuration you want from the dialog. Click , then rebuild the project (step 17).
21. All the DLLs types that you are going to create are loaded and called in the same way in WinRunner. This process will be covered once in a later section.
Q: Creating C++ DLLs for use with WinRunner
Here are the steps for creating a C++ DLL:
1. Create a new Win32 Dynamic Link Library project, name it, and click .
2. On Step 1 of 1, select "An Empty DLL Project," and click .
3. Click in the New Project Information dialog.
4. Select File New from the VC++ IDE.
5. Select C++ Source File, name it, and click .
6. Double-click on the .cpp file to open it.
7. Create your functions in the following format:

#include "include1.h"
#include "include2.h"
.
.
.
#include "includen.h"

#define EXPORTED extern "C" __declspec(dllexport)

EXPORTED ( ,
,
…,
)
{

return ;
}
.
.
.
EXPORTED ( ,
,
…,
)
{

return ;
}

8. Choose Build .DLL from the VC++ IDE menu.
9. Fix any errors and repeat step 8.
10. Once the DLL has compiled successfully, the DLL will be built in either a Debug directory or a Release directory under your project folder depending on your settings when you built the DLL.
11. To change this setting, select Build Set Active Configuration from the VC++ IDE menu, and select the Configuration you want from the dialog. Click , then rebuild the project (step 8).
12. All the DLLs types that you are going to create are loaded and called in the same way in WinRunner. This process will be covered once in a later section.

Q: Creating MFC DLLs for use with WinRunner
1. Create a new MFC AppWizard(DLL) project, name it, and click .
2. In the MFC AppWizard Step 1 of 1, accept the default settings and click .
3. Click in the New Project Information dialog.
4. Select the ClassView tab in the ProjectView and expand the classes tree. You will see a class that has the following name CApp; expand this branch.
5. You should see the constructor function CApp(); double-click on it.
6. This should open the .cpp file for the project. At the very end of this file add the following definition:
#define EXPORTED extern "C" __declspec( dllexport )
7. Below you will add your functions in the following format:
#define EXPORTED extern "C" __declspec(dllexport)
EXPORTED ( ,
,
…,
)
{

return ;
}
.
.
.
EXPORTED ( ,
,
…,
)
{

return ;
}

8. You will see the functions appear under the Globals folder in the ClassView tab in the ProjectView.
9. Choose Build .DLL from the VC++ IDE menu.
10. Fix any errors and repeat step 9.
11. Once the DLL has compiled successfully, the DLL will be built in either a Debug directory or a Release directory under your project folder depending on your settings when you built the DLL.
12. To change this setting, select Build Set Active Configuration from the VC++ IDE menu, and select the Configuration you want from the dialog. Click , then rebuild the project (step 9).
13. All the DLLs types that you are going to create are loaded and called in the same way in WinRunner. This process will be covered once in a later section.

Q: Creating MFC Dialog DLLs for use with WinRunner
1. Create a new MFC AppWizard(DLL) project, name it, and click .
2. In the MFC AppWizard Step 1 of 1, accept the default settings and click .
3. Click in the New Project Information dialog.
4. Select the ClassView tab in the ProjectView and expand the classes tree. You will see a class that has the following name CApp; expand this branch also.
5. You should see the constructor function CApp(); double-click on it.
6. This should open the .cpp file for the project. At the very end of this file add the following definition:
#define EXPORTED extern "C" __declspec( dllexport )

7. Switch to the ResourceView tab in the ProjectView.
8. Select Insert Resource from the VC++ IDE menu.
9. Select Dialog from the Insert Resource dialog and click .
10. The Resource Editor will open, showing you the new dialog. Add the controls you want to the dialog, and set the properties of the controls you added.
11. Switch to the ClassView tab in the ProjectView and select View ClassWizard from the VC++ IDE menu, or double-click on the dialog you are creating.
12. The Class Wizard should appear with an "Adding a Class" dialog in front of it. Select "Create a New Class" and click .
13. In the New Class dialog that comes up, give your new class a name and click .
14. In the Class Wizard, change to the Member Variables tab and create new variables for the controls you want to pass information to and from. Do this by selecting the control, clicking , typing in the variable name, selecting the variable type, and clicking . Do this for each variable you want to create.
15. Switch to the Message Maps tab in the Class Wizard. Select the dialog class from the Object IDs list, then select the WM_PAINT message from the Messages List. Click , then . This should bring up the function body for the OnPaint function.
16. Add the following lines to the OnPaint function so it looks like the following:
void ::OnPaint()
{
CPaintDC dc(this); // device context for painting
this-%gt;BringWindowToTop();
UpdateData(FALSE);
// Do not call CDialog::OnPaint() for painting messages
}

17. Select IDOK from the Object IDs list, then select the BN_CLICKED message from the Messages
list. Click , accept the default name, and click .
18. Add the line UpdateData(TRUE); to the function, so it looks like this:
void ::OnOK()
{
UpdateData(TRUE);
CDialog::OnOK();
}
19. When you are done with this, click to close the Class Wizard dialog and apply your changes. Your new class should appear in the ProjectView in the ClassView tab.
20. In the tree on the ClassView tab, double-click on the constructor function for the CApp (see step 5).
21. At the top of the file, along with the other includes, add an include statement to include the header file for your dialog class. It should be the same name as the name you gave the class in step 13 with a .h
appended to it. If you are unsure of the name, you can look it up on the FileView tab under the Header Files folder. 22. At the very end of the file, after the #define you created in step 6, create a function that looks something like this:
EXPORTED int create_dialog(char* thestring)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
theDlg;
theDlg.=;
theDlg.DoModal();

strcpy(thestring,strVar1); //this will pass the value back to WinRunner.
return 0;
}
23. Choose Build .DLL from the VC++ IDE menu.
24. Fix any errors and repeat step 23.
25. Once the DLL has compiled successfully, the DLL will be built in either a Debug directory or a Release directory under your project folder depending on your settings when you built the DLL.
26. To change this setting, select Build Set Active Configuration from the VC++ IDE menu, then select the Configuration you want from the dialog. Click <, then rebuild the project (step 23).
27. All the DLLs types that you are going to create are loaded and called in the same way in WinRunner. This process will be covered once in a later section.

Q: Loading and Calling the Above DLLs from WinRunner
Loading and calling DLLs from WinRunner is really very simple. There are only 3 steps.
1. Load the DLL using the command load_dll.
2. Declare the function in the DLL as an external function using the extern function.
3. Call the function as you would any other TSL function.
As simple as this is, there are some things you need to be aware of.
1. WinRunner has a limited number of variable types; basically, there is string, int, and long. Windows has many different types. Two common types, which may confuse you, are HWND and DWORD. Which WinRunner type do you choose for these? You should declare these as long.
2. If you are building a function in a DLL and you are testing it in WinRunner, make sure you unload the DLL in WinRunner using the unload_dll function before you try to recompile the DLL. If you leave the DLL loaded in WinRunner and try to recompile the DLL, you will receive an error message in VC++ that looks like this:
LINK : fatal error LNK1104: cannot open file "Debug/.DLL Error executing link.exe
To resolve this error, step through the unload_dll line in WinRunner, then compile the DLL.
3. Before shipping a DLL make sure you compile it in Release mode. This will make the DLL much smaller and optimized.
Q: Definition of Tests
As a prime entry point defining the test needs a idea to classify the scripts into finer elements of functions each contributing the various aspects of automation Techniques.
Looking into this perspective the elements of the Automation Script would require the Record Play Back techniques, details of the application as better understood as Objects in tools, execution of Business Logic using loop constructs, and the test data accessibility for either Batch Process or any Back end operations. Ultimately we need this entire salient features to function at the right point of time getting the right inputs. To satisfy these criteria we require a lot of planning before we start automating the Test Scripts

Q: Test Recorder about Object Vs Actions
In automation tools the Test Recorder is of two modes Object based and Action Mode. It requires a meticulous but yet a simplified approach on which mode to use. Though it is inevitable to avoid Action mode, it is still used for many at TE Based applications. As a best practice the object based is widely accepted and mandatory mode of operation in Test Automation. To the extent possible we will avoid Action based functions and stick on the object mode of operation.

Q: Test Recorder about Generic Test Environment Options
Some common Settings we need to set in General Options:
1. Default Recording Mode is Object mode
2. Synch Point time is 10 seconds as default
3. When Test Execution is in Batch Mode ensure all the options are set off so that the Batch test runs uninterrupted
4. In the Text Recognition if the Application Text is not recognizable then the Default Font Group is set. The Text Group is identified with a User Defined Name and then include in the General Option.

Q: Test Recorder about Test Properties
1. Every Script before recording ensure that the Test properties is in Main Test with the defaults
2. Do not entertain any Parameters for Main Test
3. It is not a good practice to load the Object library from the Test Options (if any). Rather the Object library is loaded from the Script using the suitable tool commands. This would actually avoid the hidden settings in the Script and also the ease of Setting the Object library Load and Unload can be better done dynamically in the Test Script rather than doing it manually every time the Test Suite is ran.
4. Ensure the Add-ins is correct from the Add-ins tab.

Q: Test Recorder about Script Environment
The basic idea of setting the Test Bed is that the Test Suite must be potable and can readily be ran in any environment given the initial conditions. For this to happen, the automation tool supports a lot of functions to evolve a generic methodology where we can wrap up the entire built-ins to run before the Test Suite start executing the Script. In other word the fashion of organizing the Test Scripts remain in the Test automation developer's mind to harbinger the issues and hurdles that can be avoided with little or less of programming.
Q: Test Recorder about Script Environment: Automation Inits ()
Common Functions that get into Initialization Script are
1. Usage of built-in commands to keep the test path dynamically loaded. Options to rule out the possibility of Test Path Definitions
2. Close all the object files and data files in the Initialization Script
3. Connection to the database should be done in the Inits Script
4. Always Unload and Load the Object library, and it should be done only in Inits Script.
5. Define all the "public" Variables in the Inits Script
6. Establish the db connections in the Inits Test Script

Q: Test Recorder about Script Environment: Test Scripts Elements:
Prior to the development of Test Scripts the fashion of arranging the Test Scripts needs a proper planning. Lets look at few inputs on arranging the Test ware.
Test Ware Test Repository
Test Suite Should contain Sub Folders, Exception Handlers, Global Object files, Set Data file, Driver Scripts, Initialization & Termination scripts
Driver Script Object Checks, Bit Map Checks, Text Check, Web Check, User defined Functions, Global test Report Folder
Driven Script GUI/Bit/Text Check, External Libraries, I/O Handlers

Q: Test Recorder about Control Points
In any given automation tool the overall control of AUT is by Object identification technique. By this unique feature the tool recognizes the Application as an medium to interrogate with the Tester supplied inputs and tests the mobility of the Business Logistics. Invoking this object identification technique the test tool does have certain control features that checks the application at various given point of time. Innumerous criteria, myriads of object handlers, plenty of predefined conditions are the features that determine the so-called object based features of the Functional Check points. Each tester has a different perspective of defining the Control points.

Q: Test Recorder about Control Points - If. … Else:
1. Before we start the "if else" construct the nature of the control point is commented along side. For e.g.,
# Home Page Validation
If ( == "0")
print ("Successfully Launched");
else
print ("Operation Unsuccessful");
2. For all Data Table operation the return-code of the Open function should be handled in the "if else" construct.

Q: Test Recorder about Data Access
In automation Test Data becomes very critical to control, supplement and transfer in the application. In automation tools the Test Data is handled in data sheets of Excel format or a .csv file that is basically a character separated file using the Data driven technology. In most regression batch testing the Test Data is handled in data tables with proper allocation of test data in the sheets.
Q: Test Recorder about Control Points - Check Points
1. Any checkpoints should not be a component of X & Y Co-ordinate dependant. In practical terms if there is a Check point that is defined on X,Y Parameters then the usability of the control point wouldn't make any sense for the application to test. The following are some of the criteria which denotes the do's and don't's of checkpoints.
S.No Check Point Include Exclude
1 Text Check Capture Text, Position of the Text, Font & Font Size, Text area,
2 Bitmap Check only the picture Window or Screen that holds the picture, x-y co-ordinates,
3 Web Check URL Check, orphan page Avoid any text validation
2. As a case study, the WinRunner automation tool is mentioned here as examples for creating check points. Usage of OBJ_CHECK_INFO or WIN_CHECK_INFO can be avoided and inculcate the idea of creating always the GUI Check point with Multiple Property. The advantages are to identify every small object with its clause, properties and its relativity with the previous versions. This not only enables the Regression comparisons but also it gives you the flexibility of defining the GUI Checks in all Physical state of the Object.

Q: Test Recorder about Data Handlers
Test Data can be accessed by built-in data functions. Some of the common practices that would help a automation tester to use the data-tables in a proper fashion.
1. SINGLE DATA TABLE: By default every automation tool gives the data-table as an input file can be created using a tool wizard or sometimes potentially creating using a character-separated file. This wizard would help us in creating a Data sheet with its column names from the objects used in the test objects. With this concept, we can evolve a technique to load any File or manipulate the AUT by predefined set of cases.
2. Multiple Data Table: It's a common practice to use the single default data file for many test scripts. Often the usage of data tables is restricted to one file at a moment. Handling multiple data tables is not advisable and incur a lot of redundant code to handle the table manipulations. As a general practice the data file is mapped to every script. This mean every Test Script will have a unique data table for easier data access and also the data operation will become easy to maintain.
In Compuware's QARun following is the code used.

// Run a test script
TestData ("CreditLogon.csv")
Call TestFunc1

For e.g in Mercury Interactive's WinRunner,
call_close "Test_Script1" (dTable1.xls) ;
#
call_close "Test_Script2" (dTable2.xls);

3. Data files should be initialized before starting by way of simple tool commands by transferring a standard template data table to the actual template. By this practice the need of deleting data after every run in the data table can be avoided.
In Mercury Interactive's WinRunner the piece of code below explains the data table Initialization.
#/***************Data Table Initialization*****************
ddt_open(Template, DDT_MODE_READ);
ddt_open(dTable, DDT_MODE_READWRITE);
ddt_export(Template,dTable);
ddt_save(dTable);
ddt_close(dTable);
ddt_close(Template);
ddt_close_all_tables();
#/***************Data Table Initialization*****************

4. Dynamic loading of data from the Data base operation is the most advisable practice to be followed, but yet handling the db operations with some meticulous programming would always benefit the tester avoiding a variety of operational hazard and reducing the data access time for remote server database to the local data table.
Some of the tips, which need to be followed in the WinRunner TSL handling when we use the db commands.
Set the row before writing the data values in to the data-table.
i.e., Use the following TSL Command
public count;
count = 1;
ddt_set_row (dTable, count);
Now we use the set value by row command for writing the values in it
ddt_set_val_by_row (dTable, count, "CTS_EMP_NAME", value);
Need less to mention here, but to avoid confusion it is better to use the same column names as found in the Data Base table. And never insert any columns before or after or in between the column names in the WinRunner data table. It is a better practice to load the data table with the data as found in the Backend database.
Fig 1. shows the Automation Test Plan, its pre-requisites, Initial Conditions and the Test repository. This figure also gives the idea of building any Automation Test plan.


Q: Online Vs Batch Execution - Online Test Scripts
How do we use Online Scripts?
Using Dialog functions we can use the Interactive Testing accomplished.

In Mercury Interactive the following code is
SSN = create_input_dialog ("Please Enter the SSN Number");
In Compuware's QARun the following code is Dialog "Array_A" Array_A []
USER = Array_A["Userid"]
Pass = Array_A["Password"]


Q: Online Vs Batch Execution - Test Results
. Is it necessary to pass results back to the driver script even if scripts are not dependent? How should the results be passed back?
No need to pass the result back to the driver script if your scripts are independent

Q: Online Vs Batch Execution - TRe-Runnable Tests
Should setup scripts be made re-runnable? If yes then why? Also what is the best way to make them re-runnable (should it be attaching a random-number string or should it be, 'if' statements to check if data already exists)
It is best to create scripts that are re-runnable but we understand that it may not be possible for all cases for Set-Up type.

Q: Online Vs Batch Execution - TRe-Runnable Tests
Calling a driver file from within a driver file? Is this advisable?
No.

Q: Online Vs Batch Execution - Functions & Compiled Modules-Load Library
Loading libraries and memory issues, i.e. if a library contains 100 functions and only one function is used then unnecessarily we are loading all the function into memory. Should we make multiple smaller libraries and load and unload libraries frequently or just have one big library and keep it loaded all throughout the execution of master driver
Known Issue
We will run into memory issues when loading 100 functions into memory

Q: Online Vs Batch Execution - Functions & Compiled Modules-Data Fetch
Should we open and read from data table in driver scripts? Why or why not?
The purpose of the driver script is to setup the application and then calls each individual scripts. To open, read and close the data-file should happen at the individual test script level.

Q: Online Vs Batch Execution - Functions & Compiled Modules - User Defined Functions
Creating user-defined libraries and functions: How to access if a script should be made a function - What are the pros and cons of making a script a function versus just using it as a script and calling it from the driver file?
You have to load the function library first before you are able to make a call out to any of the functions defined in a function library. Using User-defined function is more efficient in the sense that they are compiled and loaded into memory before a function is being called and a function can be used over and again without having to recompile the function library.

WinRunner: Test Director
• Test Director is a one-stop solution for organizing the entire test cycle.
• It has four main tabs(categories) corresponding to the various phases in the testing cycle namely Requirements, Test Plan, Test Lab and Defects.
• Requirements can be entered and organized into various categories like login operations, database operations and so on.
• After setting up requirements, test cases corresponding(covering) these requirements can be defined and associated with the requirements. A requirement can be covered by multiple test cases and a test case can cover multiple requirements.
• The test plan can be defined with test cases each with test steps and can be manual or automated.
• Test sets are created to group similar test cases and then the test sets can be run.
• If a particular test set fails the run, after examination, the tester/QA can enter a defect in the associated defect tracking system. Attributes such as severity can be assigned.
• Test Director allows two modes of operation - user and administrator. Administrator can create and update user and group accounts, configure mail, customize project lists, custom project entities and setup wokflow whereas the user doesn't have these privileges.
• The six project entities are Requirement, Test, Test Step, Test Set(Execution), Run and Defect.
• Test Director allows attachments(file, URL, snapshot) with requirements, test step, test case, test run or defect.
• Test Director is flexible and can be customized within certain limits. Additional fields can be added in requirements, test case, test step, test plan and defects.
• Test Director has what is known as favorite views wherein any view or report or graph can be made to look as the user wants it to. The user can make only certain columns viewable and make it a favorite view.
• Test Director also has filters to filter test cases, requirements, defects by any of the various attributes like severity, assigned to etc.
• Test Director also has an Exection Flow option which is used to schedule automated test cases.
• Work flow is setup by the administrator which includes creating Visual Basic modules to save data before entering a bug in a defect tracking system, to perform operations before opening a bug form, after a bug field is changed and so on.
• Test Director also a comprehensive document generator utility to develop professional reports for the testing process.
• Also reports and graphs corresponding to requirements, test plan, test lab and defects can be created.
• The host machine can also be configured while running the test sets.

WinRunner: Test Director - Test Repositories
. A separate test repository will be created for each groups project. The test repositories will be created as Common Directories and will be located on a network server (this area should be a shared area where the group stores the rest of their files and documents).
. Initially all test repositories will be created using a Microsoft Access Database. In the future we may change this to SQL Server.
. The path to the network area can not be more than 47 characters (A Test Director restriction).
. The path can not contain any special characters such as $,& -, or %.
. All folders that contain the test repositories should start with TD_ .
. All test repositories should start with TD_ .

TD_NameofProject
Reports - Created automatically by Test Director, this is where it stores results of tests etc.
Tests - This is where the test scripts will reside if use WinRunner also.
GUImap - This is where the GUI map files will reside
Datafile - This is where all data flat files and excel spreadsheets will reside
Docs - This is where copies of documents that pertain to this project will reside Fonts
- This is where a copy of the font groups will reside
Functions - This is where the function library for the project will reside.
. Within Test Director various folders can be created as a way to organize your project and tests. These folders are stored in the database and may or may not be apparent on the file system.
TD_NameofProject
FolderName - Folder for functional regression tests
SubFolder - Sub folder for Specific Window
FolderName - Folder for SC functional regression tests
. It is not recommended to nest the folders more than 3 levels deep.

WinRunner: Test Director - Steps to take before creating Test Projects:
. Before starting Test Director, you should close all applications that are not required for testing. (Mail, Explorer, Screen Savers, CD Player etc).
. After installing a new version of Test Director and WinRunner, it is a good idea to make a back up copy of the following ini files to another location(testers choice of location). This is recommended to allow the tester to easily reset their WinRunner/TestDirector environment in the event of system corruption.
c:\windows\wrun.ini
c:\windows\mercury.ini
c:\~\TestDirector\bin\td.ini
c:\~\TestDirector\bin\filters.ini
c:\~\TestDirector\bin\forms.ini
c:\~\TestDirector\bin\grids.ini

. Your Test Director Application comes with a full set of on-line manuals. The manuals can be accessed using the Help Menu in the Test Director application. The on-line manuals can be viewed using Adobe Acrobat Reader 4.0.

WinRunner: Test Director - Set Up Recommendations:
Before a tester starts creating folders and test scripts, they should configure their Test project using the Administration menu.
1. Create various Users and User Groups for your project through the Administration -> Setup Users… menu item. Test Director comes with the following Pre-defined users and groups. We recommend that you create a user id that is similar to your Network login. You also have the option to create a password or leave it blank. The default is blank. You can also create your own groups or use the default groups provided by Test Director.
Default Users and Groups:
Users:
. Admin
. Guest
Groups:
. TDAdmin Has full privileges in a TestDirector project. This is the only type of user which can make changes to the information in the Setup Users dialog box. It is recommended to assign this user type to one person per group who will serve as the TestDirector Administrator.
. QATester Can create and modify tests in Plan Tests mode, and create test sets, run tests, delete test runs, and report defects in Run Tests mode. This user type is recommended for a quality assurance tester.
. Project Manager Can report new defects, delete defects, and modify a defect's status. This user type is recommended for a project manager or quality assurance manager.
. Developer Can report new defects, and change a defect's status to Fixed. This user type is recommended for a software developer.
. Viewer Has read-only privileges in a project.
2. Test Director also give you the option to customize your projects by creating user-defined fields for the dialog boxes and grids, creating categories and modifying drop down lists. These options enable you to add information that is relevant to your project. Modification to your projects are done using the Administration -> Customize Project Menu item. For more details on how to customize your project please see Chapter 3 in the Test Director's Administrators Guide.
3. Decide on Script Naming Convention and consistently use the naming convention for all tests created within the project. Please reference the Naming Conventions section for more information.
4. Create Test Folders to organize your tests into various sections. Examples of possible folder(s) names could be the types of testing you are doing ie: (functional, negative, integration ) or you could base your folder names on the specific modules or windows you are testing.

5. Create test scripts on the Plan tests folder using the New button in the test frame or menu item Plan -> New Test. The Test window has four tabs, Details, Design Steps, Test script and attach.
The Details tab, should be used to list all the information regarding the test. Test Director defaults to displaying the Status: Design; Created: date and time; Designer: your id.
. The Design Steps Tab, should be used to list detail instructions on how to execute your test.
. The Test Script tab, is used for tests that are turned into automated tests, on this page the automated WinRunner code will appear.
. The Attach Tab, can be used to attach bitmaps or other files required for testing to the script.
6. When creating folders, tests and test sets in Test Director make sure every item has a description.
7. Create a "Documentation" test to document how to set up your testing environment and run your tests.
8. It is recommended that you write your test scripts as detailed as possible and not assume that the executor of your test "knows how to use your module". By making your scripts as detailed as possible, this will allow others from outside your project to understand how to execute your tests, in the event that they have to run the tests.
9. Create Test Sets to group like test together, or to specify the order in which your tests should run. Test director has a limit of 99 test scripts per test set.
10. Export the test scripts into word via the Document Generator, Menu item Report -> Document Generator.

WinRunner: Test Director - Documentation Standards:
. Use a consistent naming convention for all test scripts and tests.
. Put Detailed descriptions on all test folders and test scripts to explain the purpose of the tests.
. Each test script should have a detailed test step associated with it.
. Before any automation project is started, the tester should write an automation standards document. The automation standards document will describe the following:
. Automation Environment
. Installation requirements
. Client Machines Configurations
. Project Information
. WinRunner and Test Director Option Settings
. Identify Servers, Database and Sub System tests will run against
. Naming Convention for project
. Specific Recording Standards that apply to individual project.

WinRunner: Test Director - Naming Conventions:
. Never call a test "tests", WinRunner/TestDirector has problem distinguishing the name test with the directory tests.
. The project automation document will specify any naming conventions used for the individual projects.

WinRunner: Test Director - Importing WinRunner tests into Test Director
1. bring up Test Director
2. select Plan - > Import Automated Tests
3. select your tests and import them
4. select the test grid button
5. change each tests subject to point to the folder you want them in
6. now copy all the tests from un-attached to the folder.
7. close test director
8. bring up test director again.
9. If after all this they are not there, create a dummy test to refresh the tree view, the tree window does not seem to refresh very well.

WinRunner: Test Director - How to delete Mercury Toolbar out of MS Word
If you ever play with the Test Director import into word feature, you will automatically create a test director toolbar in your MS word application. They best way to get rid of this toolbar is to;
1. Shut down word if open
2. Bring up windows explorer
3. Navigate to C:\Program Files\Microsoft Office\Office\STARTUP
4. Delete all instances of Tdword.*
5. Restart word and verify it is now gone.

WinRunner: Other Test Director Features
The Test Director application has a number of other features:
1. Running Manual tests via Test Director application. Test Director has a feature that allows you to run your manual tests through the Mini Step Utility. This feature allows you compare the actual outcome to the expected results and record the results in the Test Director database at run time.
2. Test Director also has the capability of converting your manual tests into Automated Tests in the WinRunner application.
3. Test Director also provides reporting and graphing capabilities, that will assist you in your reviewing the process of test planning and test execution. Test Director provides a number of standard reports and graph formats as well as allows the user to create customized reports and graph.
4. Defect Tracking. Test Director also provides a Defect tracking tool in the Test Director product.

WinRunner: How to see the internal version of WebTest in your machine?
To see the internal version in your machine, right-click the ns_ext.dll file, select Properties, and click the Version tab. The ns_ext.dll file is located in the arch subdirectory of your WinRunner directory.

WinRunner: Web sites contain ActiveX controls
If your web sites contains ActiveX controls, you must install ActiveX add-in support when you install the WebTest add-in.
WinRunner: Web sites contain Java applets
If your web sites contain Java applets, you need to install Java add-in support for WinRunner.

WinRunner: To Record the Web Application
Recommendation: Set your browser to accept cookies. This will prevent a pop up window asking about the cookie from interfering with your script.

WinRunner: Steps to take before recording:
. Before starting to record, you should close all applications that are not required for testing. (Mail, Explorer, Screen Savers, CD Player etc).
. After installing a new version of Test Director and WinRunner, it is a good idea to make a back up copy of the following ini files to another location(testers choice of location). This is recommended to allow the tester to easily reset their WinRunner/TestDirector environment in the event of system corruption.
c:\windows\wrun.ini
c:\windows\mercury.ini
c:\~\TestDirector\bin\td.ini
c:\~\TestDirector\bin\filters.ini
c:\~\TestDirector\bin\forms.ini
c:\~\TestDirector\bin\grids.ini
c:\~\WinRunner\dat\ddt_func.ini
. Make sure your system is set up with all the necessary library functions that have been created.
. Make sure you create a GUI map and font group for each project.
. In the tsl_init file add the command GUI_close_all();. This command will make sure that no GUI maps are loaded when you bring up the WinRunner application. The benefit of this approach is that it will force the tester to load the correct GUI map for their testing, thus preventing scripting errors and other complications.

WinRunner: Libraries Needed for automation:
A number of libraries have been created to aid in the automation projects. Below is a list of the libraries that should be installed on each individual machine.
. csolib32 - This is a library full of many useful functions. This library was created by Mercury Customer Support and can be found in the following zip file csolib.zip. In order to access the library functions, the tsl_init file needs to be modified to run the cso_init file (which will load the libraries when the WinRunner application boots up).
. WebFunctions - This is a library contains functions designed to run on the YOUR-COMPANY Web systems.

WinRunner: Commands and Checkpoint Verification information for Web:
. Must do a set_window(); command for each action on a new window, this will assist the script in recognizing/resetting the window state and help prevent scripts failing due to slow network/system performance.
. Must add report_msg or tl_step command after each test to record what happens in the test.
. A obj_check_qui statement checks only one object on the window, and win_check_qui statement checks multiple objects in the window.
. The single property check allows you to check a single property of an object. The single property check dialog will add one of the following functions to your script.
button_check_info
edit_check_info
list_check_info
obj_check_info
scroll_check_info
static_check_info
The Object/Window check allows you to check every default object in the window. After it has completed it inserts an obj_check_gui statement in your script.
The Multiple Objects check allows you to check two or more objects in the window. This selection works best, because it first brings up the checkpoint window, then after the user selects add you can navigate to the AUT. Also, for some reason, the data in the object is retrieved with this feature but not the object/window check. After it has completed it inserts a win_check_gui statement in your script.
. There are 3 main types of GUI checks you can do with WinRunner. Single Property and Object/Window checks, and Multiple Objects.
. There are 35 Web functions, that come with the web test add-in. For the full list please see the TSL reference guide. The table below lists the most commonly used functions.

Function Description
web browser invoke Invokes the browser and opens a specified site.
web image click Clicks a hypergraphic link or an image.
web label click Clicks the specified label.
web link click Clicks a hypertext link.
web link valid Checks whether a URL name of a link is valid (not broken).
web obj get info Returns the value of an object property.
Needs a set_window command to be run before used
web obj get text Returns a text string from an object.
web obj text exists Returns a text value if it is found in an object.
web sync Waits for the navigation of a frame to be completed.
web url valid Checks whether a URL is valid
web find text Returns the location of text within a page.

. Most of the Web Test functions do not return a value to the test log, in order to record a pass or fail, conditional logic will have to be added to your code below the web function to send a tl_step or report_msg to the log

WinRunner: How to Structure tests for Web:
Create Begin and End Scripts. This will ensure that WinRunner starts and stops from the same place.
. Mercury recommends that it is better to use smaller specific GUI maps for your testing than have one large GUI map that encompasses your whole application.
. Comment all major selections or events in the script. This will make debugging easier
. Need to create a init script to load correct GUI map, font group and set option variables.
A few of the options you should set are:
# Turns off real time error message reporting if the test case
# fails. The error is still logged in the test results window.
setvar ("mismatch_break", "off");
# Turn off beeping
setvar ("beep", "off");
setvar ("sync_fail_beep", "off");
# Make sure context sensitive errors don't trigger real time
# failures that stop the script. The error is still logged in the
# test results window.
setvar ("cs_fail", "off");
# Sets time winrunner waits between executing statements
# (Mercury default is 0)
setvar ("cs_run_delay", "500");
# Sets time winrunner waits to make sure window is stable
# (Mercury default is 1000)
setvar ("delay_msec", "500");
# Sets the fail test when single property fails to uncheck (bug - recommend set to un-check) setvar ("single_prop_check_fail", "0");
. Determine all paths to start up directory and then set them in the options window.
. In your closing/ending scripts use the GUI_unload_all command to unload all GUI maps in memory.

WinRunner: Recording tips:
. Always record in Context Sensitive mode.
. WinRunner is case sensitive, so be careful in your scripting regarding what is put in upper/lower case.
. If using the full check text test case, make sure you add a filter to block items such as a date, user ID (which might vary depending upon the time the script is running and who is running it).
When recording in Analog mode, avoid holding down the mouse button if this results in a repeated action. For example, do not hold down the mouse button to scroll a window. Instead, scroll by clicking the scrollbar arrow repeatedly. This enables WinRunner to accurately execute the test.
Before switching from Context Sensitive mode to Analog mode during a recording session, always move the current window to a new position on the desktop. This ensures that when you run the test, the mouse pointer will reach the correct areas of the window during the Analog portion of the test.
When recording, if you click a non- standard GUI object, WinRunner generates a generic obj_ mouse_ click statement in the test script. For example, if you click a graph object, it records: obj_ mouse_ click (GS_ Drawing, 8, 53, LEFT); If your application contains a non- standard GUI object which behaves like a standard GUI object, you can map this object to a standard object class so that WinRunner will record more intuitive statements in the test script.
Do not Save in the test procedure unless it is absolutely necessary, this will prevent the need to write numerous clean up scripts.
Do not use the mouse for drop down selections, whenever possible use hotkeys and the arrow keys. When navigating through a window use the tab and arrow keys instead of using a mouse, this will make maintenance of scripts due to UI changes easier in the future.
. If recording on a PC, make sure the environmental settings are set up correctly. Use the Control Panels -> Regional Settings window to make sure that the date format, number formatting, currency, time and date are set the same for all PC's that will be using the scripts. This should be done to ensure that playback of test cases do not fail due to a date, currency or time differences. The best way to handle this is to record a small script to set the correct settings in the Control Panel Regional Settings window.
. If recording on a PC, make sure that all workstations running the scripts have the same Windows Display settings. By setting the PC's window appearance, and display settings the same, this will help ensure that bitmap comparisons and other graphic tests do not fail due to color and size differences. The best way to handle this is to record a small script to set the correct settings in the Control Panel Display Settings window.
When recording, if you click on an object whose description was not learned by the RapidTest Script wizard, WinRunner learns a description of the object and adds it to a temporary GUI map file.
. WinRunner does not compile the scripts until run time, so be careful to check your code before running it. Another option is to put your script in debug mode and step through the code to make sure it will compile correctly.
. Please Indent "if" statements and loops, to help make the code more understandable.
. To add a new object(s) to a GUI map that already exists; perform the following steps:
1. Ensure the no GUI Maps are loaded in the GUI Map Editor.
2. Do a simple recording that will include the object you need added to the GUI Map. This will put the object into the TEMP GUI Map.
3. Go into the Temp GUI Map and delete objects that are already contained in the existing GUI Map.
4. Go into the GUI Map Editor and load the existing GUI Map.
5. Use the Expand button to display two panels on the window.

6. Using the Copy button, copy the values in TEMP into the existing GUI Map. 7. Save the GUI Map file on the network in J:\CorpQATD\TD_Daybr\GUImap . (or substitute TD_web with whatever machine you are currently working on).
. While scripting and debugging your script it is a good idea to put a load command for the Web Function script at the top of your script and an unload at the bottom of your script. This code will automatically load the function library when you run your scripts, thus saving you the extra step when you try to debug your scripts. It is very important to remember to comment out the lines when you are done debugging/developing.
Below is a sample of code you can use.
#this is here for debugging only, when run in shell script will comment out.
#reload ("J:\\CorpQATD\\TD_web\\functions\\Webfunctions");
#this is here for debugging only, when run in shell script will comment out.
#unload ("J:\\CorpQATD\\TD_web\\functions\\Webfunctions");
. If you create a script by copying and existing one as save as, make sure to go into windows explorer to delete the exp and res folders. You could carry with you extra files you don't need.

WinRunner: Documentation:
. Each test procedure should have a manual test plan associated with it.
. Use word to write the detailed test plan information.
. When test planning is completed cut and paste (or translate) the test plans into test director.
. When creating folders, tests and test sets in Test Director make sure every item has as description.
. When creating test scripts, cut and paste the default header script:

###########################################################
# Script Name:
# Description:
#
# Project:
# #########################################################
# Revision History:
# Date: Initials: Description of change:
#
###########################################################
# Explaination of what script does:
#
#
###########################################################
#this is here for debugging only, when run in shell script
#will comment out.
#reload ("J:\\CorpQATD\\TD_Daybr\\functions\\functions");
{put code here}

#this is here for debugging only, when run in shell script #will comment out.
#unload ("J:\\CorpQATD\\TD_Daybr\\functions\\functions");
. Before any automation project is started, the tester will write an automation standard document. The automation standards document will describe the following:
. Automation Environment
. Installation requirements
. Client Machines Configurations
. Project Information
. WinRunner Option Settings
. Identify Servers, Database and Sub System tests will run against
. Naming Convention for project
. Specific Recording Standards that apply to individual project.
. While Scripting please comment major portions of the script using WinRunner's comment command "#" . (example: #This is a comment.)

WinRunner: Naming Conventions:
. Never call a test "tests", WinRunner/TestDirector has problem distinguishing the name test with the directory tests.
. The project automation document will specify any naming conventions used for the individual projects.
. Test Script names should be in UPPER CASE.

WinRunner: When Running Scripts:
When you make your shell script, remember to run it the first time in update mode to create all the expected results, and then run it in verify mode. The reason this needs to be done is because the expect results reside under each specific test script, and for shell scripts it created sub folders for each test it runs. The expected results are not pulled from the individual test area to the shell script area, so it needs to be run in update mode to re-create them. Another option is to use Windows Explorer and copy all your expected results folders to the directory containing the shell script.
WinRunner: How to test to see if the window is maximized
If you want to test to see if the window is maximized here is a sample of how to code it. This code would be best used in the start up script of any automation project.
#first grab the windows handle for the netsoft elite window
win_get_info("Browser Main Window ","handle",value);
#now test to see if window can be maximized
if(win_check_info("Browser Main Window ","maximizable",FALSE)!=E_OK)
{
#Now run maximize function and pass in the handle's value
if (is_maximized(value) == E_OK)
{
report_msg("Ran Max window test and maxed the window");
win_max("Browser Main Window ");
}
else
{
report_msg("Ran Max window test and did not have to do anything");
}
}
# end of script

WinRunner: How to determine which window you are on:
Each time a new browser window appears, you need to test to make sure the correct window is activated. to do with use the following code:
#test to make sure on browser
win_check_info("Browser Main Window_1","enabled",1);
# check to make sure the menu says Menu Selection
menu = obj_check_gui("title_shad", "list5.ckl", "gui5", 5);
if (menu == 0)
report_msg("On Menu Window");
else
{
report_msg("not on right window");
texit:
}

WinRunner: How to test if a link exists and is valid
Use the web_link_valid command, then add some conditional logic to say whether or not the test passed.
# verify the link is valid
set_window("Default Menu", 1);
yes = web_link_valid("YOUR PRODUCT APPLICATION", valid);
if (yes == 0)
report_msg("link exists on page");
else
report_msg("no link");

WinRunner: How to select a link on a web page
In order to select a link, you need to use the web_link_click command.
win_activate ("Browser Main Window");
set_window ("Default Menu", 0);
web_link_click("YOUR PRODUCT APPLICATION");
web_sync(5);

WinRunner: How to check a property of an object on the web page
The most flexible and dynamic GUI check point is the Multiple Objects Check point. This feature allows you to view the objects before selecting them, and then gives you the opportunity to select with properties of the object you want to test.
Steps to Verify contents of a list box:
1. Turn on record in context sensitive mode (this will create GUI objects for you, if you try using insert function only the code will be created, and you will then have to run in update mode to generate the gui checks).
2. Select Create -> GUI Check -> Multiple Objects
3. Next the Create GUI check point window will come up
4. Press the Add button
5. Now move the cursor around the screen and select the object(s) you want to test.
6. When done selecting the objects press right mouse
7. Now you will be brought back to the Create GUI check point window. Listed in the window will be the object(s) you selected. For each object a list of properties will be selected. Using the check boxes on the left select which values you want to check. To view the content of the values, click on the < … > in the expected results.
8. By clicking on the < … > the edit check window will come up, that will allow you to edit the values.
9. When done press OK on all windows. Then the following code will be added to your script.
win_activate ("Browser Main Window_0");
win_check_gui("State Selection", "list1.ckl", "gui1", 1);
10. To modify or edit your GUI check point select Create -> Edit GUI checklist, and the Create GUI check point window will come back up.

WinRunner: Parameterization rules:
. Do not call the excel sheet default.xls, rename it the same name as your script (or calling script).
If you want the change the start row of the table change the code table_Row = 1 on the line
for(table_Row = 1; table_Row <= table_RowCount; table_Row ++)
. The c:\~\WinRunner\dat\ddt_func.ini file lists what functions will work with Data Driven testing. No web functions are listed in this file. If you want to data drive a web function you will have to added them to the file.
. Any Excel file used for data driven testing must be saved in excel format.
. The Excel Files can only have one worksheet and no formatting.
. The character length max for a number in a cell is 10 char. Anything over becomes scientific notation and does not work. There are two workarounds to this problem, option one is to use concatenation, and option two is to use a ' in the field and make the value a string.
Workaround 1:
Use the & (concatenation command to make your values larger. ) Here is a code sample: edit_set("1" & ddt_val(table,"SalesNumMax"));
Workaround 2:
In the data table, instead of typing in the number as 12345678901 type it in as '12345678901. The ' in the front of the number will make it a string (and strings char limits are 255).
. Also a field length can not start with leading 0's. To work around this, use either of the methodologies shown above.
. When defining a new table in the DataDriver Wizard, the table will not be saved if an .xls extension is not specified.
Workaround: When typing the name of a new table, set the name to have an .xls extension. If you use the Parameterize Data function, DO NOT highlight the row, just put your cursor on the space you want to over lay and it will work. If you highlight the whole row, it comes back all messed up.
Here are some steps that explain how to use the DataDriven functionality in WinRunner.
1. Record your script save it
2. Select wizard Tools -> Data Driven Wizard
3. Press Next button
4. At Use a new or existing Excel file box: Navigate to data file area and select data file or enter name for new file.
5. On Assign table name variable: Enter the name to call table in script.
6. Check off Add statements and create a data-driven test
7. Check Parameterize test by line
8. Press Next button
9. On Test Script line to parameterize: either do not replace line (if you don't want to) or select a new column. If you select a new column (you can change column name if you want.
10. Repeat for all lines that appear (this depends upon how many line you have in script.
11. When done press Finish
12. Your script will come back and it is all parameterized for you.

Here are Code:
1 table = "path to excel file";
2 rc = ddt_open(table, DDT_MODE_READ);
3 if (rc!= E_OK && rc != E_FILE_OPEN)
4 pause("Cannot open table.");
5 ddt_get_row_count(table,table_RowCount);
6 for(table_Row = 1; table_Row <= table_RowCount; table_Row ++)
7 {
8 ddt_set_row(table,table_Row);
9 edit_set("Log",ddt_val(table,"Log"));
10 obj_type("Log","");
11 edit_set("password",ddt_val(table, "password"));
12 button_press("Login");
13 }
14 ddt_close(table);
Manual
1. Create an xls file (using WinRunner's Tools -> Data Table)
2. Make the Columns names be your variable name, make the rows be your data.
3. Save the Xls file
4. At the top of your script type line 1 (take from above example) - This sets the table name for you.
5. Type lines 2 - 5 exactly - this tells the script to open the table and does error handling incase it can't open the table, and gets the count of the table
6. Now move cursor to area want to parameterize.
7 Type lines 6 - 8. If you do not want to script to start on row 1, change table_Row = (row to start on).
If you want to run numerous times then create a loop here.
8. Now move cursor to line you want to parameterize. You parameterize by replacing the value in the edit_field statement with ddt_val(table, "variable").
Before:
edit_set("log", "STORE");
After parameterization will look like:
edit_set("Log", ddt_val(table,"Log"));
9. Repeat for all lines you want to parameterize.
10. Then add the closing }.
11. Add the last line (14) to close the table.
12. Repeat steps 7 - 11 for all areas you need to parameterize in code.

ddt_func.ini file:
The Data Wizard functionality uses the ddt_func.ini file to determine which functions you can parameterize. If you run the wizard and find that a certain function does not parameterize the work around is to add the parameter to the ddt_func.ini file. Here are the steps: 1. Shut down WinRunner Application 2. Open the ddt_func.ini file located in your \~\winrunner\dat directory. 3. Add the function you want to add and the parameter of the function you want the Data wizard to change. 4. Save the file 5. Bring up WinRunner Again. 6. Your function should now work with the data wizard
WinRunner: Use the following templates to assist in your scripting
As a default header for all scripts.
###########################################################
# Script Name:
# Description:
#
# Project:
# #########################################################
# Revision History:
# Date: Initials: Description of change:
#
###########################################################
# Explaination of what script does:
#
#
###########################################################
#this is here for debugging only, when run in shell script
#will comment out.
#reload ("J:\\CorpQATD\\TD_Daybr\\functions\\functions");
{put code here}

As a default script will reset the WinRunner's environment to have the correct option settings and GUI maps loaded.
###########################################################
# Script Name: Setenv
# Description: This script sets up the environment for the
# the automated testing suite ( ).
# Project:
# #########################################################
# Revision History:
#
# Date: Initials: Description of change:
#
#
###########################################################
# Load the Gui map
#GUI_unload ("c:\\ \\ ");
# remember to use double slashes
# Load Functions
#font group
# Load any dll's
# set any option parameters for this particular script.
# Turns off error message if the test case fails.
setvar ("mismatch_break", "off");
# Turn off beeping
setvar ("beep", "off");
setvar ("sync_fail_beep", "off");
# Make sure context sensitive errors don't trigger failure
setvar ("cs_fail", "off");
# Sets time winrunner waits between executing statements
setvar ("cs_run_delay", "2000");
# Sets time winrunner waits to make sure window is stable
setvar ("delay_msec", "2000");
# Declare any Constant Declarations
# Declare any Variable Declarations


As a default script to use for calling all the scripts in your project.
###########################################################
# Script Name: OpenClose
# Description: This is the calling(main script that runs ....
#
# Project:
# #########################################################
# Revision History:
#
# Date: Initials: Description of change:
#
###########################################################
status=0;
passed=0;
failed=1;
#Run the set up environment script
call "c:\\ "();
#Run the begin script
call "c:\\ "();
# Run
call "c:\\ "();
# Run end script
call "c:\\ "();
# Run the closeenv script
call "c:\\ "();

As a default script to reset your WinRunner environment to the generic default settings.
###########################################################
# Script Name: closeenv
# Description: This script re-sets the environment to the
# default settings.
# Project:
# #########################################################
# Revision History:
#
# Date: Initials: Description of change:
# 1
#
###########################################################
# Load the Gui map
#GUI_unload ("c:\\ \\ "); # remember to use double slashes
# Load Functions
#font group
# Load any dll's
# set any option parameters for this particular script.
# Turns off error message if the test case fails.
setvar ("mismatch_break", "off");
# Turn off beeping
setvar ("beep", "off");
setvar ("sync_fail_beep", "off");
# Make sure context sensitive errors don't trigger failure
setvar ("cs_fail", "off");
# Sets time winrunner waits between executing statements
setvar ("cs_run_delay", "2000");
# Sets time winrunner waits to make sure window is stable
setvar ("delay_msec", "2000");
# Declare any Constant Declarations
# Declare any Variable Declarations

WinRunner: The following code is written to replace WinDiff as used by WinRunner for showing differences in file comparison checks.
Written by Misha Verplak
INSTRUCTIONS
. Place these files into winrunner \arch directory:
wdiff_replace.exe
wdiff_replace.ini

. Rename wdiff.exe to wdiff_orig.exe

. Rename wdiff_replace.exe to wdiff.exe . Edit wdiff_replace.ini to specify the new difference program

FILES
wdiff_replace.exe compiled program
wdiff_replace.ini settings
wdiff_replace.c C source code
wdiff_readme.txt this file :)

#include
#define TITLE_NAME TEXT("wdiff_replace")
#define CLASS_NAME TEXT("funny_class")
#define BC2_APP_PATH TEXT("C:\\Program Files\\Beyond Compare 2\\BC2.exe")
#define WDIFF_INI TEXT("wdiff.ini")
#define WDIFF_REPL_INI TEXT("wdiff_replace.ini")
#define EMPTY_TXT TEXT("[EMPTY]")
extern char** _argv;
int WINAPI
WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
DWORD res;
TCHAR sLeftFile[MAX_PATH], sRightFile[MAX_PATH];
TCHAR sAllArgs[MAX_PATH*2];
TCHAR sPathDrive[MAX_PATH], sPathDir[MAX_PATH], sPathFile[MAX_PATH], sPathExt[MAX_PATH];
TCHAR sDiffReplIni[MAX_PATH];
TCHAR sDiffApp[MAX_PATH];
TCHAR sErrMsg[MAX_PATH*2];
TCHAR sArgN[10], sArg[MAX_PATH];
int n;
/* using argv[0] (current fullpath exe), extract directory name, expect to find ini there */
_splitpath (_argv[0], sPathDrive, sPathDir, sPathFile, sPathExt);
sprintf(sDiffReplIni, "%s%s%s", sPathDrive, sPathDir, WDIFF_REPL_INI);
/* read wdiff.ini for WinRunner's two files */
res = GetPrivateProfileString(TEXT("WDIFF"), TEXT("LeftFile"), EMPTY_TXT, sLeftFile, MAX_PATH, WDIFF_INI);
res = GetPrivateProfileString(TEXT("WDIFF"), TEXT("RightFile"), EMPTY_TXT, sRightFile, MAX_PATH, WDIFF_INI);
/* check if got the default string, this means didn't get a value */
if (!strcmp(sLeftFile, EMPTY_TXT) || !strcmp(sRightFile, EMPTY_TXT)) {
MessageBox (NULL, TEXT("Problem reading LeftFile or RightFile from wdiff.ini"), TITLE_NAME, MB_ICONERROR | MB_OK);
return(0);
}
/* read wdiff_replace.ini for file & path of replacement to wdiff */
res = GetPrivateProfileString(TEXT("Diff"), TEXT("diff_app"), EMPTY_TXT, sDiffApp, MAX_PATH, sDiffReplIni);
if (!strcmp(sDiffApp, EMPTY_TXT)) {
sprintf(sErrMsg, "Problem reading diff_app from:\n\n%s", sDiffReplIni);
MessageBox (NULL, sErrMsg, TITLE_NAME, MB_ICONERROR | MB_OK);
return(0);
}
/*
* read wdiff_replace.ini for args
* add the arguments together, with quotes, eg. "arg1" "arg2"
* also substitute for LeftFile and RightFile
*/
sprintf(sAllArgs, "");
n=1;
while(1) {
sprintf(sArgN, "arg%d", n);
res = GetPrivateProfileString(TEXT("Diff"), sArgN, EMPTY_TXT, sArg, MAX_PATH, sDiffReplIni);
if (!strcmp(sArg, EMPTY_TXT)) break;
if (!strcmp(sArg, TEXT("LeftFile"))) strcpy(sArg, sLeftFile);
if (!strcmp(sArg, TEXT("RightFile"))) strcpy(sArg, sRightFile);
if (n == 1) {
sprintf(sAllArgs, "\"%s\"", sArg);
}
else {
sprintf(sAllArgs, "%s \"%s\"", sAllArgs, sArg);
}
n++;
}
/* Run alternative diff application with its args (could use spawn here?) */
res = execlp (sDiffApp, TEXT("dummy"), sAllArgs);
/* exec replaces current app in the same env, so only get to here if problems */
sprintf(sErrMsg, "Problem running diff_app:\n\n%s", sDiffApp);
MessageBox (NULL, sErrMsg, TITLE_NAME, MB_ICONERROR | MB_OK);
return 0;
}
WinRunner: The following script and dll provides WinRunner with perl-like regular expression search and match functions, to use with any GUI property, and add search and match functions.
By Misha Verplak
# regular expressions from DLL
extern int re_match(string str, string re, out int m_pos, out int m_len, inout string detail <252>);
extern int re_search(string str, string re, out int m_pos, out int m_len, inout string detail <252>);
public function re_func_init()
{ auto re_func_dll, html_name;
# location of dll
re_func_dll = getenv("M_ROOT") "\\arch\\rexp.dll";
# to access exported functions
load_dll(re_func_dll);
# function generator declarations
generator_add_function("re_search","Search a string for a regular expression.\n"
"Returns 0 no match, 1 found match, gets position and length.\n"
"Submatch results in 'detail', use re_get_details() or re_get_match().",5,
"search_string","type_edit","\"string to search\"",
"regular_expression","type_edit","\"regexp\"", "Out position","type_edit","position",
"Out length","type_edit","len", "Out detail","type_edit","detail");
generator_add_category("regex");
generator_add_function_to_category("regex","re_search");
generator_set_default_function("regex","re_search");

generator_add_function("re_match","Match a regular expression to a whole string.\n"
"Returns 0 no match, 1 found match, gets position and length.\n"
"Submatch results in 'detail', use re_get_details() or re_get_match().",5,
"match_string","type_edit","\"string to match\"",
"regular_expression","type_edit","\"regexp\"", "Out position","type_edit","position",
"Out length","type_edit","len", "Out detail","type_edit","detail");
generator_add_function_to_category("regex","re_match");

generator_add_function("re_get_detail","Get the (sub)match position and length from the detail.\n"
"Typically used after re_search() or re_match()\nsubmatch can be 0 for whole match",6,
"detail","type_edit","detail", "submatch","type_edit","0", "Out nsubs","type_edit","nsubs",
"Out line","type_edit","line", "Out position","type_edit","position", "Out length","type_edit","len");
generator_add_function_to_category("regex","re_get_detail");

generator_add_function("re_get_match","Get the (sub)matched string from the detail.\n"
"Typically used after re_search() or re_match()\nsubmatch can be 0 for whole match",4,
"original_string","type_edit","orig_str", "detail","type_edit","detail",
"submatch","type_edit","0", "Out match_str","type_edit","match_str");
generator_add_function_to_category("regex","re_get_match");

generator_add_function("re_print_detail","Print the re match details to the debug window.\n"
"Typically used after re_search() or re_match().",1, "detail","type_edit","detail");
generator_add_function_to_category("regex","re_print_detail");

generator_add_function("matche","Replacement for the builtin match() function.",2,
"match_string","type_edit","\"string to match\"", "regular_expression","type_edit","\"regexp\"");
generator_add_function_to_category("string","matche");
generator_add_function_to_category("regex","matche");
generator_add_function("match","Do not use this function. Use matche() instead.",0);
}

# replacement for the builtin match() function
public function matche(search_string, regexp)
{
extern RSTART, RLENGTH;
auto rc, m_pos, m_len, detail;
if(re_search(search_string, regexp, m_pos, m_len, detail))
{
rc = m_pos+1;
RSTART = m_pos+1;
RLENGTH = m_len;
}
else
{
rc = 0;
RSTART = 0;
RLENGTH = 0;
}
return rc;
}

# internal function to decode detail from DLL
function _detail_decode(detail, position, nbytes)
{
auto v, v_hi;
v = int(ascii(substr(detail, position, 1))/2);
if(nbytes == 2)
{
v_hi = int(ascii(substr(detail, position+1, 1))/2);
v += v_hi*256;
}
return v;
}

# dump the detail to WinRunner's debug window
#
# structure of the detail string:
# (1 byte ) size of this detail, ie. number of submatches + 1
# (2 bytes) line number where match occurred, counting from 1
# [(2 bytes) position of (sub)match, 0-th submatch is whole match
# [(2 bytes) length of (sub)match
# [--------- repeated to a maximum of 50 submatches ---]
#
public function re_print_detail(detail)
{
auto size, line, i, pos, len, s;

size = _detail_decode(detail, 1, 1);
print "size " size;
if (size == 0) return E_OK;
print "submatches " (size-1);
line = _detail_decode(detail, 2, 2);
print "line " line;

for (s=0; s{
pos = _detail_decode(detail, s*4+4, 2);
len = _detail_decode(detail, s*4+6, 2);
print "sub(" s ") pos: " pos " len: " len;
}
return E_OK;
}

# get the (sub)match position and length from the detail
public function re_get_detail(in detail, in submatch, out nsubs, out line, out position, out len)
{
auto size;

nsubs = 0;
position = 0;
len = 0;
line = 0;

size = _detail_decode(detail, 1, 1);
if (size == 0) return E_NOT_FOUND;
nsubs = size-1;
if (submatch < 0) return E_OUT_OF_RANGE;
if (submatch+1 > size) return E_OUT_OF_RANGE;

line = _detail_decode(detail, 2, 2);
position = _detail_decode(detail, submatch*4+4, 2);
len = _detail_decode(detail, submatch*4+6, 2);
return E_OK;
}

# get the (sub)matched string from the detail
public function re_get_match(in orig_str, in detail, in submatch, out match_str)
{
auto rc, nsubs, position, len, line;

match_str = "";

rc = re_get_detail(detail, submatch, nsubs, line, position, len);
if (rc != E_OK) return rc;

match_str = substr(orig_str, position+1, len);
return E_OK;
}

Q: Online Vs Batch Execution - Functions & Compiled Modules - Wild Card Characters
. Every time there is a change in the Application Object I need to change the Object name and rerun the Test Script with a new object Name. Any suggestions on it.?
If there is a minimal change in the application Object then it is better to wild card the Object properties

Q:Coming up soon for the following Questions. If you know the answers, please email to us !
How do you call a function from external libraries (dll).
What is the purpose of load_dll?
How do you load and unload external libraries?
How do you declare external functions in TSL?
How do you call windows APIs, explain with an example?
What is the purpose of step, step into, step out, step to cursor commands for debugging your script?
How do you update your expected results?
How do you run your script with multiple sets of expected results?
How do you view and evaluate test results for various check points?
How do you view the results of file comparison?
What is the purpose of Wdiff utility?
What are batch tests and how do you create and run batch tests ?
How do you store and view batch test results?
How do you execute your tests from windows run command?
Explain different command line options?
What TSL function you will use to pause your script?
What is the purpose of setting a break point?
What is a watch list?
During debugging how do you monitor the value of the variables?
Describe the process of planning a test in WinRunner?
How do you record a new script?
Can you e-mail a WinRunner script?
How can a person run a previously saved WinRunner script?
How can you synchronize WinRunner scripts?
What is a GUI map? How does it work?
How can you verify application behavior?
Explain in detail how WinRunner checkpoints work. What are standard checkpoints?
What is a data-driven test? What are the benefits of a data-driven test?
How do you modify logical names on GUI map?
Why would you use batch testing under WinRunner? Explain advantages and disadvantages. Give an example of one project where you used batch testing.
How do you pass parameter values between the tests? typically learns all the objects in the window else we will identifying those object, which are to be learned in a window, since we will be working with only those objects while creating scripts.
Have you used WinRunner Recovery Manager?
What is an exception handler? Wny would you define one in WinRunner?
We’re testing an application that returns a graphical object (i.e., a map) as a result of the user query. Explain how you’d teach WinRunner to recognize and analyze the returned object.
What is a TSL? Write a simple script in TSL.

WinRunner: Web sites contain Java applets
If your web sites contain Java applets, you need to install Java add-in support for WinRunner.

WinRunner: To Record the Web Application
Recommendation: Set your browser to accept cookies. This will prevent a pop up window asking about the cookie from interfering with your script.

WinRunner: Steps to take before recording:
. Before starting to record, you should close all applications that are not required for testing. (Mail, Explorer, Screen Savers, CD Player etc).
. After installing a new version of Test Director and WinRunner, it is a good idea to make a back up copy of the following ini files to another location(testers choice of location). This is recommended to allow the tester to easily reset their WinRunner/TestDirector environment in the event of system corruption.
c:\windows\wrun.ini
c:\windows\mercury.ini
c:\~\TestDirector\bin\td.ini
c:\~\TestDirector\bin\filters.ini
c:\~\TestDirector\bin\forms.ini
c:\~\TestDirector\bin\grids.ini
c:\~\WinRunner\dat\ddt_func.ini
. Make sure your system is set up with all the necessary library functions that have been created.
. Make sure you create a GUI map and font group for each project.
. In the tsl_init file add the command GUI_close_all();. This command will make sure that no GUI maps are loaded when you bring up the WinRunner application. The benefit of this approach is that it will force the tester to load the correct GUI map for their testing, thus preventing scripting errors and other complications.

WinRunner: Libraries Needed for automation:
A number of libraries have been created to aid in the automation projects. Below is a list of the libraries that should be installed on each individual machine.
. csolib32 - This is a library full of many useful functions. This library was created by Mercury Customer Support and can be found in the following zip file csolib.zip. In order to access the library functions, the tsl_init file needs to be modified to run the cso_init file (which will load the libraries when the WinRunner application boots up).
. WebFunctions - This is a library contains functions designed to run on the YOUR-COMPANY Web systems.

WinRunner: Commands and Checkpoint Verification information for Web:
. Must do a set_window(); command for each action on a new window, this will assist the script in recognizing/resetting the window state and help prevent scripts failing due to slow network/system performance.
. Must add report_msg or tl_step command after each test to record what happens in the test.
. A obj_check_qui statement checks only one object on the window, and win_check_qui statement checks multiple objects in the window.
. The single property check allows you to check a single property of an object. The single property check dialog will add one of the following functions to your script.
button_check_info
edit_check_info
list_check_info
obj_check_info
scroll_check_info
static_check_info
The Object/Window check allows you to check every default object in the window. After it has completed it inserts an obj_check_gui statement in your script.
The Multiple Objects check allows you to check two or more objects in the window. This selection works best, because it first brings up the checkpoint window, then after the user selects add you can navigate to the AUT. Also, for some reason, the data in the object is retrieved with this feature but not the object/window check. After it has completed it inserts a win_check_gui statement in your script.
. There are 3 main types of GUI checks you can do with WinRunner. Single Property and Object/Window checks, and Multiple Objects.
. There are 35 Web functions, that come with the web test add-in. For the full list please see the TSL reference guide. The table below lists the most commonly used functions.

Function Description
web browser invoke Invokes the browser and opens a specified site.
web image click Clicks a hypergraphic link or an image.
web label click Clicks the specified label.
web link click Clicks a hypertext link.
web link valid Checks whether a URL name of a link is valid (not broken).
web obj get info Returns the value of an object property.
Needs a set_window command to be run before used
web obj get text Returns a text string from an object.
web obj text exists Returns a text value if it is found in an object.
web sync Waits for the navigation of a frame to be completed.
web url valid Checks whether a URL is valid
web find text Returns the location of text within a page.

. Most of the Web Test functions do not return a value to the test log, in order to record a pass or fail, conditional logic will have to be added to your code below the web function to send a tl_step or report_msg to the log

WinRunner: How to Structure tests for Web:
Create Begin and End Scripts. This will ensure that WinRunner starts and stops from the same place.
. Mercury recommends that it is better to use smaller specific GUI maps for your testing than have one large GUI map that encompasses your whole application.
. Comment all major selections or events in the script. This will make debugging easier
. Need to create a init script to load correct GUI map, font group and set option variables.
A few of the options you should set are:
# Turns off real time error message reporting if the test case
# fails. The error is still logged in the test results window.
setvar ("mismatch_break", "off");
# Turn off beeping
setvar ("beep", "off");
setvar ("sync_fail_beep", "off");
# Make sure context sensitive errors don't trigger real time
# failures that stop the script. The error is still logged in the
# test results window.
setvar ("cs_fail", "off");
# Sets time winrunner waits between executing statements
# (Mercury default is 0)
setvar ("cs_run_delay", "500");
# Sets time winrunner waits to make sure window is stable
# (Mercury default is 1000)
setvar ("delay_msec", "500");
# Sets the fail test when single property fails to uncheck (bug - recommend set to un-check) setvar ("single_prop_check_fail", "0");
. Determine all paths to start up directory and then set them in the options window.
. In your closing/ending scripts use the GUI_unload_all command to unload all GUI maps in memory.