Collaudo del software: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica |
|||
Riga 260:
Il collaudo di scenario è necessariamente un collaudo di sistema, e tipicamente è manuale o semiautomatico.
== Tipologie di collaudo ==
=== 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”.
=== 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.
=== 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.
== Il collaudo di regressione ==
Riga 291 ⟶ 345:
*[http://www.ruleworks.co.uk/testguide The Test Management Guide - A to Z and FAQ Knowledgebase]
*[http://www.testingstandards.co.uk/bs_7925-1_online.htm BS 7925-1 Vocabulary of terms in software testing - ver. 6.3]
*[http://agiletesting.blogspot.com/ Agile Testing (blog)]
[[Categoria:Ingegneria del software]]
| |||