Schon wieder „element not found“? So testen Sie, wenn Selektoren und Locators versagen

„Element not found“?Warum Selektoren und Locators kaputtgehen (dynamische IDs, Shadow DOM, iframes, Canvas) und wie Sie ohne Locator testen, der gepflegt werden muss.

Von Ait Nohaila, Business Development Representative 14 Min. Lesezeit

„Element not found“ heißt, dass Ihr Test ein Element mit einem Locator gesucht hat und rechtzeitig nichts gepasst hat.Die Lösung ist selten ein besserer Locator: Es ist ein Test, der prüft, was der Benutzer sieht.

Jeder QA-Engineer kennt diesen Morgen: zwanzig rote Tests und kein einziger echter Fehler.Ein Entwickler hat eine Klasse umbenannt, das Designteam hat ein Banner verschoben, ein Framework-Update hat die IDs geändert.Dieser Artikel erklärt, warum Locators kaputtgehen, wie man den Fehler behebt, wenn er kommt, wo die üblichen Lösungen aufhören und wie man ohne Selektor testet, der gepflegt werden muss.

Was bedeutet „element not found“?

Definition

Ein „element not found“-Fehler bedeutet, dass der Test ein Element mit einem Locator angefordert hat und vor Ablauf der Wartezeit nichts auf der Seite gepasst hat.

  • Ein Locator, auch Selektor genannt, ist die Adresse, die der Test für das Element verwendet: eine ID, ein CSS-Selektor, ein XPath, eine Rolle und ein Name, ein Text.
  • Selenium wirft NoSuchElementException, Playwright beendet die Aktion mit einem Timeout, und jedes andere Framework hat seinen eigenen Namen dafür.

Am Ende lautet die Meldung immer gleich: Der Test hat das Element verloren, ob der Benutzer es verloren hat oder nicht.

Seleniums eigene Seite zur Fehlerbehebung nennt drei wahrscheinliche Ursachen: Sie suchen an der falschen Stelle, Sie suchen zur falschen Zeit, oder der Locator hat sich geändert, seit Sie den Code geschrieben haben.Nur die letzte betrifft den Locator selbst, und sie wächst mit jedem Release.

#save-8f3a2c

Ein neuer Build erzeugt eine andere ID

.btn-primary

Ein Redesign benennt die Klasse um

text=Save

Die französische Version sagt Enregistrer

//div[3]/form/button[2]

Über dem Formular wird ein Banner eingefügt

Auf dem Bildschirm

Save

Für den Benutzer unverändert

Vier gewöhnliche Änderungen, vier kaputte Locators.Der Button, den der Benutzer sieht, ist in allen vier Fällen derselbe.

Warum gehen Selektoren und Locators kaputt?

Ein Locator ist eine Vermutung darüber, wie die Anwendung gebaut ist.Alles, was den Aufbau ändert, ohne zu ändern, was der Benutzer sieht, kann ihn kaputtmachen.

Was sich geändert hatWelche Locators kaputtgehenHat der Benutzer es bemerkt?
Generierte IDs und KlassennamenEine vom Framework geschriebene ID oder Klasse, bei jedem Build oder Seitenaufruf andersNein
Ein Redesign oder ein RefactoringCSS-Ketten und XPaths, die der Struktur der Seite folgenOft nicht
Ein A/B-TestJeder Locator der Variante, die Ihr Test nicht erwartet hatNur die Benutzer in dieser Variante
Eine ÜbersetzungLocators über sichtbaren Text oder zugänglichen NamenNein, wenn die Übersetzung stimmt
Shadow DOM und iframesLocators, die nicht in die Komponente oder den Frame hineinkommenNein
Eine virtualisierte ListeLocators für eine Zeile, die erst gezeichnet wird, wenn man zu ihr scrolltNein
Ein Canvas, ein Spiel oder eine App ohne BarrierefreiheitsbaumJeder Locator: Darin gibt es nichts, worauf man zeigen könnteNein

