A tool or device is a piece of equipment which typically provides a mechanical advantage in accomplishing a physical task, or provides an ability that is not naturally available to the user of a tool. The most basic tools are simple machines.
  For example, a crowbar simply functions as a lever. The further out from the pivot point, the more force is transmitted along the lever. When particularly intended for domestic use, a tool is often called a utensil.

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.

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.

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"}",);

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

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

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.