Test automazione con hardware incorporato

Question

Qualcuno ha avuto successo nell'automazione dei test direttamente sull'hardware incorporato?

In particolare, sto pensando di automatizzare una batteria di test unitari per moduli di livello hardware. Dobbiamo avere maggiore fiducia nel nostro codice di livello hardware. Molti dei nostri progetti utilizzano timer a interruzione, ADC, serial io, dispositivi SPI seriali (memoria flash) ecc.

Ne vale davvero la pena?

In genere puntiamo a:

Processore: microcontrollori a 8 o 16 bit (alcuni componenti DSP)
Lingua: C (a volte c ++).

Answer 1

Certo. Nel settore automobilistico utilizziamo tester personalizzati da $ 100.000 per ogni nuovo prodotto per verificare che l'hardware e il software funzionino correttamente.

Gli sviluppatori, tuttavia, costruiscono anche un tester più economico (inferiore a $ 1.000) che include un sacco di I / O USB, A / D, ingresso / uscita PWM, ecc. e utilizza script sulla workstation o HIL / appositamente costruito Software di test SIL come MxVDev.

Il test HIL (Hardware in the Loop) è probabilmente quello che vuoi dire, e implica semplicemente alcuni I / O hardware USB collegati all'I / O del tuo dispositivo, con software sul computer che esegue test contro di esso.

Se ne vale la pena dipende.

Nel settore ad alta affidabilità (aereo, automobilistico, ecc.) il cliente specifica test hardware molto estesi, quindi è necessario averlo solo per ottenere l'offerta.

Nel settore dei consumi, con progetti non complessi di solito non ne vale la pena.

Con qualsiasi progetto in cui sono coinvolti più di alcuni programmatori, è davvero bello avere un test di regressione notturno eseguito sull'hardware - è difficile simulare correttamente l'hardware nella misura necessaria per accertati che il test del software sia sufficiente.

Il test quindi mostra immediatamente quando un problema è entrato nella build.

Generalmente esegui sia il test della scatola nera che quello della scatola bianca: hai un codice diagnostico in esecuzione sul dispositivo che ti consente di spiare segnali e memoria nell'hardware (che potrebbe essere solo un debugger o potrebbe essere un codice che hai scritto che reagisce ai messaggi su un bus, ad esempio). Si tratterebbe di test in white box in cui è possibile vedere cosa sta accadendo internamente (e persino causare alcune cose, come errori di memoria critici che non possono essere testati senza introdurre l'errore da soli).

Eseguiamo anche una serie di test "scatola nera" in cui il percorso diagnostico viene ignorato e viene stimolato / letto solo l'I / O.

Per una configurazione molto più economica, puoi ottenere schede per microcontrollori da $ 100 con USB e / o Ethernet (come la famiglia Atmel UC3) che puoi collegare al tuo dispositivo ed eseguire test di base.

È particolarmente utile per la manutenzione del prodotto: al termine del progetto, conservare alcuni tavoli da lavoro, il tester e un set completo di software su CD. Quando è necessario apportare una modifica o eseguire il debug di un problema, è facile ripristinarlo e lavorarci con alcune conoscenze (dopo il test) che le principali funzionalità non sono state influenzate dalle modifiche.

-Adam

Answer 2

Sì. Ho avuto successo, ma non è un problema complicato da risolvere. In breve, ecco cosa ha fatto la mia squadra:

1. È stata definita una varietà di test unitari usando un framework di test unitario C costruito in casa. Fondamentalmente, solo molte macro, la maggior parte delle quali sono state denominate TEST_EQUAL , TEST_BITSET , TEST_BITVLR , ecc.

2. Ha scritto un generatore di codice di avvio che ha eseguito questi test compilati e li ha orchestrati in un ambiente di esecuzione. È solo un piccolo driver che esegue la nostra normale routine di avvio, ma invece di entrare nel ciclo di controllo, esegue una suite di test. Al termine, memorizza l'ultima suite da eseguire nella memoria flash, quindi reimposta la CPU. Quindi verrà eseguita la suite successiva. Questo per fornire isolamento in caso di morte di una suite. (Tuttavia, potresti voler disabilitare questo per assicurarti che i tuoi moduli collaborino. Ma questo è un test di integrazione, non un test unitario.)

3. I singoli test registrerebbero il loro output usando la porta seriale. Questo era OK per il nostro design perché la porta seriale era libera. Dovrai trovare un modo per memorizzare i tuoi risultati se tutto il tuo IO viene consumato.

Ha funzionato! Ed è stato bello avere. Usando il nostro datalogger personalizzato, puoi premere il pulsante " Test " pulsante, e un paio di minuti dopo, avresti tutti i risultati. Lo consiglio vivamente.

Aggiornato per chiarire come funziona il driver di prova.

