Che materia stai cercando?

Testing software Appunti scolastici Premium

Appunti di ingegneria del software della professoressa Fasolino sul Testing (o collaudo). Il file contiene una lunga trattazione su: il processo di debugging, la relazione tra difetto, errore e malfunzionamento, le tesi di Dijkstra e l'ispezione.

Esame di Fondamenti di informatica docente Prof. R. Fassolino

Anteprima

ESTRATTO DOCUMENTO

INGEGNERIA DEL SOFTWARE FranK 1

IL TESTING O IL COLLAUDO

Il software deve essere collaudato per individuare gli errori che sono stati commessi inavvertitamente durante la

progettazione e la realizzazione. Anche per il collaudo del software occorre stabilire una strategia sistematica. Il

collaudo procede dal “piccolo al grande”. Con questo si intende che le prime operazioni di collaudo si concentrano su

un unico componente o su piccoli gruppi di componenti correlati in modo da individuare gli errori nei dati e nella logica

elaborativi che sono collocati all’interno dei componenti. Dopo che i singoli componenti saranno stati collaudati,

occorre integrarli in modo da realizzare un sistema completo. A questo punto occorre eseguire una serie di collaudi di

alto livello per verificare che il programma risponda alle richieste del cliente. Dopo aver individuato gli errori occorre

stabilirne una diagnosi e correggerli utilizzando un processo chiamato debugging.

Per documentare l’appoggio al collaudo da parte del team software vengono sviluppati dei documenti di specifica del

collaudo che definiscono un piano che descrive la strategia globale e una procedura che definisce i passi di collaudo e i

collaudi specifici che verranno condotti.

Definizione. Errore (umano) = incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell’uso

di strumenti;

difetto (fault o bug) = manifestazione nel software di un errore umano, e causa del fallimento del sistema nell’eseguire

la funzione richiesta;

malfunzionamento (failure) = incapacità del software di comportarsi secondo le aspettative o le specifiche; un

malfunzionamento ha una natura dinamica: accade in un certo istante di tempo e può essere osservato solo mediante

esecuzione.

Il testing (collaudo) è un processo di esecuzione del software allo scopo di scoprirne i malfunzionamenti:

- osservando i malfunzionamenti possiamo dedurre la presenza di difetti.

Tesi di Dijkstra: il testing non può dimostrare l’assenza di difetti, ma può solo dimostrare la presenza di difetti.

Il debugging è il processo di analisi del software per scoprirne i difetti.

L’ispezione è un processo di analisi del software per scoprirne i difetti.

il collaudo del software fa parte di un tema più vasto, spesso chiamato verifica e convalida (o validazione). Per verifica

si intende un insieme di attività che assicurano che il software realizzi correttamente una determinata funzione. Per

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 2

convalida si intende un diverso insieme di attività che assicurano che il software costruito sia riconducibile ai requisiti

del cliente.

Verifica: Stiamo costruendo il prodotto nel modo giusto?

Convalida: Stiamo costruendo il prodotto giusto?

Il collaudo stabilisce la seconda chance per stabilire la qualità e per scoprire gli errori. Ma non si deve assolutamente

considerare il collaudo come una rete di salvataggio. Si suole dire che la qualità non può essere “iniettata” mediante il

collaudo: se mancava prima dei collaudi, mancherà dopo. La qualità deve essere incorporata nel software lungo tutto il

processo di ingegneria del software. Solo l’applicazione di metodi e tecniche valide, le revisioni tecniche formali,

adeguate misurazioni e una gestione attenta conducono alla qualità, che il collaudo può solo confermare.

Ecco alcune considerazioni da osservare:

1) lo sviluppatore del software non deve eseguire alcun collaudo;

2) il software deve essere consegnato a estranei che lo mettano alla prova in modo spietato;

3) le persone preposte al collaudo devono entrare nel progetto solo quando inizia tale attività.

