QA Wolf esegue test Windows da runner Linux con VM usa e getta
Testo scritto con l’intelligenza artificiale a partire da una fonte citata, senza revisione umana prima della pubblicazione.
La piattaforma crea e distrugge VM Windows su GCE gestite via Kubernetes, permettendo test GUI paralleli da pod Linux.
Due o tre minuti per avviare una VM Windows, pochi secondi per un container di browser. QA Wolf aggira il collo di bottiglia con VM Windows usa e getta su Google Compute Engine, orchestrate da Kubernetes e pilotate da pod Linux1.
Il problema è noto. Il testing web scala perché un browser headless nasce in un container, costa frazioni di centesimo e sparisce a fine run. Sul desktop Windows non c’è un equivalente. Ogni test richiede una VM completa. I container Windows non includono il desktop grafico. L’automazione UI funziona solo dentro una sessione attiva con utente loggato. Le macchine mantengono stato tra le esecuzioni: file installati, chiavi di registro, profili, login salvati, processi orfani. Ogni app porta installer, prompt di amministratore, dipendenze con licenza, dialog di prima esecuzione e accessi. I browser offrono tracce e screenshot, una macchina remota no, a meno di costruire visibilità ad hoc. La maggior parte degli strumenti dà per scontato Linux e i container1.
La scelta di progetto: trattare le VM come telefoni. Un test le reclama, le usa una volta, poi le distrugge. “Smettere di trattare le macchine Windows come server e trattarle come telefoni” è la sintesi dell’approccio1.
L’architettura riprende il modello mobile. Tre componenti lavorano insieme: un controller in Kubernetes mantiene un pool di VM Windows su GCE, un runner in un pod Linux esegue il codice di test, una VM Windows avvia l’app sotto test, gli strumenti di automazione e un piccolo agente desktop. Le VM sono modellate come device. Un test chiede una macchina al device scheduler con un DeviceClaim e riceve gli indirizzi di connessione. Per Windows il device può vivere fuori dal cluster, per esempio come VM GCE, e la claim restituisce anche gli endpoint CDP per i browser. Il ciclo di vita segue i passi già usati sul mobile: claim, heartbeat, record, connect, run, release. Anche le pool private Windows replicano quelle iOS1.
Il runner parla con la VM su tre canali. Playwright usa il protocollo CDP per tutto ciò che avviene nel browser. Appium, insieme a WebdriverIO, controlla le app native Windows. Un flusso WebRTC trasmette lo schermo in diretta e produce una registrazione per la revisione1.
Per tagliare le attese, il pool tiene VM già avviate e con sessione desktop attiva. Quando parte una run, il pod Linux chiede un device, il scheduler assegna una VM pronta, il runner riceve gli indirizzi per CDP, Appium e streaming, l’app viene consegnata e lanciata, lo schermo va in live e si registra. A fine test la VM viene eliminata, una VM fresca prende il suo posto nel pool1.
L’allocazione passa da tre risorse custom di Kubernetes. WindowsVMTemplate descrive immagine, dimensione e configurazione della VM. WindowsVMPool definisce quante VM pronte mantenere per ogni template. WindowsVM rappresenta una macchina concreta. Un reconciler nel scheduler confronta lo stato nei record con ciò che gira su GCE e chiude il divario: crea VM quando mancano, elimina quelle rilasciate. L’avvio richiede minuti, quindi avanza ogni macchina a piccoli passi e annota i progressi sul record. Un boot lento non blocca il resto dei device gestiti1.
Resta la tensione centrale del desktop testing: macchine pulite sono lente, macchine veloci non sono pulite. Il pool di VM già avviate e loggate riduce il costo del cold boot, che dura 2-3 minuti, e la distruzione a fine test evita la deriva di stato tra run1. L’implicazione è operativa: per scalare, il reconciler deve tenere il magazzino pieno e visibile, e i test devono comunque gestire installer, prompt e accessi che ogni app porta con sé. La promessa è la parallelizzazione su richiesta, con visibilità costruita a misura di desktop, in un ecosistema che finora ha privilegiato il browser e i container1.
Fonti
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici
Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:
- Rilettura. Un passaggio toglie i tic della prosa generata da un modello, come i contrasti costruiti e le frasi che annunciano invece di informare, senza toccare fatti e fonti.
- Fedeltà alle fonti. Un passaggio dedicato toglie ogni affermazione che le fonti non sostengono. Valutazione su questo pezzo: 9,5/10.
- Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale: superato.
- Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica. Questo articolo ha preso 8,3/10 dopo 2 revisioni.
I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.
Per vedere Millebit nelle notizie principali di Google, aggiungilo alle tue fonti preferite. Oppure segui l’edizione di oggi, il feed RSS o La Sintesi.