Agent Browser mit Videoaufnahme: die richtige FPS-Rate

Agent Browser aufzeichnen: Welche Bildrate braucht die Prüfung?

30 fps sind der beste Ausgangspunkt. Das ist der neue Standard, weil gewöhnliche Klicks, Hover-Zustände, Scrollbewegungen, CSS-Übergänge und Walkthroughs lesbar bleiben, ohne die zusätzliche Last von 60 fps zu verursachen.

Der gültige Bereich für --fps reicht von 1 bis 60. Eine höhere Zahl liefert nicht automatisch bessere Belege. Wenn die Seite seltener neu zeichnet als angefordert, erzeugt auch eine Einstellung von 60 fps keine 60 tatsächlich unterschiedlichen Seitenzustände.

Was sich mit v0.37.0 geändert hat

Der Recorder behandelt Video nun als zeitlich getakteten Blick auf die tatsächlich verwendete Seite. record start und record restart erfassen standardmäßig die aktuell aktive Seite mit 30 fps, akzeptieren --fps 1-60 und verwenden Chromes Page.startScreencast. Damit stammt das Bildsignal direkt aus Chromes Feed für neu gezeichnete Seitenframes – als wäre eine Kamera unmittelbar mit der Darstellungspipeline des Browsers verbunden, statt nur gelegentlich Screenshots aufzunehmen.

Das Release v0.37.0 verschärft außerdem das Fehlerverhalten. Fehlt ffmpeg, hat der Ausgabepfad keine Dateiendung oder ist eine Aufnahmeoption ungültig, schlägt der Befehl fehl, bevor sich Browser- oder Aufnahmezustand ändern. Kann eine Ersatzaufnahme nicht starten, bleibt die aktive Aufnahme erhalten. Eine Navigation während der Aufzeichnung entfernt nun veraltete Elementreferenzen und Frame-Zustände genauso wie eine gewöhnliche Navigation.

Für reale QA-Schleifen ist das entscheidend. Ein fehlerhafter Videopfad darf die getestete Seite nicht unbemerkt verändern. Ebenso sollte der Start einer zweiten Aufnahme die erste nicht zerstören, bevor sicher ist, dass der Ersatz funktioniert.

Der Aufnahmeablauf in fünf Schritten

Die verlässliche Reihenfolge lautet: prüfen, öffnen, aufnehmen, Assertion ausführen, stoppen. Der letzte Befehl gehört zum Belegprozess, denn erst er schreibt die Datei vollständig und speichert sie.

agent-browser doctor
agent-browser open https://app.example.com/login
agent-browser record start ./login-flow.mp4 --fps 30
agent-browser snapshot -i
agent-browser click @e1
agent-browser wait --url "**/dashboard"
agent-browser record stop

1. Zuerst den Encoder prüfen. agent-browser doctor meldet ffmpeg und die verfügbaren Aufnahme-Encoder. MP4 benötigt libx264, WebM benötigt libvpx. Eine übliche ffmpeg-Installation über Homebrew oder Debian/Ubuntu bringt normalerweise beide mit.

2. Die richtige Seite im aktiven Tab bereitstellen. Wird bei record start keine URL angegeben, verbindet sich der Recorder mit der aktiven Seite in ihrem aktuellen Zustand. Er lädt sie nicht neu, öffnet keinen neuen Tab und erstellt keinen frischen Browserkontext. Das ist hilfreich, wenn ein Fehler von einer bereits initialisierten App, einer authentifizierten Sitzung oder einem Zustand innerhalb der Seite abhängt. Wird eine URL mitgegeben, navigiert zunächst der aktive Tab; die Aufzeichnung beginnt, sobald die Seite geladen ist.

3. Das Containerformat über die Dateiendung wählen. .mp4 wählt H.264 über libx264, .webm wählt VP8 über libvpx. Andere Endungen werden mit H.264 an ffmpeg übergeben und funktionieren nur, wenn ffmpeg den jeweiligen Container kennt. Ein Dateiname ohne Endung wird abgelehnt.

4. Die Pass/Fail-Prüfung in der Automatisierung belassen. Im Beispiel prüft wait --url, ob der Browser das Dashboard erreicht hat. Der Clip hilft Menschen zu verstehen, was passiert ist. Er macht aus Pixeln keine Test-Assertion.

5. Vor dem Schließen stoppen. record stop schreibt und speichert die Aufnahme vollständig. Wird zuerst die Sitzung geschlossen, kann genau die vorgesehene Datei fehlen. record restart eignet sich, um eine Aufnahme zu beenden und sofort die nächste auf der aktiven Seite zu beginnen.

capturedFrames und frames beantworten unterschiedliche Fragen

