Questa pagina è stata tradotta automaticamente.
Completa un sondaggio di 1 minuto sulla qualità di questa traduzione.
Integrazione continua per la verifica dei modelli Simulink
David Boissy, Paul Urban, Krishna Balasubramanian, Pablo Romero Cumbreras, Colin Branch e Jemima Pulipati, MathWorks
Se utilizzi R2022a o una versione successiva e disponi di una licenza Simulink Check™, puoi semplificare l'integrazione CI utilizzando il pacchetto di supporto CI/CD Automation for Simulink Check. Con il pacchetto di supporto puoi definire un modello di processo per il tuo team e configurare il tuo sistema CI per eseguire automaticamente le attività nel tuo processo come una pipeline in CI. Il pacchetto di supporto include il supporto per diverse piattaforme CI, in modo da poter generare automaticamente pipeline specifiche per il tuo progetto e processo, eliminando la necessità di aggiornamenti manuali.
Caratteristiche principali:
- Attività integrate: Automatizza le attività comuni nel tuo workflow di sviluppo e verifica Model-Based utilizzando attività integrate per attività quali il controllo degli standard di modellazione con Model Advisor, l'esecuzione di test con Simulink Test™ e la generazione di codice con Embedded Coder®. Invece di gestire vari script per le attività di sviluppo e verifica, puoi riconfigurare e utilizzare queste attività integrate per un'esecuzione coerente e risultati organizzati.
- Build incrementali: Identifica l'impatto di una modifica sul tuo progetto e riesegui automaticamente solo le attività interessate per migliorare l'efficienza della build. L'app Process Advisor e il suo sistema di compilazione possono rieseguire attività con risultati obsoleti e saltare automaticamente le attività aggiornate.
- Generazione automatica della pipeline: Utilizza il file modello del pacchetto di supporto per generare automaticamente pipeline, in modo da non dover aggiornare manualmente i file di configurazione CI/CD quando si apportano modifiche al progetto o al processo. È possibile personalizzare facilmente le impostazioni del generatore di pipeline per separare le attività in lavori diversi, eseguire attività modello in parallelo e modificare altri comportamenti della pipeline.
Per ulteriori informazioni, vedere Continuous Integration e Integrate into Jenkins.
Questo è il primo articolo di una serie in due parti. La parte 1 esamina come sfruttare GitLab® per il controllo delle versioni e Jenkins® per l'integrazione continua (CI). Parte 2, Continuous Integration for Verification of Simulink Models Using GitLab, esamina l'utilizzo di GitLab sia per il controllo delle versioni che per la CI.
L'integrazione continua (CI) sta guadagnando popolarità e sta diventando parte integrante della progettazione Model-Based. Ma cos'è la CI? Quali sono i suoi vantaggi e quali problemi cerca di risolvere? Come Simulink® si adatta all'ecosistema CI? E come puoi sfruttare al meglio la CI per i tuoi progetti?
Se hai familiarità con la progettazione Model-Based ma sei nuovo alla CI, potresti porti queste domande. In questo articolo tecnico esploreremo un workflow CI comune e lo applicheremo alla progettazione Model-Based. Successivamente, esamineremo un esempio di tale workflow utilizzando Jenkins, GitLab e Simulink Test.
Il progetto utilizzato in questo esempio è disponibile per il download.
Che cosa è CI?
CI è una best practice della metodologia agile in cui gli sviluppatori inviano e uniscono regolarmente le modifiche al codice sorgente in un repository centrale. Questi “set di modifiche” vengono quindi automaticamente creati, qualificati e distribuiti. La Figura 1 illustra questo workflow CI di base insieme al workflow di sviluppo.
Nella parte di sviluppo del workflow, modelli e test vengono sviluppati, verificati, uniti, rivisti e inviati a un sistema di controllo delle versioni sul desktop dello sviluppatore. Il sistema di controllo delle versioni attiva quindi la parte CI automatizzata del workflow. Le parti principali del workflow CI sono:
Build: Il codice sorgente e i modelli diventano file oggetto ed eseguibili.
Test: Il test viene eseguito come un controllo di qualità.
Pacchetto: Eseguibili, documentazione, artefatti e altri prodotti finali vengono raggruppati per essere consegnati agli utenti finali.
Distribuzione: I pacchetti vengono distribuiti nell'ambiente di produzione.
Insieme, questi quattro passaggi sono noti come “pipeline” della CI. La pipeline è solitamente automatizzata e, a seconda del sistema, il suo completamento può richiedere da pochi minuti a diversi giorni. Vale la pena notare che durante tutte queste fasi vengono creati numerosi artefatti, come distinte base, risultati dei test e report.
I workflow CI sono spesso abbinati ai workflow degli sviluppatori correlati ai sistemi di controllo delle versioni. In questi workflow, gli sviluppatori spesso conservano le modifiche nei repository locali e utilizzano una pipeline CI locale per qualificare le modifiche prima della distribuzione.
Quali sono i vantaggi della CI?
I team che hanno implementato CI segnalano in genere i seguenti vantaggi:
- Ripetibilità. La pipeline CI fornisce un processo automatizzato coerente e ripetibile per la creazione, il test, il confezionamento e la distribuzione. L'automazione ripetibile consente agli sviluppatori di concentrarsi sul lavoro necessario e di risparmiare tempo su un progetto. Rappresenta inoltre un aspetto importante della riduzione del rischio e spesso è un requisito per la certificazione.
- Garanzia di qualità. I test manuali sono efficaci, ma spesso si basano su istantanee risalenti a giorni fa e mancano di ripetibilità. Con CI, le modifiche vengono sempre testate rispetto alla base di codice più recente.
- Tempi di sviluppo ridotti. Processi ripetibili con garanzia di qualità integrata hanno portato a una consegna più rapida di prodotti di alta qualità. Grazie alla distribuzione automatizzata, il tuo codice è sempre pronto per la produzione.
- Collaborazione migliorata. Con CI, gli sviluppatori dispongono di un processo definito per gestire i set di modifiche e unire il loro codice nella linea di produzione. Processi coerenti consentono di gestire team di grandi dimensioni e riducono i costi di assunzione di nuovi sviluppatori.
- Codice pronto per la revisione. Il workflow CI fornisce un'ampia traccia di controllo. Per ogni modifica che attraversa la pipeline CI, è possibile identificare chi ha apportato la modifica, chi l'ha rivista e la natura della modifica, nonché le dipendenze, i test e i relativi risultati, nonché un numero qualsiasi di report e artefatti correlati generati lungo il percorso.
Come si inserisce la progettazione Model-Based nella CI?
Per impostazione predefinita, il workflow e gli strumenti CI sono indipendenti dalla lingua e dal dominio. Ciò significa che la sfida è insegnare strumenti, sistemi e processi CI per parlare di progettazione Model-Based, in altre parole, per rendere Simulink e gli strumenti correlati lingua franca del workflow CI.
Ciò può essere fatto integrando tre componenti chiave della progettazione Model-Based nel workflow CI: verifica, generazione del codice e test (Figura 2). La progettazione Model-Based pone l'accento sulla verifica precoce, che viene mappata nella pipeline CI con una fase di verifica prima della fase di compilazione. La generazione del codice avviene nella fase di compilazione. Nella fase di test è possibile effettuare test dinamici tramite simulazione e analisi statica del codice generato.
Ecco una panoramica di come insegnare il workflow CI per parlare di progettazione Model-Based:
Sviluppo. MATLAB®, Simulink, programmatori e toolbox vengono utilizzati per le attività di sviluppo. I progetti MATLAB vengono utilizzati per organizzare il lavoro, collaborare e interagire con i sistemi di controllo delle versioni.
Test. Simulink Check viene utilizzato per eseguire controlli di qualità del modello prima della simulazione e della generazione del codice. Simulink Test viene utilizzato per sviluppare, gestire ed eseguire test basati sulla simulazione. Simulink Coverage™ viene utilizzato per misurare la copertura e valutare l'efficacia dei test. I controlli di qualità, i risultati dei test e le metriche di copertura possono quindi essere utilizzati come un parametro di controllo per consentire agli sviluppatori di qualificare il proprio lavoro.
Unione. La funzionalità Compare Files and Folders di MATLAB viene utilizzata per confrontare e unire i file MATLAB. Lo strumento Model Comparison viene utilizzato per confrontare e unire i modelli Simulink.
Revisione. La revisione è la fase finale del processo di qualità prima che le modifiche vengano inviate al sistema di controllo delle versioni. Qui vengono esaminate le modifiche apportate agli script MATLAB e ai modelli Simulink. Anche i risultati dei test di prequalificazione vengono esaminati come controllo di qualità finale prima dell'invio.
Invio. I progetti MATLAB forniscono un'interfaccia per i sistemi di controllo delle versioni.
Verifica. Simulink Check, lo stesso strumento utilizzato per la verifica locale, viene utilizzato per la verifica automatizzata all'interno del sistema CI.
Creazione. MATLAB Coder™, Simulink Coder™ ed Embedder Coder vengono utilizzati per generare codice per i test Software-In-the-Loop (SIL).
Test. Simulink Test, lo stesso strumento utilizzato per i test locali, viene utilizzato per i test automatizzati all'interno del sistema CI.
Packaging e distribuzione. Il packaging è il luogo in cui i file eseguibili, la documentazione, gli artefatti e altri prodotti vengono raggruppati per essere consegnati agli utenti finali. La distribuzione è il release del software confezionato. Nei workflow per la progettazione Model-Based, queste fasi variano notevolmente tra organizzazioni e gruppi e spesso comportano il raggruppamento di diverse build e artefatti di certificazione in un prodotto pronto per la distribuzione ad altri team.
Gli strumenti e le pratiche di sviluppo moderni consentono agli sviluppatori di creare sistemi più solidi e di testarne la funzionalità in modo tempestivo e frequente. Quando un sistema CI viene integrato nel workflow, i test a livello di unità e quelli a livello di sistema vengono automatizzati. Ciò significa che lo sviluppatore può concentrarsi sullo sviluppo di nuove funzionalità, non sulla verifica della corretta integrazione delle funzionalità.
Il seguente case study descrive un workflow che incorpora CI e la progettazione Model-Based.
Case study: Un modello Simulink verificato, costruito e testato all'interno di un sistema CI
In questo esempio utilizziamo la progettazione Model-Based con CI per eseguire test basati sui requisiti su un sistema di monitoraggio della corsia di marcia di un veicolo (Figura 3).
La pipeline che utilizzeremo (Figura 4) viene eseguita con ogni build di Jenkins.
Figura 4. Pipeline per un esempio di mantenimento della corsia.
Le fasi della pipeline sono le seguenti:
- Verifica della conformità agli standard: Uno script di unità MATLAB esegue un semplice controllo di Model Advisor. I criteri di valutazione garantiscono che il modello non presenti linee non collegate.
- Creazione del modello: Un file di unit test MATLAB crea il codice SIL di produzione per il nostro modello. I criteri di valutazione vengono superati se la compilazione riesce senza preavviso.
- Esecuzione dei casi di test: Una suite di test in Simulink Test utilizza diversi scenari di guida per testare il controller di mantenimento della corsia. Per verificare il funzionamento soddisfacente del controller vengono utilizzati tre criteri di valutazione:
- Prevenzione delle collisioni: L'auto dell'ego non entra in collisione con l'auto di testa in nessun momento durante la guida.
- Mantenimento della distanza di sicurezza: L'intervallo di tempo tra l'auto dell'ego e l'auto leader è superiore a 1,5 secondi. L'intervallo di tempo tra le due auto è definito come il rapporto tra la distanza calcolata e la velocità dell'auto ego.
- Corsia di marcia: La deviazione laterale dalla linea centrale della corsia è entro 0,2 metri.
- Artefatti del pacchetto: Ciascuna delle fasi precedenti produce artefatti, tra cui un report di Model Advisor, un eseguibile generato e un set di risultati di test che possono essere archiviati per un uso futuro o come riferimento.
Fasi del workflow
Il workflow è costituito dai seguenti passaggi (Figura 5):
- Trigger una build in Jenkins e verifica che le fasi di Verify e Build vengono superate.
- Rilevamento un fallimento del caso di test in Jenkins.
- Riproduzione il problema sul nostro desktop MATLAB.
- Risoluzione del problema nel modello allentando i criteri di valutazione.
- Test in locale per garantire il superamento del test.
- Unione e revisione le modifiche apportate al ramo di test.
- Esecuzione di “Commit” il passaggio a Git™ e l'attivazione di una build in Jenkins.
- Verifica, creazione e test in Jenkins.
Il nostro primo passaggio fallito attraverso il ciclo CI è illustrato in alto a sinistra. Mostra il fallimento del test CI, la riproduzione locale, l'allentamento dei criteri e il completamento con successo del workflow CI.
Dettagli del workflow
- Iniziamo con il triggering di una build in Jenkins selezionando Build now. Il controllo Simulink Check e la generazione del codice passano il test.

