Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Articles On Testing

Wecome to http://www.articlesontesting.com !!!

Dynamically declare an array in VBScript

How to define an array dynamically in VbScript ?

Dim i,j
i= Inputbox("Enter array's dimension First one")

j= Inputbox("Enter array's dimension Second one")

i=Cint(i)
j=Cint(j)
These lines just convert the datatype by converting the data values from string type to integer type, simply because the Inputbox always returns data as string.

'The below definition does not work.
'Just because Vbscript does not have the feature to dynamically declare an array size
Dim array(i,j)

However the same can be attained by below line of code

Redim array(i,j)
What it does is redefine the array size at run time.
Just comment the earlier declaration.

Run Action Statement in QTP


              The RunAction statement can run only actions that are already associated with your test as part of the test flow. Therefore, in order to enter a RunAction statement in the Expert View for an external action, you must first insert a call to the action (Insert > Call to Action) or copy the external action (Insert > Copy of Action) into your test. Using this option associates the action with the test and also inserts a RunAction statement for you. After the the external action is added to the test flow, you can add additional calls to that external action in the Expert View.
If you insert a RunAction statement in the Expert View for an external action that is not already associated with your test as a part of the test flow, the RunAction statement fails. For more information on copying or calling external actions.

Syntax

RunAction ActionName, [Iteration , Parameters]


Argument

Type

Description

ActionName

String

The name of the action.

Iteration

Variant

Optional.

-- oneIteration or 0 (Default)—Runs the action only once, using the row in the action's data sheet that corresponds to the global data sheet iteration counter.

If the action's data sheet contains fewer rows than the global sheet, the last row of the action's data sheet will be used for each subsequent iteration.

-- allIterations or 1—Runs iterations on all rows.

-- iteration row range (for example, "1-7")—Indicates the rows for which action iterations will be performed

Note: Iteration is required when calling an external action, but optional when calling a local action (from within the test).

Parameters

Variant

Optional.

The values and storage locations for the called action's input and output parameters. Input parameters are listed before output parameters.

For an input parameter, specify either a fixed value or the name of another defined parameter (Data Table parameter, environment parameter, or an action input parameter of the calling action) from which the argument should take its value.

For an output parameter, specify either a variable in which you want to store the value or the name of a defined parameter (Data Table parameter, environment parameter, or an action output parameter of the calling action).

Return Value

Variant.

If the action called by the RunAction statement includes an ExitAction statement, the RunAction statement can return the value of the ExitAction's RetVal argument. For more information, see ExitAction Statement.

Examples

The following example calls the SearchFlight action, and runs all iterations of the action.

RunAction "SearchFlight", allIterations

The following example performs the same call as the previous example, but runs only one iteration of the action and saves the returned value to the AxnVal variable.

AxnVal=RunAction ("SearchFlight", oneIteration)

The following example runs one iteration of the action, supplies a string value of MyValue for the input parameter, and stores the resulting value of the output parameter in a variable called MyVariable.

RunAction "Action2", oneIteration, "MyValue", MyVariable


For gaining more insights in the automation using QTP log on to below url :

Automation Testing Using QTP


 

Setting Properties for an External Action


 Setting Properties for an External Action :

When you insert a call to an external action, you can choose where you want QTP to store the Data Table data. You can specify this in the External Action tab of the Action Properties dialog box.
To open the Action Properties dialog box, right-click an action in the Test Flow pane and select Action Properties, or select Edit > Action > Action Properties

The External Action tab includes the following options :

Option
Description
Data Table parameters
Indicates where to store the action's Data Table data:
  • To use the original action's data, select Use data stored with the original action (read-only). If you select this option, the data is read-only when viewed from the calling test, and all changes to the original action's data sheet apply when the action runs in the calling test.
  • To use an editable copy of the data in the test's Data Table, select Use a local, editable copy. If you select this option, a copy of the called action's data sheet is added to the calling test's Data Table and is independent of the original action.
Changes to the original action's data sheet do not affect the calling test even if you insert another call to this action after the action's data sheet is modified.
If the called action has parameterized steps that rely on new information in the original action's data sheet, enter the relevant column names and required data to the action sheet in the calling test manually. 

Note: When you call an external action, the global data sheet columns and data from the called action's test are always imported as a local, editable copy in the calling test's global data sheet.
Changes to the original action's global data sheet do not affect the calling test even if you insert another call to this action after the called action's global data sheet is modified.
If the called action has parameterized steps that rely on new information in the global data sheet, enter the relevant column names and required data to the calling test's global data sheet manually.

 Viewing a List of the Tests and Actions Using this Action:

