Testautomatisierung
Jede neue Version kann zerstören, was gestern noch lief. Bei Desktop-Software merkt man das oft erst beim Kunden: Ein Dialog öffnet sich nicht mehr, ein Befehl rechnet falsch, ein Add-in lädt nicht. Wer alles von Hand nachprüft, schafft das bei kurzen Abständen zwischen den Versionen kaum noch vollständig.
Automatisierte Oberflächentests bedienen Ihre Anwendung wie ein Anwender und prüfen das Ergebnis. Entscheidend ist aber nicht nur, wie Sie die Tests erstellen, sondern auch, wann sie laufen.
Welche Tests sich lohnen
Automatisieren Sie zuerst, was oft wiederholt wird: Regressionstests nach jeder Änderung, große Mengen gleichartiger Prüfungen und datengetriebene Tests, also denselben Ablauf mit vielen Datensätzen. Auch Prüfungen mit hohen Anforderungen an die Genauigkeit gehören dazu. Nicht automatisieren lässt sich die Bedienbarkeit: Ob eine Oberfläche verständlich ist, beurteilt ein Mensch.
Tests erstellen: aufzeichnen statt programmieren
Mit unserem Werkzeug TesteriX zeichnen Sie Bedienschritte auf, ohne Testcode zu schreiben. Während der Aufnahme erkennt TesteriX die Bedienelemente des Zielprogramms – Menüs, Menübänder, Dialoge, Symbolleisten und Eingabefelder – und rahmt sie ein, sobald die Maus darüberfährt. Jeder Klick und jede Eingabe wird als Aktion samt Zielobjekt gespeichert. Für die Erkennung nutzt TesteriX FlaUI, Bildverarbeitung und KI-Erkennung. Wir setzen es für Desktop-Anwendungen mit WPF, WinForms, MFC oder QML ein.
Danach ergänzen Sie Überprüfungen: Eine Aktion vergleicht den tatsächlichen Wert mit dem erwarteten. Rückgabewerte legen Sie in Variablen ab und verwenden sie in späteren Schritten weiter.
Eine Besonderheit sind CAD-Systeme. Klicks in die Zeichenfläche hängen von Auflösung und Programmversion ab. Für AutoCAD und BricsCAD steuert TesteriX die Zeichenfläche deshalb über CAD-Befehle aus einem Katalog mit mehreren hundert Befehlen, etwa „Kreis mit Mittelpunkt 0,0,0 und Radius 50“. Abfrage-Befehle prüfen anschließend, was tatsächlich in der Zeichnung steht.
Wann die Tests laufen
| Betriebsart | Wer startet | Wofür |
|---|---|---|
| Von Hand | Entwickler oder Tester am eigenen Arbeitsplatz | Neue Tests ausprobieren, Fehler nachstellen, einzelne Aktionen oder Testfälle abspielen |
| Gezielt angestoßen | Ein Mensch, zu einem festen Anlass | Vor einer Auslieferung oder nach einer Fehlerbehebung, auf Wunsch nur für die betroffenen Bereiche |
| Zeitgesteuert | Ein Zeitplan, etwa nachts oder am Wochenende | Lange Testläufe auf einem Testrechner oder einer virtuellen Maschine; am Morgen liegt der Bericht vor |
| Im Build (CI) | Der Build-Server bei jeder Änderung | Fehler auffangen, bevor eine Version weitergegeben wird |
Von Hand bestimmen Sie über die Auswahl, was abgespielt wird: eine Aktion, einen Testfall oder mehrere Test-Projekte. Mit F5 läuft der Test mit Debugging und hält an Haltepunkten und im Fehlerfall an. Mit Strg+F5 läuft er ohne Unterbrechung durch. F10 führt genau einen Schritt aus – praktisch, um einen Fehler einzugrenzen.
Für den Build speichern Sie die Projektmappe als .tse-Datei und checken sie im Git-Repository der zu testenden Software ein. Auf dem Build-Server spielt der TesteriX TestPlayer, eine Variante ohne grafische Oberfläche, die Tests ab und stellt die Ergebnisse dem CI-Server bereit. So laufen die Tests bei jedem Build mit, zum Beispiel in Azure DevOps, GitHub Actions oder Jenkins. Ein zeitgesteuerter Build auf demselben Server kann den nächtlichen Lauf übernehmen.
Ergebnisse auswerten
Nach dem Lauf zeigt das Ergebnis-Fenster für jede Aktion einen Status: erfolgreich, Warnung, Fehler oder nicht ausgeführt. Eine Warnung meldet zum Beispiel eine auffällige Performanz oder nicht verglichene Werte. Zu jedem Element hält TesteriX Datum, Uhrzeit und Dauer fest. Als Protokoll erzeugen Sie ein PDF zum Archivieren oder eine HTML-Seite zum schnellen Durchsehen. Alternativ übertragen Sie die Ergebnisse an Xray in Jira. Auf Wunsch kommen Bildschirmfotos der Aktionen dazu.
Tests für mehrere Versionen wiederverwenden
Oft unterscheiden sich die Tests für zwei Programmversionen nur wenig. Statt alles neu aufzuzeichnen, fügen Sie einen Testfall als Verknüpfung in das zweite Projekt ein. Die Verknüpfung zeigt die Schritte des Originals, ohne sie zu kopieren. Ändern Sie dort nur einen Wert, bleibt der Verweis bestehen. Ergänzungen am Original übernehmen Sie mit „Verknüpfung synchronisieren“.
Typische Fehler
- Auf dem Produktivrechner testen. Automatisierte Tests steuern Programme fern und verändern Dateien. Nutzen Sie einen eigenen Testrechner und sichern Sie die verwendeten Zeichnungen und Daten vorher.
- In die Zeichenfläche klicken. Klicks auf Bildschirmkoordinaten scheitern bei anderer Auflösung oder Version. Verwenden Sie in CAD-Systemen CAD-Befehle.
- Aufzeichnen ohne Prüfen. Ein Test, der nur klickt, findet nur Abstürze. Erst Überprüfungen machen ihn aussagekräftig.
- Riesige Projektmappen. Mehrere kleine Projektmappen sind besser als eine große. Sie bleiben schnell und übersichtlich.
- Den Virenschutz vergessen. Ein Werkzeug, das andere Programme fernsteuert, kann Warnungen auslösen. Richten Sie vorher eine Ausnahme ein.
- Rote Tests ignorieren. Schlägt ein Test dauerhaft fehl, beachtet ihn bald niemand mehr. Beheben Sie die Ursache oder passen Sie den Test sofort an.
So helfen wir
- Wir erstellen Ihre Testautomatisierung, übernehmen eine bestehende oder übergeben sie an Ihr Team: Testautomatisierung.
- Unser Testwerkzeug für Desktop- und CAD-Anwendungen: TesteriX im Cadida-Shop.
- Damit Ihre Tests lauffähig bleiben, pflegen wir sie laufend: Support und Wartung.
- Erzählen Sie uns, wie Sie heute testen: Vereinbaren Sie ein Erstgespräch.
Quellen: TesteriX-Hilfe (Version 2026.7), Kapitel „Aufzeichnen und Abspielen“, „Besonderheiten CAD“, „Ergebnisse“, „Wiederbenutzung über Verknüpfungen“ und „Einbindung in Continuous Integration“; Cadida: Testautomatisierung.
kununu