<\/span><\/h3>\n <\/p>\n
I test statici e dinamici sono due approcci diversi alla verifica del software, con punti di forza, debolezze e utilit\u00e0 proprie. La scelta diretta tra l’uno e l’altro non \u00e8 uno scenario realistico, perch\u00e9 hanno funzioni diverse.<\/p>\n
I test statici servono a essere proattivi e a identificare i problemi il pi\u00f9 presto possibile. Si tratta di trovare e risolvere i problemi prima che inizino.<\/p>\n
I test dinamici sono pi\u00f9 reattivi, in quanto cercano i bug eseguendo il codice. S\u00ec, in generale, richiede pi\u00f9 tempo e risorse rispetto ai test statici. Tuttavia, trova difetti che altrimenti non verrebbero scoperti dai soli test statici.<\/p>\n
La vera risposta \u00e8 che, utilizzando insieme test statici e dinamici, \u00e8 possibile garantire che il codice e i relativi documenti siano all’altezza e che il software sia in linea con le aspettative degli stakeholder.<\/p>\n
<\/p>\n
<\/span>Cosa viene testato durante i test statici?<\/strong><\/span><\/h2>\n![\"Diversi](\"https:\/\/www.zaptest.com\/wp-content\/uploads\/2023\/09\/api-testing-1-jpg.webp\")
<\/p>\n
I test statici esaminano la progettazione, il codice e i documenti che compongono il progetto. Vediamo quali sono gli aspetti che i tester devono tenere d’occhio per garantire un approccio completo ai test statici.<\/p>\n
<\/span>1. Revisione della documentazione<\/strong><\/span><\/h3>\nUna delle prime parti del test statico prevede un esame approfondito della documentazione. Ecco alcuni dei documenti che passano al microscopio.<\/p>\n
<\/span>Documenti sui requisiti aziendali<\/strong><\/span><\/h4>\nI tester esamineranno il documento dei requisiti di business e si assicureranno che questi catturino fedelmente le esigenze degli stakeholder e si allineino agli obiettivi aziendali.<\/p>\n
<\/span>Specifiche dei requisiti software (SRS)<\/strong><\/span><\/h4>\nLe specifiche dei requisiti del software (SRS) delineano la funzione e l’utilit\u00e0 del software. Il test statico esegue la regola su questo documento e si assicura che descriva accuratamente la funzionalit\u00e0 del software, comprese le dipendenze e le interfacce utente.<\/p>\n
<\/span>Documenti di progettazione<\/strong><\/span><\/h4>\nAnche i documenti di progetto vengono esaminati per garantire la conformit\u00e0 ai requisiti e alle specifiche. I tester controllano il linguaggio di modellazione unificato (UML), il flusso di dati e i diagrammi architettonici per verificare che corrispondano ai requisiti del progetto.<\/p>\n
<\/span>Documenti sui casi d’uso e storie degli utenti<\/strong><\/span><\/h4>\nI test statici esaminano anche i documenti dei casi e le storie degli utenti per vedere come corrispondono agli aspetti funzionali e non funzionali del software. Questi documenti delineano i percorsi felici (uso previsto con successo), i flussi alternativi, i casi limite e i potenziali errori.<\/p>\n
<\/span>Casi di test<\/strong><\/span><\/h4>\nQuesta fase iniziale di test \u00e8 un’opportunit\u00e0 per esaminare i casi di test per assicurarsi che abbiano una copertura adeguata, risorse, tecniche appropriate, programmi realistici e cos\u00ec via. Inoltre, le revisioni esamineranno anche se i risultati dei casi di test sono dettagliati e realistici.<\/p>\n
<\/p>\n
<\/span>2. Revisione del codice<\/strong><\/span><\/h3>\nSuccessivamente, verr\u00e0 esaminato il codice utilizzato per l’applicazione. Ecco alcune delle aree che i team di collaudo esamineranno.<\/p>\n
<\/span>Errori di sintassi<\/strong><\/span><\/h4>\nI tester e gli sviluppatori esaminano il codice alla ricerca di errori di sintassi, refusi, nomi di variabili errati, punteggiatura mancante e qualsiasi errore, piccolo o grande, che possa causare errori quando il codice viene eseguito.<\/p>\n
<\/span>Codice morto<\/strong><\/span><\/h4>\nIl codice morto, detto anche codice irraggiungibile, \u00e8 una parte del codice sorgente di un programma che non pu\u00f2 essere eseguita a causa di problemi nel percorso del flusso di controllo.<\/p>\n
<\/span>Variabili non utilizzate<\/strong><\/span><\/h4>\nI test statici controllano anche le variabili non utilizzate, che sono dichiarate ma mai effettivamente eseguite dal compilatore.<\/p>\n
<\/span>Violazione degli standard di codifica<\/strong><\/span><\/h4>\nGli standard di codifica si riferiscono a un insieme di buone pratiche, regole e linee guida per la codifica in un particolare linguaggio. I test statici assicurano il rispetto delle best practice e rendono pi\u00f9 facile per gli altri modificare, correggere e aggiornare il codice.<\/p>\n
<\/span>Difetti di logica<\/strong><\/span><\/h4>\nI difetti di logica possono significare che il codice sorgente funziona in modo errato ma non si blocca. Le revisioni statiche cercano di identificare e risolvere questi problemi prima di eseguire il codice.<\/p>\n
<\/span>Flussi di dati<\/strong><\/span><\/h4>\nI tester esaminano anche il modo in cui i dati entrano ed escono dal sistema. Questa revisione riguarda tutte le interazioni che i dati avranno all’interno del software.<\/p>\n
<\/span>Flussi di controllo<\/strong><\/span><\/h4>\nUn’altra area in esame \u00e8 il flusso di controllo. Questa revisione esamina l’ordine di esecuzione delle istruzioni del codice e garantisce che le cose vengano eseguite nell’ordine giusto per assicurare che il software si comporti come previsto.<\/p>\n
<\/span>Vulnerabilit\u00e0 della sicurezza<\/strong><\/span><\/h4>\nI test statici esplorano anche eventuali vulnerabilit\u00e0 di sicurezza nel codice sorgente.<\/p>\n
<\/p>\n
<\/span>Tecniche statiche di test del software<\/strong><\/span><\/h2>\n![\"benefici](\"https:\/\/www.zaptest.com\/wp-content\/uploads\/2023\/09\/pexels-thisisengineering-3862619-jpg.webp\")
<\/p>\n
Ora che sapete quali sono le cose che vengono esaminate nell’ambito dei test statici, \u00e8 il momento di vedere come vengono eseguiti questi esami.<\/p>\n
Ci sono due tecniche principali di test statico nel test del software che \u00e8 necessario conoscere per implementare un test del software completo. Si tratta del processo di revisione e dell’analisi statica.<\/p>\n
<\/p>\n
<\/span>1. Il processo di revisione nelle prove statiche<\/strong><\/span><\/h3>\nIl processo di revisione \u00e8 la prima parte dell’implementazione delle tecniche statiche nel test del software. L’idea \u00e8 quella di trovare e rimuovere gli errori dalla progettazione del software. In genere, il processo di revisione dei test statici si articola in quattro fasi principali.<\/p>\n
<\/span>Revisione informale<\/strong><\/span><\/h4>\nUna revisione informale \u00e8 proprio quello che sembra: una tavola rotonda di brainstorming non strutturata in cui sviluppatori, tester e stakeholder possono esplorare i potenziali problemi e proporre domande e suggerimenti sul software. \u00c8 un’opportunit\u00e0 per identificare eventuali difetti o problemi prima di passare alle fasi successive.<\/p>\n
<\/span>Passaggi a piedi<\/strong><\/span><\/h4>\nI walkthrough sono un’occasione per i team di test di andare pi\u00f9 a fondo. Spesso, si tratta di uno o pi\u00f9 esperti del settore che esaminano la documentazione per assicurarsi che tutto corrisponda ai requisiti aziendali e di sistema.<\/p>\n
<\/span>Revisione tra pari<\/strong><\/span><\/h4>\nQuesta fase successiva prevede che gli ingegneri esaminino il codice sorgente dell’altro per vedere se riescono a individuare gli errori che devono essere corretti prima che il software venga eseguito.<\/p>\n
<\/span>Ispezione<\/strong><\/span><\/h4>\n