Dynamische IDs und generierte Klassennamen

Viele Frameworks schreiben ihre eigenen IDs und Klassennamen, etwa save-8f3a2c oder css-1x7hq.Sie sind eindeutig, was sie wie perfekte Locators aussehen lässt, und sie ändern sich beim nächsten Build.Ein darauf aufgezeichneter Test besteht heute und schlägt nach dem nächsten Deployment fehl, auf einer Seite, die niemand angefasst hat.

Redesigns, Refactorings und A/B-Tests

Ein CSS-Selektor wie .form > div:nth-child(3) button oder ein XPath wie //div[3]/form/button[2] beschreibt einen Weg durch die Seite.Packen Sie das Formular in einen neuen Container, fügen Sie darüber ein Banner ein oder tauschen Sie zwei Felder, und der Weg führt woandershin.Ein A/B-Test tut dasselbe mit Absicht: Die Hälfte der Besucher bekommt eine Seite, für die Ihre Locators nicht geschrieben wurden.

Die Dokumentation von Playwright sagt es klar: XPath- und CSS-Selektoren können an die DOM-Struktur gebunden sein, und sie können kaputtgehen, wenn sich diese ändert.

Lokalisierung und textbasierte Locators

Locators über Text, Beschriftung oder zugänglichen Namen überstehen ein Redesign, deshalb werden sie empfohlen.Eine Übersetzung überstehen sie nicht.Ein Button, der über den Namen Save gefunden wird, wird nicht mehr gefunden, wenn die französische Version Enregistrer sagt, also braucht ein lokalisiertes Produkt einen Locator pro Sprache oder eine Test-ID.

Shadow DOM und iframes

Ein iframe ist eine Seite in der Seite, und eine Webkomponente hält ihre inneren Elemente in einer Shadow Root.Selenium kennt nur die Elemente des obersten Dokuments, also muss ein codierter Test zuerst in den Frame geschickt werden, sonst meldet er, dass das Element nicht existiert.Manche Locators, etwa XPath, kommen überhaupt nicht in eine Komponente hinein.

Virtualisierte Listen und Tabellen

Eine Tabelle mit zehntausend Zeilen ist schnell, weil sie nicht alle zeichnet.AG Grid, eine weit verbreitete Datentabelle, erklärt, dass sie nur zeichnet, was man auf dem Bildschirm sieht, plus einen kleinen Vorrat an Zeilen darüber und darunter.Zeile 500 ist erst in der Seite, wenn jemand zu ihr scrollt, also findet ein Locator sie nicht, während ein Mensch einfach scrollen würde.

Wie man einen „element not found“-Fehler behebt

In Selenium, Playwright oder Cypress ist die Behebung Ihre Arbeit, und sie kommt mit jedem Release wieder.In GUI Test Studio gibt es keinen Locator zu reparieren.

Was schiefgingIn einem Code-FrameworkIn GUI Test Studio
Das Element erscheint spätSie schreiben eine Wartebedingung für den richtigen ZustandJede Prüfung wartet von selbst bis zu ihrem Zeitlimit
Das Element liegt in einem Frame oder einer Shadow RootSie schreiben den Schritt in den Frame oder die KomponenteDas Element wird dort gefunden, wo es auf dem Bildschirm gezeichnet ist
Ein Redesign hat die IDs oder die Struktur geändertSie schreiben den Locator neu, oft in vielen TestsNichts neu zu schreiben: Ein anderer Weg oder sein Bild findet es
Das Element wurde absichtlich geändertSie ändern den TestcodeEin Klick im Bericht übernimmt das neue Aussehen

