Jeder Bildschirm des Studios, und was er tut.

Wie die Dateien aussehen

Ja. Jeder Test, den das Studio schreibt oder importiert, ist Framework-Code, den Ihr Team bereits kennt. Die Engine ergänzt ihn um Nachweise, Telemetrie, Urteile (Verdicts) und Selbstheilung; sie ersetzt ihn nicht.

• Playwright, JavaScript und TypeScript: eine Playwright Test-Datei. Der Fixture-Import oben ist der des Studios; der Inhalt besteht aus page, Locators und expect.
• Playwright, Python: einfaches pytest-playwright, eine test_-Funktion, die page entgegennimmt. Sie wird allein mit pytest ausgeführt.
• Selenium, Python: pytest mit einem driver-Fixture. Die conftest.py des Arbeitsbereichs fällt auf einen einfachen WebDriver zurück, wenn die Engine nicht diejenige ist, die ihn ausführt.
• Selenium, JavaScript: selenium-webdriver-Code innerhalb von run({ driver, By, until }). Der Runner des Studios erstellt und beendet den Driver.
• Selenium, Java: JUnit 5, @ExtendWith(NexusExtension.class), ein WebDriver-Parameter, den die Extension übergibt. Build mit Maven.
• Selenium und Playwright, C#: NUnit, eine Klasse, die NexusSeleniumTest oder NexusPageTest erweitert. Build mit .NET.
• API-Tests verwenden das eigene JavaScript-Format des Studios.

So verlassen Sie die Plattform

Ihre Tests, Nachweise und der Verlauf sind Dateien in Ihrem Arbeitsbereich. Um die Suite ohne Nexus auszuführen: Die Python-Tests laufen unverändert, die Playwright-JavaScript-Importe verweisen zurück auf @playwright/test (ein visueller Prüfpunkt, falls Sie einen hinzugefügt haben, muss ersetzt werden), und die Selenium-JavaScript-Funktionen run() benötigen einige Zeilen, die einen Treiber starten. API-Tests müssten für einen anderen Runner neu geschrieben werden.

Patrol

Hier werden Tests geschrieben, ausgeführt und geplant. Die Baumansicht zeigt jeden Test mit einem Logo pro Browser, farblich nach seinem Status gekennzeichnet, und der Ausführungsstreifen über dem Editor zeigt in Worten an, was jeder Browser gerade tut.

• Fünf Tabs: Test cases, Run patrol, Nexus Recorder, AI writer und Test Adapter.
• Ziele: Desktop matrix (Chromium, Firefox und WebKit), Mobile emulated, Real device (ein echtes Android-Telefon) oder Desktop + real device für den PC und ein Android-Telefon gleichzeitig, wobei die Nachweise je Identität abgelegt werden.
• Standardmäßig ein Browser nach dem anderen, oder bis zu drei gleichzeitig und mehrere Tests gleichzeitig, wenn Sie dies festlegen. Selenium läuft auf Chromium und Firefox.
• Neue Tests werden in der Sandbox geprobt, die keinen Verlauf schreibt, bevor ihre Ausführungen zu zählen beginnen.
• Feature flags: Jedes Flag läuft ein, aus oder beides, gesendet per Cookie, Header, Local Storage oder Query-String, und die Karte benennt die Kombination, unter der ein Test fehlschlägt.

Nexus Recorder

Zeichnet Ihre Browseraktionen als Testcode auf. Es ist keine KI im Spiel: Was Sie anklicken, wird direkt geschrieben.

• Aufnehmen für Desktop, Mobile emuliert oder ein Echtes Gerät: ein Android-Telefon per USB, das den eigenen Chrome des Telefons steuert. Derzeit nur JavaScript und Python; Java und C# nehmen auf dem Desktop auf.
• Schreibt Playwright in JavaScript, TypeScript, Python oder C#, oder Selenium in JavaScript, Python, Java oder C#.
• Oder zeichnet die API-Aufrufe, die die Seite ausführt, als REST- oder GraphQL-Tests auf – ohne Auth- oder Cookie-Header und mit geheimnis­artig aussehenden Feldern, die in Umgebungsvariablen umgewandelt werden.
• Selector Maps scannen eine Seite ohne KI, bewerten jeden Selektor als HIGH, MEDIUM oder LOW und speichern die Map auf Ihrem Datenträger.