Il precedente approccio è sbagliato! Lo sviluppatore di software è sempre responsabile del collaudo delle singole unità

(i moduli) del programma e deve assicurarne il funzionamento secondo la funzione per la quale sono state progettate.

Problemi del testing

• Criterio di selezione

• Valutazione dei risultati del test

• Criterio di terminazione del testing

Valutazione dei risultati del test. Condizione necessaria per effettuare un test: conoscere il comportamento atteso per

poterlo confrontare con quello osservato.

L’oracolo conosce il comportamento atteso per ogni caso di prova (può essere un oracolo umano, che si basa sulle

specifiche o sul giudizio) o un oracolo automatico.

Terminazione del testing

Quando il programma si può ritenere analizzato a sufficienza, in base a:

- un criterio temporale: periodo di tempo predefinito

- un criterio di costo: sforzo allocato predefinito

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 3

- un criterio di copertura: percentuale predefinita degli elementi di un modello di programma, legato ad un

criterio di selezione dei casi di test;

- un criterio statistico: MTBF (mean time between failures) predefinito e confronto con un modello di

affidabilità esistente.

Quindi volendo rispondere alla domanda, quando termina un collaudo? Si può dire, il collaudo non finisce mai,

semplicemente la sua responsabilità passa dallo sviluppatore al cliente. “I collaudi terminano quando non c’è più

tempo o sono finiti i soldi”.

Problema della selezione dei casi di test

Un programma è corretto se è corretto per ogni dato di ingresso.

Un programma è esercitato da un caso di test (sottoinsieme dei dati di input).

Un test è formato da un insieme di casi di test.

L’esecuzione del test consiste nell’esecuzione del programma per tutti i casi di test.

Un test ha successo se rileva uno o più malfunzionamenti del programma.

Un test è ideale se l’insuccesso del test implica la correttezza del programma.

Un test esaustivo è un test che contiene tutti i dati di ingresso al programma (un test esaustivo è un test ideale; un

test esaustivo non è pratico e quasi sempre non è fattibile).

Obiettivo realistico: selezionare casi di test che approssimano un test ideale.

Criterio di selezione di test

Specifica le condizioni che devono essere soddisfatte da un test.

Consente di selezionare più test per uno stesso programma.

Un criterio di selezione di test è affidabile per un programma se per ogni coppia di test selezionati, T1 e T2, essi si

comportano allo stesso modo (ossia ogni insieme di casi di test che soddisfano il criterio rilevano gli stessi errori).

Un criterio di selezione di test è valido per un programma se, qualora il programma non è corretto, esiste almeno

un test selezionato che ha successo.

Teorema di Goodenough e Gerhart. Il fallimento di un test per un programma P, selezionato da un criterio C

affidabile e valido, permette di dedurre la correttezza del programma P.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 4

Selezione dei casi di test. Teorema di Howden – non esiste un algoritmo che, dato un programma arbitrario P,

generi un test ideale finito, e cioè un test definito da un criterio affidabile e valido.

Aldilà di casi banali, non è possibile costruire un criterio di selezione generale di test valido e affidabile che non sia

valido e affidabile che non sia il test esaustivo.

Obiettivi pratici:

- massimizzare il numero di malfunzionamenti scoperti (richiede molti casi di test);

- minimizzare il numero di casi di test (e quindi il costo del testing);

E’ preferibile usare più di un criterio di selezione dei test.

Osservazione. Ogni prodotto (ma anche molti altri oggetti) si può collaudare in due modi: 1) se si conoscono le

funzioni specifiche che il prodotto deve svolgere, si possono effettuare prove tese a dimostrare che tali funzioni sono

effettivamente svolte, cercando nel contempo eventuali errori in ciascuna funzione; 2) se si conosce la struttura interna

del prodotto, si possono effettuare prove tese a garantire che le operazioni interne rispettino le specifiche, avendo cura

