RenderLog Leitfäden
Diese Leitfäden helfen zu entscheiden, was erfasst, was regelmäßig geprüft und wann Referenzen, Benachrichtigungen oder längere Historie ergänzt werden sollten. Jeder Artikel beginnt mit einer echten Seitenaufgabe, nicht mit einer allgemeinen Testliste.
Wählen Sie eine echte Seite, legen Sie das erwartete Ergebnis fest und richten Sie den ersten Lauf mit der passenden Anleitung ein.
Planen Sie Ziel, Zeitplan und Prüfung, bevor Sie Benachrichtigungen aktivieren.
Wählen Sie visuelle, Formular-, Inhalts- oder SEO-Prüfungen nach dem erwarteten Ergebnis.
Wählen Sie Einzelaufnahme oder gespeicherte Prüfung und schützen Sie Zugangsdaten.
Beginnen Sie mit GET für eine einfache öffentliche Seite, verwenden Sie POST für strukturierte Einstellungen und fragen Sie Jobs bei asynchronen Renders ab.
Nützlich wenn: Nutzen Sie GET für eine einfache öffentliche URL und wenige Optionen.
Überwachen Sie die Seitenzustände, die für Ihr Geschäft zählen, und prüfen Sie einen verständlichen Diff statt besitzerloser Screenshots.
Nützlich wenn: Legen Sie die zuständige Person vor dem Zeitplan fest.
Beginnen Sie mit dem Formularzustand, den jemand bereits prüft, und machen Sie erwarteten Text, Werte und Ergebnis nach jedem Lauf sichtbar.
Nützlich wenn: Wählen Sie ein Formular mit Zuständigkeit und realen Folgen eines Fehlers.
SEO-Probleme und UI-Regressionen sehen für Uptime-Checks oft gesund aus. Öffentliche Seiten brauchen Tests, die die gerenderte Seite wie Reviewer und Crawler sehen.
Nützlich wenn: Prufen, dass indexierbare Seiten 200 zuruckgeben und nicht durch Robots-Tags blockiert sind.
Beginnen Sie mit Zuständen, die Menschen ohnehin im Browser prüfen: Preis, Anmeldeformular, Dokumentationsseite oder ein Komponentenstatus, der nach einer Veröffentlichung stabil bleiben muss.
Nützlich wenn: Preisseite: Preis und Call-to-Action sehen weiterhin korrekt aus.
Preisseiten ändern sich oft und brechen leise. RenderLog beobachtet die ganze Seite, vergleicht sie mit einem freigegebenen Stand und hält den Kontext für die nächste Preisentscheidung fest.
Nützlich wenn: Falscher Call-to-Action nach einem Kampagnen-Update.
Nutze sofortige Warnungen für kaputte Seiten und tägliche Digests für stabile Prüfhistorie, die das Team nicht nach jedem Lauf unterbrechen soll.
Nützlich wenn: Sofortige Alerts für dringende Fehler und blockierte Zustände.
Die Basishistorie deckt aktuelle Arbeit ab. Einjährige Aufbewahrung ist für Teams gedacht, die ältere Ergebnisdateien, Referenzen und Prüfkontext leicht finden müssen.
Nützlich wenn: Jüngste Historie für aktuelle QA und Launch-Review.
Fehlerregeln halten schlechte Aufnahmen aus der Prüfung heraus, damit Teams echte visuelle Änderungen prüfen.
Nützlich wenn: Login-Wall statt der erwarteten Seite.
Starte mit GET für schnelle Ausgaben. Wechsle zu POST, wenn Secrets, längere Eingaben, Speicherziele oder wiederholbare Schritte dazukommen.
Nützlich wenn: GET: schneller Aufruf mit URL und wenigen Query-Parametern.
Mach aus der nächsten wichtigen Seite ein gespeichertes Ergebnis, eine freigegebene Referenz oder eine wiederkehrende Prüfung statt eines einmaligen Problems.