Answer 3

Sì.

La difficoltà dipende dal tipo di hardware che si sta tentando di testare. Come altri hanno già detto in precedenza, il problema sarà la complessità dello stimolo esterno che è necessario applicare. Lo stimolo esterno è probabilmente meglio ottenuto con alcuni banchi prova esterni (come ha descritto Adam Davis).

Una cosa da considerare, tuttavia, è esattamente ciò che stai cercando di verificare.

È allettante supporre che per verificare l'interazione tra hardware e firmware non si abbia davvero altra scelta che applicare direttamente lo stimolo esterno (cioè applicare i DAC a tutti gli input ADC, ecc.). In questi casi, tuttavia, i casi angolari che si desidera veramente testare saranno spesso soggetti a problemi di temporizzazione (ad es. Interruzioni in arrivo durante l'esecuzione della funzione foo ()) che saranno incredibilmente difficili da testare un modo significativo - e ancora più difficile ottenere risultati significativi. (vale a dire. Le prime 100.000 volte che abbiamo eseguito questo test è andato bene. L'ultima volta che l'abbiamo eseguito non è riuscito. Perché?!?)

Ma la verifica dell'hardware dovrebbe essere fatta separatamente. Una volta fatto questo, a meno che non cambi regolarmente (tramite immagini fpga scaricabili o simili), dovresti essere in grado di supporre che l'hardware funzioni e testare puramente il tuo firmware.

Quindi in questo caso puoi concentrarti sulla verifica degli algoritmi utilizzati per elaborare i tuoi stimoli esterni. Ad esempio, chiamando le routine di conversione ADC con un valore fisso come se provenissero direttamente dall'ADC. Questi test sono ripetibili e quindi di beneficio. Richiederanno comunque build di test speciali.

Testare i percorsi di comunicazione del tuo dispositivo sarà relativamente semplice e non dovrebbe richiedere build di codice speciali.

Answer 4

Abbiamo ottenuto buoni risultati con test automatizzati sui nostri sistemi embedded. Abbiamo test scritti in linguaggi di alto livello (facili da programmare e di debug) eseguiti su macchine di test dedicate. Questi test generalmente eseguono il controllo di integrità o generano input casuali nei dispositivi, quindi controllano il comportamento corretto. C'è molto lavoro da fare per generare e mantenere questi test. Abbiamo progettato un framework e quindi lasciato che gli stagisti lavorassero sui test stessi.

Non è una soluzione perfetta e i test sono sicuramente soggetti a errori, ma la parte più importante è migliorare i buchi di copertura esistenti. Trova il buco più grande e progetta qualcosa per coprirlo in modo automatizzato, anche se non è perfetto o non copre l'intera funzionalità. Più tardi, quando tutte le tue cose saranno coperte in qualche modo, puoi tornare indietro e affrontare la copertura peggiore o le funzionalità più importanti.

Alcune cose da considerare:

• Qual è la penalità di un bug del firmware? Quanto è più semplice aggiornare il firmware sul campo.
• Che tipo di copertura fornisce il mio test? È un semplice controllo di integrità? È abbastanza configurabile da poter testare molti scenari diversi?
• Una volta fallito un test, come si riprodurrà quel valore per eseguirne il debug? Hai registrato tutte le impostazioni del dispositivo e dei test in modo da poter eliminare quante più variabili possibile? Configurazione del dispositivo, versione del firmware, versione del software di prova, tutti gli ingressi esterni, tutti i comportamenti osservati?
• A cosa stai testando? Le specifiche sono abbastanza chiare su quale sia il comportamento previsto del dispositivo che stai testando o stai confermando ciò che pensi che il codice dovrebbe fare?

Answer 5

Se il tuo obiettivo è testare il tuo codice driver di basso livello, probabilmente dovrai creare una sorta di apparecchiatura di test, usando cavi di loopback o più unità interconnesse per permetterti di esercitare ciascun driver. L'associazione di una scheda con un software noto con una scheda che esegue una build di sviluppo consentirà di verificare le regressioni nei protocolli di comunicazione, ecc.

Strategie di test specifiche dipendono dall'hardware che si desidera testare. Ad esempio, gli ADC possono essere testati presentando una forma d'onda nota e convertendo una serie di campioni, quindi controllando l'intervallo, la frequenza, il valore medio, ecc. Corretti

Ho trovato questo tipo di test molto prezioso in passato, permettendomi di modificare con sicurezza e migliorare il codice del driver senza timore di interrompere le applicazioni esistenti.

Answer 6

Sì, lo faccio, anche se ho sempre avuto una porta seriale disponibile per l'I / O di prova.

Spesso è difficile lasciare l'unità totalmente non modificata. Alcuni test richiedono una linea commentata o una chiamata aggiunta, ad es. per gestire un cane da guardia.

