UN’IMPLEMENTAZIONE EFFICIENTE DELL’AUTOMAZIONE DEI TEST DI ACCETTAZIONE

In questo articolo presento i dati relativi all’analisi delle attività di manutenzione che hanno avuto luogo in 3 settimane di lavoro in uno dei nostri progetti col servizio 121T.

I dati mostrano che le tecniche model-driven che usiamo consentono di abbattere notevolmente lo sforzo di manutezione, rendendo sostenibile l’intero processo di testing.

Cosa significa implementare una strategia di sviluppo e manutenzione dei test che deve essere sostenibile? Qual è lo sforzo richiesto?

Abbiamo già visto alcune metriche che possono essere utilizzate per determinare il valore aziendale di un’iniziativa di automazione dei test software basata su test end-to-end.

Qui illustro come una tale iniziativa può essere attuata e come può essere valutato lo sforzo richiesto. Ciò è necessario per determinare la misura in cui l’approccio del test è sostenibile.

Ecco come affrontiamo il problema con il servizio 121T.

Test harness

Il sistema in prova (SUT) è un’applicazione web nel settore finanziario, la stessa applicazione citata in un post precedente.

I dati presentati di seguito provengono da un mese di lavoro del nostro team e derivano dall’analisi dei commit della base di codice che include i casi di test stessi e il test harness del software che ne supporta l’esecuzione.

Questo test harness (testware basato su JUnit e Cucumber) è generato automaticamente da uno strumento proprietario che compila in file sorgente Java i modelli di automi a stato finito specificando il comportamento previsto del SUT. In particolare utilizziamo UML State Machines. Ogni stato del modello rappresenta uno stato di un widget dell’interfaccia utente e ogni transizione rappresenta un’azione che un utente può eseguire.

Il nostro strumento trasforma stati e transizioni in classi e metodi Java in grado di simulare un’esecuzione degli automi rispetto a una sequenza di eventi, ogni sequenza rappresenta un caso di test.

Il test harness può “toccare” il SUT in una serie di punti di contatto, che corrispondono a punti di azione del SUT (pulsanti, collegamenti, campi di modifica del testo, ecc.) e punti di osservazione (altri elementi dell’interfaccia utente, chiamati oracoli, utilizzati in condizioni di prova). Sia i punti di azione che quelli di osservazione necessitano di un modo per identificare gli elementi specifici nel DOM dell’interfaccia utente, che sono chiamati “locatori”; sono espressioni XPath che coinvolgono ID univoci, classi CSS, tag HTML e attributi.

Dati raccolti

L’analisi comprende 66 commit effettuati lo scorso gennaio in 18 giorni lavorativi consecutivi, 13 dei quali hanno coinvolto il modello ei localizzatori.

Ogni modello impegnato era basato su una media di 926 stati, 790 pseudostati, 535 regioni e 1950 transizioni.

Ogni commit ha aggiunto 3 nuovi stati, 2 nuovi pseudostati e regioni, 6 nuove transizioni. Alcuni commit hanno aggiunto un massimo di 42 stati, 32 pseudostati, 25 regioni e 80 transizioni.

In media, per ogni commit, c’erano 4 nuovi locatori per le azioni e 3 nuovi locatori per gli oracoli, 1 modifica alle azioni e nessuna modifica agli oracoli. In alcuni casi sono state aggiunte fino a 40 nuove azioni.

In totale, ci sono state 54 nuove azioni, 40 nuovi oracoli, 17 modifiche alle azioni e 6 modifiche agli oracoli.

In media, per ogni singola giornata lavorativa, si sono verificate 3 nuove azioni, 2,2 nuovi oracoli, 0,9 modifiche alle azioni e 0,3 modifiche agli oracoli.

Ogni commit ha portato in media a 160 modifiche distribuite su 11 file sorgente e alla creazione di 12 nuovi file. Il massimo era 739 modifiche distribuite su 55 file e 108 nuovi file in fase di creazione.

In totale, per i 13 diversi commit, ci sono state 2077 modifiche distribuite su 146 file e la creazione di 154 nuovi file.

In media, al giorno, ci sono state 115 modifiche su 8 file di origine e con la creazione di 8 nuovi file.

Ogni commit, in media, includeva 2619 file sorgente, con un massimo di 2698; in media ogni commit includeva un totale di 247.000 righe di codice sorgente, con un massimo di 270.000.

Ogni nuova azione ha richiesto 38 modifiche ai file di origine e ogni nuovo oracolo ha portato a 51 modifiche. Ogni azione ha cambiato 2.7 file e ogni oracolo 3.6.

Conclusioni

Tutte le modifiche ai file sorgente del test harness sono state generate automaticamente dal nostro strumento di compilazione del modello. Lo sforzo manuale equivalente è notevole:

Ogni giorno lavorativo i nostri sviluppatori dovrebbero implementare 3 nuove azioni e 2 nuovi oracoli. Ciò richiederebbe 115 modifiche ai file di origine su un totale di 2619 file.

L’aggiunta di nuove azioni e oracoli porta a modifiche relativamente diffuse (rispettivamente su file 38/51). Ciò è dovuto alla natura di queste azioni e oracoli, piuttosto che al modo in cui sono implementati nel codice sorgente: molto spesso la stessa azione o lo stesso oracolo è disponibile su più stati, e ciò richiede opportune modifiche al codice sorgente.

L’aggiunta di modifiche al modello ha un impatto considerevole sul codice sorgente: ad esempio, l’aggiunta di una nuova regione può portare a 83 modifiche coordinate sul codice sorgente.

In ciascuna di queste situazioni, gli sviluppatori dovrebbero decidere quali file modificare, apportare la modifica e quindi testarli. Lo strumento di compilazione, essendo già sostanzialmente testato, produce codice che si presume corretto. Gli sviluppatori devono assicurarsi che i localizzatori e il modello siano corretti, e questo viene fatto tramite strumenti di debug specifici.

Questa analisi è stata effettuata su commit tipici di un progetto di automazione dei test in corso.

Una conclusione ragionevole è che per i test end-to-end che coinvolgono l’interfaccia utente del SUT, è probabile che un approccio ingenuo all’automazione dei test porti a un notevole sforzo di manutenzione, che mina la sostenibilità del processo di test. Le tecniche basate sul modello sono efficaci nel ridurre questo sforzo.