PyUseCase

PyUseCase ist ein GUI-Test-Software für PyGTK.
wartbaren GUI-Tests mit einem Use Case Recorder
Aufzeichnung der Absicht, statt der Mechanik
Der natürlichste Weg, um Tests über eine Benutzeroberfläche zu erstellen ist, einfach für die Durchführung der Aktionen, die Sie durchführen und haben ein Werkzeug, das sie aufnehmen kann und dann später reproduzieren möchten. Dies ist eine einfache und schnelle Möglichkeit, um GUI-Tests zu erstellen und es gibt viele Tools, die dies tun.
Die meisten Werkzeuge Paar die Tests fest mit dem GUI
Die Probleme beginnen, wenn Sie ein paar Tests und Ihren GUI Änderungen haben. Aufzeichnung kann eine gute Möglichkeit, Tests zu erstellen, aber es ist ein schrecklicher Weg, um eine große Zahl von ihnen zu erhalten. Es ist fehleranfällig, frustrierend und sehr zeitaufwendig, wenn Sie ein paar Tests zu haben. Die erste Generation von Tools aufgezeichnet Pixelpositionen und brach, sobald Sie Ihre Bildschirmauflösung verändert. Heutige Werkzeuge Angebot in Bezug auf die GUI Mechanik: finden Sie eine Tabelle mit einem bestimmten Namen, und klicken Sie in der dritten Spalte der vierten Zeile. Sie können Bildwechsel und kleinere Wieder Anordnungen der GUI überleben, aber nicht viel mehr. Die aufgezeichneten Skripte sind dicht und den Zweck des Tests nicht zu vermitteln, und sind ein Buch mit allen nicht-technische Menschen (und manchmal auch an alle, außer dem Autor des Werkzeugs).
Das Problem ist im wesentlichen eine der Kopplung. Die Tests und die GUI sind fest miteinander verbunden und können nicht bequem unabhängig voneinander variieren. Dieser Punkt wird auch von Robert C. Martin in seinem Blog hier gemacht und seine Schlussfolgerung ist, dass GUI-Tests ist von Natur aus spröde und Sie sollten so wenig zu tun, wie Sie sich erlauben kann.
Dies scheint eher defätistische though. Es gibt eine riesige Wert in der Lage zu zeigen, was Ihre Tests zu tun, um einen Benutzer des Systems. Wenn die Tests zu umgehen die Benutzerschnittstelle so, dass Verfahren verlangt einen fairen Betrag von technischen Fähigkeiten und viel Vertrauen aus dem Teil Ihrer Benutzer. Und überhaupt, Software-Entwickler zu lösen Kopplungsprobleme die ganze Zeit. Die Antwort ist, wie üblich, auf eine andere Ebene von Dereferenzierung einzuführen.
Breaking the Kopplung mit einem UI-Karte
Geschäftsleute und Nutzer in der Regel arbeiten in Anwendungsfällen. Es handelt sich um High-Level-Beschreibungen einer Reihe von Maßnahmen in einer ihnen verständlichen Sprache: dh, dass der Domain. Die Idee einer "Use Case Recorder" ist also ein Tool, aufzuzeichnen und wiederzugeben, wie Sequenzen können und damit die Absicht des Benutzers zu erfassen. Dies ermöglicht dann ein besseres Verständnis, weniger Abhängigkeit von der genauen Form des GUI und einfacher Anpassung der bestehenden Tests ohne Rückgriff auf einen Klick alle Tasten wieder.
Der grundlegende Mechanismus ist, dass wir eine Zuordnung zwischen den Maßnahmen, die zur Zeit mit unseren GUI und Aussagen in dieser Domäne Sprache durchgeführt werden können erhalten. GUI Änderungen dann bedeuten, dass dieses Einzel Mapping aktualisiert werden muss, aber die Tests können unberührt bleiben, weiter zu beschreiben, was muss auf der konzeptionellen Ebene durchgeführt werden. Diese Zuordnung erfolgt in Form einer externen Datei in PyUseCase 3.0 und das kommende JUseCase 3,0, während in älteren Versionen sie die Form von Instrumenten erfolgt im Anwendungscode.
Überprüfen des Verhaltens über Protokolle und texttest
Also unsere Use-Case-Recorder aufzeichnen und wiedergeben Anwendungsfälle für uns. Aber wie können wir sicherstellen, dass das, was wir auf dem Bildschirm sehen, ist richtig? Die meisten GUI-Tools tun dies, indem man das Testskript zu "Behauptungen", die oben schauen etwas Widget und überprüfen Sie, dass einige Eigentum der es gleich einem hartcodierte Wert enthalten. Dies schafft noch mehr Abhängigkeit von der aktuellen GUI-Layout und kann nicht "aufgezeichnet" werden in einer natürlichen Art und Weise, aber in nachträglich programmiert werden. No "Anwendungsfall" würde natürlich enthalten diese Informationen: wenn es so wäre, es wäre in ein Testskript aktivieren.
Diese Diskussion ist nicht auf dem texttest Website für nichts. Wenn wir nur noch unsere Anwendung, um ein Protokoll, was die GUI sieht aus wie wir können überprüfen, was es durch die Überwachung des Inhalts dieses Protokoll mit texttest tut produzieren. PyUseCase 3.0 erledigt das für Sie: es erzeugt eine ASCII-art Art Protokoll des aktuellen GUI Aussehen und überwacht Änderungen daran vornehmen. Die Anwendung kann mit einer eigenen Logging ergänzen, wie es will. Mit anderen Use-Case-Recorder muss die Anwendung eine eigene Protokoll zu diesem Zweck derzeit bauen.
Synchronisieren Tests durch Code-Instrumentierung
Fast alle GUI Testaufwand werden durch Probleme mit dafür, dass das Skript wartet lange genug, bevor Sie fortfahren, wenn etwas passiert im Hintergrund geplagt. Die Lösungen reichen von obskuren Wege, warten Sie einige Widget auf eine bestimmte Erscheinung (noch mehr Abhängigkeiten von GUI-Mechanik) müssen "Schlaf" Aussagen zügig verstreut herum. Die fehlschlagen, wenn das System geladen und führen die Tests viel langsamer, als sie sonst laufen. Jeder, ohne genaue Kenntnis des Codes ist schlecht gerüstet, um solche Probleme zu lösen, aber damit ist ein wichtiger Teil des Schreibtests.
Use-Case-Recorder das Konzept eines "Application Event". Dieses ist im Allgemeinen einige Instrumentierung in den Code, der dem Anwendungsfall Recorder, der etwas geschehen ist, die gewartet werden, so dass der Rekorder zur Aufzeichnung und Wiedergabe wartet sowie Klicks braucht anzeigt. Diese werden hier näher beschrieben.
Recording-Makros sowie Tests
High-Level, sind leicht zu manipulieren "Anwendungsfälle" nützlich für andere Dinge als Test. Sie sind auch sehr nützlich für die Benutzer des Systems, die ihre eigene Makros für die Folgen von Handlungen, die sie häufig durchführen zu erstellen können.
Diese werden als "GUI Verknüpfungen" hier bekannt. Ein Use-Case-Recorder werden in der Regel kann eine Anwendung fordern eine "Symbolleiste" von ihm, welche Steuerelemente für die Aufzeichnung und Wiedergabe von ihnen, die in die Anwendung GUI wie gewünscht eingefügt werden können. Neben so dass Anwender Makros erstellen, sie können auch verwendet werden, um noch höhere Abstraktionen für die "Testsprache" oben beschrieben zu schaffen, Beihilfe Tester bei der Durchführung von Aktionen wiederholt, um einen bestimmten Bildschirm für die Prüfung zu erreichen. Diese werden hier näher beschrieben.
Weitere Informationen finden Sie auf der Startseite Projekt gefunden werden

Was ist neu in dieser Pressemitteilung:.

• Sehr einfache Unterstützung für wxPython war aufgenommen.
• Es gibt auch eine Reihe von Verbesserungen und Bugfixes für PyGTK. Bemerkenswert ist, wird gtk.Dialog.run jetzt ohne Quellcodeänderungen unterstützt.
• Python 2.6 und PyGTK 2.12 oder höher sind jetzt erforderlich.
• Das Erbe Instrumentierung-basierte Oberfläche entfernt worden ist.

Anforderungen :

• Python
• PyGTK
• texttest