Tutte le schermate dello Studio, e a cosa servono.

Come sono fatti i file

Sì. Ogni test che Studio scrive o importa è codice dei framework che il tuo team già conosce. Il motore aggiunge prove, telemetria, verdetti e riparazione automatica attorno al codice; non lo sostituisce.

• Playwright, JavaScript e TypeScript: un file Playwright Test. L'importazione della fixture in cima è quella dello Studio; il corpo contiene page, localizzatori e expect.
• Playwright, Python: semplice pytest-playwright, una funzione test_ che accetta page. Si esegue con il solo pytest.
• Selenium, Python: pytest con una fixture driver. Il file conftest.py dell'area di lavoro usa un normale WebDriver quando l'esecuzione non è gestita dal motore.
• Selenium, JavaScript: codice selenium-webdriver all'interno di run({ driver, By, until }). L'esecutore dello Studio crea e chiude il driver.
• Selenium, Java: JUnit 5, @ExtendWith(NexusExtension.class), un parametro WebDriver fornito dall'estensione. Compilazione con Maven.
• Selenium e Playwright, C#: NUnit, una classe che estende NexusSeleniumTest o NexusPageTest. Compilazione con .NET.
• I test API usano il formato JavaScript proprio dello Studio.

Come fare a meno di Nexus

I tuoi test, le prove e la cronologia sono file nella tua area di lavoro. Per eseguire la suite senza Nexus: i test Python funzionano così come sono, le importazioni JavaScript di Playwright vanno reindirizzate a @playwright/test (un eventuale punto di controllo visivo va sostituito) e alle funzioni run() di Selenium JavaScript vanno aggiunte poche righe per avviare un driver. I test API andrebbero riscritti per un altro esecutore.

Patrol

Dove si scrivono, eseguono e pianificano i test. La struttura ad albero mostra ogni test con un logo per ciascun browser, colorato in base al suo stato, e la barra di esecuzione sopra l'editor indica a parole cosa sta facendo ogni browser.

• Cinque schede: Casi di test, Esegui pattugliamento, Nexus Recorder, Assistente di scrittura IA e Test Adapter.
• Destinazioni: Matrice desktop (Chromium, Firefox e WebKit), Dispositivo mobile emulato, Dispositivo reale (un telefono Android reale), oppure Desktop + dispositivo reale per il PC e un telefono Android contemporaneamente, con le prove archiviate per identità.
• Per impostazione predefinita, un browser dopo l'altro, oppure fino a tre contemporaneamente e più test alla volta, se lo imposti. Selenium viene eseguito su Chromium e Firefox.
• I nuovi test vengono provati nell'ambiente isolato, senza registrare nulla nella cronologia, prima che le loro esecuzioni inizino a contare.
• Flag di funzionalità: ogni flag viene provato attivo, disattivo o in entrambi gli stati, trasmesso tramite cookie, intestazione, archiviazione locale o stringa di query, e la scheda indica la combinazione con cui un test fallisce.

Nexus Recorder

Registra ciò che fai nel browser sotto forma di codice di test. Non interviene alcuna IA: ciò che clicchi è ciò che viene scritto.

• Registra per Desktop, Dispositivo mobile emulato o un Dispositivo reale: un telefono Android collegato via USB, controllando Chrome sul telefono stesso. Per ora solo JavaScript e Python; Java e C# registrano su desktop.
• Scrive codice Playwright in JavaScript, TypeScript, Python o C#, oppure Selenium in JavaScript, Python, Java o C#.
• Oppure registra le chiamate API effettuate dalla pagina come test REST o GraphQL, senza intestazioni di autenticazione o cookie e trasformando i campi che sembrano contenere segreti in variabili d'ambiente.
• Le Mappe dei selettori analizzano una pagina senza IA, classificano ogni selettore come ALTO, MEDIO o BASSO e conservano la mappa sul tuo disco.

Test Adapter

Importa nello Studio i test che il tuo team ha già, senza riscriverli a mano.

• Incolla un test, trascina un file o indica una cartella: Playwright o Selenium in JavaScript, TypeScript o Python, con Playwright Test, mocha, jest, pytest o unittest.
• Riscrive in base a regole, non con l'IA: l'avvio e la configurazione del browser passano nella fixture dello Studio, mentre asserzioni, condizioni, cicli e attese restano invariati.
• Mostra le differenze affiancate e il numero di asserzioni prima e dopo. La perdita di un'asserzione blocca l'importazione, a meno che tu non la accetti, riga per riga.
• Un'IA facoltativa gestisce solo ciò che nessuna regola copre e il suo codice passa al rigoroso controllo Vet. I test mantenuti vengono provati nell'ambiente isolato fino a completare tre esecuzioni senza errori.
• Cypress, WebdriverIO, Robot Framework, Java e C# non sono supportati.

