Analisi della copertura del codice per progetti Embedded C ++ [chiuso]

Question

Di recente ho iniziato a lavorare su un progetto C ++ molto ampio che, dopo aver completato il 90% dell'implementazione, ha stabilito che devono dimostrare una copertura del ramo del 100% durante i test. Il progetto è ospitato su una piattaforma integrata (Green Hills Integrity). Sto cercando suggerimenti ed esperienze da altri su StackOverflow che hanno utilizzato prodotti di copertura del codice in ambienti simili. Sono interessato a commenti sia positivi che negativi su questi tipi di strumenti.

Answer 1

Copertura delle filiali al 100%? Questo è piuttosto un requisito, soprattutto perché alcuni rami (valori predefiniti nelle istruzioni case per le macchine a stati, per esempio) non dovrebbero essere possibili. Mi aspetto che ci siano alcune eccezioni e, in caso contrario, potresti aver bisogno di capire cosa possono e non possono essere eseguiti i test di copertura prima di iniziare - altrimenti finirai per strapparti i capelli, o peggio - fornendo dati errati.

La maggior parte dei test di copertura per sistemi embedded viene effettivamente eseguita su PC. Il codice viene trasferito, alcuni aspetti del microcontrollore vengono emulati nel software e Bullseye o un'altra copertura simile del codice PC l'utilità è in esecuzione. Il motivo è che ci sono troppi microcontrollori e compilatori / debugger / ambienti di test per sviluppare strumenti di copertura del codice per ognuno di essi.

Quando esistono strumenti di copertura del codice per una piattaforma integrata specifica, non sono così potenti, configurabili, facili da usare e privi di bug come quelli sviluppati per la piattaforma PC. I processori non hanno spesso la capacità di traccia (senza hardware di emulazione di fascia alta) necessaria per eseguire una buona copertura del codice senza inserire codice di debug aggiuntivo nel firmware, che ha quindi conseguenze ed effetti collaterali difficili da controllare, soprattutto con problemi di temporizzazione in sistemi in tempo reale.

Il porting del codice non è tremendamente difficile fintanto che puoi astrarre il codice specifico dell'hardware (e dal momento che stai usando C ++ correttamente, dovrebbe essere facile, giusto? ;-D). Il problema più grande che incontrerai sono i tipi che, sebbene meglio specificati in C ++ rispetto a quelli in C, presentano ancora alcuni problemi. Assicurati di utilizzare un'impostazione di tipo.h o simile per dire in modo specifico al compilatore esattamente quale tipo di utilizzo usi e come dovrebbe essere interpretato.

Dopodiché, puoi andare in città testando la logica principale sul PC. Puoi anche testare i driver hardware di basso livello se sei interessato a sviluppare l'emulazione software richiesta per questo, anche se i problemi di temporizzazione possono essere un po 'problematici.

Gli strumenti di test del software come MxVDev eseguono gran parte dell'emulazione del microcontrollore e aiutano a risolvere i problemi di temporizzazione come bene, ma avrai ancora un po 'di lavoro anche con un tale aiuto.

Se devi farlo sul sistema stesso, dovrai acquistare un emulatore per il processore con capacità di copertura - non una proposta economica (molti emulatori costano fino a $ 30k per l'intero set di strumenti e hardware di emulazione) , ma è uno dei molti strumenti utilizzati in ambienti ad alta affidabilità come l'industria automobilistica e aerospaziale.

-Adam

Disclaimer: lavoro per l'azienda che produce MxVDev.

Answer 2

Abbiamo usato Cantata e vectorcast in passato per test unitari e copertura del codice. Utilizziamo anche gli strumenti di Greenhills ed entrambi funzionano con gli strumenti di sviluppo di Greenhills. Eseguiamo la maggior parte dei nostri test sul simulatore PPC ed eseguiamo test che si basano su hardware sull'hardware Target tramite un pod JTAG. Canatata e il cast Vector sono molto simili con catata, leggermente più facili da usare e hanno un po 'più di funzionalità, ma i piccoli extra fanno una grande differenza nell'esperienza utente.

In genere, se si desidera ottenere un livello elevato di copertura delle filiali, è necessario progettare il codice per verificabilità. Più testerai e più impari a scrivere codice testabile.

Abbiamo anche provato i test del PC rispetto ai test integrati che ci hanno dato problemi a causa dell'endianità, ma questo è solo un problema a livello hardware.

Inoltre, questi strumenti sono certificati secondo lo standard RTCA / DO-178B.

Answer 3

Come per Adam, portiamo il nostro codice incorporato su un cablaggio basato su PC e facciamo la maggior parte della copertura e della profilazione lì. Ho usato AutomatedQA AQTime e Compuwares DevPartner, entrambi buoni prodotti,

Se dovessi fare un ob-board di copertura, dovrai utilizzare un profiler di copertura che ha creato una versione strumentata della fonte. Ci sono strumenti sia commerciali che open source disponibili per fare questo, ma IMO aggiunge molto lavoro senza molto guadagno.

La copertura del 100% è ambiziosa, poiché avrai bisogno di molta iniezione di errori per accedere a tutti i gestori di errori e gestori di eccezioni. IMO, questo sarebbe anche più facile da fare in un cablaggio che a bordo.

Vale anche la pena sottolineare a chiunque abbia chiesto una copertura del codice al 100% che il copertura del codice al 100% non equivale in alcun modo alla copertura del test al 100% . Consideriamo ad esempio la seguente funzione;

int div(int a, int b)
{
return (a/b);
}

La copertura del codice al 100% richiede di chiamare questa funzione una sola volta, la copertura del test al 100% richiederebbe molte più chiamate. La mia strategia di test prevede lo sviluppo di testcase automatizzati per darmi un livello accettabile di copertura test e l'utilizzo di uno strumento di copertura del codice puramente come ausilio per la ricerca di aree non testate. In una certa misura dipende dal budget del test; per me la copertura del codice al 100% è troppo costosa per ciò che offre.

Answer 4

Vedi Copertura test SD C ++ . Questa è una famiglia di strumenti di copertura dei test (di succursale) per una varietà di dialetti di C ++ (ANSI, GNU, MS ...) che funziona bene anche nell'hardware dei sistemi embedded effettivi in ??virtù di un ingombro molto ridotto e di una facilità modo di esportare i dati raccolti sulla copertura dei test. C'è una visualizzazione della copertura della GUI che non dipende dall'hardware reale incorporato, che produrrà anche un riepilogo completo del rapporto di copertura.

[Sono un preside dell'azienda che fornisce questi strumenti.]