Test Adapter

Überträgt die Tests, die Ihr Team bereits hat, in das Studio – ohne sie manuell neu schreiben zu müssen.

• Fügen Sie einen Test ein, legen Sie eine Datei ab oder verweisen Sie auf einen Ordner: Playwright oder Selenium in JavaScript, TypeScript oder Python, unter Playwright Test, mocha, jest, pytest oder unittest.
• Schreibt nach Regeln um, nicht per KI: Der Browser-Start und das Setup werden in das Fixture des Studios verschoben, während Assertions, Bedingungen, Schleifen und Waits unverändert bleiben.
• Zeigt den Diff nebeneinander sowie die Anzahl der Assertions vor und nach dem Import. Eine verlorene Assertion blockiert den Import, bis Sie diese Zeile für Zeile akzeptieren.
• Eine optionale KI übernimmt nur das, was keine Regel abdeckt, und ihr Code wird durch den strengen Vet geprüft. Beibehaltene Tests werden in der Sandbox wiederholt, bis drei saubere Durchläufe erreicht sind.
• Cypress, WebdriverIO, Robot Framework, Java und C# werden nicht unterstützt.

Reparaturzeile und Selbstheilung

Was passiert, wenn ein Locator fehlschlägt. Nichts wird hinter Ihrem Rücken repariert.

• Self-Healing, standardmäßig auf „Suggest“ eingestellt: Nach einem Fehler spielt ein Hintergrund-Browser den Test bis zur fehlerhaften Zeile erneut ab und liest die Seite aus, sodass die Kandidaten bereitstehen. Keine KI, und der Test bleibt rot.
• Zeile reparieren, direkt aus dem Randbereich dieser Zeile: Zeichnen Sie nur diesen Schritt erneut auf oder tauschen Sie den Selektor aus – der stärkste zuerst, XPath zuletzt. Die Änderung wird ungespeichert im Editor abgelegt, und das Speichern gilt als Ihre Freigabe.
• Meine KI fragen, welcher kann die Kandidaten neu anordnen, jedoch niemals einen hinzufügen. Die vorherige Version der Datei verbleibt in ihrer Zeitleiste.
• Locator-Zustand listet die schwachen Locators des geöffneten Tests auf und repariert sie auf dieselbe Weise.

Devices & Mobile

Echte Android-Smartphones, per USB mit dem Rechner verbunden, auf dem die Engine läuft. Keine Device-Farm, keine Minuten zu kaufen.

• Mehrere Smartphones gleichzeitig über adb und das Chrome DevTools Protocol, mit einer Anleitung zum Verbinden des ersten Geräts.
• Bildschirm ansehen spiegelt ein Smartphone auf Ihrem PC: von diesem Bildschirm aus steuerbar und schreibgeschützt, wenn es über Patrol geöffnet wird.
• Mobile Emulation über die Geräteprofile von Playwright: Chrome auf Android, ein iPhone oder iPad auf WebKit, der Engine von Safari, sowie ein Low-End-Profil. Echte Geräte sind ausschließlich Android-Smartphones: Ein iPhone oder iPad wird emuliert, niemals ein physisches Apple-Gerät, sodass die iOS-Tastatur und Systemgesten nicht getestet werden.
• Tests auf einem Smartphone werden nacheinander ausgeführt, und ein Smartphone-Durchlauf verbleibt immer auf dem Rechner, an den das Smartphone angeschlossen ist.

Watch

In Patrol unter Patrol ausführen: Führt eine Auswahl zeitgesteuert und unbeaufsichtigt erneut aus.

• Wiederholen alle 5 Minuten bis 24 Stunden oder Einmalig an einem Datum. Es endet, wenn Sie es stoppen, nach einer bestimmten Anzahl von Durchläufen oder an einem Datum.
• Es läuft als eigenständiger Prozess, sodass das Schließen des Studios es nicht stoppt. Die Maschine muss eingeschaltet bleiben: Während sie schläft, warten geplante Ausführungen oder werden übersprungen.
• Sendet Benachrichtigungen über Telegram oder Slack nur dann, wenn sich ein Status ändert, als ALERT oder RECOVERED.

Docker und SSH

