Docstoc

QTPStandards

Document Sample
QTPStandards Powered By Docstoc
					For more QTP Scripts, www.ramupalanki.com
               QuickTest Professional Scripting Standards
    THE BASIC FORMAT OF THE SCRIPT:
All new scripts/components/actions will have the following template automatically created.
Adjust as needed.

'########################################################################################
##
'#Test/Action Name:
'#Author :
'#Creation Date:
'#Copied From:
'#Modified By:
'#Modification Date:
'#Action Objective :
'#Verifications:
'########################################################################################
Option Explicit

'####Dim Generic Variables
Dim i                                              'acts as storage for loop counter value

'####Initialize Variables####
i=1

'####TRIM VARIABLES

'### Start of Script #################

'Reset SAP app to expected initial condition – Remove if not using for SAP
SAPGuiSession("Session").Reset


'###Validation Point#########




1) All QTP machines will have a copy of the ActionTemplate.mst (shown above)
   placed in the dat folder of the QTP folder to foster the formatting standards
   stated for all newly created Actions/Components following.

2) All scripts/actions/functions will provide an objective statement detailing
   what is to be accomplished and how with any special instructions for data
   included in header. This information will be copied to the test case
   description in Quality Center for use in reporting.

3) Load only those add-ins required to run the test to avoid function library
   conflicts.

4) All existing actions will have a header like template shown above.

5) Use distinct and descriptive variables names – no generic variables.




www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com

   THE CODE SECTION OF SCRIPT:

6) Always reset the initial status of application at the beginning of each script.
   For SAP, simply resetting the application takes care of this but for other
   applications it is important to ensure that all scripts have an expected initial
   and end condition that is the same. For example, starting and ending a script
   at the Home Page of a web site.

7) Use i and j as a commonly known loop counter variables.




8) Use x as a place holder for retrieved values in the code if not using
   descriptive variable.




9) Use the REPORTEVENT method of the Reporter object to output
   information into results.




10) All Reporter.ReportEvent messages should be clear and fully explanatory, no
    generic messages can be used.




11) Use white space where appropriate, such as between if statements, when
    navigating to new SAP screen, etc.



www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com




12) Indent within flow control (looping) and conditional statements (if/then and
    Select Case) one tab.




13) Object names in QTP script should be descriptive. (If process of finding name
    is too cumbersome/ time consuming please make note of it in QA Audit)




14) Use “‟##VALIDATION POINT” comment for checkpoints.




15) Add comments in code when appropriate, especially to describe situations
    where your logic determines flow - especially when BP is not obvious or
    performing calculations / data manipulations, etc.




16) No commented hardcode values.

17) No commented code, except for actual comments.




www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com




18) Any values used in pick lists should be trimmed. If data picked from list is
    insignificant in terms of performance of scenario use index (ie #0 instead of
    “Select” for Stage of Development field shown below to ensure first item is
    selected. This allows script to continue regardless of whether same value is
    first position or not.




19) If possible, import data sheets directly to the local sheet where used - use
    index position of table to direct it to correct sheet. (This is for new scripts.)

20) Use section/frame names if possible to describe parameter - otherwise use
    underscore and a number for parameters that have same name. (Example:
    Main_CustomerNumber and Department_CustomerNumber versus
    CustomerNumber_1 and CustomerNumber_2) (Not Applied to existing reusables)




21) Use underscore and “Act” for verification parameter names describing
    information retrieved/returned from application at runtime. (Example:
    ReturnedRecords_Act) (Not Applied to existing reusables – previously used _Val”)


22) Use underscore and “Exp” for verification parameter names describing
    information retrieved/returned from application to set baseline or expected
    value. (Example: ReturnedRecords_Exp) (Not Applied to existing reusables)


23) Use underscore and “Out” for output parameters names. (Example:
    VendorNumber_Out) (Not Applied to existing reusables)

   For Reusable Actions


www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com




24) Validation parameters and Output parameters should be at the end of the
    datasheet for reusable. (Not Applied to existing reusables)

   For Reusable Actions




25) Standard checkpoints should only be used when verifying texts and other
    generic validations. Dynamic validations more often require custom
    checkpoints but can also use standard checkpoints if able to put values in
    datatable.

