Webtests ohne Code für Seiten, Formulare und Oberflächenzustände
Prüfen Sie sichtbare Seiten, Inhalte, Formularwerte und Zustände der Oberfläche ohne eigenes Playwright-Testpaket.
Auf dieser Seite
Nützlich wenn
- Nutzen Sie visuelle Regression, wenn Layout oder ganzer Bildschirm zählen.
- Nutzen Sie Inhaltsprüfungen, wenn ein Wort, Preis, Feldname oder Hinweis erscheinen muss.
- Nutzen Sie Wert- und Zustandsprüfungen, wenn ein Formular oder eine Einstellung in einem bestimmten Zustand bleiben muss.
Was Webtests ohne Code abdecken sollten
Ein nützlicher Webtest beginnt mit etwas, das sonst jemand im Browser prüfen würde. Ist der Preis des Plans noch sichtbar? Behält das Anmeldeformular den erwarteten Wert? Erscheint der Hinweis zur Veröffentlichung? Hält die mobile Ansicht nach einer Änderung im CMS?
RenderLog hält solche Prüfungen nah am Seitenergebnis. Ein visueller Lauf speichert die Seitenaufnahme und vergleicht sie mit dem freigegebenen Referenzstand. Ein Testlauf speichert Prüfergebnisse für Inhalte, Werte und Ja-Nein-Zustände, ohne aus jeder Prüfung eine weitere Seitenaufnahme zu machen.
Welche Prüfungen zuerst sinnvoll sind
Beginnen Sie nicht damit, jeden Selektor abzudecken. Beginnen Sie dort, wo eine übersehene Änderung einen klaren Schaden verursacht. Bei Softwareprodukten sind das meist Preise, Anmeldung, Zahlung, Einrichtung des Benutzerkontos, Dokumentation, lokalisierte Seiten und einige Komponentenstände, die auf vielen Seiten wiederkehren.
Es geht darum, wiederholte manuelle Kontrolle zu entfernen, nicht darum, eine vollständige technische Testsuite in einem Webformular nachzubauen.
- Preisseite: Der Growth-Plan enthält "$49" und die Schaltfläche zur Zahlung ist sichtbar.
- Anmeldung: Das E-Mail-Feld übernimmt den erwarteten Wert und das Kontrollkästchen für die Bedingungen ist aktiviert.
- Dokumentation: Der Hinweis zur aktuellen Version ist vorhanden und der Hauptartikel beginnt mit der erwarteten Überschrift.
- Oberflächenbibliothek: Leerzustand, Ladezustand und Fehlerzustand entsprechen dem freigegebenen Referenzstand.
Erwartete Ergebnisse müssen leicht zu ändern sein
Echte Seiten ändern sich. Ein Preis wird angepasst, eine Überschrift wird neu geschrieben oder der Anfangszustand eines Kontrollkästchens ändert sich, weil sich das Produkt bewusst geändert hat. Die Prüfung sollte diesen neuen Zustand direkt aus dem Lauf übernehmen können, statt eine nicht technische Person zurück in die Einstellungen zu schicken.
Deshalb trennt RenderLog visuelle Referenzstände von erwarteten Prüfwerten. Ein visuelles Ergebnis kann zum neuen Referenzstand werden. Ein Testergebnis kann zum neuen erwarteten Wert für die ausgeführten Prüfungen werden.
Wann das nicht der richtige Ort ist
Wenn ein Team bereits eine tiefe Playwright-Suite mit eigenen Fixtures, Mocks und Code-Review pflegt, sollte diese Suite im Code bleiben. Wenn nur eine einmalige Seitenaufnahme oder ein PDF gebraucht wird, passt die Render-API besser als eine gespeicherte wiederkehrende Prüfung.
Webtests ohne Code passen am besten, wenn eine Seite eine verantwortliche Person hat, der erwartete Zustand klar ist und nach jeder Veröffentlichung oder jedem geplanten Lauf ein lesbares Ergebnis gebraucht wird.