Testing di integrazione software su target reale: una leva strategica per qualità e compliance.

A cura di Rosario Silvano, Daniele Gaspare Vallone e Viviana Scot.

Resp. Linea On Host Test, Technician e Resp. Unità V&V – Area Ingegneria del Software

Tra le attività di Verifica e Validazione, la campagna di test di integrazione software è tra le più complesse e onerose. Spesso viene eseguita in ambiente simulato (host), escludendo così l’interazione con librerie di sistema e kernel, cioè il componente software che gestisce le risorse del computer.

Tuttavia, nei settori altamente regolamentati come ferroviario, avionico, biomedicale e automotive, l’esecuzione dei test su hardware reale – tramite una scheda di sviluppo (PIL, Processor-in-the-Loop) o direttamente sul dispositivo di produzione (HIL, Hardware-in-the-Loop) – è spesso un requisito fondamentale per ottenere la certificazione.

Anche in progetti meno vincolati normativamente, eseguire la fase di test in un ambiente il più simile possibile a quello reale consente di individuare con maggiore precisione anomalie e regressioni, migliorando al contempo l’efficienza del ciclo di sviluppo.

Un importante improvement, quindi, è riuscire ad eseguire i test di integrazione software direttamente su target, utilizzando strumenti certificati, in modo da validare efficacemente sia l’interazione tra le varie interfacce che compongono il software applicativo che l’interazione tra il software applicativo e quello di più basso livello, con il doppio vantaggio di ridurre la durata della compagna di test e di migliorare il controllo di qualità del prodotto.

Vediamo come questo è possibile nel case study in ambito ferroviario, in particolare relativamente al software di un interlocking [1]con architettura 2oo2.

Continua a leggere se ne vuoi sapere di più.

STRUMENTI E STRUMENTAZIONE.

Il testing su hardware presenta molte sfide, tra cui la gestione delle risorse limitate del target, la minimizzazione dell’impatto sul tempo di esecuzione, l’automatizzazione di meccanismi di comunicazione con il target per la raccolta dei dati e la formazione dei team per configurare e risolvere i problemi di esecuzione sul target stesso.

In questa ottica, l’uso di strumenti per il software testing certificati è fondamentale per il raggiungimento dell’obbiettivo.

Come illustrato in Figura 1, VectorCAST/QA può essere utilizzato per strumentare in modo automatico il codice sorgente di un applicativo in fase di deploy. La strumentazione apportata è ottimizzata il più possibile per soddisfare vincoli di size e timing comuni in ambienti embedded e la versione strumentata dell’applicativo che ne risulta sarà in grado di collezionare e generare dati e metriche di coverage durante lo svolgimento di una normale sessione di system testing (o test funzionali).

CASE STUDY.

Come Case Study si è scelto, da un progetto in ambito ferroviario, il software applicativo di un interlocking dall’architettura 2oo2 costituita, quindi, da due sezioni fisiche distinte (NORMALE, RISERVA), ognuna delle quali è a sua volta costituita da una coppia di canali di calcolo (CPUA, CPUB) i cui risultati devono coincidere affinché possano essere ritenuti validi.

In Figura 2 è riportata l’architettura fisica dell’interlocking oggetto del case study in cui i due canali di calcolo, al fine di garantire la diversity software, ospitano sistemi operativi diversi: Linux e FreeBSD.

Le principali caratteristiche del prodotto sono:

• Codice sorgente scritto in linguaggio C
• Ambiente di compilazione su container Docker Linux
• Ambiente di esecuzione distribuita su schede Target con sistemi operativi Linux e FreeBSD

La scelta del canale di calcolo da sottoporre a strumentazione è ricaduta sul canale destinato ad ospitare il sistema operativo Linux con un obiettivo ben preciso: rieseguire alcuni test funzionali “ai morsetti” verificando che le strumentazioni apportate non interferissero con il “normale” comportamento dell’applicativo e, quindi, con i vari meccanismi di sicurezza che lo caratterizzano. Al termine dei test si acquisiscono i dati di coverage al fine di attestare l’integrazione sw, sollecitata direttamente in tale fase.

L’implementazione è stata impostata secondo le seguenti fasi:

1. Integrazione dello strumento di software testing nell’ambiente di deploy
2. Applicazione della strumentazione sui sorgenti del sw applicativo
3. Compilazione dell’applicativo a partire dai sorgenti strumentati e caricamento degli eseguibili sulle schede Target
4. Avvio degli eseguibili e interazione con il sistema tramite simulatori esterni, prevedendo l’esecuzione di test funzionali per verificare la stabilità del sistema a fronte delle strumentazioni introdotte
5. Recupero dei dati di coverage prodotti e generazione automatica dei report di copertura

RISULTATI.

L’utilizzo della code coverage nella verifica dell’integrazione software ha evidenziato i seguenti vantaggi:

• Tempi di implementazione ridotti rispetto ai tradizionali test di integrazione. Il nuovo approccio non richiede la pianificazione delle catene di interazione da testare né la definizione e scrittura di script di test.
• Esecuzione diretta sul target, che consente di valutare l’interazione tra i moduli dell’applicativo in uno scenario operativo reale, includendo anche le interazioni con le librerie di sistema e il kernel. Le metriche ottenute riflettono quindi le porzioni di codice effettivamente stimolate durante l’utilizzo reale del prodotto.

I test eseguiti hanno avuto lo scopo di stimolare il sistema sia dal lato delle interfacce di comunicazione sia per la parte di calcolo della logica interna.

Rispetto all’applicativo originale, le statistiche ci hanno mostrato che la versione strumentata richiede dei tempi di elaborazione maggiori, soprattutto sulle parti stimolate. Tuttavia, questo carico maggiore non ha avuto degli effetti visibili nei tempi di comunicazione del sistema e non ha avuto impatti sulla stabilità dello stesso.

I dati di copertura raccolti sono stati riprocessati per estrarre delle metriche e generare diverse tipologie di report:

• Copertura delle singole istruzioni presenti nel codice
• Copertura dei controlli secondo il criterio del MC/DC
• Sintesi delle metriche di copertura a livello di funzione, modulo, progetto

In particolare, i report possono essere generati per tutto il progetto oppure per singoli moduli o gruppi di moduli.

In Figura 3, un estratto della sezione Metrics dedicata alla sintesi delle metriche di copertura rilevata a valle dell’esecuzione di un test.

CONCLUSIONI.

In conclusione, l’adozione di strumenti per la generazione e l’estrazione della Code Coverage direttamente su Target consente di accelerare notevolmente il processo di Verifica e Validazione. Questi strumenti rendono possibile includere la fase di integrazione software all’interno dei test funzionali eseguiti direttamente sull’hardware finale, fornendo metriche concrete su tutti i moduli dell’applicativo sotto test.

[1] sistema di sicurezza che controlla e coordina gli scambi e i segnali in una stazione o nodo ferroviario, per garantire che i treni possano muoversi senza rischi di collisioni o deviazioni errate