Die beiden Zähler stehen für Ausgangsmaterial und fertiges Video. capturedFrames zählt die unterschiedlichen Frames, die die Seite erzeugt hat. frames zählt die Frames, die in die Videodatei geschrieben wurden. Eine statische Seite kann nur sehr wenige unterschiedliche Bilder liefern, während ffmpeg Frames wiederholt, damit sich die Aufnahme sinnvoll abspielen lässt.

Beim Timing gibt es eine wichtige Einschränkung. Ändert sich die Seite nicht mehr, bleibt der letzte Frame stehen. Eine einzelne statische Lücke wird bis zu fünf Sekunden gehalten; der restliche unveränderte Abschnitt entfällt. Kurze Pausen bleiben im Video also erhalten, lange Leerlaufphasen werden dagegen komprimiert. Die Wiedergabedauer taugt deshalb bei einem Dauertest nicht als Stoppuhr.

Eine niedrige Zahl bei capturedFrames bedeutet daher nicht automatisch, dass die Aufnahme fehlgeschlagen ist. Möglicherweise war die Seite einfach unbewegt. Aus demselben Grund sollten 60 fps Bewegungen vorbehalten bleiben, die wirklich geprüft werden müssen: Laut Aufnahmeanleitung verdoppeln 60 fps gegenüber 30 fps ungefähr die Bitrate, während die Zahl der unterschiedlichen Frames weiterhin davon abhängt, wie oft die Seite neu zeichnet.

Wie sich die Kostengrenze verschiebt

Wenn agent-browser im Team bereits läuft, muss die Beschaffung einfacher Videobelege nicht mehr mit einer weiteren Recorder-Lizenz beginnen. Das Paket v0.37.0 steht unter der Apache-2.0-Lizenz, für den Recorder selbst fällt also keine nutzerabhängige Softwarelizenz an. Zusätzliche Kosten entstehen bei den betriebenen Komponenten: Einrichtung von ffmpeg, CI-Zeit, Artefaktspeicher und die Minuten, die Menschen für die Prüfung des Ergebnisses benötigen.

Das unterscheidet sich deutlich vom Kauf einer vollständigen Feedback- oder Testplattform. Jam Team kostet bei jährlicher Abrechnung $14 pro Creator und Monat. BugHerd Standard kostet bei monatlicher Abrechnung $50 pro Monat für fünf Mitglieder und umfasst Video-Feedback. BrowserStack Automate weist für einen parallelen Chrome Desktop bei jährlicher Abrechnung $59 pro Monat aus und bietet Videoaufzeichnungen unter seinen Debugging-Werkzeugen.

Diese Produkte bieten weit mehr als Aufzeichnung; sie deshalb vollständig zu ersetzen, wäre der falsche Schluss. BrowserStack verkauft verwaltete Browserabdeckung. BugHerd und Jam liefern Zusammenarbeit, Fehlererfassung und Integrationen. Die sinnvolle Kostenfrage ist enger: Wenn agent-browser den Ablauf bereits ausführt und nur ein lesbares Video als Artefakt fehlt, ist keine zweite Aufzeichnungsschicht nötig.

Sieben Anwendungsfälle – geordnet nach dem größten Nutzen

1. Produktteams analysieren fehlgeschlagene CI-Abläufe

Bei einem instabilen Login- oder Checkout-Test kann ein Produktteam direkt vor dem riskanten Abschnitt eine Aufnahme mit 30 fps starten, die URL- oder Element-Assertions beibehalten und das MP4 bei einem Fehlschlag als CI-Artefakt sichern. Zu erkennen sind etwa ein Consent-Banner, ein verspätetes Overlay, ein Fokuswechsel oder ein Übergang, den ein Textprotokoll übersehen kann. Der Gewinn: weniger bezahlte Entwicklungszeit für die Rekonstruktion eines sporadisch auftretenden Zustands.

2. Frontend-Teams prüfen Drag-, Scroll- und Animationsverhalten

Ein Frontend-Engineer kann eine einzelne kurze Interaktion isolieren, sie mit 60 fps erfassen und den Clip mit Screenshots des Anfangs- und Endzustands kombinieren. Das Video zeigt, ob die Bewegung zwischen diesen Zuständen sauber war; die Screenshots bewahren die exakten Pixel. Das zahlt sich aus, wenn der Fehler zwischen zwei Screenshots liegt – etwa bei einem ausgelassenen Frame oder einem Drag-Ziel, das im falschen Moment überquert wurde.

3. KI-Produktteams prüfen das Verhalten von Browser-Agenten

