Saturday, July 12, 2008


SilkTest is
• A powerful tool for running automated test cases on the front end
• A tool for testing Web based applications across different browsers
• Very very stupid – you have to tell it everything in its own language (4test)
• Inflexible when it comes to interpreting your commands
_ It cannot guess at what you mean
_ It requires a certain syntax with certain words
• This can be quite maddening
Different Versions in Silk Test.
1. Silk Test 5.0
2. Silk Test 5.2
3. Silk Test 5.6
4. Silk Test 6.0
5. Silk Test 6.5
6. Silk Test 7.1
Latest Version of the Silk Test is 7.5
Note: The Following Questions are based on the latest version of the Silk Test
Q1. How do I add steps to DefaultBaseState?
The easiest method is to add a BaseState () method to the main window of the application. That's
the one that wMainWindow is set to. If you define this method, it will be executed at the end of
DefaultBaseState (). Suggestion: By using GetTestCaseState (), you can make your method
behave differently depending on whether the testcase is starting or stopping. This function will tell
you whether the testcase is starting or stopping.
Q2. Where can I find all the methods for a class?
Use the Library Browser. Its invoked by choosing Help-->Library Browser from the SilkTest menu.
Select the class tab, then select the class you want to view. The methods for the class appear in
the right panel. You can click on a method and view its syntax. If you check the box marked Show
Inherited, all the methods from the ancestor classes will be shown. Its major disadvantage is that
you can't copy from it.
Q3. Why don't methods defined in a derived class inherit ?
When you create a class using winclass MoveableWin : MoveableWin, you're actually deriving a
new class which has the same name as the original class. All objects automatically become
instances of the new derived class. However, other derived classes, such as DialogBox in this
case, have already been inherited from the original MoveableWin. This happened at startup and
can't be changed. Therefore, any methods you added to the inherited MoveableWin class will not
be available for use by DialogBox objects
Q4. How can I change test frames in the middle of a testplan?
First you need to understand optionsets. This feature lets you save your configuration in a file.
The configuration includes your Agent Options, Runtime Options and Class Mappings. The
feature is very useful when you try to open your test frame on a new machine. The optionset
brings all the settings from one machine to another, including the test frame. This is also very
useful for a team.
Q5. Can I pass global variables from SilkOrganizer to SilkTest ?
Yes, you can just reference them directly. For example, if you have a list of string defined
in the test frame, you can pass the variable from SilkOrganizer as testdata or directly in the
testcase statement.
Q6. Is the Extension Kit difficult to use ?
No, if you have the cooperation of the developer (s). If they understand the value of adding
functionality for you and if you're perfectly clear about what you need, you will have very quick
success at implementing the EK. This assumes that the technology for them to retrieve the
information you want exists within their application. Sometimes with 3rd party controls, there is no
exposed API which provides what you need. Unfortunately, sometimes you will need to verify
some custom objects manually (visually).
Q7. Can I call Silk Scripts from an external shell program. ?
Yes. One way is to just call Silk and pass the name of the script using the command line
arguments. The complete list of arguments is shown below.
Command Line Options
optionset: filename
Machine Name
Script / Testplan / or Suite Name
Quit SilkTest after the script or plan completes execution.
Testplan query to run
Post error count to calling program
Output results files to rex files
partner -m LabMachine13 -q -query FunctionalTests -r InsertNewData.pln
Q8. What's the difference between SilkTest and QA Partner ?
Originally there was only one product, QA Partner. In 1996, Silk (later renamed SilkTest), was
introduced as the Web Testing tool. It was actually the same executable as QA Partner, but with
browser capabilities turned on. This turned out to be confusing for most customers. If you bought
Silk, you could just turn off the browser feature and then you'd have QA Partner. However, if you
bought QA Partner, you wouldn't have the ability to test browsers. Starting with SilkTest 5.0, there
is only one product again.
Q9. What is Immediate If?
Immediate If is a 4-test operator which is little known. It allows you to do an if-then-else
on a single line. The syntax is as follows:
boolean ? ReturnValueIfTrue : ReturnValueIfFalse
STRING sGreeting = bFirstTime ? "Welcome" : "Welcome back"
Q10. When do you need to use the "this" keyword and when don't you?
The "this" keyword is used in window class methods to refer to the instance variable which is
calling the method at runtime. The "this" keyword is only required when you want to access a
data member which is uniquely defined in the instance. Otherwise its use is optional.
winclass DialogBox : DialogBox
Close ()
this.wCloseButton.Click ()
NewMethod ()
if (Exists ())
// Perform some steps
window DialogBox Test
tag "Test"
parent MyApplication
window wCloseButton = Exit
PushButton Exit
tag "Exit"
main ()
Test.Close ()
In the close method above, the "this" keyword is required because the method needs to
reference a data member which is declared in the instance "Test". In the NewMethod
above, this.Exists () is not required, because it is referencing a method which is defined at
the class level.
Q11. Should I create a function or a method?
If the action you are automating is:
closely related to a specific window, create a method of that specific window. closely related to a
class of objects, create a method of that window class. more of a utility, not related to a window or
class of windows, create a function.
Q12. What does the recording statement do?
The recording statement set the following Agent Verification options to FALSE
This can be useful if you specifically want to turn these verifications off for a specific
block of code, but usually it is better to remove the recording statement after you record
the statements you need (run with these options set to TRUE)
Q13. When and why is the Sleep () statement needed?
Sometimes Silk can't tell when an application is busy. When this happens, Silk tries to
execute the next step which gets thrown away by the application or causes an error which
is usually very difficult to reproduce either manually or under debug mode. When this
happens, a well-placed Sleep (2) or Sleep (5) can often solve this annoying problem. A
few extra sleep statements to make sure that the application is ready to move forward
may be worth the small difference in the time it takes to execute your scripts.
14. What is WinClass?
Declares a window class for an application-specific window or control.
Note Window class declarations must appear outside of any function.
15. Features in silk 7.5
The list of New features in 7.5 are
1) Support for Infragistics Grid and Toolbar controls
2) Project packaging for relocating and emailing
3) Project Explorer enhancements
4) Java Custom Windows record and playback enhancements
5) Beta support for .NET Framework Version 2
6) Updated technology support
JDK 1.5
AOL 9 Security Edition
Sybase PowerBuilder 10
Silent Installation
Support for Microsoft's Source Code Control Integration
16. What is Frame File
The test frame file
The test frame file includes the following:
· A constant named wMainWindow
· A window of class BrowserChild
A constant named wMainWindow
This constant points to the home page of your application, that is, the page that was loaded when
you created the test frame. The recovery system uses wMainWindow to restore the browser to
that page when a test fails. Just as a non-Web application typically has a state where you want
the tests to start (the base state), Web applications also have a base state. Typically, it is the first
page in the application. See Web applications and the recovery system for more information.
A window of class BrowserChild The window has the same identifier as the value of
wMainWindow. It is this window that, by default, SilkTest loads in order to restore the base state.
The window declaration contains:
· The constant sLocation, which is the URL for the page. The recovery system uses
this constant to load the page when necessary.
· Two commented constants, sUserName and sPassword which specify the user name and
password to access the application. See Specifying username and password.
· Two commented constants, BrowserSize and bDefaultFont, which specify the size of the
browser window and the default font to use for displaying text. See Specifying browser size and
· All the objects in the page, such as HtmlHeadings, HtmlText, HtmlLinks, HtmlText,
HtmlPushButtons, and so on
17. How to run the script in Remote Machine
Running tests on one remote target
There are three ways in SilkTest to specify that you want a script, suite, or testplan to run
on a remote target instead of the host:
· Enter the target Agent’s name in the host’s Runtime Options dialog. You also need to select a
network protocol in the dialog. If you have been testing a script by running SilkTest and the Agent
on the same system, you can then test the script on a remote system without editing your script
by using this method.
· Specify the target Agent’s name by enclosing it within brackets before the script
or suite name [Ohio]myscript.t · You can select "(none)" in the host’s Runtime Options dialog and
then specify the target Agent’s name in a call to the Connect function in your script. For example,
to connect to a machine named Ontario:
testcase MyTestcase ()
Connect ("Ontario")
// Call first testcase
DoTest1 ()
// Call second testcase
DoTest2 ()
Disconnect ("Ontario")
When you are only driving one remote target, there is no need to specify the current machine; all
testcase code will automatically be directed to the only connected machine. When you use the
multi-application support functions, you will not have to make explicit calls to Connect; the support
functions will issue these calls for you.
18. What is Results File
A results file provides information about the execution of the testcase, script, suite, or testplan. By
default, the results file has the same name as the executed script, suite, or testplan, but with a
.res extension (for example, find.res). Whenever you run tests, SilkTest generates a results file,
which indicates how many tests passed and how many failed, describes why tests failed, and
provides summary information. You can invoke comparison tools from within the results file that
pinpoint exactly how the runtime results differ from your known baselines. Testplan results files
offer additional features, such as the ability to generate a Pass/Fail report or compare different
runs of the testplan. When SilkTest displays a results file, on the menu bar it includes the Results
menu, which allows you to manipulate the results file and locate errors. The Results menu
appears only when the active window displays a results file.
A .res file can be opened by multiple users, as long as no test is in process. This means you
cannot have 2 users run tests at the same time and write to the same results file. You can run a
test on the machine while the file is open on the other machine. However, you must not add
comments to the file on the other machine, or you will corrupt the .res file and will not be able to
report the results of the test. If you add comments to the file on both machines, the comments will
be saved only for the file that is closed (and therefore saved) first. By default, the results file
displays an overall summary at the top of the file, including the name of the script, suite, or
testplan; the machine the tests were run on; the number of tests run; the number of errors and
warnings; actual errors; and timing information. To hide the overall summary, click on the
summary and select Results/Hide Summary. For a script or suite results file, the individual test
summaries contain timing information and errors or warnings. For a testplan results file, the
individual test summaries contain the same information as in the overall summary plus the name
of the testcase and script file.
While SilkTest displays the most current version of the script, suite, or testplan, by default
SilkTest saves the last five sets of results for each script, suite, or testplan executed. (To change
the default number, use the Runtime Options dialog.) As results files grow after repeated testing,
a lot of unused space can accumulate in the files. You can reduce a results file’s size with the
Compact menu option. The format for the rest of a testplan results file follows the hierarchy of test
descriptions that were present in the testplan. Test statements in the testplan that are preceded
by a pound sign (#) as well as comments (using the comment statement) are also printed in the
results file, in context with the test descriptions.
To change the default name and directory of the results file, edit the Runtime Options dialog.
19. How to Generate a Testplan Completion report
To measure your QA department’s progress in implementing a large testplan, you can generate a
Completion report. The Completion report considers a test complete if the test description is
linked to a testcase, with two exceptions:
1 If the testcase statement invokes a data-driven testcase and a symbol being passed
to the data-driven testcase is assigned the value ? (undefined), the test is considered
2 If the testcase is manual and marked as Incomplete in the Update Manual Tests
dialog, the test is considered incomplete. (A manual testcase is indicated with the
testcase:manual syntax; for more information, see indicating manual tests in a testplan .
To generate a testplan completion report:
1 Open the testplan you want to report on.
2 Select Testplan/Completion Report to display the Testplan Completion Report
3 In the Report Scope group box, indicate whether the report is for the entire plan or
only for those tests that are marked.
4 To subtotal the report by a given attribute, select an attribute from the Subtotal by
Attribute field.
5 Click Generate. The testplan editor generates the report and displays it in the
lower half of the dialog. If the testplan is structured as a master plan with associated
subplans, the testplan editor opens any closed subplans prior to generating the report.
You can:
· Print the report.
· Export the report to a comma-delimited ASCII file. You can then bring the report
into a spreadsheet application that accepts comma- delimited data.
· Chart (graph) the report, just as you can chart a Pass/Fail reportFor more information, see
Producing a Pass/Fail chart (everything in that section also applies to charting Completion
reports, except for the description of adding results from another execution of the testplan, which
applies only to Pass/Fail reports).
20. What is a TestCase
A test case has three stages
Each testcase that you record should have the following stages:
1 Stage 1: The testcase drives the application from the initial state to the state you
want to test.
2 Stage 2: The testcase verifies that the actual state matches the expected (correct)
state. (Your QA department might use the term baseline to refer to this expected state.)
This stage is the heart of the testcase.
3 Stage 3: The testcase cleans up the application, in preparation for the next
testcase, by undoing the steps performed in stage 1.
Each test case is independent
Each testcase you record should perform its own setup in stage 1, and should undo this setup in
stage 3, so that the testcase can be executed independently of every other testcase. In other
words, the testcase should not rely upon the successful or unsuccessful completion of another
testcase, and the order in which it is executed should have no bearing on its outcome.
If a testcase relies on a prior testcase to perform some setup actions, and an error causes
the setup to fail or, worse yet, the application to crash, all subsequent testcases will fail
because they cannot achieve the state where the test is designed to begin.
A testcase has a single purpose
Each testcase you record should verify a single aspect of the application in stage 2. When
a testcase designed in this manner passes or fails, it’ s easy to determine specifically what aspect
of the target application is either working or not working.
If a testcase contains more than one objective, many outcomes are possible. Therefore, an
exception may not point specifically to a single failure in the software under test but rather to
several related function points. This makes debugging more difficult and time consuming and
leads to confusion in interpreting and quantifying results. The net result is an overall lack of
confidence in any statistics that might be generated. Note But there are techniques you can use
to do more than one verification in a testcase. See Performing more than one verification in a
A testcase starts from a base state
In order for a testcase to be able to function properly, the application must be in a stable
state when the testcase begins to execute. This stable state is called the base state. The
recovery system is responsible for maintaining the base state in the event the application
fails or crashes, either during a testcase’s execution or between testcases.
To restore the application to the base state, the recovery system contains a routine called
DefaultBaseState that makes sure that
· The application is running and is not minimized
· All other windows (for example, dialogs) are closed
· The main window of the application is active
If these conditions are not sufficient for your application, you can customize the recovery
Defining test requirements
When defining test requirements, the goal is to rigorously test each application feature.
To do so, you need to decide which set of inputs to a feature will provide the most
meaningful test results.
21. How to Enter the TestData
Entering the testdata statement manually
1 Open up a new line after the test description and indent the line one level.
2 Enter the testdata statement as follows, if the testcase expects:
· one or more variables, use this syntax: testdata: data [,data], where data is any valid 4Test
· a record, use the same syntax as above, but open and close the list of record fields with curly
braces: testdata: {data [,data]}, where data is any valid 4Test expression
Note Be sure to follow the testdata keyword with a colon. If you enter the keyword correctly, the
statement appears in dark red, the default color. Otherwise, the statement appears in either blue
or black, indicating the compiler is interpreting the line as a description.
Specifying unique and shared data
If a data value is unique to a single test description: you should place it in the plan at the same
level as the test description, using the testdata statement. You can add the testdata statement
using the Testplan Detail dialog or type the testdata statement directly into the testplan.
If data is common to several tests: you can factor out the data that is common to a group of tests
and define it at a level in the testplan where it can be shared by the group. To do this, you define
symbols and assign them values. Using symbols results in less redundant data, and therefore,
less maintenance.
Using the Testplan Detail dialog to enter the testdata statement
1 Place the insertion point at the end of the test description. If a testdata statement is not
associated with a test description, the compiler generates an error.
2 Select Testplan/Detail. To provide context, the multi-line list box at the top of the Testplan Detail
dialog displays the line in the testplan that the cursor was on when the dialog was invoked,
indicated by the black arrow icon. If the testcase and script associated with the current test
description are inherited from a higher level in the testplan, they are shown in blue; otherwise,
they are shown in black.
3 Enter the data in the Test Data field, separating each data element with a comma.
Remember, if the testcase expects a record, you need to enclose the list of data with the list
constructor operator (the curly braces); otherwise, SilkTest interprets the data as individual
variables, not a record, and will generate a data type mismatch compiler error. 4 Click OK.
SilkTest closes the Testplan Detail dialog closes and enters the testdata statement and data
values in the plan.
22. What is a Mater Plan.
Dividing a testplan into a master plan and subplans
If several engineers in your QA department will be working on a testplan, it makes sense to break
up the plan into a master plan and subplans. This approach allows multi-user access, while at the
same time maintaining a single point of control for the entire project. The master plan contains
only the top few levels of group descriptions, and the subplans contain the remaining levels of
group descriptions and test descriptions. Statements, attributes, symbols, and test data defined in
the master plan are accessible within each of the subplans. Subplans are specified with an
include statement. To expand the subplan files so that they are visible within the master plan,
double-click in the left margin next to the include statement. Once a subplan is expanded inline,
the subplan statement changes from red (the default color for statements) to magenta, indicating
that the line is now read-only and that the subplan is expanded inline. At the end of the expanded
subplan is the marker, which indicates the end of the subplan file.
23. How to create a Sub Plan
Creating a subplan
You create a subplan in the same way you create any testplan: by opening a new testplan file
and entering the group descriptions, test descriptions, and the testplan editor statements that
comprise the subplan, either manually or using the Testplan Detail dialog.
24. What is a Lock
About locks
When first opened, a master plan and its related subplans are read-only. This allows many users
to open, read, run, and generate reports on the plan. When you need to actually edit the master
plan or a subplan, you must first acquire a lock, which prevents others from making changes that
conflict with your changes.
25. What is the importance of options menu
Options menu
The Options menu contains the following commands:
General opens the General Options dialog, which you use to set such aspect s of general system
behavior as the editor and your workspace.
Editor Font opens the Editor Font dialog, which allows you to select a screen font in the family,
size, and style of your choice.
Editor Colors opens the Editor Colors dialog, which you use to set the screen colors for various
elements of 4Test code, results information, and the testplan (if available).
Runtime opens the Runtime Options dialog, which allows you to specify settings that SilkTest
uses when it runs a script.
Agent opens the Agent Options dialog, which allows you to set global options for how the SilkTest
Agent software interacts with the application under test.
Extensions opens the Extensions dialog, which you use to enable extensions and fault trapping
for applications under test on your host machine.
Recorder opens the Recorder Options dialog, which allows you to specify settings that SilkTest
uses when recording.
SilkPerformer Recorder opens the SilkPerformer Recorder Options dialog which you use to set
recording options for SilkTest's SilkPerformer Recorder.
Class Map opens the Class Map dialog, which you use to map custom classes to standard
classes supported by SilkTest.
Property Sets opens the Property Sets dialog, which allows you to create, modify, combine, and
delete property sets, which are used to verify properties in testcases.
Source Control is available if you have a software control (version control) application installed.
Displays cascading menu that allows you to manage your SilkTest test files with your installed
software control application. This is not available with SilkTest International.
Test Manager URLs opens the SilkCentral URLs dialog, which you can use to change the "home
page" address (URL) for the Issue Manager and Test Manager consoles that are displayed in
embedded browser windows in SilkTest.
Open Options Set opens the Open Options Set dialog, a standard file-opening dialog that you can
use to load the set of custom Agent, runtime, and class map options and Library Browser Help
files that you want to be in effect for the current suite, script, or testplan.
Save New Options Set opens the Save Options Set As dialog, which you use to save the current
set of Agent, runtime, and class map options and Library Browser Help files. Close Options Set
deactivates the current options set. This command is available only when a set of custom Agent,
runtime, and class map options is in effect. The file name disappears from the title bar. The
default options are now in effect.
n option-file-name displays a list of from 1 to n file names. Each is a custom options file that you
have loaded during the current work session. File names are prefaced by an integer, n, where the
last-loaded options file is listed first. You can click on a file name to have a new set of options in
effect. Alternatively, you can select a file name by its number; for example, to load the options in
the second file in the list, press Alt+O+2.
26. What is the importance of Results Menu
Select displays the Select Results dialog, which allows you to chose which set of results to
display. You can also use this dialog to add a comment to individual results sets. This dialog is
available only when the active window is a results window. Move to description of Select Results
dialog: By default, SilkTest saves the results of five executions per script, suite, or testplan. To
change the default number of results saved, edit the History Size option in the Runtime Options
dialog, available by clicking Options/Runtime.
Merge displays the Merge Results dialog, which you use to combine the active results file with the
results file of your choice. This dialog is available only when the active window is the testplan
editor results window. For more information, see Merging testplan
Delete displays the Delete Results dialog. When you select a set of results and click OK, SilkTest
deletes it. This dialog is available only when the active window is a results window.
Extract displays the Extract Results dialog, which allows you to place selected information from a
results file in ASCII format into a new editor window or a file or send the information to a printer.
This dialog is available only when the active window is a results window.
Export displays the Export Results dialog, which you can use to export your results to a
structured file that is suitable for further processing by an application such as a spreadsheet. This
dialog is availlable only when the active window is a results window.
Send to Issue Manager displays the Send Results dialog, which you can use to send your results
directly to Issue Manager, the Segue product that you can use to manage your application’s bug
reports, enhancement requests, and documentation issues. This dialog is available only when the
active window is a results window. For more information, see sending results to Issue Manager.
Convert to Plan displays the Convert Results to Plan dialog, which allows you to transform a
results file into a testplan. This dialog is available only when the active window is a results
window and you have run a script, a suite, or a single testcase from a script.
Compact removes unused space in a results file, thereby reducing the file size. This command is
available only when the active window is a results window for a testplan. Show Summary displays
the results summary for the current suite, testplan, script, or testcase, including the start and
elapsed time, and error totals. This command is available only when the active window is a
results window. By default, a summary is shown for the script.
Hide Summary hides the display of results summary of the current suite, script, testplan, or
testcase. To have the summary hidden by default, see see Overall results summary.
This dialog is available only when the active window is a results window.
View Options displays the View Options dialog that lets you specify which information you want
displayed in the results window and how you want the information sorted.
Goto Source displays a script file associated with the current results file, if it is closed, and makes
it the active window. If the cursor was positioned at an error message in the results file, SilkTest
positions the cursor at the error line in the script. If the cursor was positioned at the results for a
particular testcase, SilkTest positions the cursor at the beginning of the testcase in the script file.
This dialog is available only when the active window is a results window.
View Differences opens the Difference Viewer when you click on the icon. This command is
available only when the active window is a results window, and the current line of the results file
displays a box icon preceding an error message. For more information, see Finding application
logic errors.
Mark Failures in Plan marks all testcases in the testplan that generated errors during the last plan
execution and makes the testplan the active window. A black stripe in the margin denotes the
marked testcases. Mark Failures in Plan is useful if you want to fix errors and rerun only failed
tests. This dialog is available only when the active window is a the testplan editor results window.
Update Expected Value replaces the expected value in the testcase with the actual value when
an error message is selected. This command is available only when the active window is a results
window. This works for certain error messages, namely those that contain a box icon and are
neither bitmap nor table verification errors. This command updates data within a testcase, not
data passed in from the testplan. It also makes the associated script file active.
Pass/Fail Report displays the Results Pass/Fail Report dialog, which generates an onscreen
report on the number and percentage of tests that have passed. This dialog is available only
when a results file produced by running a testplan is the active window.
Compare Two Results opens the Compare Two Results... which lets you to see results that have
changed from a previous run of the testplan. This command is available only when the active
window is a results window for a testplan.
Next Result Difference locates the next difference between two results files. You use this
command after you click Results/Compare Two Results. This command is available only when a
results file produced by running a testplan is the active window.
Next Error Difference locates the next difference between two results files that is due to the
pass/fail state of a test changing (skipping over differences resulting from the addition or removal
of tests). You use this command after you click Results/Compare Two Results. This command is
available only when a results file produced by running a testplan is the active window. For more
information, see Comparing different runs of a testplan.
27. What is the importance of Record Menu
Record menu
The Record menu contains the following commands.
Window Declarations opens the Record Windows Declarations dialog. Use this dialog to record
descriptions, called window declarations, of the GUI objects in your application and insert them
into a declarations file, called an include file (*.inc).
Application State opens the Record Application State dialog which you use to define an
application state routine that SilkTest runs before it executes your testcase.
Testcase opens the Record Testcase dialog which you use to record an entire testcase,
specifying the application state of your choice and including verification statements. Method
opens the Record Method dialog which you use to record a method for a class or window
Actions opens the Record Actions dialog where you record actions you perform to test an
Class opens the Record Class dialog where you record a new Visual Basic, Active X, or Java
class declaration.
Window Identifiers opens the Record Window Identifiers dialog which you use to record a fully
qualified GUI object name.
Window Locations opens the Record Window Locations dialog which you use to record the x, y
locations of a graphical control, such as a toolbar.
SilkPerformer Script opens the Record SilkPerformer Script dialog which you use to record a
SilkPerformer script from SilkTest.
28. What is the importance of Run Menu
Run menu
The Run menu contains the following commands.
Compile compiles the testplan, suite, or script and all dependent files (such as include files), if
they have changed since they were last compiled.
Compile all compiles the script or suite and all dependent include files, even if they have not
changed since they were last compiled. If the Save object files during compilation checkbox is
enabled on the Runtime Options dialog, then Compile All will create object files (*.o).
Note If the Save object files during compilation checkbox is not enabled, SilkTest does not create
object files (*.o) when you select Run/Compile all. In order to force SilkTest to create an object file
without enabling the Save object files during compilation checkbox, you must modify the source
file and compile or save it. (Compiling saves modified files, and saving saves source, object, and
backup files.)
Run compiles and runs the 4Test script, suite, or testplan in the active window.
Run All Tests executes all the tests in the testplan, first expanding any subplans. This command
is available only for the testplan editor.
Run Marked Tests executes only the marked tests in the testplan, first expanding any subplans.
This command is available only for the testplan editor.
Debug reads the script in the active window into a debugging window and enters debugging
mode. This is available only when the file in the active window is a script.
Application State opens the Run Application dialog where you run or debug an application state
defined in your test frame file or the active script file.
Testcase opens the Run Testcase dialog where you can select a testcase to run or debug.
Show Status hides or shows the Runtime Status dialog when running a script, suite, testcase, or
testplan on a target machine that is not the host machine.
Abort terminates the script, suite, testcase, or testplan that is currently executing. This command
is available only when a program is being run or debugged on a target machine other than the
host machine.
29. What is the Importance of Debug Menu
Debug menu
The Debug menu contains the following commands, all of which are available only in
debugging mode.
Abort terminates execution of the script you are debugging. Abort appears when you have
executed scripts on a target machine.
Exit quits debugging mode.
Finish Function executes the script until the current function returns.
Reset frees memory and all variables, and clears the call stack of the script you are debugging.
Run and Debug/Continue runs the script in the debugging window until the first breakpoint, if any,
is reached. Execution stops just before the line with the breakpoint.
Run to Cursor sets a temporary breakpoint (indicated by a hollow red circle in the margin) on the
line containing the cursor. SilkTest immediately runs the script, stopping at the current line. The
breakpoint is cleared after it is hit.
Step Into is available only after using Debug/Run and execution has stopped at a breakpoint.
Executes the current line of 4Test code in the active script or in a file called by the active script. If
the current line has a breakpoint, SilkTest executes the line. If the current line contains a function
call, control passes into the function; SilkTest stops at the first statement. Step Over is available
only after using Debug/Run and execution has stopped at a breakpoint. Executes the current line
of 4Test code in the active script or in a file called by the active script, without stepping into any
functions called by the current line. Control stops at the next statement.
30. What is Data Driven Testing
Working with data driven testcases
This information will be helpful to know when you are working with data driven testcases.
· When you are working with a data driven testcase, the 4Test Editor contains additional menu
selections and toolbars for you to use.
· SilkTest can data drive only one testcase at a time.
· You cannot duplicate testcase names. Data driven testcases in the same script must have
unique names.
· The Classic 4Test editor is not available with data driven testcases (in .g.t files).
· You cannot create data driven testcases from testcases in .inc files; you can only create data
driven testcases from testcases in .t or .g.t files. However, you can open a project, add the *.inc,
select the testcase from the testcase folder of the project, and then select data drive. · When you
data drive a [use '

No comments: