Anda di halaman 1dari 25

CBOSS QA Automation

Document Number: ALL-CBOSS-GDLN-38815762 Version: 1.0-2 Status: Draft

QA Automation Coding Standards & Guidelines


Introduction..................................................................................... 43 1 Scope of this Document ............................................................. 43
1.1 Inclusions: ......................................................................................... 43 1.2 Exclusions:......................................................................................... 54

Coding Standards ...................................................................... 54


2.1 Variable Naming Convention ............................................................. 76
Input and Output Parameters ...........................................................................109 Input Parameters:............................................................................................. 109 Output Parameters: .......................................................................................... 109

2.2 Constant Naming Conventions ...................................................... 1110


2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 User defined....................................................................................... 1110 Pre-defined ........................................................................................ 1110 Color Constants .................................................................................. 1110 Date and Time Constants .................................................................... 1211 Date Format Constants ....................................................................... 1211 String Constants ................................................................................. 1312 Tristate Constants .............................................................................. 1413 VarType Constants ............................................................................. 1413

2.3 Function naming conventions........................................................ 1615 2.4 Code Commenting Conventions .................................................... 1615
i Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

2.5 Business Process Test Naming Convention .................................... 1716 2.6 Business Components Naming Convention .................................... 1716 2.7 Formatting Your Code ................................................................... 1817

Headers................................................................................. 1817
3.1 Main Test Script ............................................................................ 1817 3.2 Sub / Function Procedure .............................................................. 1817

4 5 6 7 8

Control Statements ............................................................... 1918 General Rules and observations............................................. 2120 Data Table / Sheet formatting ............................................... 2221 Appendix Object Naming Convention.................................. 2322 Naming Conventions for HP Service Test ................................ 2423
Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar Formatted: Default Paragraph Font, Check spelling and grammar

Revision History ........................................................................... 2524 Introduction.......................................................................................3 1 Scope of this Document ...............................................................3


1.1 Inclusions: ........................................................................................... 3 1.2 Exclusions:........................................................................................... 4

Coding Standards ........................................................................ 4


2.1 Variable Naming Convention ............................................................... 6
Input and Output Parameters .............................................................................. 9 Input Parameters:................................................................................................ 9 Output Parameters: ............................................................................................. 9
ii

Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines


Formatted Formatted Formatted Formatted Formatted Formatted Formatted Formatted Formatted Formatted Formatted Formatted Formatted Formatted Formatted ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...

2.2 Constant Naming Conventions .......................................................... 10


2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 User defined.......................................................................................... 10 Pre-defined ........................................................................................... 10 Color Constants ..................................................................................... 10 Date and Time Constants ....................................................................... 11 Date Format Constants .......................................................................... 11 String Constants .................................................................................... 12 Tristate Constants ................................................................................. 13 VarType Constants ................................................................................ 13

2.3 Function naming conventions............................................................ 15 2.4 Code Commenting Conventions ........................................................ 15 2.5 Business Process Test Naming Convention ........................................ 16 2.6 Business Components Naming Convention ........................................ 16 2.7 Formatting Your Code ....................................................................... 16

Headers..................................................................................... 17
3.1 Main Test Script ................................................................................ 17 3.2 Sub / Function Procedure .................................................................. 17
Formatted Formatted Formatted ... ... ...

4 5 6 7 8

Control Statements ................................................................... 18


Formatted ...

General Rules and observations................................................. 20


Formatted ...

Data Table / Sheet formatting ................................................... 21


Formatted ...

Appendix Object Naming Convention...................................... 22


Formatted ...

Naming Conventions for HP Service Test .................................... 22


Formatted: Default Paragraph Font, Check spelling and grammar

Revision History ............................................................................... 24


iii Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

Introduction
The purpose of this document is to provide the CBOSS QA Performance & Automation (ITQA) team members who will be using Quick Test Professional (QTP) with a basic framework for creating automated scripts using Visual Basic Scripting Language (VBScript). These practices have been documented to ensure that experience gained in the usage of VBScript is available to and used by the team. It is expected that over time these practices will mature into coding standards used by all QTP developers. This document should be viewed as guidelines for using VBScript to code QTP automated scripts in a simple and understandable fashion. The naming conventions have been based on industry standards, but have been streamlined for the IT QA environment. The importance and benefits of a consistent coding style are well known. A consistent style: Improves the readability, and maintainability of scripts. Facilitates sharing of code among QTP developers, especially teams of developers working on the same application. Makes it easier to conduct code reviews, another software engineering process with well-known benefits. In turn, a practice of regular code reviews can help enforce a consistent style. Saves developers time, once the guidelines are learned, by enabling developers to focus on the semantics of the code, rather than spend time trying to determine what particular format is appropriate for a given situation.

These standards however, are not meant to be rigidly enforced without exception. This document does not cover all possible situations. Experience and informed judgment should be used whenever doubt exists. Consistency of coding style is more important than using a particular style. Having said that, when situations arise which are not covered by this document, we should strive to enhance this document to include the new scenario for future reference.

1 Scope of this Document


This document has been created for the use of creating all automated scripts across all applications within IT QA. This document assumes the reader has a general understanding of Visual Basic Scripting Language (VBS).

1.1

Inclusions:
Script naming conventions: Variable, function and CONSTANT naming conventions Header and footer format for Main Scripts / Business Components, Defined functions and Called Scripts
4 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

Control Statements Code formatting Functions, when to create a function

1.2

Exclusions:
Exception Handling / Recovery Scenarios

2 Coding Standards
Coding conventions are based on industry standards that help you structure your VB Script. Coding conventions included are: Naming Conventions for Business Process Tests and Business Components Naming conventions for objects, variables and procedures Commenting Text formatting and indenting guidelines

The main reason for using a consistent set of coding conventions is to standardize the structure and coding style of a VBScript or set of VBScripts so that you and others can easily read and understand the code. Overtime, the use of common coding conventions will result in more precise, readable, and unambiguous source code that is consistent with other language conventions and as intuitive as possible. VBScript Data Types VBScript has only one data type called a Variant. A Variant is a special kind of data type that can contain different kinds of information, depending on how it's used. Because Variant is the only data type in VBScript, it's also the data type returned by all functions in VBScript. Variant Subtypes - The following table contains the list of Variant data subtypes. Subtype Empty Null Boolean Description Variant is uninitialized. Value is 0 for numeric variables or a zero-length string ("") for string variables. Variant intentionally contains no valid data. Contains either True or False.
5 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

Byte Integer Currency Long Single Double

Contains integer in the range 0 to 255. Contains integer in the range -32,768 to 32,767. -922,337,203,685,477.5808 to 922,337,203,685,477.5807. Contains integer in the range -2,147,483,648 to 2,147,483,647. Contains a single-precision, floating-point number in the range -3.402823E38 to 1.401298E-45 for negative values; 1.401298E-45 to 3.402823E38 for positive values. Contains a double-precision, floating-point number in the range 1.79769313486232E308 to -4.94065645841247E-324 for negative values; 4.94065645841247E-324 to 1.79769313486232E308 for positive values. Contains a number that represents a date between January 1, 100 to December 31, 9999. Contains a variable-length string that can be up to approximately 2 billion characters in length. Contains an object. Contains an error number.

Date (Time) String Object Error

You can use conversion functions to convert data from one subtype to another. In addition, the VarType function returns information about how your data is stored within a Variant. VarType - Returns a value indicating the subtype of a variable. (see chart below) Syntax: VarType(varname) Where varname can be any variable.

Constant vbEmpty vbNull vbInteger vbLong vbSingle vbSingle vbCurrency

Value 0 1 2 3 4 5 6