- Poi, si rileva un fallimento del caso di test nella seconda fase Verify. Il caso di test
LFACC_Curve_CutInOut_TooClose
nella suite di testLaneFollowingTestScenarios
non soddisfa i criteri di valutazione.

- Per comprendere meglio il fallimento, si riproduce il guasto localmente utilizzando Simulink Test. Apriamo il file di prova
LaneFollowingTestScenarios.mldatx
ed si esegue il caso di testLFACC_Curve_CutInOut_TooClose
. Si noti che non soddisfa i criteri di valutazione della distanza di sicurezza. È richiesta maggiore flessibilità nello stabilire l'intervallo di tempo tra l'auto leader e l'auto ego.

- Grazie alle informazioni sul problema, ora risolviamo il problema. Apriamo il modello
LaneFollowingTestBenchExample.slx
e navighiamo al blocco Collision Detection/Test Assessments Test Sequence. La prima valutazione afferma che l'intervallo di tempo tra l'ego e l'auto leader non dovrebbe scendere sotto 1,5 secondi per più di 2 secondi alla volta.
GlobalAssessments % Assicurarsi che l'intervallo di tempo tra il veicolo dell'ego e il veicolo principale non scenda al di sotto di % 1,5 s per più di 2 s alla volta. verifica(durata(time_gap < 1.5, sec) < 2); % Verificare che non sia stata rilevata alcuna collisione verifica(~collisione); % Verificare che il valore assoluto della deviazione laterale dalla linea centrale della corsia non superi 0,2 m % per più di 5 s alla volta. verifica(durata(abs(lateral_deviation) > 0.2, sec) < 5);
Questa valutazione è troppo restrittiva per la manovra di guida aggressiva in esame. Ai fini di questo esempio, allentiamo i criteri di valutazione per garantire che l'intervallo di tempo non scenda al di sotto di 0,8 secondi per più di 5 secondi alla volta.
GlobalAssessments % Assicurarsi che l'intervallo di tempo tra il veicolo dell'ego e il veicolo principale non scenda al di sotto di % 0,8 s per più di 5 s alla volta. verifica(duration(time_gap < 0.8, sec) < 5); % Verificare che non sia stata rilevata alcuna collisione verifica(~collisione); % Verificare che il valore assoluto della deviazione laterale dalla linea centrale della corsia non superi 0,2 m % per più di 5 s alla volta. verifica(duration(abs(lateral_deviation) > 0.2, sec) < 5);
- Nella nostra simulazione il problema sembra risolto. Per confermare, si testa localmente, salvando il modello e rieseguendo il test nel test manager. Si noti che è approvato con i nuovi criteri di valutazione.

