Need to validate text fields against : > Null > Not Null. > whether it allows any Special Characters. > whether it allows numeric contents. > Maximum length of the field etc. * 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. * Write manual tests for doing what you want. This will create a structure to form the basis of our WR tests. * now create your WR scripts. I suggest that we use data driven tests and use Excel spreadsheets for our 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

> logicalname:"chkESActivity" { class: check_button, MSW_class: html_check_button, html_name: chkESActivity, part_value: 90 } > logical name "chkESActivity_1" { class: check_button, MSW_class: html_check_button, html_name: chkESActivity, part_value: 91 } Replace with: # we give any name as the logical name Logical:"CheckBox" { class: check_button, MSW_class: html_check_button, html_name: chkESActivity, part_value: "![0-9][0-9]" } # changes were done here we 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

We 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.

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.

set_window("Name of the window"); obj_check_info("Name of the object ","focused",0ut_value); check for out_value & proceed further

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.

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 "!".

> Use get-time to get the PC system time in seconds since 01/01/1970 > Subtract 86400 (no seconds in a day) from it > Use time_str to convert the result into a date format > If format of returned date is not correct use string manipulations to get the format you require > Insert the date into your application Alternatively we could try the following : > In an Excel datasheet create a column with an appropriate name, and in the first cell of the column use the excel formula. > Format the cell to give us the required date format. > Use the ddt : functions to read the date from the excel datasheet. > Insert the reteived date into our application .

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; }

Suppose we are running a batch test on an unstable version of our application. If our application crashes, We 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. We implement this function to respond to the unexpected error in the way that meets our specific testing needs. Once we 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.