Description Uninitialized (default) Contains no valid data Integer subtype Long subtype Single subtype Double subtype Currency subtype
6

Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

vbDate vbString vbObject vbError vbBoolean vbVariant vbDataObject vbDecimal vbByte vbArray

7 8 9 10 11 12 13 14 17

Date subtype String subtype Object Error subtype Boolean subtype Variant (used only for arrays of variant) Data access object Decimal subtype Byte subtype

8192 Array

2.1

Variable Naming Convention


Variable Declaration A variable is a way of referring to a memory location where you can store program information that may change during script execution. The body of a variable name should use mixed case and should be as descriptive as necessary and should be prefixed based on the object type prefix chart below. In VBScript, all variables are of type variant that can store different types of data. To enhance readability and consistency, use variable prefix codes to indicate the primary type of data that they are designed to hold. Scope and Lifetime of Variables You declare variables explicitly in your script using the Dim (or ReDim) statement, the Public statement, and the Private statement. For example: Dim strName You declare multiple variables by separating each variable name with a comma. For example: Dim strName, strAddress, lngPhone
7 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

Lifetime of a variable is how long a variable exists in the script. The lifetime of a script-level variable extends from the time it's declared until the time the script is finished the execution. At procedure level, a variable exists only as long as you are within that procedure. Local variables are temporary storage space when a procedure is executing. Note: You can have local variables of the same name in several different procedures because each is recognized only by the procedure in which it is declared.

Variable Scope Variables should always be defined with the smallest scope possible. VBScript variables can have the following scope. Scope Procedurelevel Script-level Where Variable Is Declared Event, Function, or Sub procedure Beginning of each script Visibility Visible in the procedure in which it is declared Visible in every procedure in the script

Variable Scope Prefixes As script size grows, so does the value of being able to quickly differentiate the scope of variables. A one-letter scope prefix preceding the type prefix provides this, without unduly increasing the size of variable names. Scope Procedure-level Script-level Prefix None S dblVelocity sblnCalcInProgress Example

Rules to declare the Variable Names: Must begin with an alphabetic character Cannot contain an embedded period Can contain an underscore (_) Max length is 255 characters Must be unique in the scope in which it is declared.

Assigning Values to Variables


8 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

Values are assigned to variables creating an expression as follows, the variable is on the left side of the expression and the value you want to assign to the variable is on the right. For example: strName = Bob Here strName is a Variable and Bob is the value of a variable.

Option Explicit statement: Option Explicit - This statement forces you to declare all the variables under it before using them in the script. As such it must be the first statement in the script. Use Option Explicit to avoid incorrectly typing the name of an existing variable or to avoid confusion in code where the scope of the variable is not clear. When you use the Option Explicit statement, you must explicitly declare all variables using the Dim, Private, Public, or ReDim statements. If you attempt to use an undeclared variable name or incorrectly typing the name of an existing variable, an error occurs. The following example illustrates use of the Option Explicit statement. Option Explicit ' Forces explicit variable declaration. Dim strVar ' Declared variable. intValue = 10 ' Undeclared variable generates an error. strVar = Tomato ' Declared variable does not generate any error. Use the following prefixes with descriptive names for variables in your QTP Scripts, for readability and consistency. Subtype Boolean Byte Date (Time) Double Error Integer Long Object Single String Prefix Bln Byt Dtm Dbl Err Int Lng Obj Sng Str Example blnExist bytTeraData dtmStartTime dblTolerance errCustomerNum intLocate lngDistance objServerName sngCount strFirstName

9 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

Constant Note:

Con

conYearEnd

The descriptive name of the variable that follows after prefix should start with first letter capitalized. There should not be any spaces in the logical name that follows after the prefix Input and Output Parameters QTP gives the facility of passing the parameters to the components while executing the business scenarios. The parameters could be classified as input parameters and output parameters.

