Test Design Studio

for QuickTest® Professional, WinRunner®, and Quality Center

  

Test Design Studio identifies syntax errors in real time as you type! All errors are underlined in the editor so that you can quickly identify the problem and fix it. QuickTest® Professional performs syntax checking when you save a file or think to kick it off manually, but Test Design Studio is constantly analyzing your syntax for immediate feedback.

Syntax checking is only half the story, and only ensures you follow the basic syntax of the language. Other errors are typically not revealed by QuickTest® Professional until you try to execute your tests because they are syntactically correct. These are the most time-consuming errors to fix because it is only during execution that you discover many silly mistakes. Oversights like declaring the same variable more than once because you copied/pasted code, forgetting to declare variables when 'Option Explicit' is used, or mistyping the name of a function/variable. When these issues are discovered at run-time, it usually means a significant loss of productivity. Tests have to be re-executed and application state must be restored.
 
Test Design Studio analyzes your code for many common errors and warns you about other potential logical errors. These issues are identified during design at the time of creation, not later when the code is actually executed and potential time has passed since the developer's mind was fresh. The following lists highlight many of the errors and warnings generated by Test Design Studio by static language analysis:
 
General:

• Promote use of the 'Option Explicit' statement to help enforce language rules.
• Cannot make duplicate declarations of variables in the same scope.
• Must use the various Exit statements in the proper context (i.e. using 'Exit Function' only within a 'Function' declaration).
• Check for proper use of parenthesis when invoking a function.
• Function calls must provide the proper number of arguments.
• Function calls and variable usage must refer to a known entity (identifies use of invalid or misspelled items).
• Ensure that object-based assignment statements use the 'Set' keyword, and non-object-based assignments do not.
• Warn on use of obsolete language elements (including the ability to mark your own elements as obsolete with XML comments).
• Identifier names cannot be too long.
• 'Select Case' constructs must have at least one 'Case' statement.

Class Declarations:

• Ensure classes instantiated with 'New' keyword are located in the same file as the statement instantiating it.
• Default Properties/Functions must be 'Public'.
• Only one member of a class can be 'Default'.
• A default property can only be defined on the 'Get' declaration.
• 'Class_Initialize' and 'Class_Terminate' cannot have arguments.
• Property declarations must have consistent argument signatures.
• Warn if public variables are used in a class instead of public properties.

Function/Sub Declaration:

• 'Sub' declarations must not attempt to return a value.
• Warn if a 'Function' declaration has no return value (did the developer forget?).
• Warn if a parameter is declared but never actually used.

All the errors and warnings generated by syntax checking and language analysis are aggregated into a single view for your entire project. The Error List tool window allows you to quickly see which errors or warnings need to be addressed.

Code Metrics are a useful tool implemented by Test Design Studio to provide an objective analysis of the complexity of your code. Higher code complexity typically leads to higher defect rates and decreased maintainability. The following metric values are calculated for major language elements including entire tests, class declarations, functions, and properties:

• Cyclomatic Complexity - measures the number of paths through your code. Inclusion of branch and loop statements (like 'If' and 'For') increases the number of paths.
• Lines of Code - counts the number of executable lines (ignores whitespace and comments).
• Halstead Metrics - (calculated behind the scenes) measures the vocabulary of your code by counting unique and total instances of operators and operands.
• Maintainability Index - all of the above metrics are used to calculate a maintainability index between 0 and 100. Values of 0-9 indicate high maintenance, 10-19 moderate maintenance, and 20-100 are low maintenance.

Test engineers can quickly locate code that might be hard to maintain or overly complex. Taking time to refactor the code can result in fewer errors and improved maintainability.