|
Tra i requisiti di qualità di un'applicazione, non c'è solo la correttezza, ma anche l'efficienza, o comunque vengono definiti requisiti prestazionali il cui soddisfacimento deve essere verificato prima di utilizzare il software prodotto.
Le attività finalizzate a determinare se un dato prodotto software soddisfa specificati requisiti prestazionali è chiamata "collaudo prestazionale" (o "performance testing"). Il suo scopo non è quindi rilevare errori nell'applicazione, ma verificare che l'applicazione nonsoddisfi siai tropporequisiti lentaprestazionali richiesti in fase di esplicitazione dei requisiti.
Solitamente, si definiscono per vari tipi di operazioni dei tempi massimi di esecuzione (dettiovvero, 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.
Il collaudo prestazionale può essere integrato nel collaudo di regressione per verificare che le modifiche non abbiano introdotto rallentamenti.
Il collaudo prestazionale viene eseguito su un prodotto che ha già superato con successo il collaudo di correttezza, in quanto non ha senso chiedersi se un software erroneo è veloce, e in quanto in presenza di errori le misurazioni possono essere difficoltose.
Inoltre, tale collaudo si applica esclusivamente al software "di produzione", cioè privo di strumentazione di debugging, in quanto quest'ultima ne può rallentare sensibilmente la velocità.
Il collaudo prestazionale viene eseguito solamente su un prodotto che ha già superato con successo il collaudo di correttezza, in quanto non ha senso chiedersi se un software erroneo è veloce, e in quanto in presenza di errori le misurazioni possono essere difficoltose.
A causa della difficoltà e dell'imprecisione del cronometraggio umano, è necessario che il software da collaudare sia attivato da un altro modulo software, che si occupa anche di misurare il tempo impiegato dalle varie operazioni e di comunicarlo all'utente.
Ad esempio, per progettare il collaudo di un'applicazione di database, si preparano una serie di interrogazioni per il DBMS, si decide quanti utenti inviano simultaneamente tali interrogazioni, e quale tempo massimo si considera accettabile. Poi, si prepara un'applicazione client che attiva un cronometro, invia in parallelo tali interrogazioni al DBMS e attende la risposta. Quando sono arrivate tutte le risposte, ferma il cronometro e comunica all'utente se il tempo misurato ha superato o no il tempo limite.
Analogamente, per progettare il collaudo di un'applicazione Web, si preparano una serie di pagine Web, e una serie di richieste di tali pagine, si decide quanti utenti inviano simultaneamente tali richieste, e quale tempo massimo si considera accettabile.
Dato che questo tipo di collaudo non richiede l'accesso al codice sorgente del software da collaudare, si tratta di un tipo di collaudo " a scatola bianca".
Tuttavia, spesso il prodotto software, per poter essere collaudato, deve essere progettato e implementato in modo da consentire un collaudo automatizzato.
Per esempio, per collaudare in modo automatizzato un'applicazione interattiva, è necessario che un'applicazione esterna possa inviare a tale applicazione dei comandi simulando un utente.
=== Collaudo di Carico/Volume (Load/Volume Test) ===
| 