Ihre Playwright-Tests, geprüft von Delta-QA. Eine Zeile pro zu prüfender Seite.
@delta-qa/vision schickt Delta-QA jede Seite, die Ihre Playwright-Tests prüfen. Delta-QA vergleicht sie Element für Element mit ihrer Referenz und sagt Ihnen, welches Element sich geändert hat. Ihre im Code geschriebenen Regressionstests und Ihre ohne Code aufgezeichneten Szenarien leben im selben Arbeitsbereich: dieselben Referenzen, dieselbe Prüfung, derselbe Bericht.
Das Vision SDK ist zunächst im frühen Zugang verfügbar: Kontaktieren Sie uns, um es mit Ihren Playwright-Tests zu nutzen.
Drei Schritte in Ihren Tests
- Erstellen Sie einen API-Schlüssel in Ihrem Delta-QA-Arbeitsbereich und legen Sie ihn als Secret in Ihrer CI ab. Das SDK liest ihn aus
DELTAQA_API_KEY; der Arbeitsbereich ist der des Schlüssels. - Fügen Sie einen Check hinzu, wo Ihr Test die Seite prüfen soll:
vision.check("Zahlung"). Sein Name ordnet ihn seiner Referenz zu. - Pushen Sie. Beim ersten Lauf ist jeder Test „Neu“: Sein erster Screenshot wird zur Referenz. Beim zweiten, bei unveränderter Website, wird kein Unterschied gemeldet.
import { test } from "@playwright/test";
import { Vision } from "@delta-qa/vision";
const vision = new Vision(); // reads DELTAQA_API_KEY
test("Checkout", async ({ page }) => {
await vision.open(page, { id: "checkout", name: "Checkout" });
await page.goto("https://shop.example.com/checkout");
await vision.check("Payment");
await vision.close(); // fails the test on an unreviewed difference
});Das SDK bietet nur Einstellungen, die Delta-QA anwendet: Keine wird ohne Wirkung akzeptiert. Tag und Referenz-Tag sind optional; ohne sie leitet das SDK sie ab.
Ein Vergleich Element für Element, nicht Pixel
Bei jeder Prüfung sendet das SDK die Seite (ihr HTML, den Viewport) und die vom Browser geladenen Ressourcen. Delta-QA öffnet die Seite erneut und vergleicht ihre Elemente mit denen der Referenz, wie ein Szenario-Schritt: Der Bericht nennt das Element, das sich geändert hat — den Button „Bezahlen“, erst blau, dann grün — und keine Pixelfläche.
Ein ungeprüfter Unterschied lässt den Playwright-Test scheitern, und das CI-Log nennt den Link zum Batch. Sie öffnen den Schritt, lesen den Bericht und entscheiden: „Gewollt“ oder „Bug“.
Jede Ressource wird an ihrem Hash erkannt: Eine Ressource, die Ihr Arbeitsbereich schon hat, wird nie erneut gesendet. Beim zweiten Lauf einer Suite verlassen bei unveränderter Website nur das HTML und die Hashes Ihre CI.
Eine Referenz pro Branch, kein automatisches Zusammenführen
- Der Tag wird abgeleitet aus Ihrem Git-Branch oder der CI, der Referenz-Tag aus dem Ziel des PR, sonst
main. Ein neuer Branch wird ab dem ersten Lauf mitmainverglichen, und der Batch zeigt „verglichen mit main“. - „Gewollt“ gilt für die Tags, die Sie ankreuzen, standardmäßig „nur dieser Tag“: Andere Branches sehen keine Änderung.
- Der Verlauf eines Tests lässt sich filtern nach Umgebung und nach Tag; jeder Scan kann als Referenz gesetzt werden, für die Tags, die Sie ankreuzen.
- Die Tests eines CI-Laufs bilden einen Batch, geteilt von parallel laufenden Maschinen; die Batch-Liste liest sich wie Ihre CI.
Erstellen Sie Ihre Szenarien mit einem KI-Agenten: der MCP-Server
Fragen zum Vision SDK
Welche Frameworks deckt das Vision SDK ab?
Muss ich meine Playwright-Tests neu schreiben?
Welche Daten sendet das SDK?
Ändern sich meine No-Code-Szenarien?
Kann ich es aus einer anderen Sprache nutzen?
Lassen Sie Ihre Playwright-Tests von Delta-QA prüfen
Um Vision zu nutzen, kontaktieren Sie uns: Es ist zunächst im frühen Zugang verfügbar. Sagen Sie uns, welche Tests Sie prüfen lassen möchten, und wir schalten Ihren Zugang frei.