Collaudo del software: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m sistemazione fonti e fix vari |
ortografia |
||
| (20 versioni intermedie di 13 utenti non mostrate) | |||
Riga 8:
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
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.
Riga 23:
=== 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;
*
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 ==
Riga 129 ⟶ 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").
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 138 ⟶ 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 145 ⟶ 144:
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 ==
Riga 153 ⟶ 159:
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.
Riga 194 ⟶ 200:
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 259 ⟶ 265:
* [[Software]]
* [[HP LoadRunner]]
* [[Test metamorfico]]
== Altri progetti ==
Riga 265 ⟶ 272:
== 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}}
Riga 273 ⟶ 280:
{{Portale|informatica}}
[[Categoria:
| |||