Il test dinamico è la stessa cosa del test manuale?

No. Il test dinamico descrive l'esecuzione del codice, indipendentemente da chi o cosa lo gestisca. Sia un'esecuzione manuale tramite script che una suite di test di regressione automatizzata sono esempi di test dinamico.

DAST è una forma di test dinamico?

Sì. Il Dynamic Application Security Testing analizza un'applicazione in esecuzione dall'esterno, esattamente come il test di sicurezza black box, e segnala le vulnerabilità che si manifestano solo durante l'esecuzione.

I test dinamici si integrano in una pipeline CI/CD?

È la spina dorsale di un sistema. Le suite di unità e API controllano ogni commit, mentre i test di regressione e di performance più lunghi vengono eseguiti ogni notte su una build distribuita.

Cos'è il test dinamico? Tipi, tecniche ed esempi

⚡ Riepilogo intelligente

Il test dinamico esegue l'applicazione e osserva come si comporta il codice in esecuzione con input reali, consentendo ai tester di convalidare funzionalità, prestazioni e stabilità che nessuna revisione della documentazione è in grado di rivelare.

🎯 Scopo: Verificate il comportamento reale in fase di esecuzione, non i documenti che lo descrivono.
🔀 Due rami: La scatola bianca analizza il codice, la scatola nera analizza il comportamento.
🧱 Quattro obiettivi: I test unitari, di integrazione, di sistema e di accettazione eseguono tutti del codice.
⚙️ Non funzionale: Qui vengono eseguiti i controlli di prestazioni, ripristino, compatibilità, sicurezza e usabilità.
🔄 Processo: Strategia, progettazione dei test, configurazione dell'ambiente, esecuzione e segnalazione dei difetti.
💰 Scambio: Rilevamento più approfondito dei difetti, a scapito di tempo, ambienti e costi.

Scopri di più

Cos'è il test dinamico?

Test dinamici Il test dinamico è un metodo di test del software utilizzato per testare il comportamento dinamico del codice. Lo scopo principale del test dinamico è esaminare il comportamento del software con variabili dinamiche, ovvero variabili che non sono costanti, e individuare i punti deboli nell'ambiente di runtime del software. Il codice deve essere eseguito per poter testare il comportamento dinamico.

Il test è verifica e validazionePer completare i test sono necessarie entrambe le V. La verifica viene effettuata tramite test statici, che esaminano i requisiti, i documenti di progettazione e il codice senza eseguirli. La validazione viene effettuata tramite test dinamici, che eseguono la build e confrontano ciò che l'applicazione effettivamente fa con ciò che dovrebbe fare.

La tabella sottostante mette in evidenza le differenze tra i due a colpo d'occhio.

Aspetto	Test statico (verifica)	Test dinamici (validazione)
Code eseguito	Nodo	Si
Attività tipiche	Revvisualizzazioni, sopralluoghi, ispezioni, analisi statica	Esecuzione dei casi di test su tutti i livelli di test
Domanda con risposta	Stiamo realizzando il prodotto nel modo giusto?	Stiamo realizzando il prodotto giusto?
Difetti trovati	Requisiti ambigui, violazioni degli standard di codifica, codice morto	Output errato, perdite di memoria, errori di temporizzazione, errori di integrazione
Avvia	Non appena esiste un artefatto	Una volta che esiste una build eseguibile
Costo relativo di una riparazione	Minori, perché i difetti vengono individuati prima	Più alto, perché i difetti emergono più tardi

Esempio di test dinamico

Un breve esempio pratico mostra come si comportano i test dinamici nella pratica.

Supponiamo di dover testare una pagina di accesso. Questa pagina ha due campi, Nome utente e Password, e il campo Nome utente è limitato a caratteri alfanumerici.

Quando l'utente inserisce il nome utente come "Guru99”, il sistema lo accetta. Quando l'utente inserisce “Guru99@123”, l’applicazione genera un messaggio di errore. Questo risultato dimostra che il codice agisce dinamicamente in base all’input dell’utente.

Il test dinamico, quindi, significa lavorare con il sistema reale, fornire un input e confrontare il comportamento effettivo dell'applicazione con il comportamento previsto; in altre parole, lavorare con il sistema con l'intento di individuare gli errori.

Il test dinamico è quindi il processo di validazione di un'applicazione software come farebbe un utente finale, in diversi ambienti, al fine di realizzare il software corretto.

Cosa fa il test dinamico?

L'obiettivo principale dei test dinamici è garantire che il software funzioni correttamente durante e dopo l'installazione, offrendo un'applicazione stabile e priva di difetti importanti. Nessun software è completamente esente da errori e i test possono evidenziare la presenza di difetti, ma mai la loro assenza.