- Abbiamo risolto il problema e verificato localmente. Ora utilizziamo lo strumento di Model Comparison per revisionare le modifiche prima di sottoporle al controllo di versione.

Potremmo anche utilizzare la funzionalità Publish dello strumento Model Comparison per revisionare il codice.

- Una volta risolto il bug, pubblichiamo queste modifiche su GitLab con i progetti MATLAB, aggiungendo un messaggio di commit per segnalare la modifica ai criteri di valutazione.
Prendiamo poi nota dell'ultimo commit in GitLab.
GitLab avvia automaticamente una build in Jenkins. La dashboard del progetto Jenkins mostra lo stato e l'avanzamento della build.

- La build di Jenkins è in esecuzione. Vediamo che le fasi della pipeline Verifica, Crea e Testa sono ormai terminate.
Ora possiamo avviare una richiesta di unione per unire le modifiche apportate al branch Test nel branch principale. In GitLab, in Repository, selezioniamo Branches, quindi fare clic Merge Request accanto all'ultimo commit sul branch Test.
Completiamo il modulo e inviamo la richiesta di merge.
In qualità di proprietari del branch, possiamo accettare la richiesta di merge cliccando sul pulsante Merge. Tutte le modifiche vengono ora acquisite nel branch principale.

Uso dell'esempio: Strumenti, risorse e requisiti
Nelle sezioni seguenti vengono descritte le risorse utili per iniziare, gli strumenti necessari e come configurarli.
Configurazione dei sistemi
Utilizziamo Jenkins come sistema di CI e GitLab come sistema di controllo delle versioni. MATLAB, Jenkins e GitLab devono essere configurati per funzionare insieme. I seguenti tutorial ti aiuteranno con la configurazione.
- Configurazione del nostro progetto MATLAB
- Configurazione di Jenkins
- Configurazione di GitLab per attivare Jenkins
I tutorial sono specifici per GitLab e Jenkins, ma i concetti possono essere applicati anche ad altri sistemi di controllo delle versioni e di CI.
Strumenti necessari
Per questo esempio sono necessari i seguenti strumenti:
- Versione di installazione 2.7.3 Jenkins o successiva. Jenkins viene utilizzato per l'integrazione continua.
- Versione 1.0.3 Plugin MATLAB per Jenkins o successiva. MATLAB, Simulink e Simulink Test sfruttano tutti questo plugin per comunicare con Jenkins. Scopri di più su GitHub.
- Plugin aggiuntivi richiesti:
- Account GitLab. GitLab viene utilizzato per il controllo del codice sorgente ed è disponibile come servizio cloud. I progetti MATLAB includono un'interfaccia Git per la comunicazione con GitLab.
Considerazioni sulla licenza per CI
Se si prevede di eseguire CI su molti host o sul cloud, contattare continuous-integration@mathworks.com per richiedere supporto. Nota: Prodotti trasformativi come MATLAB e prodotti di codifica e compilazione Simulink potrebbero richiedere licenze di accesso client (CAL).
Appendice: Configurazione di MATLAB, GitLab e Jenkins
Fase 1. Configurare il progetto MATLAB per utilizzare il controllo del codice sorgente
Il primo passo nel nostro esempio è configurare il progetto per utilizzare il controllo del codice sorgente con GitLab.
- Creare una nuova directory denominata
MBDExampleWithGitAndJenkins
, carica l'esempio al suo interno e apri MATLABProject MBDExampleWithGitAndJenkins.prj
. - In GitLab, creare un nuovo progetto che sarà il repository remoto. Nominarlo
MBDExampleWithGitAndJenkins
e registra l'URL in cui è ospitato. - In MATLAB, convertire il progetto per utilizzare il controllo del codice sorgente. Nella scheda Project, fare clic su Use Source Control.

