Tuesday, May 31, 2011

Test Procedure Overview

A test procedure is an SQABasic or Visual Basic script that you record with SQA Robot.When you record a test Procedure,SQA Robot automatically captures user activities and stores them as a series of SQA Basic commands.Test Procedure script files have the same name as the test Procedure ID, but with a .REC extension.Test Procedure files are stored in the \Repository\PROCS sub directory.

If SQA Basic is your scripting language,the test procedure script is displayed in a child Window called the test procedure wi ndow.SQA Robot does not display the test procedure window if Visual Basic is your scripting language.

When you play back the test procedure,SQA Robot executes the activities You recorded.There are two types of test procedures:

•GUI procedure s:This contain the user`srecorded GUI actions,such as Keystrokes and mouse clicks.In regression tests.GUI procedures also contain one or more GUI test cases.

•Virtual user procedures:These contain the user`s recoded HTTP requests to aWeb server.

GUI Procedure Script Struture:

A typical GUI procedure has four major sections:
• Intialization commands
• Window restoration commands (optinal)
• User action and test case commands
• Closing commands

Intialization Commands:

All SQA Robot GUI procedure scripts must begin with the following commands:

SUB mAIN:

This defines the test procedure as a subroutine named Main.this is normally the first command in the script and should not be edited.

Dim result As Integer:

This defines the variable Result as an integer variable.SQA Robot returns the value from each test case function in the variable Result. The value for Result is local to the Main subroutine.
`Intially Recorded: 03/12/96 11:12:02
`Test procedure Name:Mortgage Prequalifier History:

SQA Robot writes two comment lines (which begin with a single quotation mark) in the initialization section of each script. The first tells when the the test procedure was recorded,and the second is the text entered as the name(not the ID)of the procedure.

InitPlay:

(visual Basic only) This is a subroutine defined by SQA Robot that initializes test procedure play back. It must always be the first command in a Visual Basic script.

Set ProcID “QBPRQ01”:

(Visual Basic only) This is a subroutine defined by SQA Robot that identifies the ID of the test Procedure. This always follows Init Play and always Precedes any user action commands in a Visual Basic script.

Window Restoring Commands:

The following commands record the sizes and positions of open windows so that SQA Robot can restore the testing environment during playback. They also indicate the windows within whin user actions occur.

StartSaveWindowPositions
EndSaveWindowPositions

These statements tell SQA Robot that, during plackback,the intervening Window SetContext, Window MoveTo, and Window SetPosition commands are for windows restoration only.All Playback timing defaults are set to zero to process these commands as quickly as possible.if any command fails b/t StartSaveWindowPositions, that failure is reported to the log as a Warning, not a script command failure.

Window SetContext
WindowSetPosition

The Window SetContext statement defines the context window for subsequent test cases and user actions,and Window SetPosition indicates the position,size, and status of that context window.These statements can vary,depending on the window within which user actions occur.During recording,SQA Robot saves the positions of Windows that are normal,minimized, or maximized if Auto Record Window Size is checked in the Recording Options dialog box. It does not save the positions of hidden windows. During playback, SQA Robot restores the Windows to their positions When the test procedure nwas recorded. SQA Robot writes messages to the test log for any windows it cannot find on playback.

User Actions and Test Case Commands :

Useraction commands represent the actions you take While recording aGUI procedure. They are not test cases, but represent your actions between test cases. User actions Within a Window are always preceded in the script by a Window Set Context statement establishing the context window within which the actions occur.

Push Buttons Click, “VBName=SelectOK;Visual Text=OK”
User actions statements always begin with an object type (PushButton,Window, EditBox,etc.) followed by the action applied to it (Click,Resize, VScrollTo, etc.).
Result=WindowTC(Compare Menu, “VBName=Main;
VisualText=Mortage Prequalifier”,
“CaseID=QBPRQ01a”)

Test case and wait state functions are preceded by the Result variable.A test case functions corresponds to a test case you insert in to the text procedure While recording. During Playback,if the test case passes, Result equals 1. If the test case fails, Result equals 0.

Closing Commands:

All GUIprocedure scripts must end with the following commands, while terminate the test procedure and reset

SQA Robot:
EndPlay :

(Visual Basic only) This is a subroutine defined by SQA Robot that terminates playback of aVisual Basic test procedure script.

EndSub:
This indicates the end of the Main subroutine.

InitPlay, SetProcID, and EndPlay are required by SQA Robot to initialize and terminate playback of Visual Basic scripts.These commands are not required for SQA Basic scripts

SQA Robot includes the StartSaveWindowPositions and EndSave Window Positions commands only if Save Window Positions is checked in the Recording Options dialog box. 

Command Types:

SQA Robot test procedure commands are organized into these these types,based on the tasks they perform in the script:

CONTROL FLOW COMMANDS: Define the Beginning and end ofSQA Robot scripts, and the beginning and end of commands that save and restore windows. Control flow tasks include initialization and termination for test procedure and Playback. Used only in GUI Procedures.

ObJECT SCRIPTING COMMANDS:Acess an application`s objects and object Properties from within a test Procedure script . Object Scripting tasks include retrieving and setting an object`s properties. Used only in GUI Procedures.

TEST CASE COMMANDS:Compare objects captured While playing are same,the test case passes (Result equals 1). If the objects are different, the test case fails back successive builds of the application-under-test against the established base line data. If the objects( Result equals0).Used only in GUI Procedure.

USER ACTION COMMANDS: correspond to user actions on specific objects While recording.Actions include operations like choosing a menu command. Scrolling a list box, clicking a button, or typing text in to an edit box. Used only in GUI Procedures.

