Pianificazione e strategie di test
È possibile utilizzare Simulink® Test™ per testare funzionalmente modelli e codice. Prima di creare un test, considerare:
Identificazione degli obiettivi di test
Prima di creare il test, si consiglia di definire gli obiettivi. Gli obiettivi possono essere uno o più dei seguenti:
Test di simulazione
Nei casi in cui il test richiede solo che un modello venga simulato senza errori o per eseguire un test di regressione, è possibile eseguire un test di simulazione. I test di simulazione sono utili se il modello è ancora in fase di sviluppo oppure se si dispone di un modello di test esistente che contiene input e valutazioni e registra i dati rilevanti. Per un esempio, vedere Test a Simulation for Run-Time Errors.
Verifica dei requisiti
Se si dispone di Requirements Toolbox™, è possibile valutare se un modello si comporta in base ai requisiti collegando uno o più casi di test ai requisiti creati in Requirements Toolbox. È possibile verificare se il modello soddisfa i requisiti come segue:
Creando dichiarazioni verify o script di criteri personalizzati nel modello o nel test harness.
Includendo Model Verification Blocks nel modello o nel test harness.
Acquisendo l'output della simulazione nel caso di test e confrontandolo con i dati baseline.
Per un esempio che utilizza le dichiarazioni verify, vedere Test Downshift Points of a Transmission Controller.
Confronto dei dati
È possibile confrontare i risultati della simulazione con i dati baseline o con un'altra simulazione. È inoltre possibile confrontare i risultati tra diverse release di MATLAB®.
In un test baseline, si stabiliscono innanzitutto i dati baseline, ossia gli output previsti. È possibile definire manualmente i dati baseline, importarli da un file Excel® o MAT oppure acquisirli da una simulazione. Per maggiori informazioni, vedere Baseline Testing. Per confrontare i risultati dei test di più modelli, è possibile confrontare i risultati di ciascun test del modello con gli stessi dati baseline.
In un test di equivalenza, si confrontano due simulazioni per verificare se sono equivalenti. Ad esempio, è possibile confrontare i risultati di due risolutori o confrontare i risultati della simulazione in modalità normale con il codice generato in modalità Software-In-the-Loop (SIL), Processor-In-the-Loop (PIL) o Hardware-In-the-Loop (HIL). È possibile scoprire l'impatto di diversi valori dei parametri o insiemi di dati di calibrazione eseguendo test di equivalenza. Per un esempio di test di equivalenza, vedere Back-to-Back Equivalence Testing. Non è possibile confrontare più di due modelli in un singolo caso di test di equivalenza.
In un test su più release si eseguono test su più versioni di MATLAB installate. Utilizzare il test su più release per verificare che i test abbiano esito positivo e producano gli stessi risultati su versioni diverse.
Test SIL e PIL
È possibile verificare l'output del codice generato eseguendo simulazioni back-to-back in modalità normale e in modalità SIL o PIL. L'esecuzione di test back-to-back in modalità normale e in modalità SIL o PIL è una forma di test di equivalenza. Lo stesso test back-to-back può eseguire più scenari di test iterando su diversi vettori di test definiti in un file MAT o Excel. È possibile applicare tolleranze ai risultati per consentire differenze tecnicamente accettabili in termini di valore e tempistica tra il modello e il codice generato. Le tolleranze possono inoltre essere applicate al codice in esecuzione sull'hardware in tempo reale. Non è possibile utilizzare la modalità SIL o PIL nei modelli del sottosistema.
Test in tempo reale
Con Simulink Real-Time™, è possibile includere gli effetti di impianti fisici, segnali e hardware embedded eseguendo test in modalità HIL (Hardware-In-the-Loop) su un computer di destinazione in tempo reale. Eseguendo un test baseline in tempo reale, è possibile confrontare i risultati con dati noti e corretti. È inoltre possibile eseguire un test back-to-back tra un modello, SIL o PIL e una simulazione in tempo reale.
Coverage
Con Simulink Coverage™, è possibile acquisire dati di coverage utili a quantificare in che misura il modello o il codice è stato testato. Quando si imposta la raccolta di coverage per il file di test, i risultati del test includono la coverage del sistema sottoposto a test e, opzionalmente, i modelli di riferimento. È possibile specificare le metriche della coverage da restituire. La coverage è supportata per i blocchi Model Reference, i blocchi atomici Subsystem e i modelli ad alto livello se configurati per Software-In-the-Loop (SIL) o per Processor-In-the-Loop (PIL). La coverage non è supportata per i blocchi S-Function SIL o PIL.
Se i risultati mostrano una coverage incompleta, è possibile aumentarla:
Aggiungendo manualmente casi di test al file di test.
Generando casi di test con Simulink Design Verifier™ per aumentare la coverage.
In entrambi i casi, è possibile collegare i nuovi casi di test ai requisiti, come richiesto da alcune certificazioni.
Esecuzione del test su un modello completo o su componenti specifici
È possibile eseguire il test su un modello completo o su un componente del modello. Uno dei modi per eseguire i test consiste nel testare prima un componente singolo e poi aumentare il numero di componenti testati per eseguire test di integrazione e a livello di sistema. Utilizzando questo schema di test, è possibile identificare ed eseguire più facilmente il debug dei problemi relativi ai casi di test e alla progettazione del modello. Se si desidera ottenere una coverage aggregata, testare l'intero modello.
Utilizzo di un test harness
Un test harness contiene una copia del componente sottoposto a test o, per testare un intero modello, un riferimento al modello. L'harness contiene inoltre gli input e gli output utilizzati per i test. L'utilizzo di un test harness isola il modello o il componente sottoposto a test dal modello principale, mantenendo quest'ultimo pulito e ordinato.
È possibile salvare l'harness internamente con il file del modello o in un file esterno separato dal modello. Salvare l'harness internamente semplifica la condivisione del modello e dei test poiché sono presenti meno artefatti e consente di eseguire più facilmente il debug dei problemi di test. Salvare l'harness esternamente consente di riutilizzare e condividere solo l'harness, separando chiaramente il progetto dagli artefatti di test. Il test harness funziona allo stesso modo sia che sia interno sia che sia esterno al modello. Per maggiori informazioni sui test harness, vedere Test Harness and Model Relationship e Creazione di un test harness.
La figura mostra un esempio di test harness.
Il componente sottoposto al test è il blocco shift_logic, che viene copiato dal modello principale durante la creazione dell'harness. La copia del blocco shift_logic è collegata al modello principale. Gli input sono blocchi Inport e l'output è un blocco Outport. I sottosistemi verticali contengono blocchi di specificazione del segnale e di routing che collegano l'interfaccia del componente agli input e agli output.
Determinazione degli input e degli output
Considerare quali segnali di input e quali tolleranze di segnale utilizzare per testare il modello e da dove ottenerli. È possibile aggiungere un blocco Signal Editor al test harness per definire i segnali di input. In alternativa, è possibile definire e utilizzare gli input da un file Microsoft® Excel o MAT, oppure da un blocco Test Sequence. Se si dispone Simulink Design Verifier, è possibile generare gli input di test automaticamente.
Per l'output del test, considerare se si desidera salvare i dettagli del test e i dati dei risultati in un report per l'archiviazione o la distribuzione. È inoltre possibile utilizzare gli output come input per i blocchi Test Assessment per valutare e verificare i risultati del test. Per i test baseline, utilizzare gli output per confrontare i risultati effettivi con quelli previsti.
Ottimizzazione del tempo di esecuzione del test
I modi in cui è possibile ottimizzare il tempo di esecuzione del test includono l'utilizzo di iterazioni, test paralleli e l'esecuzione di un sottoinsieme di casi di test.
Quando si progetta il test, decidere se si desiderano più test o iterazioni dello stesso test. Un'iterazione è una variazione di un caso di test. Utilizzare le iterazioni per diversi insiemi di dati di input, insiemi di parametri, insiemi di configurazioni, scenari di test, dati baseline e modalità di simulazione nelle iterazioni. Uno dei vantaggi dell'utilizzo delle iterazioni è che è possibile eseguire i test utilizzando il riavvio rapido che evita di dover ricompilare il modello per ciascuna iterazione, riducendo così il tempo di simulazione.
Ad esempio, se sono disponibili più insiemi di dati di input, è possibile impostare un'iterazione del caso di test per ogni file di input esterno. Un altro modo per sovrascrivere i parametri è utilizzare le scansioni dei parametri con script, che consentono di iterare attraverso molti valori. Utilizzare casi di test separati se è necessario un controllo indipendente della configurazione o se ogni test è correlato a un requisito diverso. Per maggiori informazioni sulle iterazioni, vedere Test Iterations.
Se si dispone di Parallel Computing Toolbox™, è possibile eseguire test in parallelo sulla macchina locale o sul cluster. Se si dispone di MATLABParallel Server™, è possibile eseguire test in parallelo su un cluster remoto. L'esecuzione di test in parallelo è utile quando si dispone di un numero elevato di casi di test o di casi di test che richiedono molto tempo per essere eseguiti. Vedere Run Tests Using Parallel Execution.
Un altro modo per ottimizzare i tempi di test è eseguire un sottoinsieme di casi di test contrassegnando i test da eseguire.
Per maggiori informazioni sul miglioramento e l'ottimizzazione della simulazione dei modelli, vedere la sezione Optimize Performance (Ottimizzazione delle prestazioni), in Simulation (Simulazione) nella documentazione di Simulink.
Utilizzo dell'interfaccia programmatica o dell'interfaccia grafica utente
Per creare ed eseguire test, Simulink Test fornisce Test Manager, uno strumento interattivo e comandi e funzioni API che è possibile utilizzare negli script di test e nella riga di comando. Con Test Manager è possibile gestire numerosi test e acquisire e gestire i risultati in modo sistematico. Se è necessario definire nuove valutazioni dei test, utilizzare Test Manager poiché questa funzionalità non è disponibile nell'API. Se si lavora in un ambiente di integrazione continua, utilizzare l'API. In caso contrario, è possibile utilizzare l'opzione preferita.