Fare clic su Add Project to Source Control.

- Fare clic su Convert.

- Fare clic su Open Project una volta terminato.

Il progetto è ora sotto il controllo locale del codice sorgente Git.
Fase 2. Inviare le modifiche e caricare il repository locale su GitLab
- Sulla scheda Project, fare clic su Remote.

- Specificare l'URL dell'origine remota in GitLab.

Fare clic su Validate per assicurarsi che la connessione al repository remoto sia riuscita e fare clic su OK. Il progetto è ora configurato per inviare e ricevere modifiche con GitLab.
- Fare clic su Commit per eseguire un commit iniziale.


- Fare clic su Push per trasferire tutte le modifiche dal repository locale al repository GitLab remoto.

- Aggiornare la dashboard di GitLab e osservare il contenuto del progetto MATLAB.
Passaggio 3: Creare un branch di test
In questa fase creiamo un branch di test per testare e verificare le modifiche prima di unirle al branch principale.
- Fare clic su Branches.

- Espandere la sezione Branch and Tag Creation , assegnare al branch il nome “Test” e fare clic su Create.
- Osservare Test nel browser dei branch. Dal branch Test, fare clic su Switch quindi Close.
- In MATLAB, selezionare Push per inviare queste modifiche a GitLab e osservare il branch Test in GitLab.
Fase 4. Configurare Jenkins per chiamare MATLAB
- Installare i due plugin richiesti:
- GitLab plugin — Questo plugin consente a GitLab di attivare build di Jenkins e di visualizzarne i risultati nell'interfaccia utente di GitLab.
- MATLAB plugin — Questo plugin integra MATLAB con Jenkins e fornisce l'interfaccia Jenkins per chiamare MATLAB e Simulink.
- Selezionare New Item e creare un nuovo progetto FreeStyle denominato
Esempio MBDExampleUsingGitAndJenkins
. - In Source Code Management, abilitare Git, indirizzare Jenkins al nostro repository GitLab e accedere al branch Test per il build. Nota: Sono richiesti login o password e token API GitLab.
- Configurare il trigger di build per eseguire una build quando viene effettuata una richiesta push al branch Test in GitLab. Nella sezione Build Triggers, selezionare Advanced > secret token. Questo token viene utilizzato da GitLab per richiedere una build e autenticarsi con Jenkins. Prendere nota del token segreto e del webhook GitLab.
- Configurare l'ambiente di build. Selezionare Use MATLAB version e inserire la radice MATLAB.
- Configurare la fase di build.
Fare clic su Add build step e scegliere Run MATLAB Command. Inserire il comando openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecModelAdvisor
per aprire il progetto ed eseguire i controlli di Model Advisor.
Fare clic su Add build step e scegliere Run MATLAB Command di nuovo. Inserire il comando: openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecControllerBuild.
Fare clis cu Add build step e scegliere Run MATLAB Tests. Selezionare TAP test results and Cobertura code coverage per completare la configurazione della build.
Questa azione analizza i risultati del test TAP e li rende visualizzabili quando TAP Extended Test Results è selezionato. L'output contiene una panoramica dei casi di test eseguiti, il riepilogo dei risultati e i log della console MATLAB.

