Introduzione

In generale il test del software è un argomento molto vasto, descritto ampiamente in numerosi libri tecnici. L’obiettivo di questi appunti non è di effettuare una descrizione accademica di tutta la teoria che sta dietro il testing, la cui applicazione nel mondo reale comporterebbe un dispendio di risorse non indifferente, ma di fornire un criterio per effettuare una particolare tipologia di test (per microcontrollori PIC) derivante principalmente dall’esperienza pratica e che sia un buon compromesso tra l’effort speso e il risultato ottenuto.
A differenza della progettazione del software (che in genere è un’attività stimolante), l’attività di test è ritenuta frustrante, noiosa e conflittuale con il team di sviluppo. In effetti non è proprio un’attività creativa (intesa come progettazione), ma comunque è molto importante dal momento che fornisce un valore aggiunto al prodotto finale non trascurabile.

In genere è il cliente oppure la particolare tipologia di progetto ad imporre una serie di vincoli tra cui anche la granulosità e qualità dei test da effettuarsi sul software.
Nel caso in cui il programma è composto da un numero ridotto di istruzioni e non effettua particolari elaborazioni (eventi simultanei, algoritmi complicati, presenza di rete ecc.), l’attività di test risulta notevolmente semplificata e ridotta. Comunque c’è da dire che i criteri da adottare per la realizzazione ed esecuzione dei test di software di una certa importanza comporta un effort che richiede una buona creatività e molta competenza.
Di seguito si focalizzerà sui test per microcontrollori PIC anche se i concetti descritti, con le dovute modifiche, si possono estendere al software in generale. È opportuno ribadire che l’approccio utilizzato è pragmatico e riguarda una particolare tipologia di test senza essere esaustivo e senza analizzare sofisticate tipologie di configurazioni. Infatti l’ambiente di esecuzione prevede l’uso di simulatori/stimolatori software forniti a corredo dell’ambiente di sviluppo. Non si farà cenno ai programmatori e debugger hardware (MPLAB ICD X, MPLAB ICE X) anche se la maggior parte delle operazioni è la stessa e quindi si ha la possibilità di passare da un simulatore software ad un debugger hardware per testare il codice senza grandi sforzi.

Test Funzionali

In sintesi il test funzionale del software è una serie di operazioni effettuate allo scopo di verificare il rispetto dei requisiti che deve avere il prodotto software finale. In tal caso il sistema viene modellato come una black box, quindi trattabile come input ed output.

Schema Black Box

Non si discuteranno criteri di copertura dei requisiti in funzione dei test, test che mirano a controllare la completa copertura dei rami oppure la decomposizione dei requisiti in specifiche di dettaglio né la progettazione dei test. Ciononostante, l’approccio seguito non utilizzerà la definizione puntuale di test funzionale in cui il sistema è visto come una black box ed il tester come un semplice esecutore fornendo l’input ed analizzando l’output.
Un approccio che si è rilevato utile e conveniente è quello di avere un tester con maggiori competenze sul sistema e sugli algoritmi utilizzati e di utilizzare anche il debugger per analizzare quelle parti di codice particolarmente critiche o sospette. Ovviamente questo anche in funzione degli obiettivi che si vogliono raggiungere e dell’importanza che ha il sistema nel suo complesso.
Comunque per l’attività di test il punto di partenza sono i requisiti del software. Questi si dividono in:

• Requisiti funzionali. Descrivono il comportamento del software sia in termini di input, sia di output e sia elaborativi. Esempio “L’input è costituito da valori esadecimali”, “Il tasto deve essere premuto per un tempo pari a 3 secondi”, “Al verificarsi dell’evento E1, il sistema deve abilitare il pin 5 dopo 1200 ms” ecc.
• Requisiti non funzionali. Definiscono proprietà o caratteristiche del software. Esempio tempi di risposta, applicazione di standard per la codifica, affidabilità, linguaggio di programmazione da utilizzare, documentazione a corredo, sistemi operativi, quantità di RAM ecc.
  

Entrambi i requisiti, in genere, vengono descritti in un apposito documento Word. Si utilizza l’UML per una rappresentazione grafica del comportamento del sistema software ed una parte formalizzata secondo uno standard per la puntualizzazione e numerazione dei requisiti.
A partire dai requisiti formalizzati bisogna costruire i test funzionali. Questi si dividono in test che verificano il comportamento del sistema software in funzione dei requisiti e test di robustezza che consentono di avere un sistema che si comporta correttamente in funzione di input non corretti. In formato grafico:

Requisiti Funzionali