Wenn ein Test von GUI Test Studio doch an einem Element stehen bleibt, klären diese fünf Schritte die Sache, ohne eine Zeile Code.

  1. 1

    Öffnen Sie den Konfidenzbericht des Laufs

    Der Bericht öffnet sich nach jedem Lauf beim ersten Fehler.Er zeigt das erwartete Bild neben dem Bildschirm in dem Moment, in dem die Prüfung aufgab, sodass Sie sehen, ob das Element fehlte, verdeckt war oder woanders stand.

  2. 2

    Prüfen Sie, wo der Lauf begann

    Ein Test beginnt auf dem Bildschirm, auf dem seine Aufnahme begann.War die App auf einer anderen Seite oder hatte andere Daten, stellen Sie den Zustand wieder her und starten Sie den Test erneut.

  3. 3

    Vergrößern Sie den Suchbereich, wenn das Element weit gewandert ist

    Wird im Suchbereich einer Prüfung nichts gefunden, weitet sich die Suche bereits von selbst auf den ganzen Bildschirm aus.Steht das Element nun dauerhaft an einer neuen Stelle, klicken Sie im Bericht auf Suchbereich vergrößern und legen Sie den neuen Bereich in GUI Test Studio fest.

  4. 4

    Übernehmen Sie eine gewollte Änderung

    Sieht das Element anders aus, weil sich das Design geändert hat, klicken Sie im Konfidenzbericht auf Ist als Soll übernehmen und speichern Sie.Der Test ist aktuell, ohne Code zu ändern.

  5. 5

    Melden Sie den Fehler, wenn das Element wirklich verschwunden ist

    Ist das Element weg, hat der Test seine Arbeit getan.Klicken Sie auf Fehlerbericht, um ihn als PDF oder als Jira-Vorgang anzulegen, mit den Bildern im Anhang.

CSS, XPath, Rolle oder Test-ID: Jeder Locator hat seine Schwachstelle

Teams, die codierte Tests schreiben, wählen für jedes Element, das sie berühren, einen Locator.Jede Art scheitert auf ihre eigene Weise.

LocatorBeispielEr geht kaputt, wennEr übersteht
Generierte ID oder Klasse#save-8f3a2cDer nächste BuildFast nichts
CSS-Selektor.form button.primaryKlassen oder Struktur ändern sichEinen neuen Text oder eine Übersetzung
XPath//div[3]/form/button[2]Irgendetwas wird darüber oder drumherum eingefügtEine neue Klasse
Rolle und zugänglicher Namerole=button, name=SaveDie Beschriftung ändert sich oder wird übersetztRedesigns und Refactorings
Test-IDdata-testid=save-orderEin Entwickler entfernt sie oder benennt sie umRedesigns, Übersetzungen, Refactorings

Jede Strategie verschiebt das Risiko, statt es zu beseitigen.

  • Eine Rolle und ein Name hängen von den Wörtern ab, die sich mit jeder Übersetzung und jeder Textänderung ändern.
  • Eine Test-ID hängt von einer Gewohnheit ab: Jeder Entwickler muss sie hinzufügen, behalten und nie wiederverwenden, in jeder Komponente, solange das Produkt lebt.
  • CSS und XPath hängen von der Struktur ab, und genau die ändern Refactorings.

XPath oder CSS-Selektor ist die meistgestellte Frage, und sie ist weniger wichtig, als es scheint.CSS ist kürzer und leichter zu lesen; XPath kann in der Seite nach oben gehen und Text suchen.Beide beschreiben, wie die Seite gebaut ist, also gehen beide auf dieselbe Weise kaputt.

In GUI Test Studio wählt niemand einen Locator.Ein aufgenommener Test behält von selbst mehrere Wege zu jedem Element, wie die nächsten Abschnitte zeigen.

Behebt selbstheilende Testautomatisierung kaputte Locators?

Selbstheilende Werkzeuge speichern zusätzliche Details zu jedem Element, solange ein Test besteht.Wenn der Haupt-Locator nicht mehr passt, suchen sie das Element mit diesen Details und machen weiter.

Selbstheilung ist nützlich, mit drei Grenzen, die man kennen sollte.

