Collaudo del software
Da Wikipedia, l'enciclopedia libera.
In informatica, il collaudo del software (in inglese, "software testing") è un procedimento utilizzato per individuare le carenze di correttezza, completezza e affidabilità delle componenti software in corso di sviluppo. Consiste nell'eseguire il software da collaudare, da solo o in combinazione ad altro software di servizio, e nel valutare se il comportamento del software rispetta i requisiti.
Fa parte delle procedure di assicurazione di qualità, ma non ne è l'unica.
A volte il collaudo viene confuso con il debugging, con il profiling, o con il benchmarking.
Indice |
[modifica] Introduzione
In generale, occorre distinguere i "malfunzionamenti" del software (in inglese, "failure"), dai "difetti" (o "errori" o "bachi") del software (in inglese, "fault" o "defect" o "bug").
Un malfunzionamento è un comportamento del software difforme dai requisiti espliciti o impliciti. In pratica, si verifica quando, in assenza di malfunzionamenti della piattaforma (hardware + software di base), il sistema non fa quello che l'utente si aspetta.
Un difetto è una sequenza di istruzioni, sorgenti o eseguibili, che, quando eseguita con particolari dati in input, genera un malfunzionamento. In pratica, si ha un malfunzionamento solo quando viene eseguito il codice che contiene il difetto, e solo se i dati di input sono tali da evidenziare l'errore. Per esempio, se invece di scrivere "a >= 0", il programmatore ha erroneamente scritto "a > 0" in una istruzione, si può avere un malfunzionamento solo quando viene eseguita quell'istruzione mentre la variabile "a" vale zero.
Lo scopo del collaudo è di rilevare i difetti tramite i malfunzionamenti, al fine di minimizzare la probabilità che il software rilasciato abbia dei malfunzionamenti nella normale operatività.
Nessun collaudo può ridurre a zero tale probabilità, in quanto le possibili combinazioni di valori di input validi sono enormi, e non possono essere riprodotte in un tempo ragionevole; tuttavia un buon collaudo può rendere la probabilità di malfunzionamenti abbastanza bassa da essere accettabile dall'utente.
L'accettabilità di una data probabilità di malfunzionamento dipende dal tipo di applicazione.
Il software per cui è richiesta la massima qualità, è quello cosiddetto "life-critical", cioè in cui un malfunzionamento può mettere a rischio la vita umana, come quello per apparecchiature medicali o aeronautiche. Per tale software è accettabile solo una probabilità di malfunzionamento molto bassa, e pertanto il collaudo è molto approfondito e rigoroso.
Il software per cui non è richiesta un'alta qualità, come quello per i videogiochi o per la produttività personale in ufficio, viene sottoposto a un collaudo sbrigativo e informale.
Per rilevare il maggior numero possibile di difetti, nel collaudo si sollecita il software in modo che sia eseguita la maggior quantità possibile di codice con svariati dati di input.
Può anche darsi che un errore nel codice sorgente generi un malfunzionamento solo se si utilizza un particolare compilatore o interprete, o solo se eseguito su una particolare piattaforma. Pertanto può essere necessario collaudare il software con vari ambienti di sviluppo e con varie piattaforme di utilizzo.
Le tecniche di collaudo possono essere classificate in molti modi. I principali sono i seguenti:
- Per modello di sviluppo: a cascata, guidato dal collaudo.
- Per livello di conoscenza delle funzionalità interne: a scatola bianca, a scatola nera.
- Per appartenenza o meno dei collaudatori all'organizzazione che modifica i sorgenti, nonché per fase di sviluppo: Alfa, Beta.
- Per grado di automazione: manuale, semi-automatizzato, completamente automatizzato.
- Per granularità: collaudo di modulo, collaudo di sistema.
- Per grado di formalità: da informale a formale.
[modifica] Modello di sviluppo
[modifica] Sviluppo a cascata
Il procedimento tradizionale di sviluppo del software, detto "a cascata" (in inglese "waterfall"), prescrive di iniziare il collaudo appena è completata la prima versione del prodotto. I risultati del collaudo vengono utilizzati per rivedere i requisiti, o il progetto, o il codice, e produrre così la versione successiva.
Questo procedimento è stato sottoposto a una severa critica in quanto ha i seguenti svantaggi:
- Se è giunta la data prevista per il completamento del prodotto, si tende a consegnarlo anche se il collaudo non è stato completato o ha dato esito negativo, il che significa che probabilmente si sta consegnando un prodotto scadente.
- Probabilmente, tra i requisiti non è stata inclusa la "collaudabilità" (in inglese, "testability"), cioè il progetto e il codice non contengono accorgimenti che agevolino il collaudo. In tal caso, il collaudo risulterà molto più costoso e meno efficace.
- Più tempo passa tra l'introduzione di un errore in un sistema e la segnalazione di un malfunzionamento dovuto a tale errore, più risulta difficile e costoso rimediarvi.
[modifica] Sviluppo guidato dal collaudo
Un procedimento più recente, detto "guidato dal collaudo" (in inglese, "test driven"), proposto a partire dall'inizio degli anni 1990, consiste nel considerare il collaudo una parte integrante del prodotto:
- Quando si analizzano i requisiti del software da produrre, si analizzano i requisiti del collaudo.
- Quando si progetta l'architettura del software da produrre, si progetta l'architettura del collaudo.
- Quando si scrive il codice del software da produrre, si scrive il codice delle routine di collaudo automatizzato o si preparano i dati e si scrivono le istruzioni per il collaudatore manuale.
- Quando si costruiscono gli eseguibili compilando i sorgenti, se la compilazione va a buon fine, vengono automaticamente eseguite le routine di collaudo automatizzato. Le prove inerentemente interattive vengono tuttavia relegate a una procedura parzialmente manuale.
- Quando si archivia o si recupera una versione dei sorgenti, si archiviano o si recuperano tutti i suddetti documenti relativi al collaudo. Anzi, tali documenti devono essere intesi come parti integranti dei sorgenti.
[modifica] Fasi di rilascio
[modifica] Il collaudo Alfa
Appena un software è stato costruito, prima di rilasciarlo fuori dall'azienda, viene normalmente sottoposto a un collaudo interno all'azienda. Tale procedura viene chiamata "collaudo Alfa" (in inglese, "Alpha testing").
Il collaudo Alfa può essere eseguito dagli stessi programmatori o da altro personale dell'azienda.
Spesso, il software prodotto per il collaudo Alfa viene arricchito di istruzioni di controllo a run-time che facilitano il rilevamento degli errori. Esempi di tali istruzioni sono:
- il controllo che non si acceda a indici non validi di array;
- il controllo che tutta la memoria allocata venga disallocata prima della terminazione;
- asserzioni dichiarative scritte dal programmatore.
In alcuni casi, in particolare per lo sviluppo di software di sistema o di software embedded, si utilizza un ambiente hardware di esecuzione che supporta specificamente il debugging e il testing.
[modifica] Il collaudo Beta
Spesso, quando un prodotto ha superato il collaudo Alfa, viene rilasciato all'esterno dell'azienda ad alcuni clienti selezionati o anche a tutti i clienti, avvertendo gli utenti che il prodotto rilasciato potrebbe non essere di qualità elevata e probabilmente richiede ulteriori correzioni. Tale versione viene detta "versione Beta".
Gli utenti della versione Beta possono simulare l'utilizzo del software in casi realistici, e inviare al produttore resoconti dei malfunzionamenti riscontrati. Tale tipo di collaudo eseguito gratuitamente dagli utenti viene detto "collaudo Beta" (in inglese, "Beta testing").
Possono esserci più versioni Beta, man mano che vengono corretti gli errori. Quando la frequenza delle segnalazioni d'errore diventa bassa, è il momento di rilasciare la versione ufficiale.
Anche dopo che sono state rilasciate delle versioni Beta, e quindi si è in fase di collaudo Beta, all'interno dell'azienda può continuare il collaudo Alfa.
[modifica] Automazione del collaudo
Se il collaudo consiste nell'utilizzo del prodotto quasi come se fosse la normale operatività, si parla di "collaudo manuale".
Se il collaudo consiste nello sviluppo di apposito software che interagisce con il software da collaudare e fornisce un rapporto di qualità in assenza di personale, si parla di "collaudo automatizzato".
Tra questi due estremi, si possono avere varie posizioni intermedie, in cui parte del lavoro è automatizzato, ma è sempre richiesta la presenza del collaudatore. In tali casi, si parla di "collaudo parzialmente automatizzato" o di "collaudo semi-automatizzato".
Nel collaudo manuale, tipico del software interattivo, il collaudatore utilizza il software come farebbe l'utente, ma cercando di attivare il maggior numero possibile di funzioni e le configurazioni più variegate. Quando il collaudatore constata un comportamento inatteso, ne prende nota e prosegue a collaudare altre funzionalità.
Nel collaudo automatico, il collaudatore può usare due tecniche di base:
- Scrive a mano del software di collaudo.
- Esegue il software da collaudare in un ambiente di collaudo che registra le operazioni dell'utente.
La prima tecnica richiede che il collaudatore sia un programmatore che conosca l'architettura interna del software da collaudare. Il software di collaudo, tipicamente scritto in un linguaggio ad altissimo livello, può interagire con il software da collaudare in vari modi:
- chiamando direttamente le singole routine di tale software;
- chiamando le routine esportate (ossia pubblicate) da un modulo;
- inviando al programma da collaudare dei messaggi di comunicazione tra processi;
- lanciando il programma da collaudare in una modalità in cui riceve due file, uno dal quale legge i dati di input, e l'altro nel quale scrive i dati di output.
Qualunque sia la tecnica di comunicazione adottata, quando il software da collaudare risponde, il programma di collaudo confronta le risposte ottenute con i risultati attesi. In caso di discrepanza, viene generato un resoconto.
La tecnica della registrazione delle operazioni dell'utente può essere attuata anche da un collaudatore che non sa programmare o che non conosce l'architettura interna del software da collaudare. Ha tuttavia due grossi inconvenienti:
- C'è un'alta probabilità che, quando il software da collaudare viene modificato, le registrazioni siano improprie, e quindi da rifare.
- L'ambiente di collaudo non fornisce strumenti automatici per determinare se il software ha il comportamento atteso.
Questa tecnica è indicata per collaudi solo parzialmente automatizzati, in quanto è sempre necessario che il collaudatore verifichi visivamente se il software si comporta come dovrebbe.
[modifica] Granularità
[modifica] Il collaudo di modulo
Quando si costruisce un'automobile, non si ci si limita a costruire e ad assemblare i pezzi e alla fine girare la chiave per vedere se tutto funziona. Questo per tre motivi:
- Alcuni difetti producono malfunzionamenti solo dopo un utilizzo prolungato, ma sono facilmente identificabili esaminando i singoli pezzi prima dell'assemblaggio.
- Se dopo aver girato la chiave la macchina non si accende, risulta molto difficile capire qual è il difetto.
- Se dopo aver girato la chiave la macchina non si accende, risulta molto costoso smontare la macchina, sostituire il pezzo difettoso e rimontarla.
Ragionamenti analoghi valgono per il software. Pertanto, come i singoli pezzi di un macchina vengono sottoposti al controllo di qualità prima dell'assemblaggio, così è opportuno collaudare separatamente le singole componenti di un sistema software.
Le componenti collaudabili di un sistema software prendono il nome di "moduli" o "unità", per cui si parla di "collaudo di modulo" (in inglese, si usa l'espressione "unit testing").
Un modulo può avere una granularità variabile da una singola routine, a un insieme di alcune decine di routine, a un sottosistema comprendente migliaia di routine. Nella programmazione orientata agli oggetti la tipica componente da collaudare è la classe.
Siccome un modulo, per definizione, non è un programma completo, mentre il concetto stesso di collaudo richiede l'esecuzione di un programma, per eseguire il collaudo di modulo si deve costruire un apposito programma che contiene il modulo da collaudare.
In un programma completo, tutti i moduli, eccetto quelli di livello più basso, richiamano routine di altri moduli, e tutti i moduli, eccetto quelli di livello più alto, contengono routine a disposizione di altri moduli.
Per costruire un programma intorno a un modulo, è necessario fornire delle routine banali che possano essere chiamate dal modulo, finché non saranno pronte le routine complete. Tali routine banali sono dette "stub" (che in inglese significa "mozzicone", "moncherino").
Per mandare in esecuzione il codice contenuto nel modulo occorre invocarne le routine. Viene pertanto scritto un apposito programma che richiama le routine del modulo, passandole in sequenza vari parametri e verificando che le routine rendano i valori attesi. Tale programma viene detto "driver" (che in inglese significa "guidatore", "conduttore").
Normalmente, per rendere più flessibile e modificabile il collaudo, il driver preleva da un file di dati i parametri che dovrà passare alle routine del modulo da collaudare, e confronta i risultati ottenuti con il contenuto di un altro file di dati. Per ogni discrepanza riscontrata tra i dati ottenuti e quelli attesi, viene generato un messaggio d'errore in un terzo file di resoconto.
Con tale architettura, se si vuole aggiungere una combinazione di valori a quelle esistenti, basta modificare i file di dati.
[modifica] Il collaudo di sistema
Anche se i singoli moduli sono corretti, il sistema ottenuto integrandoli potrebbe non esserlo. Pertanto è sempre necessario collaudare il sistema completo.
Per collaudare un sistema completo si deve utilizzare il software in modo il più possibile simile a come verrà utilizzato nella normale operatività, ma con le seguenti differenze:
- Per il software interattivo, la normale operatività consiste in una persona che interagisce con il software. Questo si ottiene con il collaudo manuale, che è sempre utile, ma ha vari svantaggi. Il collaudo automatizzato di un programma interattivo è difficile da ottenere, se non rinunciando a parte del concetto di normale operatività.
- Nella normale operatività di un sistema software, per ogni singola installazione del sistema, l'utilizzo segue un certo andamento ripetitivo. Siccome nel collaudo si deve simulare il maggior numero possibile di situazioni, normalmente si rinuncia alla ripetitività tipica delle situazioni reali, e invece si simulano utilizzi molto variegati.
[modifica] Conoscenza delle funzionalità interne
[modifica] Il collaudo a scatola bianca
Il collaudo effettuato richiamando direttamente le routine del software da collaudare, viene detto "collaudo a scatola bianca" (in inglese, "white box testing"). Per poter eseguire il collaudo a scatola bianca, il collaudatore deve poter leggere la documentazione delle routine esportate dai moduli, se non addirittura il codice sorgente.
Si tratta di un collaudo automatizzato, e tipicamente è utilizzato per il collaudo di modulo, in quanto i singoli moduli non sarebbero altrimenti singolarmente accessibili al collaudatore.
Le routine di collaudo a scatola bianca possono essere scritte nello stesso linguaggio con cui è stata scritta l'applicazione, oppure con un altro linguaggio in grado di interfacciarsi con il primo.
Normalmente, le routine da collaudare e le routine di collaudo che le invocano costituiscono un unico processo, cioè sono linkate insieme.
Il collaudo a scatola bianca, siccome richiede l'interfacciamento con le singole routine, può essere effettuato solamente da un programmatore, anche se non necessariamente un membro del gruppo che ha sviluppato il software da collaudare. Normalmente è effettuato comunque da un membro dell'organizzazione che sviluppa il software.
Un vantaggio del collaudo a scatola bianca è che permette di sondare dettagliatamente tutte le casistiche che possono presentarsi.
Un altro vantaggio è che l'automazione è più facile ed efficiente.
Un altro vantaggio è che è più facile il debugging, cioè passare dal malfunzionamento alla correzione del difetto, in quanto la segnalazione del malfunzionamento normalmente indica il punto del codice e i valori delle variabili per cui il malfunzionamento si è manifestato.
[modifica] 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.
Se si tratta di un collaudo automatizzato, le routine di collaudo sono prevalentemente scritte in un linguaggio di livello più alto del linguaggio con cui è stata scritta l'applicazione, a volte in un linguaggio progettato appositamente per il collaudo.
Il software da collaudare e il software di collaudo costituiscono processi distinti comunicanti.
Per il collaudo a scatola nera manuale non è richiesta l'opera di un programmatore, e per quello automatizzato è sufficiente un programmatore con modeste competenze. Spesso il collaudo a scatola nera è effettuato da persone che non fanno parte dell'organizzazione che sviluppa il software; si tratta degli utilizzatori stessi che effettuano il collaudo Beta.
Un esempio di una tecnica di collaudo a scatola nera automatizzata consiste nel registrare l'interazione dell'utente in un file, e poi ripetere la registrazone simulando il comportamento dell'utente.
Un vantaggio del collaudo a scatola nera sta, nei casi in cui il codice sorgente e la documentazione di progetto sono segreti industriali, nel fatto tale collaudo può essere effettuato anche da persone esterne all'azienda.
Un altro vantaggio sta nel fatto che per tale tipo di collaudo non sono necessari programmatori esperti e che conoscano gli aspetti interni del software da collaudare. Pertanto, si possono trovare molti più collaudatori, senza dover investire nell'addestramento.
[modifica] Collaudo formale e informale
[modifica] Il collaudo informale
Nelle piccole organizzazioni, o per prodotti software di poco valore, in collaudo è normalmente informale, cioè non esiste a livello organizzativo una mansione riconosciuta come "collaudo del software".
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 verisone 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.
[modifica] Il collaudo formale
Il collaudo del software importante in grandi organizzazioni segue invece iter procedurali più rigorosi, analoghi a quelli dei progetti ingegneristici.
Per eseguire un collaudo formale, cioè rigorosamente pianificato, si scrive un "piano di collaudo" (in inglese, "test plan"), in cui si descrive dettagliatamente come deve essere svolto il collaudo.
Ci sono due strategie fondamentali per organizzare il collaudo: la "batteria di prove" (in inglese "test suite"), e lo "scenario di collaudo" (in inglese "test scenario"). Spesso si utilizzano in combinazione, cioè si pianificano una o più batterie di prove e una serie di scenari di collaudo.
Una batteria di prove è un insieme di collaudi elementari, ognuno dei quali è detto "prova" (in inglese "test case"). Ogni prova ha almeno i seguenti attributi:
- Spesso, un identificatore o numero progressivo.
- Talvolta, una descrizione dello scopo della prova.
- Una sequenza di operazioni necessarie per portare il sistema nelle condizioni iniziali per la prova.
- Una sequenza di operazioni necessarie per riportare il sistema nelle condizioni di base dopo la prova.
- Le dipendenze, cioè gli identificatori dei casi di prova che devono aver avuto successo affinché abbia senso effettuae questa prova. Per esempio, se se una prova consiste nell'aprire un file e chiuderlo, e un'altra prova consiste nel leggere lo stesso file, la seconda prova dipende dalla prima, in quanto non ha senso tentare di leggere un file che non è stato possibile aprire.
- Le operazioni che sollecitano il software da collaudare.
- Il risultato atteso.
- Talvolta, il tempo massimo ammissibile per ricevere il risultato.
Spesso vengono aggiunti altri attributi.
Nel caso di collaudo manuale, queste informazioni possono essere stampate e tenute come linea guida per il collaudatore. Nel caso di collaudo automatizzato, queste informazioni sono le specifiche per il programmatore che deve realizzare il software di collaudo.
Quando una prova viene eseguita, si registrano altre informazioni, tra cui le seguenti:
- Autore della prova.
- Data e ora di esecuzione.
- Identificatore della versione collaudata.
- Esito (successo o fallimento).
- In caso di fallimento, breve descrizione del tipo di fallimento.
Uno scenario di collaudo è un utilizzo realistico non banale del software da collaudare. Mentre le prove di collaudo considerano le funzionalità elementari, ogni scenario prende in considerazione una tipologia di utente e una situazione verosimile e complessa in cui tale utente può trovarsi. Il collaudo di scenario percorre tutti i passi che l'utente percorrerebbe in tale situazione. Il collaudo Beta è di fatto un collaudo di scenario, sebbene informale. Il collaudo di scenario è necessariamente un collaudo di sistema, e tipicamente è manuale o semiautomatico.
[modifica] Tipologie di collaudo
[modifica] Collaudo Prestazionale (Performance Test)
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. 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.
Ritornando all’esempio dell’applicazione web, questi colli di bottiglia potrebbero esistere a diversi livelli, e per identificarli si possono usare differenti tool:
- a livello applicativo, gli sviluppatori possono usare strumenti di profilatura per scoprire inefficenze 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.
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”.
[modifica] Collaudo di Carico/Volume (Load/Volume Test)
Questo tipo di test in genere è parte del performance testing e tuning. In tale contesto, significa aumentare costantemente il carico sul sistema tramite strumenti automatici. Per una applicazione web, ad esempio, il carico è il numero di utenti/connessioni HTTP concorrenti.
In letteratura, il termine load testing è di solito definito come il processo di esercizio del sistema sotto test alimentandolo in modo da fargli eseguire i task più grandi con cui esso può operare. Il test di carico è talvolta chiamato anche volume testing, o longevity/endurance testing.
Esempi di volume testing:
- test di un word processor editando un documento molto grande;
- test di una stampante inviandogli un job molto grande;
- test di un mail server con migliaia di mailbox utente;
- un caso specifico di volume testing è il cosidetto “zero-volume testing”, dove il sistema viene alimentato con task “vuoti”.
Esempi di longevity/endurance testing:
- test di una applicazione client-server eseguendo il client in un loop di accessi alla componente per un periodo di tempo esteso.
Scopi del load testing:
- scoprire bug non emersi in fase di test, quali errori del tipo “memory management”, “memory leaks”, “buffer overflow”, ecc.;
- assicurare che l’applicazione soddisfa le prestazioni di “baseline” stabilite durante il “performance testing”. Questo viene fatto effettuando un test di regressione sull’applicazione con un specifico carico massimo.
Nonostante il “performance testing” e il “load testing” possano sembrare similari, il loro scopo è differente. Da un lato, il “performance testing” utilizza tecniche e strumenti di “load testing” per la misurazione e allo scopo di effettuare misure di “benchmarking” utilizzando vari livelli di carico. Dall’altro, il “load testing” opera ad un predefinito livello di carico, di solito il massimo carico che il sistema può accettare continuando a funzionare regolarmente. Lo scopo non è di “rompere” il sistema sovraccaricandolo, ma invece provare a mantenere il sistema costantemente attivo come una “macchina ben oliata”. E’ necessario enfatizzare l’importanza di questo tipo di test. L’esperienza ha infatti mostrato che molti bug importanti non emergono fintanto che il sistema non ha a che fare con una mole di dati veramente vasta, come ad esempio migliaia di utenti in repository quali LDAP/NIS/Active Directory, migliaia di caselle di posta utente su server-mail, tabelle multi-gigabyte nei database, lunghissime gerarchie di file/directory sui file-system, ecc. In questi casi, quasi sempre c’è l’esigenza di utilizzare tool automatizzati che generino una tale mole di dati, ma fortunatamente con un qualunque buon linguaggio di scripting questo risulta un compito molto facile.
[modifica] Collaudo di Stress (Stress Test)
Lo “stress test” ha lo scopo di provare a “rompere” il sistema sotto test sovraccaricando le sue risorse o sottraendogli risorse (in tale caso viene anche chiamato “negative testing”). Lo scopo principale di queste attività è verificare che il sistema va in “fault” e successivamente (eventualmente) recupera in maniera “indolore” – questo aspetto qualitativo è noto come recoverability (sistemi fault-tolerant).
Mentre il “performance test” richiede un ambiente controllato e misure ripetibili, lo stress test provoca caos e impredicibilità. Per rifare ancora un esempio per una applicazione web, alcuni modi in cui si può stressare il sistema:
- raddoppiare il numero di utenti/connessioni HTTP previste in baseline
- in maniera casuale spegnere e riavviare porte dei switch/router di rete che collegano i server (via comandi SNMP ad esempio)
- mettere offline il database, e farlo ripartire
- effettuare un rebuild di un array RAID mentre il sistema è funzionante
- eseguire processi che consumano risorse (CPU, memoria, disco, rete) sui web-server sui database-server.
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.
[modifica] Il collaudo di regressione
Uno scopo del collaudo è verificare che i nuovi prodotti e le nuove funzionalità aggiunte a vecchi prodotti siano di alta qualità. Tuttavia, nel software capita spesso che l'introduzione di una nuove funzionalità a un vecchio prodotto comprometta la qualità di funzionalità preesistenti del prodotto. Pertanto, per assicurarsi la qualità del prodotto bisognerebbe ripetere l'intero collaudo ad ogni modifica. Il collaudo di funzionalità preesistenti e già collaudate, eseguito per assicurare che modifiche al prodotto non ne abbiano compromesso la qualità si chiama "collaudo di regressione" (in inglese, "regression testing"), in quanto si vuole verificare se la qualità è regredita.
Se erano stati prodisposti dei collaudi automatizzati, il collaudo di regressione ha normalmente un basso costo, in quanto si tratta solo di lanciare le procedure di collaudo esistenti, eventualmente ritoccate. Un completo collaudo di regressione manuale sarebbe invece enormemente costoso, e per tale motivo normalmente il collaudo di regressione manuale è più sbrigativo del collaudo originale.
[modifica] Metriche
Ci sono metriche che vengono sviluppate per misurare l'efficacia del collaudo. La principale è l'analisi della copertura del codice ottenuta tramite un profiler. Il profiler indica quante volte è stata eseguita ogni istruzione durante il collaudo. Le istruzioni eseguite almeno una volta sono dette "coperte". L'obiettivo è coprire il maggior numero possibile di istruzioni.
Un'altra metrica utile è il rapporto tra il numero di difetti trovati in un modulo e il numero di istruzioni modificate. Se si trova che in un modulo sono state modificate molte istruzioni ma sono stati trovati pochi difetti, si può dubitare sull'efficacia del collaudo di tale modulo.
