Collaudo del software: differenze tra le versioni

Versione delle 11:37, 12 set 2021

Versione delle 11:41, 12 set 2021

Riga 1:

{{Nota disambigua|l'album di [[ASAP Rocky]] del 2018|Testing (album)|Testing}}

{{F|ingegneria del software|maggio 2012}}

Il '''collaudo del software''' (detto anche '''testing''' o '''software testing''' secondo le denominazioni [[lingua inglese|inglesi]]), in [[informatica]], indica un procedimento, che fa parte del [[ciclo di vita del software]], utilizzato per individuare le carenze di [[Correttezza (logica matematica)|correttezza]], [[Specifica (ingegneria del software)#Completezza|completezza]] e [[affidabilità]] delle componenti [[software]] in corso di sviluppo. Consiste nell'esecuzione del software da parte del collaudatore, da solo o in combinazione ad altro software di servizio, e nel valutare se il comportamento del software rispetta i [[:Categoria:Requisiti software|requisiti]]. A volte il collaudo, che fa parte delle procedure di [[assicurazione di qualità]], viene confuso con il [[debugging]], con il [[Profiling (programmazione)|profiling]], o con il [[benchmark (informatica)|benchmarking]].

== Descrizione generale ==

Riga 38:

== Modello di sviluppo ==

=== Sviluppo a cascata ===

Il procedimento tradizionale di [[Sviluppo software|sviluppo del software]], detto "[[Modello a cascata|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.

Riga 44 ⟶ 45:

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

* Dato che il software in tale modello è previsto che venga sottoposto a test solo dopo aver completato la fase di sviluppo, l'eventuale feedback raccolto in fase di prova non può essere usato per alimentare tempestivamente l'apprendimento del team di sviluppo in modo tale che la qualità del codice possa essere migliorata come nei metodi iterativi ed incrementali (come può avvenire ad es. nei metodi "[[Metodologia agile|agili]]"). Pertanto nel modello di sviluppo in cascata le "lezioni apprese" possono essere utilizzate solo in eventuali successivi progetti di sviluppo, il che spesso ne limita l'effettivo valore aggiunto, in quanto la distanza nel tempo dalla fase di raccolta non agevola la applicazione.

=== Sviluppo guidato dal collaudo ===

{{vediVedi anche|Test Driven Development}}

Un procedimento più recente, detto "guidato dal collaudo" (in inglese, "''[[test driven development]]''"), proposto a partire dall'inizio degli anni 1990, consiste nel considerare il collaudo una parte integrante del prodotto:

Riga 58 ⟶ 59:

== Fasi di distribuzione ==

=== Il collaudo di tipo Alpha ===

{{vediVedi anche|Versione alpha}}

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

Riga 72:

=== Il collaudo di tipo Beta ===

{{vediVedi anche|Versione beta}}

Spesso, quando un prodotto ha superato il collaudo di tipo Alpha, viene distribuito all'esterno dell'azienda ad alcuni clienti selezionati o anche a tutti i clienti, avvertendo gli utenti che il prodotto distribuito potrebbe non essere di qualità elevata e probabilmente potrebbe richiedere ulteriori correzioni.

Riga 90 ⟶ 89:

== Granularità ==

=== Il collaudo di modulo (Unit Testing) ===

{{vediVedi anche|Unit testing}}

Quando si costruisce un prodotto complesso come un'automobile, non 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.

* In alcuni casi potrebbero derivare dei rischi di arrecare danni a persone o cose dal funzionamento difettoso di un componente critico.

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.

Riga 117 ⟶ 115:

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

Riga 128 ⟶ 127:

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

Riga 147:

== Collaudo formale e informale ==

=== Il collaudo informale ===

Nelle piccole organizzazioni, o per prodotti software di poco valore, il collaudo è normalmente informale, cioè non esiste a livello organizzativo una mansione riconosciuta come "collaudo del software".

Riga 156 ⟶ 157:

=== Il collaudo formale ===

Il collaudo del software importante in grandi organizzazioni segue invece iter procedurali più rigorosi, analoghi a quelli dei progetti ingegneristici.

Riga 186 ⟶ 188:

== Altri 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. 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 soddisfi i requisiti prestazionali richiesti in fase di esplicitazione dei requisiti.

Riga 195 ⟶ 198:

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

Riga 215 ⟶ 219:

=== 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 tolerance|fault-tolerant]]).