Test del software non distruttivo (NDT): cos'è, strategia di test
Tommaso Hamilton
⚡ Riepilogo intelligente
Il test non distruttivo verifica che un'applicazione si comporti correttamente quando riceve input validi, motivo per cui i tester lo chiamano anche test positivo o test di percorso felice. Conferma i risultati attesi rispetto ai requisiti documentati.
Cos'è il test non distruttivo del software?
Controlli non distruttivi è un tipo di test del software che prevede il test e l'interazione corretta con l'applicazione software. In altre parole, i test non distruttivi del software (NDT) possono anche essere chiamati test positivi o test del percorso felice. Fornisce i risultati attesi e dimostra che l'applicazione software si comporta come previsto.
Il nome deriva dall'ingegneria, dove le prove non distruttive ispezionano un componente fisico senza danneggiarlo. Nel software, l'idea è la stessa: l'applicazione viene utilizzata nel modo per cui è stata progettata e supera il test senza subire danni.
Esempio: Inserire i dati corretti in un modulo di accesso e verificare se le credenziali vengono accettate e se si viene reindirizzati alla pagina successiva.
Lo screenshot qui sotto mostra il modulo di accesso, con un valore valido inserito nel campo nome utente prima dell'esecuzione del test.
Per eseguire un test non distruttivo sull'esempio precedente, inserire un nome utente e una password validi nel modulo di accesso. Poiché l'input corrisponde ai requisiti, il risultato desiderato è positivo e il tester si limita a verificare che l'applicazione passi alla pagina successiva.
Perché eseguire test non distruttivi del software (NDT)?
I test non distruttivi rispondono alla prima domanda che ogni stakeholder si pone riguardo a una build: la funzionalità fa effettivamente quello che è stato richiesto? Questi sono i motivi per cui i team li eseguono.
- Il principale vantaggio del metodo NDT è che si traduce in una migliore qualità del software, perché i difetti rilevati nel flusso principale vengono corretti tempestivamente.
- Per dimostrare che le funzioni del software funzionano secondo le specifiche.
- Per verificare che i requisiti di prestazione siano stati soddisfatti.
- Verificare che vengano soddisfatte le esigenze degli utenti finali.
- Per verificare che una piccola porzione di codice o funzionalità funzioni come previsto e non comprometta le funzionalità correlate.
- Per produrre prove che possono essere mostrate a un test di accettazione dell'utente Approvazione finale, in cui il cliente desidera visualizzare il comportamento previsto piuttosto che le modalità di errore.
Quando vengono eseguiti i controlli non distruttivi (NDT)?
In questo caso, la tempistica è più importante che nella maggior parte delle altre tecniche, perché il percorso ottimale condiziona tutto ciò che segue.
- È la prima forma di test che un tester eseguirebbe su un'applicazione, vale a dire, nella fase iniziale dell' SDLC.
- Le prove non distruttive vengono generalmente eseguite quando non c'è tempo sufficiente per un ciclo di prova completo, poiché dimostrano comunque che i criteri di accettazione sono soddisfatti.
- Viene eseguito prima di scenari negativi e distruttivi. Se il flusso principale si interrompe, i test di gestione degli errori segnalano rumore anziché difetti reali.
- Viene ripetuto dopo ogni correzione del difetto, ed è qui che si sovrappone test di regressione.
Strategia di prova per prove non distruttive
La strategia per le prove non distruttive è volutamente semplice, e la disciplina sta nel mantenere un atteggiamento positivo piuttosto che nell'utilizzo di strumenti specifici.
- L'approccio alle prove non distruttive dovrebbe essere positivo.
- Lo scopo della tecnica NDT è dimostrare che un'applicazione funzionerà correttamente quando le vengono forniti dati di input validi.
- Non sono richiesti requisiti o ambienti particolari per eseguire prove non distruttive.
- La migliore pratica per le prove non distruttive è verificare se il sistema fa quello che dovrebbe fare.
Il diagramma seguente riassume come tale strategia viene normalmente organizzata durante un ciclo di test.
Come scrivere casi di test non distruttivi (positivi)
Un caso di test non distruttivo è utile solo quando il suo input è dimostrabilmente valido e il suo risultato atteso deriva da un requisito piuttosto che da un'ipotesi del tester. I seguenti passaggi producono questo tipo di caso di prova.
Passaggio 1) Scegliere un criterio di accettazione. Leggi il requisito e riformulalo come un'unica affermazione verificabile, ad esempio "il campo nome utente accetta da sei a venti caratteri alfanumerici".
Passaggio 2) Scegliere dati di input validi. Seleziona valori che rientrino comodamente nell'intervallo consentito. Partizionamento per equivalenze Questo aiuta in questo caso: di solito è sufficiente un valore rappresentativo per ogni partizione valida.
Passaggio 3) Scrivere il risultato atteso prima dell'esecuzione. Il risultato atteso deve essere scritto a partire dalle specifiche. Scriverlo dopo l'esecuzione trasforma il test in una descrizione di ciò che la build ha effettivamente fatto.
Passaggio 4) Mantenere i passaggi nell'ordine in cui sono stati eseguiti dall'utente. La sequenza deve corrispondere al modo in cui un utente reale completerebbe l'attività, poiché lo scopo della tecnica è confermare il percorso previsto.
Passaggio 5) Registrare l'identificativo del requisito. TracRiportare il caso ai suoi criteri è ciò che permette al team di dimostrare la copertura durante una revisione.
Ecco un esempio pratico del modulo di accesso.
| Settore | Caso di prova non distruttivo |
|---|---|
| Requisito | Il nome utente accetta da 6 a 20 caratteri alfanumerici. |
| Dati di test | Nome utente guru99tester, password corrispondente valida |
| Passaggi | Apri la pagina di accesso, inserisci le credenziali, seleziona Accedi |
| Risultato atteso | Le credenziali vengono accettate e viene visualizzata la pagina iniziale. |
| Tipo | percorso positivo/felice |
Nota che nulla nel caso tenta di rompere il campo. Un caso che inserisce cinque caratteri per vedere il messaggio di errore è un test negativo, non uno non distruttivo.
Esempi di controlli non distruttivi
L'esempio seguente mostra come si comportano i test non distruttivi in un'applicazione multi-modulo dopo che un difetto è stato corretto.
- Un'applicazione è composta da cinque moduli: pagina di accesso, pagina iniziale, pagina dei dettagli utente, creazione di un nuovo utente e creazione di attività.
- Supponiamo che ci sia un bug nella pagina di accesso: il campo del nome utente accetta meno di sei caratteri alfanumerici. Questo viola il requisito stabilito, che prevede che il nome utente non debba accettare meno di sei caratteri, quindi il comportamento costituisce un difetto.
- Il bug viene segnalato al team di sviluppo tramite il solito processo di gestione dei difettiIl problema è stato risolto e la build è stata inviata nuovamente al team di test.
- Il team di test non si limita a verificare la pagina di accesso in cui è stato corretto il difetto, ma testa anche gli altri moduli. Durante il test di tutti i moduli con dati validi, esegue test non distruttivi, semplicemente per confermare che l'intera applicazione funzioni ancora correttamente.
Prove non distruttive vs prove distruttive
Le due tecniche vengono spesso insegnate insieme perché rispondono a domande opposte riguardanti la stessa costruzione. Prove distruttive Il metodo di analisi individua il punto in cui il software cede, mentre i test non distruttivi confermano che il comportamento previsto si mantiene.
| Aspetto | Controlli non distruttivi | Test distruttivi |
|---|---|---|
| Intenzione | Interagisci correttamente con l'applicazione e verifica i risultati positivi | Fornire input insoliti o non validi per individuare il punto di errore |
| Dati in ingresso | Dati validi tratti dal requisito | Dati non validi, corrotti o fuori sequenza |
| Requisiti necessari | Sì, i casi vengono redatti in base ai criteri di accettazione | Non necessariamente; i tester lavorano senza il pregiudizio legato alla user story. |
| Ciò che rivela | Punti deboli nella funzionalità rispetto alle specifiche | Punti deboli nella progettazione, nella robustezza e nella recuperabilità |
| Tecniche correlate | Test del fumo, test funzionali | Test della scimmia, test esplorativi |
I due metodi sono complementari, non alternativi. Eseguire solo test non distruttivi non verifica la gestione degli errori, mentre eseguire solo test distruttivi non dimostra mai che il prodotto svolga correttamente la sua funzione.
Vantaggi e limiti dei test software non distruttivi
Sapere dove una tecnica smette di essere utile è tanto importante quanto sapere cosa copre.
Vantaggi
- Progettazione ed esecuzione rapide, perché i dati di test provengono direttamente dalle specifiche.
- Non richiede ambienti speciali, iniezione di errori o set di dati corrotti.
- Produce prove che corrispondono in modo univoco ai requisiti, il che è utile per audit e approvazioni.
- Funziona altrettanto bene come test manuale e come previsto test di automazione, quindi gli stessi casi possono essere riutilizzati in una suite di regressione.
- Fornisce un segnale tempestivo e onesto sulla salute della build a qualsiasi livello, dall'unità fino a test d'integrazione a test di sistema.
limitazioni
- Un test completo non dice nulla su come l'applicazione si comporta con input non validi, quindi gravi difetti nella gestione degli errori possono sfuggire al controllo.
- La copertura è limitata dalla qualità dei requisiti. Tutto ciò che non è specificato non viene mai testato.
- Può generare una falsa sicurezza quando la strada più agevole è l'unica percorsa prima di un rilascio.
- Non misura la robustezza, il recupero o le prestazioni sotto stress, che necessitano di tecniche proprie dall'insieme più ampio di tipi di test del software.
Considera i test non distruttivi come la base su cui si fonda ogni altra tecnica e pianificali all'interno del più ampio Ciclo di vita del test del software piuttosto che come attività isolata.
