Cos'è il test incorporato nel test del software?
Team editoriale
⚡ Riepilogo intelligente
Il testing embedded verifica congiuntamente il comportamento funzionale e non funzionale del software e dell'hardware, poiché in un sistema embedded i due elementi sono strettamente interconnessi e nessuno dei due può essere validato correttamente singolarmente.
Cosa sono i sistemi Embedded?
Sistemi integrati I sistemi embedded sono dispositivi controllati elettronicamente in cui software e hardware sono strettamente interconnessi. Possono contenere una varietà di dispositivi di elaborazione. Si tratta di PC integrati in altri dispositivi per svolgere funzioni specifiche di un'applicazione. L'utente finale di solito non è nemmeno consapevole della loro esistenza.
Test integrati
Test integrato è un processo di test per verificare la funzionalità e non funzionale attributi sia del software che dell'hardware in un sistema embedded e garantire che il prodotto finale sia privo di difetti. Lo scopo principale del testing embedded è verificare e convalidare se il prodotto finale, costituito da hardware e software embedded, soddisfa o meno i requisiti del cliente.
Il collaudo del software embedded verifica e garantisce che il software in questione sia di buona qualità e conforme a tutti i requisiti. Il collaudo del software embedded è un approccio eccellente per garantire la sicurezza in applicazioni critiche come apparecchiature mediche, ferrovie, aviazione, industria automobilistica, ecc. Test rigorosi e accurati sono fondamentali per ottenere la certificazione del software.
Come eseguire il test del software incorporato
In generale, esegui il test per quattro motivi:
- Per trovare bug nel software
- Aiuta a ridurre i rischi sia per gli utenti che per l'azienda
- Ridurre i costi di sviluppo e manutenzione
- Per migliorare le prestazioni
Nei test su sistemi embedded, vengono eseguite le seguenti attività:
- Il software viene fornito con alcuni input.
- Viene eseguita una parte del software.
- Lo stato del software viene monitorato e gli output vengono controllati per verificarne le proprietà attese, come ad esempio la corrispondenza tra l'output e il risultato previsto, la conformità ai requisiti e l'assenza di arresti anomali del sistema.
Tipi di test del software incorporato
Fondamentalmente, esistono cinque livelli di test applicabili al software embedded.
Test di unità software
Il modulo unitario è una funzione o una classe. Il test unitario viene eseguito dal team di sviluppo, principalmente dallo sviluppatore, e di solito si svolge secondo un modello di peer-review. I casi di test vengono sviluppati in base alle specifiche del modulo.
Test d'integrazione
Test d'integrazione può essere classificato in due segmenti:
- Test di integrazione del software
- Test di integrazione software/hardware
Infine, viene testata l'interazione tra il dominio hardware e i componenti software. Ciò può includere l'esame dell'interazione tra i dispositivi periferici integrati e il software.
Lo sviluppo di software embedded presenta una caratteristica peculiare: l'ambiente effettivo in cui il software viene eseguito viene generalmente creato in parallelo con il software stesso. Ciò comporta degli inconvenienti per la fase di test, poiché non è possibile effettuare test completi in un ambiente simulato.
Test delle unità di sistema
Ora il modulo da testare è un framework completo che consiste nel codice software completo più tutto sistema operativo in tempo reale (RTOS) e componenti correlati alla piattaforma come interruzioni, meccanismi di gestione dei task, comunicazioni e così via. Il protocollo Point of Control non è più una chiamata a una funzione o un'invocazione di metodo, bensì un messaggio inviato o ricevuto tramite le code di messaggi dell'RTOS.
Le risorse di sistema vengono osservate per valutare la capacità del sistema di supportare l'esecuzione del sistema incorporato. Per questo aspetto, test a scatola grigia è il metodo di test preferito. A seconda dell'organizzazione, il test unitario del sistema è compito dello sviluppatore o di un team dedicato all'integrazione del sistema.
Test di integrazione del sistema
Il modulo da testare parte da un insieme di componenti all'interno di un singolo nodo. I Punti di Controllo e Osservazione (PCO) sono un mix di protocolli di comunicazione di rete ed eventi RTOS, come i messaggi di rete. Oltre a un componente, un Virtual Tester può anche svolgere il ruolo di nodo.
Test di convalida del sistema
Il modulo da testare è un sottosistema con un'implementazione completa, oppure l'intero sistema embedded. L'obiettivo di questo test finale è soddisfare i requisiti funzionali di un'entità esterna. Si noti che un'entità esterna può essere una persona, un dispositivo in una rete di telecomunicazioni o entrambi.
Differenza: test integrati e test del software
La tabella seguente mette a confronto i test integrati con quelli convenzionali test del software.
| Software Testing | Test integrati |
|---|---|
| Il test del software è relativo solo al software. | I test integrati riguardano sia il software che l'hardware. |
| In media, il 90% dei test effettuati nel mondo è puramente manuale. test della scatola nera. | Il test integrato viene eseguito su sistemi o chip integrati e può essere a scatola nera o test della scatola bianca. |
| Le aree principali di test sono i controlli della GUI, la funzionalità, la convalida e un certo livello di test del database. | Le principali aree di test riguardano il comportamento dell'hardware in relazione al numero di input che gli vengono forniti. |
| I test del software vengono eseguiti principalmente su applicazioni client-server, Web e mobili. | I test sui sistemi embedded vengono generalmente eseguiti sull'hardware. |
| per esempio, Google Mail, Yahoo Mail, Android applicazioni. | Ad esempio, macchinari del settore sanitario, microcontrollori utilizzati nei computer. |
Sfide: test del software incorporato
Alcune delle sfide che si possono incontrare durante il test del software embedded:
Dipendenza hardware
La dipendenza dall'hardware è una delle principali difficoltà riscontrate durante il test del software embedded, a causa dell'accesso limitato all'hardware stesso. Tuttavia, emulatori e simulatori potrebbero non rappresentare con precisione il comportamento del dispositivo reale e potrebbero fornire un'impressione errata delle prestazioni del sistema e dell'usabilità dell'applicazione.
Software Open Source
La maggior parte dei componenti software embedded è di natura open source, non è sviluppata internamente e non dispone di una suite di test completa. Esiste un'ampia gamma di combinazioni di test e relativi scenari.
Difetti software e hardware
Un altro aspetto riguarda lo sviluppo di software per hardware di nuova creazione. Durante questo processo, si può riscontrare un'elevata percentuale di difetti hardware. I difetti rilevati non si limitano al software, ma possono essere correlati anche all'hardware.
Difetti riproducibili
Nel caso di un sistema embedded, i difetti sono più difficili da riprodurre o ricreare. Ciò obbliga la procedura di test dei sistemi embedded ad attribuire un valore significativamente maggiore a ogni occorrenza di difetto rispetto a un caso standard, e a raccogliere quanti più dati possibile per individuare la causa principale del difetto.
Aggiornamenti software continui
I sistemi embedded richiedono aggiornamenti software regolari, come aggiornamenti del kernel, correzioni di sicurezza, driver di dispositivo diversi, ecc. I vincoli associati agli aggiornamenti software rendono difficile l'identificazione dei bug. Inoltre, ciò aumenta l'importanza della procedura di compilazione e distribuzione.
