Using SilkTest for Test Automation

Dos & Donts

Abstract:
Borland SilkTest is one of the most popular tools in software test automation. SilkTest uses a scripting
language called 4Test, so using the tool beyond simple recording requires programming skill and
experience, especially when designing scripts that are efficient and easy to maintain for testing
enterprise applications, which often run on multiple platforms.
In this white paper, well present a general framework when using SilkTest to do automation testing and
three valuable tips developed by XBOSoft, plus examples, for writing high quality SilkTest scripts.
Introduction to SilkTest 4Test Scripting Language
SilkTests 4test scripting language is an object-oriented language. Scripts are organized into several
types of files, including .t files, .inc files, .s files, .pln files, .vtp files, etc. Each of these files has its own
function. For instance, .t files are the basic files required by SilkTest to create and run test cases
while .inc files are include files where a tester can define application objects and write functions for the
required business scenarios. A suite of scripts is contained in an .s file which enables running a group
of scripts sequentially. Test plans are contained in a .pln file.
Generally, the basic workflow of SilkTest automation testing is: Plan Capture Create Run Report
Track.
1. Plan ensures all parties are on the same page regarding objectives and the applications
functionality and includes the overall design and structure of a set of scripts.
2. Capture means setting up the testing environment to capture the application under test. This
includes getting the GUI Identifier for each related part of the application, designing utility
functions, and constants and variables which support the scripts.
3. Create includes developing the specific test cases that address the objective of the test plan and
verify the functionality of an applications objects and features. The end objective is to find defects,
so its important that the test cases automatically verify functionality and provide descriptive error
logging. Verification ensures that the results match the expected, and error logging can help
testers figure out error reason and detect bugs.
4. Run means executing one or more test cases manually, a suite file, or the test plan. To execute
many test cases smoothly, an application state recovery system needs to be set up. Before each
test case runs, a check is needed to ensure the application state is correct based on
preconditions for the test case. After the test case runs the application state can be restored to
match the other scripts that execute afterwards. This way, when a test case fails, it returns to the
precondition (base) state automatically, and will not affect other test cases execution.
5. Reports are stored by SilkTest in a .res file. Options for the related results can be changed in
Runtime settings, such as the Directory/File and History size. A reporting option to consider for
managing, monitoring and analyzing convenience is saving the results report in a separate DB
that then feeds into a customized report.
www.xbosoft.com

Page 1 of 9

Contact Us at info@xbosoft.com

6. Track connects defects with test cases so that the user can go back and do regression testing to
ensure that defects are fixed.
Dos and Donts
A practical example: The discussion below addresses important dos and donts when using .t and .inc
files in SilkTest scripting. These are described as Problem #1, Problem #2 and Problem #3 in a simple
test case that verifies copy and paste functions in Microsoft Excel 2003.
This sample test case consists of the following steps:
1. Open Excel,
2. Select cell (A, 4) and enter a number,
3. Select the cell again and copy it,
4. Select cell (A, 5) and paste the content from cell (A, 4),
5. Do necessary verifications,
6. Close Excel.
Problem 1: What kind of test scripts gives a tester enough information to find bugs?
According to the test case, the test script should open Excel as the first step. To do this, a tester will
typically create an .inc file for the necessary window declarations of Excel and a function for opening
Excel, named as Invoke() with the file name frame.inc.
The major window declarations and Invoke() are included in the following code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14

window MainWin MSExcel

{
tag "[DialogBox]Microsoft Excel - Book1"
const sDir = "C:\Program Files\Microsoft Office\OFFICE11"
const sCmdLine = "C:\Program Files\Microsoft
Office\OFFICE11\EXCEL.EXE"
// Functions
void Invoke ( )
{
MainWin:: Invoke ( )
MSExcel.SetActive( )
MSExcel.TypeKeys("<Ctrl-F1>")
Sleep(1)
MSExcel.Maximize( )
}
}

Second, a .t file would be created and named verification.t, which includes a Main() function and a test
case to invoke Excel:

www.xbosoft.com

Page 2 of 9

Contact Us at info@xbosoft.com

1
2
3
4
5
6
7
8

Main ( )
{
CellVerification ( )
}
testcase CellVerification ( )
{
MSExcel.Invoke ( )
}

When these test scripts are run to open Excel, however, the function Invoke() does not provide enough
verification information.
Recommendation 1: Enable scripts to provide as much information as possible. Dont let scripts
pass without this!
The function Invoke()is not enough because the way it is written does not provide any logging
information nor consider other possible situations. Useful logging information includes what the function
does, especially the pre-condition and post-condition of the function. One possible situation that needs
to be considered is if Excel is already open and enabling Invoke() to handle this.
Considering all above, this can be addressed by modifying Invoke () as shown below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Boolean Invoke ( )
{
Print ("Invoking Excel starts...")
If ! (MSExcel.Exists ())
{
MainWin:: Invoke ( )
}
else
{
If ! MSExcel.Exists(5)
{
LogError(Excel cannot be invoked)
Return false
}
MSExcel.SetActive()
MSExcel.TypeKeys("<Ctrl-F1>")
Sleep(1)
MSExcel.Maximize()
Print ("Invoking Excel passed...")
Return true
}
}