Ein KI-Produktteam kann die aktive authentifizierte Seite mit 30 fps aufnehmen, während sein Agent eine Aufgabe ausführt, und das Video anschließend neben Befehlsprotokoll und Assertions ablegen. So lässt sich unterscheiden, ob der Plan ungeeignet war oder sich die Seite unter dem Agenten verändert hat. Aus einem undurchsichtigen Lauf wird ein Beleg, den Produktmanagement und Engineering gemeinsam besprechen können.

4. QA-Engineers reproduzieren zustandsabhängige Fehler

Ein QA-Engineer kann die Sitzung so weit vorbereiten, bis alle Vorbedingungen für den Fehler vorliegen, und anschließend record start ohne URL ausführen. Da die Aufnahme direkt an den bestehenden Zustand anknüpft, ersetzt keine kalte Navigation die Seite. Das lohnt sich bei Fehlern, die von einem aufgebauten Warenkorb, einem Modal, einer authentifizierten Route oder einer anderen beim Neuladen verlorenen Bedingung abhängen.

5. Agenturen übergeben einen Release an den Kunden

Eine Webagentur kann einen Abnahmeablauf mit 30 fps aufnehmen, an Entscheidungspunkten kurze Pausen einfügen und dem Kunden einen Clip geben, dessen Tempo für Menschen statt für eine Automatisierungs-Engine passt. Der genaue Ablauf lässt sich prüfen, ohne Zugriff auf den Test-Runner zu gewähren. So muss die Agentur weniger Besprechungszeit darauf verwenden, einen Ablauf zu erklären, den das Artefakt bereits zeigt.

6. Reliability-Teams sichern Zeitleisten aus Langläufen

Wenn die Reihenfolge wichtiger ist als die Bewegungsqualität, kann ein Reliability-Engineer einen langen Dauertest mit 10 fps aufzeichnen. Gegenüber 30 oder 60 fps sinken Aufnahmeaufwand und Dateiwachstum. Die Aufnahme hilft weiterhin, den sichtbaren Moment eines Fehlers zu finden. Wegen der komprimierten statischen Lücken müssen Zeitstempel jedoch aus Protokollen stammen und nicht aus der Wiedergabedauer.

7. Support-Engineers eskalieren schwer greifbare Browserprobleme

Ein Support-Engineer kann einen Kundenablauf in einem kontrollierten Konto reproduzieren, ihn mit 30 fps aufzeichnen, die Aufnahme stoppen und an die Eskalation anhängen. Das Entwicklungsteam erhält so Informationen zu Timing und unerwarteten Overlays, die in einem schriftlichen Ticket oft verloren gehen. Der Nutzen entsteht allerdings nur, wenn der Workflow zugleich verhindert, dass Geheimnisse und Kundendaten in die Aufnahme geraten.

Drei Produkte, deren Entwicklung sich lohnt

Beste Chance: ein Belegpaket für Agentenläufe

Ein kompakter Dienst könnte einen Browser-Agentenlauf in ein einziges Prüfpaket verwandeln: Assertion-Ergebnis, Befehlsprotokoll, finaler Screenshot, MP4, Frame-Zähler und ein Link, der in Jira oder Linear gepostet wird. Produkt- und Engineering-Teams würden dafür bezahlen, weil das Ergebnis in den bereits verwendeten Ticket-Workflow passt.

Die Nachfrage ist konkret. US-Keyword-Daten zeigen rund 590 Suchanfragen pro Monat für „bug reporting tool“ bei einem CPC von $43.80. Auch bestehende Ausgaben sind sichtbar: Jam Team kostet bei jährlicher Abrechnung $14 pro Creator und Monat, BugHerd Standard bei monatlicher Abrechnung $50 pro Monat. Für die kleinste verkaufbare Version genügen ein Wrapper für agent-browser, Artefaktspeicher, eine Integration in einen Issue-Tracker und eine Checkliste zur Schwärzung sensibler Daten.

Das ist die stärkste Chance, weil nicht der Codec, sondern die Übergabe verkauft wird. Der Haken ist der geringe technische Vorsprung. Jira-Posts und Videospeicher lassen sich leicht kopieren; das Produkt muss deshalb besonders gut darin werden, vertrauenswürdigen Kontext zusammenzustellen und sensible Daten fernzuhalten.

Ein QA-Übergabeportal für Agenturen

Eine kundenorientierte Prüfseite könnte Agenturen einen Ablauf auswählen, gegen die Staging-Umgebung ausführen und Assertion, Screenshots sowie ein passend getaktetes Video unter einem gemeinsamen Freigabelink veröffentlichen lassen. Käufer wären Agenturen und externe QA-Teams, denn bei der Kundenfreigabe werden technische Belege häufig zu einer Besprechung.