Input Parameters: Values could be passed to the defined parameters during execution. The value passed could be used in the script during execution Output Parameters: Values could be return by the script during execution. The calling script for further execution could use the return value. To enhance readability and consistency and to differentiate between the types of the parameter use the following prefixes with descriptive names for the parameters declared in the code. A standard prefix preceding the variable name would easily help in identifying the type of the parameter defined.

Parameter Type Input

Prefix Ip

Example ipintCount, ipstrName, ipblnStatus opintCount, opstrName, opblnStatus

Output

Op

10 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

2.2
2.2.1

Constant Naming Conventions


User defined
Earlier versions of VBScript had no mechanism for creating user-defined constants. Constants, if used, were implemented as variables and distinguished from other variables using all uppercase characters. Multiple words were separated using the underscore (_) character. For example: USER_LIST_MAX NEW_LINE While this is still an acceptable way to identify your constants, you may want to use an alternative naming scheme, now that you can create true constants using the Const statement. This convention uses a mixed-case format in which constant names have a "con" prefix. For example: conYourOwnConstant

2.2.2

Pre-defined
A number of pre-defined constants in VBScripts can be used in the code. Constants provide a convenient way to use specific values without actually having to remember the value itself. Using constants also makes your code more maintainable should the value of any constant ever change. Because these constants are already defined in VBScript, you don't need to explicitly declare them in your code. Simply use them in place of the values they represent. Following are the various categories of constants provided in VBScript.

2.2.3

Color Constants
There are eight basic colors that can be used in scripting. Constant VbBlack VbRed vbGreen vbYellow Value &h00 &hFF &hFF00 &hFFFF Description Black Red Green Yellow

11 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

VbBlue vbMagenta VbCyan vbWhite

&hFF0000 &hFF00FF &hFFFF00 &hFFFFFF

Blue Magenta Cyan White

2.2.4

Date and Time Constants Defines date and time constants used by various date and time functions. Constant vbSunday vbMonday vbTuesday vbWednesday vbThursday vbFriday vbSaturday vbUseSystemDayOfWeek Value Description 1 2 3 4 5 6 7 0 Sunday Monday Tuesday Wednesday Thursday Friday Saturday Use the day of the week specified in your system settings for the first day of the week. Use the week in which January 1 occurs (default). Use the first week that has at least four days in the new year. Use the first full week of the

vbFirstJan1 vbFirstFourDays

1 2

vbFirstFullWeek

2.2.5

Date Format Constants Defines constants used to format dates and times.

12 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

Constant vbGeneralDate

Value Description 0 Display a date and/or time. For real numbers, display a date and time. If there is no fractional part, display only a date. If there is no integer part, display time only. Date and time display is determined by your system settings. Display a date using the long date format specified in your computer's regional settings. Display a date using the short date format specified in your computer's regional settings. Display a time using the long time format specified in your computer's regional settings. Display a time using the short time format specified in your computer's regional settings.

vbLongDate

vbShortDate

vbLongTime

vbShortTime

2.2.6

String Constants Defines a variety of non-printable characters used in string manipulation.

Constant vbCr vbCrLf vbFormFeed vbLf vbNewLine

Value Chr(13) Chr(13) & Chr(10) Chr(12) Chr(10)

Description Carriage return. Carriage returnlinefeed combination. Form feed; not useful in Microsoft Windows. Line feed.

Chr(13) & Chr(10) or Platform-specific newline character; whatever is appropriate for Chr(10) the platform. Chr(0) Character having the value 0.

vbNullChar vbNullString

String having value 0 Not the same as a zero-length string (""); used for calling external procedures.

13 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

vbTab

Chr(9)

Horizontal tab. Vertical tab; not useful in Microsoft Windows.

vbVerticalTab Chr(11)

2.2.7

Tristate Constants Defines constants used with functions that format numbers. Constant vbUseDefault vbTrue vbFalse Value -2 -1 0 Description Use default from computer's regional settings. True False

2.2.8