UTILITY COMMANDS:Affect the flow of test Procedure playback by setting wait times,calling other test procedures, starting applications, starting applications , starting and stopping timers,and playing back low-level recordings. They also control output to the test log, retrieve results from running test procedures, and set characters used in statements.Used only in GUI Procedures.

If you have Virtual User Recording installed. You can use these SQA Basic commands:

Data Pool commands-Retrieve data from a datapool created with SQA Datapool Manager.
HTTP commands- Issue HTTP or HTTPS requests to aWeb server that is not SSL-protected.
HTTP/HTTPS commands-Issue HTTP or HTTPS requests to aWeb server,depending on whether the server is SSL-protected.

Virtual User commands-Perform operations in virtual user procedures. For example,virtual user commands perform synchronization and timer operations for virtual users, and handle communications between the Master and Agent test stations.Except for control flow commands,which must appear at the beginning and end of every script,the order of recorded commands depends on your recording options and user actions.

NAMING CONVENTIONS OVERVIEW:

SQA Robert requires you to assign an ID for each test procedure and test case (or wait state). These IDs have an eight character limit,imposed by the DOS filename restriction. Because test procedure and test case IDs are referred to in the SQA repository and in test procedure scripts, it is important that you establish and adhere to a naming convention. Having a Meaningful naming convention helps you identify the test item`s purpose.

Because SQA Robot complies Visual Basic test Procedures in to executables with .EXE extensions, aVisual Basic test procedure ID should not be the same as that of another .EXE program.
However,because SQA Robot compiles SQABasic test procedures into .SBX files,this restriction does not apply if SQABasic is your scripting language.

Test Procedure IDs

A test procedure ID should indicate which application or component the test procedure tests. To achieve this, you canj assign meanings to characters of the filename.

In this diagram two characters identify the testing phase of the application-under-test (for example,function testing,transaction testing,or performance testing), five characters identify the functional area that the procedure tests (the module within the application-under-test),and a different tests on the same application module.

This is only one way in which you can define meaningful test procedure IDS. You can define IDs in whatever way best suits your organization and the application-under-test. The pieces that your naming convention identifies may correspond directly to the test requirements hierarcthy defined using SQA Manager.
Test Case IDs: The ID you define for a test case should help you identify the application-under-test,the test procedure it is in,and the type of test case.

In this diagram,two characters identify the testing phase of the application-under-test,three characters identify the functional area or module that the procedure tests, two characters identify the test case type, and a single character indicates the sequence. You can use either numbers, letters,or both for the sequence character,Which allows up to 36 test cases (0 through 9 plus A through z) in a test procedure. How ever, SQA recommends that you not create such alarge test procedure. Instead of including many test cases, define test procedures that are short and modular.

Autonaming:
SQA Robot can assign IDs for test procedures and test cases with its autonaming feature, which you can set using the preferences dialog box. If Autonaming On is checked,SQA Robot automatically inserts default IDs for test procedures, test cases, or both. You can accept or change these default IDs.

The autonamed test case or wait state IDs consist of the test procedure ID plus a single consecutive alphabetic character. For example, if the test procedure ID is TESTI, the autonamed ID for the first test case (or wait state) inserted in to the procedure is TESTIA, the ID for the second test case is TESTIB,and so on. If you change the default test procedure ID, you should limit it to seven characters to allow the auto naming of test case IDs. Because of the eight character filename limit,SQA Robot cannot automatically generate test case or wait state IDs if a test procedure ID exceeds seven characters.

Managing Test Procedures Overview:

Every time you record a test procedure,SQA Robot automatically adds a test procedure ID and definition to the SQA Repository. SQA Robot also lets you define,modify,and delete test procedure definations in your test planning phase before any actual recording takes place. You can also define test procedures using SQA Manager, Which stores the test procedure IDs,names,and definations in the SQA Repository and makes them available for recording with SQA Robot.

Defining New Test Procedures:
To create a new test procedure ID and definition:
•Choose Admin Test Procedure.
•Choose New.

•Enter the information to define your new test procedure.
This information is displayed in the SQA Test Log Viewer when you examine playback results, and also in SQA Manager when you perform defect tracking and reporting.

•Choose Ok.
•Enter an ID of up to eight alphanumeric characters and choose OK.This becomes the test procedure ID in the selector list.
Test procedures you define in SQA Robot are also available to SQA Manager.
Modifying Test Procedures:
•Choose Admin Test Procedure.
SQA Robot lists all defined test procedures in the dialog box,regardless of whether or not they have been recorded.
•Select a test procedure from the list.
•Choose Open or double-click the test procedure in the list.
•Change the information to redefine your test procedure.
This information is displayed in the SQA Test Log Viewer when you examine playback results,and also in SQA Manager when you perform defect tracking and reporting.
•Choose OK.
Deleting Test Procedures:
•Choose Admin Test Procedure.

SQA Robot lists all defined test procedures in the dialog box, regardless of whether or not they have been recorded.

•Select one or more test procedures from the list, or choose Select All.

•Choose Delete.SQA Robot prompts you to confirm the deletion.

•Choose Yes or Yes to All to delete the the test procedures, choose No to retain the indicated test procedure,or choose Cancel to terminate the entire deletion process.

Test Procedure Recording Overview:

The type of user action you record varies, depending on whether you are recording a GUI procedure or a virtual user procedure. 

Recording GUI procedures:

When you record a GUI procedure, you typically record a sequence of user actions required to execute one or more test cases, or verification points, in an application-under-test. When you record a GUI procedure, SQA Robot creates a script that keeps track..[Continue next update]


View the original article here

Web Statistics