Che cos'è il test distruttivo nel software?

By: Tommaso Hamilton Tommaso Hamilton
Hours aggiornato

⚡ Riepilogo intelligente

I test distruttivi spingono deliberatamente un'applicazione software al limite fino al suo guasto, rivelando i punti esatti in cui la robustezza viene meno a causa di un utilizzo improprio, input non validi e comportamenti imprevedibili, punti che i normali controlli funzionali non riescono a individuare.

  • 💥 Idea centrale: L'applicazione è progettata per fallire di proposito, in modo che i suoi punti deboli diventino visibili e misurabili.
  • 🔎 Non sono richiesti requisiti specifici: La conoscenza preliminare delle specifiche è facoltativa, sebbene affini la strategia di test.
  • ️ Coppia opposta: I test non distruttivi seguono la strada più sicura; i test distruttivi la attaccano da ogni angolazione sbagliata.
  • 🧰 Approcci: Analisi dei punti critici, revisione tra pari dei tester, revisione aziendale ed eseguizioni esplorative con fogli di esecuzione.
  • 🧪 Metodi riutilizzati: Test di regressione, di interfaccia, di partizionamento per equivalenza, di ciclo e di accettazione perseguono tutti obiettivi distruttivi.
  • 📉 Limiti onesti: È difficile garantire la copertura, l'impegno richiesto è elevato e i risultati possono essere difficili da riprodurre.
Scopri di più

Che cos'è il test distruttivo nel software, con metodi e tecniche?

Cos'è il test distruttivo?

Prove distruttive Il test distruttivo è un metodo di test del software utilizzato per individuare i punti di errore in un programma. In questa tecnica, un'applicazione viene intenzionalmente resa inutilizzabile, in modo da verificarne la robustezza e identificarne i punti deboli. A differenza dei metodi di test che verificano il corretto funzionamento dell'applicazione, il test distruttivo esamina il comportamento imprevedibile dell'utente all'interno dell'applicazione.

La conoscenza dei requisiti originali non è necessaria per i test distruttivi. Tuttavia, una certa conoscenza è utile nello sviluppoping una buona strategia di test.

L'illustrazione qui sotto riassume il concetto: il tester lavora contro il prodotto, anziché con esso.

Concetto di test distruttivo: un'applicazione spinta deliberatamente fino al punto di guasto.

Perché eseguire test distruttivi?

  • Aiuta a comprendere il comportamento prevedibile del software quando quest'ultimo viene utilizzato in modo improprio.
  • Aiuta a verificare la robustezza di un prodotto software.
  • Mette in luce difetti rari che gli utenti comuni non riscontrano mai, ma che emergono in fasi successive della produzione.

Test distruttivi vs test non distruttivi

I due approcci sono complementari, non rivali. Controlli non distruttivi — detto anche test positivo o test di tipo "happy-path" — interagisce correttamente con il software e lascia la build intatta. Il test distruttivo fa l'opposto: immette dati non validi e sequenze errate finché qualcosa non si rompe.

Aspetto Prove distruttive Controlli non distruttivi
Intento Forzare il fallimento dell'applicazione Verificare che l'applicazione funzioni come specificato
Input utilizzato Non valido, malformato, fuori intervallo, fuori sequenza Dati validi entro l'intervallo previsto
Domanda con risposta Dove e come si rompe? Fa quello che dovrebbe?
Conoscenza dei requisiti Opzionale Essential
Costo tipico Livello superiore: esplorativo e aperto Inferiore — preimpostato e ripetibile
Risultato Punti di guasto, limiti di intervallo, comportamento di recupero Superare o non superare la prova secondo le specifiche

Cosa si verifica durante un test distruttivo?

I test distruttivi esaminano entrambi i lati del confine comportamentale:

  • Comportamento corretto del software
  • Comportamento improprio del software
  • Uso improprio
  • Dati di input non corretti
  • Dati di output corretti

Durante l'esercizio devono sussistere due condizioni:

  • Il software non deve mai elaborare o accettare dati di input non validi.
  • Indipendentemente dalla validità o dalla correttezza dei dati di input, il software dovrebbe sempre produrre dati di output appropriati.
Da non perdere:

Come eseguire i test distruttivi?

Il test distruttivo comprende numerose attività, come la progettazione di una serie di script di test, l'esecuzione di tali script, la segnalazione e la risoluzione dei bug e la fornitura di metriche di superamento o fallimento agli stakeholder al termine dell'iterazione.

Esistono numerosi modi per eseguirlo. Ecco alcuni esempi.

  • Metodo di analisi dei punti di guasto: una panoramica del sistema che valuta cosa potrebbe andare storto in vari punti. Aiuto da un analista di affari può essere presa in considerazione per questa strategia.
  • Revisione tra pari da parte dei tester: prendi il tuo casi test analizzato o rivisto da un altro tester meno esperto del sistema o della funzione.
  • Analisi aziendale dei casi di test: Spesso gli utenti finali o gli esperti pensano a scenari validi che i tester non considerano, perché la loro attenzione è focalizzata sui requisiti dichiarati.
  • Eseguire test esplorativi utilizzando fogli di esecuzione: test esplorativi I fogli di esecuzione registrano ciò che è stato testato, consentono di ripetere i test e mantengono sotto controllo la copertura dei test.
  • Utilizza un'altra fonte: Chiedi a qualcun altro di testare il software e di analizzare gli scenari che riscontra.