Bisogna tenere presente che è altamente probabile che da un requisito, specie quello funzionale, possono scaturire più test. Per la progettazione dei test associati al requisito è sufficiente studiare attentamente il requisito stesso. Dal requisito si ricavano gli input da fornire e gli output attesi. Per il test di robustezza bisogna individuare il negato dell’input e utilizzare quell’insieme minimo sufficiente a verificare il corretto funzionamento del software (altrimenti si ha un’esplosione di test). Nel caso di più input bisogna porre attenzione ai casi di concomitanza degli stessi in termini di valore e di tempi di arrivo.
In generale un test è composto da:

• Una scheda di test. È un documento Word composta da varie sezioni. Una descrive cosa ci si propone di fare con l’esecuzione del test. È una parte descrittiva del test. Un’altra descrive l’input da fornire al software. Per tale sezione è conveniente utilizzare un formato tabellare in cui si evidenzia se l’input è imposto oppure no. Un’altra descrive l’output. Anche per tale sezione è conveniente utilizzare un formato tabellare in cui si evidenzia l’output ottenuto e quello atteso. Una sezione in cui si descrive l’ambiente di esecuzione del test. Infine una sezione in cui si descrive eventuali configurazioni/impostazioni dell’ambiente necessari all’esecuzione del test.
• Una directory associata al test (opzionale). Tale directory contiene eventuali file di input, di output e di supporto necessari all’esecuzione del test.
• File/Applicativi (opzionale) per automatizzare, se possibile, l’esecuzione dei test. In generale quando si modificano i requisiti oppure si risolvono un certo numero di malfunzionamenti, è preferibile rieseguire tutti i test in modo da accertarsi che non vi siano effetti collaterali legati alle modifiche del codice.
• Documento in cui si evidenzia l’esito di tutti i test (può essere anche un semplice file xls). Nel caso in cui il test non è superato oppure presenta un risultato non previsto, bisogna comunicarlo al team di sviluppo per la correzione. Per la comunicazione di un malfunzionamento è preferibile utilizzare una scheda contenente almeno la descrizione del problema riscontrato ed associargli la directory associata al test fallito per agevolare la risoluzione della stessa.

Quanto descritto è un esempio abbastanza semplificato per la progettazione e gestione dei test. L’importante è avere ben chiaro che dai requisiti si estraggono i test che ci consentono di verificare il corretto comportamento e la robustezza del sistema software e che tali test vengano formalizzati e scritti in un opportuno documento.

Test Funzionali per microcontrollori PIC

Come già detto si prenderà in considerazione i test funzionali relativi ad un software generico eseguito su un microcontrollore della Microchip escludendo:

• Un ambiente di esecuzione multithread.
• Un ambiente distribuito.
• Librerie compilate in codice oggetto.

Questi contesti sono abbastanza articolati e non fanno parte di questi appunti. L’obiettivo è quello di avere un criterio rigoroso per effettuare dei test sul software da caricare in un microcontrollore PIC che sia economico ma che allo stesso tempo consente di avere una buona fiducia sul comportamento in campo del sistema realizzato.
In realtà per verificare il buon funzionamento di un programma è possibile utilizzare una scheda hardware con una serie di periferiche predisposte ad hoc. In effetti a prima vista può sembrare una soluzione semplice ed efficace, ma, se il programma è un pò articolato e bisogna verificare il buon funzionamento anche a fronte di input non previsti (es. sovrapposizione di due segnali su pin diversi, sincronismo temporale tra tre input anomalo, simultaneità tra il timer interno ed un segnale esterno, sequenza di comandi non corretta ecc.) risulta evidente che è estremamente difficile riprodurre tali condizioni. Anche l’esecuzione dei test sul campo (nella situazione reale di funzionamento) non sempre è agevole oppure fattibile. Spesso è proprio la creazione degli input associati ai test (in particolar modo quelli di robustezza) che risultano difficili da realizzare a meno che non si usino componenti o strumenti appositi (in genere costosi).
In tali condizioni è conveniente fare uso di simulatori software in modo da agevolare l’esecuzione dei test ed in particolare modo la riesecuzione degli stessi a seguito dei cambiamento dei requisiti. Nell’ambiente integrato MPLAB esiste per l’appunto un simulatore software dei microcontrollori ed un sistema di gestione di stimoli che consentono di effettuare svariati test.
E’ evidente che utilizzando il tool che mette a disposizione l’ambiente integrato si fanno le seguenti ipotesi:

• Il simulatore software del microcontrollore oggetto di test funziona correttamente, in pratica non ha bug.
• Il codice oggetto generato a partire da quello sorgente( linguaggio C ) a seguito della compilazione in Debug e comprensivo di eventuali modifiche, non subisce alterazioni significative oppure le si possono ritenere trascurabili ai nostri fini rispetto alla compilazione in Release.
• Il sottosistema per la gestione degli stimoli si comporta esattamente secondo quanto richiesto dalle nostre impostazioni.

In pratica il sistema a cui si farà riferimento per la progettazione ed esecuzione dei test può essere schematizzato nel seguente modo:

Ambiente Test

Di seguito una descrizione sommaria dei vari blocchi:

• Segnali Input. Rappresentano i vari input al microcontrollore. Nella realtà questi possono essere generati da varie fonti per esempio pulsanti, interruttori, ricevitori ad infrarossi/ultrasuoni, segnali analogici, forme d’onda oppure provenire da altri sottosistemi ed avere caratteristiche sincrone ed asincrone. Nel nostro sistema saranno simulati dagli stimoli sincroni ed asincroni opportunamente configurati e da file contenenti valori numerici.
• Simulatore MPLAB Sim. In tale blocco sono presenti sia il simulatore del microcontrollore con relativa esecuzione del software e sia la gestione degli stimoli. L’ambiente ci consentirà di monitorare tutte le variabili ed i registri di interesse e quindi capire l’evoluzione del sistema. In teoria il tester non dovrebbe entrare nel merito dell’evoluzione del sistema, bensì dovrebbe concentrare la sua attenzione sull’input e sull’output. In pratica è preferibile che abbia conoscenze sugli algoritmi di elaborazione e capire, in caso di malfunzionamento, dove è localizzato il problema. A fronte di un piccolo effort si ottengono discreti risultati. Come effetto collaterale bisogna gestire eventuali attriti e permalosità che possono crearsi tra il tester ed il desiger/developer.
• Segnali Output. Rappresenta l’output del microcontrollore al termine del test. Questi possono essere sia dei diagrammi temporali che il valore assunto da determinate variabili.
• Trace. E’ un file contenente l’evoluzione delle variabili/registri/CPU/input/output durante l’esecuzione del test. Spesse volte vengono anche monitorate le istruzioni eseguite. Diventa un elemento importante nell’individuare le cause che hanno portato il sistema in uno stato non corretto. In genere, tranne che per casi semplici, l’analisi delle variabili viene effettuata tramite tool esterni e realizzati a tale scopo.
  

Per effettuare dei test performanti volti ad ottenere un buon compromesso tra effort speso e qualità del software prodotto, bisogna giungere ad un compromesso in cui il tester deve avere delle competenze sul sistema e sugli algoritmi realizzati dal team di sviluppo. Inoltre deve essere, per potere fornire indicazioni su dove è localizzato il malfunzionamento ed avere piena padronanza dell’evoluzione del software, in grado di utilizzare il debugger e gli ulteriori tool messi a disposizione dell’ambiente integrato.
In questo caso non si può proprio parlare, come detto, di test funzionale del tipo black box in senso accademico, ma comunque se ben gestito il processo di testing così come impostato fornisce un risultato soddisfacente in funzione dell’effort speso senza entrare in metodologie di test del tipo white box le quali notoriamente sono estremamente costose in termini di risorse. Si ribadisce che l’effort da utilizzare è legato fortemente agli obiettivi che si vogliono raggiungere ed all’importanza del sistema completo. Per esempio nel caso in cui un malfunzionamento provocasse la perdita di vite umane o forti perdite economiche (sistemi per aerei, navi, apparecchi elettromedicali ecc) è conveniente investire sui test (anche in funzione dell’assessment da parte di un ente di certificazione). Se il malfunzionamento non provoca effetti economici rilevanti (controllo della temperatura di un forno, misurazione della potenza trasmessa, controllo del movimento di un giocattolo ecc.) è accettabile un insieme di test più economici ad esempio solo quelli black box senza utilizzare il debugger per verificare lo stato dei registri/CPU/variabili/input/output e le funzioni più sensibili alle anomalie.
Di seguito dettaglierò principalmente la realizzazione dell’ambiente di esecuzione dei test. In particolare su come realizzare gli input desiderati (sia quelli attesi che quelli anomali) utilizzando gli strumenti messi a disposizione dall’ambiente integrato, sul come ottenere, se possibile, il trace delle variabili di interesse ed infine sull’output. Il primo elemento da trattare con particolare attenzione è l’utilizzo del debugger, almeno le funzionalità fondamentali, in modo da potere effettuare un’analisi particolareggiata dell’evoluzione del codice di interesse.