Wednesday, December 28, 2011
Sunday, September 18, 2011
Software Architectures
One Tier Architecture :
A simple form of standalone application architecture where everything resides in a single program. Contrast this to 2-tier and 3-tier architectures.
Single-tier architecture is the notion of having the user interface of a web application, the middle ware and the data access all contained in one whole architecture. Usually in Software Engineer you break your application to make them more maintainable and sustainable. If you know that your software will not grow over time, you may want to do a single tier architecture.
Two Tier Architecture :
In Two-Tier Architecture we have just two layers
1. GUI/ intrface / presentation layar
2. Database layer (where we store/retrieve our data)
Basically this architecture is followed in client/server applications where database and application resides in the same machine or database may in other machine conected thtough network.
Two-tier architecture is a client/server architecture , where a request to do some task is sent to the server and the server responds by performing the task.where as a three-tier or a multi tier architecture has client, server and database. Where the client request is sent to the server and the server in turn sends the request to the database. The database sends back the information/data required to the server which inturn sends it to the client.
Three Tier Architecture :
In three tier architecture we can find three layers names:
1. Presentation Layer
2. Busness Layer/ Mid Layer
3. Database Layer.
Presentation Layer: GUI/Interface , where a user view or enters the data.
Business Layer: where business login and rules are execute and can accommodate hundreds of users.
Database Layer: Data access layer takes care of connection between the appication and storing the data as a warehouse.This is very important layer in any architecture 'coz finally all data comes to it and maintaining such a huge amount of data is taken care by this layer avoiding concurrency and maintaining scalibility, durability to the application.
Load Testing with LoadRunner
LoadRunner reduces the personnel requirements by replacing human users with virtual users or Vusers. These Vusers emulate the behavior of real users—operating real applications.
Because numerous Vusers can run on a single computer, LoadRunner reduces the hardware requirements.
The LoadRunner Controller allows you to easily and effectively control all the Vusers—from a single point of control
The repeatability of the tests are very easy and effective
Loadrunner generates effective graphs and reports for analysing the performance of the applications
Because numerous Vusers can run on a single computer, LoadRunner reduces the hardware requirements.
The LoadRunner Controller allows you to easily and effectively control all the Vusers—from a single point of control
The repeatability of the tests are very easy and effective
Loadrunner generates effective graphs and reports for analysing the performance of the applications
Manual Load Testing
It is expensive, requiring large amounts of both personnel and machinery
It is complicated, especially coordinating and synchronizing multiple testers
It involves a high degree of organization, especially to record and analyze results meaningfully
The repeatability of the manual tests is limited
It is complicated, especially coordinating and synchronizing multiple testers
It involves a high degree of organization, especially to record and analyze results meaningfully
The repeatability of the manual tests is limited
Sunday, June 26, 2011
Understanding Checkpoints
A checkpoint is a verification point that compares a current value for a specified property.
When you add a checkpoint, QuickTest adds a checkpoint to the current row in the Keyword View and adds a Check Checkpoint statement in the Expert View.
When you run the test or component, Quickest compares the expected results of the checkpoint to the current results.
If the results do not match, the checkpoint fails.
You can view the results of the checkpoint in the Test Results window with the expected value for that property.
If you want to retrieve the return value of a checkpoint (a Boolean value that indicates whether the checkpoint passed or failed), you must add parentheses around the checkpoint argument in the statement in the Expert View. For example: a = browser("MyBrowser").page("MyPage").check (checkPoint("MyProperty"))
Check Points
1.Standard Check point
Check values of the object's property
2.Image Check point
Checks the property values of the image
3.Table Check point
Checks information in the table
4.Page Check point
Check the characteristics of the web page
5.Text/Text Area Check point
Checks that a text string is displayed in the appropriate place or application window
Adding Check points to Test
You can add checkpoints during a recording session or while editing your test or component. It is generally more convenient to define checks once the initial test or component has been recorded.
Quickest adds a checkpoint to the current row in the Keyword View and adds a Check Checkpoint statement in the Expert View.
To add checkpoints while recording or editing:
Use the commands on the Insert menu, or click the arrow beside the Insert Checkpoint button on the Testing toolbar. This displays a menu of checkpoint options that are relevant to the selected step in the Keyword View
To add a checkpoint while editing only:
Right-click the step in the Keyword View where you want to add the checkpoint and choose
Insert Standard Checkpoint
Right-click any object in the Active Screen and choose Insert Standard Checkpoint. This option can be used to create checkpoints for any object in the Active Screen (even if the object is not part of any step in the Keyword View).
Understanding the checkpoint property dialog box
![]()
Different type of checkpoints in detail:
Standard Checkpoint
Standard checkpoints are supported for all add-in environments.
The standard checkpoint checks a variety of objects such as buttons, radio buttons, combo boxes, lists, etc.
Example : you can check that a radio button is activated after it is selected or you can check the value of an edit field.
Page Checkpoint
checks the characteristics of a Web page. For example, you can check how long a Web page takes to load or whether a Web page contains broken links. You create a page checkpoint by inserting a standard checkpoint on a page object.
Note :- Page checkpoints are supported for the Web environment only
Image Checkpoint
checks the value of an image in your application or Web page. For example, you can check that a selected image’s source file is correct.
Note: You create an image checkpoint by inserting a standard checkpoint on an image object.
Text Checkpoint
Checks that a text string is displayed in the appropriate place in your application or on a Web page.
Example suppose your application or Web page displays the sentence Flight departing from New York to San Francisco. You can create a text checkpoint that checks that the words “New York” are displayed between “Flight departing from” and “to San Francisco”.
Text Area Checkpoint
Checks that a text string is displayed within a defined area in a Windows application, according to specified criteria.
Suppose your Visual Basic application has a button that says View Doc, where is replaced by the four digit code entered in a form elsewhere in the application.
You can create a text area checkpoint to confirm that the number displayed on the button is the same as the number entered in the form
Accessibility Checkpoint
identifies areas of your Web site that may not
conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines.
Bitmap Checkpoint
Checks an area of your Web page or application as a bitmap.
Suppose you have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. You can record the new map that is displayed after one click on the control key that zooms in the map. Using the bitmap checkpoint, you can check that the map zooms in correctly.
Table Checkpoint
checks information within a table. For example, suppose
our application or Web site contains a table listing all available flights from New York to San Francisco. You can add a table checkpoint to check that the time of the first flight in the table is correct.
Note: You create a table checkpoint by inserting a standard checkpoint on a table object.
Database Checkpoint
Checks the contents of a database accessed by your application. For example, you can use a database checkpoint to check the contents of a database containing flight information for your Web site.
XML Checkpoint
Checks the data content of XML documents in XML files or XML documents in Web pages and frames
When you add a checkpoint, QuickTest adds a checkpoint to the current row in the Keyword View and adds a Check Checkpoint statement in the Expert View.
When you run the test or component, Quickest compares the expected results of the checkpoint to the current results.
If the results do not match, the checkpoint fails.
You can view the results of the checkpoint in the Test Results window with the expected value for that property.
If you want to retrieve the return value of a checkpoint (a Boolean value that indicates whether the checkpoint passed or failed), you must add parentheses around the checkpoint argument in the statement in the Expert View. For example: a = browser("MyBrowser").page("MyPage").check (checkPoint("MyProperty"))
Check Points
1.Standard Check point
Check values of the object's property
2.Image Check point
Checks the property values of the image
3.Table Check point
Checks information in the table
4.Page Check point
Check the characteristics of the web page
5.Text/Text Area Check point
Checks that a text string is displayed in the appropriate place or application window
Adding Check points to Test
You can add checkpoints during a recording session or while editing your test or component. It is generally more convenient to define checks once the initial test or component has been recorded.
Quickest adds a checkpoint to the current row in the Keyword View and adds a Check Checkpoint statement in the Expert View.
To add checkpoints while recording or editing:
Use the commands on the Insert menu, or click the arrow beside the Insert Checkpoint button on the Testing toolbar. This displays a menu of checkpoint options that are relevant to the selected step in the Keyword View
To add a checkpoint while editing only:
Right-click the step in the Keyword View where you want to add the checkpoint and choose
Insert Standard Checkpoint
Right-click any object in the Active Screen and choose Insert Standard Checkpoint. This option can be used to create checkpoints for any object in the Active Screen (even if the object is not part of any step in the Keyword View).
Understanding the checkpoint property dialog box
Standard Checkpoint
Standard checkpoints are supported for all add-in environments.
The standard checkpoint checks a variety of objects such as buttons, radio buttons, combo boxes, lists, etc.
Example : you can check that a radio button is activated after it is selected or you can check the value of an edit field.
Page Checkpoint
checks the characteristics of a Web page. For example, you can check how long a Web page takes to load or whether a Web page contains broken links. You create a page checkpoint by inserting a standard checkpoint on a page object.
Note :- Page checkpoints are supported for the Web environment only
Image Checkpoint
checks the value of an image in your application or Web page. For example, you can check that a selected image’s source file is correct.
Note: You create an image checkpoint by inserting a standard checkpoint on an image object.
Text Checkpoint
Checks that a text string is displayed in the appropriate place in your application or on a Web page.
Example suppose your application or Web page displays the sentence Flight departing from New York to San Francisco. You can create a text checkpoint that checks that the words “New York” are displayed between “Flight departing from” and “to San Francisco”.
Text Area Checkpoint
Checks that a text string is displayed within a defined area in a Windows application, according to specified criteria.
Suppose your Visual Basic application has a button that says View Doc
You can create a text area checkpoint to confirm that the number displayed on the button is the same as the number entered in the form
Accessibility Checkpoint
identifies areas of your Web site that may not
conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines.
Bitmap Checkpoint
Checks an area of your Web page or application as a bitmap.
Suppose you have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. You can record the new map that is displayed after one click on the control key that zooms in the map. Using the bitmap checkpoint, you can check that the map zooms in correctly.
Table Checkpoint
checks information within a table. For example, suppose
our application or Web site contains a table listing all available flights from New York to San Francisco. You can add a table checkpoint to check that the time of the first flight in the table is correct.
Note: You create a table checkpoint by inserting a standard checkpoint on a table object.
Database Checkpoint
Checks the contents of a database accessed by your application. For example, you can use a database checkpoint to check the contents of a database containing flight information for your Web site.
XML Checkpoint
Checks the data content of XML documents in XML files or XML documents in Web pages and frames
Sunday, June 12, 2011
Regular Expressions
Regular expressions enable QuickTest to identify objects
and text strings with varying values.
You can use regular expressions when:
• defining the property values of an object
• parameterize a step
• creating checkpoints with varying values
A regular expression is a string that specifies a complex search phrase.
Common Options used in the regular expression
Using the Backslash Character ( \ )
Matching Any Single Character ( . )
Matching Any Single Character in a List ( [xy] )
Matching Any Single Character Not in a List ( [^xy] )
Matching Any Single Character within a Range ( [x-y] )
Matching Zero or More Specific Characters ( * )
Matching One or More Specific Characters ( + )
Matching Zero or One Specific Character ( ? )
Matching One of Several Regular Expressions ( |)
Matching the Beginning of a Line ( ^ )
Matching the End of a Line ( $ )
Matching Any AlphaNumeric Character Including the
Underscore ( \w )
Matching Any Non-AlphaNumeric Character ( \W )
Combining Regular Expression Operators
and text strings with varying values.
You can use regular expressions when:
• defining the property values of an object
• parameterize a step
• creating checkpoints with varying values
A regular expression is a string that specifies a complex search phrase.
Common Options used in the regular expression
Using the Backslash Character ( \ )
Matching Any Single Character ( . )
Matching Any Single Character in a List ( [xy] )
Matching Any Single Character Not in a List ( [^xy] )
Matching Any Single Character within a Range ( [x-y] )
Matching Zero or More Specific Characters ( * )
Matching One or More Specific Characters ( + )
Matching Zero or One Specific Character ( ? )
Matching One of Several Regular Expressions ( |)
Matching the Beginning of a Line ( ^ )
Matching the End of a Line ( $ )
Matching Any AlphaNumeric Character Including the
Underscore ( \w )
Matching Any Non-AlphaNumeric Character ( \W )
Combining Regular Expression Operators
Error Recovery
Recover Scenario:
Unexpected events, errors, and application crashes during a run session can disrupt your run session and distort results.
This is a problem particularly when running tests or components unattended—the test or component is suspended until you perform the operation needed to recover.
A recovery scenario consists of the following:
1.Trigger Event
2. Recovery Operation(s)
3. Post Recovery Test Run option
Deciding When to use Recovery Scenarios
• If we can predict that a certain event may happen at a specific point in your test or component.
• For e.g., say overwrite file message.
Defining Recovery Scenario
• The Recovery Scenario Manager dialog box enables to create recovery scenarios and save them in recovery files.
• We can create recovery scenarios using the Recovery Scenario Wizard, which leads through the process of defining each of the stages of the recovery scenario.
• We then save the recovery scenarios in a recovery file, and associate them with specific tests or components.
Understanding the Recovery Scenario Wizard
• Defining the trigger event that interrupts the run session
• Specifying the recovery operation(s) required to continue
• Choosing a post-recovery test run operation
• Specifying a name and description for the recovery scenario
• Specifying whether to associate the recovery scenario to the current test and/or to all new tests
Understanding the recovery scenario wizard
Welcome screen
Trigger Event Screen - Object State Trigger Event
Trigger Event Screen - Object State Trigger Event
Trigger Event Screen - Test Run Error Trigger event
Any Error
Item in the list or menu is not unique
Item in the list or menu is not found
More that one object responds to the physical description
Object is disabled
Object not found
Object not visible
Trigger Event Screen - Application Crash Trigger Event
Recovery Operations Screen
Keyboard or mouse operations
Close Application process
Function Call
Restart Ms windows
Click button or press key Close processes screen
Recovery Operations Screen - Function Call Screen
Post Recovery Test Run Options Screen
Repeat current step and continue
Proceed to nest step
Proceed to next action iteration
Proceed to next test Iteration
Restart current test run
Stop the test run
Name and Description Screen Finish Screen
Managing Recovery Scenarios
Managing Recovery Scenarios
Recovery Scenario Manager enables us to manage existing scenarios by:
Viewing Recovery Scenario Properties
Modifying Recovery Scenarios
Deleting Recovery Scenarios
Copying Recovery Scenarios between
Recovery Scenario files
Setting Recovery Scenarios List for the Tests
Adding Recovery Scenarios to the tests
Viewing Recovery Scenario Properties
Setting Recovery Scenario Priorities
Enabling and Disabling Recovery Scenarios
Setting Default Recovery Scenario Settings for All New Tests
Programmatically Controlling the Recovery Mechanism
We can use the Recovery object to control the recovery mechanism programmatically during the run session. For example:
Enable or disable the entire recovery mechanism or specific recovery scenarios for certain parts of a run session.
Retrieve status information about specific recovery scenarios
Explicitly activate the recovery mechanism at a certain point in the run session
By default, QuickTest checks for recovery triggers when an error is returned during the run session.
We can use the Recovery object’s Activate method to force QuickTest to check for triggers after a specific step in the run session
Represents the Recovery tab of the Test Settings or Business Component Settings dialog box, which enables you to configure which recovery scenarios to associate with a test or business component.
Methods
Add Adds the specified recovery scenario to the specified position.
Find The position of the specified recovery scenario.
MoveToPos Changes the order of the recovery scenarios by moving a recovery scenario from its current position to a specified position.
Remove Removes the recovery scenario that is located in the specified position.
RemoveAll Removes all recovery scenarios from the Recovery collection.
SetActivationMode Sets the activation mode for all the recovery scenarios associated with the test or component.
SetAsDefault Sets the current list of recovery scenarios as the default recovery scenarios for all new tests or business components.
Add
object.Add ScenarioFile, ScenarioName, [Position]
Find
object.Find (ScenarioFile, ScenarioName)
MoveToPos
object.MoveToPos CurPosition, NewPosition
Remove
object.Remove Position
Remove All
object.RemoveAll
SetActivationMode
object.SetActivationMode Mode
SetAsDefault
object.SetAsDefault
Unexpected events, errors, and application crashes during a run session can disrupt your run session and distort results.
This is a problem particularly when running tests or components unattended—the test or component is suspended until you perform the operation needed to recover.
A recovery scenario consists of the following:
1.Trigger Event
2. Recovery Operation(s)
3. Post Recovery Test Run option
Deciding When to use Recovery Scenarios
• If we can predict that a certain event may happen at a specific point in your test or component.
• For e.g., say overwrite file message.
Defining Recovery Scenario
• The Recovery Scenario Manager dialog box enables to create recovery scenarios and save them in recovery files.
• We can create recovery scenarios using the Recovery Scenario Wizard, which leads through the process of defining each of the stages of the recovery scenario.
• We then save the recovery scenarios in a recovery file, and associate them with specific tests or components.
Understanding the Recovery Scenario Wizard
• Defining the trigger event that interrupts the run session
• Specifying the recovery operation(s) required to continue
• Choosing a post-recovery test run operation
• Specifying a name and description for the recovery scenario
• Specifying whether to associate the recovery scenario to the current test and/or to all new tests
Understanding the recovery scenario wizard
Welcome screen
Trigger Event Screen
Trigger Event Screen - Pop-Up Window Trigger Event
Trigger Event Screen - Object State Trigger Event
Trigger Event Screen - Object State Trigger Event
Any Error
Item in the list or menu is not unique
Item in the list or menu is not found
More that one object responds to the physical description
Object is disabled
Object not found
Object not visible
Trigger Event Screen - Application Crash Trigger Event
Keyboard or mouse operations
Close Application process
Function Call
Restart Ms windows
Repeat current step and continue
Proceed to nest step
Proceed to next action iteration
Proceed to next test Iteration
Restart current test run
Stop the test run
Name and Description Screen Finish Screen
Recovery Scenario Manager enables us to manage existing scenarios by:
Viewing Recovery Scenario Properties
Modifying Recovery Scenarios
Deleting Recovery Scenarios
Copying Recovery Scenarios between
Recovery Scenario files
Setting Recovery Scenarios List for the Tests
Adding Recovery Scenarios to the tests
Viewing Recovery Scenario Properties
Setting Recovery Scenario Priorities
Enabling and Disabling Recovery Scenarios
Setting Default Recovery Scenario Settings for All New Tests
Programmatically Controlling the Recovery Mechanism
We can use the Recovery object to control the recovery mechanism programmatically during the run session. For example:
Enable or disable the entire recovery mechanism or specific recovery scenarios for certain parts of a run session.
Retrieve status information about specific recovery scenarios
Explicitly activate the recovery mechanism at a certain point in the run session
By default, QuickTest checks for recovery triggers when an error is returned during the run session.
We can use the Recovery object’s Activate method to force QuickTest to check for triggers after a specific step in the run session
Programmatically Controlling the Recovery Mechanism
Recovery ObjectRepresents the Recovery tab of the Test Settings or Business Component Settings dialog box, which enables you to configure which recovery scenarios to associate with a test or business component.
Methods
Add Adds the specified recovery scenario to the specified position.
Find The position of the specified recovery scenario.
MoveToPos Changes the order of the recovery scenarios by moving a recovery scenario from its current position to a specified position.
Remove Removes the recovery scenario that is located in the specified position.
RemoveAll Removes all recovery scenarios from the Recovery collection.
SetActivationMode Sets the activation mode for all the recovery scenarios associated with the test or component.
SetAsDefault Sets the current list of recovery scenarios as the default recovery scenarios for all new tests or business components.
Add
object.Add ScenarioFile, ScenarioName, [Position]
Find
object.Find (ScenarioFile, ScenarioName)
MoveToPos
object.MoveToPos CurPosition, NewPosition
Remove
object.Remove Position
Remove All
object.RemoveAll
SetActivationMode
object.SetActivationMode Mode
SetAsDefault
object.SetAsDefault
Monday, June 6, 2011
Descriptive programming
Introduction:
Using Descriptive Programming automation scripts can be created even if the application has not been developed.
Descriptive Programming:
Whenever QTP records any action on any object of an application, it adds some description on how to recognize that object to a repository of objects called object repository. QTP cannot take action on an object until unless its object description is in the Object Repository. But descriptive programming provides a way to perform action on objects which are not in Object repository
Object Identification:
To identify an object during the play back of the scripts QTP stores some properties which helps QTP to uniquely identify the object on a page. Below screen shots shows an example Object repository:
Browser("Browser").Page("Page").WebRadioGroup ("testPath").Select "2"
a = Browser("Browser").Page("Page").WebTable ("WebTable").GetCellData (1,1)
Browser("Example2").Page("Page").WebEdit("testPath").Set "Test text"
When and Why to use Descriptive programming?
Below are some of the situations when Descriptive Programming can be considered useful:
1. The objects in the application are dynamic in nature and need special handling to identify the object. The best example would be of clicking a link which changes according to the user of the application, Ex. “Logout <>”.
2. When object repository is getting huge due to the no. of objects being added. If the size of Object repository increases too much then it decreases the performance of QTP while recognizing a object.
3. When you don’t want to use object repository at all. Well the first question would be why not Object repository? Consider the following scenario which would help understand why not Object repository
Scenario 1: Suppose we have a web application that has not been developed yet. Now QTP for recording the script and adding the objects to repository needs the application to be up, that would mean waiting for the application to be deployed before we can start of with making QTP scripts. But if we know the descriptions of the objects that will be created then we can still start off with the script writing for testing
Scenario 2: Suppose an application has 3 navigation buttons on each and every page. Let the buttons be “Cancel”, “Back” and “Next”. Now recording action on these buttons would add 3 objects per page in the repository. For a 10 page flow this would mean 30 objects which could have been represented just by using 3 objects. So instead of adding these 30 objects to the repository we can just write 3 descriptions for the object and use it on any page.
4. Modification to a test case is needed but the Object repository for the same is Read only or in shared mode i.e. changes may affect other scripts as well.
5. When you want to take action on similar type of object i.e. suppose we have 20 textboxes on the page and there names are in the form txt_1, txt_2, txt_3 and so on. Now adding all 20 the Object repository would not be a good programming approach.
How to use Descriptive programming?
There are two ways in which descriptive programming can be used
1. By creating properties collection object for the description.
2. By giving the description in form of the string arguments.
1. By creating properties collection object for the description.
To use this method you need first to create an empty description
Dim obj_Desc ‘Not necessary to declare
Set obj_Desc = Description.Create
Now we have a blank description in “obj_Desc”. Each description has 3 properties “Name”, “Value” and “Regular Expression”.
obj_Desc(“html tag”).value= “INPUT”
When you use a property name for the first time the property is added to the collection and when you use it again the property is modified. By default each property that is defined is a regular expression. Suppose if we have the following description
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt.*”
This would mean an object with html tag as INPUT and name starting with txt. Now actually that “.*” was considered as regular expression. So, if you want the property “name” not to be recognized as a regular expression then you need to set the “regularexpression” property as FALSE
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt.*”
obj_Desc(“name”).regularexpression= “txt.*”
This is how of we create a description. Now below is the way we can use it
Browser(“Browser”).Page(“Page”).WebEdit(obj_Desc).set “Test”
When we say .WebEdit(obj_Desc) we define one more property for our description that was not earlier defined that is it’s a text box (because QTPs WebEdit boxes map to text boxes in a web page).
If we know that we have more than 1 element with same description on the page then we must define “index” property for the that description
Consider the HTML code given below
Now the html code has two objects with same description. So distinguish between these 2 objects we will use the “index” property. Here is the description for both the object
For 1st textbox:
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt_Name”
obj_Desc(“index”).value= “0”
For 2nd textbox:
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt_Name”
obj_Desc(“index”).value= “1”
Consider the HTML Code given below:
We can use the same description for both the objects and still distinguish between both of them
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt_Name”
When I want to refer to the textbox then I will use the inside a WebEdit object and to refer to the radio button I will use the description object with the WebRadioGroup object.
Browser(“Browser”).Page(“Page”).WebEdit(obj_Desc).set “Test” ‘Refers to the text box
Browser(“Browser”).Page(“Page”).WebRadioGroup(obj_Desc).set “Test” ‘Refers to the radio button
But if we use WebElement object for the description then we must define the “index” property because for a webelement the current description would return two objects.
Hierarchy of test description:
When using programmatic descriptions from a specific point within a test object hierarchy, you must continue to use programmatic descriptions
from that point onward within the same statement. If you specify a test object by its object repository name after other objects in the hierarchy have
been described using programmatic descriptions, QuickTest cannot identify the object.
For example, you can use Browser(Desc1).Page(Desc1).Link(desc3), since it uses programmatic descriptions throughout the entire test object hierarchy.
You can also use Browser("Index").Page(Desc1).Link(desc3), since it uses programmatic descriptions from a certain point in the description (starting
from the Page object description).
However, you cannot use Browser(Desc1).Page(Desc1).Link("Example1"), since it uses programmatic descriptions for the Browser and Page objects but
then attempts to use an object repository name for the Link test object (QuickTest tries to locate the Link object based on its name, but cannot
locate it in the repository because the parent objects were specified using programmatic descriptions).
Getting Child Object:
We can use description object to get all the objects on the page that matches that specific description. Suppose we have to check all the checkboxes present on a web page. So we will first create an object description for a checkboxe and then get all the checkboxes from the page
Dim obj_ChkDesc
Set obj_ChkDesc=Description.Create
obj_ChkDesc(“html tag”).value = “INPUT”
obj_ChkDesc(“type”).value = “checkbox”
Dim allCheckboxes, singleCheckBox
Set allCheckboxes = Browse(“Browser”).Page(“Page”).ChildObjects(obj_ChkDesc)
For each singleCheckBox in allCheckboxes
singleCheckBox.Set “ON”
Next
The above code will check all the check boxes present on the page. To get all the child objects we need to specify an object description i.e. we can’t use the string arguments that will be discussed later in the 2nd way of using the programming description.
Possible Operation on Description Object
Consider the below code for all the solutions
Dim obj_ChkDesc
Set obj_ChkDesc=Description.Create
obj_ChkDesc(“html tag”).value = “INPUT”
obj_ChkDesc(“type”).value = “checkbox”
Q: How to get the no. of description defined in a collection
A: obj_ChkDesc.Count ‘Will return 2 in our case
Q: How to remove a description from the collection
A: obj_ChkDesc.remove “html tag” ‘would delete the html tag property from the collection
Q: How do I check if property exists or not in the collection?
A: The answer is that it’s not possible. Because whenever we try to access a property which is not defined its automatically added to the collection. The only way to determine is to check its value that is use a if statement “if obj_ChkDesc(“html tag”).value = empty then”.
Q: How to browse through all the properties of a properties collection?
A: Two ways
1st:
For each desc in obj_ChkDesc
Name=desc.Name
Value=desc.Value
RE = desc.regularexpression
Next
2nd:
For i=0 to obj_ChkDesc.count - 1
Name= obj_ChkDesc(i).Name
Value= obj_ChkDesc(i).Value
RE = obj_ChkDesc(i).regularexpression
Next
2. By giving the description in form of the string arguments.
You can describe an object directly in a statement by specifying property:=value pairs describing the object instead of specifying an object’s
name. The general syntax is:
TestObject("PropertyName1:=PropertyValue1", "..." , "PropertyNameX:=PropertyValueX")
TestObject—the test object class could be WebEdit, WebRadioGroup etc….
PropertyName:=PropertyValue—the test object property and its value. Each property:=value pair should be separated by commas and quotation
marks. Note that you can enter a variable name as the property value if you want to find an object based on property values you retrieve during a run session.
Consider the HTML Code given below:
Now to refer to the textbox the statement would be as given below
Browser(“Browser”).Page(“Page”).WebEdit(“Name:=txt_Name”,”html tag:=INPUT”).set “Test”
And to refer to the radio button the statement would be as given below
Browser(“Browser”).Page(“Page”).WebRadioGroup(“Name:=txt_Name”,”html tag:=INPUT”).set “Test”
If we refer to them as a web element then we will have to distinguish between the 2 using the index property
Browser(“Browser”).Page(“Page”).WebElement(“Name:=txt_Name”,”html tag:=INPUT”,”Index:=0”).set “Test” ‘ Refers to the textbox
Browser(“Browser”).Page(“Page”).WebElement(“Name:=txt_Name”,”html tag:=INPUT”,”Index:=1”).set “Test” ‘ Refers to the radio button
Using Descriptive Programming automation scripts can be created even if the application has not been developed.
Descriptive Programming:
Whenever QTP records any action on any object of an application, it adds some description on how to recognize that object to a repository of objects called object repository. QTP cannot take action on an object until unless its object description is in the Object Repository. But descriptive programming provides a way to perform action on objects which are not in Object repository
Object Identification:
To identify an object during the play back of the scripts QTP stores some properties which helps QTP to uniquely identify the object on a page. Below screen shots shows an example Object repository:
Now to recognize a radio button on a page QTP had added 2 properties the name of the radio button and the html tag for it. The name the left tree view is the logical name given by QTP for the object. This can be changed as per the convenience of the person writing the test case. QTP only allows UNIQUE logical name under same level of hierarchy. As we see in the snapshot the two objects in Browser->Page node are “WebTable” and “testPath”, they cannot have the same logical name. But an object under some other node can have the same name. Now with the current repository that we have, we can only write operation on objects which are in the repository. Some of the example operations are given below
Browser("Browser").Page("Page").WebRadioGroup ("testPath").Select "2"
a = Browser("Browser").Page("Page").WebTable ("WebTable").GetCellData (1,1)
Browser("Example2").Page("Page").WebEdit("testPath").Set "Test text"
When and Why to use Descriptive programming?
Below are some of the situations when Descriptive Programming can be considered useful:
1. The objects in the application are dynamic in nature and need special handling to identify the object. The best example would be of clicking a link which changes according to the user of the application, Ex. “Logout <
2. When object repository is getting huge due to the no. of objects being added. If the size of Object repository increases too much then it decreases the performance of QTP while recognizing a object.
3. When you don’t want to use object repository at all. Well the first question would be why not Object repository? Consider the following scenario which would help understand why not Object repository
Scenario 1: Suppose we have a web application that has not been developed yet. Now QTP for recording the script and adding the objects to repository needs the application to be up, that would mean waiting for the application to be deployed before we can start of with making QTP scripts. But if we know the descriptions of the objects that will be created then we can still start off with the script writing for testing
Scenario 2: Suppose an application has 3 navigation buttons on each and every page. Let the buttons be “Cancel”, “Back” and “Next”. Now recording action on these buttons would add 3 objects per page in the repository. For a 10 page flow this would mean 30 objects which could have been represented just by using 3 objects. So instead of adding these 30 objects to the repository we can just write 3 descriptions for the object and use it on any page.
4. Modification to a test case is needed but the Object repository for the same is Read only or in shared mode i.e. changes may affect other scripts as well.
5. When you want to take action on similar type of object i.e. suppose we have 20 textboxes on the page and there names are in the form txt_1, txt_2, txt_3 and so on. Now adding all 20 the Object repository would not be a good programming approach.
How to use Descriptive programming?
There are two ways in which descriptive programming can be used
1. By creating properties collection object for the description.
2. By giving the description in form of the string arguments.
1. By creating properties collection object for the description.
To use this method you need first to create an empty description
Dim obj_Desc ‘Not necessary to declare
Set obj_Desc = Description.Create
Now we have a blank description in “obj_Desc”. Each description has 3 properties “Name”, “Value” and “Regular Expression”.
obj_Desc(“html tag”).value= “INPUT”
When you use a property name for the first time the property is added to the collection and when you use it again the property is modified. By default each property that is defined is a regular expression. Suppose if we have the following description
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt.*”
This would mean an object with html tag as INPUT and name starting with txt. Now actually that “.*” was considered as regular expression. So, if you want the property “name” not to be recognized as a regular expression then you need to set the “regularexpression” property as FALSE
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt.*”
obj_Desc(“name”).regularexpression= “txt.*”
This is how of we create a description. Now below is the way we can use it
Browser(“Browser”).Page(“Page”).WebEdit(obj_Desc).set “Test”
When we say .WebEdit(obj_Desc) we define one more property for our description that was not earlier defined that is it’s a text box (because QTPs WebEdit boxes map to text boxes in a web page).
If we know that we have more than 1 element with same description on the page then we must define “index” property for the that description
Consider the HTML code given below
Now the html code has two objects with same description. So distinguish between these 2 objects we will use the “index” property. Here is the description for both the object
For 1st textbox:
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt_Name”
obj_Desc(“index”).value= “0”
For 2nd textbox:
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt_Name”
obj_Desc(“index”).value= “1”
Consider the HTML Code given below:
We can use the same description for both the objects and still distinguish between both of them
obj_Desc(“html tag”).value= “INPUT”
obj_Desc(“name”).value= “txt_Name”
When I want to refer to the textbox then I will use the inside a WebEdit object and to refer to the radio button I will use the description object with the WebRadioGroup object.
Browser(“Browser”).Page(“Page”).WebEdit(obj_Desc).set “Test” ‘Refers to the text box
Browser(“Browser”).Page(“Page”).WebRadioGroup(obj_Desc).set “Test” ‘Refers to the radio button
But if we use WebElement object for the description then we must define the “index” property because for a webelement the current description would return two objects.
Hierarchy of test description:
When using programmatic descriptions from a specific point within a test object hierarchy, you must continue to use programmatic descriptions
from that point onward within the same statement. If you specify a test object by its object repository name after other objects in the hierarchy have
been described using programmatic descriptions, QuickTest cannot identify the object.
For example, you can use Browser(Desc1).Page(Desc1).Link(desc3), since it uses programmatic descriptions throughout the entire test object hierarchy.
You can also use Browser("Index").Page(Desc1).Link(desc3), since it uses programmatic descriptions from a certain point in the description (starting
from the Page object description).
However, you cannot use Browser(Desc1).Page(Desc1).Link("Example1"), since it uses programmatic descriptions for the Browser and Page objects but
then attempts to use an object repository name for the Link test object (QuickTest tries to locate the Link object based on its name, but cannot
locate it in the repository because the parent objects were specified using programmatic descriptions).
Getting Child Object:
We can use description object to get all the objects on the page that matches that specific description. Suppose we have to check all the checkboxes present on a web page. So we will first create an object description for a checkboxe and then get all the checkboxes from the page
Dim obj_ChkDesc
Set obj_ChkDesc=Description.Create
obj_ChkDesc(“html tag”).value = “INPUT”
obj_ChkDesc(“type”).value = “checkbox”
Dim allCheckboxes, singleCheckBox
Set allCheckboxes = Browse(“Browser”).Page(“Page”).ChildObjects(obj_ChkDesc)
For each singleCheckBox in allCheckboxes
singleCheckBox.Set “ON”
Next
The above code will check all the check boxes present on the page. To get all the child objects we need to specify an object description i.e. we can’t use the string arguments that will be discussed later in the 2nd way of using the programming description.
Possible Operation on Description Object
Consider the below code for all the solutions
Dim obj_ChkDesc
Set obj_ChkDesc=Description.Create
obj_ChkDesc(“html tag”).value = “INPUT”
obj_ChkDesc(“type”).value = “checkbox”
Q: How to get the no. of description defined in a collection
A: obj_ChkDesc.Count ‘Will return 2 in our case
Q: How to remove a description from the collection
A: obj_ChkDesc.remove “html tag” ‘would delete the html tag property from the collection
Q: How do I check if property exists or not in the collection?
A: The answer is that it’s not possible. Because whenever we try to access a property which is not defined its automatically added to the collection. The only way to determine is to check its value that is use a if statement “if obj_ChkDesc(“html tag”).value = empty then”.
Q: How to browse through all the properties of a properties collection?
A: Two ways
1st:
For each desc in obj_ChkDesc
Name=desc.Name
Value=desc.Value
RE = desc.regularexpression
Next
2nd:
For i=0 to obj_ChkDesc.count - 1
Name= obj_ChkDesc(i).Name
Value= obj_ChkDesc(i).Value
RE = obj_ChkDesc(i).regularexpression
Next
2. By giving the description in form of the string arguments.
You can describe an object directly in a statement by specifying property:=value pairs describing the object instead of specifying an object’s
name. The general syntax is:
TestObject("PropertyName1:=PropertyValue1", "..." , "PropertyNameX:=PropertyValueX")
TestObject—the test object class could be WebEdit, WebRadioGroup etc….
PropertyName:=PropertyValue—the test object property and its value. Each property:=value pair should be separated by commas and quotation
marks. Note that you can enter a variable name as the property value if you want to find an object based on property values you retrieve during a run session.
Consider the HTML Code given below:
Now to refer to the textbox the statement would be as given below
Browser(“Browser”).Page(“Page”).WebEdit(“Name:=txt_Name”,”html tag:=INPUT”).set “Test”
And to refer to the radio button the statement would be as given below
Browser(“Browser”).Page(“Page”).WebRadioGroup(“Name:=txt_Name”,”html tag:=INPUT”).set “Test”
If we refer to them as a web element then we will have to distinguish between the 2 using the index property
Browser(“Browser”).Page(“Page”).WebElement(“Name:=txt_Name”,”html tag:=INPUT”,”Index:=0”).set “Test” ‘ Refers to the textbox
Browser(“Browser”).Page(“Page”).WebElement(“Name:=txt_Name”,”html tag:=INPUT”,”Index:=1”).set “Test” ‘ Refers to the radio button
Friday, June 3, 2011
Using Library Files
QTP Library Files:
Library file is nothing but a VB script file containing code in VB Script format. Library files in QTP are used to declare functions that are needed to be used across actions. There are two ways to load a Library file in to your test:
1. Specify the Library file in the settings of the script
Variables, classes, functions etc… declared in the Library files are accessible to all the Actions present with in the test. Specifying library files using this method makes it impossible to restrict the use of the Library to specific actions.
Library file is nothing but a VB script file containing code in VB Script format. Library files in QTP are used to declare functions that are needed to be used across actions. There are two ways to load a Library file in to your test:
1. Specify the Library file in the settings of the script
Create the VB Script file that you need and save to your PC
In QTP go to Test->Settings… Menu as shown in the image below
Go to the Resources tab of the Test Settings window and Click on “+” button. A new line in the list box will appear
Click on “…” button to choose the location of the file
If you specify 2 or more library having a function with same name then QTP will execute the one that comes first i.e. by looking at the order you specify the files. There is no need to specify an order for dependent library file Ex- if file2 uses functions defined in file1 then it is not necessary to specify file1 above file2 any order will work fine.
Click on the “Check Syntax” button to verify that the script is a valid one
The VB script file has been associated with your test and functions it can be used in all the actions present in the script. If you click on the “Set as Default” button then all the library files specified in your current test would be automatically added to the new tests that you create from now on.
Variables, classes, functions etc… declared in the Library files are accessible to all the Actions present with in the test. Specifying library files using this method makes it impossible to restrict the use of the Library to specific actions.
2. Loading the library file at run-time
Instead of specifying the library file in test settings we can load it at run-time by using the execute file function.
ExecuteFile “C:\Documents and Settings\tarun_lalwani\Desktop\Demo.vbs”
This would load all the variables, classes, structures etc… declared in the Library but they would be accessible on in the action that has called the ExecuteFile function i.e. if Action1 loads a library file using ExecuteFile then everything present in the library file would only be accessible to Action1 and not any other action.
To Load a library file present in Test Director the path can be specified as “[Quality Center] Subject\PathInTD”
Once a Library file is loaded using ExecuteFile it can’t be unloaded. It is unloaded automatically when the action ends.
The below table gives advantages of both the methods
Specifying Library File in Test Setting Loading Library File at Run-Time
For declaring Global Variable, Functions, classes etc…
Add all global variables to a VB Script file and specify it in settings. For restricting functions of the library to specific Actions
For loading libraries depending upon conditions at run-time. Ex-
If Condition1 then
ExecuteFile “C:\File1.vbs”
Else
ExecuteFile “C:\File2.vbs”
End If
Sunday, May 29, 2011
Working With Text File
The File System object allows us to work with files and folders .We can read, write, create, and delete files and folders using the File System object and the objects that are associated with it.
Creation of Text File:
Three ways to create an empty text file:
1.CreateText File method
2.OpenTextFile method of the FileSystemObject object with the ForWriting flag set.
3.OpenAsTextStream method with the ForWriting flag set.
CreateTextFile Method
Creates a specified file name and returns a TextStream object that can be used to read from or write to the file.
Example:
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\testfile.txt", ForWriting, True)
f.Write "Hello world!“
f.Close
Syntax:
For Moving a File:
Object.Move(“Destination path”)
For Copying a File:
Object.Copy(“Destination path”)
For Deleting a File:
Object.Delete
Set MyFile = fso.GetFile("c:\testfile.txt")
MyFile.Move(c:\tmp\testfile.txt)
MyFile.Copy (“c:\QTP\testfile.txt “)
Set f2=fso.Getfile(“C:\QTP\testfile.txt”)
f2.Delete
There are 3 methods to read a file.
Read Method: Read a specified number of characters from a file.
ReadAll Method: Read the entire contents of a text.
ReadLine Method:Read an entire line (up to, but not including, the newline character).
Reads a specified number of characters from a TextStream file and returns the resulting string.
Write Method
Example:
Function WriteToFile
Const ForReading = 1, ForWriting = 2
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\testfile.txt", ForWriting, True)
f.Write "Hello world!"
WriteLine Method
Writes a specified string and newline character to a TextStream file.
Syntax :
object.WriteLine([string])
Example:
Const ForReading = 1, ForWriting = 2
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\testfile.txt", ForWriting, True)
f.WriteLine "Hello world!“
f.WriteLine "VBScript is fun!"
Writes a specified number of newline characters to a TextStream file.
Syntax: object.WriteBlankLines(lines)
WriteBlankLines Method
Example:
Const ForReading = 1, ForWriting = 2
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\testfile.txt", ForWriting, True)
f.WriteBlankLines 2
f.WriteLine "Hello World!"
Syntax: object.Read(characters)
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\testfile.txt", ForWriting, True)
Read Method
f.Write "Hello world!"
Set f = fso.OpenTextFile("c:\testfile.txt", ForReading)
s= f.Read(5)
Msgbox s
ReadAll Method
Reads an entire TextStream file and returns the resulting string.
Syntax :object.ReadAll( );
Readline Method
Example:
Dim fso, f1, ts, s
Const ForReading = 1
Set fso = CreateObject("Scripting.FileSystemObject")
Set f1 = fso.CreateTextFile("c:\testfile.txt", True)
Write Method
Writes a specified string to a TextStream file.
Syntax :
object.Write(string)
Syntax:
object.CreateTextFile(filename[, overwrite[, unicode]])
Object-> Name of a FileSystemObject or Folder object
Filename ->String expression that identifies the file to create.
Overwrite-> “True” if the file can be overwritten and “False” otherwise
Unicode-> value is “True” if the file is created as a Unicode file and “False” if the file is created as a ASCII file.
Example:
Dim fso, f1
Set fso = CreateObject("Scripting.FileSystemObject")
Set f1 = fso.CreateTextFile("c:\testfile.txt", True)
OpenTextFile method
Opens a Specified file and returns a Textstream object that can be used to read from,write to or append to the file.
Syntax: object.OpenasTextStream([iomode, [format]])
Object – Name of the File object
Iomode-Optional (Can be For Reading=1,For Writing=2 ,For Appending=8)
Format: Optional. Used to indicate the format of the opened file.
TristateUseDefault – 2
Tristate True –1
Tristate False 0
0 opens the file as ASCII and –1 opens as Unicode and –2 uses System default.
Example:
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Const TristateUseDefault = -2, TristateTrue = -1, TristateFalse = 0
Dim fso, f, ts
Set fso = CreateObject("Scripting.FileSystemObject") fso.CreateTextFile "test1.txt" ' Create a file.
Set f = fso.GetFile("test1.txt")
Set ts = f.OpenAsTextStream(ForWriting, TristateUseDefault)
ts.Write "Hello World"
ts.Close
FileMethod
Syntax:
object.OpenTextFile(filename[, iomode[, create[, format]]])
Object: Always the name of a FileSystemObject.
filename :String expression that identifies the file to open.
iomode :Optional. Can be one of three constants: ForReading, ForWriting, or ForAppending
Create: Optional. Boolean value that indicateas whether a new file can be created if the specified filename doesn't exist. The value is True if a new file is created, False if it isn't created. If omitted, a new file isn't created.
Creation of Text File:
Three ways to create an empty text file:
1.CreateText File method
2.OpenTextFile method of the FileSystemObject object with the ForWriting flag set.
3.OpenAsTextStream method with the ForWriting flag set.
CreateTextFile Method
Creates a specified file name and returns a TextStream object that can be used to read from or write to the file.
Example:
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\testfile.txt", ForWriting, True)
f.Write "Hello world!“
f.Close
Syntax:
For Moving a File:
Object.Move(“Destination path”)
For Copying a File:
Object.Copy(“Destination path”)
For Deleting a File:
Object.Delete
Set MyFile = fso.GetFile("c:\testfile.txt")
MyFile.Move(c:\tmp\testfile.txt)
MyFile.Copy (“c:\QTP\testfile.txt “)
Set f2=fso.Getfile(“C:\QTP\testfile.txt”)
f2.Delete
There are 3 methods to read a file.
Read Method: Read a specified number of characters from a file.
ReadAll Method: Read the entire contents of a text.
ReadLine Method:Read an entire line (up to, but not including, the newline character).
Reads a specified number of characters from a TextStream file and returns the resulting string.
Write Method
Example:
Function WriteToFile
Const ForReading = 1, ForWriting = 2
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\testfile.txt", ForWriting, True)
f.Write "Hello world!"
WriteLine Method
Writes a specified string and newline character to a TextStream file.
Syntax :
object.WriteLine([string])
Example:
Const ForReading = 1, ForWriting = 2
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\testfile.txt", ForWriting, True)
f.WriteLine "Hello world!“
f.WriteLine "VBScript is fun!"
Writes a specified number of newline characters to a TextStream file.
Syntax: object.WriteBlankLines(lines)
WriteBlankLines Method
Example:
Const ForReading = 1, ForWriting = 2
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\testfile.txt", ForWriting, True)
f.WriteBlankLines 2
f.WriteLine "Hello World!"
Syntax: object.Read(characters)
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Dim fso, f
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\testfile.txt", ForWriting, True)
Read Method
f.Write "Hello world!"
Set f = fso.OpenTextFile("c:\testfile.txt", ForReading)
s= f.Read(5)
Msgbox s
ReadAll Method
Reads an entire TextStream file and returns the resulting string.
Syntax :object.ReadAll( );
Readline Method
Example:
Dim fso, f1, ts, s
Const ForReading = 1
Set fso = CreateObject("Scripting.FileSystemObject")
Set f1 = fso.CreateTextFile("c:\testfile.txt", True)
Write Method
Writes a specified string to a TextStream file.
Syntax :
object.Write(string)
Syntax:
object.CreateTextFile(filename[, overwrite[, unicode]])
Object-> Name of a FileSystemObject or Folder object
Filename ->String expression that identifies the file to create.
Overwrite-> “True” if the file can be overwritten and “False” otherwise
Unicode-> value is “True” if the file is created as a Unicode file and “False” if the file is created as a ASCII file.
Example:
Dim fso, f1
Set fso = CreateObject("Scripting.FileSystemObject")
Set f1 = fso.CreateTextFile("c:\testfile.txt", True)
OpenTextFile method
Opens a Specified file and returns a Textstream object that can be used to read from,write to or append to the file.
Syntax: object.OpenasTextStream([iomode, [format]])
Object – Name of the File object
Iomode-Optional (Can be For Reading=1,For Writing=2 ,For Appending=8)
Format: Optional. Used to indicate the format of the opened file.
TristateUseDefault – 2
Tristate True –1
Tristate False 0
0 opens the file as ASCII and –1 opens as Unicode and –2 uses System default.
Example:
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Const TristateUseDefault = -2, TristateTrue = -1, TristateFalse = 0
Dim fso, f, ts
Set fso = CreateObject("Scripting.FileSystemObject") fso.CreateTextFile "test1.txt" ' Create a file.
Set f = fso.GetFile("test1.txt")
Set ts = f.OpenAsTextStream(ForWriting, TristateUseDefault)
ts.Write "Hello World"
ts.Close
FileMethod
Syntax:
object.OpenTextFile(filename[, iomode[, create[, format]]])
Object: Always the name of a FileSystemObject.
filename :String expression that identifies the file to open.
iomode :Optional. Can be one of three constants: ForReading, ForWriting, or ForAppending
Create: Optional. Boolean value that indicateas whether a new file can be created if the specified filename doesn't exist. The value is True if a new file is created, False if it isn't created. If omitted, a new file isn't created.
Friday, May 27, 2011
QTP DataTable
Introduction:
The Data Table is a Microsoft Excelsheet with columns and rows representing the data
The Data Table contains one Global tab plus an additional tab for each action.
The Data Table assists you in parameterizing your test.
To view the Data Table, click the Data Table toolbar button
DataTable Parameters:
Data Table parameters enable you to create a data-driven test, component, or action that runs several times using the data you supply. In each iteration, QTP uses a different value from the Data Table
Setting DataTable Parameter Options:
Data Table parameters enable you to create a data-driven test (or action) that runs several times using the data you supply. For each iteration, QTP uses a different value from the Data Table.
When Data Table is selected as the parameter type, the Parameter Options dialog box enables you to configure your parameter to use values from the Data Table.
Global Datasheet:
The Global sheet contains the data that replaces parameters in each iteration of the test. If you create a Global parameter called Arrivals, the Global sheet might look like this:
Run Time DataTable:
During the run session, QTP creates a run-time Data Table associated with your test.It displays the run-time data in the Data Table pane so that any changes to the Data Table can be seen as they occur.The final data from the run-time Data Table is displayed in the Run-Time Data Table in the Test Results window
The Run-Time Data Table displays the parameterized values that were used, as well as any output values stored in the Data Table during the run.The Run-Time Data Table can be viewed from the Test results window.
Run Time Data Table Methods:
AddSheet Method
DeleteSheet Method
Export Method
ExportSheet Method
GetCurrentRow Method
GetRowCount Method
GetSheet Method
GetSheetCount Method
Import Method
ImportSheet Method
SetCurrentRow Method
SetNextRow Method
SetPrevRow Method
AddSheet Method
Adds the specified sheet to the run-time Data Table and returns the sheet so that properties can be directly set for the new sheet in the same statement.
Syntax:
DataTable.AddSheet(SheetName)
Example
Variable=DataTable.AddSheet ("MySheet").AddParameter("Time", "8:00")
DeleteSheet Method
Deletes the specified sheet from the run-time Data Table.
Syntax
DataTable.DeleteSheet SheetID
The SheetID can be the sheet name or index. Index values begin with 1.
Example
DataTable.DeleteSheet "MySheet"
MySheet gets deleted from Data Table
Export Method
Saves a copy of the run-time Data Table in the specified location
Syntax
DataTable.Export(FileName)
Example:
DataTable.Export ("C:\flights.xls")
ExportSheet Method
Exports a specified sheet of the run-time Data Table to the specified file.
If the specified file does not exist, a new file is created and the specified sheet is saved.
If the current file exists, but the file does not contain a sheet with the specified sheet name, the sheet is inserted as the last sheet of the file.
If the current file exists and the file contains the specified sheet, the exported sheet overwrites the existing sheet.
Syntax:
DataTable.ExportSheet(FileName, DTSheet)
Example:
DataTable.ExportSheet "C:\name.xls" ,1
GetCurrentRowCount
Returns the current (active) row in the first sheet in the run-time Data Table
Syntax:
DataTable.GetCurrentRow
Example
row = DataTable.GetCurrentRow
Reporter.ReportEvent 1, "Row Number", row
GetRowCount Method
Returns the total number of rows in the longest column in the first sheet in the run-time Data Table
Syntax
DataTable.GetRowCount
Example:
rowcount = DataTable.GetSheet("MySheet").GetRowCount
Reporter.ReportEvent 2, "There are " &rowcount, "rows in the data sheet."
GetSheet Method
Returns the specified sheet from the run-time Data Table
Syntax
DataTable.GetSheet(SheetID)
Example
MyParam=DataTable.GetSheet ("MySheet").AddParameter("Time", "8:00")
GetSheetCount Method
Returns the total number of sheets in the run-time Data Table
Syntax
DataTable.GetSheetCount
Example
Sheetcount = DataTable.GetSheetCount
Import Method
Imports the specified Microsoft Excel file to the run-time Data Table.
Syntax
DataTable.Import(FileName)
Example
DataTable.Import ("C:\flights.xls")
ImportSheet Method
Imports a sheet of a specified file to a specified sheet in the run-time Data Table.
The data in the imported sheet replaces the data in the destination sheet
Syntax
DataTable.ImportSheet(FileName, SheetSource, SheetDest)
Example:
DataTable.ImportSheet "C:\name.xls" ,1 ,"name"
SetCurrentRow Method
Sets the specified row as the current (active) row in the run-time Data Table.
Syntax
DataTable.SetCurrentRow(RowNumber)
Example
DataTable.SetCurrentRow (2)
SetNextRow Method
Sets the row after the current (active) row as the new current row in the run-time Data Table.
Syntax
DataTable.SetNextRow
Example
DataTable.SetNextRow
SetPreRow Method
Sets the row above the current (active) row as the new current (active) row in the run-time Data Table.
Syntax
DataTable.SetPrevRow
Example
DataTable.SetPrevRow
Data Table Properties
GlobalSheetProperties
RawValueProperties
LocalSheetProperties
GlobalSheet Properties
Returns the first sheet in the run-time Data Table
Syntax
DataTable.GlobalSheet
Example
ParamValue=DataTable.GlobalSheet.AddParameter("Time", "5:45")
LocalSheet Properties
Returns the current (active) local sheet of the run-time Data Table.
Syntax:
DataTable.LocalSheet
Example
MyParam=DataTable.LocalSheet.AddParameter("Time", "5:45")
RawValue Property
Retrieves the raw value of the cell in the specified parameter and the current row of the run-time Data Table
Syntax
DataTable.RawValue ParameterID [, SheetID]
Example
FormulaVal=DataTable.RawValue ("Date","ActionA")
Value Property
This is a DataTable’s default property. It retrieves or sets the value of the cell in the specified parameter and the current row of the run-time Data Table
Syntax
DataTable.Value(ParameterID[,SheetID]) = NewValue
Example
DataTable.Value(“Destination”,”ActionA”) = “New York”
Name Property
Returns the name of the run-time data sheet
Syntax
DTSheet.Name
Example
SheetName = DataTable.LocalSheet.Name
The Data Table is a Microsoft Excelsheet with columns and rows representing the data
The Data Table contains one Global tab plus an additional tab for each action.
The Data Table assists you in parameterizing your test.
To view the Data Table, click the Data Table toolbar button
DataTable Parameters:
Data Table parameters enable you to create a data-driven test, component, or action that runs several times using the data you supply. In each iteration, QTP uses a different value from the Data Table
Data Table parameters enable you to create a data-driven test (or action) that runs several times using the data you supply. For each iteration, QTP uses a different value from the Data Table.
When Data Table is selected as the parameter type, the Parameter Options dialog box enables you to configure your parameter to use values from the Data Table.
The Global sheet contains the data that replaces parameters in each iteration of the test. If you create a Global parameter called Arrivals, the Global sheet might look like this:
During the run session, QTP creates a run-time Data Table associated with your test.It displays the run-time data in the Data Table pane so that any changes to the Data Table can be seen as they occur.The final data from the run-time Data Table is displayed in the Run-Time Data Table in the Test Results window
The Run-Time Data Table displays the parameterized values that were used, as well as any output values stored in the Data Table during the run.The Run-Time Data Table can be viewed from the Test results window.
Run Time Data Table Methods:
AddSheet Method
DeleteSheet Method
Export Method
ExportSheet Method
GetCurrentRow Method
GetRowCount Method
GetSheet Method
GetSheetCount Method
Import Method
ImportSheet Method
SetCurrentRow Method
SetNextRow Method
SetPrevRow Method
AddSheet Method
Adds the specified sheet to the run-time Data Table and returns the sheet so that properties can be directly set for the new sheet in the same statement.
Syntax:
DataTable.AddSheet(SheetName)
Example
Variable=DataTable.AddSheet ("MySheet").AddParameter("Time", "8:00")
DeleteSheet Method
Deletes the specified sheet from the run-time Data Table.
Syntax
DataTable.DeleteSheet SheetID
The SheetID can be the sheet name or index. Index values begin with 1.
Example
DataTable.DeleteSheet "MySheet"
MySheet gets deleted from Data Table
Export Method
Saves a copy of the run-time Data Table in the specified location
Syntax
DataTable.Export(FileName)
Example:
DataTable.Export ("C:\flights.xls")
ExportSheet Method
Exports a specified sheet of the run-time Data Table to the specified file.
If the specified file does not exist, a new file is created and the specified sheet is saved.
If the current file exists, but the file does not contain a sheet with the specified sheet name, the sheet is inserted as the last sheet of the file.
If the current file exists and the file contains the specified sheet, the exported sheet overwrites the existing sheet.
Syntax:
DataTable.ExportSheet(FileName, DTSheet)
Example:
DataTable.ExportSheet "C:\name.xls" ,1
GetCurrentRowCount
Returns the current (active) row in the first sheet in the run-time Data Table
Syntax:
DataTable.GetCurrentRow
Example
row = DataTable.GetCurrentRow
Reporter.ReportEvent 1, "Row Number", row
GetRowCount Method
Returns the total number of rows in the longest column in the first sheet in the run-time Data Table
Syntax
DataTable.GetRowCount
Example:
rowcount = DataTable.GetSheet("MySheet").GetRowCount
Reporter.ReportEvent 2, "There are " &rowcount, "rows in the data sheet."
GetSheet Method
Returns the specified sheet from the run-time Data Table
Syntax
DataTable.GetSheet(SheetID)
Example
MyParam=DataTable.GetSheet ("MySheet").AddParameter("Time", "8:00")
GetSheetCount Method
Returns the total number of sheets in the run-time Data Table
Syntax
DataTable.GetSheetCount
Example
Sheetcount = DataTable.GetSheetCount
Import Method
Imports the specified Microsoft Excel file to the run-time Data Table.
Syntax
DataTable.Import(FileName)
Example
DataTable.Import ("C:\flights.xls")
ImportSheet Method
Imports a sheet of a specified file to a specified sheet in the run-time Data Table.
The data in the imported sheet replaces the data in the destination sheet
Syntax
DataTable.ImportSheet(FileName, SheetSource, SheetDest)
Example:
DataTable.ImportSheet "C:\name.xls" ,1 ,"name"
SetCurrentRow Method
Sets the specified row as the current (active) row in the run-time Data Table.
Syntax
DataTable.SetCurrentRow(RowNumber)
Example
DataTable.SetCurrentRow (2)
SetNextRow Method
Sets the row after the current (active) row as the new current row in the run-time Data Table.
Syntax
DataTable.SetNextRow
Example
DataTable.SetNextRow
SetPreRow Method
Sets the row above the current (active) row as the new current (active) row in the run-time Data Table.
Syntax
DataTable.SetPrevRow
Example
DataTable.SetPrevRow
Data Table Properties
GlobalSheetProperties
RawValueProperties
LocalSheetProperties
GlobalSheet Properties
Returns the first sheet in the run-time Data Table
Syntax
DataTable.GlobalSheet
Example
ParamValue=DataTable.GlobalSheet.AddParameter("Time", "5:45")
LocalSheet Properties
Returns the current (active) local sheet of the run-time Data Table.
Syntax:
DataTable.LocalSheet
Example
MyParam=DataTable.LocalSheet.AddParameter("Time", "5:45")
RawValue Property
Retrieves the raw value of the cell in the specified parameter and the current row of the run-time Data Table
Syntax
DataTable.RawValue ParameterID [, SheetID]
Example
FormulaVal=DataTable.RawValue ("Date","ActionA")
Value Property
This is a DataTable’s default property. It retrieves or sets the value of the cell in the specified parameter and the current row of the run-time Data Table
Syntax
DataTable.Value(ParameterID[,SheetID]) = NewValue
Example
DataTable.Value(“Destination”,”ActionA”) = “New York”
Name Property
Returns the name of the run-time data sheet
Syntax
DTSheet.Name
Example
SheetName = DataTable.LocalSheet.Name
Wednesday, May 25, 2011
Object Repository
Object Repository is the collection of object properties used by QTP to identify the objects on the application .
Object repository is split into two components
1.Logical Name
2.Physical Description
Logical name is accomadated in script and repository to link script and repository.
Physical description is accomadated in repository to uniquely identify the objects.
Choosing the Object Repository Mode
The object repository per-action mode is easiest to use when you are creating simple record and run tests, especially under the following conditions
You have only one, or very few, tests that correspond to a given application, interface, or set of objects
You do not expect to frequently modify test object properties
You generally create single-action tests
The shared object repository mode is generally the preferred mode when:
You have several tests that test elements of the same application, interface, or set of objects
You expect the object properties in your application to change from time to time and/or you regularly need to update or modify test object properties
You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action options
When working in object repository per-action mode:
QuickTest creates a new (blank) object repository for each action
As you record operations on objects in your application, QuickTest automatically stores the information about those objects in the appropriate action object repository
When you create a new action, QuickTest creates another new object repository and again begins adding test objects to the repository as you record
When you record on the same object in your application in two different actions, the object is stored as a separate test object in each object repository
When you save your test, all of the action object repositories are automatically saved with the test as part of each action within the test. The action object repository is not accessible as a separate file (as is the shared object repository)
Updating Test Objects in Object Repository Per-Action Mode
Modifying the test object properties, values, or names in one object repository does not affect the information stored for the same test object in another object repository or in other tests
If you parameterize objects in one action, the parameterization applies only to the objects in that current action
Splitting and Copying Actions in Object Repository Per-Action Mode
When you split an action in your test while using the object repository per-action mode:
QuickTest makes a copy of the action object repository
The two actions have identical object repositories containing all of the objects that were in the original object repository
If you add objects to one of the split actions, the new objects are added only to the corresponding action object reposit
When you insert a copy of an action into your test:
The copied action's action object repository is copied along with the action steps
You can edit the object repository of the copied action as you would any other object repository in the test
Understanding the Shared Object Repository Mode
When working in shared object repository mode: QuickTest uses the same test object from the shared object repository file when you record on the same object in two different actions or in different tests or components.
QuickTest adds new objects to the object repository as you record steps on the object
QuickTest uses the existing information and does not add the object to the object repository if you record operations on an object that already exists in the shared object repository (i.e. the object has the same test object description)
QuickTest saves changes to the shared object repository file when you save your open test or component or when you click Save in the Object Repository dialog box if the shared object repository is not locked and/or opened in read-only mode
Updating Test Objects in Shared Object Repository Mode
Shared object repository mode enables you to:
Easily maintain your tests or components when an object in your application changes
Manage all the objects for a suite of tests or components in one central location
When you modify the test object properties, names, parameterization settings, and so forth, in your shared object repository for an open test or component, QuickTest applies the change to all the tests or components that use the same shared object repository file
Parameterizing Test Objects in Shared Object Repository Mode
When you parameterize an object property in a shared object repository, there are several issues you should consider:
When you parameterize an object property (with any type of parameter), the change applies to all tests or components that already contain that object
When you parameterize an object property that is part of an object's description, and then record on the object in your application again, QuickTest creates a new test object in the shared object repository. This is because the description of the object in the object repository is not identical to the one in the application
Renaming Objects in a Shared Object Repository
If you rename objects in a shared object repository in one test or component and save the changes, when you open another test or component using the same shared object repository, that test or component updates the object name in all steps of the test or component. This process may take a few moments. If you save the changes to the second test or component, the renamed steps are saved.
However, if you close the second test or component without saving, then the next time you open the same test or component, it will again take a few moments to update the object names in the test or component steps
Splitting and Copying Actions in Shared Object Repository Mode .
When you insert a copy of an action into a test that uses a shared object repository, keep in mind:
Only the action itself is copied and not its corresponding object repository.
The copied action will use the same shared object repository as the test into which it is being copied.
When you insert copies of actions from tests using a different shared object repository or per-action repository mode, you must ensure that all the objects contained in the action are in the test's shared object repository. If the action uses objects that are not in the shared object repository, the test may fail
Choose Test > Settings > Resources tab
In the Object repository type area, select Per-action or Shared
If you selected Shared, specify the shared object repository file you want to use as the object repository file. To specify a file, enter the object repository file name or click the browse button and select a resource file from the Open dialog box. To create a new shared object repository file, enter a new file name in the Shared box
If you want to make your selection the default setting for new tests, click Set as Default
Click OK to save and close the Test Settings dialog box
Setting the Object Repository Mode
Consider the following when setting a default shared object repository file:
Any existing or open tests or components will not be affected by setting a different, default shared object repository file
All new tests or components will attempt to access your default shared object repository
If the shared object repository file's path is relative, QuickTest searches for the shared object repository file in the current test's folder and then in the Folders tab of the Options dialog box
It is recommended that you ensure that the path for the shared object repository is absolute or listed in the Folders tab of the Options dialog box
If you choose to set a file with a relative path or one that is in the current test's folder as the default shared object repository, QuickTest may not be able to locate the file when creating a new test
If the default shared object repository file is in Quality Center, you must be connected to Quality Center when you create a new test
Object repository is split into two components
1.Logical Name
2.Physical Description
Logical name is accomadated in script and repository to link script and repository.
Physical description is accomadated in repository to uniquely identify the objects.
Choosing the Object Repository Mode
The object repository per-action mode is easiest to use when you are creating simple record and run tests, especially under the following conditions
You have only one, or very few, tests that correspond to a given application, interface, or set of objects
You do not expect to frequently modify test object properties
You generally create single-action tests
The shared object repository mode is generally the preferred mode when:
You have several tests that test elements of the same application, interface, or set of objects
You expect the object properties in your application to change from time to time and/or you regularly need to update or modify test object properties
You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action options
When working in object repository per-action mode:
QuickTest creates a new (blank) object repository for each action
As you record operations on objects in your application, QuickTest automatically stores the information about those objects in the appropriate action object repository
When you create a new action, QuickTest creates another new object repository and again begins adding test objects to the repository as you record
When you record on the same object in your application in two different actions, the object is stored as a separate test object in each object repository
When you save your test, all of the action object repositories are automatically saved with the test as part of each action within the test. The action object repository is not accessible as a separate file (as is the shared object repository)
Updating Test Objects in Object Repository Per-Action Mode
Modifying the test object properties, values, or names in one object repository does not affect the information stored for the same test object in another object repository or in other tests
If you parameterize objects in one action, the parameterization applies only to the objects in that current action
Splitting and Copying Actions in Object Repository Per-Action Mode
When you split an action in your test while using the object repository per-action mode:
QuickTest makes a copy of the action object repository
The two actions have identical object repositories containing all of the objects that were in the original object repository
If you add objects to one of the split actions, the new objects are added only to the corresponding action object reposit
When you insert a copy of an action into your test:
The copied action's action object repository is copied along with the action steps
You can edit the object repository of the copied action as you would any other object repository in the test
Understanding the Shared Object Repository Mode
When working in shared object repository mode: QuickTest uses the same test object from the shared object repository file when you record on the same object in two different actions or in different tests or components.
QuickTest adds new objects to the object repository as you record steps on the object
QuickTest uses the existing information and does not add the object to the object repository if you record operations on an object that already exists in the shared object repository (i.e. the object has the same test object description)
QuickTest saves changes to the shared object repository file when you save your open test or component or when you click Save in the Object Repository dialog box if the shared object repository is not locked and/or opened in read-only mode
Updating Test Objects in Shared Object Repository Mode
Shared object repository mode enables you to:
Easily maintain your tests or components when an object in your application changes
Manage all the objects for a suite of tests or components in one central location
When you modify the test object properties, names, parameterization settings, and so forth, in your shared object repository for an open test or component, QuickTest applies the change to all the tests or components that use the same shared object repository file
Parameterizing Test Objects in Shared Object Repository Mode
When you parameterize an object property in a shared object repository, there are several issues you should consider:
When you parameterize an object property (with any type of parameter), the change applies to all tests or components that already contain that object
When you parameterize an object property that is part of an object's description, and then record on the object in your application again, QuickTest creates a new test object in the shared object repository. This is because the description of the object in the object repository is not identical to the one in the application
Renaming Objects in a Shared Object Repository
If you rename objects in a shared object repository in one test or component and save the changes, when you open another test or component using the same shared object repository, that test or component updates the object name in all steps of the test or component. This process may take a few moments. If you save the changes to the second test or component, the renamed steps are saved.
However, if you close the second test or component without saving, then the next time you open the same test or component, it will again take a few moments to update the object names in the test or component steps
Splitting and Copying Actions in Shared Object Repository Mode .
When you insert a copy of an action into a test that uses a shared object repository, keep in mind:
Only the action itself is copied and not its corresponding object repository.
The copied action will use the same shared object repository as the test into which it is being copied.
When you insert copies of actions from tests using a different shared object repository or per-action repository mode, you must ensure that all the objects contained in the action are in the test's shared object repository. If the action uses objects that are not in the shared object repository, the test may fail
Choose Test > Settings > Resources tab
In the Object repository type area, select Per-action or Shared
If you selected Shared, specify the shared object repository file you want to use as the object repository file. To specify a file, enter the object repository file name or click the browse button and select a resource file from the Open dialog box. To create a new shared object repository file, enter a new file name in the Shared box
If you want to make your selection the default setting for new tests, click Set as Default
Click OK to save and close the Test Settings dialog box
Setting the Object Repository Mode
Consider the following when setting a default shared object repository file:
Any existing or open tests or components will not be affected by setting a different, default shared object repository file
All new tests or components will attempt to access your default shared object repository
If the shared object repository file's path is relative, QuickTest searches for the shared object repository file in the current test's folder and then in the Folders tab of the Options dialog box
It is recommended that you ensure that the path for the shared object repository is absolute or listed in the Folders tab of the Options dialog box
If you choose to set a file with a relative path or one that is in the current test's folder as the default shared object repository, QuickTest may not be able to locate the file when creating a new test
If the default shared object repository file is in Quality Center, you must be connected to Quality Center when you create a new test
Sunday, May 22, 2011
Introduction To QTP
QUICK TEST PROFESSIONAL
A powerful functional and regression testing automation tool designed by mercury interactive.
QTP is easier to use and implement for both technical and non technical tester in comparison to other testing tools available in the market.
QTP uses VBScript as a scripting language , which is very easy to learn and use and implement the logics.
Environments supported
Windows Applications
(MFC)
Visual Basic
.Net
J2EE
XML
Java
ActiveX
Web Technologies
HTML
DHTML
JavaScript
Enterprise Applications
SAP
Oracle
PeopleSoft
Siebel
Browser Supported
IE
Netscape
AOL
Operating System
Windows XP
Windows 2K
Windows 98
Windows NT
Windows ME
A powerful functional and regression testing automation tool designed by mercury interactive.
QTP is easier to use and implement for both technical and non technical tester in comparison to other testing tools available in the market.
QTP uses VBScript as a scripting language , which is very easy to learn and use and implement the logics.
Environments supported
Windows Applications
(MFC)
Visual Basic
.Net
J2EE
XML
Java
ActiveX
Web Technologies
HTML
DHTML
JavaScript
Enterprise Applications
SAP
Oracle
PeopleSoft
Siebel
Browser Supported
IE
Netscape
AOL
Operating System
Windows XP
Windows 2K
Windows 98
Windows NT
Windows ME
Introduction To Automation Testing
1.Limitaions Of manual testing
a.Time consuming.
b.Chances of making mistakes when doing repatative work.
c.Require more human resources.
2.Advantages of automation tools
a.Faster test execution
b.Reliable
c.Repeatability
d.Progmamming capability
e.Reusability
3.Test cases to be automated
a.Tests that needs to be run for every build of the application(Sanity test and regression test)
b.Tests that use multiple data for same actions.
c.Load/Stress testing
More Repeatative Execution ! Better Candidates for Automation.
4.Tests cases not to be automated
a.Usability testing
b.One time testing
c.ASAP testing
d.Adhoc/Random testing
a.Time consuming.
b.Chances of making mistakes when doing repatative work.
c.Require more human resources.
2.Advantages of automation tools
a.Faster test execution
b.Reliable
c.Repeatability
d.Progmamming capability
e.Reusability
3.Test cases to be automated
a.Tests that needs to be run for every build of the application(Sanity test and regression test)
b.Tests that use multiple data for same actions.
c.Load/Stress testing
More Repeatative Execution ! Better Candidates for Automation.
4.Tests cases not to be automated
a.Usability testing
b.One time testing
c.ASAP testing
d.Adhoc/Random testing
Wednesday, May 11, 2011
Tracebility Matrix
Traceability matrix is used to map between requirements and test cases.It is used to check all requirements are tested or not?.A document showing the relation between test requirement and test case.To check whether the testcases are mapped with the requirement.
Suppose a requirement contains 100 requiremets , then we should have atleast one testcase to veryfy each and every requirement , this is called farward tracebility.
If you trace back from test case to requirement ,all test case should point to atleast one requirement this is called backword tracibility.
There should not be any requirement without any test cases and there should not be any test case which is not pointed to some requirement.
The content of the tracibility matrix looks like the below image ...
Suppose a requirement contains 100 requiremets , then we should have atleast one testcase to veryfy each and every requirement , this is called farward tracebility.
If you trace back from test case to requirement ,all test case should point to atleast one requirement this is called backword tracibility.
There should not be any requirement without any test cases and there should not be any test case which is not pointed to some requirement.
The content of the tracibility matrix looks like the below image ...
Wednesday, April 27, 2011
Testing Types
There are different types testing done for different accation and for diffrerent purpose .Broadly classifying the entire testing activities ,there are mainly two types
1.White box testing
2.Black box testing
Black box testing:
Functional Testing based on the requirements with no knowledge of internal program structure or data .Also know as closed box testing.
Eg - All testing types done in system testing level by testers are black box testing .
Sanity testing ,Regression testing , Alpha testing ,Beeta testing etc.
White box testing:
White box testing is performed based on the knowledge of how the system is implemented. White box testing includes analyzing data flow, control flow, information flow, coding practices, and exception and error handling within the system, to test the intended and unintended software behavior. White box testing can be performed to validate whether code implementation follows intended design, to validate implemented security functionality, and to uncover exploitable vulnerabilities.
Also known as Open box testing ,Glass box testing
Eg-Unit testing
Gray box testing:
Grey box testing is the combination of black box and white box testing. Intention of this testing is to find out defects related to bad design or bad implementation of the system.
Eg-Integration testing
Sanity Testing:
The initial level of testing to make sure that basic/primary feature are there and working properly to start with the detailed level of testing.Sanity testing is done when the application is deployed into testing for the very first time .
Eg: Open URL and login ,navigate and check all menus and fields and buttons are there in place.
Try one or two very basic transactions.
Smoke Testing:
Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. Done especially during hardware upgradations.
Functional Testing:
Its a blackbox testing done in a system testing level to verify the functionality of the pplication .Functionality testing is performed to verify that a software application performs and functions correctly according to design specifications.
Regression Testing:
Testing that is performed after making a functional improvement or repair to the program. Its purpose is to determine if the change has regressed other aspects of the program.
Retesting :
Testing application with different inputs is normally known as retesting .Executing the same test case with different inputs .
Security Testing:
Testing how well system protects the unauthorised access , the primary aspects of security testing are authentication and authorisation
Authentication:First level of security testing to decide whether user is a valid user ,normally this can be done by testing the login requirement ie username and password.
Authorisation:This is next level of security where users are testing for their access rights ,this can be tested by creating different users with different access rights and login and verify their access rights .
Installation Testing :
Installation is the first interaction of user with our product and it is very important to make sure that user do not have any trouble in installing the software.
Usually installers ask a series of questions and based on the response of the user, installation changes. It is always a good idea to create a Tree structure of all the options available to the user and cover all unique paths of installation if possible.
Person performing installation testing, should certainly have information on what to expect after installation is done. Tools to compare file system, registry. DLLs etc are very handy in making sure that installation is proper.
Most of the installers support the functionality of silent installation, this also need thorough testing. Main thing to look for here is the config file that it uses for installation. Any changes made in the config file should have proper effect on the installation.
If installation is dependent on some other components like database, server etc. test cases should be written specifically to address this.
Negative cases like insufficient memory, insufficient space, aborted installation should also be covered as part of installation testing. Test engineer should make sure that proper messages are given to the user and installation can continue after increasing memory, space etc.
Test engineer should be familiar with the installer technologies and if possible try to explore the defects or limitation of the installer itself.
Recovery Testing:
Recovery testing is the forced failure of the software in a variety of ways to verify that recovery is properly performed.Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc.Type or extent of recovery is specified in the requirement specifications. It is basically testing how well a system recovers from crashes, hardware failures, or other catastrophic problems
Examples of recovery testing:
While an application is running, suddenly restart the computer, and afterwards check the validness of the application's data integrity.
While an application is receiving data from a network, unplug the connecting cable. After some time, plug the cable back in and analyze the application's ability to continue receiving data from the point at which the network connection disappeared.
Restart the system while a browser has a definite number of sessions. Afterwards, check that the browser is able to recover all of them.
Performance Testing:
Testing the application behaviour like reponse time under various load is known as performance testing.
Load Testing:
Testing application behaviour with defined load is known as load testing
Stress Testing:
Testing the application behaviour with behind the defined load is known as stress testing
Volume Testing :
Volume testing is done against the efficiency of the application. Huge amount of data is processed through the application (which is being tested) in order to check the extreme limitations of the system
Volume Testing, as its name implies, is testing that purposely subjects a system (both hardware and software) to a series of tests where the volume of data being processed is the subject of the test. Such systems can be transactions processing systems capturing real time sales or could be database updates and or data retrieval.
User Acceptance Testing:
Formal tests (often performed by a customer) to determine whether or not a system has satisfied predetermined acceptance criteria. These tests are often used to enable the customer (either internal r external) to determine whether or not to accept a system.
Alpha Testing :
If the testers and real customers combinedly test the software in development site then it is called alpha testing.
Beta Testing :
If the testers and model customers combinedly test the software in customer site,then it is called beta
testing.
Adhoc Testing:
Testing done by testing team/non testing team as a end user without using any testplan and test cases covering the very basic scenario. The tester tries to 'break' the system by randomly trying the system's functionality.
Monkey Testing :
Kind of adhoc testing done specially on game softwares to test the software ,here tester acts as a monkey and tries to break the software .
Localization Testing:
Testing software ability to adapt to local standards like local language , interface and voice etc.
1.White box testing
2.Black box testing
Black box testing:
Functional Testing based on the requirements with no knowledge of internal program structure or data .Also know as closed box testing.
Eg - All testing types done in system testing level by testers are black box testing .
Sanity testing ,Regression testing , Alpha testing ,Beeta testing etc.
White box testing:
White box testing is performed based on the knowledge of how the system is implemented. White box testing includes analyzing data flow, control flow, information flow, coding practices, and exception and error handling within the system, to test the intended and unintended software behavior. White box testing can be performed to validate whether code implementation follows intended design, to validate implemented security functionality, and to uncover exploitable vulnerabilities.
Also known as Open box testing ,Glass box testing
Eg-Unit testing
Gray box testing:
Grey box testing is the combination of black box and white box testing. Intention of this testing is to find out defects related to bad design or bad implementation of the system.
Eg-Integration testing
Sanity Testing:
The initial level of testing to make sure that basic/primary feature are there and working properly to start with the detailed level of testing.Sanity testing is done when the application is deployed into testing for the very first time .
Eg: Open URL and login ,navigate and check all menus and fields and buttons are there in place.
Try one or two very basic transactions.
Smoke Testing:
Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. Done especially during hardware upgradations.
Functional Testing:
Its a blackbox testing done in a system testing level to verify the functionality of the pplication .Functionality testing is performed to verify that a software application performs and functions correctly according to design specifications.
Regression Testing:
Testing that is performed after making a functional improvement or repair to the program. Its purpose is to determine if the change has regressed other aspects of the program.
Testing conducted for the purpose of evaluating whether or not a change to the system has introduced a new failure. Regression testing is often accomplished through the construction, execution and analysis of product and system tests.
Retesting :
Testing application with different inputs is normally known as retesting .Executing the same test case with different inputs .
Security Testing:
Testing how well system protects the unauthorised access , the primary aspects of security testing are authentication and authorisation
Authentication:First level of security testing to decide whether user is a valid user ,normally this can be done by testing the login requirement ie username and password.
Authorisation:This is next level of security where users are testing for their access rights ,this can be tested by creating different users with different access rights and login and verify their access rights .
Installation Testing :
Installation is the first interaction of user with our product and it is very important to make sure that user do not have any trouble in installing the software.
Usually installers ask a series of questions and based on the response of the user, installation changes. It is always a good idea to create a Tree structure of all the options available to the user and cover all unique paths of installation if possible.
Person performing installation testing, should certainly have information on what to expect after installation is done. Tools to compare file system, registry. DLLs etc are very handy in making sure that installation is proper.
Most of the installers support the functionality of silent installation, this also need thorough testing. Main thing to look for here is the config file that it uses for installation. Any changes made in the config file should have proper effect on the installation.
If installation is dependent on some other components like database, server etc. test cases should be written specifically to address this.
Negative cases like insufficient memory, insufficient space, aborted installation should also be covered as part of installation testing. Test engineer should make sure that proper messages are given to the user and installation can continue after increasing memory, space etc.
Test engineer should be familiar with the installer technologies and if possible try to explore the defects or limitation of the installer itself.
Recovery Testing:
Recovery testing is the forced failure of the software in a variety of ways to verify that recovery is properly performed.Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc.Type or extent of recovery is specified in the requirement specifications. It is basically testing how well a system recovers from crashes, hardware failures, or other catastrophic problems
Examples of recovery testing:
While an application is running, suddenly restart the computer, and afterwards check the validness of the application's data integrity.
While an application is receiving data from a network, unplug the connecting cable. After some time, plug the cable back in and analyze the application's ability to continue receiving data from the point at which the network connection disappeared.
Restart the system while a browser has a definite number of sessions. Afterwards, check that the browser is able to recover all of them.
Performance Testing:
Testing the application behaviour like reponse time under various load is known as performance testing.
Load Testing:
Testing application behaviour with defined load is known as load testing
Stress Testing:
Testing the application behaviour with behind the defined load is known as stress testing
Volume Testing :
Volume testing is done against the efficiency of the application. Huge amount of data is processed through the application (which is being tested) in order to check the extreme limitations of the system
Volume Testing, as its name implies, is testing that purposely subjects a system (both hardware and software) to a series of tests where the volume of data being processed is the subject of the test. Such systems can be transactions processing systems capturing real time sales or could be database updates and or data retrieval.
User Acceptance Testing:
Formal tests (often performed by a customer) to determine whether or not a system has satisfied predetermined acceptance criteria. These tests are often used to enable the customer (either internal r external) to determine whether or not to accept a system.
Alpha Testing :
If the testers and real customers combinedly test the software in development site then it is called alpha testing.
Beta Testing :
If the testers and model customers combinedly test the software in customer site,then it is called beta
testing.
Adhoc Testing:
Testing done by testing team/non testing team as a end user without using any testplan and test cases covering the very basic scenario. The tester tries to 'break' the system by randomly trying the system's functionality.
Monkey Testing :
Kind of adhoc testing done specially on game softwares to test the software ,here tester acts as a monkey and tries to break the software .
Localization Testing:
Testing software ability to adapt to local standards like local language , interface and voice etc.
Monday, April 25, 2011
Quality
What is Quality?
Quality is an abstract term , like many other abstract things in life viz music , beauty etc . We can’t define Quality but we can say that the product is of high quality or not.
Quality : Degree of conformance of the product features to its requirements. If, the degree of conformance is high we can say that the product is of high quality.
Quality is a function of user-satisfaction . Again, user-satisfaction depends upon many factors like
conforming product , delivered within budget and
schedule etc
Quality On Time :
Delivering the product on or before the delivery date of the product is known as Quality on Time .
Quality of Conformance :
Delivering the right product( conforming product ) is termed as Quality of conformance.
Quality Goal : Quality of conformance + Quality on Time.
Delivering the right product at the right time is the Ultimate Quality Goal .
Requirement:
Requirements can be of three types:
Explicit Requirements : These are user needs
and expectations of the product , explicitly stated by the customer.
Implicit Requirements : These requirements are often not stated by the customer due to his technical unawareness . These are to be taken care of the technical people in the organization .
Obligatory Requirements : Mandatory requirements
Imposed rules and regulations on the product by some government bodies , authorities etc.
Cost of Non Confirmance:
All costs in occured by repairing or reworking the Non-Confirming the product.
Impact of defect on the cost in the SDLC
Quality assurance :
Set of umbrella activities that must be applied throughout the software process to assure that the product coming out is of high quality.
In Quality Assurance we will check the process to ensure Quality .
Assurance activities can be broadly classified into
Assuring Process Quality
Assuring Product Quality – Quality Control .
Example of software quality assurance activities
In Quality Control we will check and test the product .
Examples of Quality Control processes are
Testing , code reviews and document reviews.
Demine Cycle:
According to Deming , continual improvement of an organization on a regular basis , can be achieved by P-D-C-A cycle. By , P-D-C-A cycle we mean Plan-Do-Check-Act .
Effectiveness :
• Extent to which planned activities are realized and planned results are achieved.
• To check the effectiveness we have to evaluate based on Analysis of DATA .
Improvement of the QMS
The organization shall continually improve the effectiveness of the quality management system through the use of the quality policy, quality objectives, audit results, analysis of data, corrective and preventive actions and management review.
Quality Management Principles :
• These principles are derived and developed by ISO Technical Committee ( ISO/TC 176 ). These
principles are often used by the senior management as a framework to guide the organization towards continual improvement in the performance.These 8 principles are defined in ISO 9000:2000 QMS Fundamentals .
Principle 1 : Customer Focus
• Organizations depend on their customers and therefore should understand current and future customer needs and expectations. The Organization should meet customer expectations and strive to exceed their expectations.
Principle 2 : Leadership
Leaders establish unity of purpose and unity of direction to the organization They should create an internal environment so that people can become fully involved in achieving the organization's objective.
Principle 3: Process oriented approachPrinciple 4: Involvement of people
• Process is set of pre-defined actions or activities ( set of framework activities ) to produce a product.( its a road map whose goal is ultimate production of the product) .
Principle 4: Involvement of people
• People at all levels are the essence of the organization and their full involvement enables their abilities to be useful for the organization's benefit.
Principle 5 : System approach to Management
System is group of related things or parts that function together as a whole.System may consists of one or more processes.
Interrelated processes are identified , understood and managed as a system . This improves the organization's effectiveness and efficiency.
Principle 6: Continual improvement
• Continual improvement should be a permanent objective of the organization.
Quality is an abstract term , like many other abstract things in life viz music , beauty etc . We can’t define Quality but we can say that the product is of high quality or not.
Quality : Degree of conformance of the product features to its requirements. If, the degree of conformance is high we can say that the product is of high quality.
Quality is a function of user-satisfaction . Again, user-satisfaction depends upon many factors like
conforming product , delivered within budget and
schedule etc
Quality On Time :
Delivering the product on or before the delivery date of the product is known as Quality on Time .
Quality of Conformance :
Delivering the right product( conforming product ) is termed as Quality of conformance.
Quality Goal : Quality of conformance + Quality on Time.
Delivering the right product at the right time is the Ultimate Quality Goal .
Requirement:
Requirements can be of three types:
Explicit Requirements : These are user needs
and expectations of the product , explicitly stated by the customer.
Implicit Requirements : These requirements are often not stated by the customer due to his technical unawareness . These are to be taken care of the technical people in the organization .
Obligatory Requirements : Mandatory requirements
Imposed rules and regulations on the product by some government bodies , authorities etc.
Cost of Non Confirmance:
All costs in occured by repairing or reworking the Non-Confirming the product.
Impact of defect on the cost in the SDLC
Set of umbrella activities that must be applied throughout the software process to assure that the product coming out is of high quality.
In Quality Assurance we will check the process to ensure Quality .
Assurance activities can be broadly classified into
Assuring Process Quality
Assuring Product Quality – Quality Control .
Example of software quality assurance activities
Internal Quality Audits / Configuration Audits / Supplier Audits / Formal Technical Reviews etc..
Quality Control :
• Checking , inspecting and reviewing the product itself whether it is conforming to its requirements or not.
In Quality Control we will check and test the product .
Examples of Quality Control processes are
Testing , code reviews and document reviews.
Demine Cycle:
According to Deming , continual improvement of an organization on a regular basis , can be achieved by P-D-C-A cycle. By , P-D-C-A cycle we mean Plan-Do-Check-Act .
Effectiveness :
• Extent to which planned activities are realized and planned results are achieved.
• To check the effectiveness we have to evaluate based on Analysis of DATA .
Improvement of the QMS
The organization shall continually improve the effectiveness of the quality management system through the use of the quality policy, quality objectives, audit results, analysis of data, corrective and preventive actions and management review.
Quality Management Principles :
• These principles are derived and developed by ISO Technical Committee ( ISO/TC 176 ). These
principles are often used by the senior management as a framework to guide the organization towards continual improvement in the performance.These 8 principles are defined in ISO 9000:2000 QMS Fundamentals .
Principle 1 : Customer Focus
• Organizations depend on their customers and therefore should understand current and future customer needs and expectations. The Organization should meet customer expectations and strive to exceed their expectations.
Principle 2 : Leadership
Leaders establish unity of purpose and unity of direction to the organization They should create an internal environment so that people can become fully involved in achieving the organization's objective.
Principle 3: Process oriented approachPrinciple 4: Involvement of people
• Process is set of pre-defined actions or activities ( set of framework activities ) to produce a product.( its a road map whose goal is ultimate production of the product) .
Principle 4: Involvement of people
• People at all levels are the essence of the organization and their full involvement enables their abilities to be useful for the organization's benefit.
Principle 5 : System approach to Management
System is group of related things or parts that function together as a whole.System may consists of one or more processes.
Interrelated processes are identified , understood and managed as a system . This improves the organization's effectiveness and efficiency.
Principle 6: Continual improvement
• Continual improvement should be a permanent objective of the organization.
Subscribe to:
Posts (Atom)