Riparazione della riga e autoriparazione

Cosa succede quando un localizzatore smette di funzionare. Nulla viene riparato a tua insaputa.

• Autoriparazione, impostata su Suggerisci per impostazione predefinita: dopo un errore, un browser in background riesegue il test fino alla riga non riuscita e legge la pagina, così i candidati sono pronti. Nessuna IA e il test resta rosso.
• Ripara riga, dal margine di quella riga: registra di nuovo solo quel passaggio oppure sostituisci il selettore, dal più robusto fino a XPath per ultimo. La modifica appare nell'editor senza essere salvata e il salvataggio vale come approvazione.
• Chiedi alla mia IA quale scegliere può riordinare i candidati, ma mai aggiungerne uno. La versione precedente del file resta nella sua cronologia.
• Stato dei localizzatori elenca i localizzatori deboli del test aperto e li ripara allo stesso modo.

Devices & Mobile

Telefoni Android reali, collegati tramite USB alla macchina su cui gira il motore. Nessun parco dispositivi remoto, nessun minuto da acquistare.

• Più telefoni contemporaneamente, tramite adb e Chrome DevTools Protocol, con una guida per collegare il primo.
• Visualizza schermo riproduce lo schermo di un telefono sul tuo PC: controllabile da questa schermata e in sola visualizzazione quando viene aperto da Patrol.
• Emulazione mobile, con i profili dispositivo di Playwright: Chrome su Android, un iPhone o iPad su WebKit, il motore di Safari, e un profilo di fascia bassa. I dispositivi reali sono solo telefoni Android: un iPhone o iPad viene emulato, non è mai un dispositivo Apple fisico, quindi la tastiera e i gesti di sistema di iOS non vengono testati.
• I test su un telefono vengono eseguiti uno alla volta e l'esecuzione su telefono resta sempre sulla macchina a cui è collegato.

Watch

In Patrol, sotto Esegui pattugliamento: riesegue una selezione a intervalli programmati, senza supervisione.

• Ripeti a intervalli da 5 minuti a 24 ore, oppure Una volta, in una data. Termina quando lo interrompi, dopo un certo numero di esecuzioni o in una data.
• Viene eseguito come processo indipendente, quindi chiudere lo Studio non lo interrompe. La macchina deve restare accesa: mentre è in sospensione, le esecuzioni pianificate restano in attesa o vengono saltate.
• Avvisi su Telegram o Slack solo quando cambia uno stato, come ALLARME o RIPRISTINATO.

Docker e SSH

Studio è un'applicazione desktop per Windows 11, da usare sul tuo PC o, facoltativamente, su un mini PC con Windows 11. Da Studio, il motore esegue le suite di un'area di lavoro su questa macchina, in Docker sulla stessa macchina oppure tramite SSH su un'altra macchina. Studio stesso non viene mai eseguito in Docker o tramite SSH.

• In Docker, la suite viene eseguita nel contenitore del runner sullo stesso disco, quindi le evidenze vengono salvate nel tuo spazio di lavoro come di consueto.
• Tramite SSH, su un VPS con Ubuntu 24.04 LTS, Docker Engine e Compose v2, con accesso basato su chiavi: il motore esegue la suite sul VPS nella stessa immagine del contenitore usata localmente con Docker e le evidenze restano lì finché non le scarichi.
• Telefoni Android reali, suite Selenium e Python, caos infrastrutturale e importazione dei risultati vengono sempre eseguiti sulla macchina dello Studio.
• La barra superiore mostra dove viene eseguito lo spazio di lavoro e la RAM e la CPU disponibili. Quando attivi la gestione adattiva del carico, il numero di browser eseguiti contemporaneamente si adatta alla RAM libera.

Test API

Test REST e GraphQL con sette verdetti dedicati. Si eseguono da Patrol come qualsiasi test e ogni endpoint ha una propria cartella nella sezione dei test API di Evidence Locker.

