Testen von Adobe® Flex® 4-Anwendungen mit HP QuickTest ... · PDF fileTESTEN VON FLEX 4-ANWENDUNGEN MIT HP QUICKTEST PROFESSIONAL Arbeiten mit QuickTest Professional 4 und

Testen von ADOBE® FLEX® 4-Anwendungen mit

HP QuickTest Professional

Letzte Aktualisierung 4.3.2010

Copyright© 2010 Adobe Systems Incorporated. All rights reserved.

Testen von Adobe® Flex® 4-Anwendungen mit HP 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, Flash, Flash Builder, Flex, and Flex Builder and are either registered trademarks or trademarks of Adobe Systems Incorporated in the

United States and/or other countries. HP is a registered trademark of Hewlett-Packard Company. ActiveX and Windows are either registered trademarks or

trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are the property of their respective owners.

This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

This product contains either BISAFE and/or TIPEM software by RSA Data Security, Inc.

The Flash Builder 4 software contains code provided by the Eclipse Foundation (“Eclipse Code”). The source code for the Eclipse Code as contained in Flash

Builder 4 software (“Eclipse Source Code”) is made available under the terms of the Eclipse Public License v1.0 which is provided herein, and is also available at

http://www.eclipse.org/legal/epl-v10.html.

Adobe Systems Incorporated, 345 Park Avenue, San Jose, CA 95110-2704, 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. 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.

iiiLetzte Aktualisierung 4.3.2010

Inhalt

Kapitel 1: Arbeiten mit QuickTest Professional

Einführung in das Testverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Erstellen von Tests – Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Aufzeichnen von Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Einführung in Testskripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Einführung in Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Verwenden von Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Häufig verwendete Methoden und Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Wiedergeben von Flex-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Kapitel 2: Erweiterte Konzepte

Arbeiten mit Containern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Arbeiten mit Repeater-Objekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Arbeiten mit datengesteuerten und listenbasierten Steuerelementen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Fehlerbehebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Beschränkungen automatischer Testverfahren mit Flex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1Letzte Aktualisierung 4.3.2010

Kapitel 1: Arbeiten mit QuickTest Professional

Einführung in das Testverfahren

Umfangreiche und komplexe Anwendungen müssen getestet werden, um zu gewährleisten, dass

Benutzerinteraktionen keine Laufzeitausnahmen auslösen und Verbindungen zu Datendiensten ordnungsgemäß

funktionieren.

In diesem Dokument wird von zwei am Testverfahren beteiligten Rollen ausgegangen: dem Fachmann für QA-Tests

und dem Flex-Entwickler. Des Weiteren wird angenommen, dass der QA-Mitarbeiter mit dem Entwickeln von

Anwendungen nicht vertraut ist und auf den Flex-Quellcode, den Flex-Compiler sowie die Flex-Dokumentation nicht

zugreifen kann. Der Flex-Entwickler auf der anderen Seite weiß nicht unbedingt, wie ein Testtool wie HP QuickTest

Professional (QTP) zu verwenden ist.

Die Flex-Dokumentation für Entwickler enthält eine Reihe von Richtlinien zum Erstellen prüffähiger Anwendungen.

Diese Richtlinien enthalten Anweisungen dazu, wie prüffähige Anwendungen zu kompilieren sind, benutzerdefinierte

Komponenten so instrumentiert werden, dass sie getestet werden können, und wie Anwendungen geschrieben werden

müssen, damit der Testvorgang reibungslos ausgeführt werden kann. Informationen zu den Richtlinien finden Sie

unter Using Adobe Flex 4.

Bevor Sie eine Anwendung testen können, kompiliert ein Flex-Entwickler eine SWF-Datei für Sie. Der Entwickler

stellt Ihnen außerdem eine HTML-Datei zur Verfügung, in die die SWF-Datei eingebettet ist. Diese Datei wird als

HTML-Wrapper bezeichnet. Sie stellen diese beiden Dateien sowie die ggf. erforderlichen extern geladenen Elemente

wie Bild- und Videodateien auf einem beliebigen Webserver bereit.

Für einige Anwendungen ist die Verwendung von externen Ressourcen wie Webservices und Remote-Objekten

erforderlich. Stellen Sie sicher, dass Ihr Webserver auf diese Ressourcen zugreifen kann. Beispiel: Eine Anwendung