Sie geht immer noch von einem Locator aus, also braucht sie ein Element in der Seite, zu dem sie heilen kann.

Sie macht aus einer Änderung ein Bestehen, also muss jede Heilung von einem Menschen geprüft werden, sonst versteckt sich eine echte Änderung dahinter.

Wo es gar kein Element gibt, kann sie nicht helfen: ein Canvas, ein Spiel, ein entfernter Bildschirm.

Wo jeder Locator aufhört: Canvas, Spiele und Apps ohne Barrierefreiheitsbaum

Alle Strategien oben setzen voraus, dass die Anwendung ihre Elemente beschreibt.Viele tun das nicht, und dann gibt es keinen Locator zu schreiben, weder einen guten noch einen schlechten.

AnwendungWas ein Locator erreichen kann
Ein Canvas, ein Diagramm, eine Karte, eine WebGL-SzeneEin einziges Element, das ein Bild enthält
Ein SpielEin einziges Fenster: Das Spiel zeichnet seine Menüs selbst
Flutter im WebNichts, bis die App ihre Barrierefreiheit einschaltet: Flutter zeichnet seine Oberfläche auf ein Canvas, und seine Barrierefreiheit ist im Web optional
Qt, Java Swing, Delphi und andere selbst gezeichnete Desktop-AppsWenig oder nichts, je nachdem, wie jedes Steuerelement gezeichnet wird
Citrix, Remotedesktop und virtuelle MaschinenEin einziges Fenster aus Pixeln auf Ihrem Computer

Für Windows-Desktop-Apps zeigt WinAppDriver-Alternativen für Apps ohne Barrierefreiheitsbaum, welche Programme sich beschreiben und welche nicht.

Wenn Ihr Test nur sieht, was die Anwendung beschreibt, kann eine Anwendung, die nichts beschreibt, nicht getestet werden.Der Benutzer sieht trotzdem jeden Button.

Testautomatisierung ohne Selektoren, die gepflegt werden müssen

GUI Test Studio, das End-to-End-Tests unter Windows automatisiert, geht einen anderen Weg: Niemand schreibt oder pflegt einen Selektor.Sie zeichnen den Test auf, indem Sie den Ablauf selbst durchgehen, oder beschreiben ihn in einem Prompt, und jede Prüfung betrifft das, was der Benutzer sieht.

Die PrüfungWas sie prüft
Bild-AssertionEin Element ist auf dem Bildschirm und sieht wie erwartet aus: sein Bild, gefunden und verglichen
Text-AssertionEin Text ist auf dem Bildschirm, dort gelesen, wo er stehen soll
Dynamische Text-AssertionEin Wert hat die richtige Form, etwa ein Datum, ein Betrag oder eine Bestellnummer, egal welchen Wert er hat
Layout-AssertionDie Elemente stehen im Verhältnis zueinander dort, wo sie sollen

Um jedes Element zu finden, nutzt die GTS Engine + AI zwei Wege.Sie fragt zuerst die Anwendung: die Barrierefreiheitsinformationen, die eine Windows-App über ihre Steuerelemente gibt, oder die eigenen Elemente einer Webseite.Wenn die Anwendung nichts sagt, findet sie das Element am Aussehen, auf dem Bildschirm.Wie GUI Test Studio Elemente auf dem Bildschirm findet erklärt beide Wege im Detail.

Auf einer Webseite: mehrere Wege zu einem Element

Bei einem Webtest speichert GUI Test Studio mehrere Wege zu jedem Element, auf das es einwirkt, nach Rang geordnet: seine Test-ID, seine ID, seine Rolle und seinen Namen, seine Beschriftung, seinen Platzhalter, seinen Text und zuletzt seine Stelle in der Seite.Eine ID, die nach einem Framework generiert aussieht, rückt ans Ende der Liste, hinter alles, was ein Mensch lesen kann.