26) Avoid using hardcoded values if possible. Hardcoded values should only be
    used for “any old data” pieces that do not affect outcome or business process
    flow.

27) Use functions when appropriate to:
        Easily identify the tasks performed by the script
        Prevent needless duplication of code
        Make your code portable and reusable
        Allow your code to be encapsulated in code libraries to provide one point of
          maintenance.
        Business processes should not be made into functions – but reusable actions




28) Functions should be maintained by a specific person. (To be determined).

29) All functions should be stored in the „BPT Resources‟ folder under the
    „Libraries‟ folder in Quality Center.



www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com




30) All shared object repositories should be stored in the „BPT Resources‟ folder
    under the „Object Repositories‟ folder in Quality Center.




31) No hard coded wait statements unless impossible to sync otherwise.
Use the WaitProperty statement or create your own sync loop on visual cue. For
example, if the visual cue is text on a screen then the following code can be better
employed (as a function) rather than a wait statement. (This is a generic
function that can be used for any window in any application.)
Public Function WaitForTextInWindow(WindowName,MyDesiredText,MaxTimeWillingToWait)
        Dim TheHandle: Dim CurText : Dim i: Dim MyCtr
        TheHandle = Window(WindowName).GetROProperty("hwnd")
        For i = 1 To MaxTimeWillingToWait
                 CurText = TextUtil.GetText(TheHandle)
                 If InStr(CurText,MyDesiredText) > 0 And MyCtr <= MaxTimeWilingToWait Then
                          WaitForTextInWindow = "found it"
                          MyCtr = MaxTimeWillingToWait 'get out of loop
                 else
                          wait(1)
                          MyCtr = MyCtr + 1
                 End If
        Next


www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com
       If WaitForTextInWindow <> "found it" Then
         WaitForTextInWindow = "failed"
       End If
End Function

32) Only declare needed input and output parameters. (Extraneous parameters
    can confuse in case of maintenance needs. – Often a result of copying
    components and making changes but forgetting to change options)

Optional:
33) Use the “Generate „With‟ statements” option found in the Options General
    tab to ensure coding is grouped by current focused window.

34) Any scripts that are audited should be transformed to use the „With‟ by
    selecting EditAdvancedApply With menu item.


 QuickTest Professional Sample Script
'######################################################################
'#Test/Action Name:     File Tab
'#Author :              Jane Smith
'#Creation Date:        APRIL 28, 2007
'#Copied From:          \Subject\Core\Driver Script… (For Reusable Actions only)
'#Modified By:          Dave Mark
'#Modification Date:    APRIL 29, 2007
'#'#Action Objective :  This test is designed to automate the Search functionality of
'#                      the File tab in the StrIDE environment.
'#Verifications:        Verifies the number of records returned matches expectations.
'######################################################################
Option Explicit

'#### DIM GENERIC VARIABLES
Dim rc ' Return Code (rc) of a function
Dim ExtFile

'#### INITALIZE VARIABLES
FieldSkip = "<SKIP>"

'####TRIM VARIABLES
StageOfDevelopment = Trim (StageOfDevelopment)

'#### START OF SCRIPT
'Reset SAP app to expected initial condition
SAPGuiSession("Session").Reset

Script ….

'##VALIDATION POINT



www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com
x =JavaWindow("Search").JavaStaticText("Your Search Returned").GetROProperty("label")
rc = CompareValue(RecordsReturned_Val,TempArray(1),"Number of Records Returned")



                              Best Practices

Object Repository
•   Object Repositories should be created prior to creation of scripts.
       – Rename objects logical name to reflect user interface
              • Makes scripts more readable and more easily maintained
              • Enforces uniformity of reference
       – Map custom objects prior to scripting
              • Allows custom objects that behave like standard objects to be
                 treated as standard giving greater context sensitivity and
                 increases reliability
       – Use shared object repositories in all Apps but SAP – otherwise
           business process fosters local repository method as one-time use.
       – Create one Shared Object Repository for application functionality
              • For instance – Creating sales order – Materials Management, etc
                            • currently all reusables have own local repository –
                                should share one
                            • Do not overlap objects by storing same in multiple
                                repositories
              • * Set as Default when working in same area – client setting in
                 Action Properties –Associated Repositories tab option.