Note the following changes:

Two Print() functions, one LogError() function and two if() statements have been added.

The first print function (line 2) points to where the pre-condition can be verified and the second
print function points (line 18) to where the post-condition can be verified. If this function includes
more complicated logic and parameters, these two points are the right location to include more

www.xbosoft.com

Page 3 of 9

Contact Us at info@xbosoft.com

thorough verifications of pre and post-conditions. They also improve the clarity of test flow and
help testers analyze the results.

If Excel already exists on the desktop, the script will jump off the first if statement (line 3) and will
not invoke it again. So we dont need to close Excel every time before execute the scripts.

The second if statement (line 9) prints an error when Excel invoke fails.

The function type of Invoke()is changed to Boolean, This is a better way when calling this
function rather than a void function because it can return a Boolean value for future use after its
execution.

Problem 2: How to best use .inc files and make .t files easy to maintain?
In this test case, the first step was to invoke Excel. The subsequent steps examine the copy and paste
functions of Excel. In steps 2, 3, and 4 a cell must be accessed and selected. This can be achieved with
the function, GotoCell. After this, scripts need to be written to realize the following: type a number to a
cell, copy data from a cell and paste data to another cell. All three of these steps depend on the function
of GotoCell() so it should be created as a public function where the other three can invoke it.
This presents a problem: where should these functions be placed, in a .t file or an .inc file?
Recommendation 2: Keep scripts readable and maintainable
All the complicated test logic should be encapsulated in the .inc file, while the .t file follows the same
structure of the test case. Script writing is confined by testing requirements and programming demands,
so it is important to keep the test scripts succinct and data flow clear. .t files need to be kept simple,
while the bulk of the functions should be placed in the .inc file. The .t file executes test cases by invoking
functions from corresponding .inc files. For the example Excel test case, we are going to add one
GotoCell()function below Invoke(), and other three functions which contain GotoCell().
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Invoke ( )

GotoCell (string stringOfCell)

