Test di regressione: la tua assicurazione software
I tester del software solitamente intendono un test di regressione come la ripetizione di un test esistente. Vuoi verificare se questo test funziona ancora con successo dopo una modifica del software.
1. Obiettivi dei test di regressione
Obiettivo 1: “Il vecchio codice funziona ancora”
Standard come IEC 62304 richiedono test di regressione per determinare che una modifica a un componente del SISTEMA non abbia influito sulla sua funzionalità, affidabilità o prestazioni e non abbia causato ulteriori difetti.
Ciò rende chiaro l’obiettivo di un test di regressione dal punto di vista della norma IEC 62304: trovare errori causati da una modifica del software nel codice già testato.
La FDA lo formula in modo quasi identico nella Guida alla convalida del software:
Il test di regressione è la ripetizione dei casi di test che un programma ha precedentemente eseguito correttamente e il confronto del risultato corrente con quello precedente al fine di rilevare gli effetti indesiderati di una modifica del software.
Quelle: Guida alla convalida del software FDA
Obiettivo 2: “Il codice funziona in modo affidabile”
La norma IEC 62304 non menziona un secondo obiettivo: un test di regressione può anche verificare se il software si comporta allo stesso modo nel lungo termine senza modificarlo. Tali test sono consigliati se il software non si comporta in modo strettamente deterministico, ad es
- alle condizioni di gara
- quando ci sono modifiche all’ambiente di runtime, come l’hardware o il sistema operativo
- o quando si dipende dai dati (modificabili).
2. Test di regressione: requisiti normativi
a) Requisiti della norma IEC 62304
Test di regressione durante i test di integrazione
La norma IEC 62304 richiede test di regressione/test di regressione come parte del test di integrazione/test di integrazione. Questo per garantire che non vengano introdotti errori durante l’integrazione di componenti in una parte di componenti già integrata. Lo standard non descrive quali errori potrebbero essere.
Test di regressione per modifiche al sistema software
Come previsto, lo standard richiede test di regressione per le modifiche al sistema software. Anche con piccoli cambiamenti, come sottolinea.
I produttori devono anche giustificare se non eseguono nuovamente tutti i test di regressione dopo una modifica. Maggiori informazioni su questo punto di seguito.
b) Requisiti della FDA
Test di regressione per modifiche al software
La FDA sottolinea che il 79% di tutti i bug software vengono introdotti modificando software già rilasciato. Di conseguenza, sottolinea la necessità di test di regressione nella Guida alla convalida del software:
Ogni volta che il software viene modificato, è necessario condurre un’analisi di convalida non solo per convalidare la singola modifica, ma anche per determinare l’entità e l’impatto di tale modifica sull’intero sistema software. Sulla base di questa analisi, lo sviluppatore del software dovrebbe quindi condurre un livello appropriato di test di regressione del software per dimostrare che le parti invariate ma vulnerabili del sistema non sono state influenzate negativamente. I controlli di progettazione e i test di regressione appropriati forniscono la certezza che il software viene convalidato dopo una modifica del software.
Guida alla convalida del software FDA
Analogamente alla norma IEC 62304, la FDA richiede test di regressione e un’analisi di quali parti del software devono essere nuovamente testate.
Test di regressione durante i test di integrazione
Analogamente alla norma IEC 62304 esiste anche un requisito relativo all’integrazione:
L’analisi di regressione e i test di regressione dovrebbero essere impiegati anche quando si utilizzano metodi di integrazione per costruire un prodotto software per garantire che i moduli appena integrati non incidano negativamente sul funzionamento dei moduli precedentemente integrati.
Quale: IEC 62304
Se possibile, eseguire ogni test come test di regressione
La FDA presta particolare attenzione alla gestione della configurazione e alla capacità di (tutti) i test di essere ripetuti come parte dei test di regressione:
Le procedure di test, i dati e i risultati dei test devono essere documentati in modo da consentire di raggiungere decisioni oggettive di superamento/fallimento. Dovrebbero inoltre essere adatti alla revisione e al processo decisionale obiettivo successivo all’esecuzione del test e dovrebbero essere adatti all’uso in qualsiasi successivo test di regressione.
Quelle: FDA
3. Quale parte del software deve essere sottoposta a test di regressione?
La risposta breve a questa domanda è: l’intero sistema software con tutti i test, a meno che non si possa giustificare un ambito di test più piccolo.
Esistono quindi due viti di regolazione che possono essere utilizzate per ridurre l’ambito del controllo:
- La dimensione dell’oggetto di test (ovvero l’intero sistema software o solo parti)
- Gli obiettivi del test, ovvero quali caratteristiche di qualità controlli il software. La norma ISO 25010 offre una panoramica delle possibili caratteristiche di qualità.
Annuncio 1. Limitazione della dimensione dell’oggetto di prova
Se si apporta una modifica a una parte di un sistema software e si desidera sottoporre solo quella parte a test di regressione, è necessario spiegare perché questa modifica non può influenzare altre parti del sistema software.
Il modo migliore per giustificare ciò è utilizzare un’architettura software documentata. Questo dovrebbe mostrare:
- le dipendenze di altri componenti dal componente modificato
- le interfacce attraverso le quali vengono implementate queste dipendenze
Annuncio 2. Limitazione degli obiettivi del test
Soprattutto quando si tratta di “requisiti non funzionali” come prestazioni o portabilità, un argomento esclusivo basato sull’architettura software (statica) spesso non ha successo. Tuttavia, le ragioni sono ovvie. Esempi:
- È improbabile che la modifica di un algoritmo influisca sulla portabilità del software.
- Se un test unitario può dimostrare che le prestazioni di un componente sono invariate, è improbabile che si verifichi un cambiamento nelle prestazioni dell’intero sistema.
Tuttavia, questa capacità di selezionare i test di regressione in base al tipo di obiettivo del test richiede che anche i test siano classificati e suddivisi di conseguenza.
4. Test di regressione: migliori pratiche
a) Consigli generali
Il test di regressione è un segno distintivo dello sviluppo di software professionale. Sono la tua “assicurazione”, i tuoi guardrail, soprattutto quando si tratta di modifiche al software.
Se non stai ancora eseguendo test di regressione completi, questi sarebbero i miei suggerimenti:
- Automatizzareche può essere automatizzato.
Questo è un investimento iniziale che ripaga. Se hai problemi di capacità, considera uno studente di laurea triennale o magistrale che sta costruendo un’infrastruttura di test come parte del suo lavoro. Chi non investe in un test di regressione è come chi dice di non avere tempo per affilare la sega perché deve segare faticosamente tanto legno. - Aumentare la percentuale di test di regressione
La maggior parte delle persone non vorrà più “riscrivere” i test per il codice esistente. Quindi si specifica che tutte le modifiche e tutte le nuove parti di codice devono essere incluse in una suite di regressione. In questo modo è possibile aumentare costantemente nel tempo la percentuale di codice testato automaticamente (vedere Fig. 1). - Migliora la tua architettura software
L’affermazione che un codice è difficile da testare (ad esempio solo con l’hardware) è una chiara indicazione che il codice è strutturato in modo non ottimale. Un livello di astrazione dell’hardware, un refactoring dell’architettura e una maggiore formazione sui test del software possono fare miracoli. - Esegui i test il più spesso possibile
Una build automatizzata con uno strumento come Hudson o Maven ti aiuta a trovare ed eliminare gli errori in anticipo, evitando così un ritardo imprevisto del progetto poco prima del rilascio.
b) Testare il software incorporato
Alcuni clienti sospettano che non possiamo eseguire test automaticamente perché programmiamo molto strettamente sull’hardware. Inoltre, anche la norma IEC 62304 non lo richiederebbe.
È certamente vero che la norma IEC 62304 non richiede automazione. È anche vero che con il software incorporato che è molto legato all’hardware, l’hardware deve essere presente per testare questo software. Ciò nonostante:
- Da un lato, i banchi prova automatizzati che contengono questo hardware non sono una nuova invenzione.
- D’altro canto, la decisione a favore o contro i test automatizzati non deve essere presa in modo trasversale per l’intero software.
Quando il software incorporato può e deve essere testato automaticamente
Una regola semplice per esempio per uno Sviluppo software SOP potrebbe significare che tutti i componenti che non contengono accesso hardware devono essere testati automaticamente. La determinazione dell’eventuale accesso all’hardware deve essere effettuata a ogni livello della gerarchia.
La Fig. 2 mostra che il sistema nel suo insieme (livello di blocco 0) ha accesso hardware, quindi è rosso e non necessita di essere testato in modo completamente automatico.
Al livello di blocco 1 solo uno dei quattro componenti ha accesso all’hardware, gli altri no (verde). E di questo componente con accesso hardware (rosso), esiste solo un componente al livello 2 (rosso).
Tuttavia, se quasi tutti i componenti avessero accesso all’hardware, sorge la domanda sulla qualità dell’architettura. Hai dimenticato un HAL del livello di astrazione hardware? Le funzionalità vengono addirittura implementate in modo ridondante? Un diagramma dei componenti fornisce esattamente questa panoramica e comprensione.
Infrastruttura per testare il software incorporato
A volte è difficile testare direttamente l’interfaccia hardware esterna perché non esiste un’infrastruttura di test adeguata e/o il protocollo è molto complesso. Quindi un’altra regola potrebbe essere che in questi casi il sistema collegato esternamente (qui in azzurro) possa essere utilizzato come test driver. Questo non è più un vero e proprio test dei componenti ai sensi della norma IEC 62304, ma è almeno meglio che rinunciare completamente a questo test.
Sarebbe meglio che il software integrato creasse un’infrastruttura di test in grado di padroneggiare i protocolli di tutte le interfacce interne ed esterne. Tuttavia, questo sforzo iniziale vale la pena se si devono sviluppare più versioni di un prodotto (componente) e quindi Test di regressione (anche ai sensi della norma IEC 62304) sono obbligatori.
c) Testare software basato sull’intelligenza artificiale
L’affermazione secondo cui il software basato sull’intelligenza artificiale, in particolare il software che utilizza reti neurali come i modelli linguistici di grandi dimensioni, è difficile da sottoporre a test di regressione a causa della sua “natura probabilistica” dovrebbe essere messa in discussione in diversi modi:
- La scelta del token successivo è basata sulla probabilità. Tuttavia, ciò non significa necessariamente che gli output cambino secondo una distribuzione di probabilità dati gli stessi input. Dopotutto, i “pesi e i pregiudizi” delle reti neurali non cambiano.
- Se i risultati sono così imprevedibili da non soddisfare una specifica, è necessario verificare se il dispositivo medico può essere “approvato”. Se però le prestazioni soddisfano i requisiti di una specifica, ciò deve essere garantito anche a lungo termine. Questo è esattamente ciò che i test di regressione dovrebbero e possono verificare.
- I produttori devono essere in grado di creare tale specifica. Queste specifiche potrebbero anche essere necessarie per determinare la probabilità (possibilmente a seconda degli input/caratteristiche) con cui i modelli effettuano previsioni corrette. I test di regressione devono quindi verificare anche queste probabilità, il che a sua volta può richiedere che questi test vengano eseguiti più volte.
Per i modelli basati sull’intelligenza artificiale sono necessari test di regressione, soprattutto per gli aggiornamenti di software/modelli, poiché anche piccole modifiche al modello (ad es. dopo ulteriore formazione) possono avere effetti importanti.
Questi test di regressione di prodotti o modelli per l’analisi delle immagini possono essere eseguiti in modo riproducibile utilizzando fantasmi (ad esempio i fantasmi a raggi X di PhantomX).
Cambiare la storia
- 2024-07-09: Aggiunta la sezione 4.c). Modifiche editoriali
- 2019-01-31: Pubblicata la prima versione dell’articolo
Il post Test di regressione: la tua assicurazione sul software è apparso per primo su Conoscenza del software medico.
I tester del software solitamente intendono un test di regressione come la ripetizione di un test esistente. Vuoi verificare se questo test funziona ancora con successo dopo una modifica del software. Leggi questo articolo su cosa dovresti considerare quando conduci un test di regressione per un software medico. 1. Obiettivi dei test di regressione Obiettivo…