Reusable Actions
•   You can use principles of Modular Scripting or Business Process Testing
    (BPT) even if just using QTP
•   Reusable actions imply generic code
•   Use reusable actions to mimic common Business Actions
•   Code should be generic to allow for variations of business process
•   Data entry / Validations should be data driven
•   Use custom checkpoints whenever possible to provide greater flexibility
•   Use Function Libraries for commonly used low-level activity
•   ie: – manipulate external files


www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com
•   Perform calculations
•   Work with custom objects
•   Associate function libraries with scripts and set as default
•   Create external function libraries and organize by task type
•   ie: Calculation, String Manipulation, File manipulation etc.


One point of maintenance is key
•   Avoid creation of local functions unless being reused only within script.
•   Think at an object level and not business process level – to foster generic code.
•   Data in spreadsheet should determine where and what is being done
•   Reduce duplication of code within reusable actions
•   Data drive tests whenever possible
•   Avoid hard coded data regardless – parameterize everything!
•   Maintain external spreadsheets – define shared folder location with folder
    structure to mirror QC.
•   Use ImportSheet command – reference data table parameters – do not
    reassign to variables.
•   Create a column called TestName for looping purposes if needed
•   Reference Environment(“TestName”) as follows:
       RowCount = DataTable.LocalSheet.GetRowCount
       For i= 1 to RowCount
               If DataTable(“TestName”,dtLocalSheet) = Environment(“TestName”)
                      Do this stuff…..
               End If
       Next




Initial Conditions - QTP
•   Use the “Record on any open Browser” option for Web Apps
       – You control the initial condition of browser in script
       – Use the SAPGuiSession(“Session”).Reset command for SAP
•   Use the “Record on any open Application” for Desktop Apps
       – You control the initial condition of AUT in script
•   Run Options – make sure the following are checked:
       –   Allow other Mercury products to run tests and components
       –   Save still image captures to results: select For errors and warnings
       –   Normal run mode with 100 milliseconds delay
       –   Automatically generate “With” statements after recording to establish
           focus and increase readability of script. (General option)
       –   Ignore Quality Center (Web option)



www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com
• Test/Component Settings
       –   Make sure proper associated add-ins loaded – only those needed.
       –   Run on all rows if global datatable has multiple rows
       –   Establish realistic timeout value – currently 20

• Action Settings
       –   Each new action will automatically be formatted to fit current format
           requirements – be sure to provide needed information where
           appropriate.
       –   ActionTemplate.mst will be stored locally at:
              • C:\Program Files\Mercury Interactive\QuickTest Professional\dat


Reusable\Flexible Code
Always think in terms of “where else can I use this” or “how can I make this as
generic (usable) as possible”. See the example above for the synchronization
function. Although it was created for a use in a specific application, the code is
written so that any windows application could use it without changing any code.
This train of thought will make your reusable code and your scripting efforts
more efficient not just for yourself but the entire team. This does not merely
apply to functions but components and actions as well. You need to get out of
the mode of thinking “how do I get this one business process piece to work?”, to
thinking “how do I make this work and make it so that it is most easily reused
and maintained?”.


•   Descriptive Programming
       –   Use when the properties of an object are dynamic and its properties
           are unknown for each iteration of the script
       –   Use descriptive programming in Web apps for dynamically created
           objects like text links and web elements where expectations can be
           defined or “actuals” easily retrieved.
       –   Use when same object is duplicated dynamically based on data input
           and varies widely.


Recovery Scenarios
•   Recovery Scenarios can be used for unexpected situations / errors / common
    pop ups
•   Use recovery scenarios when the pop up messages are predictable unless
    messages are BP status related.
•   Weigh Positive vs. Negative testing needs



www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com
•   Use conditional logic for predictable errors and put logic in the script and not
    in recovery scenario.
•   Checkpoints should only be in script – never in RS.
•   *Makes script execution more reliable and maintenance more efficient
    providing one point of maintenance when/if things change.