If your tests are stored in Quality Center and are using the resources and dependencies model, the Action Properties dialog box displays the Used By tab. This enables you to view a list of the tests and actions that contain calls to this particular action. This is the same list that is displayed in the Dependencies tab of the Test Plan module in Quality Center. 

 To open the Action Properties dialog box, right-click an action in the Test Flow pane and select Action Properties, or select Edit > Action > Action Properties

The Used By tab includes the following options:
 Option
Description
Test
Indicates the Quality Center path of the test containing a call to this action.
Action
Indicates the internal name of the action containing a call to this action. The internal name is the name that QTP applies to an action by default when the action is created, for example, Action 1. The internal name of the action calling this action is displayed even if the calling action was renamed.

For gaining more insights in the automation using QTP log on to below url :

Automation Testing Using QTP

Setting Action Properties In QTP



Setting General Action Properties:

 You can use the General tab of the Action Properties dialog box to modify the name of an action, add or edit an action's description, or change the reusability status of the action. 

 To open the Action Properties dialog box, right-click an action in the Test Flow pane and select Action Properties, or select Edit > Action > Action Properties

 Note: The name of the action and its path are displayed in the tab. If it was defined with a relative path in QTP, then the path is displayed as .\. If the action is a reusable action or an external action, then Reusable action or External Action is displayed next to the action name. 

The General tab includes the following options:
Option
Description
Name
The name of the action. By default, the action name is the internal name provided by QTP, such as Action 1. This number is incremented by 1 for each new action that is added to the test.
You can rename the action, as needed. The action name must be unique (within the test), cannot begin or end with a space, cannot exceed 1023 characters, and cannot contain the following characters:   \ / : * ? " < > | % ' ! { }
Location
The folder or Quality Center path where the action is stored.
Description
You can insert comments about the action. An action description helps you and other testers know what a specific action does without reviewing all the steps in the action. The description is also displayed in the description area of the Select Action dialog box. This enables you and other testers to determine which action you want to call or copy from another test without having to open it.

Note: You can also add a description when inserting a call to a new action.
Reusable action
Indicates whether the action is a reusable action. By default, this check box is selected. A reusable action can be called multiple times within a test and can be called from other tests. Non-reusable actions can be copied and inserted as independent actions, but cannot be inserted as calls to the original action.
When you change this setting, the action icon changes to a non-reusable action icon or reusable action icon as appropriate. If the steps of the action were expanded, they collapse after changing a non-reusable action to a reusable action. You can view the steps of the reusable action by selecting the action name in the Test Flow pane.

Notes:
·  If the action is called more than once within the test flow or if the action is called by a reusable action, the Reusable action option is read-only. If you want to make the action non-reusable, remove the additional calls to the action from the test. 

·  You cannot expand reusable actions from the test flow view. You can view details of a reusable action by double-clicking the action in the Keyword View, or selecting the action from the Action List. For more information on the test flow and action views, see Using the Action Toolbar in the Keyword View.

For gaining more insights in the automation using QTP log on to below url :

Automation Testing Using QTP

Action Properties In QTP

What are Action properties in QTP?

The Action Properties dialog box enables you to define options for the stored action. These settings apply each time the action is called. You can modify an action name, add or modify an action description, and set an action as reusable or non-reusable. For an external action, you can set the Data Table definitions.
The Action Properties dialog box also enables you to define input and output parameters to be used by the action, and specify the object repositories that are associated with the action. For more information, see Associating Object Repositories with Actions.

Note: The following sections describe how to define action properties using the Action Properties dialog box. You can also define actions and action parameters in the Expert View.

You can open the Action Properties dialog box while working with your test by:
  • Right-clicking an action node in the Test Flow pane and selecting Action Properties.
  • Choosing Edit > Action > Action Properties when an action node is highlighted in the Keyword View or displayed in the Expert View.
  • Right-clicking an action node in the Keyword View and selecting Action Properties.
The Action Properties dialog box always contains the General tab, the Parameters tab, the Associated Repositories tab, and the Used By tab:
Note: In addition to the tabs shown above, the Action Properties dialog box for a called external action also contains an External Action tab, and the other tabs are read-only.

For gaining more insights in the automation using QTP log on to below url :

Automation Testing Using QTP


Mercury.Devicereplay Method in QTP




Mercury.DeviceReplay  And Presskey method in QTP :

Set obj = CreateObject("Mercury.DeviceReplay")
Window("Notepad").Activate
obj.PressKey 63 

The PressKey method uses the ASCII value for the key.

