02:55
jobsindia
The 4Test language
The 4Test language is an object-oriented fourth-generation language (4GL) designed specifically with the needs of the QA professional in mind. 4Test’s powerful features are organized into three basic kinds of functionality:
A robust library of object-oriented classes and methods that specify how a testcase can interact with an application’s GUI objects.
A set of statements, operators, and data types that you use to add structure and logic to a recorded testcase.
A library of built-in functions for performing common support tasks. Note This section provides a high-level look at 4Test.
More on 4test language
Data types and variables
Built-in data types
4Test provides the following built-in data types:
ANYTYPELIST
ARRAY BOOLEAN BROWSERTYPE DATACLASS DATATYPE DATE DATETIME FONTSTYLE GUITYPE HANDLE INTEGER LIST LONG NUMBER REAL SEMAPHORE SET STRING
TABLECOL TABLEROW TIME WINDOW
C data types for DLL functions
In addition to the 4Test data types, the following C data types are supported for use in calling functions in DLLs.
char int short long unsigned char unsigned int unsigned short unsigned
long float double
The first two columns above show data types that correspond to the 4Test INTEGER data type. The third column corresponds to the REAL data type.
User-defined types
You can also create new data types, including enumerated types and records.
For example:
type FILE is LIST OF STRING type COLOR is enum red green
Built-in functions
4Test contains a function library to handle the most common programming tasks. The following table summarizes the functions by category:
Application state
Array manipulation
Char/string conversion
Data type manipulation
Distributed processing
Exception handling
File manipulation
List manipulation
Numeric operations
Random values
Results file operations
Script information
Semaphore operations
Set manipulation
Startup
String manipulation
System calls
Timers, time/date info
Window information
Sample script for 4Test statements
Consider an example of testing a web based application.
testcasesample()
Browser.Loadpage("www.yahoo.com") // Loads the yahoo homepage as the default page
if Yahoo.Exists() // checking for the existence of the homepage
print("Yahoo window exists") // confirming that the window exists
Yahoo.objYahoo.Loginname.SetText("username") // Setting the login name in the corresponding textfield
Yahoo.objYahoo.Password.SetText("password")
Yahoo.objYahoo.Submit.Click()
if !YahooMail.Exists()
LogError("Cannot login - test fail") // printing the error message
print("Yahoo mail logged in")
YahooMail.objYahooMail.CheckMessage.Click() // checking the mail
In the above example, the 4Test statements, framename used, its objects,properties & methods are clearly defined. The Line 1 is for loading the the homepage of the yahoo site. In the next line, the exists is a method that belongs to the window class 'Yahoo'. In line 3, the SetText is the method belong to the class textfield, HtmlTextField Loginname. The concepts of the classes are described in the 'How to write scripts' portion of the index page.
Back
SilkTest:
SilkTest is a tool specifically designed for doing regression1 and functionality testing. It is developed by Segue Software Inc. SilkTest is the industry's leading functional testing product for e-business applications, whether Window based, Web, Java, or traditional client/server-based. SilkTest also offers test planning and management, direct database access and validation, the flexible and robust 4Test scripting language, a built-in recovery system for unattended testing, and the ability to test across multiple platforms, browsers, and technologies. The version of SilkTest which is being used is the 5.0.3.
You have two ways to create automated tests using silktest:
Use the Record Testcase command to record actions and verification steps as you navigate through the application.
Write the testcase manually using the Visual 4Test scripting language.
1. Record testcase 2
The Record/Testcase command is used to record actions and verification steps as you navigate through the application. Tests are recorded in an object-oriented language called Visual 4Test. The recorded test reads like a logical trace of all of the steps that were completed by the user. The SilkTest point-and-click verification system allows you to record the verification step by selecting from a list of properties that are appropriate for the type of object being tested. For example, you can verify the text that is stored in a text field.
2. Write the testcase manually
We can write tests that are capable of accomplishing many variations on a test. The key here is re-use. A testcase can be designed to take parameters including input data and expected results. This “data-driven” testcase is really an instance of a class of testcases that performs certain steps to drive and verify the application-under-test. Each instance varies by the data that it carries. Since far fewer tests are written with this approach, changes in the GUI will result in reduced effort in updating tests. A data-driven test design also allows for the externalization of testcase data and makes it possible to divide the responsibilities for developing testing requirements and for developing test automation. For example, it may be that a group of domain experts create the Testplan Detail while another group of test engineers develop tests to satisfy those requirements.
1 A set of baseline tests that are run against each new build of an application to determine if the current build has regressed in quality from the previous one.
2 In a script file3 , an automated testcase that ideally addresses one test requirement. Specifically, a 4Test function that begins with the testcase keyword and contains a sequence of 4Test statements. It drives an application to the state to be tested, verifies that the application works as expected, and returns the application to its base state.
3 A script file is a file that contains one or more related testcases. A script file has a .t extension, such as find.t.
Other Segue products
The Silk products include
SilkTest for functional and regression testing
SilkPerformer for load and performance simulation
SilkPilot for functional and regression testing CORBA and EJB servers
SilkRadar for automated defect tracking
SilkVision for enterprise application health monitoring
SilkExpress for a scalability and load testing consulting solution
An experiment with the tags
A Tag: is an object’s actual name or index as it appears in the GUI. It is the name by which SilkTest locates and identifies objects in the application. We identify the controls and windows / frames of the application by looking at the identifiers.
An Identifier: Name used in test scripts to refer to an object in the application. Logical, GUI- Independent name. Identifier is mapped to the tag in a window declaration.
For example consider the sample code given below.
[-] window BrowserChild Yahoo
tag "Yahoo - Netscape"
parent Browser
[-] HtmlImage CheckMail //expanded form of the variable
tag "#2"
[-] HtmlText Messenger
tag "Messenger"
[+] HtmlLink PhotoGallery
In the above example, there is a window declaration of the Yahoo home page (only some variables are given above for example). It contains the BrowserChild (window) name followed by its tag value and the parent information. The 'parent Browser' text shows that the window is a main window and not a dialog box. Because only the window name or browser window name contains this keyword in the declaration part. Next comes the three variables. The first variable is of datatype HtmlImage.Here, the identifier name is 'CheckMail' and the tag value of it is '#2'. The user/programmer will write the script using the identifier name and it can be changeable. But the tag value should not be changed since the silktest will identify the objects in the window (or) the window itself by only looking at the tag values. Hence, the tag value should be same as of that when declared.
From the above example, let us change the tag value for the HtmlImage CheckMail. After changing the tag value from '#2' to '#3', the code will look like this. Here no need to change the identifier name.
[-] window BrowserChild Yahoo
tag "Yahoo - Netscape"
parent Browser
[-] HtmlImage CheckMail
tag "#3" // tag changed
[-] HtmlText Messenger
tag "Messenger"
[+] HtmlLink PhotoGallery
It is advisable to use muititags to avoid frequent change in tag values. To select multitag option,
Select the Record -> Window Declarations option from the menu bar.
You will get the Record Window Declarations dialog box waiting on your applicatoin to capture the window and its objects.
In the 'Record Window Declarations' dialog box, select the 'options' button.
You will get another dialog box 'Record window declarations options' .
In that dialog box, chech the 'Record Multiple tags' option and click on the 'OK' button.
Now the silktest will capture the objects as multitags.
A multitag will look like as below.
[-] window BrowserChild Yahoo
[-] multitag "Yahoo - Netscape"
[ ] "#12"
[ ] "$http:??yahoohomepage.jsp"
parent Browser
[-] HtmlImage CheckMail
[-] multitag "Check Mail"
[ ] "#1"
When to change the tag:
Consider a situation that the testing process stops due to some error. We will check for the result file for the kind of error. If the error is something like HtmlLink not found, BrowserCustomClass not found… then it might happen because of the change in tag value. In Silktest, the tag value will get changed rarely. It can be considered as a limitation of the tool.
How to change the tag:
By making some changes in the script, we have to continue the testing process, in order to check for errors. Follow the steps given below, to rectify the error in your code:
Take the error file (result file).
Click on the [+] image in the error statement.
Double click on the error by keeping the cursor in the leftmost end of the error statement (that is indicated in red color)
The control will take you to the statement where you get the error message.
Double click on the object, which gives you the error. For example, if the error is ‘HtmlText not found’, then double click on the variable text, if the error is ‘BrowserCustomClass Not Found’ then click on the Window name.
After double clicking on the object that gives the error, press the Ctrl+Dot(.) buttons simultaneously.
It will take you the file where that object has been declared. Also the cursor will wait in the same line of the object.
Click on the [+] image in the object name.
Check for the tag value.
Then go to menu Window-> Declaration in the silktest, and activate your application manually.
Check for the tag value of the control that gives you the error. Say if you get the error ‘HtmlText Name not found’, then check for the tag value of the text ‘Name’ to that of the value in the previously available identifier.
If the tag value matches, then leave it as it is. The tag values are available in the third column of the ‘Record Window Declaration’ dialog box.
If the tag value doesn’t match, then copy the tag value of the entire window in a file, temporarily. Copy the tag (only) of that particular object and overwrite it on the existing tag of that object. Make sure that you have to copy only the tag value and not the entire line / the identifier name.
Save that file, compile it and run it again. Now the chances of getting the error are minimal.
In silktest, the tag value of the window / objects will get changed rarely. Hence applying these steps is a necessary one in letting the testcase error-free to make your application bug-free.
Application State
An application state is typically used to put an application into the state it should be in at the start of a testcase.
You can define the application state from scratch or base the definition on another application state, which in turn can be based on another application state, and so on. The base state is the lowest level of application state in this chain of inheritance. The application state DefaultBaseState is predefined for your use by SilkTest.
To associate an application state with a testcase, use the appstate keyword when you define the testcase. The second example below associates the application state MyAppState (which is based on MyBaseState) with the testcase MyTestCase.
· By default, SilkTest call the SetAppState function when you enter a testcase, in the DefaultTestCaseEnter function.
The SetAppState function executes the statements defined in the application state and in each of the application states upon which it is based, starting with the statements in the base state and working up to the application state chain.
· By default, SilkTest calls the SetBaseState function when you exit a testcase, in the DefaultTestCaseExit function.
The SetBaseState function executes the statements defined in the lowest level application state only (the base state). For example, suppose a testcase uses the application state AppState3, based on AppState2, based on AppState1. Calling the SetBaseState function executes only the statements in AppState1.
References www.segue.com ,Silkuserguide.pdf ,,SilkTest help
SilkTest - Computer Based Training
Objective: To give hands-on training with silk test for 5 members. A series of classes running for 5 days with
morning session of 2 hrs/day on theory and afternoon session of 2-3 hr. on practical and assignment will be designed to provide in depth knowledge on silk test.
Support Documents: A Handout or Online Training material associated with it. Referral books will be furnished upon request.
Required Skills: Programming logic, HTML Objects, Components of Web Technology, Popular Web Servers and Web Browsers in the Market.
Technical / Equipment requirements: Hardware: 5 Computers with 128 MB memory and 4GB Hard Disk. Software: Windows NT workstation, Netscape Communicator 4.75, Internet Explorer 5.0 installed.
Client - Server testing:
With SilkTest:
• You can test an application that runs on a different machine than SilkTest. • You can test applications running on two or more machines at once. • You can test multiple different applications simultaneously. The database tester provides an additional feature: You can access a server database directly, thereby circumventing the untested database operations of the application under test.
In a client/server environment, SilkTest drives the client application by means of an Agent process running on each application’s machine. The application then drives the server just as it always does. SilkTest is also capable of driving the GUI belonging to a server or of directly driving a server database by running scripts that submit SQL statements to the database. These methods of directly manipulating the server application are intended to support testing in which the client application drives the server.
The kinds of network testing you can perform
Software testing can be categorized according to the various broad testing goals that are the focus of the individual tests. This section describes at a conceptual level the kinds of automated application testing you can perform using SilkTest in a networked environment:
Functional
Configuration
Concurrency
Stress
Load
Performance
Client/server testing configurations:
The processes that participate in a client/server testing scenario are logically associated with three different computers:
1 System A runs SilkTest, which processes test scripts and sends application commands to the Agent.
2 System B runs the client application and the SilkTest Agent, which submits the application commands to the client application.
3 System C runs the server software, which reacts to requests submitted by the client application.
During your initial test development phase, you can reduce your hardware needs by making two (and possibly all) of these systems the same. If you write tests for an application running on the same system as SilkTest, you can implement the tests without consideration of any of the issues of remote testing. You can then expand your testing program incrementally to take your testing into each new phase.
Understanding host and target machines
In a client/server environment, SilkTest typically drives the client application by means of an Agent process running on each application’s machine. The application then drives the server. Alternatively, SilkTest is capable of driving the GUI for a server (if it has one) or of driving a server database directly by running scripts that submit SQL statements to the database.
SilkTest runs on many platforms, but only three different protocols are used. This means that a SilkTest script on one platform can drive the Agent on a target platform, as long as both the host and Agent platforms are running an appropriate protocol for the platform and both are running the same protocol (regardless of the protocols used by the applications under test).
For example, suppose you are running SilkTest under Windows 95 and testing an application that requires TCP/IP communications in order to communicate with a server on a Sun Sparc station. SilkTest’s Windows machine can run NetBIOS for the host and the application’s Windows machine must then run NetBIOS for the Agent as well as TCP/IP for the application under test. Running NetBIOS will have no impact on your TCP/ IP connections but will allow SilkTest to communicate with the Agent.
Alternatively, since the application is already running TCP/IP, you can choose to use TCP/IP for SilkTest and its Agents as well.
To configure a network of computers so that they can run SilkTest and its Agents, you must do the following:
Install (or have already running) networking protocols supported by SilkTest.
Install SilkTest on the host machine and the Agent software on all target machines.
Establish connectability between host and Agents. This may require some setup.
Enable networking on any PC-based target machines; use the Agent window
Enable networking on the host machine. Use the Runtime Options dialog; details vary, depending on your configuration.
Gather the information that your test scripts will need when making explicit connections. For example, you can edit the Agent names into a list definition and have your testplan pass the list variable name as an argument for testcases controlled by that plan. The testcases then pass each Agent name to a Connect or SetUpMachine function and that function makes the explicit host-to-Agent connection.
Parallel processing Template:
You can use this template by doing three edits:
Include the file that contains your window declarations.
Substitute your application’s MainWin name defined in your MainWin window declaration for the template’s “MyMainWin” MainWin name.
Insert the calls to one or more tests, or to the main function, where indicated.
file://sample code
use "myframe.inc"
multitestcase MyParallelTest (LIST of STRING lsMachines) STRING sMachine
// Connect to all machines in parallel:
for each sMachine in lsMachines
spawn
SetUpMachine (sMachine, MyMainWin)
rendezvous
// Set app state of each machine, invoking if necessary:
SetMultiAppStates()
// Run testcases in parallel
for each sMachine in lsMachines
spawn
SetMachine (sMachine)
// Call testcase(s) or call main()
rendezvous
Configuring the settings
In SilkTest, select Option -> Extentions menu from the menu bar.
It will load the Extentions dialog box.
In that dialog box, check the kind of application you are testing.
Say, if you are testing the web based application in the Netscape browser, Enable the Netscape option by checking against it and un-check all the other options.
Click on the OK button.
Now click on the Options -> Runtime option.
Set the 'use path' option to point to the silktest installed folder. Say if the silktest has been installed in your c:\ drive then set the use files = "C:\Program Files\Segue\SilkTest\EXTEND". This is to use the common include files as per the application.
Since we have selected the Extentions, the use file will have the declaration 'extend\netscape.inc' of the include file.
Now the script is ready to open the Netscape browser by default and run the scripts.
From the status bar Go to the Start -> Programs -> SilkTest -> Extention Enabller option, to declare the same set of extentions ( as in step 4) in the 'Extention Enabler' dialog box.
TESTING: The primary reasons to test the applications are to identify the defects and measure the quality of the application.
Different kinds of testing :There are different types of tests that can be executed depending on the objectives of the test engineer.
Error testing :Verify the product’s responses to error conditions. These tests ensure that the responses are meaningful, correct, and may include the display of context-sensitive, error-specific help screens. Reviewing error message lists may help to identify each error which can be generated by a specific screen or module.
Stress testing :Measure the system’s response to large amounts of data. This may include single-users manipulating large sets of data, or multiple machines running the application simultaneously.
White - Box testing :Places the focus on the internal structure of the software. Tests are designed using the code and the functional specification as input.
Black - Box testing :Views the software from the end-user perspective, and is unaware of the underlying code.
Distributed testing :Is concerned about the behavior of the client software as well as the data being stored and manipulated at the server. This may include verification of startup data,
modifications to tables, verification that cascading deletes are correct, and that dependencies between database tables are correct.
Multi - User testing:Includes concurrency tests which verify the interaction of two simultaneous users on two separate machines. For example, if one user locks a record, a second user may receive an error message when attempting to lock the same record. Stress testing verifies the response of the system when a large number of users are connected to the database. Other types of tests verify that a process on one machine is capable of initiating a process on another machine.
SilkTest Features:
Some of the features of silktest are given below.
Easy-to-use interface
Built-in recovery system
The object oriented concept
Record & Play
Multi-kind application testing
Automatic generation of results
Browser & Platform independent
Distributed testing
24x365 unattended testing
Power Testing with the 4Test Language
Centralized Testing of Distributed Applications
Distributed Access to Test Results
Extensive Component Testing
Cross-Platform Java Testing
Testing Across Multiple Browsers and Windows Versions
Support for HTML, XML, JavaScript, Java, ActiveX, Windows controls, and Visual Basic
Single-recording testing for cross-platform Java testing with the SilkBean
Against Over 35 Databases
Link Tester
Validation of Advanced Database Structures and Techniques
Creation of
Test Plan
Test Frame
Test Suite
Integration with other silk products.
SilkTest architecture :
Normal use of an application consists of a person manipulating a keyboard and mouse to initiate application operations. The person is said to be interacting with the GUI (Graphical User Interface). During SilkTest testing, SilkTest interacts with the GUI to submit operations to the application automatically. Thus SilkTest can simulate the actions of a person who is exercising all the capabilities of an application and verifying the results of each operation. The simulated user (SilkTest) is said to be driving the application. The application under test reacts to the simulated user exactly as it would react to a human user. SilkTest consists of two distinct software components that execute in separate processes:
The SilkTest host software
The 4Test Agent software
SilkTest host software
The SilkTest host software is the program you use to develop, edit, compile, run, and debug your 4Test scripts and testplans. This manual refers to the system that runs this program as the host machine or the SilkTest machine.
The Agent
The 4Test Agent is the software process that translates the commands in your 4Test scripts into GUI-specific commands. In other words, it is the Agent that actually drives and monitors the application you are testing. One Agent can run locally on the host machine. In a networked environment, any number of Agents can run on remote machines. This manual refers to the systems that run remote Agents as target machines. In a client/server environment, SilkTest drives the client application by means of an Agent process running on each application’s machine. The application then drives the server just as it always does. SilkTest is also capable of driving the GUI belonging to a server or of directly driving a server database by running scripts that submit SQL statements to the database. These methods of directly manipulating the server application are intended to support testing in which the client application drives the server.
Limitations of SilkTest:
Some of the limitations of SilkTest are given below.
SilkTest may not recognise some objects in a window / page due to some technical reasons.
SilkTest may not recognise some window frames.
The 'tag' value may get changed frequently.
Sometimes it will be difficult to activate some window.
It may be necessary to make some modifications if testing should be shifted to other browser/operating system.
In web based applications, sometimes silktest will take the links as simple text.
System Requirements:
The minimum requirement, a system needs to run the silk test is given below.
Windows NT, Windows 95, 98 or 2000
Pentium 466 Mhz or better processor (application dependent)
32 MB RAM
60MB Hard Disk
· Supported Environments:
Netscape Navigator 4.x
Internet Explorer 4 and 5
ActiveX, Visual Basic 5 and 6
Java JDK 1.3
Swing 1.1
Microsoft Web browser control
The 4Test language is an object-oriented fourth-generation language (4GL) designed specifically with the needs of the QA professional in mind. 4Test’s powerful features are organized into three basic kinds of functionality:
A robust library of object-oriented classes and methods that specify how a testcase can interact with an application’s GUI objects.
A set of statements, operators, and data types that you use to add structure and logic to a recorded testcase.
A library of built-in functions for performing common support tasks. Note This section provides a high-level look at 4Test.
More on 4test language
Data types and variables
Built-in data types
4Test provides the following built-in data types:
ANYTYPELIST
ARRAY BOOLEAN BROWSERTYPE DATACLASS DATATYPE DATE DATETIME FONTSTYLE GUITYPE HANDLE INTEGER LIST LONG NUMBER REAL SEMAPHORE SET STRING
TABLECOL TABLEROW TIME WINDOW
C data types for DLL functions
In addition to the 4Test data types, the following C data types are supported for use in calling functions in DLLs.
char int short long unsigned char unsigned int unsigned short unsigned
long float double
The first two columns above show data types that correspond to the 4Test INTEGER data type. The third column corresponds to the REAL data type.
User-defined types
You can also create new data types, including enumerated types and records.
For example:
type FILE is LIST OF STRING type COLOR is enum red green
Built-in functions
4Test contains a function library to handle the most common programming tasks. The following table summarizes the functions by category:
Application state
Array manipulation
Char/string conversion
Data type manipulation
Distributed processing
Exception handling
File manipulation
List manipulation
Numeric operations
Random values
Results file operations
Script information
Semaphore operations
Set manipulation
Startup
String manipulation
System calls
Timers, time/date info
Window information
Sample script for 4Test statements
Consider an example of testing a web based application.
testcasesample()
Browser.Loadpage("www.yahoo.com") // Loads the yahoo homepage as the default page
if Yahoo.Exists() // checking for the existence of the homepage
print("Yahoo window exists") // confirming that the window exists
Yahoo.objYahoo.Loginname.SetText("username") // Setting the login name in the corresponding textfield
Yahoo.objYahoo.Password.SetText("password")
Yahoo.objYahoo.Submit.Click()
if !YahooMail.Exists()
LogError("Cannot login - test fail") // printing the error message
print("Yahoo mail logged in")
YahooMail.objYahooMail.CheckMessage.Click() // checking the mail
In the above example, the 4Test statements, framename used, its objects,properties & methods are clearly defined. The Line 1 is for loading the the homepage of the yahoo site. In the next line, the exists is a method that belongs to the window class 'Yahoo'. In line 3, the SetText is the method belong to the class textfield, HtmlTextField Loginname. The concepts of the classes are described in the 'How to write scripts' portion of the index page.
Back
SilkTest:
SilkTest is a tool specifically designed for doing regression1 and functionality testing. It is developed by Segue Software Inc. SilkTest is the industry's leading functional testing product for e-business applications, whether Window based, Web, Java, or traditional client/server-based. SilkTest also offers test planning and management, direct database access and validation, the flexible and robust 4Test scripting language, a built-in recovery system for unattended testing, and the ability to test across multiple platforms, browsers, and technologies. The version of SilkTest which is being used is the 5.0.3.
You have two ways to create automated tests using silktest:
Use the Record Testcase command to record actions and verification steps as you navigate through the application.
Write the testcase manually using the Visual 4Test scripting language.
1. Record testcase 2
The Record/Testcase command is used to record actions and verification steps as you navigate through the application. Tests are recorded in an object-oriented language called Visual 4Test. The recorded test reads like a logical trace of all of the steps that were completed by the user. The SilkTest point-and-click verification system allows you to record the verification step by selecting from a list of properties that are appropriate for the type of object being tested. For example, you can verify the text that is stored in a text field.
2. Write the testcase manually
We can write tests that are capable of accomplishing many variations on a test. The key here is re-use. A testcase can be designed to take parameters including input data and expected results. This “data-driven” testcase is really an instance of a class of testcases that performs certain steps to drive and verify the application-under-test. Each instance varies by the data that it carries. Since far fewer tests are written with this approach, changes in the GUI will result in reduced effort in updating tests. A data-driven test design also allows for the externalization of testcase data and makes it possible to divide the responsibilities for developing testing requirements and for developing test automation. For example, it may be that a group of domain experts create the Testplan Detail while another group of test engineers develop tests to satisfy those requirements.
1 A set of baseline tests that are run against each new build of an application to determine if the current build has regressed in quality from the previous one.
2 In a script file3 , an automated testcase that ideally addresses one test requirement. Specifically, a 4Test function that begins with the testcase keyword and contains a sequence of 4Test statements. It drives an application to the state to be tested, verifies that the application works as expected, and returns the application to its base state.
3 A script file is a file that contains one or more related testcases. A script file has a .t extension, such as find.t.
Other Segue products
The Silk products include
SilkTest for functional and regression testing
SilkPerformer for load and performance simulation
SilkPilot for functional and regression testing CORBA and EJB servers
SilkRadar for automated defect tracking
SilkVision for enterprise application health monitoring
SilkExpress for a scalability and load testing consulting solution
An experiment with the tags
A Tag: is an object’s actual name or index as it appears in the GUI. It is the name by which SilkTest locates and identifies objects in the application. We identify the controls and windows / frames of the application by looking at the identifiers.
An Identifier: Name used in test scripts to refer to an object in the application. Logical, GUI- Independent name. Identifier is mapped to the tag in a window declaration.
For example consider the sample code given below.
[-] window BrowserChild Yahoo
tag "Yahoo - Netscape"
parent Browser
[-] HtmlImage CheckMail //expanded form of the variable
tag "#2"
[-] HtmlText Messenger
tag "Messenger"
[+] HtmlLink PhotoGallery
In the above example, there is a window declaration of the Yahoo home page (only some variables are given above for example). It contains the BrowserChild (window) name followed by its tag value and the parent information. The 'parent Browser' text shows that the window is a main window and not a dialog box. Because only the window name or browser window name contains this keyword in the declaration part. Next comes the three variables. The first variable is of datatype HtmlImage.Here, the identifier name is 'CheckMail' and the tag value of it is '#2'. The user/programmer will write the script using the identifier name and it can be changeable. But the tag value should not be changed since the silktest will identify the objects in the window (or) the window itself by only looking at the tag values. Hence, the tag value should be same as of that when declared.
From the above example, let us change the tag value for the HtmlImage CheckMail. After changing the tag value from '#2' to '#3', the code will look like this. Here no need to change the identifier name.
[-] window BrowserChild Yahoo
tag "Yahoo - Netscape"
parent Browser
[-] HtmlImage CheckMail
tag "#3" // tag changed
[-] HtmlText Messenger
tag "Messenger"
[+] HtmlLink PhotoGallery
It is advisable to use muititags to avoid frequent change in tag values. To select multitag option,
Select the Record -> Window Declarations option from the menu bar.
You will get the Record Window Declarations dialog box waiting on your applicatoin to capture the window and its objects.
In the 'Record Window Declarations' dialog box, select the 'options' button.
You will get another dialog box 'Record window declarations options' .
In that dialog box, chech the 'Record Multiple tags' option and click on the 'OK' button.
Now the silktest will capture the objects as multitags.
A multitag will look like as below.
[-] window BrowserChild Yahoo
[-] multitag "Yahoo - Netscape"
[ ] "#12"
[ ] "$http:??yahoohomepage.jsp"
parent Browser
[-] HtmlImage CheckMail
[-] multitag "Check Mail"
[ ] "#1"
When to change the tag:
Consider a situation that the testing process stops due to some error. We will check for the result file for the kind of error. If the error is something like HtmlLink not found, BrowserCustomClass not found… then it might happen because of the change in tag value. In Silktest, the tag value will get changed rarely. It can be considered as a limitation of the tool.
How to change the tag:
By making some changes in the script, we have to continue the testing process, in order to check for errors. Follow the steps given below, to rectify the error in your code:
Take the error file (result file).
Click on the [+] image in the error statement.
Double click on the error by keeping the cursor in the leftmost end of the error statement (that is indicated in red color)
The control will take you to the statement where you get the error message.
Double click on the object, which gives you the error. For example, if the error is ‘HtmlText not found’, then double click on the variable text, if the error is ‘BrowserCustomClass Not Found’ then click on the Window name.
After double clicking on the object that gives the error, press the Ctrl+Dot(.) buttons simultaneously.
It will take you the file where that object has been declared. Also the cursor will wait in the same line of the object.
Click on the [+] image in the object name.
Check for the tag value.
Then go to menu Window-> Declaration in the silktest, and activate your application manually.
Check for the tag value of the control that gives you the error. Say if you get the error ‘HtmlText Name not found’, then check for the tag value of the text ‘Name’ to that of the value in the previously available identifier.
If the tag value matches, then leave it as it is. The tag values are available in the third column of the ‘Record Window Declaration’ dialog box.
If the tag value doesn’t match, then copy the tag value of the entire window in a file, temporarily. Copy the tag (only) of that particular object and overwrite it on the existing tag of that object. Make sure that you have to copy only the tag value and not the entire line / the identifier name.
Save that file, compile it and run it again. Now the chances of getting the error are minimal.
In silktest, the tag value of the window / objects will get changed rarely. Hence applying these steps is a necessary one in letting the testcase error-free to make your application bug-free.
Application State
An application state is typically used to put an application into the state it should be in at the start of a testcase.
You can define the application state from scratch or base the definition on another application state, which in turn can be based on another application state, and so on. The base state is the lowest level of application state in this chain of inheritance. The application state DefaultBaseState is predefined for your use by SilkTest.
To associate an application state with a testcase, use the appstate keyword when you define the testcase. The second example below associates the application state MyAppState (which is based on MyBaseState) with the testcase MyTestCase.
· By default, SilkTest call the SetAppState function when you enter a testcase, in the DefaultTestCaseEnter function.
The SetAppState function executes the statements defined in the application state and in each of the application states upon which it is based, starting with the statements in the base state and working up to the application state chain.
· By default, SilkTest calls the SetBaseState function when you exit a testcase, in the DefaultTestCaseExit function.
The SetBaseState function executes the statements defined in the lowest level application state only (the base state). For example, suppose a testcase uses the application state AppState3, based on AppState2, based on AppState1. Calling the SetBaseState function executes only the statements in AppState1.
References www.segue.com ,Silkuserguide.pdf ,,SilkTest help
SilkTest - Computer Based Training
Objective: To give hands-on training with silk test for 5 members. A series of classes running for 5 days with
morning session of 2 hrs/day on theory and afternoon session of 2-3 hr. on practical and assignment will be designed to provide in depth knowledge on silk test.
Support Documents: A Handout or Online Training material associated with it. Referral books will be furnished upon request.
Required Skills: Programming logic, HTML Objects, Components of Web Technology, Popular Web Servers and Web Browsers in the Market.
Technical / Equipment requirements: Hardware: 5 Computers with 128 MB memory and 4GB Hard Disk. Software: Windows NT workstation, Netscape Communicator 4.75, Internet Explorer 5.0 installed.
Client - Server testing:
With SilkTest:
• You can test an application that runs on a different machine than SilkTest. • You can test applications running on two or more machines at once. • You can test multiple different applications simultaneously. The database tester provides an additional feature: You can access a server database directly, thereby circumventing the untested database operations of the application under test.
In a client/server environment, SilkTest drives the client application by means of an Agent process running on each application’s machine. The application then drives the server just as it always does. SilkTest is also capable of driving the GUI belonging to a server or of directly driving a server database by running scripts that submit SQL statements to the database. These methods of directly manipulating the server application are intended to support testing in which the client application drives the server.
The kinds of network testing you can perform
Software testing can be categorized according to the various broad testing goals that are the focus of the individual tests. This section describes at a conceptual level the kinds of automated application testing you can perform using SilkTest in a networked environment:
Functional
Configuration
Concurrency
Stress
Load
Performance
Client/server testing configurations:
The processes that participate in a client/server testing scenario are logically associated with three different computers:
1 System A runs SilkTest, which processes test scripts and sends application commands to the Agent.
2 System B runs the client application and the SilkTest Agent, which submits the application commands to the client application.
3 System C runs the server software, which reacts to requests submitted by the client application.
During your initial test development phase, you can reduce your hardware needs by making two (and possibly all) of these systems the same. If you write tests for an application running on the same system as SilkTest, you can implement the tests without consideration of any of the issues of remote testing. You can then expand your testing program incrementally to take your testing into each new phase.
Understanding host and target machines
In a client/server environment, SilkTest typically drives the client application by means of an Agent process running on each application’s machine. The application then drives the server. Alternatively, SilkTest is capable of driving the GUI for a server (if it has one) or of driving a server database directly by running scripts that submit SQL statements to the database.
SilkTest runs on many platforms, but only three different protocols are used. This means that a SilkTest script on one platform can drive the Agent on a target platform, as long as both the host and Agent platforms are running an appropriate protocol for the platform and both are running the same protocol (regardless of the protocols used by the applications under test).
For example, suppose you are running SilkTest under Windows 95 and testing an application that requires TCP/IP communications in order to communicate with a server on a Sun Sparc station. SilkTest’s Windows machine can run NetBIOS for the host and the application’s Windows machine must then run NetBIOS for the Agent as well as TCP/IP for the application under test. Running NetBIOS will have no impact on your TCP/ IP connections but will allow SilkTest to communicate with the Agent.
Alternatively, since the application is already running TCP/IP, you can choose to use TCP/IP for SilkTest and its Agents as well.
To configure a network of computers so that they can run SilkTest and its Agents, you must do the following:
Install (or have already running) networking protocols supported by SilkTest.
Install SilkTest on the host machine and the Agent software on all target machines.
Establish connectability between host and Agents. This may require some setup.
Enable networking on any PC-based target machines; use the Agent window
Enable networking on the host machine. Use the Runtime Options dialog; details vary, depending on your configuration.
Gather the information that your test scripts will need when making explicit connections. For example, you can edit the Agent names into a list definition and have your testplan pass the list variable name as an argument for testcases controlled by that plan. The testcases then pass each Agent name to a Connect or SetUpMachine function and that function makes the explicit host-to-Agent connection.
Parallel processing Template:
You can use this template by doing three edits:
Include the file that contains your window declarations.
Substitute your application’s MainWin name defined in your MainWin window declaration for the template’s “MyMainWin” MainWin name.
Insert the calls to one or more tests, or to the main function, where indicated.
file://sample code
use "myframe.inc"
multitestcase MyParallelTest (LIST of STRING lsMachines) STRING sMachine
// Connect to all machines in parallel:
for each sMachine in lsMachines
spawn
SetUpMachine (sMachine, MyMainWin)
rendezvous
// Set app state of each machine, invoking if necessary:
SetMultiAppStates()
// Run testcases in parallel
for each sMachine in lsMachines
spawn
SetMachine (sMachine)
// Call testcase(s) or call main()
rendezvous
Configuring the settings
In SilkTest, select Option -> Extentions menu from the menu bar.
It will load the Extentions dialog box.
In that dialog box, check the kind of application you are testing.
Say, if you are testing the web based application in the Netscape browser, Enable the Netscape option by checking against it and un-check all the other options.
Click on the OK button.
Now click on the Options -> Runtime option.
Set the 'use path' option to point to the silktest installed folder. Say if the silktest has been installed in your c:\ drive then set the use files = "C:\Program Files\Segue\SilkTest\EXTEND". This is to use the common include files as per the application.
Since we have selected the Extentions, the use file will have the declaration 'extend\netscape.inc' of the include file.
Now the script is ready to open the Netscape browser by default and run the scripts.
From the status bar Go to the Start -> Programs -> SilkTest -> Extention Enabller option, to declare the same set of extentions ( as in step 4) in the 'Extention Enabler' dialog box.
TESTING: The primary reasons to test the applications are to identify the defects and measure the quality of the application.
Different kinds of testing :There are different types of tests that can be executed depending on the objectives of the test engineer.
Error testing :Verify the product’s responses to error conditions. These tests ensure that the responses are meaningful, correct, and may include the display of context-sensitive, error-specific help screens. Reviewing error message lists may help to identify each error which can be generated by a specific screen or module.
Stress testing :Measure the system’s response to large amounts of data. This may include single-users manipulating large sets of data, or multiple machines running the application simultaneously.
White - Box testing :Places the focus on the internal structure of the software. Tests are designed using the code and the functional specification as input.
Black - Box testing :Views the software from the end-user perspective, and is unaware of the underlying code.
Distributed testing :Is concerned about the behavior of the client software as well as the data being stored and manipulated at the server. This may include verification of startup data,
modifications to tables, verification that cascading deletes are correct, and that dependencies between database tables are correct.
Multi - User testing:Includes concurrency tests which verify the interaction of two simultaneous users on two separate machines. For example, if one user locks a record, a second user may receive an error message when attempting to lock the same record. Stress testing verifies the response of the system when a large number of users are connected to the database. Other types of tests verify that a process on one machine is capable of initiating a process on another machine.
SilkTest Features:
Some of the features of silktest are given below.
Easy-to-use interface
Built-in recovery system
The object oriented concept
Record & Play
Multi-kind application testing
Automatic generation of results
Browser & Platform independent
Distributed testing
24x365 unattended testing
Power Testing with the 4Test Language
Centralized Testing of Distributed Applications
Distributed Access to Test Results
Extensive Component Testing
Cross-Platform Java Testing
Testing Across Multiple Browsers and Windows Versions
Support for HTML, XML, JavaScript, Java, ActiveX, Windows controls, and Visual Basic
Single-recording testing for cross-platform Java testing with the SilkBean
Against Over 35 Databases
Link Tester
Validation of Advanced Database Structures and Techniques
Creation of
Test Plan
Test Frame
Test Suite
Integration with other silk products.
SilkTest architecture :
Normal use of an application consists of a person manipulating a keyboard and mouse to initiate application operations. The person is said to be interacting with the GUI (Graphical User Interface). During SilkTest testing, SilkTest interacts with the GUI to submit operations to the application automatically. Thus SilkTest can simulate the actions of a person who is exercising all the capabilities of an application and verifying the results of each operation. The simulated user (SilkTest) is said to be driving the application. The application under test reacts to the simulated user exactly as it would react to a human user. SilkTest consists of two distinct software components that execute in separate processes:
The SilkTest host software
The 4Test Agent software
SilkTest host software
The SilkTest host software is the program you use to develop, edit, compile, run, and debug your 4Test scripts and testplans. This manual refers to the system that runs this program as the host machine or the SilkTest machine.
The Agent
The 4Test Agent is the software process that translates the commands in your 4Test scripts into GUI-specific commands. In other words, it is the Agent that actually drives and monitors the application you are testing. One Agent can run locally on the host machine. In a networked environment, any number of Agents can run on remote machines. This manual refers to the systems that run remote Agents as target machines. In a client/server environment, SilkTest drives the client application by means of an Agent process running on each application’s machine. The application then drives the server just as it always does. SilkTest is also capable of driving the GUI belonging to a server or of directly driving a server database by running scripts that submit SQL statements to the database. These methods of directly manipulating the server application are intended to support testing in which the client application drives the server.
Limitations of SilkTest:
Some of the limitations of SilkTest are given below.
SilkTest may not recognise some objects in a window / page due to some technical reasons.
SilkTest may not recognise some window frames.
The 'tag' value may get changed frequently.
Sometimes it will be difficult to activate some window.
It may be necessary to make some modifications if testing should be shifted to other browser/operating system.
In web based applications, sometimes silktest will take the links as simple text.
System Requirements:
The minimum requirement, a system needs to run the silk test is given below.
Windows NT, Windows 95, 98 or 2000
Pentium 466 Mhz or better processor (application dependent)
32 MB RAM
60MB Hard Disk
· Supported Environments:
Netscape Navigator 4.x
Internet Explorer 4 and 5
ActiveX, Visual Basic 5 and 6
Java JDK 1.3
Swing 1.1
Microsoft Web browser control
Posted in: Silk Test
0 comments:
Post a Comment