• API_SECURE: tutte le asserzioni sono state soddisfatte e la struttura della risposta corrisponde all'ultima registrata. API_FLAKY: il test è passato a un nuovo tentativo. API_DRIFTED: il test è passato, ma la struttura è cambiata e il confronto indica ogni campo aggiunto, rimosso o di cui è cambiato il tipo. Una variazione conta come esito positivo finché non imposti il controllo rigoroso.
• API_BREACHED: un'asserzione non è stata soddisfatta. API_DEGRADED: latenza superiore al limite previsto, pari a 2000 ms per impostazione predefinita, e verdetto assegnato solo quando il controllo delle prestazioni è rigoroso. API_VULNERABLE: una richiesta senza credenziali ha ricevuto risposta dove era atteso un 401 o un 403; la sola assenza di un'intestazione di sicurezza non determina mai questo verdetto. API_BLOCKED: un 429, oppure un 403 con una firma Cloudflare o Akamai, quindi la richiesta non ha mai raggiunto il tuo prodotto.
• Sullo schermo: riquadri per endpoint, esiti positivi, esecuzioni oltre il limite, strutture cambiate, vulnerabilità rilevate almeno una volta e massima latenza osservata; i filtri tutti, falliti, variati e vulnerabili; e una tabella con endpoint, verdetto, min, mediana, p95, max, n e percentuale di successo. Un endpoint con meno di 20 osservazioni mostra un trattino, non un percentile.
• Fai clic su un'esecuzione per aprirla in sei schede: Rapporto, Richiesta, Risposta, Prestazioni, Schema e Analisi IA, quest'ultima compilata quando la tua IA è collegata. Un passaggio fallito di un flusso offre Riesegui dal passaggio N e Riesegui il passaggio fallito.
• Archiviati per ogni esecuzione in api-evidence: request.json, response.json, performance.json, schema.json, report.md e metadata.json, con i dati segreti oscurati nelle intestazioni e nel corpo. report.md termina con un comando curl che ripete la chiamata. Per le esecuzioni riuscite si conservano le 20 più recenti per test; quelle fallite vengono sempre conservate.
• Crearne uno: Nuovo test, API, richiede un Tipo: REST, GraphQL o SOAP su HTTP. Ogni Tipo parte da un caso che viene eseguito così com'è su un endpoint pubblico, e la prima riga del file registra il Tipo, così l'albero dei file lo mostra e spostare il file non lo modifica. SOAP è XML inviato come testo e verificato con regole testuali, senza un analizzatore XML. Gli ambienti con nomi come staging e prod mantengono ciascuno il proprio URL di base, e un token viene conservato solo come nome della relativa variabile. Le cartelle possono essere annidate.
• API Flow Recorder: in Nexus Recorder, registra le chiamate effettuate dalla pagina, poi Rivedi la registrazione prima che venga scritta la suite. Chiamate elenca ciascuna chiamata con metodo, percorso, stato, categoria e motivazione. Inizialmente la suite include solo le chiamate API applicative, di autenticazione, di lettura e di modifica dello stato; i beacon di telemetria, gli host di terze parti, le risorse e le richieste preliminari sono esclusi, ma puoi selezionarli per includerli. I Flussi collegano un valore di una risposta a una richiesta successiva, come un token di accesso, e Oscuramenti elenca i campi che sembrano contenere dati segreti, contrassegnati per non essere mai scritti.
• Dalla revisione: Genera test crea la suite, Genera OpenAPI crea una bozza 3.1 con tipi e codici di stato e senza valori registrati, mentre Test di carico apre le chiamate come piano di carico.

History

Ogni test su ogni identità, esecuzione dopo esecuzione.

• Schede per riepilogo, affidabilità, prestazioni, API, errori, copertura, qualità e risultati dei test unitari e di integrazione.
• Andamenti per sessione, giorno o settimana: Peggiorato, Ripristinato, Ancora non funzionante, Più lento. La matrice delle identità incrocia ogni test con ogni browser e dispositivo.
• Test unitari e di integrazione: importa file XML JUnit da Jest, Vitest, pytest, Maven o gotestsum, mantenendoli separati dai dati dei test end-to-end.
• Rischio, in Evidence Locker e in Patrol: una classifica basata su quanto spesso un test cambia esito, fallisce o fa perdere tempo, in cui nessun test viene definito instabile prima di cinque esecuzioni, e una previsione del rischio tramite regressione logistica sulla cronologia, con ripiego su EWMA quando i dati scarseggiano.

Cosa contiene una riga della Cronologia →

Visual Regression

Confronto dei pixel con le immagini che hai approvato. La prima esecuzione con --visual crea il riferimento e ogni esecuzione successiva viene confrontata con esso. La schermata si apre su ciò che richiede una decisione: Pixel modificati.

