Unit Testing Embedded Software

Question

Quali best practice avete utilizzato nei software embedded di testing unitario che sono peculiari dei sistemi embedded?

Answer 1

software embedded possono aver fatto molta strada negli ultimi 10 anni, ma in genere ha fatto la seguente:

• per gli algoritmi che non dipendono dal hardware di destinazione, abbiamo semplicemente avuto unit test che sono stati costruiti e testato su una piattaforma non incorporata.
• per le cose che richiedevano l'hardware, i test di unità sono stati compilati nel codice per utilizzare qualsiasi hardware disponibile. Nel nostro caso, era una porta seriale sul bersaglio che spingeva i risultati su un'altra macchina, più capace, in cui i test venivano controllati per la correttezza.
• A seconda dell'hardware, a volte è possibile caricare un dispositivo "virtuale" su una piattaforma non incorporata. Questo di solito consisteva nell'avere un altro thread di esecuzione (o funzione di segnale) che modificava la memoria utilizzata dal programma. Utile per l'I/O mappato in memoria ma non per gli IRQ e così via.
• in genere, è possibile testare solo un piccolo sottoinsieme del codice completo alla volta (a causa di limiti di memoria).
• per testare le cose sensibili al tempo, non l'abbiamo fatto. Chiaro e semplice. L'hardware che abbiamo usato (8051 e 68302) non era sempre funzionale se funzionava troppo lentamente. Questo tipo di debug doveva essere fatto inizialmente con un CRO (oscilloscopio) e (quando avevamo un po 'più di soldi) un ICE (emulatore in-circuit).

Speriamo che la situazione sia migliorata dall'ultima volta che l'ho fatto. Non vorrei che il dolore sul mio peggior nemico.

Answer 2

Un sacco di processori integrati sono disponibili sulle schede di valutazione, quindi anche se non si dispone dei propri dispositivi di I/O, spesso è possibile eseguire una buona parte dei propri algoritmi e logica su uno di questi tipi di cose, spesso con debug hardware disponibile tramite jtag. E i test di "unità" di solito sono più sulla tua logica che sul tuo I/o comunque. Di solito, il problema riporta gli elementi del test fuori da di uno di questi ambienti.

Answer 3

I sistemi integrati sono un argomento ampio, ma in generale, pensiamo che sia un prodotto specifico che combina hardware e software. Il mio background embedded deriva dai telefoni cellulari, che è solo un piccolo sottoinsieme di tutti i sistemi embedded. Cercherò di mantenere un po 'i seguenti punti sul lato astratto:

• Estrarre dipendenze hardware quando possibile. In questo modo è possibile eseguire i test unitari su "hardware" deriso e testare anche vari casi rari/eccezionali che sarebbero più difficili da testare sul target. Per evitare costi di astrazione, puoi utilizzare per es. compilazione condizionale.

• Avere il minimo possibile dipende dall'hardware.

• I test di unità in esecuzione su un emulatore o su un ambiente con cross-compiler non garantiscono ancora che il codice funzioni sull'hardware di destinazione. Devi provare anche sull'obiettivo. Testare l'obiettivo il prima possibile.

Answer 4

Dividere il codice tra & indipendente dal dispositivo. Il codice indipendente può essere testato unitamente senza troppi problemi. Il codice dipendente dovrà semplicemente essere testato a mano fino a quando non avrai un'interfaccia di comunicazione fluida.

Se sei scrittura l'interfaccia di comunicazione, mi dispiace.

Answer 5

Non ci può essere un sacco da guadagnare unit testing in un ambiente PC (compilazione del codice con un compilatore PC C ed eseguire il codice in un quadro unit testing PC), con varie clausole:

1. Questo non si applica al test del codice di basso livello, incluso il codice di avvio, i test della RAM, i driver hardware. Dovrai utilizzare più unità di test diretto di quelli.
2. Il compilatore del sistema incorporato deve essere affidabile, quindi non stai cercando i bachi creati dal compilatore.
3. Il codice deve essere un'architettura a livelli, con l'astrazione dell'hardware. Potrebbe essere necessario scrivere simulatori di driver hardware per il framework di test dell'unità PC.
4. Si dovrebbe sempre utilizzare i stdint.h tipi come uint16_t piuttosto che semplice unsigned int ecc

Abbiamo seguito queste regole, e abbiamo scoperto che dopo Unit Testing il codice a livello di applicazione in un quadro di unit test PC, possiamo avere una buona dose di sicurezza sul fatto che funzioni bene.

vantaggi di unit testing su piattaforma PC:

1. non si faccia il problema di esaurire lo spazio ROM sul vostro piattaforma embedded a causa di aggiunta di un framework di unit testing.
2. Il ciclo di esecuzione del ciclo di compilazione è in genere più veloce e più semplice sulla piattaforma PC (ed evita il passaggio di "scrittura/download" che può potenzialmente richiedere diversi minuti).
3. Sono disponibili ulteriori opzioni per la visualizzazione del progresso (alcune applicazioni incorporate dispongono di periferiche I/O limitate), la memorizzazione dei dati di input/output per l'analisi e l'esecuzione di test più dispendiosi in termini di tempo.
4. È possibile utilizzare framework di test unità basati su PC prontamente disponibili che non sono disponibili/adatti per una piattaforma integrata.

Answer 6

Voce di inesperienza, ma questo è qualcosa a cui ho pensato anche ultimamente. Mi sembra che l'approccio migliore sia

A) Scrivere tanto codice di applicazione indipendente dall'hardware come è possibile in un ambiente PC, prima di scriverlo sul target e scrivere i test di unità al stesso tempo (farlo sul PC per primo dovrebbe aiutare a costringerti a separare le cose indipendenti dall'hardware). In questo modo è possibile utilizzare i tester dell'unità, quindi testare le cose dipendenti dall'hardware alla vecchia maniera - con RS-232 e/o oscilloscopi e pin I/O che segnalano i dati dipendenti dal tempo, a seconda della velocità con cui deve essere eseguito .