IMHO, è meglio di nessun test unitario. E ovviamente devi anche eseguire test di integrazione / sistema completi.

Answer 7

L'unità di test dei progetti incorporati è piuttosto diffusa, in quanto richiede solitamente uno stimolo esterno e una misurazione esterna.

Siamo riusciti a sviluppare un protocollo seriale esterno (messaggi rs232 o udp o tcpip) con comandi di base per l'esercizio della hw con registrazione di debug nei driver di basso livello in cerca di condizioni errate o anche leggermente anormali (soprattutto per limite controllo)

Ma una volta sviluppato possiamo eseguire i test dopo ogni build, se necessario. Ti consentirà sicuramente di offrire un prodotto di qualità migliore.

Answer 8

So che ora è vecchio, ma forse sarà di aiuto. Sì, puoi farlo ma dipende da quanto vuoi investire nella soluzione che desideri. Più di due anni ho lavorato su test e validazione per il livello MCAL di AUTOSAR. Questo è il minimo che puoi ottenere quando si tratta di test del software. Era una sorta di test a livello di componente. Alcuni potrebbero chiamarlo a livello di unità, ma era leggermente superiore a quello perché stavamo testando le API dei componenti MCAL. Cose come: ADC, SPI, ICU, DIO e così via.

La soluzione utilizzata prevedeva: - un framework di test in esecuzione sul micro target - una scatola dSPACE per fornire e leggere segnali da e verso il bersaglio quando richiesto - Accesso XCP tramite Vector CANape per attivare l'esecuzione del test e la raccolta dei risultati - un framework Python per eseguire il controllo del test e la validazione dei risultati

I casi di test sono stati scritti in C e sono stati visualizzati sul target insieme al software in prova. È stato un test black box perché non abbiamo modificato in alcun modo l'implementazione dell'MCAL. E penso che nemmeno la sequenza di avvio sia stata toccata. Un'attività inattiva è stata utilizzata per controllare continuamente lo stato di un flag che era il segnale per iniziare l'esecuzione di un test. Un'attività di 10 ms è stata utilizzata per eseguire effettivamente il test. Un caso di prova era in realtà un caso di commutazione. Ogni caso in questo interruttore è stato un passaggio di prova. Python stava innescando l'esecuzione del test a livello di fase di test. Un aspetto positivo di questo approccio è stato il riutilizzo di passaggi con parametri diversi. Questo controllo del test, cosa eseguire e come, è stato eseguito da Python attraverso una struttura di dati di controllo del test che funge da API tra l'implementazione del test e il meccanismo di attivazione e valutazione del test. Questo è ciò per cui CANape è stato utilizzato. Per impostare il test da eseguire e leggere i risultati del test. Ogni valore ottenuto da una fase di test è stato memorizzato in una parte dell'array della struttura dei dati. Il passaggio del test stesso non è stato coinvolto in alcuna convalida perché il target è stato considerato un componente non attendibile dell'ambiente di test. La convalida è stata effettuata da Python in base alle specifiche del test. Python stava analizzando queste specifiche ed è stato in grado di creare automaticamente script di attivazione dei test, inclusi i criteri di convalida per ogni fase del test. La specifica di ogni caso di test era una serie di descrizioni delle fasi di test insieme ai loro criteri di validazione. Alcuni di questi passaggi erano passaggi correlati a dSPACE. Ad esempio, un passaggio stava inizializzando qualcosa e chiedeva che alcuni catturassero alcuni bordi su un canale già configurato, e il passo successivo era applicare il segnale su quel canale comandando l'apparecchiatura dSPACE.

Una soluzione più economica implicherebbe l'utilizzo di una scheda interna anziché delle apparecchiature dSPACE. In una certa misura, è possibile utilizzare anche un generatore di segnale programmabile, ma ciò non sarebbe utile se fosse necessario convalidare i segnali emessi dal target.

Answer 9

Se il tuo obiettivo è produrre test (assicurando che i moduli siano assemblati correttamente, senza cortocircuiti / aperture / ecc. involontari), dovresti prima concentrarti sul test di cavi e connettori, seguito da connessioni con presa e saldata, quindi dal PCB stesso. Tutti questi articoli possono essere testati per cortometraggi e amp; si apre trovando schemi di accesso che spingono in alto ogni singola linea mentre i suoi vicini sono bassi e viceversa, quindi rileggendo i valori delle linee.

Senza conoscere più dettagli dell'hardware è difficile essere più specifici, ma la maggior parte dei processori embedded può impostare i pin I / O su una modalità GPIO che semplifica questo tipo di test.

Se non esegui test sul letto di chiodi sui tuoi PCA, questi test dovrebbero essere considerati un primo passo obbligatorio per le schede di nuova fabbricazione.