WPF-Testautomatisierung und UI-Tests für WinForms ohne Code (und ohne Barrierefreiheitsbaum)
WPF-Testautomatisierung und UI-Tests für WinForms ohne Code: was Ihre App einem Testtool zeigt, was sie verbirgt und wie Sie einen Test aufzeichnen, prüfen und bei jedem Build ausführen.
10 Min. LesezeitVon Ait Nohaila, Business Development Representative
Die kurze Antwort
Um UI-Tests für eine WPF-Anwendung zu automatisieren, zeichnen Sie einen Ablauf einmal in GUI Test Studio auf: Jeder Klick, jede Taste und jede Prüfung wird zu einem Test, der jedes Steuerelement über die Barrierefreiheitsinformationen der App findet, oder am Aussehen, wenn sie nichts sagt.
Dieser Leitfaden richtet sich an QA-Engineers und Entwicklungsteams, die eine WPF- oder Windows-Forms-Anwendung (WinForms) testen wollen.Er zeigt, was eine solche App einem Testtool sagt und was sie verbirgt, zeichnet Schritt für Schritt einen Test auf, wählt die Prüfungen, die ein Redesign überstehen, führt den Test bei jedem Build aus und sagt, wann eine Code-first-Bibliothek trotzdem die bessere Wahl ist.
Was eine WPF- oder WinForms-App einem Testtool zeigt und was sie verbirgt
WPF und WinForms beschreiben Windows ihre Standardsteuerelemente beide über UI Automation: einen Typ, einen Namen, eine Position auf dem Bildschirm und, wenn das Entwicklungsteam eine gesetzt hat, eine AutomationId.Ein Screenreader nutzt diese Beschreibung, und ebenso jedes Testtool, das Steuerelemente über Locators findet.Dieselbe App enthält aber auch Steuerelemente, die gar nichts sagen.
| Art des Steuerelements | Was UI Automation sieht | Wie ein Test es findet |
|---|---|---|
| Ein WPF-Standardsteuerelement mit AutomationId: Button, TextBox, ListView, DataGrid | Sein Typ, sein Name, seine Position und die ID, die das Entwicklungsteam ihm gegeben hat | Über das, was die App sagt, sofort |
| Ein WinForms-Standardsteuerelement: Button, TextBox, DataGridView | Sein Typ, sein Text und die Eigenschaft Name des Steuerelements als ID, wenn sie gesetzt wurde | Über das, was die App sagt |
| Eine WinForms-App, deren Steuerelemente ihre Standardnamen behalten haben | Typen und Texte, mit IDs wie button1, die wenig aussagen | Über Text und Position des Steuerelements, und am Aussehen |
| Ein Steuerelement, das die App selbst zeichnet: ein Diagramm, eine Messanzeige, ein Menüband, eine Zeichenfläche | Ein einziges Rechteck, es sei denn, sein Entwicklungsteam hat die Barrierefreiheit dafür geschrieben | Am Aussehen |
| Eine selbst gezeichnete Tabelle oder Liste | Zeilen ohne ihre Zellen, oder Zellen hinter Platzhalternamen | Am Aussehen, Zelle für Zelle |
| Eine Steuerelement-Suite eines Drittanbieters | Das hängt vom Anbieter ab: von einer vollständigen Beschreibung bis zu einem einzigen Bereich | Über das, was die App sagt, wo sie etwas sagt, am Aussehen, wo nicht |
| Ein Bild, ein Symbol, eine Zeichnung | Ein Bild ohne Text | Am Aussehen |
Die eigene Dokumentation von Microsoft sagt, dass ein Steuerelement ohne Anbieter für UI Automation für diese weitgehend undurchsichtig ist, sodass sie kaum mehr als seine Position melden kann.Der Abschnitt Welche Windows-Apps keinen Barrierefreiheitsbaum haben listet die Arten von Anwendungen auf, bei denen das die Regel und nicht die Ausnahme ist.
Automatisiertes Testen einer WPF-Anwendung: Schritt für Schritt aufzeichnen
Automatisiertes Testen einer WPF-Anwendung beginnt mit einer einzigen Aufzeichnung im GUI Test Runner-Recorder.Der App wird nichts hinzugefügt: kein Test-Build, keine Bibliothek, keine AutomationId, die Sie nicht schon hatten.Das folgende Beispiel zeichnet eine App zur Auftragserfassung auf, und eine WinForms-App wird genauso aufgezeichnet.Alle Optionen finden Sie unter Einen Test aufzeichnen.
- 1
Auf „Aufzeichnen“ klicken
Öffnen Sie den GUI Test Runner-Recorder und klicken Sie auf Aufzeichnen.Bringen Sie Ihre App in den Zustand, in dem der Test beginnen soll: der erste Bildschirm des Ablaufs, ohne dass sonst etwas darauf geöffnet ist.
- 2
„Was möchten Sie testen?“ mit „Eine App“ beantworten
Wählen Sie Eine App und dann Ihr Programm unter den laufenden aus, oder suchen Sie seine .exe, wenn es noch nicht geöffnet ist.Aktivieren Sie das Kontrollkästchen, das die App mit dem Test startet und am Ende schließt, damit jeder Lauf mit einer frisch gestarteten App beginnt.
Es wird immer der ganze Bildschirm aufgezeichnet.Die Wahl „Eine App“ entscheidet nur, woher die automatischen Prüfungen kommen. - 3
Die App benutzen, wie es ein Tester täte
Geben Sie den Namen des Kunden ein, wählen Sie ein Produkt in der Liste, klicken Sie auf „Speichern“ und lesen Sie die Bestätigung.Jeder Klick und jede Taste wird aufgezeichnet, und der Recorder schneidet von jedem Steuerelement, das Sie anklicken, ein Bild aus, kurz bevor Sie es anklicken.Drücken Sie die Stopptaste, wenn der Ablauf fertig ist.
- 4
„Was soll dieser Test prüfen?“ beantworten
Drei Karten fragen, was der Test prüfen soll: die visuellen Elemente, die Sie angeklickt haben, den Text auf dem Bildschirm und das, was während Ihrer Arbeit erschienen ist, etwa einen Dialog oder eine Bestätigung.Behalten Sie für einen ersten Test die Standardwerte bei, und speichern Sie.
Die Prüfungen werden nach der Aufzeichnung gewählt, wenn Sie gerade gesehen haben, was die App getan hat. - 5
Der Test wird in einem eigenen Ordner gespeichert und ausgeführt
Ein Test namens Orders wird als
OrdersOrders.GTSgespeichert, in einem eigenen Ordner, in dem die Ergebnisse und der Verlauf jedes Laufs daneben aufbewahrt werden.Klicken Sie auf Test ausführen: Der Test gibt Ihre Klicks und Tasten als echte Eingaben wieder, gezielt dorthin, wo jedes Steuerelement jetzt steht, und endet in einem Konfidenzbericht, der sagt, was bestanden hat und was sich geändert hat.
Was die Aufzeichnung über jedes Steuerelement behalten hat, entscheidet, wie es beim nächsten Lauf gefunden wird.
- Für die Schaltfläche „Speichern“ sagte die App Button, Speichern und SaveButton, und der Test behält das neben dem Bild der Schaltfläche.
- Für das Diagramm sagte die App nichts, was sich zu behalten lohnt, und das Bild allein findet es.
Sie können die Aufzeichnung auch überspringen und den Ablauf in einem Prompt beschreiben, für Claude, ChatGPT oder ein lokales KI-Modell, eines von uns oder Ihr eigenes: Der Test wird auf dieselbe Weise erstellt, mit denselben Prüfungen.
UI-Tests für WinForms: die Prüfungen, die ein Redesign überstehen
UI-Tests für WinForms stehen und fallen, wie WPF-Tests, mit Prüfungen, die eine echte Änderung fangen und die harmlosen ignorieren.GUI Test Studio bietet drei Arten, jede ein Block auf der Zeitleiste des Tests, den jeder im Team hinzufügen, verschieben oder bearbeiten kann.
Bild-Assertion
Eine Bild-Assertion prüft, dass ein Element auf dem Bildschirm ist und so aussieht wie aufgezeichnet: ein Symbol der Symbolleiste, eine Statusleuchte, ein Diagramm, das dieselbe Kurve zeigen muss.
Text-Assertion
Eine Text-Assertion prüft die Wörter, die ein Element zeigt, fragt zuerst die App und liest den Bildschirm, wenn die App es nicht sagen kann, und eine Dynamische Text-Assertion akzeptiert einen sich ändernden Wert anhand seines Formats, etwa eine Bestellnummer.
Layout-Assertion
Eine Layout-Assertion prüft, dass die Elemente eines Bildschirms so angeordnet sind wie aufgezeichnet, sodass eine verschobene Spalte oder eine Schaltfläche, die ihren Platz verloren hat, gefangen wird, auch wenn jedes Element für sich noch richtig aussieht.
Alle drei ignorieren das Rauschen, das jeder Bildschirm hat, und fangen trotzdem, was ein Mensch eine Änderung nennen würde: eine falsche Farbe, ein fehlendes Symbol, ein Wort mit geänderter Groß-/Kleinschreibung, ein verrutschtes Steuerelement.Der Leitfaden Bildprüfungen geht die Einstellungen jeder einzelnen durch.
Der Suchbereich
Jede Prüfung sucht ihr Element in einem Suchbereich, einem Bereich um die Stelle, an der das Element aufgezeichnet wurde.Der Bereich hält Doppelgänger auseinander: Eine Schaltfläche „Speichern“ in der Symbolleiste und eine Schaltfläche „Speichern“ in einem Dialog werden daran unterschieden, wo jede steht.Eine Prüfung, die ihr Element nach einer Sekunde nicht in ihrem Bereich gefunden hat, sucht auch auf dem ganzen Bildschirm, sodass ein Fenster, das sich weiter rechts geöffnet hat, den Test nicht fehlschlagen lässt, und der Konfidenzbericht sagt, wo das Element gefunden wurde.
Ein Redesign des Codes hinter einem Steuerelement
Ein Test funktioniert weiter, durch alle Änderungen hindurch, die eine WPF- oder WinForms-App erlebt.
- Ein Steuerelement, das von WinForms nach WPF neu geschrieben wurde, wird trotzdem gefunden: Die App benennt es noch, und es sieht noch gleich aus.
- Ein Steuerelement, das in ein anderes Panel verschoben wurde, wird dort gefunden, wo es jetzt steht.
- Eine umbenannte Klasse oder eine neue Steuerelementbibliothek ändert nichts, worauf sich der Test stützt.
Ein dunkles Design, ein Design mit hohem Kontrast, eine andere Sprache
Die Barrierefreiheitsinformationen der App ändern sich nicht mit einem Design, sodass eine Prüfung, die die App fragt, im hellen wie im dunklen Design hält.Das Bild, das eine Bild-Assertion vergleicht, ändert sich dagegen, und ein Baseline-Profil behält eine erwartete Version pro Umgebung: Führen Sie den Test mit dem Profil „Dunkelmodus“ aus, übernehmen Sie jedes neue Aussehen einmal im Konfidenzbericht, und derselbe Test prüft danach das helle und das dunkle Aussehen, jedes gegen die richtige Version.
Ein Locator bricht, wenn sich der Code ändert.Eine Prüfung, die die App fragt und auf den Bildschirm schaut, bricht, wenn der Bildschirm falsch ist, und das ist der einzige Fehlschlag, den Sie wollen.
Desktop-Testautomatisierung für Windows bei jedem Build
Desktop-Testautomatisierung unter Windows zahlt sich aus, wenn sie läuft, ohne dass jemand sie startet. gtr-cli, der Befehlszeilen-Runner, führt einen Test genau wie die Schaltfläche „Test ausführen“ aus und antwortet so, wie eine Pipeline es erwartet: Ein fehlgeschlagener Test lässt den Build fehlschlagen, eine JUnit-Datei füllt die Test-Registerkarte, und jedes Bild dessen, was fehlgeschlagen ist, wird in einem Ordner aufbewahrt.
gtr-cli run tests --countdown 0 --junit results\junit.xml --artifacts results\artifactsEine Option nennt das CI-Tool, und die Fehlschläge erscheinen dann in dessen eigenem Protokoll, als Anmerkungen oder Testeinträge, ohne dass ein Plug-in installiert werden muss:
| CI-Tool | Der Befehl | Was das Tool zeigt |
|---|---|---|
| TeamCity | gtr-cli run tests --countdown 0 --format teamcity --artifacts results\artifacts | Jeder Test in der Registerkarte Tests, die Fehlschläge mit ihren Gründen |
| Azure DevOps | gtr-cli run tests --countdown 0 --format azure --junit results\junit.xml --artifacts results\artifacts | Ein Protokollierungsbefehl pro Fehlschlag, und die JUnit-Datei in der Registerkarte Tests |
| GitHub Actions | gtr-cli run tests --countdown 0 --format github --junit results\junit.xml --artifacts results\artifacts | Eine Anmerkung pro Fehlschlag am Lauf, und der Ordner mit den Artefakten zum Herunterladen |
Ein Desktop-Test wird auf einem echten Bildschirm wiedergegeben, daher braucht der Build-Agent eine entsperrte Windows-Desktopsitzung: Eine virtuelle Maschine mit fester Bildschirmgröße eignet sich gut.Der Leitfaden Tests in Ihrer Pipeline ausführen listet jede Option auf, und der Artikel End-to-End-Tests bei jedem Build ausführen richtet einen TeamCity-Build Schritt für Schritt ein, mit demselben Befehl für Jenkins, GitHub Actions, GitLab und Azure DevOps.
FlaUI, pywinauto und andere Tools für UI-Tests unter WPF: wann Code die richtige Wahl ist
Zu zwei Open-Source-Bibliotheken würde ein Entwicklungsteam sonst greifen.FlaUI ist eine .NET-Bibliothek für automatisierte UI-Tests von Windows-Anwendungen, darunter WPF und WinForms, die die UI-Automation-Bibliotheken von Microsoft für einen in C# geschriebenen Test kapselt.pywinauto ist laut seiner GitHub-Seite eine Sammlung von Python-Modulen zur Automatisierung der Windows-GUI, mit zwei Backends: der Win32-API, seiner Voreinstellung, und UI Automation.
Beide sind eine gute Wahl für ein Code-first-Team, dessen Steuerelemente alle zugänglich sind: Die Tests leben im eigenen Repository der App, in einer Sprache, die das Team jeden Tag schreibt, neben den Unit-Tests, und wer den Steuerelementbaum kennt, kann für jedes Element einen präzisen Locator schreiben.Der Preis wird in Entwicklerzeit bezahlt, für jeden Locator und für jedes Redesign, das einen davon ändert, und ein Element, das die App nicht beschreibt, braucht einen anderen Zugang.
Die beiden sind keine Gegner.Ein Team mit einer WPF-App voller eigener Steuerelemente behält seine Unit-Tests oft im Code und zeichnet seine End-to-End-Tests auf, sodass die Menschen, die die Abläufe am besten kennen, sie pflegen können, und auch die Steuerelemente getestet werden, die die App nicht beschreibt.
Das Wichtigste in Kürze
- 1WPF und WinForms beschreiben ihre Standardsteuerelemente, und sagen nichts über ein Diagramm, eine Messanzeige, eine selbst gezeichnete Tabelle oder viele Steuerelemente von Drittanbietern.
- 2Eine einzige Aufzeichnung testet beide Arten: Die GTS Engine + AI fragt zuerst die App und findet das Steuerelement am Aussehen, wenn die App nichts sagt.
- 3Wählen Sie Prüfungen, die ein Redesign überstehen: Eine Bild-Assertion, eine Text-Assertion und eine Layout-Assertion schlagen nur fehl, wenn der Bildschirm falsch ist, und ein Baseline-Profil deckt ein dunkles Design ab.
- 4Führen Sie ihn mit gtr-cli bei jedem Build aus, in TeamCity, Azure DevOps, GitHub Actions, Jenkins oder GitLab, auf einem entsperrten Windows-Desktop.
- 5FlaUI und pywinauto sind weiterhin sinnvoll für ein Code-first-Team, dessen Steuerelemente alle zugänglich sind; der Preis ist Entwicklerzeit für jeden Locator.
Fragen
Wie automatisiert man UI-Tests für eine WPF-Anwendung?
Zeichnen Sie einen Ablauf einmal in GUI Test Studio auf: Öffnen Sie die App, klicken, tippen und lesen Sie, was erscheint, so wie es ein Tester täte.Jede Aktion und jede Prüfung wird zu einem Test ohne Code, und gtr-cli führt ihn bei jedem Build erneut aus.Jedes Steuerelement wird über die Barrierefreiheitsinformationen der App gefunden, oder am Aussehen, wenn die App nichts darüber sagt.
Kann man eine WinForms-App ohne AutomationIds testen?
Ja.Ein WinForms-Standardsteuerelement meldet weiterhin seinen Typ und seinen Text, und ein Steuerelement, das nichts Brauchbares meldet, wird am Aussehen gefunden, an seinem Bild auf dem Bildschirm.Der Anwendung muss nichts hinzugefügt werden, damit der Test funktioniert.
Muss ich meiner WPF-App für die Testautomatisierung AutomationIds hinzufügen?
Nicht mit GUI Test Studio.Eine AutomationId hilft, weil die App das Steuerelement dann genau benennt, und GUI Test Studio behält sie, wenn es eine gibt.Ohne sie genügen der Name, der Typ und die Position des Steuerelements sowie sein Bild.
Wie testet man selbst gezeichnete Steuerelemente oder Steuerelemente von Drittanbietern in einer WPF-App?
Am Aussehen.Ein Diagramm, eine Messanzeige, eine selbst gezeichnete Tabelle oder ein Steuerelement eines Drittanbieters zeigt Windows oft ein einziges leeres Rechteck.GUI Test Studio findet ein solches Steuerelement an seinem Bild in seinem Suchbereich, bedient es mit echten Maus- und Tastatureingaben und prüft auf dieselbe Weise, was es zeigt.
Welche FlaUI-Alternative braucht keinen Code?
GUI Test Studio.FlaUI ist eine .NET-Bibliothek, die Windows UI Automation aus C#-Code steuert, sodass jedes Element einen Locator in einem Testprojekt braucht.GUI Test Studio zeichnet stattdessen den Ablauf auf, behält die Barrierefreiheitsinformationen der App von selbst und findet am Aussehen, was die App nicht beschreibt.
Funktioniert WPF-Testautomatisierung mit einem dunklen Design?
Ja.Die Barrierefreiheitsinformationen der App ändern sich nicht mit einem Design, und für die Prüfungen, die ein Bild vergleichen, behält ein Baseline-Profil eine erwartete Version pro Design.Derselbe Test läuft gegen das helle und das dunkle Aussehen und vergleicht jedes mit der richtigen Version.
Können WPF- und WinForms-Tests in einer CI/CD-Pipeline laufen?
Ja. gtr-cli führt die Tests auf einem Windows-Build-Agent mit entsperrter Desktopsitzung aus, lässt den Build fehlschlagen, wenn ein Test fehlschlägt, schreibt eine JUnit-Datei und bewahrt jedes Bild eines Fehlschlags auf.Es funktioniert mit TeamCity, Azure DevOps, GitHub Actions, Jenkins und GitLab.
Muss in der Anwendung etwas installiert werden?
Nein.GUI Test Studio beobachtet den Bildschirm, fragt Windows, was die App bereits über sich selbst beschreibt, und benutzt Maus und Tastatur wie ein Mensch.Es gibt keine Bibliothek, keinen Test-Build und keinen Agenten in der App.
Microsoft, Windows, WPF, Windows Forms, FlaUI, pywinauto, TeamCity, Azure DevOps, GitHub, GitLab und Jenkins sind Marken oder Projekte ihrer jeweiligen Inhaber.
Bereit, Ihren ersten Test aufzuzeichnen?
Jede Funktion, 15 Tage lang.
Lieber an der Art von App sehen, die Sie testen?Buchen Sie ein kostenloses 30-minütiges Gespräch mit unserem Team.