Collaudo del software: differenze tra le versioni

Versione delle 23:06, 20 dic 2024

Versione attuale delle 08:35, 2 ago 2025

(7 versioni intermedie di 6 utenti non mostrate)

Riga 23:

=== Verifica e validazione ===

La fase di '''verifica''' e di '''validazione''' serve ad accertare che il [[software]] rispecchiottemperi iagli requisiti e che li rispetti nella maniera dovutaobiettivi.

Precisamente:

* la '''verifica''' serve a stabilire che il software rispetti i requisiti e le specifiche, quindi ad esempio che non ci siano requisiti mancanti o che le diverse prove (esecuzione, moduli/parti del sistema, unità, integrazione, etc) abbiano esito positivo, La verifica può essere eseguita in diverse sotto fasi o riguardare specifici aspetti (categorie di funzioni, sicurezza, architettura, ingegnerizzazione del sistema, prestazioni); spesso si esegue la verifica X per poter procedere alla successiva sottofase X+1; esistono test di verifica della progettazione (analisi funzionale) e altre più propriamente di sviluppo;

* mentreinvece, la '''validazione''' serve ad accertare che i requisiti siano anche rispettati nella maniera giusta cioè secondo criteri di utilizzo (secondo i bisogni e le atteseaspettative dell'utente) siano anche soddisfatti nella maniera giusta. Il collaudo per antonomasia è quello finale, eseguito in condizioni che simulino il reale impiego applicativo. La validazione (validare = convalidare, rendere valido) segue sempre la verifica.

Questa fase, infatti, è molto delicata in quanto, se il software passa la verifica, ma non la validazione, dopo tutto il processo si può ottenere un [[software]] perfettamente funzionante, senza errori, ma del tutto inutile in quanto non rispecchia quanto era stato chiesto all'inizio (in tal caso non adempiendo all'insieme completo delle funzionalità previste e quindi non servendo allo scopo di progetto, può esserci il rischio che venga rigettato dal cliente). Oltre alla funzioni (tra cui quelle di sicurezza, sempre più rilevanti e spesso date per scontate), la validazione deve accertare anche il raggiungimento dei livelli prestazionionali (in pratica, la velocità di esecuzione e l'efficienza del sistema).

Secondo il modello applicato questa fase si applica su stadi intermedi o su tutto il sistema software (ivi compresa l'ingegnerizzazione della piattaforma SW/HW quando prevista cioè l'ambiente in cui il software verrà eseguito e fruito). La verifica può essere ''statica'', se effettuata su carta, cioè sul progetto, o ''dinamica'', se effettuata attraverso il [[collaudo]] dello stesso software con dati di test.

La verifica può essere ''statica'', se effettuata su carta, cioè sul progetto, o ''dinamica'', se effettuata attraverso il [[collaudo]] dello stesso software con dati di test.

== Modello di sviluppo ==

Riga 129 ⟶ 127:

=== Il collaudo a scatola nera ===

Il collaudo effettuato accedendo al software solamente tramite l'interfaccia utente, oppure tramite interfacce di [[comunicazione tra processi]], viene detto "collaudo a scatola nera" (in inglese, "black box testing").

Può essere manuale oppure automatizzato, e tipicamente è utilizzato per il collaudo di sistema, in quanto per collaudare l'intero sistema normalmente non è necessario richiamare singole routine.

Riga 161 ⟶ 159:

Il programmatore, appena dopo aver apportato una modifica al software, manda in esecuzione il software modificato e verifica interattivamente se il funzionamento è quello atteso. Se il comportamento è insoddisfacente, apporta altre modifiche e reitera il procedimento.

Quando il programmatore è soddisfatto del comportamento del software, invia il software al suo superiore, che effettua un ulteriore rapido collaudo manuale. A questo punto, se non si tratta di modifiche che devono urgentemente essere rese operative, la nuova versione viene inviata agli utenti e al personale di assistenza ("[[help desk]]") come versione Beta. Gli utenti e il personale vengono addestrati alle nuove modifiche, e tale addestramento costituisce l'occasione per la rilevazione di ulteriori malfunzionamenti.

In tale procedimento informale di collaudo, la segnalazione di malfunzionamenti e di nuove versioni non segue un iter ben definito. Si usano comunicazioni di persona, telefoniche, e-mail, e appunti su biglietti.

Riga 202 ⟶ 200:

Solitamente, si definiscono per vari tipi di operazioni dei tempi massimi di esecuzione (ovvero, si definiscono delle "baseline") e si verifica che il prodotto software non superi tali tempi limite. Con l'evolvere dei software e dell'hardware, anche le baseline possono venire modificate. Per esempio, se il software viene sviluppato adottando una libreria meno efficiente, si ammette che le varie operazioni possano essere un po' più lente; d'altra parte, se il collaudo viene fatto su un sistema multiprocessore, si richiede che, a parità di velocità dei processore, le varie operazioni debbano essere più veloci. Le baseline possono essere semplicemente ottenute misurando i tempi di esecuzione di un sistema esistente. Da un punto di vista di test, queste attività sono tutte del tipo white-box, dove il sistema è ispezionato e controllato "dall'interno verso l'esterno" e da vari angoli. Una volta raccolte le misure e analizzate, come risultato, si effettua un tuning applicativo.

Tuttavia, a volte si usa anche un approccio black-box effettuando un test di carico sul sistema. Per una [[applicazione web]], ad esempio, si usano tool che simulano un certo numero di utenti/connessioni http concorrenti e si misura il “response time”.

Il collaudo prestazionale può essere integrato nel collaudo di regressione per verificare che le modifiche non abbiano introdotto rallentamenti.