Il plugin TAP raccoglie anche i risultati delle ultime esecuzioni dei test e visualizza un diagramma dello stato di integrità come mostrato di seguito. È possibile accedere a qualsiasi build precedente cliccando sul diagramma.

Fase 6. Pubblicazione di report HTML
Fare clic su Add post-build action > Publish HTML reports. Immettere il percorso radice relativo in cui verrà pubblicato il report HTML e il nome file della pagina indice presente nel percorso.
Aggiungere tante voci quanti sono i report HTML da pubblicare. In questo scenario, ci sono due report web: Riepilogo del Model Advisor e report sulla generazione del codice. Si tratta di report standard creati con le funzioni integrate MATLAB. È possibile aggiungere report HTML personalizzati.
Per ogni report HTML nella pagina principale del job di Jenkins troverete un collegamento al report corrispondente all'ultima build. Se si attiva la casella di controllo “Always link to last build” sotto Publishing options, il plugin pubblicherà report per l'ultima build indipendentemente dallo stato della build. Se questa casella di controllo non è attivata, il plugin si collegherà solo all'ultima build “riuscita”.
Fase 7. Configurare GitLab per attivare una build in Jenkins
Configurare GitLab per attivare una build automatica in Jenkins quando si verifica un nuovo push sul branch principale. Per fare ciò, andare a Settings > Webhooks. Utilizzare l'URL del webhook e il token segreto forniti da Jenkins nella configurazione del Build Trigger e selezionare Push Events.
Nota: Utilizzare un nome di dominio completamente qualificato nella sezione URL al posto di localhost in modo che GitLab possa trovare l'installazione di Jenkins.