63 is the ASCII value for F5.
ASCII values for other keys:
F1 - 59
F2 - 60
F3 - 61
F4 - 62
F5 - 63
F6 - 64
F7 - 65
F8 - 66
F9 - 67
F10 - 68
F11 - 87
F12 – 88


For gaining more insights in the automation using QTP log on to below url :

Automation Testing Using QTP


Count Pages In Pdf File


How :  To count number of pages in a pdf file using VbScript.

Function PageCountInPDFFile(strFile)
    Dim pdfFile, objAcroapp, objPdf
    'Create Automation Objects using VbScript for PDF Operations
    Set objAcroapp = CreateObject("AcroExch.App")
    Set objPdf = CreateObject("AcroExch.PDDoc")
    objPdf.Open strFile,"temp"
    Set pdfFile = objPdf.GetPDDoc
    GetPDFPageCount = pdfFile.GetNumPages
    Set pdffile = nothing
    objAcroapp.Exit
End Function


For gaining more insights in the automation using QTP log on to below url :

Automation Testing Using QTP


Multiple UiTest Files in VSTS CodedUi Testing

How to create Multiple UiTset files in a  CodedUi Test Project?

 The logically inter related blocks of modules within a System Under Test can be automated in a modularized  block of code, in the following outlined manner. for our case we will just have a look at how we have create three different Uitest files. 

The first UiTest file is AllLink.uitest file, which is actually a xml file, and its two components are namely , AllLink.cs and AllLink.designer.cs file. The designer file is non editable file which incorporates all the recorded set of scripts in it. The AllLink.cs file is again a partial class file which is used for more of data overriding and code globalisation along with reusability.

The second UiTest file is UsrIntrfc.uitest file, which is actually a xml file, and its two components are namely ,  UsrIntrfc.cs and  UsrIntrfc.designer.cs file. The designer file is non editable file which incorporates all the recorded set of scripts in it. The  UsrIntrfc.cs file is again a partial class file which is used for more of data overriding and code globalisation along with reusability.


The third  UiTest file is MsgValidatn.uitest file, which is actually a xml file, and its two components are namely ,  MsgValidatn.cs and  MsgValidatn.designer.cs file. The designer file is non editable file which incorporates all the recorded set of scripts in it. The  MsgValidatn.cs file is again a partial class file which is used for more of data overriding and code globalisation along with reusability.

The approach for recording the various functions outlined as under has thus been classified into three specific categories, namely clicking the links, doing the functional event, and finally validating the final event of functionality being successful.

The AllLink uitest file is actually an xml file having the events related to clicking the links, similarly UsrIntrfc is the functional event, MsgValdtn is the validation checkpoint also called the assertion point in VSTS as termed in QTP automation.

At last we have  one class file wherein , we will bring into use all three events from three uitest files and create a standard framework for automating with minimal rework effort.
Just have a look at the snapshot below to gain insights into how we arrange the multiple uitst files :

As outlined in the code below, we create an instance of all three uitest files, and utilize the features available as per the record time in them.

using System;
using System.Collections.Generic;
using System.Text.RegularExpressions;
using System.Windows.Input;
using System.Windows.Forms;
using System.Drawing;
using Microsoft.VisualStudio.TestTools.UITesting;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UITest.Extension;
using Keyboard = Microsoft.VisualStudio.TestTools.UITesting.Keyboard;
using multipleuimaps.Uimaps.AllLinkClasses;
using multipleuimaps.UIAssertions.UsrIntrfcClasses;
using multipleuimaps.MsgValdtn.MsgValdtnClasses;

namespace multipleuimaps.Uimaps.AllLinkClasses
{
    ///


    /// Summary description for CodedUITest1
    ///
    [CodedUITest]
    public class UploadValidation
    {
        public UploadValidation()
        {
        }

        [TestMethod]
        public void UploadValidationTestMethod1()
        {
            // To generate code for this test, select "Generate Code for Coded UI Test" from the shortcut menu and select one of the menu items.
            // For more information on generated code, see http://go.microsoft.com/fwlink/?LinkId=179463

            this.AllLink.ClkDocLink();
            this.UsrIntrfc.FeatrUploadDoc();
            this.MsgValdtn.ScsfulyUplodedDoc();
            //this.AllLink.ClkDocMyHomeLnk();
            //this.AllLink.ClkDocAdminLnk();
            //this.AllLink.ClkDocAdminPrmsnLnk();
            //this.AllLink.ClkDocAdminFltrLnk();
            //this.AllLink.ClkDocAdminCreateRepLnk();
            //this.AllLink.ClkDocAdminEditRepLnk();

        }

        #region Additional test attributes

