|
|
||
|
|
||
|
|
| |
678-662-3440
Table of Content
QuickTest Pro for WinRunner Developers
Define Test-Automation Architecture
Create Object Repository Files
Setup Default Behavioral Events
Setup Testing Options in the Script
Call WR Scripts and User-Defined
Functions
Automatically Submit Defects to
Quality Center
Use QuickTest Actions with LoadRunner
and Topaz
QuickTest Implementation RoadMap Modern music is nothing else,
but old tune upgraded to meet today’s technological standards… …Famous musician ProblemOver the past decade WinRunner became an industry standard as functional test-automation technology, gathering under its flag thousands of developers who improved their skills in this product over the years of their professional careers. However, we live in a very dynamic technological environment and have to comply with its standards. As we have noticed lately, more and more organizations have recognized the value of another one Mercury’s functional test-automation tools – QuickTest Pro. This tool has a slightly different approach to automation. If you‘ve been told by your manager that your group no longer will support WinRunner and you are going to implement QTP (QuickTest Pro), don’t get upset, and don’t hurry up to update your resume looking for a new job – you didn’t waste your time polishing your WinRunner skills. In fact, QuickTest is a great tool that was designed by the same group of engineers that created WinRunner. And, QTP has a lot of similarities to WR; and even has some more improved functionalities. In our consulting practice in ZAPtechnologies.com [Mercury Special Forces] we are coming across many developers who have outstanding knowledge and experience with WinRunner and need just a few pointers for starting to work with QuickTest. Today, I want to share with you as WinRunner experts, quick approach to implementation of QuickTest 8.x. A Few Things to Remember First of all, as a WR developer you need to know that unlike WinRunner, QuickTest has an “icon view” (Keyword View), however, like WinRunner, QuickTest has a “source code view” (Expert View). Additionally, QuickTest has a visible data table and an active screen (screenshots of steps performed on AUT).
Having WR experience, I’m sure most of you will feel comfortable with the Expert View. Saying that, you need to remember that QTP is using VBScript as its scripting language, a VB-like syntax with a simplified data structure (only variants), as well as a VB function library alone with QuickTest functions. Unlike TSL you don’t need to finish each line with semicolon, and you will not use curly brackets for segments of code. Instead, you still can group your code using With/End With statements for better readability of the code. You can enable a With statement in your script by selecting L_Ctrl + W hot-keys. Since the main targets in our functional testing are objects of the AUT (Application Under Test), as WR developers you have to remember, that QTP utilizes an Object Oriented technology. This means that all objects in QuickTest belong to its hierarchy, i.e. WebEdit object always will be belong to its Frame, Frame to its Table, Table to its Page, and Page to its Browser; as well as WinEdit object will always be belong to its dialog. Each object also has a collection of methods (functions in TSL) with their own arguments, which perform particular actions on these objects.
If you are going to assign variable to a statement, you need to include arguments of the method in the parentheses.
Components As fundamentals of any test-automation framework you need to define what components you are going to operate with. Basic components that you need to consider will be: Add-Ins, Object Repository Files, Actions, Data Tables, Recovery Scenarios, Generated Scripts of QTP Settings, Advanced Settings, External Libraries, and optional User-Defined Methods. Road Map Sequence for developing robust test-automation framework utilizing QuickTest will be as follows: · Define Test-Automation Architecture · Define Add-ins · Define Conventions · Setup Action Appearance · Create Object Repository Files · Create Data Tables · Setup Default Behavioral Events · Setup Testing Options in the Script · Develop Actions o Recording Modes o Checkpoints o Active Screen o Step Generator o Optional Steps · Define Parameters · Develop External Library · Register User-Defined Methods · Define Recovery Scenarios · Call WR Scripts and User-Defined Functions · Automatically Submit Defects to Quality Center
Let’s consider each of these steps in more details.
Define Test-Automation Architecture Similar to WinRunner-based frameworks, you can use QuickTest on stand-alone bases, or in conjunction with TestDirector. Our preferred architecture is Quality Center (Quality Management (a.k.a TestDirector) & QuickTest). Some of main benefits of using Quality Center architecture are modularity of test design and flexibility of test execution. By using Quality Management as your testing cockpit, you can design TestScripts divided by AUT functional area modules with parameters (Templates). Also, you can create TestSets, by combining TestScripts that will focus on testing particular functional areas of your AUT. You may define execution flows, execution conditions and on-failure recovery flows, thereby avoiding developing and maintaining sophisticated custom recovery functions simply by using Quality Management build-in functionalities. To find out more about our approach to Quality Center (a.k.a. TestSuite) based frameworks, you may refer to our Requirement-Driven Test Automation Process article. Define Add-insAs WR developers you familiar with Add-Ins. QuickTest Add-Ins designed to work in the similar manner, except the fact that QTP offers add-ins for some latest technologies like .NET and others. Just as with WinRunner, you need to know the development technologies of your AUT, and load your Add-Ins prior to invoking QuickTest.
Define ConventionsIf you have an experience working with a group of other WinRunner developers you probably will agree that scripting conventions are a very important part of the development process. Uniforming your code will improve the readability of your code and facilitate change management in your test-automation group, which will improve the overall Test Script development process. Since QTP uses VBScript as a scripting language, we found best to use Hungarian-like naming conventions (Microsoft VB naming conventions). You may use convention for literally any entity in your architecture. For example, you may name objects: txtObjectName, lstObjectName, btnObjectName…; variables – varVariableName, envVariableName; datasheets – dsDatasheetName; parameters column names – colParamenterName, or prmParamenterName, etc.
Setup Action AppearanceUnlike WinRunner, in QuickTest you may customize the appearance of your actions. Actions are segments of code, similar to sub procedures in VB. You may include startup script into your action template, Action header, Option Explicit, or any other statement that you want QuickTest to execute prior to a test run. You may customize your Actions by creating an Action Template. In order to do this, you need to:
Now every time you will open new QuickTest Action, your action template will be loaded.
Optional: you can create an Active Screen template in a similar manner. Create Object Repository FilesLike in WinRunner 7.x, QuickTest allows you to have Object Repository file per Action (on plug-and-play basis). However, if you planning to build robust test-automation framework, you will probably want to use Shared Object Repository file. In WinRunner, these are the “GUI Map per Test” and “Global GUI Map” settings, respectively. As a WinRunner developer you know importance of well-created GUI Map files. Just as you do with WinRunner and GUI Maps, you need to create Object Repository files that will contain all the objects under test in your AUT. We are highly recommend investing time in creating solid and accurate Object Repository files prior to Test Script development, which will have properly named objects. This will be efficient, especially when you work with group of other QTP developers. You cannot edit Object Repository files if it is shared and opened by someone else, however, you still can record your base-line script if all of your objects under test presented in the given file. Also, sharing framework components, including Object Repository files, will allow you to update their instances centralized, i.e. in one place. Like for example if software developers will update any object in your AUT, you can edit it’s properties in one file shared by all TestScripts. In addition to WinRunner GUI Map Editor functionalities, using the QTP Object Repository utility you can export your Object Repository file, invoke Object Spy (WR GUI Spy), edit object properties (for example to parameterize them), or change the way QTP will recognize object during test execution (for example to enable Smart Identification). Also, a like that WinRunner QuickTest 8.x allows you to highlight given object on AUT using ‘Highlight’ functionality.
Create Data TablesThe Data Driving mechanism in QuickTest is, for most part,
built similar to WinRunner, except the fact that the Data Table is visible in
the QTP IDE and you can use most of Excel functionalities including multiple
datasheets. You need to remember that QTP
operates with datasheets of given Data Table, and by default creates Global
datasheet (dtGlobalSheet) and Local datasheet (dtLocalSheet, or
<ActionNameSheet>). You can follow
QTP conventional data structures and use either the Global datasheet, or the
Action local datasheet; or if you are certain about the data in your AUT, you
may structure your data datasheet-per-AUT_functional_area, etc. However, if you are planning to create flexible data structures and use full QTP built-in Data Driving functionalities, you need to know that if you set Action properties to execute on all rows (‘Run on all rows’), your Action will iterate according to number of data rows in the given datasheet. For this you will probably want to use the Global datasheet for global data only, or in most cases only for passing parameters between Actions.
Setup Default Behavioral EventsUnlike WinRunner, QuickTest allows you to set up Behavioral Events that QTP will execute by default. One of the settings is available in the Web Add-in (Tools > Options > Web tab > Advanced button > Advanced dialog). Using these settings you may, for example, set QTP to create Automatic Accessibility checkpoints per each web page, create global web page checkpoint during recording as you navigate to next page, perform browser clean-up as you test exiting execution, and many more. This will allow you to expedite your Test Script development process and reduce maintenance of the scripts.
Setup Testing Options in the ScriptYou can set QuickTest settings dynamically in your script by creating .vbs files using ‘Generate Script’ functionalities available in QTP. There are three places in QuickTest where you can generate script based on settings defined in QTP dialogs: General Options (Tools > Options), Test Settings (Test > Settings), and Object Identification (Tools > Object Identification). There are few ways you can use QTP settings scripts. First you may generate scripts and refer to them in your Startup script that will be called in your Action Template. This way you will ensure that QuickTest will maintain same settings during test execution. Also, you may use (copy/paste) fragments of given setting script in your Actions on ad-hoc basis.
Develop ActionsAs WinRunner developers you need to remember that QuickTest is the fully Event-Driven technology, and strongly presumes test modularity. Similar to LoadRunner Vugen QTP structured by Actions – sub procedures, which perform certain actions on AUT in the test. There are two main types of Actions: Regular Actions (Non-Reusable Actions), and Reusable Actions Regular Actions (regular sub procedures) are actions that can be used only in the test in which they were created, and only once. Regular Actions are similar to WinRunner script. Reusable Actions – Actions that can be called by other Actions, either regular or reusable (in similar manner to WinRunner compiled modules). Reusable Actions also have two types: Internal and External. Internal Actions are Reusable Actions that created and used in the given test on local scope. External Actions – Reusable Actions that were created in another test as Internal Actions and called by the given test.
The process of creating a Reusable Action is very simple. First you record and enhance a Test Script in the same manner as a regular (Non-Reusable) Action, and then you set Action Properties as Reusable.
Besides calling Actions, you can also copy them. You can copy any type of action, either regular or Reusable. Once you copy an Action, QuickTest creates an editable local copy of the copied Action into your test. Also, you can split an Action. Splitting Actions is very useful, allowing you to divide your test by multiple Actions, and/or create Reusable ones. Keyword ViewAs an experienced WinRunner developer you probably familiar with Keyword-Driven test automation frameworks, and know how efficient these frameworks became in QA, allowing Subject Matter Experts and Business Analysts to develop automated scripts using plain English. However, if you had experience developing and maintaining these frameworks you also know the cost associated with it. Being custom architectures and based primarily on Compiled Modules, development of such frameworks used to take long time and involved highly skilled WinRunner specialists. Also, maintenance of Keyword-Driven framework was very tidiest, since it required updating custom crafted and low-level WinRunner code, in most cases with no supplementary documentation and support. QuickTest 8.x offers Keyword-Driven framework as a component of the tool!
Utilizing Keyword View QuickTest 8.x allows developing TestScripts without recording them (you just have to make sure that all Test Objects of Application Under Test are stored in the object repository). Keyword View consists of six (6) components (columns): Item, Operation, Value, Documentation, Assignment, and Comments. Item
Column - contains the items on which
you want to perform the steps (test object, utility object, function call, or
statement). This column displays a hierarchical icon-based tree (similar to
Tree View in previous versions of QuickTest). The highest level of the tree are
actions or components, and all steps are contained within the relevant branch
of the tree. Steps performed within the same parent object are displayed under
that same object. Function calls, utility objects, and statements are placed in
the tree hierarchy at the same level as the item above them (as a sibling).
Operation
Column - contains the operations to be
performed on the item. This column contains a list of all available operations
(methods or functions) that can be performed on the item selected in the Item
column, for example Click and Select. The default operation for the item
selected in the Item column is displayed by default.
Value
Column - contains the argument values
for the selected operation, or the content of the statement. The Value cell is
partitioned according to the number of arguments of the selected operation.
Value Column also allows you to parameteraze the value of the given Operation (similar to Method Argument future in
previous versions of QuickTest).
Assignment
Column - contains the assignment of a
value to or from a variable, for example, Store In varAgentname would store the return value of the
GetROProperty step in a variable called varAgentName, which you could then use later in
the test or component.
Comment
Column – contains
comments from the given step. These are also displayed as inline comments in the Expert View.
Documentation
Column - contains read-only
auto-documentation of what the step does, in an easy-to-understand sentence.
Documentation column allows you to generate TestStep similar to the one we
develop as a Design Step in Quality Management (TestDirector), or in MSWord or
Excel.
Utilizing Documentation collumn functionality will allow your to
develop proper documentation for the given TesScript during automation, that
will tramendousely expedite development and maintenance of TestScript
documentation. Its also important to mention that QuickTest 8.x enables printing of the Keyword View
data –
easy-to-understand TestScript steps in plain English.
Recording ModesUnlike WinRunner, besides regular Context Sensitive recording, QuickTest has Analog Recording and Low Level Recording modes. I feel some note of criticism from WR gurus regarding Analog recording, and this where it will get tricky. Now, pay attention – WR-like analog recording mode is implemented slightly different in QTP. QuickTest uses two ways of capturing keystrokes and mouse movements: Analog Recording - enables you to record the exact mouse and
keyboard operations you perform in relation to either the screen or the
application window. In this recording
mode, QuickTest records and tracks every movement of the mouse as you drag the
mouse around a screen or window. This
mode is useful for recording operations that cannot be recorded at the level of
an object, for example, recording a signature produced by dragging the
mouse. You need to remember, that QTP’s
Analog recording is captured as black-box files – Tracks and stores them in the
directory of your test, i.e. you can not edit them through QuickTest interface,
however, there is a way to edit Tracks, using Analog Recording Parcer
utility available in QuickTest Plus. Low Level Recording - enables you to record on any object in your application, whether or not QuickTest recognizes the specific object or the specific operation. This mode records at the object level and records all run-time objects as Window or WinObject test objects. Use low-level recording for recording tests in an environment or on an object not recognized by QuickTest. You can also use low-level recording if the exact coordinates of the object are important for your test. As you can see, QTP Low Level Recording mode is the one similar to WR Analog Recording mode.
CheckpointsAs a WR expert you know that any Test Script has to have checkpoints. Besides WinRunner-like set of checkpoints you can use XML and Accessibility checkpoints.
QuickTest offers improved checkpoint functionalities compared to WinRunner. Using QuickTest checkpoints you can parameterize object properties you’d like to check, measure page load-time, check for broken links in your web page, and much more.
Alternatively, if you are fan of custom checkpoints, like some WinRunner developers are, you can use the GetROProperty method to check the runtime value of an object in your AUT.
Active ScreenOne of the very powerful functionalities of QuickTest is Active Screen. The Active Screen is the functionality that provides a snapshot of your application, as it appeared when you performed a certain step while recording your test. Using the Active Screen you may set checkpoints after recording, create output values, or create steps using Method Argument utility.
In case you created a custom step in your test and you would like to associate the active screen with this step, or change captured one, you can assign a screenshot using the Change Active Screen functionality (Tools > Change Active Screen). Step GeneratorSimilar to WinRunner’s Function Generator, QuickTest 8.x offers Step Generator. The Step Generator utility enables you to add steps in your TestScript that perform operations, using test object methods, utility object methods, or function calls. If you just started to work with QTP, you may find this utility very handy. You may access the Step Generator three ways:
As an alternative, you can insert methods in your script manually by selecting it from method list. If you type a dot ‘.’ following your object, QTP will invoke list of methods available for this object. Select desired method and follow the tool tips to insert arguments for this method.
This technique also applies to manually inserting objects in your script. You need to remember, however, that in order to use object list, this object has to be captured in Object Repository. Optional StepsQuickTest offers alternative to Recovery Scenarios (WR 7.5 – 7.6) way of bypassing appearance of unexpected objects during the test run. For example, let’s say your AUT generates error message if your input data exceeding allowed boundary, in this case instead of creating Recovery Scenario to handle this situation, you just may record this step in your test and mark that as an Optional Step. If, during the next test run your input data will be valid and this error message will not appear, QuickTest wont fail the test, but will bypass this step and will continue test execution. We found it useful to use Optional Step technique in cases when step is a part of the AUT business process, otherwise we would recommend using Recovery Scenarios.
Define ParametersSimilar to WinRunner, QTP uses a DataDriver Wizard, where you can parameterize either all values in objects parameterization-candidates, or only desired ones.
It is also very useful to know that you can pass parameters in QuickTest 8.x either by using Output Values, Environment Variables, Using Data Table method for Global or Local data sheets, or similar to WinRunner using either Test Parameters or Action Parameters. However, unlike WinRunner, QTP 8.x alone with Input Parameters allows you to specify Output Parameters. Output parameters - specifies the parameters that the test or component can pass to the source that runs or calls it. Also, you may specify type of the Input and Output parameter: String, Boolean, Date, Number, Password, or Any. You may specify Test Parameters selecting Test Settings > Parameters tab. Accordingly Action Parameters may be specified either by selecting Step > Action Properties from QTP tool bar, or by right clicking on action icon and selecting Action Properties from sub-menu (Keyword View only). As an QuickTest Experts most of your activities will be in Expert View, instead of selecting input (or output) parameters from the appropriate dialog boxes while parameterizing steps or inserting output value steps, you can enter input and output parameters as values in the Expert View using the Parameter utility object: Parameter("ParameterName"). Parameterization is very much improved in QuickTest compared to WinRunner. You can parameterize not only input and select values, but also object properties, and checkpoints, to give you more flexibility in Test Script development. You may also create parameters using system or user-defined environment variables, random numbers, or regular expression.
Develop External LibrarySimilar to Compiled Module (Function) Libraries in WinRunner, you may create user-defined function libraries using VBScript syntax. You may save your functions as .vbs or .txt files, set it in QTP Test Settings and call it by function name similar to WinRunner. Debugging QTP External User-Defined Functions is easier than WinRunner compiled modules – you don’t need to reload function library every time you need to execute function, you may even keep your file open, just make sure you saved the changes. We found it to be a good practice to develop functions using QTP and then copy/paste the source code into text file. You just need to make sure you will not use any checkpoints or analog recording files in your functions, since they reside in QTP test directories. If you need to use checkpoints, we recommend creating Reusable Actions instead.
Register User-Defined MethodsSince methods in QuickTest caring functionalities of functions in WinRunner, you can create library of user-defined methods associated with particular object. For example in your framework you will use parameter to define which radio button to select. In this case in order to implement Select method on WebRadio class objects you are going to write few lines of code including proper reporting. Instead you may develop user–defined function and associate it with user-defined method.
Define Recovery Scenarios
Recovery Scenarios in QuickTest 8.x implemented using same Recovery Scenario Wizard as the Compound Recovery Scenarios Wizard available in WinRunner 7.5 and 7.6. In case you have not had a chance to work with these versions of WinRunner, you need to know that unlike Exception Handler utility available in previous versions of WinRunner and QuickTest, Recovery Scenario Wizard in QuickTest 8.x offers the ability to create multiple recovery paths for your test including post-recovery. There are four trigger-event types of recovery scenarios: Pop-up Window, Object State, Test Run Error, and Application Crash. Some of these triggers have options using user-defined functions similar to Simple Recovery Scenarios (Exception Handlers in earlier WR versions) in WinRunner. |