Nel menu a discesa Test, selezionare Push Events per testare l'integrazione. GitLab mostrerà il messaggio “Hook eseguito correttamente: HTTP 200” e Jenkins avvierà una build.

Fase 8. Configurare l'autenticazione Jenkins-to-GitLab
Per pubblicare automaticamente lo stato di una build di Jenkins su GitLab, è necessario configurare l'autenticazione da Jenkins a GitLab.
- Creare un token di accesso personale su GitLab con ambito API selezionato.

- Copiare il token e creare una connessione GitLab in Jenkins Configure System.
Nota: Le connessioni possono essere riutilizzate su più processi Jenkins e possono essere configurate globalmente se l'utente dispone almeno dei diritti di “maintainer”.
Fase 9. Integrare Jenkins nella pipeline GitLab
Per integrare Jenkins nella pipeline GitLab, è necessario configurare la connessione GitLab in Jenkins e pubblicare lo stato del job su GitLab.
- Selezionare GitLab Connection nella sezione General del tuo job Jenkins.
- Aggiungere un'azione post-build per pubblicare lo stato della build su GitLab.
Nota: Questa azione non ha parametri e utilizzerà la connessione GitLab esistente per pubblicare lo stato della build su GitLab e creare una tracciabilità bidirezionale per ogni commit e richiesta di merge.