Die Wege zum Save-Button, der Reihe nach versucht

  1. 1Seine Test-IDdata-testid="save"Bei einem Refactoring entfernt
  2. 2Seine Rolle und sein Namerole=button · name=SaveGefunden
  3. 3Sein TextSaveNicht nötig
  4. 4Seine Stelle in der Seiteform > button:nth-of-type(2)Nicht nötig
Wenn ein Weg nicht mehr passt, findet der nächste das Element.Der Lauf vermerkt, welcher Weg es gefunden hat und welcher sich geändert hat, und die Prüfung schaut trotzdem auf den Bildschirm.

Eine entfernte Test-ID oder eine umbenannte Klasse hält den Test also nicht auf: Der nächste Weg findet das Element trotzdem.Dieselben Wege erreichen Elemente in einem Shadow Root, und sie lassen einen für ein Smartphone erzeugten Test das Menü öffnen, das dort einen Link versteckt.

Genau das lässt einen einzigen aufgezeichneten Webtest in Chrome, Edge, Firefox und auf emulierten Smartphones laufen, wie Cross-Browser-Tests aus einer einzigen Aufzeichnung zeigt.

In einer Desktop-App: zuerst das Steuerelement, dann der Bildschirm

In einer Windows-App speichert eine Prüfung auf einem Button, was die App über diesen Button gesagt hat: seinen Namen, seine Art, wo er stand.Bei jedem Lauf fragt die Engine zuerst die laufende App nach ihm und sucht sein Bild in dem Rahmen, den die App angibt.Unter mehreren gleichen Buttons nimmt sie den, der der Stelle des aufgezeichneten am nächsten ist.

Eine Textprüfung fragt die App, was das Element sagt, bevor sie die Wörter auf dem Bildschirm liest, sodass ein auf dem Bildschirm schwer lesbares Wort trotzdem mit dem verglichen wird, was die App wirklich sagt.

Überall sonst: am Aussehen

Ein Spiel, ein Canvas, eine Citrix-Sitzung oder ein Programm ohne Barrierefreiheitsbaum wird am Aussehen getestet, ohne dass der Anwendung etwas hinzugefügt wird.Die Prüfung sucht das Bild des Elements in ihrem Suchbereich, und eine Textprüfung liest die Wörter auf dem Bildschirm.

BeispielEin Diagramm auf einem Canvas

Ein Dashboard zeichnet sein Umsatzdiagramm auf ein Canvas, also kann kein Locator einen Balken oder eine Legende erreichen.Sie zeichnen einen Klick auf den März-Balken auf und fügen eine Bild-Assertion der Legende hinzu.Der Klick wird über das Bild des Balkens gezielt, und die Legende wird so geprüft, wie der Benutzer sie sieht.

Was passiert, wenn sich das Element bewegt oder ändert

Ein Test, der nicht von einem einzigen Locator abhängt, muss trotzdem mit Änderungen umgehen.So geht GUI Test Studio bei jedem Schritt vor.

  1. Fragen

    Die Anwendung sagt, wo das Element ist

  2. Schauen

    Oder sein Bild wird in seinem Suchbereich gefunden

  3. Erweitern

    Nichts da: der ganze Bildschirm

  4. Berichten

    Wo es gefunden wurde, und warum

Jeder Schritt deckt eine andere Art von Änderung ab.

  • Ein verschobenes Fenster, ein verrutschtes Layout oder eine gescrollte Liste: Die Anwendung sagt, wo das Element jetzt ist, oder sein Bild wird dort gefunden.
  • Ein Element, das seinen Suchbereich verlassen hat: Wenn dort nichts gefunden wird, erweitert sich die Suche auf den ganzen Bildschirm, und der Konfidenzbericht sagt, dass das Element außerhalb seines Bereichs gefunden wurde, mit einem Link, um ihn zu erweitern.
  • Ein Wort, das die Texterkennung schlecht liest: Eine Textprüfung fragt die Anwendung, was das Element sagt.
  • Ein Webelement, dessen erster Locator kaputt ist: Der nächste Weg findet es, und der Lauf vermerkt, welcher Weg sich geändert hat.

Auch die Klicks folgen dem Element: Jeder Klick wird über die Prüfung davor gezielt, also bewegt sich der Klick mit, wenn sich der Button bewegt.Siehe Bildprüfungen und Textprüfungen dazu, wie jede Prüfung eingestellt wird.

Was weiterhin Sie entscheiden

Kein Ansatz macht jede Änderung kostenlos.Das sind die Fälle, in denen ein Mensch entscheidet.

SituationWas zu tun ist
Das Aussehen eines Elements wurde absichtlich geändertDie Prüfung schlägt fehl, mit dem erwarteten und dem tatsächlichen Bild nebeneinander.Klicken Sie im Konfidenzbericht auf Ist als Soll übernehmen und speichern Sie.
Bildschirmgröße oder Skalierung weichen von der Aufzeichnung abEine Prüfung am Aussehen vergleicht Bilder, also führen Sie sie mit derselben Bildschirmgröße und Skalierung aus, oder halten Sie für jede ein Baseline-Profil.
Die App startet nicht dort, wo die Aufzeichnung begannBringen Sie die Anwendung in den Zustand zurück, in dem die Aufzeichnung begann: dieselbe Seite, dieselben Daten, dieselben offenen Fenster.
Ein A/B-Test liefert eine andere VarianteLegen Sie die Variante in Ihrer Testumgebung fest, oder halten Sie für jede Variante ein Baseline-Profil.
Das Element ist wirklich verschwundenDas ist ein Fehler.Der Test schlägt fehl, und der Bericht zeigt, was wo erwartet wurde.

Ein neues Aussehen übernehmen zeigt die Aktualisierung mit einem Klick, und instabile Tests und Fehlalarme erklärt, wie eine Prüfung harmloses Rauschen von einer echten Änderung unterscheidet.

Für die visuellen Fehler, die eine Locator-basierte Prüfung durchlässt, ohne sie zu sehen, lesen Sie visuelle Fehler, die Ihre automatisierten Tests übersehen.

Das Wichtigste in Kürze

  • 1„Element not found“ ist meist ein Problem des Tests, kein Fehler: Locator, Zeitpunkt oder Kontext stimmen öfter nicht als die Anwendung.
  • 2Locators gehen aus gewöhnlichen Gründen kaputt: generierte IDs, Redesigns, A/B-Tests, Übersetzungen, Shadow DOM, iframes und virtualisierte Listen.
  • 3Jede Strategie verschiebt das Risiko: CSS und XPath hängen von der Struktur ab, Rollen und Namen von den Wörtern, Test-IDs von einer Teamgewohnheit, Selbstheilung von einer Prüfung durch Menschen.
  • 4Manche Apps geben einem Locator nichts: Canvas, Spiele, Citrix-Sitzungen und Apps ohne Barrierefreiheitsbaum lassen sich nur am Aussehen testen.
  • 5GUI Test Studio hat keine Selektoren oder Locators, die gepflegt werden müssen: Es fragt zuerst die Anwendung, findet das Element am Aussehen, wenn die Anwendung nichts sagt, und prüft, was der Benutzer sieht.

Fragen

Was bedeutet „element not found“ in der Testautomatisierung?

Es bedeutet, dass der Test ein Element mit einem Locator angefordert hat, etwa einer ID, einem CSS-Selektor oder einem XPath, und rechtzeitig nichts auf der Seite gepasst hat.In Selenium erscheint es als NoSuchElementException, in Playwright als Timeout.Das Element kann fehlen, aber öfter stimmen Locator, Zeitpunkt oder Kontext nicht.

Warum findet mein Test das Element lokal, aber nicht in der CI?

