自动化测试开发规则和标准

Automated Testing Developing Standards

Capitalization:

1.DataTypes are always all uppercase. Examples: STRING, INTEGER.

2.UnderScores are used in DataTypes that are multiple words.

Examples: MY_ENUM, MY_RECORD.

3. Hungarian notation is used for all variable names. The first letter of a variable name is the first letter(s) of its type.

Examples: sUserName, iLoopCounter, lsProperties.

4.Method and Function names begin with an uppercase letter. Each Significant letter is capitalized.

Naming Conventions:

e the const SCRIPT_DIR to reference the path to 4Test scripts. If multiple directories are used, make these

references relative to SCRIPT_DIR.

2.The method used to invoke a window is called 'Invoke'.

3.The method used to close a window is called 'Close'.

4.The method used to accept a dialog is called 'Accept'.

Coding Conventions:

1.Functions and Methods that do not return a value should be indicated by using the return type VOID.

2.All methods and functions should end with a return statement even if it is VOID.

3.All while loops that wait for a GUI event to terminate include a second expression/counter to prevent infinite loops.

Example:

iLoops = 1

while !MyWindow.Exists && iLoops < 60

… iLoops++

4. All switch statements have a default case, which may raise an error if no case is matched.

5.Place reusable functions in a file called myapp_funcs.inc.

6.Pathnames are never hard-coded. Instead use a const in a general.inc file that is either assigned explicitly or via

an environment variable.

Examples:

const SCRIPT_DIR = “ { HOST_GetEnv ( “ SCRIPT_DIR” ) } ”

const DATA_DIR = “ { SCRIPT_DIR }\data ”

7. All "included files" are listed in a file called usefiles.inc. The main frame file for the application under test includes

the statement use "usefiles.inc".

8.Include a single space between a method name and its argument list. There is no space between the parenthesis

and the first and last arguments.

Example: VOID Invoke (STRING sPath)

9.The optional message parameter in the Verify statement is always included to better explain the error condition

being generated.

Window Declaration Standards:

e Multi-tags only where necessary.

2.Objects are named as they are rendered in the application under test unless the name is ambiguous or long. In

those cases a clear, concise name can be substituted. Cute names are anathema.

3.Move declarations for controls that are not expected to be used to the bottom of the parent's window declaration,

e.g. StaticText.

4.Members variables and are placed at the top of a window declaration after the tag and parent statements.

Methods are placed next followed by declarations for child windows

Machine Independence

Tests should not be designed to run on a specific machine. A common mistake is made when tests assume a constant directory structure and refer to components using an absolute path. If tests are moved to another machine, errors are generated because files cannot be found. Refer to the standard regarding the use of SCRIPT_DIR above for a simple resolution to this problem.

Tests must also be independent of screen resolution when using bitmaps. Users are often surprised when every test fails due to bitmap errors when tests are moved to another machine. This weakness in the bitmap approach can be overcome by creating sets of bitmaps for each different screen resolution to be tested and testing for resolution at runtime using the registry (see the SilkTest help entry for SYS_GetRegistryValue

Commenting

Every test should include comments describing its intentions, test method and expected results. Any references to a script component located in a remote file should include its relative path and file name for easy location. Comments should also identify the author in case further explanation is needed. All non-trivial test code should be commented.

Each file should include a header like this:

Each method or function written should include the following information block: