Macromedia FLEX 2 User Manual

™

Flex

Adobe

Testing Flex Applications with Mercury QuickTest Professional

Testing Flex™ Applications with Mercury QuickTest Professional™

If this guide is distributed with software that includes an end-user agreement, this guide, as well as the software described in it, is furnished under license and may be used or copied only in accordance with the terms of such license. Except as permitted by any such license, no part of this guide may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without the prior written permission of Adobe Systems Incorporated. Please note that the content in this guide is protected under copyright law even if it is not distributed with software that includes an end-user license agreement.

The content of this guide is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Adobe Systems Incorporated. Adobe Systems Incorporated assumes no responsibility or liability for any errors or inaccuracies that may appear in the informational content contained in this guide.

Please remember that existing artwork or images that you may want to include in your project may be protected under copyright law. The unauthorized incorporation of such material into your new work could be a violation of the rights of the copyright owner. Please be sure to obtain any permission required from the copyright owner.

Any references to company names in sample templates are for demonstration purposes only and are not intended to refer to any actual organization.

Adobe, the Adobe logo, Flex, Flex Builder and Flash Player are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. ActiveX and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Linux is a registered trademark of Linus Torvalds. Solaris is a registered trademark or trademark of Sun Microsystems, Inc. in the United States and other countries. All other trademarks are the property of their respective owners. Quicktest and Mercury Quicktest Professional are registered trademarks or trademarks of Mercury Interactive Corporation or its wholly-owned subsidiaries, Freshwater Software, Inc. and Mercury Interactive (Israel) Ltd. in the United States and/or other countries.

This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Macromedia Flash 8 video is powered by On2 TrueMotion video technology. © 1992-2005 On2 Technologies, Inc. All Rights Reserved. http:// www.on2.com. This product includes software developed by the OpenSymphony Group (http://www.opensymphony.com/). Portions licensed from Nellymoser (www.nellymoser.com). Portions utilize Microsoft Windows Media Technologies. Copyright (c) 1999-2002 Microsoft Corporation. All Rights Reserved. Includes DVD creation technology used under license from Sonic Solutions. Copyright 1996-2005 Sonic Solutions. All Rights Reserved. This Product includes code licensed from RSA Data Security. Portions copyright Right Hemisphere, Inc. This product includes software developed by the OpenSymphony Group (http://www.opensymphony.com/).

Adobe Systems Incorporated, 345 Park Avenue, San Jose, California 95110, USA

Notice to U.S. government end users. The software and documentation are “Commercial Items,” as that term is defined at 48 C.F.R. §2.101, consisting of “Commercial Computer Software” and “Commercial Computer Software Documentation,” as such terms are used in 48 C.F.R. §12.212 or 48 C.F.R. §227.7202, as applicable. Consistent with 48 C.F.R. §12.212 or 48 C.F.R.

§§227.7202-1 through 227.7202-4, as applicable, the Commercial Computer Software and Commercial Computer Software Documentation are being licensed to U.S. Government end users (a) only as Commercial items and (b) with only those rights as are granted to all other end users pursuant to the terms and conditions herein. Unpublished-rights reserved under the copyright laws of the United States. Adobe Systems Incorporated, 345 Park Avenue, San Jose, CA 95110-2704, USA. For U.S. Government End Users, Adobe agrees to comply with all applicable equal opportunity laws including, if appropriate, the provisions of Executive Order 11246, as amended, Section 402 of the Vietnam Era Veterans Readjustment Assistance Act of 1974 (38 USC 4212), and Section 503 of the Rehabilitation Act of 1973, as amended, and the regulations at 41 CFR Parts 60-1 through 60-60, 60-250 ,and 60-741. The affirmative action clause and regulations contained in the preceding sentence shall be incorporated by reference.

Chapter 1: Working with QuickTest Professional . . . . . . . . . . . . . . 5

Introduction to the testing process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Deploying Flex files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

About the Flex installed testing files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

About the testing environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Test creation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

About the QTP object model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Storing objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

About the application hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Recording tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

About the testing script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Identifying objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

About operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Using checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Standard checkpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Bitmap checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Table checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Using common methods and properties . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Playing back Flex tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 2: Advanced Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Working with containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Working with Repeater objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Working with data-driven and List-based controls. . . . . . . . . . . . . . . . 22

Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

General troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Resolving playback synchronization issues . . . . . . . . . . . . . . . . . . . . 24

Delaying startup test time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Making a test fail but continue to the end . . . . . . . . . . . . . . . . . . . . . . 28

Limitations of automated testing with Flex. . . . . . . . . . . . . . . . . . . . . . . 29

4Contents

CHAPTER 1

Working with QuickTest Professional

This topic describes how to work with Mercury QuickTest Professional™ and Adobe Flex applications.

Contents

Introduction to the testing process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Test creation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Recording tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

About the testing script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

About operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Using checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Using common methods and properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Playing back Flex tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Introduction to the testing process

Large, complex applications must be tested to make sure that user interactions do not create run-time exceptions and that connections to data services are functioning properly.

This document assumes that there are two roles in the testing process: the QA testing professional and the Flex developer. It assumes that the QA testing professional does not know how to develop Flex applications and does not have access to the Flex source code, the Flex compiler, or the Flex documentation. The Flex developer, on the other hand, does not necessarily know how to use a testing tool, such as Mercury QuickTest Professional (QTP).

Flex documentation for developers includes a set of guidelines for creating testable applications. These guidelines include instructions on how to compile testable applications, how to instrument custom components so that they can be tested, and how to write applications so that the testing process works more smoothly. For information about the guidelines, see the Flex 2 Developer’s Guide.

Before you can test a Flex application, a Flex developer compiles a SWF file for you. The developer also provides you with an HTML file that embeds the SWF file in it. This is known as the HTML wrapper. You deploy these two files to any web server.

Some Flex applications require the use of external resources, such as web services or remote objects, so you should ensure that your web server can access these resources. You might be required to add a permissions file to the target server to allow your Flex application to access the server. For more information, ask the Flex developer.

To run a test, you launch QTP and request the HTML wrapper. QTP records the interaction with the Flex application as it would with any other target type. You should then be able to rerun your tests against the Flex application as long as the web server remains accessible.

Deploying Flex files

Before you can test the Flex application, you must deploy the application and its supporting files to a location that is accessible by QTP. These files include:

■ Application SWF file

■ HTML wrapper and wrapper files (the wrapper files can include SWF files, JavaScript

files, and other files)

■ RSL SWC files

■ Module SWF files

■ Helper files such as theme SWC files, style SWF files, and image, video, and sound files

You deploy the Flex application and HTML wrapper file to any location on your HTTP server. You must be able to access this location from QTP.

In some cases, files used by the Flex application might be located on a remote server. In this case, you must be sure that the files are accessible through any firewalls. Furthermore, the remote servers might need to include cross-domain permission files to allow remote access. For more information, you should discuss this with the Flex developer.

If necessary, you can password-protect the HTML wrapper and use the QTP authentication mechanism to access it. For more information, see the QTP documentation.

6 Working with QuickTest Professional

About the Flex installed testing files

The Flex support for QTP requires that you install two ActiveX plug-ins on the testing machine. These plug-ins provide the necessary communication layer between Flex and QTP. One plug-in runs inside of QTP, and the other runs inside the browser. The browser plug-in is signed, and is designed to run in Microsoft Internet Explorer 6 on Windows only. Together, these plug-ins ensure that Flash Player and the Flex framework can send the appropriate script interactions to QTP during record mode.

Similarly, the plug-ins provide the mechanism for QTP to send script commands to the Flash Player and Flex during playback. The browser plug-in uses the Flash Player flash.external.ExternalInterface class and, therefore, requires the correct security context for flash.external.ExternalInterface to run. If the SWF file runs from a web server, the Flash Player automatically enables flash.external.ExternalInterface. If the SWF file runs from a local file system, the SWF file must be trusted for flash.external.ExternalInterface to be enabled and for the browser plug-in to work properly. If the plug-ins have problems loading, the cause is written to the Flash Player debug log file.

About the testing environment

Flex component names reflect the nature of the component. For example, a button is a Button control in the Flex programming environment. In the testing environment, the name of each testable control is prefixed with Flex; for example, a Button control is known as FlexButton in the QTP scripts. This prevents controls from different types of applications from being confused in your scripts.

