Le misure chiave di un test includono il completamento e la qualità.
Il completamento del test è una misurazione della completezza di verifica e si basa sul completamento della verifica
espresso dal completamento dei requisiti di test e dagli scenari di test o dal completamento del codice eseguito.
La qualità è una misura di affidabilità, stabilità e prestazioni dell'obiettivo del test (sistema o applicazione
sottoposti a test). La qualità si basa sulla valutazione dei risultati del test e sull'analisi delle richieste di
modifica (difetti) identificate durante la verifica.
Le metriche di completamento forniscono risposte alla domanda : "Quanto è completa la verifica?" Le misure di
completamento utilizzate più frequentemente si basano sul completamento dei requisiti software e del codice sorgente.
Fondamentalmente, il completamento del test è una misura di completezza rispetto a un altro requisito (basato sul
requisito) o ai criteri di implementazione e di progettazione (basati sul codice), come la verifica dei casi d'uso
(basata sul requisito) o l'esecuzione di tutte le righe di codice (basata sul codice).
Qualsiasi attività di verifica sistematica si basa su almeno una strategia di copertura test. Tale strategia guida la
progettazione degli scenari di test, indicando lo scopo generale della verifica. L'istruzione della strategia di
completamento può essere semplice come la verifica di tutte le prestazioni.
Una strategia di completamento basata sui requisiti potrebbe essere sufficiente per produrre una misurazione
quantificabile di completezza se i requisiti sono catalogati completamente. Ad esempio, se tutti i requisiti del test
delle prestazioni sono stati identificati, è possibile fare riferimento ai risultati del test per ottenere delle
misurazioni; ad esempio il 75% dei requisiti del test delle prestazioni sono stati verificati.
Se viene applicato un completamento basato sul codice, le strategie di test vengono formulate in termini di quanta
parte del codice sorgente è stata eseguita dai test. Questo tipo di strategia di completamento test è molto importante
per sistemi critici per la sicurezza.
Entrambe le misurazioni possono essere ottenute manualmente (utilizzando le equazioni fornite nelle due successive
intestazioni) o possono essere calcolate tramite gli strumenti di automazione verifica.
Il completamento del test basato sui requisiti, misurata diverse volte durante il test, identifica il completamento del
test in un milestone nella durata della verifica, come il completamento del test pianificato, implementato, eseguito e
completato correttamente.
-
Il completamento del test viene calcolato utilizzando la seguente equazione:
Completamento test = T(p,i,x,s) / RfT
Dove:
T è il numero di Test (pianificati, eseguiti o completati correttamente), espressi come procedure o scenari di
test.
RfT è il numero totale di Requisiti per test (Requirement for Test).
-
Nell'attività Pianifica test, il completamento del test viene calcolato per determinare il completamento del test
pianificato nel seguente modo:
Completamento test (pianificato) = T(p) / RfT
Dove:
Tp è il numero di test pianificati, espressi come procedure o scenari di test.
RfT è il numero totale di Requisiti per test (Requirement for Test).
-
Nell'attività Implementa test, man mano che le procedure di test vengono implementate (come script di test), il
completamento del test viene calcolato utilizzando la seguente equazione:
Completamento test (implementato) = Ti / RfT
in questo caso:
Ti è il numero di Test implementati, espresso dal numero di procedure o di scenari di test,
per cui esistono script di test corrispondenti.
RfT è il numero totale di Requisiti per test (Requirement for Test).
Completamento test riuscito (eseguito) = Ts / RfT
Dove:
Ts è il numero di test eseguiti, espressi come procedure o scenari di test completati
correttamente, senza difetti.
RfT è il numero totale di Requisiti per test (Requirement for Test).
Convertendo i suddetti indici in percentuali, si ottiene la seguente istruzione di completamento test basata sui
requisiti:
x% di scenari di test (T(p,i,x,s) nelle suddette equazioni) sono stati completati con un
indice di esito positivo del y%
E' possibile stabilire una corrispondenza tra questa istruzione significativa di completamento test e i criteri di
esito positivo definiti. Nel caso non siano stati soddisfatti i criteri, l'istruzione fornisce una base per predire
l'impegno lavorativo rimanente per le verifiche.
Le misure di completamento del test basato sul codice sono state eseguite durante il test, confrontate alla parte di
codice che ancora deve essere eseguito. Il completamento del codice può essere basato sui flussi di controllo
(istruzione, ramo o percorsi) o sui flussi di dati.
-
Nel completamento del flusso di controllo, lo scopo è verificare le righe di test del codice, le condizioni del
ramo, i percorsi tramite il codice o altri elementi del flusso di controllo del software.
-
Nel completamento del flusso di dati, lo scopo è verificare che lo stato dei dati rimanga valido tramite
l'operazione del software; ad esempio, che un elemento di dati venga definito prima di essere utilizzato.
Il completamento del test basato sul codice viene calcolato utilizzando la seguente equazione:
Completamento test = Ie / TIic
Dove:
Ie è il numero di voci eseguite, espresse come istruzioni, rami e percorsi di codice, punti
di decisione dello stato dei dati o nomi di elemento dei dati.
TIic è il numero totale di voci nel codice.
Convertendo tale indice in una percentuale, si ottiene la seguente istruzione di completamento del test basato sul
codice:
x% di scenari di test (I nella suddetta equazione) sono stati completati con un indice di esito positivo del y%
E' possibile stabilire una corrispondenza tra questa istruzione significativa di completamento test e i criteri di
esito positivo definiti. Nel caso non siano stati soddisfatti i criteri, l'istruzione fornisce una base per predire
l'impegno lavorativo rimanente per le verifiche.
Sebbene la valutazione del completamento test fornisca una misurazione dell'estensione della completezza dell'impegno
lavorativo per le verifiche, la valutazione dei difetti rilevati fornisce la migliore indicazione della qualità
software sperimentata. E' possibile utilizzare tale percezione della qualità per riconoscere la qualità generale del
sistema software. La qualità software percepita è una misurazione della capacità del software di soddisfare i propri
requisiti, quindi, in questo contesto, i difetti sono considerati come un tipo di richiesta di modifica in cui
l'obiettivo del test non è riuscito a soddisfare i requisiti software.
La valutazione dei difetti può basarsi su metodi che spaziano dai semplici calcoli di difetti a una modellazione
statistica rigorosa.
La valutazione rigorosa utilizza presupposizioni relative alle frequenze di rilevazione o di arrivo dei difetti durante
il processo di verifica. Un modello comune presuppone che la frequenza segua una distribuzione Poisson. I dati
effettivi sull'incidenza dei difetti vengono quindi adattati al modello. La valutazione risultante calcola
l'affidabilità del software corrente e predice l'indice di crescita di tale affidabilità, nel caso la verifica e la
rimozione dei difetti dovessero continuare. Tale valutazione viene descritta come modellazione di crescita
dell'affidabilità del software ed è un'area di esame attivo. A causa della mancanza di supporto di tool per questo tipo
di valutazione, si consiglia di bilanciare attentamente il costo dell'utilizzo di questo approccio con i vantaggi
ottenuti.
Analisi dei difetti implica l'analisi della distribuzione dei difetti sui valori di uno o più attributi
associati a un difetto. L'analisi dei difetti fornisce un'indicazione dell'affidabilità del software.
Nell'analisi dei difetti, vengono analizzati comunemente quattro attributi principali dei difetti:
-
Stato - lo stato corrente del difetto (aperto, in fase di correzione, chiuso e così via.
-
Priorità - l'importanza relativa di questo difetto in fase di esame e di risoluzione.
-
Severità - l'impatto relativo di questo difetto per l'utente, per un'organizzazione, per terze parti e così
via.
-
Origine - ubicazione e significato dell'errore di origine che da' come risultato questo difetto o il
componente che verrà corretto per eliminare questo difetto.
I conteggi dei difetti possono essere riportati come funzione temporale, creando un report o un diagramma Trend dei
difetti. Essi possono anche essere riportati in un Report di densità del difetto come funzione di uno o più attributi
del difetto, ad esempio la severità o lo stato. Questi tipi di analisi forniscono una prospettiva sui trend o sulla
distribuzione di difetti che rivelano l'affidabilità del software.
Ad esempio, è previsto che le frequenze di rilevazione dei difetti diminuiranno con l'avanzamento della verifica e
della correzione. E' possibile stabilire una soglia di qualità scarsa o del difetto, in cui la qualità del software
sarà inaccettabile. I conteggi dei difetti possono essere riportati anche sull'origine del modello di implementazione,
che consente la rilevazione di "modelli deboli", "aree sensibili" e parti del software che subiscono continue
correzioni, il che indica ulteriori punti deboli di progettazione fondamentali.
In un'analisi di tale tipo, vengono inclusi solo difetti confermati. Non tutti i difetti riportati denotano un punto
debole effettivo; alcuni potrebbero essere richieste di potenziamento esterne all'ambito del progetto o potrebbero
descrivere un difetto già riportato. Tuttavia, è utile esaminare e analizzare perché numerosi difetti, duplicati o non
confermati, vengono riportati.
Il RUP (Rational Unified Process) consiglia una valutazione dei difetti basata su più categorie di creazione report,
nel seguente modo:
-
I report di distribuzione dei difetti (Densità) consentono la visualizzazione dei conteggi dei difetti come
funzione di uno o più attributi dei difetti.
-
I report di età del difetto sono un tipo speciale di report di distribuzione dei difetti. I report di età di un
difetto visualizzano per quanto tempo un difetto è rimasto in uno stato particolare, ad esempio Aperto. In
qualsiasi categoria di età, i difetti possono anche essere ordinati tramite un altro attributo, ad esempio il
Proprietario.
-
I report di trend dei difetti mostrano i conteggi dei difetti, per stato (nuovo, aperto o chiuso) come funzione
temporale. I report di trend possono essere cumulativi o non cumulativi.
Molti di questi report sono utili per la valutazione della qualità del software. Essi sono utili soprattutto quando
vengono analizzati insieme ai report di avanzamento e ai risultati del test che visualizzano i risultati dei test
condotti su una serie di iterazioni e cicli di test per l'applicazione sottoposta a test. I consueti criteri di test
includono un'istruzione relativa al numero di difetti aperti tollerabili in particolari categorie, come ad esempio la
classe di severità, che viene controllata con una valutazione della distribuzione dei difetti. Tramite ordinamento e
raggruppamento di questa distribuzione da parte delle motivazioni test, la valutazione può incentrarsi su importanti
aree di interesse.
Per produrre report di tale tipo in modo efficace, normalmente è richiesto un supporto di tool.
Stato di un difetto rispetto a priorità
Associare a ogni difetto una priorità. E' generalmente pratico e sufficiente disporre di quattro livelli di priorità,
come ad esempio:
-
Priorità urgente (risolvere immediatamente)
-
Priorità elevata
-
Priorità normale
-
Priorità bassa
Nota: i criteri per un test completato correttamente possono essere espressi in termini di aspetto della
distribuzione dei difetti su questi livelli di priorità. Ad esempio, i criteri dei test completati correttamente
potrebbero essere "nessun difetto di Priorità 1 e meno di cinque difetti di Priorità 2 sono aperti". Viene generato un
diagramma di distribuzione dei difetti, come il seguente.
E' chiaro che i criteri non siano stati soddisfatti. E' necessario che tale diagramma includa un filtro per
visualizzare solo difetti aperti, come richiesto dai criteri di test.
Stato di un difetto rispetto a severità
I report di severità dei difetti mostrano il numero di difetti presenti per ogni classe di severità; ad esempio, errore
irreversibile, funzione principale non eseguita, errore minore.
Stato di un difetto rispetto a ubicazione nel modello Implementazione
I report di origine difetto mostrano la distribuzione dei difetti su elementi nel modello Implementazione.
L'analisi dell'età di un difetto forniscono un buon feedback sull'efficacia delle attività di verifica e rimozione dei
difetti. Ad esempio, se la maggioranza di difetti meno recenti e non risolti si trova in uno stato di convalida in
sospeso, ciò indica probabilmente che, all'impegno di ulteriore verifica, non vengono applicate sufficienti risorse.
I report dei trend di difetti identificano l'incidenza dei difetti e forniscono una vista particolarmente buona dello
stato della verifica. I trend dei difetti seguono un modello abbastanza prevedibile in un ciclo di verifica. Nella
prima parte del ciclo, l'incidenza dei difetti aumenta rapidamente, quindi raggiunge un picco e diminuisce più
lentamente nel tempo.
Per individuare i problemi, è possibile esaminare la pianificazione del progetto alla luce di tale trend. Ad esempio,
se l'incidenza dei difetti è in aumento nella terza settimana di un ciclo di test di quattro settimane, il progetto non
rispetta, evidentemente, la pianificazione.
Questa semplice analisi di trend presuppone una correzione istantanea dei difetti e una verifica delle correzioni in
build successive, quindi l'incidenza di chiusura difetti dovrebbe seguire lo stesso profilo dell'incidenza di
rilevazione difetti. Quando ciò non si verifica, è possibile che sia presente un problema nel processo di risoluzione
dei difetti: le risorse di correzione dei difetti o le risorse per verificare e convalidare le correzioni potrebbero
essere inadeguate.
Il trend riflettuto in tale report mostra che i nuovi difetti vengono rilevati e aperti rapidamente all'inizio del
progetto e che diminuiscono con il tempo. Il trend per aprire i difetti è simile a quello per i nuovi difetti, ma
impiega un tempo leggermente superiore. Il trend per chiudere i difetti aumenta nel tempo man mano che i difetti
vengono corretti e verificati. Tali trend descrivono un impegno lavorativo impiegato correttamente.
Se i trend si allontanano sensibilmente da questi, è possibile che sia presente un problema e che sia necessario
applicare ulteriori risorse a specifiche aree di sviluppo o di verifica.
Quando combinata con le misurazioni di completamento test, l'analisi dei difetti fornisce una valutazione molto valida
su cui basare i criteri di completamento test.
Vengono utilizzate diverse misure per la valutazione delle funzionalità delle prestazioni dell'obiettivo del test e per
l'evidenziazione della cattura di dati relativi alle funzionalità, ad esempio il tempo di risposta, i profili di
tempificazione, l'affidabilità operativa e i limiti. Principalmente, tali misure vengono valutate nell'attività Valuta
test, tuttavia, esistono misure delle prestazioni utilizzate durante l'attività Esegui test per valutare lo stato e
l'avanzamento del test.
Le misure delle prestazioni principali includono:
-
Monitoraggio dinamico - cattura in tempo reale e visualizzazione dello stato di ogni script di test
effettuato durante l'esecuzione del test.
-
Report di produttività e tempo di risposta - misurazione dei tempi di risposta e produttività dell'obiettivo
del test per attori e casi d'uso specificati.
-
Report di percentuale - misurazione della percentuale e calcolo dei valori dei dati raccolti.
-
Report di confronto - differenze o trend tra due (o più) serie di dati che rappresentano diverse esecuzioni
di test.
-
Report di traccia - dettagli dei messaggi e delle conversazioni tra l'attore (script di test) e l'obiettivo
del test.
Il monitoraggio dinamico fornisce una creazione di report e una visualizzazione in tempo reale durante l'esecuzione del
test, generalmente nel formato di un istogramma o di un grafico. Il report esegue il monitoraggio o la valutazione
visualizzando lo stato corrente e l'avanzamento degli script di test.
Ad esempio, nell'istogramma precedente, sono presenti 80 script di test che eseguono lo stesso caso d'uso. In questo
grafico, 14 script di test si trovano in stato Inattivo, 12 nella Query, 34 in SQL Execution, 4 in SQL Connect e 16 in
altro stato. Con l'avanzamento del test, è previsto che il numero di script in ogni stato cambi. L'output visualizzato
è tipico di un'esecuzione di test effettuata normalmente e si trova nel mezzo della relativa esecuzione. Tuttavia, se
gli script di test rimangono in uno stato o non visualizza le modifiche durante l'esecuzione del test, ciò potrebbe
indicare un problema con l'esecuzione del test o la necessità di implementazione o di valutazione di altre misure di
prestazioni.
I report di produttività e del tempo di risposta, come indica il nome, misurano e calcolano le funzionalità delle
prestazioni relative al tempo e alla produttività (numero di transazioni elaborate). Normalmente, tali report vengono
visualizzati come un grafico con tempo di risposta (o numero di transazioni) sull'asse "y" ed eventi sull'asse "x".
E' spesso utile calcolare e visualizzare informazioni statistiche, come la deviazione media e standard dei valori di
dati oltre alla visualizzazione dell'effettiva funzionalità delle prestazioni.
I report di percentuali forniscono un altro calcolo statistico delle prestazioni, visualizzando i valori di percentuale
popolamento.
E' importante confrontare i risultati di un'esecuzione del test delle prestazioni con quelli di un'altra, quindi è
possibile valutare l'impatto delle modifiche apportate tra le esecuzioni di test sulle funzionalità delle prestazioni.
Utilizzare i report di confronto per visualizzare le differenze tra due serie di dati (ognuna rappresentante differenti
esecuzioni di test) o trend tra diverse esecuzioni di test.
Quando le funzionalità delle prestazioni non sono accettabili o quando il monitoraggio delle prestazioni indica
possibili colli di bottiglia (ad esempio quando gli script di test rimangono in uno stato specificato per periodi
estremamente lunghi), la creazione di report della traccia potrebbe costituire il report più valido. I report di
traccia e di profilo visualizzano informazioni di livello inferiore. Queste informazioni includono i messaggi tra
l'attore e l'obiettivo del test, il flusso di esecuzione, l'accesso ai dati e le chiamate di sistema e di funzione.
|