Collaudo del software: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
ortografia |
|||
| (101 versioni intermedie di 66 utenti non mostrate) | |||
Riga 1:
{{Nota disambigua|l'album di [[ASAP Rocky]] del 2018|Testing (album)|Testing}}
{{F|ingegneria del software|maggio 2012}}
Il '''collaudo del software''' (anche '''software testing''' in [[lingua inglese]]), 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 ==
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 distribuito 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 bassa probabilità di malfunzionamento dipende dal tipo di applicazione.
Il software per cui è richiesta la massima qualità, è quello cosiddetto "life-critical" ("safety 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. 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 (informatica)|interprete]], o solo se eseguito su una particolare piattaforma. Pertanto può essere necessario collaudare il software con vari [[Integrated development environment|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.
Riga 40 ⟶ 22:
* Per grado di formalità: da informale a formale.
=== Verifica e validazione ===
La fase di '''verifica''' e di '''validazione''' serve ad accertare che il [[software]]
Precisamente:
* la '''verifica''' serve a stabilire che il software rispetti i requisiti e le specifiche, quindi ad esempio che non ci siano requisiti mancanti o che le diverse prove (esecuzione, moduli/parti del sistema, unità, integrazione, etc) abbiano esito positivo, La verifica può essere eseguita in diverse sotto fasi o riguardare specifici aspetti (categorie di funzioni, sicurezza, architettura, ingegnerizzazione del sistema, prestazioni); spesso si esegue la verifica X per poter procedere alla successiva sottofase X+1; esistono test di verifica della progettazione (analisi funzionale) e altre più propriamente di sviluppo;
* invece, la '''validazione''' serve ad accertare che i requisiti di utilizzo (bisogni e aspettative dell'utente) siano anche soddisfatti nella maniera giusta. Il collaudo per antonomasia è quello finale, eseguito in condizioni che simulino il reale impiego applicativo. La validazione (validare = convalidare, rendere valido) segue sempre la verifica.
Questa fase, infatti, è molto delicata in quanto, se il software passa la verifica, ma non la validazione, dopo tutto il processo si può ottenere un [[software]] perfettamente funzionante, senza errori, ma del tutto inutile in quanto non rispecchia quanto era stato chiesto all'inizio (in tal caso non adempiendo all'insieme completo delle funzionalità previste e quindi non servendo allo scopo di progetto, può esserci il rischio che venga rigettato dal cliente). Oltre alla funzioni (tra cui quelle di sicurezza, sempre più rilevanti e spesso date per scontate), la validazione deve accertare anche il raggiungimento dei livelli prestazionionali (in pratica, la velocità di esecuzione e l'efficienza del sistema).
Secondo il modello applicato questa fase si applica su stadi intermedi o su tutto il sistema software (ivi compresa l'ingegnerizzazione della piattaforma SW/HW quando prevista cioè l'ambiente in cui il software verrà eseguito e fruito). La verifica può essere ''statica'', se effettuata su carta, cioè sul progetto, o ''dinamica'', se effettuata attraverso il [[collaudo]] dello stesso software con dati di test.
== 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.
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.
*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 ===
{{Vedi 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:
* 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.
Riga 72 ⟶ 55:
* 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.
== Fasi di
=== Il collaudo di tipo Alpha ===
{{Vedi anche|Versione alpha}}
Appena un software è stato costruito, prima di
Il collaudo di tipo Alpha può essere eseguito dagli stessi programmatori o da altro personale dell'azienda.
Spesso, il software prodotto per il collaudo Alpha 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 [[Allocazione dinamica della memoria|memoria allocata]] venga disallocata prima della terminazione;
* asserzioni dichiarative scritte dal programmatore.
In alcuni casi, in particolare per lo sviluppo di [[Sistema operativo|software di sistema]] o di [[software embedded]], si utilizza un ambiente hardware di esecuzione che supporta specificamente il debugging e il testing.
=== Il collaudo di tipo Beta ===
{{Vedi anche|Versione beta}}
Spesso, quando un prodotto ha superato il collaudo
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
Anche dopo che sono state distribuite delle versioni Beta, e quindi si è in fase di collaudo Beta, all'interno dell'azienda può continuare il collaudo Alpha.
== Automazione del collaudo ==
{{Vedi anche|Automazione del collaudo del software}}
Se il collaudo consiste nell'utilizzo del prodotto quasi come se fosse la normale operatività, si parla di "collaudo manuale".
Riga 107 ⟶ 87:
== Granularità ==
=== Il collaudo di modulo (Unit Testing) ===
{{Vedi 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 una 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 (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 128 ⟶ 105:
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 (informatica)|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.
Riga 142 ⟶ 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.
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:
Riga 150 ⟶ 122:
== Conoscenza delle funzionalità interne ==
=== Il collaudo a scatola bianca ===
Il collaudo a scatola bianca, noto anche con le denominazioni [[lingua inglese|inglesi]] ''white box testing'' o ''clear/glass box testing'' ("collaudo a scatola trasparente") o ''structural testing'' ("collaudo strutturale") è una forma di collaudo che verifica il funzionamento ''interno'' di un componente software, piuttosto che le sue funzionalità. Poiché richiede la conoscenza e la comprensione della struttura interna del software sotto test (eventualmente anche del suo [[codice sorgente]]), questa forma di testing è in genere a carico di un programmatore, spesso lo stesso che ha scritto il codice. Benché il concetto si possa applicare a diversi livelli, il collaudo a scatola bianca è tipicamente [[unit testing|unitario]]. Il collaudo a scatola bianca può facilitare il compito di garantire una copertura esaustiva dei [[test case]] rispetto al codice sorgente; la sua controindicazione principale è che esso costituisce una deroga al principio dell'[[Incapsulamento (informatica)|incapsulamento]]: in particolare, un test case esistente può fallire a seguito di una modifica strutturale di un componente (per esempio in seguito a [[refactoring]]) anche quando questa modifica preservi correttamente la funzionalità del componente stesso.
=== 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.
Riga 182 ⟶ 136:
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.
Riga 190 ⟶ 145:
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.
=== Tecniche di collaudo a scatola nera ===
Ci sono tre tecniche principali:
* [[Tecnica della copertura delle classi di equivalenza]]
* [[Tecnica di analisi dei valori estremi]]
* Tecnica di copertura delle funzionalità
== Collaudo formale e informale ==
=== Il collaudo informale ===
Nelle piccole organizzazioni, o per prodotti software di poco valore,
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 versione 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.
=== Il collaudo formale ===
Riga 212 ⟶ 169:
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 "[[caso di test|test case]]"). Ogni prova ha almeno i seguenti attributi:
* Spesso ha un identificatore o numero progressivo.
* Talvolta ha 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.
Riga 227 ⟶ 182:
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:
Riga 237 ⟶ 191:
* 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.
== 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.
Solitamente, si definiscono per vari tipi di operazioni dei tempi massimi di esecuzione (ovvero, si definiscono delle "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. Le baseline possono essere semplicemente ottenute misurando i tempi di esecuzione di un sistema esistente. 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, 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 time”.
Il collaudo prestazionale può essere integrato nel collaudo di regressione per verificare che le modifiche non abbiano introdotto rallentamenti.
Riga 274 ⟶ 221:
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
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.
=== 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]]).
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:
Riga 290 ⟶ 236:
* 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
== Il collaudo di
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 nuova funzionalità a un vecchio prodotto comprometta la qualità di funzionalità preesistenti del prodotto stesso. 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", o anche "non-regression testing"<ref>{{cita libro |autore=Mauro Pezzè |autore2=Michal Young |titolo=Software testing and analysis: process, principles, and techniques |anno=2008 |editore=Wiley}}</ref>), in quanto si vuole verificare se la qualità sia ''regredita''.<ref name="metrics">{{cita libro|autore=Anirban Basu| titolo=Software Quality Assurance, Testing and Metrics| anno=2015| editore=PHI Learning| isbn=978-81-203-5068-7| url=https://books.google.com/books?id=aNTiCQAAQBAJ&pg=PA150}}</ref>
Se sono stati predisposti dei collaudi automatizzati, tramite appositi strumenti software e script dedicati, il collaudo di regressione ha normalmente un basso costo, in quanto si tratta solo di lanciare le procedure di collaudo esistenti, eventualmente ritoccate e confrontare i risultati prodotti con quelli corretti. Un completo collaudo di regressione manuale sarebbe invece enormemente costoso, soprattutto se il sistema deve essere collaudato con molti utenti simultanei.
Per tale motivo normalmente il collaudo di regressione manuale è più sbrigativo del collaudo originale e anche molto più pericoloso.
== Metriche ==
Ci sono [[metrica del software|metriche]] che vengono sviluppate per misurare l'efficacia del collaudo.<ref name="metrics" /> 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 dell'efficacia del collaudo di tale modulo.
== Certificazioni ==
Il software testing sta assumendo sempre di più il ruolo centrale nell'ambito dell'ingegneria del software. È quindi sempre più importante riuscire a qualificare, in maniera oggettiva, professionisti nell'ambito del testing. Sono quindi nati a livello mondiale percorsi di certificazione delle conoscenze. L'[[International Software Testing Qualifications Board]] (ISTQB) è l'ente più importante a livello mondiale che si occupa di queste certificazioni.
I software critici sviluppati per gli aeromobili devono rispettare le norme [[DO-178]], standard ''de facto'' del mondo dell'aviazione.
== Note ==
<references/>
== Voci correlate ==
* [[Ciclo di vita del software]]
* [[Modello a cascata]]
* [[Modello a spirale]]
* [[Rollout]]
* [[Software]]
* [[HP LoadRunner]]
* [[Test metamorfico]]
== Altri progetti ==
{{interprogetto|preposizione=sul}}
== Collegamenti esterni ==
* {{Collegamenti esterni}}
* {{cita web|url=http://www.ruleworks.co.uk/testguide|titolo=The Test Management Guide - A to Z and FAQ Knowledgebase|accesso=5 novembre 2006|dataarchivio=6 dicembre 2006|urlarchivio=https://web.archive.org/web/20061206141503/http://www.ruleworks.co.uk/testguide/|urlmorto=sì}}
* {{cita web|url=http://www.testingstandards.co.uk/bs_7925-1_online.htm|titolo=BS 7925-1 Vocabulary of terms in software testing - ver. 6.3}}
* {{cita web|url=http://www.testcompanies.com/|titolo=Global directory of software testing companies}}
* {{cita web|url=https://www.simform.com/blog/functional-testing-types/|titolo=Functional Testing Types Explained With Examples}}
{{Collaudo del software}}
{{Portale|informatica}}
[[Categoria:Qualità del software]]
| |||