AO_399

114 / 134

GIUGNO-LUGLIO 2017 AUTOMAZIONE OGGI 399 114
AO SOFTWARE
Aggiungere parallelizzazione
alla simulazione
L’organizzazione del processo è solo una parte del processo
stesso. È anche fondamentale l’utilizzo di una struttura parallela
di testing per la riduzione dei tempi di CI. Utilizzando Jenkins
come server CI, i target di test devono anche essere vagliati.
Una delle scelte più note è l’utilizzo di Simics di Wind River, che
funziona come un simulatore in grado di replicare una modalità
dell’hardware target. Utilizzando Jenkins e Simics insieme, gli in-
gegneri possono decidere quale ambiente testare e individuare
quali casi necessitano di essere ricompilati ed eseguiti, in base
alle modifiche apportate al codice sorgente.
Gli sviluppatori possono effettuare il set up di differenti configu-
razioni della stessa scheda, per eseguire test equivalenti, il che
consente complete attività di coverage dei test.
Dunque Simics rende il testing più affidabile, dato che, avendo
la possibilità di testare un modello dell’hardware (a volte per-
sino prima che questo sia disponibile), vi sono meno possibilità
di incorrere in errori con i test effettivi, che potrebbe far sprecare
tempo prezioso. Simics offre anche la possibilità di registrare e
riprodurre i valori di input, il che supporta la CI consentendo l’ac-
cesso alle informazioni e al loro utilizzo da parte di altri membri
del team. Per agevolare un ambiente completo di CI è poi neces-
saria una piattaforma unificata, che metta insieme tutti questi
elementi in un solo luogo. La soluzione ideale è una piattaforma
che possa organizzare tutti i test case in gruppi che consentono
agli sviluppatori di mappare l’architettura dell’applicazione e che
permetta di testare singoli stack, anticipando i test di sistema e
accelerando la versione pronta per la distribuzione.
Effettuare test solo su ciò che lo richiede
Ora che abbiamo un ambiente che possa eseguire una suite
completa di test, il più rapidamente possibile, si possono otte-
nere prestazioni software maggiori soltanto effettuando gli spe-
cifici test richiesti per ripristinare al 100% la totalità del testing
quando viene apportata una modifica al codice sorgente. Il prin-
cipio dell’analisi di impatto di un cambiamento (Change-Impact
Analysis) è ben conosciuto e documentato ed è l’ingrediente fi-
nale nella creazione di un sistema di CI davvero evoluto.
In VectorCart è presente una funzionalità di Change-Based Te-
sting che identifica automaticamente i test minimi necessari da
eseguire per ogni variazione del codice. Ciò significa che, invece
di eseguire 10.000 test, è richiesto che solo una frazione dei test
venga eseguita nuovamente quando avviene un cambiamento,
il che riduce notevolmente i tempi da giorni a minuti.
Un esempio per capire
Per contestualizzare tutto questo, possiamo prendere a esempio
un ipotetico scenario che si può anche trovare sul sito web di
Vector Software. Immaginiamo un piccolo progetto di 20 am-
bienti, per un totale di 122 test di unità, che utilizza l’ambiente
di analisi mostrato in Figura 3, che contiene VectorCast, un server
di Jenkins con nove nodi slave distribuiti su tre host di prova,
ognuno con tre ambienti di board simulati. Abbiamo un riferi-
mento di 47 minuti per compilazione ed esecuzione combinate,
utilizzando un singolo nodo slave e scheda Simics per eseguire
un set completo di test.
Per dimostrare la potenza del parallelismo, creiamo i processi dei
20 ambienti test utilizzando VectorCast, che li invia a una coda
di compilazione Jenkins. Jenkins eseguirà i primi nove processi
sui nodi slave, dove vengono eseguiti sulle schede Simics; ciò
prosegue fino a quanto la compilazione non è completa. Il risul-
tato è un tempo complessivo di ricompilazione ripartito di 7:47
secondi. Ciò equivale a una compilazione sei volte più veloce o
l’85% di risparmio sui tempi.
Apportiamo alcune modifiche a due dei moduli e avviamo una
ricompilazione. Tra VectorCast e Jenkins, il sistema eseguirà solo
quei test che hanno bisogno di essere nuovamente eseguiti e
invierà i processi in coda e sui nodi slave. Ciò che accade è che
il primo modulo ha bisogno di una completa ricompilazione e
analisi dei tre casi di test, mentre il secondo modulo deve solo
completare una ricompilazione incrementale e l’esecuzione di
due dei nove casi. Il risultato è che solo per cinque test case è
necessaria l’esecuzione, su un totale di 122. Ne consegue un
tempo di esecuzione per la ricompilazione inferiore ai 2 minuti.
In termini di tempo risparmiato rispetto al riferimento stabilito,
stiamo parlando di circa il 95%. Questo dimostra chiaramente la
potenza di un ambiente di testing distribuito parallelizzato, in
grado di supportare continue variazioni dei requisiti. •
Vector Software
-
Figura 3 - Impiegando VectorCast e Jenkins, il sistema
eseguirà solo i test che occorre realmente rieseguire,
risparmiando tempo
Figura 4 - Scopo di un sistema di CI evoluto è abilitare i test
subito e spesso: si parla di Agile Development o Test-Driven
Development