        // You can use the following additional attributes as you write your tests:

        ////Use TestInitialize to run code before running each test
        //[TestInitialize()]
        //public void MyTestInitialize()
        //{       
        //    // To generate code for this test, select "Generate Code for Coded UI Test" from the shortcut menu and select one of the menu items.
        //    // For more information on generated code, see http://go.microsoft.com/fwlink/?LinkId=179463
        //}

        ////Use TestCleanup to run code after each test has run
        //[TestCleanup()]
        //public void MyTestCleanup()
        //{       
        //    // To generate code for this test, select "Generate Code for Coded UI Test" from the shortcut menu and select one of the menu items.
        //    // For more information on generated code, see http://go.microsoft.com/fwlink/?LinkId=179463
        //}

        #endregion

        ///


        ///Gets or sets the test context which provides
        ///information about and functionality for the current test run.
        ///
        public TestContext TestContext
        {
            get
            {
                return testContextInstance;
            }
            set
            {
                testContextInstance = value;
            }
        }
        private TestContext testContextInstance;


        // References made to each of the three uitest files :
        // AllLnk
        // UsrIntrfc
        //MsgValdtn

        public multipleuimaps.MsgValdtn.MsgValdtnClasses.MsgValdtn MsgValdtn
        {
            get
            {
                if ((this.map2 == null))
                {
                    this.map2 = new multipleuimaps.MsgValdtn.MsgValdtnClasses.MsgValdtn();
                }

                return this.map2;
            }
        }

        private multipleuimaps.MsgValdtn.MsgValdtnClasses.MsgValdtn map2;

       public AllLink AllLink
        {
            get
            {
                if ((this.map1 == null))
                {
                    this.map1 = new AllLink();
                }

                return this.map1;
            }
        }

        private AllLink map1;

        public UsrIntrfc UsrIntrfc
        {
            get
            {
                if ((this.map == null))
                {
                    this.map = new UsrIntrfc();
                }

                return this.map;
            }
        }

        private UsrIntrfc map;


    }
}

Automating Using QTP Day5 Some VbScripting Techniques

Synchronization of the application load with the Script execution :
Wait and WaitRoproperty.
In scenarios wherein the properties of the object changes after some time we use waitproperty.

Object Recognition Mechanism in QTP :

  • Add object in the Object Repository using Object Spy 
  • Creating the same using Descriptive programming.
  • Using the active screen or going into the application and clicking insert new object.
Regular Expression Usage Effectively in the scripting :
After having gone through the Book Ticket scenario in the Flight application . just go into the File menu for Fax order scenario.
Go to file and select Fax the booked tickets.
Select for regular expression option so that the fax order number gets recognised each time on the basis
of this very regular expression
Just put a .* after the point from where the characters is expected to be changed.

Text Checkpoint :
Checked text, Text Before, After text
Match CAse, exact match,

Text Area checkpoint
is for tabular display for any specific row.
namespace standards in xml.
XML Addins
is required for the XML checkpoints.

Test Objects used by web services.
Strat Transaction end transactionm...
Time frames get retunrned
Generally used foir query time out features related to databasae interactions.
Colon is used to combine multiple statement in one line

Important conecpts in Advanced QTP workaround :

  • Parameterization
  • Checkpoint
  • Synchronization
  • Object Repository
Descriptive Programming  is a technique used when an object property changes frequently.
No Object Repository method is used for object identification.

Static are the necessary properties of an objects.
Methods like SET are used for creating references to the objects actually present in the application.

Let us look into describing the Objects in the application. Do remember the hierarchy of the Parent and child objects. Generally  the approach we follow for the description programming  is coding in the hierarchial manner that an object is recognized by the QTP tool during the course of object identification.

 Login Box Which is a dialog box
 Keep your appplication open, Object Spy tool can be useed to spy onto the objects and highlight and  copy the properties of the required objects.
 Individually search for each of the objects associated properties.
 Always use the two things, class name and the text name genuinely very relevant.

 Below we spy for the Login dialog page properties

Parent Objects :
Set oLogin=Description.Create()oLogin("Class Name").Value="Dialog"
oLogin("text").Value="Login"

 Child Objects :
 For Login Fileds Textbox

Set oUserNam=Description.Create() oUserNam("Class Name").Value="WinEdit"
 oUserNam("attached text").Value="Agent Name:"

 For Password Fields Textbox Set opassword=Description.Create()
 opassword("Class Name").Value="WinEdit"
 opassword("attached text").Value="Password:"