{

}
TypeDatatoCell (string stringOfCell, string stringOfNum)
{
This.GotoCell(stringOfCell)

}
CopeDatafromCell (string stringOfCell)
{
This.GotoCell(stringOfCell)

}
PasteDatatoCell (string stringOfCell)
{
This.GotoCell(stringOfCell)

www.xbosoft.com

Page 4 of 9

Contact Us at info@xbosoft.com

To finish, the CellVerification() test case in the .t file only needs to call the three functions for the
last three steps:
1
2
3
4
5
6
7
8
9
10
11
12
13
14

Main ( )
{
CellVerification ( )
}
testcase CellVerification ( )
{
MSExcel.Invoke ( )
MSExcel.TypeDatatoCell ("$A$4", "1024")
MSExcel.CopeDatafromCell ("$A$4")
MSExcel.PasteDatatoCell ("$A$5")
// Verifications

As can be seen from the above scripts, all the complicated test logic is encapsulated in the .inc file, while
the .t file follows the same structure of the designed test case. This makes the script much more
readable and maintainable.
SilkTests inc files are very powerful. You can have .inc files depend on other .inc files, so that you can
architect your test logic into a hierarchical structure. The below example shows the 3 functions in
AdvanceFunctions.inc call GotoCell()function in BasicFunctions.inc by using BasicFunctions.inc
keywords.
1
2
3
4
5
6
7

// BasicFunctions.inc
Invoke ( )

GotoCell (string stringOfCell)

{

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// AdvanceFunctions.inc
use BasicFunctions.inc
TypeDatatoCell (string stringOfCell, string stringOfNum)
{
GotoCell(stringOfCell)

}
CopeDatafromCell (string stringOfCell)
{
GotoCell(stringOfCell)

}
PasteDatatoCell (string stringOfCell)
{

www.xbosoft.com

Page 5 of 9

Contact Us at info@xbosoft.com

15
16
17

GotoCell(stringOfCell)

Problem 3: What if a test script needs to run on many platforms with different sets of data?
Problems #1 and #2 covered the conversion of a manual test case into an automation script. In some
cases, however, a script may have to be run on multiple platforms against different sets of data. Also, the
script may need to have the capability of testing different versions of an application. This raises the
question of how to efficiently run a test script across multiple platforms with different sets of data?
Recommendation 3: Write data-driven test cases, do not write test cases without considering
changeable data input
A test script should read data from an external storage site, for example, from a file or database, rather
than use values hard-coded in the script. Such a separation between controls and data makes test
scripts logically simpler, easier to maintain, and more flexible. A script containing several sets of hardcoded values can be difficult to modify. For instance, if you need more input data, you will have to modify
the script code. In the Excel 2003 example, if we change to testing Excel 2007, the script must import a
method to dynamically load variables related to the version of Excel. This can be done by storing real
values of these variables in a file, for example, a .txt or a .ini file. A function can be written in the script to
read those values during run-time and evaluate associated variables.
First, a few related parts in frame.inc and verification.t should be changed. You can see the
highlights parts in the code below:
1
2
3
4
5
6
7

//frame.inc
window MainWin MSExcel
{
tag "[DialogBox]Microsoft Excel - Book1"
const sDir = "C:\Program Files\Microsoft Office\OFFICE11"
const sCmdLine = "C:\Program Files\Microsoft
Office\OFFICE11\EXCEL.EXE"
// Functions
}

1
2
3
4
5
6
7
8
9
10
11
12

// verification.t
Main ( )
{
CellVerification ( )
}
testcase
{
string
string
string

www.xbosoft.com

CellVerification ( )
numForType
cellLocationCopy = stringForCellLocationCopy
cellLocationPaset = stringForCellLocationPaste

Page 6 of 9

Contact Us at info@xbosoft.com

13
14
15
16
17

MSExcel.Invoke ( )
MSExcel.TypeDatatoCell (stringForCellLocationCopy, numForType)
MSExcel.CopeDatafromCell (stringForCellLocationCopy)
MSExcel.PasteDatatoCell (stringForCellLocationPaste)
}

An .inc file should be added to evaluate variables. This file is named string.inc. It includes functions to
retrieve values from string.txt file.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// string.inc
// Strings
// Number
string numForType = GetString ("numForType")
// Tags
string TAG_Excel2007 = GetTag ("TAG_FOR_EXCEL")
// Const strings
string
stringForCellCopy
=
GetString
("stringForCellLocationCopy")
string
stringForCellPaste
=
GetString
("stringForCellLocationPaste")
string stringForDir = GetString ("stringForDir")
string stringForCmdLine = GetString("stringForCmdLine")
// Functions
private string GetTag (string stringForTag)
{
return GetValue (stringForTag)
}
private string Gesturing (string stringForConst)
{
return GetValue (stringForConst)
}
private string GetValue (string stringForRealValue)
{
list of string ls
integer i, lsCount
ListRead (ls, "C:\String.txt")
lsCount = ListCount (ls)
for i=1 to lsCount
if (MatchStr ("{stringForRealValue}=*", ls[i]))
return GetField (ls[i], "=", 2)
LogError
("The
'String.txt'
does

www.xbosoft.com

Page 7 of 9

not

have

Contact Us at info@xbosoft.com

{stringForRealValue}!")
return " "

1
2
3
4
5
6
7
8
9
10

//string.txt
[Tag]
TAG_FOR_EXCEL=Microsoft Excel*
[Const strings]
numForType=1024
stringForCellLocationCopy=A4
stringForCellLocationPaste=A5
stringForDir=C:\Program Files\Microsoft Office\OFFICE11
stringForCmdLine=
C:\Program
Files\Microsoft
Office\OFFICE11\EXCEL.EXE

Last step, with the functions support in string.inc, we update original frame.inc and
verification.t as seen in the code below. Notice the usage of use keywords in the very
beginning of each file.
1
2
3
4
5
6
7

//frame.inc
Use string.inc
window MainWin MSExcel
{
tag TAG_Excel2007
const sDir = stringForDir
const sCmdLine = stringForCmdLine
// Functions
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// verification.t
Use frame.inc
Use string.inc
Main ( )
{
CellVerification ( )
}
testcase CellVerification ( )
{
MSExcel.Invoke ( )
MSExcel.TypeDatatoCell (stringForCellLocationCopy, numForType)
MSExcel.CopeDatafromCell (stringForCellLocationCopy)
MSExcel.PasteDatatoCell (stringForCellLocationPaste)
}

www.xbosoft.com

Page 8 of 9

Contact Us at info@xbosoft.com

The data file, sting.txt, includes all the data values: cell locations and version information. So if you want
to change an input string or the Excel tag is changed, only the data values in sting.txt need to be
modified. This approach is much easier to maintain and keeps test data and test logic separate.
Summary
When writing SilkTest scripts, plan through the entire process and design architecture based on your
application and your objectives. SilkTest uses a scripting language with powerful capabilities but to
take advantage of it, you need to have some basic programming skills to go beyond its simple recording
capabilities. Some basic rules to follow along the way:
1. Insert debugging points in the script just as you would when writing normal code. This will help
you troubleshoot scripts and give you information about the conditions under which a test case
fails.
2. Keep your test scripts succinct and clear. Using function calls and include files to create
components that can be called from other scripts.
3. Separate your data from your test logic. Rather than hard coding data values, use variables and
separate data files to make your scripts more robust and flexible.

www.xbosoft.com

Page 9 of 9

Contact Us at info@xbosoft.com