structural testing tutorial what is structural testing
Questo tutorial completo sui test strutturali spiega cos'è il test strutturale, i suoi tipi, cos'è il test del flusso di controllo e il grafico del flusso di controllo, i livelli di copertura, ecc .:
Una rapida ricerca su Google di alcuni dei bug software più costosi mi ha lasciato la mente sbalordita - $ 500 miliardi. Sì, è così che può costare un bug. Anche leggere qualsiasi cosa relativa a vite perse nel settore dei trasporti e della sanità a causa di un bug del software può essere orribile.
Sebbene gli errori nel codice non siano sempre così estremi in cui comportano la perdita di copiose quantità di denaro e vite, l'unico punto chiave qui che stiamo cercando di trasmettere è che non si può trascurare il test.
Quando i test vengono eseguiti frequentemente in tutto l'SDLC, ci consente di individuare bug che richiederebbero molto più tempo per essere risolti dopo la spedizione del prodotto.
Ciò che è importante sono i tipi di test del software che scegliamo. Ce ne sono molti, inclusi test funzionali, strutturali e basati sul cambiamento.
Questo tutorial spiega anche i tipi di test strutturali. Scopri come eseguire test di mutazioni, test basati su sezioni, test del flusso di dati in dettaglio con esempi e spiegazioni.
Cosa imparerai:
- Perché il test del software è importante
- Che cos'è il test strutturale
- Tipi di test strutturali
- Vantaggi e svantaggi dei test strutturali
- Best practice per i test strutturali
- Conclusione
Perché il test del software è importante
Oltre a risparmiare denaro ed evitare disastri come i casi sopra menzionati, ci sono molti altri motivi per giustificare l'importanza dei test.
Di seguito sono elencati alcuni motivi:
# 1) Per garantire che i requisiti stipulati siano soddisfatti prima di iniziare a costruire un progetto. Le parti interessate (ad esempio, sviluppatori e clienti) devono concordare su tutti gli aspetti della soluzione / prodotto / software necessari per costruire un progetto.
Il test implica la verifica se i requisiti software sono soddisfatti. Lo sviluppatore o la società coinvolta nella creazione della soluzione si guadagnano anche una buona reputazione per la progettazione di una soluzione di alta qualità gestita da codice eclat.
programmi per monitorare cpu e gpu temp
# 2) Verifica che la funzione del codice funzioni come previsto. Il test comporta anche la verifica della funzionalità del software e, in caso di malfunzionamento, dovrebbe essere risolto durante le prime fasi dell'SDLC (Software Development Life Cycle).
# 3) Verifica le prestazioni: ad esempio, per identificare il tempo totale trascorso durante l'esecuzione del codice. Se usiamo diversi file Per loop nel nostro codice, ci vorrà molto tempo per ottenere l'output desiderato e talvolta può anche andare in timeout.
# 4) Aiuta a ottenere una migliore esperienza utente. Gli utenti non apprezzeranno l'utilizzo di software malfunzionante, difettoso o 'troppo lento'. Gli utenti probabilmente diventeranno impazienti e abbandoneranno l'uso del software. I test ci offrono una possibilità migliore per garantire che gli utenti possano utilizzare facilmente i nostri prodotti.
# 5) Verifica la scalabilità. Uno sviluppatore dovrebbe mirare a creare software che possa essere scalato.
# 6) Verifica la presenza di vulnerabilità nel codice. I test ci consentono di individuare le vulnerabilità della sicurezza, Per esempio, codice che potrebbe compromettere PII (Informazioni di identificazione personale) che è una priorità elevata per il GDPR.
In questo articolo, ci concentreremo su un tipo di test, ad es. Test strutturali . Come suggerisce il nome, ha a che fare con la struttura del codice. Questo è diverso da quello che abbiamo menzionato in precedenza che il test aiuta a determinare aspetti come le prestazioni del codice, la funzionalità e la sicurezza.
Test strutturali vs altri tipi di test
Esistono molti tipi di test del software. comunque, il FERMARE (International Software Testing Qualifications Board), definisce 4 principali tipi di test del software, vale a dire
- Funzionale
- Non funzionale
- Strutturale
- Basato sul cambiamento
Le differenze possono essere spiegate come di seguito:
Test funzionale: Ciò comporta la verifica della funzionalità del software rispetto ai requisiti stipulati. I dati del test vengono utilizzati come input. Controlliamo anche che l'output fornito sia quello previsto.
Test non funzionali : Ciò comporta un processo di test per analizzare come funziona il software, per esempio, il numero di utenti che può gestire contemporaneamente.
Test strutturali: Questo tipo di test si basa sulla struttura del codice. Per esempio, se un codice ha lo scopo di calcolare la media dei numeri pari in un array, i test basati sulla struttura sarebbero interessati ai 'passaggi che portano al calcolo della media', piuttosto che se l'output finale è un valore numerico corretto.
Supponiamo di dover verificare se abbiamo definito il codice che differenzia i numeri pari da quelli dispari. Potremmo avere un'istruzione condizionale qui, come, se un elemento dell'array è divisibile per due senza resto, if (arr (i)% 2 === 0) quindi il numero può essere detto come un numero pari.
I test strutturali vengono eseguiti dalle stesse persone che scrivono il codice nel modo in cui lo capiscono meglio.
Test basati sul cambiamento : Ciò implica il test degli effetti delle modifiche al codice e quindi la verifica che le modifiche apportate siano state implementate. Garantisce inoltre che le modifiche al codice non lo interrompano.
Cosa non sono i test strutturali
Abbiamo accennato in precedenza che il test basato sulla struttura si riferisce alla struttura del codice. Nota che qui ci occupiamo del codice effettivo. Non controlliamo i requisiti né testiamo gli input rispetto agli output previsti. A questo punto non ci occupiamo di funzionalità, esperienza utente o prestazioni.
Che cos'è il test strutturale
Il test basato sulla struttura, quindi, può essere definito come un tipo di test del software che verifica la struttura del codice e i flussi previsti. Per esempio, verificare il codice effettivo per aspetti come la corretta implementazione delle istruzioni condizionali e se ogni istruzione nel codice viene eseguita correttamente. È anche noto come test basato sulla struttura.
Per eseguire questo tipo di test, è necessario comprendere a fondo il codice. Questo è il motivo per cui questo test viene solitamente eseguito dagli sviluppatori che hanno scritto il codice nel modo in cui lo capiscono meglio.
Come eseguire i test strutturali
Per testare diversi aspetti del codice, dobbiamo prima comprendere i flussi di controllo.
Controllo del flusso di prova
Si tratta di derivare test dai flussi di controllo del codice (l'ordine in cui vengono implementate le istruzioni, le funzioni e i diversi aspetti del codice).
Processo di verifica del flusso di controllo:
Grafico del flusso di controllo
Il processo del flusso di controllo inizia con la creazione di una rappresentazione visiva di diverse sezioni del codice che ci aiuta a definire i percorsi che possono essere seguiti durante l'esecuzione.
Queste rappresentazioni visive sono note come Control Flow Graphs (CFG) e hanno diversi componenti come nodi, bordi, percorsi, giunzioni e punti di decisione. Il grafico può essere creato manualmente o automaticamente, dove il software viene utilizzato per estrarre il grafico dal codice sorgente.
Diamo un'occhiata a questi componenti di seguito:
# 1) Blocco di processo
Questa parte viene utilizzata per rappresentare una sezione di codice che viene eseguita in modo sequenziale. Ciò significa che viene eseguito allo stesso modo ogni volta e non ci sono decisioni o 'ramificazioni' che devono essere prese. È costituito da nodi con un percorso di entrata e di uscita.
Esempio di un blocco di processo:
(Immagine fonte )
Il blocco del processo non è una parte essenziale del flusso di controllo e, di conseguenza, deve essere testato una sola volta.
# 2) Punti decisionali
Questi sono alcuni componenti chiave nel flusso di controllo del codice. All'interno di questi nodi vengono prese le decisioni. Questo di solito viene fatto tramite confronto e il flusso di controllo cambia, a seconda della decisione. Questa parte del CFG è composta da un nodo con almeno 2 uscite.
La decisione presa qui potrebbe essere istruzioni condizionali come istruzioni if-else (che hanno due possibili output) e istruzioni case (che possono avere più di due output).
(Immagine fonte )
Nel diagramma sopra, c'è un punto di decisione (dal condizionale 'età = 18') che è seguito dalle opzioni 'sì' o 'no'.
# 3) Punti di giunzione
Dal diagramma sopra, possiamo facilmente identificare i punti di giunzione rispetto al punto in cui i punti di decisione si uniscono. I punti di giunzione possono avere molti percorsi di ingresso ma possono avere un solo percorso di uscita.
Best practice per i grafici di flusso di controllo:
Ci sono alcune cose da notare quando si costruiscono i grafici del flusso di controllo:
- Cerca il più possibile di mantenere semplice il CFG. Possiamo farlo combinando parti che possono essere considerate 'meno significative', per esempio, blocchi di processo.
- Assicurati che nei punti di decisione venga presa una sola decisione. Nei CFG più complessi, ci sono 'conseguenze' che vengono dopo che la decisione è stata presa. Nel nostro esempio sopra, potremmo anche aggiungere che se un individuo ha 18 anni o più, è idoneo e deve pagare un biglietto. Se non lo sono, l'ingresso è gratuito. La decisione 'altro' deve 'saltare' alcuni nodi e tutti questi passaggi devono essere mostrati nel nostro CFG.
Una volta definito il nostro CFG, è ora il momento di passare alla fase successiva del processo di test del flusso di controllo, ovvero definire la misura in cui testeremo il codice.
Definizione di quanto testare:
Quanto del codice sorgente dovrebbe essere testato? Dovremmo testare ogni possibile percorso? Cercare di coprire tutti i percorsi nei nostri test è praticamente impossibile. Dobbiamo trovare una via di mezzo per determinare quanti test possiamo fare.
Se diciamo che miriamo a testare il 50% del nostro codice, ciò potrebbe significare che definiremo tutte le istruzioni del codice eseguibile e mireremo a testarne almeno la metà. Tuttavia, la domanda che sorge qui è 'dobbiamo quindi definire tutti i possibili percorsi eseguibili?'
Anche in questo caso potrebbe essere praticamente impossibile. Un approccio migliore potrebbe mirare a testare il 50% dei percorsi che possiamo identificare in ogni sezione del codice.
Esistono diversi livelli di copertura, vale a dire copertura per estratto conto, filiale e percorso. Li esamineremo brevemente più tardi.
Creazione di casi di test:
Il passaggio successivo è creare i casi di test che useremo. I casi di test nei test basati sulla struttura si basano sui seguenti fattori:
- Le istruzioni eseguibili.
- Le 'decisioni' che devono essere prese.
- I possibili percorsi che si possono seguire.
- Le condizioni che devono essere soddisfatte (possono essere multiple o booleane).
I fattori di cui sopra ci danno un'idea dei tipi di casi di test che dobbiamo creare. Possiamo anche utilizzare uno strumento di generazione di test strutturali. Se il nostro codice è nel linguaggio di programmazione C, possiamo utilizzare PathCrawler per generare codice di test. Un altro strumento che possiamo usare è fMBT.
Esecuzione dei casi di test:
Qui, possiamo eseguire i test. Possiamo inserire input o dati per controllare come il codice lo esegue e quindi verificare se otteniamo i risultati attesi. Per esempio, immettere un array in una chiamata di funzione per osservare i risultati che otteniamo dopo averlo eseguito in loop o per verificare se i punti decisionali stanno prendendo le decisioni corrette.
Analizzando i risultati:
In questa parte, tutto ciò che facciamo è verificare se otteniamo i risultati corretti dopo l'esecuzione. Per esempio, se inseriamo un array in cui tutti i valori sono superiori a 18, dovremmo avere tutti i punti di decisione risultanti 'idonei'.
download gratuito del software tracker indirizzo ip
Presupposti del flusso di controllo
È importante notare che per eseguire il test del flusso di controllo, ci sono alcune ipotesi che vengono fatte. Questi includono:
- Gli unici bug presenti sono quelli che possono influenzare il flusso di controllo.
- Tutte le variabili, le funzioni e gli elementi sono definiti accuratamente.
Livelli di copertura nei flussi di controllo
Come accennato in precedenza, ci sono diversi livelli di copertura nei test del flusso di controllo.
Vediamoli brevemente.
# 1) Copertura della dichiarazione
Nei test strutturali, le istruzioni del codice eseguibile svolgono un ruolo vitale quando si tratta di decidere i metodi di progettazione dei test.
Miriamo a raggiungere una copertura del 100%, il che significa che ogni istruzione eseguibile è stata testata almeno una volta. Maggiore è la copertura, minore è la probabilità di perdere bug ed errori.
È necessario utilizzare i casi di test qui. I dati di cui abbiamo bisogno sono per garantire che ogni istruzione eseguibile in un blocco di codice venga eseguita almeno una volta.
# 2) Copertura delle filiali
Questo livello di copertura prevede il test dei punti nelle filiali CFG (dove vengono prese le decisioni). I risultati sono booleani. Anche se viene utilizzata un'istruzione switch e ci sono più risultati, in sostanza, ogni blocco case è un confronto di una coppia di valori.
Proprio come con la copertura delle dichiarazioni, dovremmo mirare a una copertura del 100% delle filiali. Per raggiungere questo obiettivo, dobbiamo testare ogni risultato a ogni livello decisionale almeno una volta. Dato che abbiamo a che fare con risultati booleani, dovremmo mirare a eseguire almeno 2 test per sezione di codice.
# 3) Copertura del percorso
Questo livello di copertura è più completo rispetto alla copertura delle decisioni e delle dichiarazioni. L'obiettivo qui è quello di 'scoprire' tutti i percorsi possibili e testarli almeno una volta. Questo può richiedere molto tempo. Può, tuttavia, aiutare a scoprire bug o errori nel nostro codice, o anche aspetti che dobbiamo definire, per esempio, input dell'utente.
Tipi di test strutturali
(Immagine fonte )
Test di mutazione
Il test di mutazione è una tecnica di test basata su errori in cui vengono testate varie varianti di un'applicazione software rispetto al set di dati di test.
>> Fare riferimento a questo tutorial per uno sguardo approfondito Test di mutazione.
Test basato su sezioni
Slice Based Testing (SBT) può essere definito come una tecnica di test del software basata su fette - parti eseguibili del programma o gruppi di istruzioni che influenzano alcuni valori in particolari punti di interesse nel programma, per esempio, parti in cui vengono definite le variabili o l'output di un gruppo di istruzioni.
Come fare affettare
Esempio di affettatura in SBT: Codice per stampare numeri pari e dispari (Python)
num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}') 
Esistono due modi per esaminare una sezione: Seguendo il percorso di una variabile di interesse o la parte di codice che interessa l'output.
Nel nostro esempio, se guardiamo l'output dei numeri dispari, possiamo tracciare la parte di codice che ci conduce a questo output.
Nei criteri di slicing forniti da Mark Weiser (che ha introdotto SBT), una slice viene definita utilizzando questa formula: S (v, n) , dove, v si riferisce alla variabile in questione ( per esempio, dove è definita una variabile) e n è la dichiarazione di interesse ( per esempio, dove viene fornito l'output) e S sta per la fetta.
Nell'esempio sopra, per ottenere lo slice, partiamo dal nostro output sulla riga 10, che diventa il nostro n . La nostra variabile è dove .
Quindi i nostri criteri di affettatura sono:
S(v,n) = S(var,10)La nostra preoccupazione sono le dichiarazioni che ci portano all'output.
Questi sono:
10,9,8,4,3,1
Quindi, la nostra fetta in questo codice è:
num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Tipi di test basati su sezioni
Esistono due tipi di SBT: statico e dinamico
# 1) Test dinamico basato su slice
L'esempio SBT spiegato sopra in cui abbiamo esaminato le dichiarazioni che influenzano la stampa dei numeri dispari è SBT dinamico. La nostra preoccupazione è molto specifica. Ci concentriamo solo su ciò che influenza direttamente il particolare output.
Eseguiamo il codice e utilizziamo i dati di test per assicurarci che funzioni come dovrebbe. Potremmo aumentare l'intervallo a (1,50), per esempio, per vedere se genera ancora solo numeri dispari. L'SBT dinamico è anche noto come test di convalida.
# 2) StaticoTest basato su sezioni
A differenza di Dynamic SBT, il focus del test statico è su una particolare variabile. Se pensiamo al nostro output nell'esempio precedente come dove , possiamo tracciare la fetta che la interessa come 10,9,8,7,6,5,4,3,2,1
È fondamentalmente l'intero blocco di codice! Qui verifichiamo che il codice sia corretto in termini di sintassi e requisiti e non lo eseguiamo. Static SBT è anche noto come test di verifica.
È importante notare che SBT dinamico è 'più piccolo' rispetto alla sua controparte statica. È anche più specifico.
Best practice / linee guida per i test basati su sezioni
I criteri di taglio dovrebbero essere determinati da:
- Dichiarazioni in cui vengono definiti valori o valore assegnato, nonché valore riassegnato.
- Dichiarazioni in cui i valori vengono ricevuti dall'esterno del programma, per esempio, tramite input dell'utente.
- Dichiarazioni che stampano output / restituiscono output.
- L'ultima dichiarazione del programma, per esempio, una chiamata di funzione che può definire valori o fornire valori agli argomenti
I vantaggi del test basato su slice includono:
- Poiché in SBT lavoriamo solo con specifiche aree di interesse, è più facile generare efficacemente suite di test.
- Il percorso è definito dalle dipendenze all'interno del codice, che è meglio dell'utilizzo copertura del percorso.
- Con SBT, è più facile trovare errori nel codice sorgente.
Gli svantaggi del test basato su slice includono:
- Se usiamo il test dinamico durante il test di una grande base di codice, avremo bisogno di molte risorse di calcolo.
- Se utilizziamo test statici, potremmo perdere gli errori.
Test del flusso di dati
Il test del flusso di dati può essere definito come una tecnica di test del software basata sui valori dei dati e sul loro utilizzo in un programma. Verifica che i valori dei dati siano stati utilizzati correttamente e che generino i risultati corretti. Il test del flusso di dati aiuta a tracciare le dipendenze tra i valori dei dati su un particolare percorso di esecuzione.
Anomalie del flusso di dati
Le anomalie del flusso di dati sono semplicemente errori in un programma software. Sono classificati rispettivamente nei tipi 1, 2 e 3.
Analizziamoli di seguito:
Tipo 1: Viene definita una variabile e le viene assegnato un valore due volte.
Codice di esempio: Python
lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var) 
Lst_1 è definito e gli vengono assegnati due valori diversi. Il primo valore viene semplicemente ignorato. Le anomalie di tipo 1 non causano il fallimento del programma.
Tipo 2: Il valore di una variabile viene utilizzato o referenziato prima di essere definito.
Codice di esempio: Python
for var in lst_1: print(var) 
Il ciclo precedente non ha valori su cui iterare. Le anomalie di tipo 2 causano il fallimento del programma.
Tipo 3: A il valore dei dati viene generato, ma non viene mai utilizzato.
Codice di esempio: Python
lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var) 
La variabile lst_2 non è stato referenziato. Le anomalie di tipo 3 potrebbero non causare errori del programma.
Processo di test del flusso di dati
Per definire le dipendenze tra i valori dei dati, è necessario definire i diversi percorsi che possono essere seguiti in un programma. Per fare ciò in modo efficace, dobbiamo prendere in prestito da un altro tipo di test strutturale noto come test del flusso di controllo .
Passo 1) Disegna un grafico del flusso di controllo
Dobbiamo disegnare un grafico del flusso di controllo, che è una rappresentazione grafica dei percorsi che potremmo seguire nel nostro programma.
Codice di esempio: Python
cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill) 
Nell'esempio di codice sopra, un membro dovrebbe ottenere uno sconto se invita un visitatore.
Grafico del flusso di controllo (CFG):
Passo 2) Esplora la definizione e l'utilizzo delle variabili e dei valori dei dati.
Una variabile in un programma viene definita o utilizzata. In CFG, abbiamo variabili in ogni nodo. Ogni nodo è denominato in base al tipo di variabile che ospita. Se una variabile è definita in un particolare nodo, crea un nodo di definizione. Se una variabile viene utilizzata in un nodo, crea un nodo di utilizzo.
Se consideriamo il costo variabile in CFG, questi sono i nodi di definizione e utilizzo:
| Nodo | genere | Codice |
|---|---|---|
| 1 | Definizione del nodo | costo = 20 |
| 5 | Nodo di utilizzo | fattura = costo -1 |
| 7 | Nodo di utilizzo | fattura = costo |
Passaggio 3) Definire percorsi di utilizzo delle definizioni.
Esistono due tipi di percorsi di utilizzo delle definizioni: du percorsi e percorsi dc. du percorsi sono percorsi di definizione che iniziano con un nodo di definizione e terminano con un nodo di utilizzo. Questo è il caso del percorso in riferimento al costo variabile di cui sopra.
Un esempio di un percorso dc, un percorso decisionale chiaro, è il percorso relativo alla variabile bill come di seguito:
| Nodo | genere | Codice |
|---|---|---|
| 5 | Definizione del nodo | fattura = costo -1 |
| 7 | Definizione del nodo | fattura = costo |
| 8 | Nodo di utilizzo | stampa (fattura) |
dc path ha più di un nodo di definizione anche se termina ancora in un nodo di utilizzo.
Passaggio 4) Crea la suite di test.
Questo sta aggiungendo input. Nota che abbiamo bisogno di una suite di test diversa per ogni variabile. La suite di test ci aiuterà a identificare le anomalie del flusso di dati.
Tipi di test del flusso di dati
Esistono due tipi: Statico e dinamico .
Statico significa che esaminiamo il codice e il CFG per identificare le anomalie dei dati, senza eseguirlo. Dinamico significa che identifichiamo effettivamente i percorsi specifici e quindi creiamo suite di test per testarli nel tentativo di 'rilevare' le anomalie che potremmo aver perso durante i test statici.
Vantaggi e svantaggi del test del flusso di dati:
- Il test del flusso di dati è ideale per identificare le anomalie del flusso di dati, il che lo rende un metodo di test strutturale molto efficace.
- Il suo svantaggio è che è necessario conoscere bene il linguaggio utilizzato per scrivere il codice per utilizzare il test del flusso di dati. Inoltre richiede molto tempo.
Vantaggi e svantaggi dei test strutturali
Cerchiamo ora di scoprire i motivi per cui i test strutturali sono un ottimo approccio ed esplorare anche alcuni dei suoi aspetti negativi.
Vantaggi:
- Consente un test approfondito del codice, con il risultato di errori minimi. I test basati sulla struttura offrono spazio per testare a fondo il software. I diversi livelli di copertura - dichiarazione per dichiarazione, ogni punto decisionale e percorso mirano a raggiungere una copertura del 100%, il che riduce notevolmente le possibilità che gli errori non vengano rilevati.
- La capacità di automatizzare . Esistono diversi strumenti che possiamo utilizzare per automatizzare i test. Questo ci aiuterà a ottenere la massima copertura del codice e in tempi più brevi rispetto all'esecuzione manuale dei test.
- Il risultato è un codice di qualità superiore . Gli sviluppatori hanno la possibilità di studiare la struttura e l'implementazione del codice e correggere eventuali errori, oltre a migliorare questi aspetti. Ci consente di tenere a mente la grande struttura mentre scriviamo parti di codice successive o implementiamo le funzionalità rimanenti.
- Può essere eseguito in ogni fase dell'SDLC - È possibile eseguire test strutturali in ciascuna fase dell'SDLC senza attendere il completamento dello sviluppo al 100%. Ciò semplifica l'identificazione degli errori nella fase iniziale e consente quindi di risparmiare molto tempo rispetto al test dopo il completamento dello sviluppo.
- Aiuta a sbarazzarsi del codice morto . Questo può essere visto come un codice 'extra' o non necessario, per esempio, codice che calcolerà un risultato ma non lo utilizzerà mai in nessuno dei seguenti calcoli.
- Efficienza - Poiché gli sviluppatori che scrivono il codice sono gli stessi che lo testano, non è necessario coinvolgere altre persone come i QA.
Svantaggi:
- Gli sviluppatori che eseguono test basati sulla struttura devono avere una conoscenza approfondita del linguaggio . Altri sviluppatori e QA che non sono esperti nella lingua non possono aiutare con i test.
- Può diventare piuttosto costoso in termini di tempo e denaro . Sono necessari molto tempo e risorse per eseguire i test in modo efficiente.
- Causa ritardi nella consegna delle funzionalità . Questo perché gli sviluppatori sono trascinati dalla creazione di software per eseguire test.
- Il ridimensionamento è un problema, soprattutto quando sono coinvolte applicazioni di grandi dimensioni . Una vasta applicazione equivale a un numero eccessivamente elevato di rotte da coprire. Raggiungere il 100% di copertura diventa impossibile.
- Potrebbero mancare casi e percorsi , per esempio, in un caso in cui le funzionalità non sono completamente sviluppate o devono ancora essere sviluppate. Ciò significa che deve essere combinato con altri tipi di test come il test dei requisiti (dove controlliamo le funzionalità specificate che dovevano essere costruite).
Best practice per i test strutturali
Alcuni dei fattori che richiedono attenzione durante l'esecuzione di test basati sulla struttura sono i seguenti:
- Etichettare e denominare chiaramente i test . Se qualcun altro ha bisogno di eseguire i test, deve essere in grado di individuarli facilmente.
- Prima di migliorare il codice, ad esempio rifattorizzandolo e ottimizzandolo per l'uso in ambienti diversi, assicurarsi che la sua struttura e il suo flusso siano ideali.
- Eseguire i test separatamente . In questo modo, è facile identificare i bug e risolverli. D'altra parte, è meno probabile che perdiamo bug o percorsi a causa di sovrapposizioni in sezioni di codice, blocchi o percorsi.
- Genera test prima di apportare modifiche . I test devono essere eseguiti come previsto. In questo modo, se qualcosa si rompe, è facile rintracciare e risolvere il problema.
- Tenere separati i test per ciascuna sezione o blocco di codice . In questo modo, se ci sono cambiamenti lungo la linea, non abbiamo bisogno di cambiare molti test.
- Risolvi i bug prima di procedere con i test . Se identifichiamo dei bug, è meglio risolverli prima di procedere al test della sezione o del blocco di codice successivo.
- Non saltare mai i test strutturali partendo dal presupposto che un QA 'eseguirà comunque i test comunque'. Anche se all'inizio i bug possono sembrare insignificanti, cumulativamente, possono risultare in codice difettoso che non può mai raggiungere lo scopo previsto.
Domande frequenti per i test basati sulla struttura
Qui esploreremo le domande frequenti quando si tratta di test basati sulla struttura.
D # 1) Qual è la differenza tra test funzionali e test strutturali?
Risposta: Il test funzionale è un tipo di test del software basato sui requisiti stipulati nelle SRS (Specifiche dei requisiti software). Di solito viene fatto nel tentativo di trovare disparità tra le specifiche nell'SRS e il funzionamento del codice. I test strutturali si basano sulla struttura interna del codice e sulla sua implementazione. È necessaria una conoscenza approfondita del codice.
Q # 2) Quali sono i tipi di test strutturali?
matrice di ordinamento bolla c ++
Rispondi al i tipi includono:
- Test del flusso di dati
- Test di mutazione
- Controllo del flusso di prova
- Test basati su slice
D # 3) Che cos'è un esempio di test strutturale?
Risposta: Ecco un esempio che mostra la copertura delle dichiarazioni:
const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums(); La quantità di copertura che otteniamo dipende dai dati di test che forniamo come input (se soddisfa le condizioni di somma> 0).
Q # 4) Qual è la differenza tra il test del flusso di dati e il test del flusso di controllo?
Risposta: Sia il test del flusso di dati che il test del flusso di controllo utilizzano grafici del flusso di controllo. L'unica differenza è che nel test del flusso di controllo, ci concentriamo sui percorsi generati dal codice, mentre nel test del flusso di dati, ci concentriamo sui valori dei dati, sulla loro definizione e sull'utilizzo all'interno dei percorsi identificati all'interno di un programma.
D # 5) A cosa serve il test del flusso di dati?
Risposta: Il test del flusso di dati è ideale per identificare anomalie nell'utilizzo dei valori dei dati all'interno dei percorsi in un grafico del flusso di controllo, per esempio, una variabile a cui è stato assegnato un valore due volte, una variabile che è stata definita e non utilizzata o una variabile che è stata utilizzata o referenziata e non definita.
Q # 6) Qual è la differenza tra affettare e sminuzzare nei test del software?
Risposta: Affettare significa concentrarsi su particolari dichiarazioni di interesse in un programma e ignorare il resto. Il Dicing è quando identifichiamo una fetta che sta avendo un input sbagliato e poi la affettiamo ulteriormente per tracciare il comportamento corretto.
D # 7) Qual è la differenza tra il test di mutazione e la copertura del codice?
Risposta: Nel test di mutazione, consideriamo il numero di mutanti uccisi come percentuale dei mutanti totali. La copertura del codice è semplicemente la quantità di codice che è stata testata in un programma.
Conclusione
In questo tutorial abbiamo esaminato in modo approfondito i test strutturali: cos'è, cosa non è, come procedere, tipi di copertura, vantaggi e svantaggi, best practice e persino alcune domande frequenti relative a questo tipo di test del software.
C'è ancora molto di più che possiamo imparare sui test basati sulla struttura. Nelle esercitazioni future esploreremo la copertura del codice (istruzione, decisione, ramo e percorso), i tipi di test strutturali (mutazione, flusso di dati e basati su sezioni) e persino gli strumenti che possiamo utilizzare per automatizzare questi processi di test.
È importante notare che non esiste un tipo o un approccio di test del software efficiente al 100%. È sempre consigliabile combinare diversi tipi e approcci di test.
Per esempio, i test strutturali sono ampiamente integrati dai test dei requisiti, in quanto potrebbero esserci caratteristiche che potrebbero non essere state sviluppate al momento in cui venivano eseguiti i test basati sulla struttura.
Le tecniche di test strutturale si basano sugli errori che i programmatori umani commettono durante la scrittura del codice. Il presupposto è che il programmatore sia un esperto e sappia cosa sta codificando, ma di tanto in tanto sbaglia.
I diversi tipi di test strutturali che abbiamo esaminato: test di mutazione, test basato su sezioni e test del flusso di dati potrebbero essere ricondotti a errori come l'utilizzo dell'operatore sbagliato (test di mutazione) o il riferimento a una variabile prima di utilizzarlo (test del flusso di dati) .
Lettura consigliata
- Tutorial sui test distruttivi e non distruttivi
- Test funzionale vs test non funzionale
- Che cos'è la tecnica di test basata sui difetti?
- Tutorial sul Soak Test - Cos'è il Soak Test
- Esercitazione sul test SOA: metodologia di test per un modello di architettura SOA
- Test di carico con HP LoadRunner Tutorial
- Cos'è il Gamma Testing? La fase finale del test
- Tutorial sul test DevOps: in che modo DevOps influirà sui test di controllo qualità?
- Che cos'è il test di conformità (test di conformità)?