Esempio di test distruttivo

Consideriamo le schermate di accesso e del profilo di un'applicazione bancaria. Un attacco distruttivo funzionerebbe in casi come questi:

  • Incolla una stringa di 5,000 caratteri in un campo limitato a 50 caratteri e verifica che il campo la rifiuti anziché troncarla silenziosamente.
  • Inserisci lettere, simboli e valori negativi in ​​un campo numerico.
  • Interrompi la sequenza prevista: apri direttamente la pagina di conferma del pagamento senza completare il passaggio precedente.
  • Premi ripetutamente e in rapida successione il pulsante "Invia" per verificare se vengono creati record duplicati.
  • Disconnetti la rete a metà transazione e verifica se l'applicazione si ripristina correttamente o se lascia una traccia parziale.

Ogni caso ha un'aspettativa ben definita: un messaggio di convalida chiaro, nessuna corruzione dei dati e nessuna eccezione non gestita. Qualsiasi altra situazione rappresenta un punto debole da segnalare come difetto.

Metodi di test distruttivi

Nell'ingegneria del software, per raggiungere gli obiettivi dei test distruttivi, si utilizzano i seguenti metodi:

Tecniche di test distruttivi

Le tecniche descritte di seguito possono essere utilizzate con alcune modifiche:

Le tecniche adiacenti che vale la pena aggiungere quando l'obiettivo è la robustezza sono test negativo, stress test, test di recupero and test fuzz.

Vantaggi e svantaggi delle prove distruttive

È opportuno esplicitare chiaramente il compromesso prima di pianificare il rilascio di questa tecnica.

Vantaggi

  • RevIndividua i punti di fallimento che i test basati su conoscenze pregresse non raggiungono mai.
  • Definisce limiti di portata reali, in modo che il prodotto possa essere utilizzato al loro interno con sicurezza.
  • Mette in luce difetti rari che emergono in produzione molto tempo dopo il rilascio.
  • Verifica la durabilità, la recuperabilità e la gestione degli errori in condizioni di utilizzo improprio.

Svantaggi

  • Essendo un'iniziativa a carattere aperto, la sua copertura non può essere garantita né misurata con facilità.
  • Richiede tempo ed è dipendente dall'esperienza e dalla creatività del tester.
  • I risultati possono essere difficili da riprodurre senza un'accurata documentazione dei passaggi eseguiti.
  • Le esecuzioni non controllate correttamente possono corrompere i dati di test condivisi, pertanto è necessario un ambiente isolato.

DOMANDE FREQUENTI

Si sovrappongono, ma differiscono per ambito di applicazione. Test negativo Il test distruttivo verifica gli input non validi definiti rispetto alla gestione degli errori prevista. Il test distruttivo è più ampio e aperto, e mira a individuare qualsiasi condizione che provochi il fallimento dell'applicazione.

Solitamente, il team è composto da ingegneri QA esperti, supportati da colleghi che non hanno familiarità con il modulo e da utenti aziendali. Il parere esterno è importante, perché chi ha sviluppato la funzionalità tende a testarla nel modo in cui è stata progettata.

Dopo che la suite funzionale è stabile, i fallimenti indicano la robustezza piuttosto che funzionalità incomplete. Molti team lo pianificano durante i test di sistema e lo ripetono prima delle principali release. ciclo di vita dei test.

I modelli generano carichi utili non conformi, valori limite e sequenze di azioni insolite a un volume che nessun tester può eguagliare, quindi classificano le anomalie prodotte. L'apprendimento automatico sui dati relativi ai difetti passati prevede anche quali moduli meritano il trattamento più severo.

Copilota GitHub Redige rapidamente generatori di input, casi limite e routine di pulizia. Un tester decide comunque quali modalità di errore sono rilevanti e se il comportamento osservato può essere considerato un risultato accettabile.

L'input o la sequenza esatta utilizzata, l'errore osservato, i log e gli screenshot, l'ambiente e la gravità dell'impatto. Le metriche di successo o fallimento per l'iterazione vanno agli stakeholder insieme al registri dei difetti.

Non dovrebbe mai essere utilizzato in produzione. Eseguilo in un ambiente isolato con dati ripristinabili, perché input volutamente non validi e arresti anomali forzati possono lasciare record incompleti la cui pulizia è costosa.

Durante la sessione, tieni un foglio di esecuzione in cui registri ogni azione e input in ordine. Riproduci il foglio partendo da uno stato pulito, quindi riducilo alla sequenza più breve che sia ancora in grado di causare l'errore.

Riassumi questo post con: