Collaudo del software: differenze tra le versioni

Versione delle 18:52, 26 ott 2005

Versione delle 19:36, 26 ott 2005

Riga 2:

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 [[benchmark (informatica)|benchmarking]].

Riga 37:

* 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.

Riga 65:

== Fasi di rilascio ==

=== CollaudoIl collaudo Alfa ===

Appena un software è stato costruito, prima di rilasciarlo fuori dall'azienda, viene normalmente sottoposto a un collaudo interno all'azienda.

Riga 80:

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.

=== CollaudoIl 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.

Riga 92:

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.

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

== Automazione del collaudo ==

Riga 149 ⟶ 139:

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 [[programmzioneprogrammazione orientata agli oggetti]] una [[classe]] è unala tipica componente da collaudare è la [[classe (informatica)|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.

Riga 269 ⟶ 259:

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.

== Il collaudo di regressione ==

Riga 282 ⟶ 273:

== Metriche ==

Ci sono [[metrica del software|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.