Concetto: Misure chiave di test
Questa linea guida presenta misure di qualità e completamento per suite di test.
Relazioni
Descrizione principale

Introduzione

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.

Misure di completamento

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.

Completamento del test basato sui requisiti

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

  • Nell'attività Esegui test, vengono utilizzate due misure di completamento test: una identifica il completamento test raggiunto tramite l'esecuzione dei test e la seconda identifica il completamento test eseguito correttamente (i test eseguiti senza difetti, ossia senza difetti o risultati imprevisti).

    Queste misure di completamento vengono calcolate utilizzando le seguenti equazioni:

    Completamento test (eseguito) = Tx / RfT

    Dove:
    Tx è il numero di test eseguiti, espressi come procedure o scenari di test.

    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.

Completamento del test basato sul codice

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.

Misurazione della qualità percepita

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.

Report di difetti

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.

Report di densità dei difetti

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.

Diagramma di distribuzione dei difetti



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.

Report di età dei difetti

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.

Report di trend dei difetti

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.



Diagramma dei report di trend dei difetti

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.

Diagramma del report di analisi dei trend

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.

Misure delle prestazioni

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.

Monitoraggio dinamico

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.

Monitoraggio dinamico visualizzato come istogramma

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.

Report di produttività e tempo di risposta

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

Diagramma del report di analisi e produttività di esempio

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.

Report delle percentuali

I report di percentuali forniscono un altro calcolo statistico delle prestazioni, visualizzando i valori di percentuale popolamento.

Diagramma del report delle percentuali di esempio

Report di confronto

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.

Report di traccia e di profilo

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.