|
QA Partner tips:
How do I get out of an infinite loop?
Click here
CurrentPath and CurrentFile keywords Click here
Printf Click here
Are the SilkTest Products Y2K Compliant? Click here
Let Silk do the Hard Stuff Click here
A Semi-Automated Way to do Manual Testing Click here
GetExecutableVersion Click here
Binding Agent Options Click here
Fault Trapping Click here
DontInheritClassTag Click here
Help! How do I get out of an infinite loop?
If you have code that continues in a while loop until a dialog appears -- and that dialog fails to be invoked --
then you may end up in an infinite loop.
Normally, you can simply choose Abort from the Run menu. Sometimes, though, the automation keeps trying to make
the test application active making it nearly impossible to access the SilkTest menus.
In this case, there is a 'back-door' way of aborting the running of the automation script ... Press BOTH Shift
keys simultaneously
CurrentPath
and CurrentFile keywords
CurrentPath is a keyword whose value
is the path (not including the file name) of the file containing the reference to CurrentPath. CurrentFile is a
keyword whose value is the name of the file (not including the path) containing the reference to CurrentFile.You
can use these keywords to locate files at runtime.
See the Silk Online help for more information
Printf
Besides the well-known Print function, 4Test also supports the Printf function, same as for Ansi C.
See the Silk Online help for more information
The Segue product
line is Y2K compliant.
But don't take my word for it -- take a look at their web page Click here
Let Silk do the Hard
Stuff
For instance, if you want to explicitly trap for an exception of type
"Window Not Found", then what is the Exception Number to look for? Yes, you can find the Segue source
files and read through the approximately 170 exception numbers until you locate the one you want. An easier way
is to write code such as this:
do
//reference to a declared window
//that will not be found (such as a
//modal dialog that is not invoked)
except
Print (ExceptNum ())
By doing this, the result file will contain the string "-27800". That's
exactly what we are searching for.
Now I can write the code in this way:
do
//reference to a declared window
//that maybe will not be found
//(such as a modal dialog that is
//not invoked)
except
if (ExceptNum () == -27800)
LogWarning ("your message...")
else
reraise
Note that reraise passes control to the next exception handler in the current block, or in any block in which the
function that caused the exception is called. If no other exception handler is found, the script halts.
A Semi-Automated Way
to do Manual Testing
No automation tool can easily test such elements as Bitmaps, Colors, or
Fonts as the Device Context handle has already been recycled by the time
that object has been painted.
However, a clever approach to this testing can be done by combining Active Links with automation. In general, the
"automation" would work this way: The Form Window or Dialog is opened, with some bitmap, color, or
font on it -- and the text trim asks the user if that element looks correct
(such as, "If the button's text does not look red, then press the 'Fail'
button.") When the user pushes the appropriate button, then the Active Link
fires and then either closes the Dialog and/or perhaps changes a status from 'New' to either 'Pass' or 'Fail'.
The automation, which has been waiting either for the Dialog to no longer exist or for the status to no longer
be 'New', now can get out of the "infinite" while loop and go to the next line in the script. If the
test fails, based upon the user's input, the automation then
logs the appropriate failure to the results file. This still requires the automation to be monitored and some questions
answered by a human, but the tedious, repetitive actions are automated.
GetExecutableVersion
This is a new method made available in Silk 5.0.2 ... it is not supported,
but seems to work. I don't know all of its uses, yet, but it is useful when
trying to determine the version of Browser.
For instance, the following code will return the major version and minor
version of the Internet Explorer Browser (where it has been set as the
default browser) as 5 and 0:
INTEGER iMajor, iMinor
Browser.GetExecutableVersion (iMajor, iMinor)
Binding Agent
Options
Normally, if you need to change an Agent option within your script, you end
up writing code such as:
Agent.SetOption (OPT_VERIFY_UNIQUE, FALSE)
// Your code that requires non-unique windows
Agent.SetOption (OPT_VERIFY_UNIQUE, TRUE)
which turns out not to work well because sometimes your testcase fails in
the code between the setting of Agent options and it never gets reset (such
as back to TRUE in the example above).
A solution to this is to instead use BindAgentOption in a withoptions block.
For example, the same code above would look like this:
withoptions
BindAgentOption (OPT_VERIFY_UNIQUE, FALSE)
The nice thing is that the 4Test code remembers the previous Agent option
and resets it when the block exits. Although listed in the Help file as
officially being "... provided as a convenience to you, but ... not
thoroughly tested, " it works well and doesn't seem to cause any
side-effects in existing automation code.
Fault Trapping
If you plan to use 32-bit Fault Trapping in your automation, remember to not
set it up on your Windows 95 workstations.
As it states in the SilkTest release notes -- On Windows 95, if you have
fault trapping enabled and a fault occurs, SilkTest may freeze. (Issue
#25713).
DontInheritClassTag
If you derive a new class based upon an existing one, then the Window
Declarations Recorder has an irritating habit of using the new class name
when recording -- rather than the class itself. For instance, if you created a class RButton that is of type PushButton,
the recorder will record all future push buttons as being RButton class. There are two ways to avoid this. The
less intuitive way is to provide a placeholder tag (such as "Dont Use This") when defining your new class.
Any instance of this class will have its own tag that will override the "bogus" one. At least this way,
the recorder now won't mistakenly misdeclare the object. The better way to do this, though, is to add the line
of code "setting DontInheritClassTag=TRUE" under the new window class declaration. When using that line
of code, you don't need to create bogus tags.
|