Das Studio ist eine Windows 11 Desktop-App auf Ihrem PC oder optional auf einem Windows 11 Mini-PC. Von dort aus führt die Engine die Suites eines Workspace auf diesem Rechner, in Docker darauf oder über SSH auf einem anderen Rechner aus. Das Studio selbst läuft niemals in Docker oder über SSH.

• In Docker läuft die Suite im Runner-Container auf demselben Datenträger, sodass die Nachweise wie gewohnt in Ihrem Arbeitsbereich landen.
• Über SSH auf einem VPS mit Ubuntu 24.04 LTS, Docker Engine und Compose v2, erreichbar über schlüsselbasierten Zugriff: Die Engine führt die Suite dort im selben Container-Image wie Docker hier aus, und die Nachweise verbleiben dort, bis Sie sie abrufen.
• Echte Android-Telefone, Selenium- und Python-Suites, Infrastruktur-Chaos und Ergebnisimport laufen immer auf der eigenen Maschine des Studios.
• Die obere Leiste zeigt an, wo der Arbeitsbereich läuft, sowie dessen RAM und CPU. Adaptives Pacing, wenn Sie es einschalten, passt die Größe der Browser sofort an den freien RAM an.

API-Tests

REST- und GraphQL-Tests mit sieben eigenen Urteilen. Sie werden wie jeder Test über Patrol ausgeführt, und jeder Endpunkt legt seinen eigenen Ordner im Bereich „API testing“ des Evidence Lockers an.

• API_SECURE: Jede Assertion war erfolgreich und die Struktur der Antwort entspricht der zuletzt aufgezeichneten. API_FLAKY: Beim Wiederholungsversuch bestanden. API_DRIFTED: Bestanden, aber die Struktur hat sich geändert, und das Diff benennt jedes Feld, das hinzugefügt, entfernt oder typgeändert wurde. Drift gilt als bestanden, bis Sie es als strikt festlegen.
• API_BREACHED: Eine Assertion ist fehlgeschlagen. API_DEGRADED: Langsamer als das Latenzbudget, standardmäßig 2000 ms, und nur ein Urteil, wenn die Performance strikt geprüft wird. API_VULNERABLE: Eine Anfrage ohne Anmeldedaten wurde beantwortet, wo ein 401 oder 403 erwartet wurde; ein fehlender Sicherheitsheader allein führt nie zu diesem Urteil. API_BLOCKED: Ein 429 oder ein 403 mit einer Cloudflare- oder Akamai-Signatur, sodass die Anfrage Ihr Produkt nie erreicht hat.
• Auf dem Bildschirm: Kacheln für Endpunkte, Bestanden, Läufe über Budget, Struktur geändert, Jemals anfällig und Langsamster beobachteter Wert; die Filter Alle, Fehlgeschlagen, Gedriftet und Anfällig; sowie eine Tabelle mit Endpunkt, Urteil, Min, Median, P95, Max, N und Erfolgsquote. Ein Endpunkt mit weniger als 20 Beobachtungen zeigt einen Bindestrich statt eines Perzentils.
• Klicken Sie auf einen Lauf, um ihn auf sechs Tabs zu öffnen: Report, Request, Response, Performance, Schema und AI Analysis, wobei letzteres ausgefüllt wird, wenn Ihre KI verbunden ist. Ein fehlgeschlagener Schritt eines Flows bietet Re-run from step N und Re-run failed step.
• Pro Lauf in api-evidence abgelegt: request.json, response.json, performance.json, schema.json, report.md und metadata.json, mit geschwärzten Geheimnissen in Headern und Body. report.md endet mit einem curl-Befehl, der den Aufruf wiederholt. Bei erfolgreichen Läufen werden die neuesten 20 pro Test aufbewahrt; Fehlschläge werden immer aufbewahrt.
• Erstellen: Neuer Test, API, fragt nach einem Typ: REST, GraphQL oder SOAP über HTTP. Jeder Typ beginnt mit einem Fall, der unverändert gegen einen öffentlichen Endpunkt ausgeführt wird, und die erste Zeile der Datei zeichnet den Typ auf, sodass die Dateibaumstruktur ihn anzeigt und das Verschieben der Datei ihn nicht ändert. SOAP ist als Text gesendetes und mit Textregeln geprüftes XML, ohne XML-Parser. Umgebungen mit Namen wie staging und prod behalten ihre eigene Basis-URL, und ein Token wird nur als Name seiner Variable gespeichert. Ordner können verschachtelt werden.
• API Flow Recorder: Zeichnen Sie im Nexus Recorder die Aufrufe auf, die die Seite tätigt, und wählen Sie dann Review the recording before the suite is written. Calls listet jeden Aufruf mit Methode, Pfad, Status, Kategorie und Grund auf. Nur geschäftliche, Authentifizierungs-, Lese- und zustandsändernde API-Aufrufe starten in der Suite; Telemetrie-Beacons, Drittanbieter-Hosts, Assets und Preflights sind zunächst ausgeschlossen und können per Häkchen wieder hinzugefügt werden. Flows verketten einen Wert aus einer Antwort in eine spätere Anfrage, wie etwa ein Login-Token, und Redactions listet die geheim aussehenden Felder auf, die als niemals geschrieben markiert sind.
• Aus dem Review heraus: Generate test schreibt die Suite, Generate OpenAPI schreibt einen 3.1-Entwurf mit Typen und Statuscodes ohne aufgezeichnete Werte, und Load test öffnet die Aufrufe als Lasttestplan.

