Collaudo del software: differenze tra le versioni

Versione delle 12:43, 25 dic 2007

Versione delle 18:26, 25 dic 2007

Riga 260:

Il collaudo di scenario è necessariamente un collaudo di sistema, e tipicamente è manuale o semiautomatico.

== TipologieAltre tipi di collaudo ==

=== Collaudo Prestazionale (Performance Test) ===

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.

Lo scopo del “performance testing” non è di rilevare errori nell’applicazione, ma di eliminare potenziali “colli di bottiglia” e stabilire una baseline (prestazionale) per i futuri test di regressione.

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 non sia troppo lenta.

Per condurre un test di questo tipo è necessario eseguirlo in un processo controllato di misurazione e analisi. Il software sottoposto a test dovrebbe essere abbastanza stabile in modo che le operazioni di verifica possano procedere senza intoppi.

Un insieme chiaramente definito di “cosa ci si aspetta” è essenziale per un test significativo.

Ad esempio, per un’applicazione web sarebbe necessario conoscere almeno le seguenti due cose:

* “carico atteso” in termini di utenti concorrenti o connessioni http,

* “tempi di risposta” considerati accettabili.

Solitamente, si definiscono per vari tipi di operazioni dei tempi massimi di esecuzione (detti "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.

Ritornando all’esempio dell’applicazione web, questi colli di bottiglia potrebbero esistere a diversi livelli, e per identificarli si possono usare differenti tool:

Le baseline possono essere semplicemente ottenute misurando i tempi di esecuzione di un sistema esistente.

* a livello applicativo, gli sviluppatori possono usare strumenti di profilatura per scoprire inefficienze del codice (es. “poor search algorithms”)

* a livello di database, gli sviluppatori e i DBA possono usare tool specifici del database (profilers o ottimizzatori di query).

* a livello di sistema operativo, i system engineers possono usare utility quali top, vmstat, iostat (su sistemi Unix-like) e PerfMon (su Windows) per verificare l’uso delle risorse hardware quale la CPU, memoria, aree di swap, disk I/O.

* a livello di rete, i network engineers possono usare i packet sniffer quail tcpdump, o network protocol analyzers come ethereal, e altre utility varie come netstat, MRTG, ntop, mii-tool.

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, e come risultato, si effettua un tuning applicativo.

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

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 times”.

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) ===

Riga 314 ⟶ 321:

La lista può essere ovviamente arricchita. Comunque, lo stress test non è fatto al puro scopo di far andare in crash il sistema, ma piuttosto deve servire per osservare come il sistema reagisce alle failure. Riesce a salvare il suo stato o va in crash nuovamente/continuamente? Si ferma improvvisamente, bloccandosi, o in maniera controllata? Al riavvio, è in grado di recuperare dall’ultimo stato corretto? Visualizza messaggi di errore comprensibili all’utente, o si limita a visualizzare incomprensibili elenchi di codice esadecimale? La sicurezza del sistema è compromessa a causa di un failure inatteso? E così via.

[http://www.indirizzo-del-sito.foo titolo del link]

== Il collaudo di regressione ==