Automazione dei test
Ogni nuova versione può rompere ciò che ieri funzionava ancora. Nel software desktop spesso ce ne si accorge solo presso il cliente: una finestra di dialogo non si apre più, un comando calcola in modo errato, un add-in non si carica. Chi ricontrolla tutto a mano, con intervalli brevi tra una versione e l'altra, difficilmente riesce ancora a farlo in modo completo.
I test automatizzati dell'interfaccia utente usano la Sua applicazione come farebbe un utente e ne verificano il risultato. Decisivo però non è solo come crea i test, ma anche quando vengono eseguiti.
Quali test convengono
Automatizzi prima ciò che si ripete spesso: test di regressione dopo ogni modifica, grandi quantità di controlli dello stesso tipo e test guidati dai dati, cioè lo stesso flusso con molti record. Ne fanno parte anche i controlli con elevati requisiti di precisione. Non si può automatizzare l'usabilità: se un'interfaccia è comprensibile, lo giudica una persona.
Creare i test: registrare invece di programmare
Con il nostro strumento TesteriX registra i passi di utilizzo senza scrivere codice di test. Durante la registrazione TesteriX riconosce gli elementi di comando del programma da testare – menu, barre multifunzione, finestre di dialogo, barre degli strumenti e campi di immissione – e li incornicia non appena il mouse vi passa sopra. Ogni clic e ogni immissione vengono salvati come azione insieme all'oggetto di destinazione. Per il riconoscimento TesteriX utilizza FlaUI, elaborazione delle immagini e riconoscimento basato sull'IA. Lo impieghiamo per applicazioni desktop con WPF, WinForms, MFC o QML.
Successivamente aggiunge le verifiche: un'azione confronta il valore effettivo con quello atteso. I valori restituiti li salva in variabili e li riutilizza nei passi successivi.
Un caso particolare sono i sistemi CAD. I clic nell'area di disegno dipendono dalla risoluzione e dalla versione del programma. Per AutoCAD e BricsCAD TesteriX controlla quindi l'area di disegno tramite comandi CAD tratti da un catalogo di diverse centinaia di comandi, ad esempio «cerchio con centro 0,0,0 e raggio 50». Comandi di interrogazione verificano poi che cosa c'è effettivamente nel disegno.
Quando vengono eseguiti i test
| Modalità | Chi avvia | A che cosa serve |
|---|---|---|
| A mano | Sviluppatori o tester alla propria postazione | Provare nuovi test, riprodurre errori, eseguire singole azioni o casi di test |
| Avviati in modo mirato | Una persona, in un'occasione precisa | Prima di un rilascio o dopo una correzione, su richiesta solo per le aree interessate |
| Pianificati | Una pianificazione, ad esempio di notte o nel fine settimana | Lunghe sessioni di test su un computer di test o su una macchina virtuale; al mattino il rapporto è pronto |
| Nella build (CI) | Il server di build a ogni modifica | Intercettare gli errori prima che una versione venga distribuita |
A mano, con la selezione determina che cosa viene eseguito: un'azione, un caso di test o più progetti di test. Con F5 il test gira con debug e si ferma ai punti di interruzione e in caso di errore. Con Ctrl+F5 gira senza interruzioni. F10 esegue esattamente un passo – pratico per circoscrivere un errore.
Per la build salva la soluzione come file .tse e la registra nel repository Git del software da testare. Sul server di build il TesteriX TestPlayer, una variante senza interfaccia grafica, esegue i test e mette i risultati a disposizione del server CI. Così i test vengono eseguiti a ogni build, ad esempio in Azure DevOps, GitHub Actions o Jenkins. Una build pianificata sullo stesso server può farsi carico dell'esecuzione notturna.
Valutare i risultati
Dopo l'esecuzione la finestra dei risultati mostra per ogni azione uno stato: riuscita, avviso, errore o non eseguita. Un avviso segnala ad esempio prestazioni anomale o valori non confrontati. Per ogni elemento TesteriX registra data, ora e durata. Come verbale genera un PDF da archiviare o una pagina HTML da scorrere rapidamente. In alternativa trasferisce i risultati a Xray in Jira. Su richiesta si aggiungono screenshot delle azioni.
Riutilizzare i test per più versioni
Spesso i test per due versioni di un programma differiscono di poco. Invece di registrare tutto da capo, inserisce un caso di test come collegamento nel secondo progetto. Il collegamento mostra i passi dell'originale senza copiarli. Se lì modifica soltanto un valore, il riferimento rimane. Le aggiunte all'originale le riprende con «Sincronizza collegamento».
Errori tipici
- Testare sul computer di produzione. I test automatizzati controllano i programmi a distanza e modificano file. Usi un computer di test dedicato e salvi prima i disegni e i dati utilizzati.
- Cliccare nell'area di disegno. I clic su coordinate dello schermo falliscono con un'altra risoluzione o versione. Nei sistemi CAD usi i comandi CAD.
- Registrare senza verificare. Un test che si limita a cliccare trova solo i crash. Solo le verifiche lo rendono significativo.
- Soluzioni enormi. Più soluzioni piccole sono meglio di una grande. Restano veloci e chiare.
- Dimenticare l'antivirus. Uno strumento che controlla a distanza altri programmi può far scattare avvisi. Imposti prima un'eccezione.
- Ignorare i test rossi. Se un test fallisce in modo permanente, presto nessuno ci fa più caso. Elimini la causa o adegui subito il test.
Come La aiutiamo
- Realizziamo la Sua automazione dei test, ne prendiamo in carico una esistente o la consegniamo al Suo team: Automazione dei test.
- Il nostro strumento di test per applicazioni desktop e CAD: TesteriX nel Cadida-Shop.
- Perché i Suoi test restino eseguibili, li curiamo costantemente: Supporto e manutenzione.
- Ci racconti come esegue i test oggi: Fissi un primo colloquio.
Fonti: guida di TesteriX (versione 2026.7), capitoli «Registrazione e riproduzione», «Particolarità CAD», «Risultati», «Riutilizzo tramite collegamenti» e «Integrazione nella Continuous Integration»; Cadida: Automazione dei test.
kununu