History

Jeder Test für jede Identität, Ausführung für Ausführung.

• Tabs für die Zusammenfassung, Zuverlässigkeit, Leistung, API, Fehler, Abdeckung, Qualität sowie Unit- und Integrationsergebnisse.
• Trends nach Sitzung, Tag oder Woche: Regressiert, Wiederhergestellt, Weiterhin fehlerhaft, Langsamer. Die Identitätsmatrix stellt jeden Test jedem Browser und Gerät gegenüber.
• Unit- und Integrationstests: Importieren Sie JUnit-XML aus Jest, Vitest, pytest, Maven oder gotestsum – getrennt von den End-to-End-Zahlen aufbewahrt.
• Risiko, im Evidence Locker und in Patrol: eine Rangfolge danach, wie oft ein Test wechselt, fehlschlägt oder Zeit kostet, wobei nichts als flaky gilt, das weniger als fünf Durchläufe aufweist, sowie ein vorhergesagtes Risiko aus einer logistischen Regression über Ihre Historie, mit einem EWMA-Fallback bei dünner Datenlage.

Was eine Zeile des Verlaufs enthält →

Visual Regression

Pixelvergleich mit den von Ihnen genehmigten Bildern. Der erste Lauf mit --visual legt die Baseline fest, und jeder spätere Lauf wird damit verglichen. Der Bildschirm öffnet sich direkt bei dem, was eine Entscheidung erfordert: Pixels moved.

• Jede Regression ist eine Karte: der Test, der Checkpoint, der Anteil der verschobenen Pixel im Vergleich zu seiner Toleranz, „N von M px“, die Abmessungen, wie viele Bereiche sich geändert haben, und ein Hinweis, wenn die Erfassung nie stabil wurde. Durch Antialiasing neu überblendete Randpixel werden nicht mitgezählt.
• Ansichten für Side by side, Swipe, Diff und Blink sowie die früheren Läufe desselben Checkpoints: Eine Regression ist eine Tatsache, vier in Folge, die jeweils etwas schlechter werden, sind eine driftende UI, und vier identische sind ein Test, der gegen etwas Instabiles aufgezeichnet wurde.
• Baselines werden pro Browser und Plattform gespeichert. Diese Änderung genehmigen ersetzt nur das Bild dieses Prüfpunkts; Alle genehmigen ist für Änderungen gedacht, die viele Prüfpunkte betreffen, wie z. B. ein globaler Header.
• Einstellungen auf demselben Bildschirm mit ihren Standardwerten: Pixel bei jedem Durchlauf vergleichen aus, Ganzseitige Toleranz 1.0%, Prüfpunkttoleranz für Elemente 0.1%, Eine Regression lässt den Test fehlschlagen aus (die Regression wird aufgezeichnet und der Test bleibt SICHER; an, wird er als VERLETZT angezeigt) und Auf jedem Foto maskiert (CSS-Selektoren) für eine Uhr oder eine Anzeige.
• Pro Regression abgelegt in visual-regression: baseline.png, current.png, diff.png (rot geändert, bernsteinfarbenes Antialiasing ignoriert, grau unverändert), visual-report.md und result.json, die neuesten 10 pro Test und Prüfpunkt bei etwa 1 MB pro Satz.

