Metriche di test del software: cos'è, tipi ed esempi
Tommaso Hamilton
⚡ Riepilogo intelligente
Le metriche di test del software sono misure quantitative dei progressi, della qualità e della produttività di un processo di test. Questa guida illustra i tre tipi di metriche, la distinzione tra metriche di base e metriche calcolate, il ciclo di vita delle metriche e un glossario di formule che è possibile applicare direttamente.
Che cosa sono le metriche di test del software?
Metriche di test del software sono le misure quantitative utilizzate per stimare il progresso, la qualità, la produttività e lo stato di salute del processo di test del software. L'obiettivo delle metriche di test del software è migliorare l'efficienza e l'efficacia nel processo di test del software e aiutare a prendere decisioni migliori per ulteriori processi di test fornendo dati affidabili sul processo di test.
Una metrica esprime, in termini quantitativi, il grado in cui un sistema, un componente o un processo possiede un determinato attributo. Un semplice esempio è il consumo settimanale effettivo di carburante di un'auto rispetto al dato dichiarato dal produttore.
Metriche di test del software: migliora l'efficienza e l'efficacia di un processo di test del software.
Le metriche di test del software o la misurazione dei test del software sono l'indicazione quantitativa di estensione, capacità, dimensione, quantità o dimensione di alcuni attributi di un processo o prodotto.
Esempio di misurazione del test del software: Numero totale di difetti
Perché le metriche dei test sono importanti?
“Non possiamo migliorare ciò che non possiamo misurare.” Le metriche di test esistono per rendere misurabile il processo di test.
- Decidere quale dovrebbe essere la fase successiva delle attività
- Fornire prove a sostegno di un'affermazione o di una previsione sulla qualità
- Individuare il tipo di miglioramento necessario
- Giustificare un cambiamento di processo o di tecnologia
Leggi di più su di esso Importanza delle metriche di test
Tipi di metriche di test
- Metriche di processo: Può essere utilizzato per migliorare l'efficienza del processo SDLC (Ciclo di vita dello sviluppo del software)
- Metriche del prodotto: Si occupa della qualità del prodotto software
-
Metriche del progetto: Può essere utilizzato per misurare l'efficienza di un team di progetto o di qualsiasi altro strumenti di test utilizzati dai membri del team
Scegliere le metriche giuste è più importante che raccoglierne molte. Prima di definire un insieme di metriche, considera i seguenti aspetti:
- Fissare il pubblico di destinazione per la preparazione della metrica
- Definire l'obiettivo per le metriche
- Introdurre tutte le metriche rilevanti in base alle esigenze del progetto
- Valuta il rapporto costi-benefici di ogni metrica e la fase del ciclo di vita del progetto in cui essa apporta il maggior valore.
Metriche di test manuali
In Software Engineering, Le metriche dei test manuali sono classificate in due classi
- Metriche di base
- Metriche calcolate
Le metriche di base sono i dati grezzi raccolti dall'Analista del test durante lo sviluppo e l'esecuzione del test case (N. di casi di test eseguiti, N. di casi di test). Mentre le metriche calcolate derivano dai dati raccolti nelle metriche di base. Le metriche calcolate vengono solitamente seguite dal responsabile del test a scopo di reporting del test (% di completamento, % di copertura del test).
A seconda del progetto o del modello di business, le metriche più importanti sono generalmente:
- Metriche di produttività dell'esecuzione dei casi di test
- Metriche di produttività della preparazione dei casi di test
- Metriche dei difetti
- Difetti per priorità
- Difetti per gravità
- Rapporto di slittamento dei difetti
Metriche di test manuali vs. automatizzate
Le metriche descritte sopra si basano su una suite eseguita manualmente. Una suite automatizzata viene misurata in modo diverso, poiché lo sforzo di esecuzione non rappresenta più il fattore limitante.
| Criteri | Metriche dei test manuali | Metriche per i test di automazione |
|---|---|---|
| Focus primario | Progressi nell'impegno e nell'esecuzione | Copertura, stabilità e durata |
| Misura tipica | Casi di test eseguiti al giorno | percentuale di copertura dell'automazione |
| Segnale di qualità | Difetti riscontrati per ora di test | Tasso di test instabili, la percentuale di test non affidabili |
| Misura dei costi | Orari di prova | Ore di manutenzione dello script per rilascio |
| Misura della velocità | Durata del ciclo in giorni | Tempo di esecuzione della suite in minuti |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
Un tasso di test instabile merita particolare attenzione. Una volta superato il 5% circa, i team iniziano a ignorare le build rosse e a quel punto la suite smette di fornire informazioni, indipendentemente dal livello di copertura raggiunto.
Ciclo di vita delle metriche di test nell'ingegneria del software
| Diverse fasi del ciclo di vita delle metriche | Passaggi durante ogni fase |
|---|---|
| Analisi |
|
| Comunicare |
|
| Valutazione |
|
| Relazione |
|
Come calcolare un parametro di valutazione di un test
| signore# | Passaggi per testare le metriche | Esempio |
|---|---|---|
| 1 | Identificare la chiave test del software processi da misurare | Avanzamento dei test tracprocesso del re |
| 2 | In questa fase, il tester utilizza i dati come base per definire le metriche | Il numero di casi di test pianificati per l'esecuzione al giorno |
| 3 | Determinazione delle informazioni da seguire, una frequenza di tracre e la persona responsabile | L'effettiva esecuzione giornaliera del test verrà acquisita dal responsabile del test alla fine della giornata |
| 4 | Calcolo, gestione e interpretazione efficaci delle metriche definite | I casi di test effettivi eseguiti ogni giorno |
| 5 | Identificare le aree di miglioramento in base all’interpretazione delle metriche definite | If caso di prova Se l'esecuzione non raggiunge l'obiettivo concordato, indagare sulle cause e proporre misure correttive. |
Esempio di calcolo di una metrica di test
Prendiamo come esempio la percentuale di casi di test eseguiti. Per esprimere lo stato di esecuzione in percentuale, utilizzare la formula:
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
Se sono stati scritti 250 casi di test e ne sono stati eseguiti 175, il risultato è (175 / 250) x 100 = 70 per cento.
Lo stesso schema si applica a tutti gli altri parametri di esecuzione: casi di test non eseguiti, superati, falliti e bloccati. Ognuno di essi rappresenta semplicemente un numeratore diverso sullo stesso denominatore.
Le metriche di test più importanti da Track
Il glossario alla fine di questo tutorial elenca tutte le formule di uso comune. In pratica, un pacchetto di report raramente ne richiede più di otto. Queste sono quelle che guidano costantemente un processo decisionale.
| Metrico | Cosa risponde | Stai attento |
|---|---|---|
| Percentuale di esecuzione dei casi di test | A che punto siamo del percorso previsto? | Non dice nulla sulla qualità, solo sul progresso. |
| Densità dei difetti | Difetti per unità di misura: qual è quindi il modulo più debole? | Dipende da una misura di dimensione coerente |
| efficienza nella rimozione dei difetti | Quale percentuale di difetti abbiamo individuato prima del rilascio? | Può essere finalizzato solo dopo l'arrivo dei dati di produzione |
| Perdita di difetto | Quanti difetti sono stati riscontrati e segnalati al cliente? | Il segnale di qualità più importante in assoluto |
| Copertura di prova | Quanti dei requisiti stabiliti vengono effettivamente soddisfatti? | Un'elevata copertura con affermazioni deboli non dimostra nulla |
| indice di gravità del difetto | I difetti visibili sono gravi o solo di natura estetica? | Contare i difetti senza ponderazione è fuorviante. |
| Tempo medio di riparazione | Quanto tempo impiega il team a risolvere il problema? | Distorto da alcuni difetti di lunga data |
| produttività dell'esecuzione dei test | Quanti casi completa un tester al giorno? | Incoraggia test superficiali se utilizzato come obiettivo |
Due formule che vale la pena aggiungere al glossario perché sono quelle richieste dalla direzione:
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
La trappola della misurazione. Qualsiasi parametro utilizzato come obiettivo smette di essere una buona misura. Se si imposta un obiettivo di produttività di 30 casi di test al giorno, i tester ne scriveranno 30 banali. I parametri vanno riportati nel loro insieme, mai singolarmente, e ogni dato di produttività deve essere accompagnato da un dato relativo alla qualità.
Glossario delle formule per le metriche di test del software
- Rapporto sforzo di rilavorazione = (Sforzi di rilavorazione effettivi spesi in quella fase/sforzi effettivi totali spesi in quella fase) X 100
- Requisito Creep = (Numero totale di requisiti aggiunti/Numero di requisiti iniziali)X100
- Variazione di programma = (Data di consegna effettiva – Data di consegna pianificata)
- Costo per la ricerca di un difetto durante i test = (Sforzo totale speso per i test/difetti riscontrati nei test)
- Slittamento del programma = (Data di fine effettiva – Data di fine stimata) / (Data di fine pianificata – Data di inizio pianificata) X 100
- Percentuale di casi di test superati = (Numero di test superati/Numero totale di test eseguiti) X 100
- Percentuale di casi di test non riusciti = (Numero di test non riusciti/Numero totale di test eseguiti) X 100
- Percentuale di casi di test bloccati = (Numero di test bloccati/Numero totale di test eseguiti) X 100
- Percentuale difetti fissi = (Difetti risolti/Difetti segnalati) X 100
- Percentuale difetti accettati = (Difetti accettati come validi dal team di sviluppo/Difetti totali segnalati) X 100
- Percentuale differita dei difetti = (Difetti differiti per versioni future/Totale difetti segnalati) X 100
- Percentuale difetti critici = (Difetti critici/Difetti totali segnalati) X 100
- Tempo medio impiegato da un team di sviluppo per riparare i difetti = (Tempo totale impiegato per le correzioni dei bug/Numero di bug)
- Numero di test eseguiti per periodo di tempo = Numero di test eseguiti/Tempo totale
- Testare l'efficienza della progettazione = Numero di test progettati/Tempo totale
- Efficienza della revisione dei test = Numero di test revisionati/Tempo totale
- Tasso di rilevamento dei bug, ovvero difetti per ora di prova = Numero totale di difetti / Numero totale di ore di prova