All visual Flex components can be scripted in your quality control tests. Most of their properties and methods can be recorded and then played back. Each method stores a certain number of properties.

When you create a test for the first time, notice that visual controls are usually referenced inside containers. Not all containers that are used by Flex programmers are reflected in the testing environment. For example, a set of buttons might be inside a horizontal box container (or HBox), but that HBox control might not show up in the test script. Restricting the controls in the scripts makes the scripts easier to read and keeps the hierarchies as short as possible without losing detail.

The tea.html document includes a complete list of Flex components that you can test. You can also view the testable methods and properties of these components in that document.

Introduction to the testing process 7

Test creation overview

When you record a test, QTP records the lines of the test script correlating to each action that you performed. Each line typically represents an action that you carried out on a component that appears on the screen. Those components are called objects and the actions you perform on them (such as clicking a button) are called operations.

The basic building block of a test is the test object. Objects are stored in the QTP object repository. You should understand how QTP identifies objects and adds them to the object repository. For more information, see “Identifying objects” on page 14.

To create a narrative for a test, you record a series of operations or events on the test objects. It is important to understand which events are recognized by QTP. For Flex developers who want to add events to the list of supported ones for each object, see the Flex 2 Developer’s Guide.

Most QTP tests use checkpoints to compare output values against known values. Flex supports a subset of the types of checkpoints that are used in QTP. For more information, see

“Using checkpoints” on page 17.

If you encounter problems while testing Flex applications, you should refer to

“Troubleshooting” on page 22. This section describes error codes and their meanings, and

describes some common problems that can occur when using the Flex plugin with QTP.

About the QTP object model

Before you create a test, it is important to understand how the object model of the QTP and Flex are integrated. The test object model is a set of object types that QTP uses to represent objects that are used in your application. The test object model maps the QTP test objects to the Flex objects in your application. For example, a Button control in a Flex application is recognized as a FlexButton in the QTP object model.

The QTP test objects store properties and record events during the test. Each object has its own set of properties and methods that QTP can record. Test objects do not support all events and properties of the Flex objects that they correspond to, but they do support the events that are most commonly associated with users’ gestures.

The object repository is a list of all objects used in the test. To add an object to a test, you must add it to the object repository. To remove an object from the test, you remove it from the object repository.

8 Working with QuickTest Professional

Operations are actions that you perform on objects. They are equivalent to a Flex event, but are generally at a higher level. For example, when you click on a Button, QTP records a “click” operation. QTP does not record the mouseDown and mouseUp events, which essentially make up the click event.

Each operation has one or more arguments that define information about the event. This information includes details such as what keys were held down when the operation occurred or the index of a selected item in a list.

Not all controls have operations. For example, the FlexRule controls do not have operations. You can still add these controls to the object repository and use checkpoints to test object properties. Other controls without operations, such as FlexRepeater and FlexDisplayObject, are low-level objects that you generally do not have to interact with for your tests.

Automated testing requires that each component be identifiable by a set of persistent unchanging properties, with one main one, automationName, which is human readable and easily associated with its on-screen counterpart. Collectively, this set of properties is called the automation ID. QTP stores the automation ID in a repository. A change to a component’s ID results in multiple versions of the object in the repository. Additionally, QA engineers can create data driven scripts by changing these IDs with IDs from a database.

QTP specifically avoids treating list items as components, because the identifiers for list items can change in an editable list, and identifiers can repeat (for example, a data grid with rows that have repeating text). Also, creating and or requiring entries in the repository for list items can create a huge burden for data driven scripts, because you must put all of your list items in the repository and change many objects in the repository.

Storing objects

With QTP, you can record and play back your interaction with the Flex application or you can write the script yourself. It is generally easier to have QTP record your actions with a Flex application, and then modify that recorded script. During a recording session, QTP adds the Flex objects that you interact with to the object repository. Otherwise, you would have to define each object separately before using it in your own script.

When QTP encounters a Flex control during a test, it stores a set of properties that describe that object and stores a reference to it in the object repository. The definition of the Flex control in the QTP object repository contains enough information for QTP to map that Flex control (such as, Button) to a test object (such as, FlexButton).

Test creation overview 9

+ 21 hidden pages