Efficient coding example:
The following is an example of utilizing code to most efficiently perform a
verification. At the same time, this code allows for the user to verify both a
positive and negative scenario, without having to change verification statements.
The idea is that flexibility is built in to the code based on what you know may or
may not be tested for the application.

For example, the VNet home page is comprised of various links to other pages.
Some of these links are to dynamic materials (ie news stories), others are to static
web pages that will always be there (ie Mission Statement, Committee) . The
ones that will always be there can be considered “always expected” so they will
pretty much be “positive” tests. Those that won‟t always be there can be either
positive or negative depending on when the testing takes place.

If testType = “Pos” then a=0:b=1 else a=1:b=0 End If „where testType tells if pos or neg test
If Exp_Condition = Act_Condition Then
    Reporter.ReportEvent a, “Conditional Check”,”The condition specified above was met.”
Else
    Reporter. ReportEvent b, “Conditional Check”,”The condition specified above was not met.”
End If


BPT Specific Information (Left in for possible shift back to BPT Usage)


Parameters vs. Local Sheet Usage
   Parameters are to be used for data values when the data in question needs to
    be controlled by the end user. During requirements gathering period
    analysts should ask questions regarding need/desire to be able to change
    specific values.
       o Does this data piece have an affect on business process flow?
       o Is this data replenished /can it be used up?
       o Is this data retrievable from database in way that can make script
           dynamic and work into flow of BP seamlessly?
       o Does data exist in reference table that may affect other data or be
           affected by other data in such a way that it may used for other
           dependent scenarios?


www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com

   Answers to the previous above questions will affect how data is
    parameterized. If the answers to questions are „no‟, then parameterize the
    data in the local sheet of the Action or the Component. If „yes‟ then
    parameterize the data in component parameters table to allow end user to
    manipulate as needed. Provide a default value so that users do not have to
    provide data for each piece.
   If data is retrievable through dynamic SQL and is based on conditional
    criteria, that is determined by objective statement, gather info from subject
    matter experts to create SQL statement and code action/component to
    retrieve data and store in local data sheet to be used for input.
   Importing data from an external sheet should be imported directly to the
    localsheet desired.
   Avoid duplication of storage of data by referencing the datatable or
    parameter where data was originally defined unless the need for
    manipulation within the script would cause issues with the use of the value
    later in the script.




       Functions and Function Libraries




www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com

'** Please add all new function names and objectives to this list as they are added to the library and in order in which they
appear.
'****************************************************************************************************************************************
' User Defined Database Functions
' -------------------------
'
' Available Functions:
'            * DataGrab - grab data from the defined database and write it to the local sheet
'            *
' Version: QTP9.2 February 2008
'
'*****************************************************************************************************************************************
'######################################################################################
'Function                 DataGrab(MyDSN,MySQL)
'Objective: This function will grab data from the defined database and write it to the
'                         local sheet of the action from which the function is called - it automatically
'                         creates columns in the local sheet with the names of the database columns retrieved
'                         and adds the number of rows needed to completely write out the data to the sheet.
'Parameters:              MyDSN - name of the system DSN that has connection string settings needed
'                         MySQL - the SQL statement to run to retrieve data from the database
'
'Created By; Unknown
'Date Created:
'Modifications:
'######################################################################################
'Function to grab the values from database to runtime data sheet
  Public Function DataGrab(MyDSN,MySQL)
             Dim TheDB                                                           'Declare the database object name alias
             Set TheDB = CreateObject("ADODB.Connection")                        'Create connection object to allow dynamic
                                                                                 connection to database
             TheDB.ConnectionString = "DSN="&MyDSN                               'Reference System DSN to establish connection
             TheDB.Open                                                          'Make connection
             Set MyResults = TheDB.Execute(MySQL)                                'Store record set (returned info) in object called
                                                                                 MyResults
             'MsgBox MyResults.Fields.Count                                      'Find out how many columns exist with data
             'MsgBox MyResults.Fields(0).Name                                    'Find out what the name of the first column is
             For a = 1 To MyResults.Fields.Count                                 'Establish loop begin and end conditions - start at
                                                                                 row one and end at last row
                          ParamName=DataTable.LocalSheet.AddParameter(MyResults.Fields(a-1).Name, "").Name
                          i=1
                          'Establish intial for my data entry loop
                          Do Until MyResults.EOF                       'Keep looping while there is still data to be read
                                     DataTable.LocalSheet.SetCurrentRow (i) 'Set focus on row i in data table localsheet
                                     DataTable(MyResults.Fields(a-1).Name,dtLocalSheet)=MyResults(ParamName)
                                                                       'write out the value to the datatable for the current record
                                     MyResults.MoveNext                'Advance to next record in recordset
                                     i=i+1                             'Increment counter to push datatable focus to the next row
                          Loop
                          MyResults.MoveFirst              'Go back to the first record in recordset for next column (if any)
             Next
             MyResults.Close                     'Clean up by closing database connection and removing objects from memory
             TheDB.Close
             Set MyResults = Nothing
             Set TheDB = Nothing