• Ogni regressione è una scheda: il test, il punto di controllo, la percentuale di pixel modificati rispetto alla tolleranza, "N di M px", le dimensioni, il numero di aree modificate e una nota se l'acquisizione non si è mai stabilizzata. I pixel dei bordi ricalcolati dall'antialiasing non vengono conteggiati.
• Viste Affiancate, Scorrimento, Differenze e Alternanza, e le esecuzioni precedenti dello stesso punto di controllo: una regressione è un dato di fatto, quattro consecutive ciascuna leggermente peggiore indicano un'interfaccia che cambia progressivamente, e quattro identiche indicano un test registrato su qualcosa di instabile.
• Le immagini di riferimento vengono conservate per browser e piattaforma. Approva questa modifica sostituisce solo l'immagine di quel punto di controllo; Approva tutto serve per una modifica che ne interessa molti, come un'intestazione globale.
• Impostazioni sulla stessa schermata, con i valori predefiniti: Confronta i pixel a ogni esecuzione disattivato, Tolleranza dell'intera pagina 1.0%, Tolleranza del punto di controllo dell'elemento 0.1%, Una regressione fa fallire il test disattivato (la regressione viene registrata e il test resta SECURE; se attivato, riporta BREACHED), e Mascherati in ogni foto (selettori CSS) per un orologio o un annuncio.
• Archiviati per ogni regressione in visual-regression: baseline.png, current.png, diff.png (rosso per le modifiche, ambra per l'antialiasing ignorato, grigio per le parti invariate), visual-report.md e result.json, i 10 più recenti per test e punto di controllo, a circa 1 MB per insieme.

Executive Report

La qualità di un rilascio in un unico PDF, per chi deve approvarlo.

• Scegli un periodo: dall'inizio, gli ultimi 7, 30 o 90 giorni, oppure un intervallo personalizzato.
• Una decisione sul rilascio: procedere, procedere con cautela o non procedere, con livello di confidenza, copertura e percentuale di superamento.
• Errori con causa radice e impatto aziendale, stabilità per test, vulnerabilità rilevate, test delle API e piramide della qualità dei risultati end-to-end, di integrazione e unitari.
• Le raccomandazioni derivano da regole, non da un'IA.

Chaos Lab

Test di resilienza, dal browser al container.

• Guasti del browser: latenza di Rete (≈3G), un'Interruzione della connessione durante il test, un Rallentamento CPU 4x su Chromium, oppure tutti insieme, con l'aggiunta di perdita di pacchetti e pressione sulla memoria.
• Infrastruttura: registra un container Docker, oppure l'app da testare, poi mettilo in pausa, arrestalo, terminalo forzatamente o riavvialo, con o senza un test in esecuzione su di esso.
• Il ripristino viene misurato con una verifica dello stato ogni 500 ms: tempo di rilevamento, tempo di ripristino, disponibilità. L'esito è RESILIENT, DEGRADED, NOT_RECOVERED o NOT_INJECTED.
• Solo destinazioni registrate, mai i container di Studio. Il guasto viene registrato prima di essere attivato e le condizioni iniziali vengono sempre ripristinate; un test superato senza che sia stato attivato alcun guasto non viene mai definito resiliente.

Load

Concorrenza, percentili e un verdetto, direttamente dal motore.

• Thread di lavoro nel motore, nessuno strumento di carico esterno e un rapporto in file statistics.json distinti per etichetta.
• Richieste al secondo, p50, p90, p95 e p99, tasso di errore e APDEX. Il verdetto è PASS, OVER_BUDGET o UNMEASURED.
• Misura i Web Vitals sotto carico: una vera pagina Chromium campionata prima del carico, ogni 15 secondi durante il carico e dopo, per LCP, CLS, FCP, TTFB e TBT.
• Si attiva solo dopo aver digitato AUTHORIZED, e chiede una nuova conferma se la destinazione non è questa macchina.

Sicurezza

Esegue i controlli di sicurezza che configuri e registra ciò che ha rilevato, con le prove. Smart Monkey, lo scanner DAST, si trova nella schermata Sicurezza sotto Esegui una scansione.

• Smart Monkey analizza una destinazione che sei autorizzato a testare: XSS, SQL injection, controllo degli accessi compromesso, IDOR, SSRF, iniezione di comandi, attraversamento dei percorsi, iniezione nei template, XXE, reindirizzamenti aperti, CORS, intestazioni di sicurezza e attributi dei cookie, tra gli altri.
• Scegli una fase o eseguile tutte: pre-auth, auth-transit, post-auth, http-probes (cookie, CORS, intestazioni, reindirizzamenti, file), ssrf, cmdi, xss-oob, sqli (cieca, booleana e basata sul tempo), idor o agent (ricerca orchestrata con un budget definito). Una riga in linguaggio semplice spiega quella che hai scelto.
• La conferma fuori banda usa un listener HTTP sul tuo computer: ogni payload contiene un token casuale di 32 caratteri, e SSRF, iniezione di comandi e XSS cieco vengono conteggiati solo quando il bersaglio effettua una richiesta di ritorno con quel token. Non ci sono richieste di ritorno DNS né servizi pubblici come Interactsh o Burp Collaborator, quindi nessuna informazione sul tuo bersaglio viene trasmessa a terzi.
• Autorizzazione ai test: un host privo di una base di autorizzazione registrata viene rifiutato prima che venga inviato un pacchetto, mentre gli indirizzi privati e locali vengono accettati anche senza. Ogni scansione registra autorizzazione, operatore, bersaglio, operazione e una finestra di 60 minuti, sigillati localmente e mai trasmessi altrove.
• Ogni sessione archivia una cartella per ciascun rilievo con audit_report.json, screenshot.png, replay.webm se la registrazione è stata conservata, e un file eseguibile replay.mjs che nexus replay esegue sulla cartella del rilievo. La cartella principale della sessione aggiunge session_summary.json e results.sarif. Vengono conservate le 10 sessioni più recenti.
• SARIF 2.1.0, un risultato per rilievo: la regola è il CWE del rilievo, CRITICAL e HIGH corrispondono a error, MEDIUM a warning, gli altri a note, e la posizione è l'URL sottoposto a verifica. GitHub code scanning e GitLab lo importano direttamente, e nexus monkey lo scrive su un esecutore CI senza Studio.

Controlli di qualità durante un'esecuzione

Si attivano per ogni esecuzione in Avvia pattuglia o nelle Impostazioni. Ciascuno è solo indicativo finché non lo imposti come rigoroso, dopodiché diventa un verdetto.

• Accessibilità con axe-core rispetto alle WCAG 2.1 AA, oltre alle dimensioni delle aree toccabili sui telefoni.
• Web Vitals rispetto alle soglie (LCP 2.5 s, CLS 0.1, INP 200 ms, TTFB 800 ms), e una verifica del caricamento differito che assegna un voto da A a F al modo in cui la pagina carica le immagini.
• Rilevamento dei blocchi: un 403, un 429 o una pagina di verifica producono l'esito BLOCKED. I segnali di automazione sono nascosti al sito per impostazione predefinita, e un interruttore disattiva questa funzione.
• La modalità rigorosa trasforma una violazione in A11Y_VIOLATION, PERFORMANCE_DEGRADED o SECURITY_VIOLATION.

Timeouts

Quanto può attendere un passaggio Playwright prima che l'esecuzione riporti TIMEOUT. Quattro parametri nelle Impostazioni, sotto Esecuzione & Timeout. I valori seguenti sono quelli predefiniti.

AI Providers

L'IA alla base dell'analisi forense degli errori e della classificazione dei risultati di Smart Monkey.

• Solo locale è l'impostazione predefinita: un modello su questa macchina tramite Ollama, senza ricorso al cloud.
• Auto, Anthropic o OpenAI quando lo scegli tu, e la schermata indica chiaramente quando i prompt escono dalla tua rete. Le chiavi sono di sola scrittura.

Settings

Le impostazioni alla base delle altre schermate, in un unico posto.

• Integrazioni: Jira, Xray, Azure DevOps, Slack e Telegram, tutte disattivate finché non le attivi. Jira e Azure Boards mantengono una sola segnalazione per ogni test non riuscito: un errore (BREACHED, BREACHED_FLAKY o CHAOS_BREACHED) o un TIMEOUT la apre, una ricorrenza aggiunge un commento, un esito positivo senza errori la chiude. Mai in caso di blocco, arresto anomalo, sito irraggiungibile o errore di configurazione. Integrazioni
• Prove e conservazione: quanti rapporti sui bug, schermate di test superati e sessioni di scansione conserva ogni test.
• Selettori e autoriparazione, ritmo adattivo in base alla pressione sulla RAM e segnali di automazione mostrati dal browser.