I test dinamici garantiscono inoltre la coerenza dell'intero software, come dimostra questo esempio.

In un'applicazione bancaria ci sono diverse schermate, come I miei conti, Trasferimento fondi e Bill Paga. Tutti contengono un campo per l'importo.

Supponiamo che il campo I miei account visualizzi l'importo come 25,000, Trasferimento fondi visualizzi $25,000 e il Bill Nella schermata di pagamento viene visualizzato $25000. L'importo è lo stesso, ma la modalità di visualizzazione è diversa, il che rende il software incoerente.

La coerenza non si limita alla funzionalità. Comprende anche standard quali prestazioni, usabilità e compatibilità, ed è per questo che i test dinamici sono così importanti.

Tipi di test dinamici

I test dinamici si suddividono in due categorie.

Bianco Box Collaudo
Nero Box Collaudo

Il diagramma sottostante mette in relazione le due categorie con i livelli di test sottostanti.

Ciascuna tipologia e il suo scopo previsto sono descritti di seguito.

Bianco Box Collaudo — un metodo di test del software in cui la struttura e la progettazione interne sono note al tester. Il suo scopo principale è verificare le prestazioni del sistema in base al codice. Viene eseguito principalmente dagli sviluppatori o da tester white box che possiedono conoscenze di programmazione.

Nero Box Collaudo — un metodo di test in cui la struttura interna, il codice e la progettazione NON sono noti al tester. Il suo scopo principale è verificare la funzionalità del sistema in fase di test. Questo tipo di test richiede l'esecuzione dell'intera suite di test, viene svolto principalmente dai tester e non richiede conoscenze di programmazione.

I test a scatola nera si classificano a loro volta in due tipologie.

Test di funzionalità
Test non funzionali

Test di funzionalità

Test funzionali viene eseguito per verificare che tutte le funzionalità sviluppate corrispondano alle specifiche funzionali. Viene effettuato eseguendo il test funzionale casi test Scritto dal team di controllo qualità. In questa fase il sistema viene testato fornendo input, verificando l'output e confrontando i risultati effettivi con i risultati attesi.

Esistono diversi livelli di test funzionali, tra i quali i più importanti sono i quattro elencati di seguito.

Test unitari — un'unità è una piccola porzione di codice testabile. Il test unitario viene eseguito su una singola unità software ed è effettuato dagli sviluppatori.
Test d'integrazione — Eseguito dopo i test unitari, combinando le singole unità testabili. Viene eseguito dagli sviluppatori o dai tester.
Test di sistema — Eseguito per garantire che il sistema si comporti in conformità ai requisiti. Viene generalmente eseguito dai tester quando il sistema completo è pronto, una volta che la build è stata rilasciata al team di QA.
Test di accettazione — Viene eseguita per verificare se il sistema soddisfa i requisiti aziendali ed è pronto per l'uso o la distribuzione. Generalmente viene eseguita dagli utenti finali.

Test non funzionali

Test non funzionali È una tecnica di test che non si concentra sugli aspetti funzionali, bensì sugli attributi non funzionali del sistema, come perdite di memoria, prestazioni o robustezza. I test non funzionali vengono eseguiti a tutti i livelli di test.

Esistono numerose tecniche di test non funzionali, tra cui le più importanti sono le cinque elencate di seguito.

Test di Performance — verifica se il tempo di risposta del sistema è normale, in base ai requisiti, con il carico di rete desiderato.
Test di recupero — verifica l'efficacia con cui un sistema si riprende da arresti anomali e guasti hardware.
Test di compatibilità — verifica il comportamento del sistema in ambienti diversi.
Test di sicurezza — verifica la robustezza dell'applicazione, garantendo che solo gli utenti e i ruoli autorizzati possano accedere al sistema.
Test di usabilità — verifica l'usabilità del sistema da parte degli utenti finali e il grado di familiarità che questi ultimi provano con esso.

Tecniche di test dinamici

Una volta definiti i tipi, la domanda successiva è come viene effettivamente eseguito un ciclo di test dinamico.

Tecniche di test dinamiche nel STLC Il processo di test dinamico comprende attività quali l'analisi dei requisiti per i test, la pianificazione dei test, la progettazione e l'implementazione dei casi di test, la configurazione dell'ambiente di test, l'esecuzione dei casi di test, la segnalazione dei bug e, infine, la chiusura dei test. Ogni attività nel test dinamico dipende dal completamento dell'attività precedente nel processo di test.

Nell'ambito del ciclo di vita dei test (STLC), il processo di test dinamico vero e proprio inizia con la progettazione dei casi di test. Il diagramma seguente mostra la sequenza delle attività, ciascuna delle quali è descritta di seguito.