Meist, weil der Lauf anders ist, nicht der Code.Ein langsamerer Build-Agent zeigt das Element später als Ihr Laptop, ein kleinerer Bildschirm versteckt es hinter einem Menü, andere Testdaten ändern seinen Text, oder ein A/B-Test liefert eine andere Variante.Sehen Sie sich den Screenshot oder das Video des fehlgeschlagenen Laufs an, bevor Sie den Locator ändern.

Ist XPath oder ein CSS-Selektor besser?

Keiner ist allein sicher.Beide beschreiben, wie die Seite gebaut ist, also brechen beide, wenn sich ihre Struktur ändert, wie die Dokumentation von Playwright warnt.Eine Rolle mit Namen oder eine Test-ID halten länger, aber auch sie werden von Hand geschrieben und aktuell gehalten.In GUI Test Studio schreibt niemand das eine oder das andere: Der Test behält seine eigenen Wege zu jedem Element.

Wie gehe ich in Selenium oder Playwright mit dynamischen IDs um?

Bauen Sie keinen Test darauf: Eine ID, die sich mit jedem Build oder jedem Seitenaufruf ändert, kann dasselbe Element nicht zweimal finden.In einem codierten Test heißt das, von Hand einen anderen Locator zu schreiben und zu pflegen.In GUI Test Studio gibt es nichts zu schreiben: Ein Webtest stellt eine ID, die generiert aussieht, ans Ende seiner Liste der Wege zum Element, nach allem, was ein Mensch lesen kann.

Funktioniert selbstheilende Testautomatisierung?

Sie hilft, wenn sich ein Attribut ändert und das Element noch da ist.Ein wirklich verschwundenes Element kann sie nicht zurückholen, und sie geht weiterhin von einem Locator aus, den jemand geschrieben hat und pflegen muss.Prüfen Sie jede Heilung, sonst kann sie eine echte Änderung verbergen.

Wie testet man eine App, die keinen Barrierefreiheitsbaum hat?

Am Aussehen, auf dem Bildschirm.Spiele, Canvas, Diagramme, Citrix- und Remotedesktop-Sitzungen und viele selbst gezeichnete Programme bieten nichts, was ein Locator erreichen kann.GUI Test Studio findet ihre Elemente an ihrem Bild und prüft den auf dem Bildschirm gelesenen Text, ohne etwas an der Anwendung zu ändern.

Kann ich End-to-End-Tests ohne Selektoren oder Locators automatisieren?

Ja.In GUI Test Studio zeichnen Sie einen Test auf oder beschreiben ihn in einem Prompt, und es gibt keine Selektoren oder Locators, die gepflegt werden müssen.Jede Prüfung ist ein Bild, ein Text, die Form eines Werts oder eine Anordnung auf dem Bildschirm, und die GTS Engine + AI findet jedes Element, indem sie zuerst die Anwendung fragt, und am Aussehen, wenn diese nichts sagt.

Was passiert, wenn sich ein Button absichtlich ändert?

Die Prüfung schlägt fehl und zeigt das erwartete und das tatsächliche Bild nebeneinander.Wenn die Änderung gewollt ist, klicken Sie im Konfidenzbericht auf Ist als Soll übernehmen und speichern: Der Test ist aktuell, ohne Code zu ändern.

Wie GUI Test Studio funktioniertDie ganze Idee in zwei Minuten.Lesen BildprüfungenEin Element finden, dann vergleichen.Lesen TextprüfungenDie Wörter auf dem Bildschirm prüfen, oder ihre Form.Lesen

Selenium, Playwright, Cypress, AG Grid, Flutter, Qt, Java, Delphi, Citrix, Chrome, Edge, Firefox und Windows sind Marken ihrer jeweiligen Inhaber.

Weiterlesen

Alle Artikel

Bereit, Ihren ersten Test aufzuzeichnen?

Jede Funktion, 30 Tage lang.

Kostenlos testenIhr erster Test, Schritt für Schritt
Vorführung buchen