VarType Constants Defines the various Variant subtypes. Constant vbEmpty vbNull vbInteger vbLong vbSingle vbSingle vbCurrency vbDate vbString Value Description 0 1 2 3 4 5 6 7 8 Uninitialized (default) Contains no valid data Integer subtype Long subtype Single subtype Double subtype Currency subtype Date subtype String subtype

14 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

vbObject vbError vbBoolean vbVariant

9 10 11 12

Object Error subtype Boolean subtype Variant (used only for arrays of variants) Data access object Decimal subtype Byte subtype

vbDataObject 13 vbDecimal vbByte vbArray 14 17

8192 Array

15 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

2.3

Function naming conventions


A function should be treated the same as variables when it comes to declaring it as a Str, Int, etc. based on the type of variable that is returned. If there is no variable returned the function will need not have a prefix to represent a data type or class. A function is this case is a procedure with a script that does a specific amount of work in an effort to either calculate a result or perform an action. Although functions and subroutines are considered to be public by default, the function declaration should be explicitly defined as either Public or Private. All procedures should begin with a brief comment describing what they do. This description should not describe the implementation details (how it does it) because these often change over time, resulting in unnecessary comment maintenance work, or worse, erroneous comments. The code itself and any necessary inline comments describe the implementation. Arguments passed to a procedure should be described when their purpose is not obvious and when the procedure expects the arguments to be in a specific range. Return values for functions and variables that are changed by a procedure, especially through reference arguments, should also be described at the beginning of each procedure.

2.4

Code Commenting Conventions


All the scripts, procedures, functions should begin with a brief comment describing what they do. This description should not describe how this could be implemented because these often change over time, resulting in unnecessary comment maintenance work. Arguments passed to a procedure, function should be described when their purpose is not obvious and when the procedure or function expects the arguments to be in a specific range. Return values for functions and variables that are changed by a procedure, especially through reference arguments, should also be described at the beginning of each procedure. Remember the following points while writing the scripts:

Every important variable declaration should include an inline comment describing the use of the variable being declared. Variables, controls, functions and procedures should be named clearly enough that inline comments are only needed for complex implementation details. At the beginning of your script, you should include an overview that describes the script, pre/post conditions, assumptions, etc.

16 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

2.5

Business Process Test Naming Convention


All the Business Process Tests that are to be created by the Automation or SV&V team need to follow the common naming conventions while naming those tests. The naming convention to be followed to by Business Process Tests will be: <Product Name / Lines of Business>_<Module Name>_<Business Scenario Name> <Product Name> - Product Name refers to the name of the product for which the Business Process Tests are being created. <Lines Ofof Business> - Indicates the applicable appropriate Line of Business for which thisthat if the Business Process Test is applicable.is applicable to any Lines Of Business of the product for which automation in progress <Module> - Describes the name of the module within the Product. <Business Scenario Name> - Describes about the business scenario for which the test is developed. The name of the Business Scenario should contain information to understand the purpose.

2.6

Business Components Naming Convention


The naming conventions for the business components should be similar with to the Business Process Tests naming conventions. The following naming convention to be used for the Business Components: <Product Name / Lines of Business>_<Module>_<Business Component Name> <Product Name> - Product Name refers to the name of the product for which the Business Components are being created. <Lines Oof Business> - Indicates the appropriate Line of Business for which thisthat if the Business Component is applicable to any Lines of Business of the product for which automation in progress. <Module> - Describes the name of the module within the Product. <Business Component Name> - Describes the purpose of the business component.

17 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

2.7

Formatting Your Code


Some pointers: Standard nested blocks should be indented 1 tab (which is four spaces). The overview comments of a procedure should be indented one space. Add space / lines where necessary to improve readability.