Prima di avviare il processo, è necessario concordare la strategia da seguire per i test dinamici.

Una strategia di test dovrebbe concentrarsi principalmente sulle risorse disponibili e sulla tempistica. Sulla base di questi due fattori, è necessario documentare l'obiettivo del test, l'ambito del test, le fasi o i cicli di test, il tipo di ambiente, le ipotesi o le sfide che potrebbero presentarsi e i rischi.

Una volta definita e approvata la strategia dal management, inizia il processo di progettazione dei casi di test.

Progettazione e implementazione dei test

In questa fase il team identifica quanto segue.

Caratteristiche da testare
Condizioni di prova derivate da tali caratteristiche
Elementi di copertura derivati dalle condizioni di prova
Casi di test derivati dagli elementi di copertura

Scatola nera tecniche di progettazione dei test come la partizione di equivalenza, l'analisi dei valori limite, test della tabella decisionale and test di transizione di stato sono ciò che trasforma una condizione di test in un insieme concreto di casi eseguibili.

Configurazione dell'ambiente di prova

Migliori ambiente di test L'ambiente di test dovrebbe essere sempre simile a quello di produzione. In questa fase, la build viene installata e le macchine di test vengono gestite e configurate.

Esecuzione del test

Durante questa fase i casi di test vengono effettivamente eseguiti, manualmente o tramite automazionee i risultati effettivi vengono registrati confrontandoli con i risultati attesi.

Segnalazione di bug catturata

In base all'esecuzione, se i risultati attesi e quelli effettivi non sono gli stessi, il caso di test deve essere contrassegnato come fallito e deve essere registrato un bug nel gestione dei difetti

Vantaggi del test dinamico

I test dinamici rivelano difetti considerati troppo difficili o complessi da individuare, e che l'analisi statica non è in grado di rilevare.
Il software viene eseguito dall'inizio alla fine, il che innalza la qualità sia del prodotto che del progetto.
I test dinamici rappresentano un mezzo essenziale per rilevare le minacce alla sicurezza in un sistema in esecuzione.
I difetti che si verificano solo in fase di esecuzione, come perdite di memoria, problemi di temporizzazione e errori di integrazione, emergono qui e in nessun altro luogo.

Svantaggi del test dinamico

I test dinamici richiedono molto tempo, perché l'esecuzione dell'applicazione o del codice richiede una grande quantità di risorse.
Ciò aumenta i costi del progetto, perché non viene affrontato nelle prime fasi del ciclo di vita del software e i problemi risolti nelle fasi successive risultano più costosi da correggere.
Un ambiente simile a quello di produzione e dati di test realistici sono prerequisiti fondamentali, ed entrambi richiedono impegno per essere creati e mantenuti.

DOMANDE FREQUENTI

Gli sviluppatori si occupano della parte "white box", eseguendo i controlli unitari e dei componenti. I tester QA si occupano della parte "black box", a partire dai test di sistema. Gli utenti finali chiudono il ciclo con i test di accettazione.

I modelli leggono i requisiti e i casi esistenti, quindi propongono i valori limite, gli input non validi e le sequenze di stato che un backlog umano solitamente ignora. Un tester conferma comunque ogni risultato atteso prima dell'esecuzione.

Sì. La creazione di asserzioni, gli oggetti pagina e la configurazione dei fixture sono codice ripetitivo che un assistente gestisce bene. Decidere cosa costituisca un comportamento corretto rimane un giudizio umano basato sui requisiti.

Strutture unitarie come JUnit, TestNG e pytest, oltre a runner di interfaccia utente e API come Selenium, Cypress and Postman. Carica strumenti come JMeter coprire il lato non funzionale di automazione.

I report di lavoro white box mostrano la copertura di dichiarazioni, rami e percorsi da esecuzioni strumentate. I report di lavoro black box mostrano la copertura dei requisiti e delle condizioni di test. Nessuno dei due valori da solo dimostra che la build sia stata testata in modo adeguato.

No. Il test dinamico descrive l'esecuzione del codice, chiunque o qualunque cosa lo gestisca. Uno script Manuale Sia l'esecuzione che la suite di regressione automatizzata sono test dinamici.

Sì. Il test dinamico di sicurezza delle applicazioni analizza un'applicazione in esecuzione dall'esterno, esattamente come una scatola nera. test di sicurezza Esegue questa operazione e segnala vulnerabilità che si manifestano solo in fase di esecuzione.

È la spina dorsale di uno. Le suite di unità e API controllano ogni commit, mentre più a lungo regressione e i test di performance vengono eseguiti ogni notte su una build distribuita.