For Button to log on OKSet oOKButton=Description.Create() oOKButton("Class Name").Value="WinButton"
oOKButton("text").Value="OK"

 For Button to log on CancelSet oCanButton=Description.Create() oCanButton("Class Name").Value="WinButton"
oCanButton("text").Value="Cancel"

 Now , let us code using VBScript  to execute the events in the application which is expected to be performed for logging into the application.

InvokeApplication
"D:\Program Files\HP\QuickTest Professional\samples\flight\app\flight3a"
Dialog(oLogin).WinEdit(oUserNam).Type"employee"
Dialog(oLogin).WinEdit(oUserNam).Set "employee"
Dialog(oLogin).WinEdit(oPassword).Set "mercury"
Dialog(oLogin).WinButton(oOKButton).Click


Dynamic Descriptive programming :
InvokeApplication  "D:\Program Files\HP\QuickTest Professional\samples\flight\app\flight3a"
Dialog("Class Name:= Dialog","text:=Login").Winedit("Class Name:=WinEdit","attached text:=Agent Name:").Set "2039"
Dialog("Class Name:= Dialog","text:=Login").Winedit("Class Name:=WinEdit","attached text:=Password:").Setsecure "4ceb5e5216db248fd801b9d8e2364301e4bafec6"


This is how we do descriptive programming to automate the stable working features of an application. Do always take care of the hierarchy of the application.

Coded Ui Automation testing

Visual Studio 2010 Feature Packs

Feature Packs enable you to extend Visual Studio 2010 with capabilities that enhance and complement the existing tools.

Feature Pack Downloads

Visual Studio 2010 Feature Pack 2 (MSDN Subscribers Only)Visual Studio 2010 Feature Pack 2 (MSDN Subscribers Only)
Cumulative feature pack that extends testing, code visualization and modeling capabilities in Visual Studio 2010.
Testing features:
  • Use Microsoft Test Manager to capture and playback action recordings for Silverlight 4 applications.
  • Create coded UI tests for Silverlight 4 applications with Visual Studio 2010 Premium or Visual Studio 2010 Ultimate.
  • Edit coded UI tests using a graphical editor with Visual Studio 2010 Premium or Visual Studio 2010 Ultimate.
  • Use action recordings to fast forward through manual tests that need to support Mozilla Firefox 3.5 and 3.6.
  • Run coded UI tests for web applications using Mozilla Firefox 3.5 and 3.6 with Microsoft Visual Studio 2010 Premium or Visual Studio 2010 Ultimate.
Code visualization and modeling features (requires Visual Studio 2010 Ultimate):
  • Use the Generate Code command to generate skeleton code from elements on UML class diagrams. You can use the default transformations, or you can write custom transformations to translate UML types into code.
  • Create UML class diagrams from existing code.
  • Explore the organization and relationships in C, C++, and ASP.NET projects by generating dependency graphs.
  • Import elements from UML sequence diagrams, class diagrams, and use case diagrams as XMI 2.1 files that are exported from other modeling tools.
  • Create links and view links from work items to model elements.
  • Create layer diagrams from C or C++ code and validate dependencies.
  • Write code to modify layer diagrams and to validate code against layer diagrams.
From Microsoft Site.

The XML file namely, UiMap.uitest, which seems very complex otherwise is in a lot more organised manner, with everything displayed as a Ui Interface. Just install and may be bring a little bit of code flexibility in terms of editing, though lot more still is expected.

User Interface changes handling in Coded Ui Testing

What to do if your user interface changes ?

User interfaces frequently change during development. Here are some ways to reduce the effect of these changes:
  • Find the recorded method which references this control and use the Coded UI Test Builder to re-record the actions for this method. You can use the same name for the method to overwrite the existing actions. Do keep track that you record no multiple flows under single function module. Because that will bring lot of dependency of one module on other. For example you might be having the scenario of logging into Gmail and then clicking on the MyContacts link. One record action should be under one function module that is Login and the other event that is navigating to the MyContact link by clicking it.
    As a result of which what we shall be able to acheive is that even if tomorrow the Management decides to alter the MyContact link into some new name as MyRelatives , our script being specifically modularised into separate function name as in our case now is we can record just the Click event on the one control that is the new link for MyContacts that is MyRelatives. What comes out is that our script gets very modularised. And maintenance effort is minimised.


  • If a control has an assertion that is no longer valid:
    • Delete the method that contains the assertion.
    • Remove the call to this method from the test method.
    • Add a new assertion by dragging the cross-hair button onto the UI control, open the UI map, and add the new assertion.

      But this logic works successfully only in the case wherein we have just one assertion condition and this very function name can be hence re recorded and validated for our code maintenance ease.