di mettere alla prova tutti i componenti. Il primo metodo è detto collaudo black-box e il secondo, collaudo white-box (al

posto dei termini collaudo black-box e collaudo white-box vengono rispettivamente utilizzati i termini collaudo

funzionale e collaudo strutturale).

Strategie di collaudo per il software convenzionale. Una strategia di collaudo che viene scelta dalla maggior parte dei

team di sviluppo software adotta una visione incrementale del collaudo, iniziando con il collaudo delle singole unità del

programma, procedendo con i test progettati per facilitare l’integrazione di queste unità e terminando con i test che

mettono alla prova il sistema finale. Il collaudo delle unità si concentra sull’impegno di verifica della più piccola unità

di programmazione software: il componente o il modulo. Il collaudo delle unità sfrutta di norma le tecniche white-box e

il passo può essere condotto per più moduli contemporaneamente. L’interfaccia del modulo viene provata per assicurare

che le informazioni fluiscano correttamente all’interno e all’esterno dell’unità di programma in esame. Vengono

esaminate le strutture di dati locali, per assicurare che i dati memorizzati temporaneamente mantengano la propria

integrità. Vengono provati tutti i cammini di esecuzione per la gestione degli errori. I casi di prova devono mirare a

scoprire errori causati da calcoli e confronti errati o da anomalie del flusso di controllo. Quindi, riassumendo il testing

di unità è applicato isolatamente ad una unità o ad un modulo di un sistema software; obiettivo fondamentale è quello

di rilevare errori (logica e dati) nel modulo; prassi diffusa è che esso venga realizzato dal programmatore che ha

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 5

prodotto l’unità sotto test. L’ unità è l’elemento definito nel progetto di un sistema software e testabile separatamente.

Nel testing unità e modulo sono spesso usati come sinonimi.

Il collaudo viene considerato come una appendice della stesura del codice. Dopo aver sviluppato, riveduto e verificato

da un punto di vista sintattico il codice sorgente e dopo aver verificato la corrispondenza con il progetto dei

componenti, può iniziare la preparazione dei casi di prova. Sfortunatamente, molti moduli non possono essere provati

singolarmente solo mediante semplice software; in tali casi, il collaudo completo va rimandato sino al momento del

collaudo di integrazione.

Prove di convalida. Le prove di convalida iniziano al termine del collaudo dell’integrazione, quando i singoli

componenti sono stati messi alla prova, quando il software è stato completamente assemblato in un pacchetto e quando

sono stati rilevati e corretti tutti gli errori di interfacciamento. Il collaudo, a questo punto, si concentra sulle azioni

visibili e sull’output del sistema.

La convalida del software si raggiunge attraverso una serie di collaudi che ne dimostrano la conformità rispetto ai

requisiti. Al termine delle prove di convalida sono possibili due casi:

1) le caratteristiche di funzione e prestazione sono conformi alle specifiche e pertanto accettate;

2) si rileva una deviazione dalle specifiche e viene stilato un elenco delle lacune riscontrate.

Le deviazione o gli errori rilevati a questo punto del progetto possono raramente essere corretti prima della data prevista

di termine. È spesso necessario contrattare con il cliente per stabilire un metodo per risolvere tali mancanze.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 6

COLLAUDO DI INTEGRAZIONE. Il Testing di Integrazione è un testing applicato ad un aggregato di due o più

unità di un sistema software. L’obiettivo è quello di rilevare errori nelle interazioni fra le unità e nelle funzioni che

l’aggregato deve assolvere. Non è compito dei programmatori che hanno prodotto le unità componenti. Le unità da

integrare sono selezionabili in base a criteri funzionali ricavabili dal progetto (architettura del sistema). Partendo da una

architettura organizzata gerarchicamente, le integrazioni possono essere realizzate con approccio top-down o botton-

up o mista. Quando ciascun modulo, preso singolarmente, funziona in modo corretto perché dobbiamo dubitare sulla

correttezza del loro funzionamento quando questi vengono aggregati? Il problema consiste nell’interfacciamento: alcuni

