|
1)
How do you handle unexpected events and errors?
a)
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.
2)
How do you handle pop-up exceptions?
a)
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
i.
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.
ii.
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.
3)
How do you handle TSL exceptions?
a)
A TSL exception enables you to
detect and respond to a specific error code returned during test execution.
b)
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.
c)
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.
d)
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.
4)
How do you handle object exceptions?
a)
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.
b)
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
5)
How do you comment your script?
a)
We comment a script or line of
script by inserting a ‘#’ at the beginning of the line.
6)
What is a compile module?
a)
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.
b)
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.
7)
What is the difference between script and compile module?
a)
Test script contains the executable
file in WinRunner while Compiled Module is used to store reusable functions.
Complied modules are not executable.
b)
WinRunner performs a
pre-compilation automatically when it saves a module assigned a property value
of “Compiled Module”.
c)
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" );
d)
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");
|
