Ein HTTP-Aufruf zeigt, dass eine URL geantwortet hat. Er zeigt nicht, ob der richtige Tarif sichtbar ist, ein Registrierungsformular den erwarteten Schritt erreicht oder eine lokalisierte Seite ihre Überschrift behalten hat. Der Browser muss erst das Richtige rendern, bevor jemand es prüfen kann.
RenderLog speichert diesen Zustand als Szenario in einer Check Suite. Ein Lauf kann aus dem Dashboard, über API, CI, Webhook oder Zeitplan starten. Ergebnis, Seitendaten, Assertions, visueller Vergleich und Review-Entscheidung bleiben zusammen.
Beginnen Sie mit einer Seite und einer Entscheidung
Nehmen wir eine öffentliche Preisseite mit dem Plan Growth für 49 $ und der Schaltfläche 'Start free trial'. Der Check speichert Seite und Ansicht, prüft 'Growth' und '49 $' und erfasst das Layout. Entfernt ein Release den Plan oder verschiebt die Schaltfläche, zeigt der Lauf, was geprüft werden muss. Die Beträge sind ein Beispiel, keine RenderLog-Preise.
Wählen Sie einen Zustand, den jemand heute schon von Hand prüft. Legen Sie im Szenarioeditor URL, Ziel, Ansicht und nur die nötigen Schritte fest. Ergänzen Sie Assertions für sichtbaren Text, Wert, Attribut oder Kontrollzustand. Eine visuelle Baseline ist sinnvoll, wenn das Layout Teil der Entscheidung ist.
Bewahren Sie die Einstellungen für vergleichbare Läufe
Eine URL reicht nicht, wenn Cookie, Sprache, Ansicht, Selector oder ein Flow-Schritt das Ergebnis ändern. Eine Check Suite speichert Szenarien und gemeinsame Browserdefaults; ein Szenario kann Eingabe, Ziel, Ansichten, Flow, Assertions und Baseline festlegen. So starten spätere Läufe mit derselben Grundlage.
Führen Sie den Check beim Einrichten manuell aus. Nach einem Release kann CI, API oder Webhook denselben Check starten; für Änderungen außerhalb des Release-Prozesses eignet sich ein Zeitplan. Alle Läufe bleiben in einem Verlauf.
Nutzen Sie den Laufverlauf für die Entscheidung
Im Demo oben wurde example.com in 5,9 Sekunden als PNG mit 19,1 KB gespeichert. Neben Passed stehen 'No assertions' und '0 steps'. Dieser Lauf bestätigt, dass der Screenshot erstellt wurde. Für eine Preisseite brauchen Sie eigene Assertions für Tarifname und Preis, bevor das Ergebnis etwas über deren Richtigkeit aussagt.
Bei einer visuellen Änderung vergleichen Sie Baseline, aktuelles Bild und hervorgehobenen Diff. Prüfen Sie die geänderte Fläche und die Assertions und speichern Sie danach Accept, Reject oder Ignore mit einer kurzen Notiz. Eine Login-Wand, ein fehlender Selector oder ein unvollständiges Ergebnis darf keine neue Baseline werden. Bewahren Sie Zugangsdaten im Request oder in den Einstellungen einer gespeicherten Check Suite auf, nicht in URLs oder Screenshots. Der Browserlauf ergänzt Uptime, Analytics, Accessibility und End-to-end-Tests, ersetzt sie aber nicht.
Im gleichen Workflow weitermachen
RenderLog-Guides öffnen
Praktische Guides zu No-Code-Tests, visuellen Reviews und API-Ausgabe.
Guide: Website-Änderungen überwachen
Ein praktischer Einstieg für Seiten, Zustände und Review-Verantwortung.
No-Code-Website-Tests
Seiten, Formulare und UI-Zustände mit Assertions, Baselines und wiederholten Läufen prüfen.
Website-Screenshot-API
Einmalige oder automatisierte Screenshots und Dokumentdateien per Request erzeugen.
Guide: Preisseiten überwachen
Wie visueller Vergleich und freigegebene Zustände in ein Review passen.
Guide: visuelle Diffs prüfen
Baselines, Verlauf und Hinweise nutzen, ohne jeden Screenshot zum Alarm zu machen.
Guide: Seitenchecks planen
Eine Frequenz wählen, wenn der wiederkehrende Review bereits einen Owner hat.
Beginnen Sie mit einer Seite, die das Team bereits prüft
Speichern Sie den Zustand, ergänzen Sie eine Assertion für das eigentliche Risiko und bestimmen Sie, wer Änderungen prüft. Fügen Sie weitere Seiten hinzu, sobald der erste Check eine klare Zuständigkeit und Reaktion hat.