dati possono perdersi nell’attraversare una interfaccia. Un modulo può provocare, involontariamente, un effetto

negativo su un altro modulo. Il collaudo di integrazione è una tecnica sistematica per la costruzione della struttura di un

programma conducendo allo stesso tempo prove tese a rilevare errori relativi alle interfacce. L’obiettivo è quello di

costruire la struttura del programma dettata dal disegno, partendo dai moduli che sono stati provati singolarmente. Il

collaudo di integrazione va condotto in modo incrementale: il programma viene costruito e provato in piccoli segmenti,

nei quali è più facile trovare e correggere gli errori, le interfacce si possono provare in modo completo e si può

procedere sistematicamente.

Vediamo ora alcune strategie usate per il collaudo di integrazione:

Integrazione top-down. È un approccio incrementale alla costruzione della struttura di un programma. I moduli

vengono integrati muovendosi lungo la gerarchia di controllo, a partire dal modulo principale di controllo e

incorporando man mano i moduli subordinati, ossia gerarchicamente inferiori nella struttura.

Integrazione bottom-up. Il collaudo per integrazione bottom-up come indica il nome, inizia la costruzione e le prove

dai moduli atomici (ossia dai componenti appartenenti all’ultimo livello della struttura del programma). Poiché i

componenti vengono integrati dal basso verso l’alto, l’elaborazione richiesta per i moduli gerarchicamente inferiori a un

certo livello è sempre disponibile e viene pertanto eliminata la necessità di introdurre moduli fittizi.

Collaudo per regressione. Ogni volta che, nel corso del collaudo di integrazione, si aggiunge un nuovo modulo, il

software cambia. Si formano nuovi cammini del flusso dei dati, nuove operazioni di input/output vengono aggiunte e si

richiamano nuovi blocchi logici di controllo. Queste modifiche possono comportare problemi nelle funzioni che in

precedenza operavano correttamente. Il collaudo per regressione consiste nel rieseguire alcune delle prove già condotte

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 7

al fine di garantire che le modifiche non abbiano prodotto effetti indesiderati. Si devono svolgere collaudi per

regressione ogni volta che si apporta una grossa modifica al software (compresa l’integrazione di nuovi moduli).

L’obiettivo finale del collaudo è quello di trovare il maggior numero possibile di errori con un impegno applicato in un

arco di tempo realistico.

Collaudo di sistema. Alla fine, il software deve essere integrato con gli altri elementi del sistema (per esempio nuovo

hardware, informazioni) e possono quindi essere eseguite prove di integrazione e di convalida. Il collaudo di sistema è

in realtà una serie di prove diverse il cui scopo primario è quello di esercitare completamente il sistema informatico.

Sebbene ciascuna prova abbia un obiettivo distinto, tutte sono finalizzati alla verifica che gli elementi del sistema siano

stati correttamente integrati e svolgano le funzioni a loro assegnate. Il testing di sistema è applicato al sistema software

completo ed integrato. L’obiettivo è quello di valutare l’adesione del sistema ai requisiti specificati. Va effettuato dal

team addetto al testing. I requisiti del sistema non sono solo le funzionalità e fondamentali sono i requisiti di qualità,

stabiliti ad esempio sulla base di un modello di qualità del prodotto opportunamente istanziato.

Testing di accettazione. Il testing viene effettuato sull’intero sistema sulla base di un piano e di procedure approvate

dal cliente (o utente). Segna il passaggio del sistema dal produttore all’ambiente operativo. L’obiettivo è quello di

mettere il cliente, l’utente o altri a ciò preposti (collaudatori o enti ad hoc) in condizione di decidere se accettare il

prodotto. È più una dimostrazione che un test, infatti è a carico del committente. Esistono due livelli di test di

accettazione: alpha testing (uso del sistema da parte di utenti reali ma nell’ambiente di produzione e prima della

immissione sul mercato) e beta testing (installazione ed uso del sistema in ambiente reale prima della immissione sul

mercato).