3 Headers
3.1 Main Test Script
Having a brief description about the functionality covered in the script helps in understanding the script for a third person without actually going through the code. Script Header:
**************************************************************************** Script Name : <Name of the Script> Summary : Description of what the script does Author Name : <Script Creator> Created Date : <script creation date > Input Parameters : All Input Parameters for the script Output Parameters : All Output Parameters for the script Reviewed By : <<Reviewer of the script >> Modification Log : Script modification history '----------------------------------------------------------------------------------'' Sr.No. Date Modified by Reason for Modification Remarks '----------------------------------------------------------------------------------****************************************************************************

3.2

Sub / Function Procedure


Sub / Functions could be written to avoid the repetition of code. Identify the functionality/code, which is repetitive, and create a function/procedure, which could be called at appropriate places instead of repeating the code each time
**************************************************************************** Sub / Function Name: <Sub / Function Procedure Name> Author : <Script Creator> Test Case : <All manual test cases encompassed in this script> Description : Description of what the script does Important Notes : <If any> Functions Used : <All functions used within this script> Input Parameters : <Function arguments>

18 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines


Modification Log : <<Script modification history>> ----------------------------------------------------------------------------------' Sr.No. Date Modified by Reason for Modification Remarks ----------------------------------------------------------------------------------****************************************************************************

Sub procedure - is a series of VBScript statements, enclosed by Sub and End Sub statements that perform actions but don't return a value. A Sub procedure can take arguments (constants, variables, or expressions that are passed by a calling procedure). If a Sub procedure has no arguments, its Sub statement must include an empty set of parentheses (). Function procedure - is a series of VBScript statements enclosed by the Function and End Function statements. A Function procedure is similar to a Sub procedure, but can return a value. A Function procedure can take arguments (constants, variables, or expressions that are passed to it by a calling procedure). If a Function procedure has no arguments, its Function statement must include an empty set of parentheses. A Function returns a value by assigning a value to its name in one or more statements of the procedure. The return type of a Function is always a Variant. Make appropriate use of functions and procedures. When a status of a particular execution is required, make use of the function as it gives you the flexibility of returning the status. When a status of a particular execution is not required, but its a simple process to be executed , make use of the procedure. You can call the Sub / Function procedures using Call statement. Call ReportChkDB(Report, ChkDatabase) ReportChkDB Report, ChkDatabase Notice that the parentheses are omitted in the call when the Call statement is not used.

4 Control Statements
All control statements should be preceded by comments stating the purpose of the control flow and status of the control operation. Very often when you write code, you want to perform different actions for different decisions. You can use conditional statements in your code to do this. In VBScript we have the following conditional statements:

If...Then...Else - The If...Then...Else statement is used to evaluate whether a condition is True or False and, depending on the result, to specify one or more statements to run. Usually the condition is an expression that uses a comparison operator to compare one value or variable with another.
19

Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

Select Case - The Select Case structure provides an alternative to If...Then...Else If for selectively executing one block of statements from among multiple blocks of statements. A Select Case statement provides capability similar to the If...Then...Else statement, but it makes code more efficient and readable. Do...Loop - Loops while or until a condition is True. You can use Do...Loop statements to run a block of statements an indefinite number of times. The statements are repeated either while a condition is True or until a condition becomes True. While...Wend - Loops while a condition is True. The While...Wend statement is provided in VBScript for those who are familiar with its usage. However, because of the lack of flexibility in While...Wend, it is recommended that you use Do...Loop instead. For...Next - You can use For...Next statements to run a block of statements a specific number of times. For loops, use a counter variable whose value is increased or decreased with each repetition of the loop. For Each...Next - For Each...Next loop is similar to a For...Next loop. Instead of repeating the statements a specified number of times, a For Each...Next loop repeats a group of statements for each item in a collection of objects or for each element of an array. This is especially helpful if you don't know how many elements are in a collection.

20 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

5 General Rules and observations