B) Scrivere tutto sull'hardware di destinazione, ma avere un obiettivo di compilazione condizionale di una build di test dell'unità che eseguirà i test unitari e produrrà i risultati (o dati che possono essere analizzati per i risultati) tramite RS-232 o altri mezzi. Se non hai molta memoria, questo può essere complicato.

Modifica 7/3/2009 Ho appena avuto un altro pensiero su come testare le cose dipendenti dall'hardware unitario.Se gli eventi hardware stanno accadendo troppo velocemente per registrare con RS-232, ma non vuoi setacciare manualmente tonnellate di dati dell'oscilloscopio per verificare se i tuoi flag di pin I/O salgono e scendono come previsto, puoi usare un PC scheda con DIO integrato (come la linea di schede di acquisizione dati di National Instruments) per valutare automaticamente i tempi di tali segnali. Dovresti quindi solo scrivere il software sul tuo PC per controllare la scheda di acquisizione dei dati per sincronizzarti con il test dell'unità attualmente in esecuzione.

Answer 7

c'è un sacco di buone risposte qui, alcune cose che non sono stati menzionati è quello di avere il codice di diagnostica in esecuzione al fine di:

eventi Log HAL (allarmi, messaggi di autobus, ecc)

dispone di codice per tenere traccia delle vostre risorse, (tutti i semafori attivi, l'attività filo)

hanno un meccanismo di acquisizione ariete per copiare il contenuto heap e la memoria di storage persistente (disco rigido o equivalente) per rilevare e deadlock di debug, livelocks, perdite di memoria , buffer overflow, ecc.

Answer 8

Si potrebbe voler controllare Test Driven Development for Embedded C di James W. Grenning. Il libro è programmato per essere pubblicato nell'agosto 2010, ma il libro beta è ora disponibile allo The Pragmatic Bookshelf.

Answer 9

Quando mi trovavo ad affrontare questo ultimo anno, volevo davvero testare la piattaforma integrata. Stavo sviluppando una libreria e stavo usando le chiamate RTOS e altre funzionalità della piattaforma integrata. Non c'era nulla di specifico disponibile, quindi ho adattato il codice UnitTest ++ ai miei scopi. Programma sulla famiglia NetBurner e, poiché dispone di un server Web incorporato, è stato abbastanza semplice scrivere un runner di test GUI basato sul Web che fornisse il classico feedback ROSSO/VERDE. È turned out pretty well, e ora il test delle unità è molto più semplice e mi sento molto più sicuro di sapere che il codice funziona sull'hardware reale. Uso anche il framework di test delle unità per eseguire test di integrazione. In un primo momento metto a punto/mozzo l'hardware e inietto quell'interfaccia per testare. Ma alla fine scrivo alcuni test "man-in-the-loop" che esercitano l'hardware vero e proprio. Risulta essere un modo molto più semplice per conoscere l'hardware e avere un modo semplice per recuperare da trappole incorporate. Poiché i test vengono eseguiti da callback AJAX al server Web, una trappola si verifica solo come risultato del richiamo manuale di un test e il sistema si riavvia sempre in modo pulito pochi secondi dopo il trap.

NetBurner è abbastanza veloce da consentire il ciclo di scrittura/compilazione/download/esecuzione di circa 30 secondi.

Answer 10

Siamo riusciti a ottenere un bel po 'di codice dipendente dall'hardware testato utilizzando un simulatore, usiamo il simulatore e l'IDE di Keil (non affiliati, basta usare i loro strumenti). Scriviamo gli script del simulatore per guidare l''hardware' in un modo che ci aspettiamo che risponda e siamo in grado di testare in modo affidabile il nostro codice funzionante. Certo, può richiedere un certo sforzo per modellare l'hardware per alcuni test, ma per la maggior parte delle cose funziona molto bene e ci consente di fare molto senza l'hardware disponibile. Siamo stati in grado di avvicinarci al sistema completo lavorando nel simulatore prima di avere accesso all'hardware e abbiamo avuto pochissimi problemi da affrontare una volta inserito il codice sulla cosa reale. Questo può anche velocizzare significativamente la produzione del codice, dal momento che tutto può essere fatto sul PC con il debugger più approfondito disponibile mentre si simula il chip contro il tentativo di fare tutto sull'hardware.

Sono riusciti a far funzionare in modo affidabile sistemi di controllo complessi, interfacce di memoria, circuiti integrati personalizzati SPI e persino un display mono.