End Function

Standards for functions and function libraries:

           1. All user defined function libraries will have a header that indicates the
              functions contained within and a description of each for easy perusal.


www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com
   2. Only “Add-In” libraries created by QTP for use in registering the add-
      in functions and the template library file will remain directly in the
      Libraries Attachment area. All others will find a place in the functional
      structure shown above.

   3. Functions will be stored in logically named libraries that indicate the
      type of functions contained. For example, functions whose purpose is
      to manipulate strings should be contained in a library called
      “String_Funcs”, functions that perform mathematical operations
      should reside in a library called “Calculation_Funcs”, etc.

   4. If the function is relevant only to a specific application and can have no
      reasonable use across applications should reside in libraries with the
      system abbreviation under the folder indicating the type of function
      within. (For example see the VSEC library under the
      ENV_Initialize_Funcs folder).

   5. All procedures should be developed with the intention that they will
      be reused by other scripts. Avoid private Subs in cases where the Sub
      is to be called only once within a script. If it is needed multiple times
      then it is acceptable to declare/define a Sub at the beginning of the
      script. However, it is suggested that you analyze the procedure to see
      if/how it could be written to be more generic and thus gain more
      efficiency for script creation.

   6. All function procedures will have a header similar to the one shown
      above in the example function. The header is to include:
          a. The function name with the parameters declared.
          b. An objective statement to define what the function does
          c. A list of the parameters and a description of what they mean so other users
             will know how to use the function.
          d. The author name
          e. Date Created
          f. Modification information – be specific as to what you changed and why.

   7. Use indentation to show scope of function as well as scope of
      conditional statements, whether they are loops, ifs, select case
      statements or whatever to increase readability.

   8. Provide comments to explain your logic – remember, functions are
      basically algorithms that you have thought out to accomplish a goal.
      The way you think may be different than the next person so you need
      to walk them through your logic to provide understanding in case they
      are to be modified by someone else.


www.ramupalanki.com
For more QTP Scripts, www.ramupalanki.com

   9. Business processes should not be wrapped up as a function. If you
      want to make a business process reusable – use an action to do so,
      unless you need the business process to perform a recovery scenario.

   10. Register your function within the project where you created it
       whenever possible. This will allow other users to find your functions
       using the Step Generator. (If you do not register the function to a specific test object,
       the function is automatically defined as a global function. Global functions can be called by
       selecting the Functions category in the Step Generator (for function libraries), or the
       Operation item in the Keyword View. A list of global functions can be viewed alphabetically
       in the Operation box when the Functions category is selected in the Step Generator (for
       function libraries), in the Operation list when the Operation item is selected from the Item
       list in the Keyword View.)

   11. Functions should not contain statements that pass/fail the step, however they
       should provide information in the form of an output variable value that can be
       used within the script/action to perform a check. We can not always assume
       that a function failure is a bad thing, especially in terms of negative testing
       unless the test type is taken into consideration when developing the function
       and it is made powerful enough to handle pos/neg logic. (see the section on
       efficient coding)

   12. Recognize that a function is a procedure. There are two kinds of procedures –
       Functions and Subs. If your procedure does not return a value then it is to be
       declared as a Sub – otherwise update your Function to send a return value
       indicating success or failure.




www.ramupalanki.com