Some general rules and observations: Avoid using On Error Resume Next as it can lead to unpredictable results especially if you are evaluating a condition which you know is false, however the script is behaving like it is true and its all due to the fact that On Error Resume Next caused the script to skip the error and move onto the next line of code even though it was wrong. Always use Option Explicit at the beginning of your script to enforce variable declaration. Standard, tab based, nested blocks should be used. All conditional statements must be indented by one tab progressively depending on the nesting. Variables and constants should be scoped by function / procedure, rather than global. Document anything that needs documenting. Even if the creator finds the items self explanatory someone trying to debug it in a hurry may not. Modularity is important; anything that can be used by more than one script should be either in a function library or a reusable action within a Test. The more things that are put into a function, module, or called script the easier it will be to maintain. When creating a script scenario keep in mind that the goal is to verify expected results, both positive and negative. The QTP automated scripts should not be created to simply go through the workflow to see if an application blows up. The tool is designed to help produce a higher quality product with fewer defects. Expected results can come in the form of expected static text in a message box, a GUI verification of a screen, the status of a button or other icons / objects being either focused, displayed, active, enabled, disabledetc Try to use Select Case whenever possible instead of multiple If .. Then.. Else if statements. Every important variable declaration should include an inline comment describing the use of the variable being declared. Comments for self explanatory statements should be avoided There should not be any commented code lines in the script. In unavoidable cases of multiple nesting, it can be encapsulated as a function within the script and be called when required. Use Report Statements to report pass/fail conditions for each section in a script. Add screenshot in the result file for the required validation during the execution Every manual step should be followed by automation step in test script

21 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

6 Data Table / Sheet formatting


Currently there are no guidelines in this area except for using common sense with regards to making the column names easy to read and understand.

22 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

7 Appendix Object Naming Convention


Object type 3D Panel Animated button Arrays Check box Combo box Command button Common dialog Connection object Dictionary Drive Excel application object File Folder Frame Horizontal scroll bar Prefix pnl ani arr chk cbo cmd dlg cnx dic drv xls fle fld fra hsb Example pnlGroup aniMailBox arrKeys Object type Image Label Line Prefix img lbl lin lst btn sht Sld spn txt txs tbr win Example imgShow lblHelp linHorizontal lstCustomerCode s btnChoice rstQueryResults shtLayout sldRuler spnPages txtFirstName txsWrench tbrTools vsbVolume winTitle

chkReadOnl List Box y cboGerman cmdClose cnxDBLink dicFiles drvHDD xlsForecast fleHandle fldRoot hsbSize Radio button

Recordset object rst Slider Spin Text box TextStream (FSO) Tool Bar

dlgFileExists Sheet Object

Vertical scroll bar vsb

fraLanguage Window

23 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

8 Naming Conventions for HP Service Test


The naming convention to be followed for scripts written in HP Service Test will be samewill follow as the VuGen naming convention and coding standard followed used by the CBOSS QA Performance Team. Specifically the Script Transactions section found in this document Performance Testing Team - File Naming Conventions.doc The above naming convention document resides in this LiveLink folder: http://insite/livelink/llisapi.dll?func=ll&objId=26650353&objAction=browse&sort=name

24 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

QA Automation Coding Standards & Guidelines

Revision History
Version 1.0-2 Date 08-Mar-2011 Revised by Marco Marsili Description Updated according to the new templates from go/templatecentral. Updated document to include BPT and HP Service Test details Approved by <Full Name, Title> <Full Name, Title> <Full Name, Title> <Full Name, Title>

1.0-1

07-Mar-2011

Sid Pal & Automation Team Marco Marsili

1.0

24-Mar-2009

Created the initial coding standards document

Paul McNally, Manager, Performance & Automation

25 Revised 30-Jan-201308-Mar-2011
Document Number: ALL-CBOSS-GDLN-38815762 | Version: 1.0-2 | Status: Draft 2013 Research In Motion Limited. RIM Confidential Internal use only. Controlled document (except printed copies).

Anda mungkin juga menyukai