Executive Report

Die Qualität eines Releases in einer PDF, für die Person, die ihn freigibt.

• Wählen Sie einen Zeitraum: gesamter Zeitraum, die letzten 7, 30 oder 90 Tage oder ein benutzerdefinierter Bereich.
• Eine Release-Entscheidung mit Go, Caution oder No-Go, mit Konfidenz, Abdeckung und Bestehensrate.
• Fehler mit ihrer Grundursache und Geschäftsauswirkung, Stabilität nach Test, Sicherheitsbefunde, API-Tests und die Qualitätspyramide aus End-to-End-, Integrations- und Unit-Ergebnissen.
• Empfehlungen stammen aus Regeln, nicht aus einer KI.

Chaos Lab

Resilienztests, vom Browser bis zum Container.

• Browser-Fehler: Network (≈3G)-Latenz, ein Offline blackout mitten im Test, ein CPU throttle 4x auf Chromium oder alles gleichzeitig, mit Paketverlust und Speicherdruck zusätzlich.
• Infrastruktur: Registrieren Sie einen Docker-Container oder die zu testende Anwendung, und pausieren, stoppen, beenden oder starten Sie diese dann neu – mit oder ohne einen gleichzeitig laufenden Test.
• Die Wiederherstellung wird mit einem Health-Probe alle 500 ms gemessen: Zeit bis zur Erkennung, Zeit bis zur Wiederherstellung, Verfügbarkeit. Das Ergebnis lautet RESILIENT, DEGRADED, NOT_RECOVERED oder NOT_INJECTED.
• Nur registrierte Ziele, niemals die eigenen Container von Nexus Studio. Der Fehler wird schriftlich festgehalten, bevor er ausgelöst wird, und immer wiederhergestellt; ein bestandener Test, bei dem kein Fehler ausgelöst wurde, wird niemals als resilient bezeichnet.

Load

Parallelität, Perzentile und ein Urteil – direkt aus der Engine.

• Worker-Threads in der Engine, kein externes Load-Tool und ein Bericht in statistics.json-Dateien mit Statistiken je Label.
• Anfragen pro Sekunde, p50, p90, p95 und p99, Fehlerrate und APDEX. Das Urteil lautet PASS, OVER_BUDGET oder UNMEASURED.
• Web Vitals unter Last messen: Eine echte Chromium-Seite wird vor dem Last-Test, alle 15 Sekunden während des Tests und danach erfasst – für LCP, CLS, FCP, TTFB und TBT.
• Die Funktion wird erst aktiviert, nachdem Sie AUTHORIZED eingegeben haben; ein Ziel, das nicht dieser Rechner ist, fragt erneut nach.

Sicherheit

Führt die von Ihnen konfigurierten Sicherheitsprüfungen durch und zeichnet die Ergebnisse zusammen mit den Nachweisen auf. Smart Monkey, der DAST-Scanner, befindet sich auf dem Bildschirm „Sicherheit“ unter Scan ausführen.