US-Keyword-Daten zeigen 110 Suchanfragen pro Monat für „website qa testing“, ein Plus von 55% gegenüber dem Vorjahr, bei einem CPC von $23.91. Ein MVP könnte einige wiederverwendbare Abläufe, Aufnahmen mit 30 fps, Kommentare sowie Freigabe oder Ablehnung unterstützen. Der Haken ist die Tiefe etablierter Anbieter: Im Standard-Tarif bündelt BugHerd bereits unbegrenzt viele Projekte, Kundenzugänge, Screenshots, Metadaten und Video-Feedback. Das neue Produkt müsste mit agentenerzeugten Belegen gewinnen, nicht mit einer weiteren Kommentarmarkierung.

Eine Preset-Schicht für Bewegungstests

Ein schlankes CI-Tool könnte Tests als timeline, default oder motion kennzeichnen, ihnen 10, 30 oder 60 fps zuordnen und überraschende Abweichungen zwischen erfassten und geschriebenen Frames melden. Frontend-Plattformteams würden für konsistente Belege zu Animations- und Interaktionsregressionen bezahlen.

US-Keyword-Daten zeigen 110 Suchanfragen pro Monat für „automated browser testing“ bei einem CPC von $14.96. Die engere kommerzielle Formulierung „automated browser testing tools“ erreicht nur 20 monatliche Suchanfragen, aber einen CPC von $63.21 – ein Hinweis darauf, dass dieser kleine Käuferkreis teuer zu erreichen ist. Das MVP besteht aus einem Testmanifest, einem Wrapper für agent-browser-Befehle, nur bei Fehlschlägen gespeicherten Clips und einem kompakten Artefaktindex.

Der Haken ist die schwächere Dynamik: Das breitere Keyword liegt 18% unter dem Vorjahr, und 60 fps verursachen zusätzlichen Aufwand, bleiben aber zugleich durch die Neuzeichnungsrate der Seite begrenzt. Daher sollte dies zunächst ein Feature innerhalb eines Evidenzprodukts sein und kein eigenständiges Unternehmen.

Was die Aufnahme nicht beweist

Video schafft Beobachtbarkeit, nicht Korrektheit. Es kann weder feststellen, ob der richtige Datenbankeintrag geschrieben wurde, noch ob eine API-Antwort gültig war oder sich jeder Browser und jedes Gerät gleich verhält. Assertions, Protokolle und Screenshots gehören deshalb weiterhin daneben.

Auch Umgebungsrisiken verschwinden nicht. Für die Aufnahme müssen ffmpeg und der passende Encoder über PATH erreichbar sein. Höhere Bildraten erhöhen den Aufwand, lange Aufnahmen belegen Speicherplatz und eingeschränkte Headless-Systeme können an Codec- oder GPU-Grenzen stoßen. Eine Seite, die sich nur langsam neu zeichnet, kann pro Sekunde keine 60 unterschiedlichen Frames liefern.

Datenschutz muss als Produktanforderung behandelt werden. Der Recorder erfasst den aktiven Viewport und den Zustand innerhalb der Seite. Genau das macht ihn nützlich – und verlangt klare Regeln für Testkonten, das Maskieren von Geheimnissen, die Aufbewahrung von Artefakten und die Zugriffskontrolle. Dafür ist betriebliche Umsicht nötig; eine eingebaute Zusage zur Schwärzung gibt es nicht.

Schließlich zeichnet agent-browser den Beleg zwar auf, interpretiert ihn aber nicht. Soll nach dem Lauf ein Modell das Videomaterial prüfen, ist dafür ein separates System nötig, eher vergleichbar mit dem agentischen Videoverständnis. Diese Schicht sollte von der deterministischen Pass/Fail-Prüfung getrennt bleiben.

Der konkrete Schritt für Montag

Wählen Sie für die nächste Woche einen störanfälligen Login-, Checkout- oder Veröffentlichungsablauf. Führen Sie doctor aus, zeichnen Sie die bestehende aktive Seite mit 30 fps auf, behalten Sie die aktuelle Assertion bei, rufen Sie record stop auf und hängen Sie das MP4 an das Testergebnis. Wechseln Sie nur dann zu 60 fps, wenn eine Bewegungsstörung sonst nicht zuverlässig beurteilt werden kann; für einen Langlauf, bei dem vor allem die Reihenfolge zählt, reichen 10 fps. Der Pilot ist erfolgreich, wenn sich ein Fehlschlag ohne erneute Ausführung diagnostizieren lässt – nicht schon dann, wenn das Video lediglich flüssig aussieht.

Wenn ein Browser-Agent prüfbare Belege für Ihr Team erstellen soll, kann ich ihn an Ihrem realen QA-Workflow ausrichten.