ruft eine PHP-Datei auf einem Remoteserver (z. B. http://yourserver.com/YourFile.php) auf. Stellen Sie in diesem Fall

sicher, dass Sie von Ihrem Testserver aus auf die PHP-Datei zugreifen können.

Möglicherweise müssen Sie auch dem Zielserver eine Berechtigungsdatei hinzufügen, damit Ihre Anwendung auf den

Server zugreifen kann. Die Berechtigungsdateien heißen crossdomain.xml-Dateien. Weitere Informationen erhalten

Sie vom Flex-Entwickler.

Um einen Test auszuführen, starten Sie QTP und fordern den HTML-Wrapper an. QTP zeichnet die Interaktion mit

der Anwendung wie bei jedem anderen Zieltyp auf. Anschließend sollten Sie die Tests der Anwendung so lange

wiederholen können, wie der Webserver zugänglich bleibt.

Bereitstellen von Flex-Dateien

Bevor Sie die Anwendung testen können, stellen Sie diese zusammen mit den sie unterstützenden Dateien an einem

Speicherort bereit, auf den QTP zugreifen kann. Dies umfasst die folgenden Dateien:

• SWF-Datei der Anwendung

• HTML-Wrapper und Wrapper-Dateien (die Wrapper-Datei kann SWF-Dateien, JavaScript-Dateien und andere

Dateien enthalten, die Unterstützung für Funktionen wie tiefe Verknüpfungen, das so genannte Deep Linking, und

die Verlaufsverwaltung bieten).

• RSL SWC-Dateien

http://www.adobe.com/go/learn_flex4_usingflex_de

2TESTEN VON FLEX 4-ANWENDUNGEN MIT HP QUICKTEST PROFESSIONAL

Arbeiten mit QuickTest ProfessionalLetzte Aktualisierung 4.3.2010

• SWF-Dateien von Modulen

• Helper-Dateien wie SWC-Dateien für Design, SWF-Dateien für Stile sowie Grafik-, Video- und Audiodateien.

Sie stellen die Anwendung und die HTML-Wrapper-Datei an einem beliebigen Speicherort auf Ihrem HTTP-Server

bereit. Dieser Speicherort muss von QTP aus zugänglich sein.

In einigen Fällen befinden sich Dateien, die von der Anwendung verwendet werden, auf einem Remoteserver. Stellen

Sie dann sicher, dass der Zugriff auf die Dateien trotz ggf. vorhandener Firewalls möglich ist. Die Remoteserver

erfordern darüber hinaus möglicherweise domänenübergreifende Berechtigungsdateien für den Fernzugriff. Weitere

Informationen erhalten Sie vom Flex-Entwickler.

Bei Bedarf können Sie den HTML-Wrapper durch ein Kennwort schützen und mithilfe der QTP-

Authentifizierungsfunktion auf ihn zugreifen. Weitere Informationen können Sie der QTP-Dokumentation

entnehmen.

Einführung in die Flex- und AIR-Add-ins

Für die Unterstützung von QTP durch Flex ist die Installation der folgenden Add-ins auf dem Testrechner

ierforderlich:

• Flex QTP-Add-in

• AIR QTP-Add-in

Diese Add-ins stellen die zwischen den Flex- und AIR-Anwendungen einerseits und QTP andererseits erforderliche

Kommunikationsebene zur Verfügung. Diese Plug-ins stellen sicher, dass Adobe® Flash® Player und das Flex-

Framework bei aktiviertem Aufzeichnungsmodus die entsprechenden Skriptinteraktionen an QTP senden können.

Das Flex QTP-Add-in wird in QTP ausgeführt. Es sorgt dafür, dass QTP die Skriptbefehle während der Wiedergabe

an den Flash Player senden kann.

Das AIR QTP-Add-in ist für das Testen von AIR-Anwendungen vorgesehen. Es wird in QTP ausgeführt. Wenn Sie

AIR-Anwendungen testen möchten, starten Sie vor der AIR-Anwendung zuerst QTP.

Auswählen von Add-ins

Beim Starten von QTP wählen Sie aus, welche Add-ins verwendet werden sollen. Die verfügbaren Add-ins werden

Ihnen im Add-in Manager von QTP angezeigt. Für das Testen von Anwendungen wählen Sie das Flex Add-in. Für das

Testen von AIR-Anwendungen wählen Sie das AIR Add-in.

Wählen Sie für mit Flex erstellte Anwendungen im Add-in Manager zusätzlich zum Flex Add-in immer auch das Web

Add-in. Die zusätzliche Auswahl des Web Add-ins ist für AIR-Anwendungen nicht erforderlich.

Wählen Sie nur die von Ihnen benötigten Add-ins. Laden Sie nicht mehr als die für Ihre Tests notwendigen Add-ins.

Einführung in das ActiveX Browser-Plug-in

Über diese QTP-Add-ins hinaus erfordert das Testen von Anwendungen in QTP auch ein ActiveX Browser-Plug-in

für Microsoft Internet Explorer 6 oder höher. Dieses Plug-in wird installiert, wenn Sie die Flex QTP-Stapeldatei

ausführen.

Das Browser-Plug-in ist ein signiertes ActiveX-Plug-in. Es verwendet die Flash Player-Klasse

flash.external.ExternalInterface. Für deren Ausführung ist der korrekte Sicherheitskontext erforderlich.



Wenn die SWF-Datei von einem Webserver ausgeführt wird, aktiviert Flash Player automatisch die Klasse

flash.external.ExternalInterface. Wird die SWF-Datei dagegen auf einem lokalen Dateisystem ausgeführt, muss die

SWF-Datei vertrauenswürdig sein, damit flash.external.ExternalInterface aktiviert wird und das Browser-Plug-in

ordnungsgemäß funktioniert.

Treten beim Laden der Plug-ins Probleme auf, wird die Ursache hierfür in die Debug-Protokolldatei von Flash Player

geschrieben.

Einführung in die Testumgebung

Die Namen der Komponenten weisen darauf hin, um welche Art von Komponente es sich handelt. So entspricht zum

Beispiel eine Schaltfläche (engl. Button) einem Button-Steuerelement in der Flex-Programmierumgebung. In der

Testumgebung erhält der Name jedes prüfbaren Steuerelements ein Präfix, das den Komponententyp beschreibt.

Das Präfix richtet sich nach der für die Kompilierung verwendeten Anwendung (AIR oder Flex) und danach, welchem

Komponentensatz die Komponente angehört (Halo/MX oder Spark). Hierdurch wird verhindert, dass Steuerelemente

aus unterschiedlichen Anwendungstypen und Komponentensätzen in Ihren Skripten verwechselt werden.

In der folgenden Tabelle werden diese Präfixe beschrieben:

Die Funktionalität der Steuerelemente ist ähnlich, jedoch handelt es sich um unterschiedliche Steuerelemente. Spark-

Steuerelemente stammen aus dem neueren Spark-Komponentensatz. Steuerelemente ohne die Bezeichnung „Spark“

gehen aus dem älteren Komponentensatz „MX“ hervor (oder aus „Halo“). Es gibt Anwendungen, die Steuerelemente

aus nur einem Komponentensatz enthalten. Andere Anwendungen hingegen verwenden eine Kombination aus

Spark- und MX-Steuerelementen. Beispielsweise gibt es in Spark keine Entsprechung zum DataGrid-Steuerelement.

Im Allgemeinen hat dies jedoch keine Auswirkungen auf die Tests.

In Ihren Tests zur Qualitätskontrolle können die meisten visuellen Flex-Komponenten durch Skripten gesteuert

werden. Die gängigsten Eigenschaften und Methoden dieser Komponenten können aufgezeichnet, getestet und

wiedergegeben werden.

Wenn Sie zum ersten Mal einen Test erstellen, beachten Sie, dass visuelle Steuerelemente normalerweise in Containern

referenziert werden. Allerdings finden sich nicht alle Container, die von Flex-Programmierern verwendet werden, in

der Testumgebung wieder. So können sich beispielsweise mehrere Schaltflächen in einem Horizontal Group

Container (oder HGroup) befinden, ohne dass das HGroup-Steuerelement im Testskript verfügbar ist. Durch die

Beschränkung der Steuerelemente in den Skripten werden die Skripte lesefreundlicher und Hierarchien werden so

kurz wie möglich gehalten, ohne dass Details verloren gehen.

Dokument „QTP Object Type Information“

Das Dokument „QTP Object Type Information“ (tea.html) enthält eine vollständige Liste der Flex MX-Komponenten,

die gestestet werden können. Dieses Dokument können Sie unter der folgenden Adresse herunterladen:

www.adobe.com/go/flex3_qtp_object_type_reference

QTP-Präfix Bezeichnung Beispiel (wie in QTP angezeigt)

Flex MX- (oder Halo-)Komponente in einer Flex-

Anwendung.

FlexButton

Spark Spark-Komponente in einer Flex-Anwendung. SparkButton

AirFlex MX- (oder Halo-)Komponente in einer AIR-Anwendung. AirFlexButton

SparkAir Spark-Komponente in einer AIR-Anwendung. SparkAirButton

http://www.adobe.com/go/flex3_qtp_object_type_reference



Es enthält auch die prüfbaren Methoden und Eigenschaften der einzelnen Komponenten.

Derzeit steht keine Liste der prüfbaren Methoden und Eigenschaften von Spark-Komponenten zur Verfügung.

Erstellen von Tests – Überblick

Wenn Sie einen Test aufzeichnen, zeichnet QTP die Zeilen des Testskripts auf, die den einzelnen von Ihnen

ausgeführten Aktionen entsprechen. Normalerweise steht eine Zeile für jeweils eine Aktion, die Sie auf einer der auf

dem Bildschirm angezeigten Komponenten ausgeführt haben. Diese Komponenten werden als Objekte bezeichnet,

und bei den darauf ausgeführten Aktionen (z. B. Klicken auf eine Schaltfläche) handelt es sich um Operations.

Den grundlegenden Baustein eines Tests stellt das Testobjekt dar. Objekte werden in QTP im Object Repository

abgelegt. Sie sollten damit vertraut sein, wie QTP Objekte identifiziert und sie dem Object Repository hinzufügt.

Weitere Informationen finden Sie unter „Identifizieren von Objekten“ auf Seite 9.

Um eine Testsequenz zu erstellen, zeichnen Sie eine Reihe von Operations oder Ereignissen an den Testobjekten auf.

Hierfür ist es unerlässlich zu wissen, welche Ereignisse von QTP erkannt werden können. Flex-Entwickler, die weitere

Ereignisse zur Liste der für die einzelnen Objekte unterstützten Ereignisse hinzufügen möchten, finden hierzu

Informationen im Handbuch Using Adobe Flex 4.

Die meisten QTP-Tests verwenden Checkpoints, um Ausgabewerte mit bekannten Werten zu vergleichen. Flex

unterstützt eine Untergruppe von Checkpoint-Typen, die in QTP verwendet werden. Weitere Informationen finden

Sie unter „Verwenden von Checkpoints“ auf Seite 11.

Wenn beim Testen von Anwendungen Probleme auftreten, lesen Sie unter „Fehlerbehebung“ auf Seite 15 nach. In

diesem Abschnitt werden Fehlercodes sowie deren Bedeutung erläutert. Außerdem werden einige häufig auftretende

Probleme beschrieben, die beim Verwenden des Flex-Plug-ins mit QTP auftreten können.

Einführung in das QTP-Objektmodell

Bevor Sie einen Test erstellen, sollten Sie sich damit vertraut machen, wie das Objektmodell von QTP und Flex

integriert sind. Das Testobjektmodell entspricht einer Gruppe von Objekttypen, mit deren Hilfe QTP die in Ihrer

Anwendung verwendeten Objekte darstellt. Das Testobjektmodell ordnet die QTP-Testobjekte den Flex-Objekten in

Ihrer Anwendung zu. So entspricht ein Button-Steuerelement in einer Anwendung einem FlexButton im QTP-

Objektmodell.

Dem Dokument „QTP Object Type Information“ können Sie eine vollständige Liste der Flex-Objekte und Angaben

dazu entnehmen, wie sie im QTP-Objektmodul erscheinen. Dieses Dokument beschreibt die Operations und

Eigenschaften von Objekten, die beim Testen von Anwendungen mit QTP verfügbar sind.

Während des Tests speichern die QTP-Testobjekte Eigenschaften und zeichnen Ereignisse auf. Jedes Objekt verfügt

über eigene Eigenschaften und Methoden, die QTP aufzeichnen kann. Die Testobjekte unterstützen nicht sämtliche

Ereignisse und Eigenschaften der ihnen jeweils entsprechenden Flex-Objekte. Sie unterstützen jedoch diejenigen

Ereignisse, die mit den Benutzeraktionen am häufigsten verknüpft sind.

Das Object Repository entspricht einer Liste aller Objekte, die in einem Test verwendet werden. Um einem Test ein

Objekt hinzuzufügen, fügen Sie es dem Object Repository hinzu. Um ein Objekt aus einem Test zu entfernen,

entfernen Sie es aus dem Object Repository.

Operations sind Aktionen, die Sie an Objekten ausführen. Sie entsprechen einem Flex-Ereignis, werden jedoch in der

Regel auf einer höheren Ebene ausgeführt. Wenn Sie beispielsweise auf eine Schaltfläche klicken, zeichnet QTP eine

„click operation“ auf. Die mouseDown- und mouseUp-Ereignisse, die im Wesentlichen das Klickereignis bilden,

zeichnet QTP nicht auf.



Jede Operation verfügt über ein oder mehrere Argumente, die Informationen zum Ereignis definieren. Diese

Informationen enthalten Einzelheiten wie die Tasten, die beim Auftreten der Operation gedrückt gehalten wurden,

und die Indexposition eines ausgewählten Elements in einer Liste.

Nicht alle Steuerelemente weisen Operations auf. Zum Beispiel verfügt das FlexRule-Steuerelement (eine horizontale

oder vertikale Linie) nicht über Operations. Sie können Steuerelemente ohne Operations dennoch zum Object

Repository hinzufügen und Checkpoints zum Testen der Objekteigenschaften verwenden. Weitere Steuerelemente

ohne Operation wie die FlexRepeater- und FlexDisplayObject-Steuerelemente sind Low-Level-Objekte, mit denen Sie

bei Ihren Tests in der Regel nicht interagieren müssen.

Für automatisierte Tests ist es erforderlich, dass jede Komponente durch eine Gruppe von dauerhaft unveränderlichen

Eigenschaften gekennzeichnet wird. Die wichtigste Eigenschaft ist dabei automationName. Diese kann von Menschen

gelesen werden und problemlos mit dem entsprechenden Gegenstück auf dem Bildschirm verknüpft werden.

Gemeinsam wird diese Gruppe von Eigenschaften als Automation ID bezeichnet. QTP speichert die Automation ID

in einem Repository. Eine Änderung der ID einer Komponente führt zu mehreren Versionen des Objekts im

Repository. Darüber hinaus können QA-Mitarbeiter datengesteuerte Skripte erstellen, indem sie diese IDs durch IDs

aus einer Datenbank ersetzen.

Bei QTP werden Listenelemente ausdrücklich nicht als Komponenten behandelt, da sich die IDs der Listenelemente

in einer bearbeitbaren Liste ändern können und die IDs sich auch wiederholen können (Beispiel: ein Datenraster mit

Zeilen, die sich wiederholenden Text enthalten). Außerdem kann durch das Erstellen oder Anfordern von Einträgen

im Repository für Listenelemente eine große Last für datengesteuerte Skripte entstehen, da Sie alle Ihre Listenelemente

in das Repository einfügen und viele Objekte im Repository ändern müssen.

Verwandte Themen

„Dokument „QTP Object Type Information““ auf Seite 3

Speichern von Objekten

Mit QTP können Sie Ihre Interaktionen mit der Anwendung aufzeichnen und wiedergeben oder das Skript selbst

schreiben. In der Regel ist es einfacher, QTP das Aufzeichnen Ihrer Aktionen in der Anwendung zu überlassen und

anschließend das aufgezeichnete Skript zu ändern. Während einer Aufzeichnungssitzung fügt QTP die Flex-Objekte,

mit denen Sie interagieren, dem Object Repository hinzu. Andernfalls müssen Sie jedes Objekt einzeln definieren,

damit Sie es in Ihrem eigenen Skript verwenden können.

Wenn QTP während eines Tests auf ein Flex-Steuerelement trifft, speichert es eine Reihe von Eigenschaften, die das

Objekt beschreiben, sowie einen Verweis auf das Objekt im Object Repository. Die Definition des Flex-Steuerelements

im Object Repository von QTP enthält genügend Informationen, die es QTP ermöglichen, dieses Flex-Steuerelement

(z. B. Button) einem Testobjekt (z. B. FlexButton) zuzuordnen.

Im folgenden Beispiel ist ein FlexButton-Steuerelement im QTP Repository Editor dargestellt:



A. Name des Testobjekts B. Klasse des Testobjektmodells C. Flex-Eigenschaften, die zum Identifizieren des Objekts verwendet werden D. Anwendungshierarchie

Wenn Sie einen Test ausführen und mit einem Flex-Steuerelement interagieren, führt QTP die folgenden Schritte aus:

1 Identifizieren der Testobjektklasse, der Ihr Flex-Objekt zugeordnet wird

2 Lesen des aktuellen Status des Objekts und Speichern von dessen Liste mit beschreibenden Eigenschaften und

Werten

3 Zuweisen einer eindeutigen ID, die zum Identifizieren des Objekts in den Skripten verwendet wird. QTP kann eine

oder mehrere Objekteigenschaften verwenden. Die Eigenschaften können auf dem Aussehen des Flex-

Steuerelements (z. B. der Beschriftung) oder der Flex-ID des Steuerelements basieren.

4 Aufzeichnen der Operations, die Sie mithilfe der entsprechenden Testobjektmethode am Objekt durchführen.

Wenn ein Test ausgeführt wird, speichert QTP Komponenteneigenschaften als Name/Wert-Paare. QTP speichert nur

Eigenschaften, die für die Identifizierung im Object Repository benötigt werden. Zu diesen Eigenschaften gehören id

und index. Sie können Checkpoints, Datentabellen und sonstige Methoden zum Speichern und Abrufen weiterer

Objekteigenschaften verwenden. Eine Eigenschaft kann der Wert des Texts eines TextInput-Steuerelements sein oder

der Wert der Farbe eines Button-Steuerelements.

Einführung in die Anwendungshierarchie

Im Object Repository werden Objekte in einer Hierarchie gespeichert. Der Stamm der Hierarchie entspricht dem

Browser. Das folgende Element ist das Anwendungsobjekt. Darunter befinden sich die Container und Steuerelemente,

die die Anwendung bilden.

Im Object Repository und der Keyword View von QTP stellt eine Baumstruktur die Containerebenen der Anwendung

dar. In der Regel folgt die Hierarchie der visuellen Darstellung der Anwendung. In der Anwendung „MyApp“

erscheint die Hierarchie eines Button-Steuerelements mit der Beschriftung „Submit“ in einer TabNavigator-Ansicht

mit der Beschriftung „Change Settings“ beispielsweise wie folgt:

D

A

C

B



Browser | Application ("MyApp") | Panel ("Change Settings") | Button ("Submit")

In QTP-Skripten verwenden Sie für den Zugriff auf Objekte eine Punktnotationssyntax, bei der die einzelnen Ebenen

jeweils durch einen Punkt getrennt sind. Auf ein Button-Steuerelement verweisen Sie mit einem Pfad wie dem

folgenden:

Browser("Home").FlexApplication("MyApp").FlexPanel("Change Settings").FlexButton("Submit")

Weitere Informationen dazu, wie ein QTP-Skript Anwendungen anzeigt, finden Sie unter „Einführung in Testskripte“

auf Seite 8.

Um das Lesen der Skripten zu erleichtern, werden einige Flex-Container in der Hierarchie ausgelassen, wenn der

Container keine Auswirkungen auf den Test hat. Ein TabNavigator-Container enthält z. B. weitere Container, etwa

HBox oder Panel. Der TabNavigator-Container selbst erscheint in der Hierarchie nicht, die Container seiner einzelnen

Registerkarten hingegen schon.

Die Anwendungshierarchie wird auch als Anzeigehierarchie bezeichnet, da sie in der Regel in einer Baumstruktur

darstellt, was Sie auf dem Bildschirm sehen. Die Anzeigehierarchie entspricht nicht immer der

Automatisierungshierarchie. Bei dieser handelt es sich um die Hierarchie der Objekte, auf die in den QTP-Skripten

verwiesen wird. Manchmal sind Container, die auf dem Bildschirm angezeigt werden (z. B. mit einem Rahmen oder

in einem Fenster), Bestandteil der Anzeigehierarchie, nicht jedoch Bestandteil der Automatisierungshierarchie.

Wenn ein Container nicht auf dem Bildschirm angezeigt wird, erscheint er in der Regel auch nicht in der

Testhierarchie. Beispiel: Ein eigenständiger HGroup-Container wird häufig zum Anordnen von Inhalt verwendet. Der

HGroup-Container wird selbst nicht visuell dargestellt und erscheint im Allgemeinen auch nicht in den Testskripten.

Die einzige Ausnahme hiervon bildet der Fall, wenn der Container ein untergeordnetes Element von TabNavigator ist.

Hier wird der Container benötigt, um den Inhalt eindeutig zu identifizieren, und ist deshalb Bestandteil der

Hierarchie. Weitere Informationen zur Verwendung des TabNavigator-Containers und weiterer Container finden Sie

unter „Arbeiten mit Containern“ auf Seite 14.

Aufzeichnen von Tests

Um einen Test in QTP aufzeichnen zu können, benötigen Sie eine kompilierte Anwendung als SWF-Datei und

HTML-Wrapper-Dateien. Die Wrapper-Hauptdatei definiert die Anwendung als Objekt auf der Seite und bettet sie

ein, sodass bei Anforderung der Seite Flash Player aufgerufen wird. Es ist nicht möglich, die SWF-Datei der

Anwendung direkt aufzurufen. Der Entwickler oder Sie können die HTML-Wrapper-Datei selbst schreiben oder der

Entwickler kann sie mit dem Compiler generieren.

Sie verweisen QTP auf die Wrapper-Datei, in der die SWF-Datei der Anwendung eingebettet ist.

Um einen Test aufzuzeichnen, legen Sie entweder fest, dass QTP den Text im derzeit geöffneten Browser ausführen

soll, oder Sie geben den Speicherort der Anwendung als URL an. Im letztgenannten Fall startet QTP den Browser und

übergibt die von Ihnen angegebene Anforderungs-URL. Welche Methode verwendet werden soll, legen Sie im

Dialogfeld „Record and Run Settings“ fest.

Normalerweise übergeben Sie den HTML-Wrapper von einem Webserver an den QTP-Client. Fordern Sie die

HTML-Wrapper-Datei nicht im Dateisystem an.



Damit QTP eine Anwendung testen kann, die aktuell in einem geöffneten Browserfenster ausgeführt wird, aktivieren

Sie das Optionsfeld „Record and run test on any open browser“. Damit QTP einen Browser öffnet und eine URL

anfordert, aktivieren Sie das zweite Optionsfeld wie im folgenden Beispiel gezeigt:

Wenn Sie den Test wiedergeben, öffnet QTP den Browser und fordert dieselbe URL an.

Einführung in Testskripte

QTP zeichnet den Test in einer als Keyword View bezeichneten Objektebene auf sowie in einer reinen Textansicht der

Schritte, die als Expert View bezeichnet wird. Änderungen, die Sie in der einen Ansicht vornehmen, werden von QTP

in der jeweils anderen Ansicht nachgezogen. Wenn Sie beispielsweise einen Schritt in der Expert View entfernen,

entfernt QTP diesen Schritt auch aus der Keyword View. Dasselbe gilt für das Hinzufügen von Schritten sowie das

Hinzufügen und Entfernen von Checkpoints.

In der Expert View wird jeder Testschritt als Aktion in VBScript dargestellt. VBScript verwendet die Punktnotation,

um übergeordnete von untergeordneten Elementen zu trennen. Jede Zeile endet mit einer Aktion gefolgt von

Parametern, die die Aktion definieren.

Im folgenden Beispiel ist eine Mausklick-Operation in der Expert View dargestellt:

Browser("Main Page").FlexApplication("MyApp").FlexButton("b2").Click

Die Syntax der Expert View lautet wie folgt:

Browser("document_title").FlexApplication("application_name").test_object("name").operation [parameters]

Die document_title-Eigenschaft wird durch das <TITLE>-Tag im <HEAD>-Block einer HTML-Seite definiert. Bei

einer Flex-Anwendung ist der Standardwert des <TITLE>-Tags in einem HTML-Wrapper die URL zur MXML-Datei.

Wenn die Seite keinen Titel aufweist, verwendet QTP den Titel Browser.

Die app_name-Eigenschaft entspricht der ID-Eigenschaft der SWF-Datei, die in das <object>-Tag der HTML-Seite

eingebettet ist.



Das test_object ist das QTP-Testobjekt, das dem Flex-Steuerelement entspricht. Das QTP-Testobjekt eines Button-

Steuerelements ist beispielsweise FlexButton. Dieses Objekt verfügt über eine name-Eigenschaft, die den QTP-Namen

für das Objekt angibt, wie er im Object Repository angezeigt wird. Dieser Name basiert in der Regel auf dem Aussehen

(z. B. der Beschriftung), gelegentlich ist er mit der Flex-ID im Flex-MXML-Quellcode identisch.

Die operation-Eigenschaft entspricht dem Ereignis, das von dem Objekt ausgelöst wird, das QTP aufzeichnet. Diese

Eigenschaft kann null oder mehr Parameter aufweisen.

Anzahl und Typ der Parameter einer Operation hängen vom Typ des Steuerelements ab, das das Ereignis auslöst. Bei

den Parametern kann es sich um eine Taste handeln, die während der Operation gedrückt gehalten wurde, die

Indexposition eines Listeneintrags oder den Text, der in ein Textfeld eingegeben wurde.

Wenn ein Benutzer beispielsweise Zeichen in ein FlexTextArea-Objekt eingibt, wird der vom Benutzer eingegebene

Text nach der Operation angezeigt. Wenn der Benutzer die Zahl 42 in ein FlexTextArea-Objekt eingegeben hat, wird

in der Expert View eine Anweisung ähnlich dem folgenden Beispiel angezeigt:

Browser("Main Page").FlexApplication("MyApp").FlexTextArea("ta1").Input "42"

Wenn der Benutzer Text in einem FlexTextArea-Objekt auswählt, zeichnet QTP eine Select-Operation auf. Diese

Operation weist zwei durch Komma getrennte Parameter auf. Der erste Parameter gibt die Startzeichenposition und

der zweite die Endzeichenposition der Auswahl an. Wenn der Benutzer die ersten vier Zeichen in einem FlexTextArea-

Objekt ausgewählt hat, zeigt die Expert View eine Anweisung ähnlich dem folgenden Beispiel an:

Browser("Main Page").FlexApplication("MyApp").FlexTextArea("ta1").Select 0,3

Identifizieren von Objekten

In QTP stellen Testobjekte die Bausteine der Testskripte dar. Alle in einem Test verwendeten Objekte werden im

Object Repository gespeichert. Diesen QTP-Testobjekten werden Flex-Steuerelemente zugeordnet.

Wenn Sie einen Test aufzeichnen, fügt QTP jedes Objekt, mit dem Sie interagieren, dem Object Repository hinzu. QTP

verweist auf dieses Objekt anhand seines Testobjektnamens im Skript. Die von QTP verwendete ID entspricht der

name-Eigenschaft des Testobjekts im Repository. Diese Eigenschaft entspricht teilweise der Flex-ID, die der Flex-

Entwickler im Quellcode der Flex-Anwendung angibt. Beispiel: Ein ComboBox-Steuerelement mit der Flex-

ID"myCombo" wird im Object Repository unter dem Namen „myCombo“ gespeichert. In QTP-Skripten verweisen Sie

entsprechend dem folgenden Beispiel darauf:

FlexComboBox("myCombo")

Flex-Objekte werden in Skripten jedoch nicht immer durch ihre Flex-ID-Eigenschaften identifiziert. In vielen Fällen

entspricht der Testobjektname dem, was Sie auf dem Bildschirm sehen. Der QTP-Testobjektname eines FlexButton-

Objekts entspricht beispielsweise dem Wert der label-Eigenschaft des Objekts und nicht der id-Eigenschaft. Das

folgende FlexButton-Steuerelement wird in QTP im Object Repository beispielsweise als "Click Me" identifiziert:

In der Expert View von QTP verweisen Sie auf das FlexButton-Objekt entsprechend dem folgenden Beispiel:

FlexButton("Click Me")

Wenn das FlexButton-Objekt keine Beschriftung aufweist, verwendet QTP die QuickInfo des Button-Steuerelements

als Testobjektnamen. Ist keine Beschriftung und keine QuickInfo verfügbar, verwendet QTP die id-Eigenschaft des

Quellcodes. Hat der Flex-Entwickler keine id angegeben, verwendet QTP die Indexposition. Fehlen alle diese

Angaben, verwendet QTP sein eigenes Nummerierungsschema, um das Objekt zu identifizieren.



In welcher Reihenfolge die Eigenschaften zur Bestimmung des Testobjektnamens verwendet werden, variiert in

Abhängigkeit vom Objekt. Weitere Objekte, deren Testobjektnamen von den id-Eigenschaften in Flex abweichen,

sind: FlexAccordionHeader, FlexButtonBarButton, FlexCheckBox, FlexLink, FlexPopUpButton, FlexRadioButton,

FlexScrollThumb, FlexSimpleButton, FlexSliderThumb und FlexTab.

Einführung in Operations

Wenn Sie während einer Aufzeichnung mit einer Anwendung interagieren, werden Ihre Aktionen in einem QTP-

Skript gespeichert. Aktionen wie beispielsweise das Klicken auf eine Schaltfläche definieren die Sequenz des

Testskripts. Sie werden in QTP als Operations bezeichnet, in Flex dagegen als Ereignisse. Jede Operation definiert eine

Interaktion mit einem Steuerelement der Anwendung. Komplexe Interaktionen mit Anwendungen erfolgen im

Allgemeinen durch eine Kombination mehrerer Operations. Zu derartigen Operations zählt das Ausfüllen und

Absenden von Formularen oder das Ziehen mehrerer Objekte und das Ablegen an einer bestimmten Position.

Flex-Steuerelemente wie z. B. Button definieren viele Ereignisse. Sie umfassen häufig vorkommende Ereignisse wie

click, showToolTip und focusIn. Doch es kommen auch selten oder nie direkt vom Benutzer aufgerufene

Ereignisse wie creationComplete, render und invalid vor. Flex steuert auch Auslöseereignisse feinerer

Granularität als für Tests im Allgemeinen erforderlich. Hierzu gehören mouseMove, keyDown und focusOut.

Die am häufigsten verwendeten Flex-Ereignisse stehen in QTP als Operation zur Verfügung. QTP zeichnet jedoch

nicht alle Ereignisse auf. Vielmehr zeichnet QTP die für die Semantik wichtigen Aktionen auf, sowie Operations, die

eine logische Einheit bilden. Beispiel: Wenn Sie ein Objekt in einem ComboBox-Steuerelement wählen, zeichnet QTP

statt der Ereignissequenz von mouseDown, open, drag, mouseUp und close einfach nur das open- und das select-

Ereignis auf.

Einige Ereignisse sind vollkommen ausgeschlossen, diese können Sie jedoch manuell zum Wiedergabeskript

hinzufügen. So wird zum Beispiel das mouseMove-Ereignis des FlexApplication-Objekts standardmäßig nicht

aufgezeichnet. Andernfalls müsste in das Skript für jedes Pixel der Mausbewegung jeweils ein neuer Schritt eingefügt

werden. Dadurch würde der Test schnell überfrachtet. Sie können QTP anweisen, dieses Ereignis wiederzugeben,

indem Sie es dem Testskript manuell hinzufügen. Eine Liste der für jede Flex-Komponente verfügbaren Operations

können Sie dem Dokument „QTP Object Type Information“ entnehmen:

www.adobe.com/go/flex3_qtp_object_type_reference

In einigen Fällen werden Benutzeraktionen von QTP als Folge kleinerer Ereignisse wiedergegeben. Das Klickereignis

wird in Abhängigkeit davon, wie es ausgelöst wurde (beispielsweise als mouseDown- und mouseUp- bzw. keydown- und

keyUp-Ereignispaar), wiedergegeben.

QTP speichert für jede Operation mehrere Parameter, die Aspekte der Operation definieren. Diese Parameter

enthalten z. B. Informationen darüber, welche Tasten beim Klicken mit der Maus gedrückt wurden, oder wie die x/y-

Position des Ziels einer Drag & Drop-Operation lautet. Mit Operation-Parametern wird auch aufgezeichnet, womit

Interaktionen ausgelöst wurden (z. B. Tastatur oder Maus).

QTP zeichnet auf, wie die aufgezeichneten Operations an Flex-Steuerelementen ausgeführt werden. Dabei wird

festgehalten, ob Ereignisse über die Maus oder Tastatur ausgelöst wurden, da die Wiedergabe in diesen Fällen

unterschiedlich sein kann. Wenn beispielsweise mit der Maus auf eine Schaltfläche geklickt wird, werden die

folgenden Ereignisse ausgelöst: mouseDown, mouseUp und click. Wenn das Klicken auf die Schaltfläche jedoch durch

Drücken der Leertaste, als die Schaltfläche im Fokus war, erfolgte, lauten die ausgelösten Ereignisse keyDown, keyUp

und click.

http://www.adobe.com/go/flex3_qtp_object_type_reference



Damit die Skripte leichter lesbar sind, hält das Flex-Plug-in die Anzahl der im Skript aufgezeichneten

Ereignisparameter möglichst gering. Um die Aufzeichnung häufig vorkommender Daten zu vermindern, ist in QTP

für jede Operation ein Standardparameter verfügbar. Der Standardwert für den Interaktionstyp des Klickens auf eine

Schaltfläche lautet „mouse“. Wenn ein Operation-Parameter mit dem Standardwert identisch ist, zeichnet QTP die

Operation nicht auf. Beispiel: Statt Folgendes aufzuzeichnen:

FlexButton("buttonId").Click "mouse"

zeichnet QTP nur Folgendes auf:

FlexButton("buttonId").Click

Die Standardaktion ist das Klicken mit der Maus, da das Klicken auf FlexButton in den meisten Fällen mit der Maus

und nicht über die Tastatur erfolgt.

Verwenden von Checkpoints

Mit Checkpoints können Sie Objekte prüfen. Je nachdem, ob das Objekt den erwarteten Wert aufweist, schlägt der

Test fehl oder wird bestanden. Während des Tests vergleicht QTP den aktuellen Wert mit dem am Checkpoint

erwarteten Wert. Wenn die Werte nicht übereinstimmen, schlägt der Test fehl. Stimmen sie überein, ist der Test

bestanden.

Das Flex QTP-Plug-in unterstützt die folgenden Checkpoint-Typen:

• Bitmap

• Standard

• Tabelle

Das Flex QTP-Plug-in unterstützt die folgenden Checkpoint-Typen nicht:

• Barrierefreiheit

• Datenbank

• Image

• Seite

• Text

• XML

Standard-Checkpoints

Mit Standard-Checkpoints können Sie die Eigenschaften von Steuerelementen prüfen. Es ist möglich, jedes Flex-

Objekt im Object Repository zu prüfen. Zu den prüfbaren Eigenschaften gehören sowohl Informationen zum Status

des Objekts (z. B. die text-Eigenschaft eines TextArea-Steuerelements) als auch Informationen zum Aussehen des

Objekts (wie z. B. die color-Stileigenschaft oder die height- und width-Eigenschaften).

Bei den verfügbaren Eigenschaften handelt es sich um eine Untergruppe der vollständigen Eigenschaftsgruppe des

Flex-Steuerelements, die die am häufigsten verwendeten Eigenschaften enthält. Eine Liste der für jede Flex-

Komponente verfügbaren Operations können Sie dem Dokument „QTP Object Type Information“ entnehmen.

Im folgenden Beispiel ist ein Teil eines Skripts dargestellt, in dem die Check-Methode verwendet wird, die überprüft,

ob der tatsächliche Wert eines Objekts mit dem erwarteten Wert übereinstimmt:



Browser("FlexStore").FlexApplication("flexstore").FlexCanvas("Support"). FlexForm("index:4").Check CheckPoint("index:4")

Weitere Informationen finden Sie in der QuickTest Professional Object Model Reference.

Bitmap-Checkpoints

Stellen Sie bei der Verwendung von Bitmap-Checkpoints sicher, dass Sie die Unterschiede im Aussehen von Flex-

Objekten berücksichtigen. Diese Unterschiede können durch den Tabulatorfokus auf einem Testobjekt oder die

Reaktion eines Objekts auf ein mouseOver-Ereignis verursacht werden. Wenn Sie einen Bitmap-Checkpoint zu einem

Bereich der Anwendung hinzufügen, in dem sich ein Objekt mit Fokus (und dem Haloeffekt um das Objekt) befindet,

stellen Sie sicher, dass das Objekt während des Tests im Fokus ist.

Das folgende Beispiel zeigt die Unterschiede zwischen einem FlexButton-Testobjekt ohne Fokus, einem FlexButton-

Objekt im Fokus und einem FlexButton-Objekt mit Mouse-over:

FlexImage-Objekte befinden sich niemals sichtbar im Fokus, sodass dieser bei Verwendung eines Bitmap-Checkpoints

für das Prüfen von Bildern nicht von Bedeutung ist.

Tabellen-Checkpoints

Mit Tabellen-Checkpoints können Sie Eigenschaften in listenbasierten Steuerelementen und Containern prüfen. Sie

können Tabellen-Checkpoints bei allen listenbasierten Flex-Steuerelementen wie List-, DataGrid-, TileList- und Tree-

Steuerelementen verwenden. Außerdem können Sie Tabellen-Checkpoints auch bei allen Containern verwenden, die

eine Liste der automationValues aller in ihnen enthaltenen untergeordneten Elemente generieren.

Häufig verwendete Methoden und Eigenschaften

Flex-Testobjekte unterstützen die Methoden und Eigenschaften, die von allen QTP-Testobjekten verwendet werden.

Folgende Methoden werden häufig verwendet:

• CaptureBitmap

• Check

• CheckProperty

• ChildObjects

• GetROProperty

• GetTOProperty

Folgende Eigenschaften werden häufig verwendet:

• Exist

• Object

Sie können die häufig verwendeten Methoden und Eigenschaften in der Keyword View und in der Expert View

verwenden. Im folgenden Expert View-Beispiel wird mithilfe der CheckProperty()-Methode geprüft, ob die

visible-Eigenschaft des myList-Steuerelements auf false eingestellt ist.



Browser("My Page").FlexApplication("MyApp").FlexCheckBox("myList").CheckProperty "visible", false

Informationen zu häufig verwendeten Methoden und den Eigenschaften der QTP-Testobjekte finden Sie in der QTP

Object Model Reference.

Wiedergeben von Flex-Tests

Für die Testwiedergabe braucht Ihr Browser nicht bereits geöffnet zu sein. QTP startet den Browser für Sie. Sie müssen

über einen generierten HTML-Wrapper verfügen, den Sie von QTP anfordern. Fordern Sie die SWF-Datei der

Anwendung nicht direkt an.

In einigen Fällen funktioniert die Wiedergabe nicht wie erwartet. Meist liegt dies an der Synchronisierung.

Beispielsweise kann die Wiedergabe eines Effekts länger dauern als von QTP erwartet. Dies bedeutet, dass QTP

möglicherweise schon während der Wiedergabe des Effekts versucht, mit dem nächsten Schritt im Skript fortzufahren.

Ein weiteres Problem kann auftreten, wenn Sie asynchrone Methoden für das Beziehen von Daten (wie z. B. einen

Webdienstaufruf) verwenden. Das Skript wird fortgesetzt, auch wenn Sie die Daten der Webdienst-Operation noch

nicht empfangen haben.

Diese Probleme können u. a. gelöst werden, indem Sie Wartebefehle einfügen oder vor dem Fortfahren das

Vorhandensein eines Objekts überprüfen. Weitere Informationen finden Sie unter „Lösen von Problemen mit der

Wiedergabesynchronisierung“ auf Seite 17.

14Letzte Aktualisierung 4.3.2010

Kapitel 2: Erweiterte Konzepte

Arbeiten mit Containern

Im Allgemeinen hält HP QuickTest Professional (QTP) den Umfang an Detailinformationen zu verschachtelten

Steuerelementen im Testskript möglichst gering. Die Software entfernt Container, die keine Auswirkungen auf die

Testergebnisse oder die Identifizierung von Steuerelementen haben, aus dem Skript. Dies gilt für Container wie

HGroup-, VGroup-, HBox-, VBox- und Canvas-Container, die ausschließlich für Layouts verwendet werden, es sei

denn, sie werden in ViewStack-, TabNavigator- oder Accordion-Containern verwendet. Dann werden sie für die

Navigation zur Hierarchie hinzugefügt.

Achten Sie bei der Verwendung von verschachtelten Containern auf mögliche ID-Konflikte. Container mit mehreren

Registerkarten (wie Accordion- und TabNavigator-Container) können dieselbe Beschriftung auf mehreren

Registerkarten aufweisen. Diese Container leiten ihre IDs von den Registerkartenbeschriftungen ab, sodass mehrere

identische IDs vorhanden sein können.

QTP erfasst Layoutcontainer nur dann im Skript, wenn Sie ein Ereignis bezüglich des Containers ausführen. So wird

verhindert, dass die Testobjekte zu tief verschachtelt und die Testskripte dadurch unübersichtlich werden.

Weitere Informationen zur Anwendungshierarchie finden Sie unter „Einführung in die Anwendungshierarchie“ auf

Seite 6.

Arbeiten mit Repeater-Objekten

Repeater-Objekte werden in der QTP-Objekthierarchie und in Skripten angezeigt. Sie enthalten die von ihnen

erstellten untergeordneten Objekte. In Anwendungen sind diese untergeordneten Objekte Elemente, die dem

Hauptcontainer untergeordnet sind und nicht etwa dem Repeater-Objekt. In QTP-Tabellen-Checkpoints werden

beide Modelle berücksichtigt: Die untergeordneten Objekte werden als untergeordnete Elemente des Containers und

des Repeater-Objekts angezeigt.

Arbeiten mit datengesteuerten und listenbasierten Steuerelementen

Damit die Automatisierung korrekt funktioniert, muss ein benutzerdefiniertes Elementrendererobjekt für ein

listenbasiertes Steuerelement datengesteuert sein. Für das Erstellen von Tabellen-Checkpoints werden einem

einzelnen Elementrenderer Daten hinzugefügt und anschließend Werte abgefragt. Wenn ein Elementrenderer nicht

datengesteuert ist, sind die generierten Werte falsch.

Wenn Daten, die in einem listenbasierten Steuerelement angezeigt werden, testübergreifend geändert werden,

verwenden Sie einen indexbasierten Ansatz für die Aufzeichnung. Die wertebasierte Aufzeichnung schlägt in

derartigen Situationen fehl.


Erweiterte KonzepteLetzte Aktualisierung 4.3.2010

Fehlerbehebung

Bei der Verwendung von QTP zum Testen von Anwendungen können einige Probleme auftreten, für die im

Folgenden Lösungsmöglichkeiten angegeben werden. Überprüfen Sie folgende Punkte:

• Der Entwickler muss beim Kompilieren das include-libraries-Flag verwenden, um die Dateien

„automation.swc“, „automation_agent.swc“ und „qtp.swc“ mit der Anwendung zu verknüpfen. (Sie können

feststellen, ob diese Bibliotheken eingeschlossen sind, indem Sie die Größe der SWF-Datei mit und ohne

Bibliotheken vergleichen. Anwendungen, die mit diesen Bibliotheken kompiliert wurden, sind größer.)

• Mit dem Process Explorer (verfügbar unter

http://www.microsoft.com/technet/sysinternals/Processesandthreadsutilities.mspx) können Sie herausfinden, ob

die DLLs „TEAPluginIE.dll“ und „TEAPluginQTP.dll“ geladen sind. Suchen Sie nach diesen DLLs, sobald Sie mit

dem Aufzeichnen begonnen haben. Wenn nur „TEAPluginQTP.dll“ geladen ist, „TEAPluginIE.dll“ jedoch nicht,

besteht möglicherweise ein Problem mit den IE-Sicherheitseinstellungen. „TEAPluginIE“ verfügt über ein

ActiveX-Control, das vom QTP-Agent verwendet wird.

• Zeigen Sie die Flash Player-Protokolldatei an. Sie befindet sich im Ordner C:\Dokumente und

Einstellungen\benutzername\Anwendungsdaten\Macromedia\Flash Player\Logs. Dabei entspricht benutzername

dem aktuellen Windows-Benutzernamen. Überprüfen Sie, ob Fehlerstrings verfügbar sind.

Allgemeine Fehlerbehebung

Sie können weitere häufig auftretende Probleme lösen, indem Sie Folgendes in Bezug auf Ihre Umgebung und

Anwendung sicherstellen:

• Die ActiveX-Version der Debugger-Version von Flash Player 9 oder höher ist installiert.

• QTP-Add-ins zu Flex oder AIR sind installiert. In QTP werden die verfügbaren Plug-ins beim Starten angezeigt.

• Die Anwendung wurde in Flex 3 oder höher mit der neuesten „frameworks.swc“-Datei kompiliert, die

automatisierte Tests unterstützt.

• Die Anwendung wird in Microsoft Internet Explorer Version 6 oder höher ausgeführt.

• Die Anwendung wurde über eine HTML-Seite (oder einen Wrapper) mit einem <object>-Tag geladen, das über

ein id-Attribut verfügt. Das id-Attribut enthält keine Punkte und Bindestriche.

• Die Anwendung wird entweder von einem Webserver oder lokal über eine vertrauenswürdige SWF-Datei geladen.

Um zu ermitteln, ob Sie über die korrekten Versionen der erforderlichen Anwendungen verfügen, wechseln Sie in der

Windows-Systemsteuerung zu „Software“. Überprüfen Sie dort die Liste der installierten Programme.

Wenn QTP keine Interaktionen mit der Anwendung aufzeichnet, stellen Sie fest, ob die Add-ins und das Plug-in

installiert sind. Die folgenden Probleme treten am häufigsten auf:

• Flash Player weist nicht die richtige Version auf. Version 9 oder höher ist erforderlich.

• Internet Explorer weist nicht die richtige Version auf. Version 6 oder höher ist erforderlich.

• In Internet Explorer sind Plug-ins deaktiviert. Für QTP ist ein ActiveX-Plug-in erforderlich.

• QTP ActiveX-Plug-in war nicht installiert (es hätte zusammen mit den Flex- und AIR-Plug-ins geladen werden

sollen).

• QTP-Add-ins zu Flex oder AIR sind nicht installiert.

• Die DLLs, von denen die Flex-Plug-ins abhängen, sind nicht im System vorhanden. Dazu gehören die Dateien

„MSVCR71.DLL“ und „MSVCP71.DLL“.



Sie können dieses Problem auf folgende Weise untersuchen:

• Zeigen Sie im Add-ins Manager von QTP eine Liste der installierten Add-ins an.

• Zeigen Sie die Protokolldateien an. Weitere Informationen finden Sie unter „Protokollieren mit der Debugger-

Version von Flash Player“ auf Seite 16.

Aufzeichnen von Ereignissen

Beim Aufzeichnen von Ereignissen mit QTP können die folgenden Probleme auftreten:

• Wenn QTP keine Ereignisse aufzeichnet, stellen Sie sicher, dass die Anwendung mit den

Automatisierungsbibliotheken kompiliert wurde, wenn Sie diese nicht zur Laufzeit laden. Bitten Sie den Flex-

Entwickler, die Anwendung erneut zu kompilieren.

• Beim Klicken auf eine Komponente wird das Klickereignis möglicherweise für eine andere Komponente

aufgezeichnet. In diesem Fall war die erforderliche Komponente möglicherweise Bestandteil eines

zusammengesetzten Objekts. Entweder hat das enthaltende Objekt seine untergeordneten Objekte nicht korrekt

bereitgestellt oder die owner-Eigenschaft wurde nicht korrekt eingestellt.

Protokollieren

Um die Problemquelle zu ermitteln, können Sie die Flash Player- und die QTP-Protokolldatei anzeigen.

Protokollieren mit der Debugger-Version von Flash Player

Die Debugger-Version von Flash Player schreibt Plug-in- und ActionScript-Fehler in die Datei „flashlog.txt“. Diese

Datei befindet sich standardmäßig im Ordner C:\Dokumente und

Einstellungen\benutzername\Anwendungsdaten\Macromedia\Flash Player\Logs. Dabei entspricht benutzername

dem aktuellen Windows-Benutzernamen.

Um die Protokollierung zu aktivieren, verwenden Sie die Debug-Version von Flash Player. Möglicherweise müssen

Sie „mm.cfg“ neu konfigurieren, damit die Protokolle erstellt werden können. Weitere Informationen finden Sie unter

Using Flex 4.

Protokollieren mit QTP

Sie können die QTP-Protokollierung so konfigurieren, dass die QTP-Fehler aus dem Anwendungstest protokolliert

werden. Anschließend zeigen Sie die QTP-Protokolldatei an, um mögliche Problemquellen daraus zu ersehen.

Aktivieren Sie die Protokollierung in der QTP-Protokolldatei.

1 Öffnen Sie ein Befehlszeilendialogfeld.

2 Wechseln Sie in den QTP-Ordner „bin“. Der Standardpfad lautet C:\Programme\HP\QuickTest Professional\bin.

3 Führen Sie bei QTP 9.2 und früher MicLogSetting.exe aus. Führen Sie bei QTP 9.5 und höher ClientLogs.exe aus.

Das Dialogfeld „Log settings“ wird angezeigt.

4 Wählen Sie aus der Liste „Available Categories“ als QTP-Optionen „LogCatPackTEA“ und „LogCatPackTE“.

Klicken Sie auf die Nach-rechts-Schaltfläche, um diese Kategorien in die Liste „Selected Categories“ zu verschieben.

5 Erhöhen Sie für jede Kategorie die Protokollebene. Setzen Sie bei QTP 9.5 und höher „Category Level“ auf

„Debug2“.

6 Geben Sie einen Pfad ein, in dem die Protokolldateien gespeichert werden sollen.

7 Klicken Sie auf „OK“, um die Änderungen an den QTP-Protokollebenen zu speichern.



8 Führen Sie QTP aus. Zeichnen Sie wie üblich die Interaktionen mit Ihrer Anwendung auf.

9 Schließen Sie QTP.

10 Prüfen Sie die QTP-Protokolldatei auf mögliche Probleme.

QTP generiert eine Protokolldatei an dem im Dialogfeld „Log settings“ angegebenen Speicherort. Um sicherzustellen,

dass das Plug-in ausgeführt wird, überprüfen Sie, ob Folgendes im Protokoll angezeigt wird:

Read Flex environment and matching ProgId TEAPluginQTP.TEAFlexAgentQTP

Hinweis: Die QTP-Protokolldatei kann sehr groß sein. Es empfiehlt sich, ihre Verwendung auf die Fälle zu beschränken,

in denen Fehler aufgetreten sind, die Sie auf andere Weise nicht lösen können.

Lösen von Problemen mit der Wiedergabesynchronisierung

In einigen Fällen wird die Wiedergabe eines Testskripts nicht mit der Anzeige auf dem Bildschirm synchronisiert.

QTP testet Objekte beispielsweise bereits, bevor Effekte abgeschlossen sind oder Datenergebnisse zurückgegeben

wurden. Dies kann dazu führen, dass QTP beispielsweise die folgenden Fehler aufzeichnet:

• Ihre Skripte werden widersprüchlich wiedergegeben.

• Es tritt ein nicht näher spezifizierter Fehler auf.

• Ihre Skripten schlagen an einer Position fehl, die keine Fehler verursachen dürfte.

Hinzufügen von Wartebefehlen zu Skripten

Sie können die Wait-Anweisung verwenden, um die Wiedergabe des Skripts für eine beliebige Anzahl an Sekunden

zu unterbrechen. Sie übergeben Wait(anz_sekunden) als Argument an die Operation, die Sie in dem Skript

unterbrechen möchten.

Im folgenden Beispiel wird 10 Sekunden gewartet, bevor auf das Milk FlexCheckBox-Steuerelement geklickt wird:

Browser("My Page").FlexApplication("MyApp").FlexCheckBox("Milk").Click Wait(10)

Weitere Informationen zum Verwenden von Wait-Anweisungen finden Sie in der QTP-Dokumentation.

Prüfen, ob Objekte existieren

Sie können prüfen, ob ein Objekt existiert, bevor Sie eine Operation an diesem Steuerelement ausführen. Dafür

können Sie die Exist-Anweisung verwenden. Im folgenden Beispiel wird geprüft, ob das Milk FlexCheckBox-

Steuerelement existiert, bevor darauf geklickt wird:

If Browser("My Page").FlexApplication("MyApp").FlexCheckBox("Milk").Exist Then Browser("My Page").FlexApplication("MyApp").FlexCheckBox("Milk").Click End If

Sie können auch den Wert der allgemeinen Exist-Eigenschaft des Steuerelements prüfen. Weitere Informationen zur

Verwendung der Exist-Anweisung und der allgemeinen Exist-Eigenschaft finden Sie in der QTP-Dokumentation.

Verlangsamen von globalen Wiedergabezeiten

Es ist möglich, QTP so zu konfigurieren, dass alle Ereignisse langsamer wiedergegeben werden. Hierzu stellen Sie eine

globale Ausführungsverzögerung ein. Dies stellt jedoch nur einen allerletzten Ausweg dar. Versuchen Sie zunächst,

vor problematischen Punkten im Test Wait-Anweisungen einzufügen, wie unter „Hinzufügen von Wartebefehlen zu

Skripten“ auf Seite 17 erläutert. In sehr großen Testskripten kann das Erhöhen des Zeitaufwands für das Auslösen der

einzelnen Ereignisse – wenn auch nur um den Bruchteil einer Sekunde – eine dramatische Erhöhung der

Gesamtlaufzeit des Tests nach sich ziehen. Ermitteln Sie deshalb möglichst den niedrigsten Wert, bei dem Ihre

Skripten noch korrekt ausgeführt werden.



Wenn Sie sich für das Hinzufügen einer globalen Verzögerung entscheiden, konfigurieren Sie QTP so, dass jeder

Schritt in Ihrem Skript um wenige Millisekunden verzögert wird. Anschließend können Sie die Anzahl an

Millisekunden graduell erhöhen, bis keine Fehler mehr auftreten.

Hinzufügen einer Verzögerung zu jedem Schritt im Test

1 Wählen Sie „Tools“ > „Options“ aus.

2 Wählen Sie im Dialogfeld „Options“ die Registerkarte „Run“ aus.

3 Aktivieren Sie unter „Run mode“ das Optionsfeld „Normal“. Dies ist die Standardoption.

4 Erhöhen Sie den Wert im Feld „Delay Each Step Execution By“ um einige Millisekunden. Der Standardwert ist 0.

5 Klicken Sie zum Speichern der Änderungen auf „OK“.

6 Führen Sie den Test erneut aus. Wenn weiterhin Probleme auftreten, erhöhen Sie die Verzögerung und führen den

Test erneut aus.

Verzögern der Teststartzeit

Wenn Sie eine Anwendung ändern oder die Anwendung erneut kompilieren, wenn sie von QTP im Browser gestartet

wird, denken Sie daran, den Zeitpunkt des Teststarts nach dem Browserstart zu verzögern. Wenn Sie einen Test sofort

starten, die Anwendung jedoch noch nicht alle Objekte instanziiert hat, zeichnet QTP möglicherweise Fehler auf.

Verzögern des Teststarts

1 Wählen Sie „Tools“ > „Options“ aus.



2 Wählen Sie im Dialogfeld „Options“ die Registerkarte „Web“ aus:

3 Erhöhen Sie den Wert im Feld „Add n Seconds To Page Load Time“ so, dass sichergestellt ist, dass Ihre Anwendung

kompiliert ist, bevor QTP mit dem Ausführen des Tests beginnt. Der Standardwert ist 10.

Fehlschlagenlassen eines Tests und ihn dennoch bis zum Ende fortsetzen

Es können Situationen auftreten, in denen Sie einen Test aus einem Skript weder fehlschlagen lassen noch ihn

erfolgreich durchführen können und ihn auch nicht bis zum Ende fortsetzen können. Dies gilt insbesondere für Tests,

die eine Formel in einer Datentabelle ändern.

Um eine QTP-Methode zu schreiben, durch die ein Test fehlschlägt, aber bis zum Ende fortgesetzt wird, erstellen Sie

ein Schlüsselwort, wie im folgenden Beispiel gezeigt.

Public Function WidthGreaterThan(test_object, minWidth) actual = test_object.GetROProperty("width") a = CInt(actual) b = CInt(minWidth) If a > b Then Msg = "WidthGreaterThan", "Width is greater than: " &minWidth Reporter.ReportEvent micPass, Msg Else Msg = "Width " & actual & " is not greater than " & minWidth Reporter.ReportEvent micFail, "WidthGreaterThan", Msg End If End Function RegisterUserFunc "FlexButton", "WidthGreaterThan", "WidthGreaterThan" Browser("FlexStore").FlexApplication("flexstore").FlexCanvas("Products"). FlexButton("Remove from cart_11").WidthGreaterThan 10 Browser("FlexStore").FlexApplication("flexstore").FlexCanvas("Products"). FlexButton("Remove from cart_11").WidthGreaterThan 1099 Browser("FlexStore").FlexApplication("flexstore").FlexCanvas("Products"). FlexButton("Remove from cart_11").WidthGreaterThan 100



Beschränkungen automatischer Testverfahren mit Flex

Die Flex-Integration mit QTP weist die folgenden Beschränkungen auf:

• Flex-Testobjekte werden im Dialogfeld „Object Identification“ („Tools“ > „Object Identification“) nicht angezeigt.

Deshalb konfigurieren Sie in der Regel nicht die Art und Weise, wie QTP eine Objekt-ID abruft, und ändern auch

nicht, welche Eigenschaften von QTP gespeichert werden. Sie können die Eigenschaften, die Flex für die

Identifizierung eines Objekts verwendet, in der Datei „TEAFlex.xml“ konfigurieren.

• Webeinstellungen („Tools“ > „Web Event Recording Configuration“) werden auf Flex-Anwendungen nicht

angewendet. Hier können Sie die Empfindlichkeit von Mausereignissen angeben. (Beispielsweise können Sie QTP

anweisen, eine mouseDown- und dann eine mouseUp-Operation anstelle einer click-Operation aufzuzeichnen).

• Flex-Testobjekte sind in der QuickTest Object Model Reference („Help“ > „QuickTest Professional Help“ >

Registerkarte „Contents“ > „QuickTest Object Model Reference“) nicht enthalten. In dieser Referenz sind alle

prüffähigen Methoden und Eigenschaften, Beispiele und eine Liste der Identifizierungseigenschaften aufgeführt.

In der Datei „tea.html“ werden alle Flex-Testobjekte (oder MX-Steuerelemente), deren Ereignisse und deren

Ereigniswerte erläutert. Nähere Informationen erhalten Sie unter „Dokument „QTP Object Type Information““

auf Seite 3.

Documents

Testen von Adobe® Flex® 4-Anwendungen mit HP QuickTest ... · PDF fileTESTEN VON FLEX 4-ANWENDUNGEN MIT HP QUICKTEST PROFESSIONAL Arbeiten mit QuickTest Professional 4 und