Collaudi alfa e beta. È virtualmente impossibile per uno sviluppatore software prevedere come il cliente utilizzerà

realmente un programma. Le istruzioni per l’uso possono essere fraintese, possono essere utilizzate regolarmente, strane

combinazioni di dati, risultati apparentemente chiari per il collaudatore possono essere incomprensibili all’utente.

Quando si costruisce software personalizzato sulla base di specifiche esigenze di un cliente, si conduce un serie di prove

d’accettazione per consentire al cliente di convalidare tutti i requisiti.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 8

Il collaudo alfa è condotto dal cliente ma presso il luogo di sviluppo. Il software viene utilizzato dall’utente in modo

normale, sotto il controllo dello sviluppatore, e vengono annotati errori ed eventuali problemi d’uso riscontrati. I test

alfa vengono pertanto condotti in un ambiente controllato.

Il collaudo beta è condotto dall’utente finale presso uno o più clienti. A differenza del test alfa, in questo caso

generalmente lo sviluppatore non è presente. Pertanto, il beta test è un uso “dal vivo” del software, in un ambiente che

non può essere controllato dallo sviluppatore. Il cliente annota tutti i problemi (reali o supposti) riscontrati e li comunica

allo sviluppatore a intervalli regolari. Come risultato dei problemi rilevati, lo sviluppatore software apporta le opportune

modifiche e quindi prepara il rilascio del prodotto software per tutti i clienti.

Collaudo orientato agli oggetti. Nel concetto orientato agli oggetti cambia il concetto delle unità. La definizione delle

classi è determinata dall’incapsulazione. Questo significa che ciascuna classe e ciascuna istanza di una classe (oggetto)

comprende sia gli attributi (i dati) che le operazioni (funzioni) che li manipolano. Una classe incapsulata è normalmente

l’elemento principale del collaudo nelle unità. Tuttavia, le operazioni svolte all’interno della classe sono le più piccole

unità delle quali è possibile eseguire un collaudo.

L’arte del debugging. Il collaudo del software è un processo che può essere pianificato e definito sistematicamente. È

possibile condurre la progettazione dei casi di prova, definire una strategia e valutare i risultati sulla base delle

aspettative. Il debugging è una conseguenza del collaudo; ossia, quando un caso di prova rileva un errore,il debugging è

il processo che porta all’eliminazione di quest’ultimo. Il debugging non è il collaudo ma ne è una conseguenza e tenta di

associare un sintomo con le cause, giungendo in tal modo alla correzione dell’errore. Il processo di debugging può

portare a due risultati: 1) si è trovata la causa e si è proceduto alla correzione; o 2) non si è riusciti a determinare la

causa. Nell’ultimo caso, la persona preposta al debugging può avere un’idea della causa, progettare un caso di prova che

confermi il suo sospetto e cercare l’errore in modo iterativo.

Suddivisione in Classi di Equivalenza

Occorre dividere i possibili input in gruppi i cui elementi si ritiene che saranno trattati similarmente dal processo

elaborativo. Questi gruppi saranno chiamati classi di equivalenza. Una possibile suddivisione è quella in cui classe di

equivalenza rappresenta un insieme di stati validi o non validi per una condizione sulle variabili d’ingresso. Chi esegue

il testing dovrà eseguire un solo test per ogni classe di equivalenza.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli


PAGINE

18

PESO

301.31 KB

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2013-2014

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher cecilialll di informazioni apprese con la frequenza delle lezioni di Fondamenti di informatica e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Napoli Federico II - Unina o del prof Fassolino Rita.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Fondamenti di informatica

Fondamenti di Informatica - von neumann e processore
Dispensa
Fondamenti di Informatica – Dispensa
Dispensa
Appunti di Fondamenti di Informatica
Appunto
Fondamenti di informatica - Esercitazioni
Esercitazione