Fase 10. Visualizzare le metriche di test basate sui requisiti (R2020b)
Le metriche di test basate sui requisiti consentono di valutare lo stato e la qualità delle attività di test basate sui requisiti. I risultati delle metriche possono essere visualizzati utilizzando la Model Testing Dashboard.
- Creare un file chiamato
collectModelTestingResults.m
in base alla funzione mostrata di seguito. Questa funzione inizializzerà l'infrastruttura del motore delle metriche e raccoglierà tutte le metriche del modello disponibili.
La capacità metrica della funzione collectModelTestingResults() % aggiunta in R2020a se exist('metric') metricIDs = [... "ConditionCoverageBreakdown" "CoverageDataService"... "DecisionCoverageBreakdown" "ExecutionCoverageBreakdown"... "MCDCCoverageBreakdown" "OverallConditionCoverage"... "OverallDecisionCoverage" "OverallExecutionCoverage"... "OverallMCDCCoverage" "RequirementWithTestCase"... "RequirementWithTestCaseDistribution" "RequirementWithTestCasePercentage"... "RequirementsPerTestCase" "RequirementsPerTestCaseDistribution"... "TestCaseStatus" "TestCaseStatusDistribution"... "TestCaseStatusPercentage" "TestCaseTag"... "TestCaseTagDistribution" "TestCaseType"... "TestCaseTypeDistribution" "TestCaseWithRequirement"... "TestCaseWithRequirementDistribution" "TestCaseWithRequirementPercentage"... "TestCasesPerRequirement" "TestCasesPerRequirementDistribution"... ]; % collect all metrics for initial reconcile E = metric.Engine(); execute(E, metricIDs); end end
- Aggiungere questo file al tuo progetto e al percorso.
- Configurare Jenkins per raccogliere i risultati delle metriche chiamando
new collectModelTestingResults function
due volte. La prima chiamata inizializza l'integrazione delle metriche con Simulink Test Manager. La secondo raccoglie i risultati delle misurazioni utilizzando i risultati esportati di Simulink Test Manager.- Fare clic su Add build step e scegliere Run MATLAB Command di nuovo. Inserire il comando:
openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
Posizionare questo passaggio di build prima del passaggio di build Run MATLAB Tests . - Fare clic su Add build step e scegliere Run MATLAB Command di nuovo. Inserire nuovamente il comando:
openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
Posizionare questo passaggio di build dopo il passaggio Run MATLAB Tests.
- Fare clic su Add build step e scegliere Run MATLAB Command di nuovo. Inserire il comando:
- Controllare i risultati di Simulink Test Manager nel passaggio di build Run MATLAB Tests.

- Archiviare i risultati delle metriche nella directory derivata. È inoltre necessario archiviare i risultati esportati del test manager, poiché consentiranno la navigazione completa dei risultati delle metriche una volta ricaricati in MATLAB.
Fare clic sull’Add post-build action e scegliere Archive the artifacts. Inserire il percorso derived/**,matlabTestArtifacts/*.mldatx
per archiviare tutti i file salvati in quella directory.
Nota: Per visualizzare questi risultati in MATLAB su una macchina diversa da quella di prova, procedere come segue:
- Scaricare gli artefatti archiviati (directory derivata e file MLDATX dei risultati dei test).
- Estrarre e copiare in una copia locale la stessa versione del progetto utilizzata per eseguire il job di CI.
- Aprire il progetto in MATLAB e avviare la Model Testing Dashboard.
I risultati generati dal CI verranno visualizzati sulla dashboard.
Jenkins® is a registered trademark of LF Charities Inc.
Pubblicato nel 2024
I prodotti utilizzati
Ulteriori informazioni
Visualizza articoli per funzionalità correlate
Visualizza articoli per settori correlati
Primi passi con l’integrazione continua con Simulink utilizzando il pacchetto di supporto di automazione di CI/CD