• Smart Monkey durchsucht ein Ziel, das Sie zum Testen autorisiert haben: XSS, SQL-Injection, fehlerhafte Zugriffskontrolle, IDOR, SSRF, Command-Injection, Path-Traversal, Template-Injection, XXE, Open Redirects, CORS, Sicherheits-Header und Cookie-Flags – unter anderem.
• Wählen Sie eine Phase oder führen Sie alle aus: pre-auth, auth-transit, post-auth, http-probes (Cookies, CORS, Header, Weiterleitungen, Dateien), ssrf, cmdi, xss-oob, sqli (Blind-, boolesche und zeitbasierte), idor oder agent (orchestrierte, budgetierte Erkennung). Eine Zeile in verständlicher Sprache erklärt die von Ihnen ausgewählte Phase.
• Die Out-of-Band-Bestätigung verwendet einen HTTP-Listener auf Ihrem eigenen Rechner: Jede Payload enthält ein zufälliges 32-Zeichen-Token, und SSRF, Command Injection sowie Blind-XSS zählen nur, wenn das Ziel damit zurückruft. Es gibt keinen DNS-Callback und keinen öffentlichen Dienst wie Interactsh oder Burp Collaborator, sodass keine Informationen über Ihr Ziel an Dritte gelangen.
• Autorisierung zum Testen: Ein Host ohne erfasste Grundlage wird abgewiesen, bevor ein Paket gesendet wird; private und lokale Adressen werden ohne Autorisierung zugelassen. Jeder Scan erfasst seine Autorisierung, den Operator, das Ziel, die Operation und ein 60-Minuten-Zeitfenster, lokal versiegelt und niemals irgendwohin gesendet.
• Jede Sitzung legt einen Ordner pro Befund an mit audit_report.json, screenshot.png, replay.webm (sofern die Aufzeichnung erhalten blieb) und einer ausführbaren replay.mjs, die von nexus replay für den Ordner des Befunds ausgeführt wird. Das Stammverzeichnis der Sitzung fügt session_summary.json und results.sarif hinzu. Die neuesten 10 Sitzungen werden aufbewahrt.
• SARIF 2.1.0, ein Ergebnis pro Befund: Die Regel ist die CWE des Befunds, CRITICAL und HIGH werden als error, MEDIUM als warning, der Rest als note interpretiert, und der Speicherort ist die geprüfte URL. GitHub Code Scanning und GitLab lesen dies direkt ein, und nexus monkey schreibt es auf einem CI-Runner ohne das Studio.

Qualitätsprüfungen innerhalb eines Laufs

Pro Lauf in Run patrol oder in den Einstellungen aktiviert. Jede Prüfung ist zunächst beratend, bis Sie sie als strikt festlegen – dann wird sie zu einem Urteil.

• Barrierefreiheit mit axe-core gemäß WCAG 2.1 AA, einschließlich Touch-Target-Größe auf Mobilgeräten.
• Web Vitals anhand von Budgets (LCP 2,5 s, CLS 0,1, INP 200 ms, TTFB 800 ms) sowie ein Lazy-Loading-Audit, das die Art, wie die Seite ihre Bilder lädt, von A bis F bewertet.
• Blockierungserkennung: Ein 403, ein 429 oder eine Challenge-Seite wird als BLOCKED ausgewertet. Automatisierungssignale werden standardmäßig vor der Website verborgen; ein Schalter deaktiviert dies.
• Der Strict-Modus wandelt einen Fehler in A11Y_VIOLATION, PERFORMANCE_DEGRADED oder SECURITY_VIOLATION um.

Timeouts

Wie lange ein Playwright-Schritt warten darf, bevor der Lauf als TIMEOUT gilt. Vier Regler in den Einstellungen unter Execution & Timeouts. Die nachfolgenden Werte sind die Standardwerte.

AI Providers

Die KI hinter der forensischen Analyse von Fehlern und der Triage von Smart Monkey-Befunden.

• Nur lokal ist die Standardeinstellung: ein Modell auf diesem Rechner über Ollama, ohne Fallback in die Cloud.
• Auto, Anthropic oder OpenAI nach Ihrer Wahl, und der Bildschirm zeigt klar an, wenn Prompts Ihr Netzwerk verlassen. Schlüssel sind nur schreibbar.

Settings

Die Schalter hinter den anderen Bildschirmen, an einem Ort.

• Integrationen: Jira, Xray, Azure DevOps, Slack und Telegram, jeweils deaktiviert, bis Sie sie aktivieren. Jira und Azure Boards führen jeweils ein Issue pro fehlgeschlagenem Test: Ein Fehlschlag (BREACHED, BREACHED_FLAKY oder CHAOS_BREACHED) oder ein TIMEOUT öffnet es, eine Wiederholung kommentiert es, ein erfolgreicher Durchlauf schließt es ab. Niemals eine Blockierung, ein Absturz, eine nicht erreichbare Website oder ein Konfigurationsfehler. Integrationen
• Nachweise und Aufbewahrung: wie viele Fehlerberichte, bestandene Screenshots und Scan-Sitzungen jeder Test aufbewahrt.
• Selektoren und Selbstheilung, adaptives Tempo durch RAM-Auslastung sowie die Automatisierungssignale, die der Browser anzeigt.