Metriche statiche

Dettagliate metriche statiche di analisi del componente sottoposto a verifica (CUT) possono contribuire a scegliere in che modo prioritizzare le verifiche. Esistono metriche che analizzano l'architettura del componente, la complessità del componente e la copertura della verifica.

Le metriche statiche vengono visualizzate nella nuova procedura guidata di Verifica componenti Java, dopo che sono stati selezionati i file origine che costituiscono il CUT. In questa fase è possibile ordinare, nascondere e visualizzare i dati per determinare la migliore strategia di verifica:

Utilizzo delle metriche per pianificare le verifiche

I suggerimenti che seguono possono risultare utili per la pianificazione delle verifiche:
  • Concentrarsi sulla verifica dei componenti che forniscono il maggior tasso di copertura. La metrica Fan out rappresenta il numero di utenti di metodi o attributi definiti al di fuori della classe. Si tratta di una buona indicazione su quali classi hanno un elevato impatto sul tasso di copertura. Le classi di verifica con un elevato punteggio Fan out senza nessuno stub consentiranno di verificare rapidamente un'ampia percentuale del codice. Al contrario, una verifica approfondita di ciascuna unità in queste classi (utilizzando gli stub per isolare i componenti) richiederà un'ampia mole di lavoro per la creazione degli stub.
  • Concentrarsi sulla verifica dei componenti che sono critici da un punto di vista funzionale. Verificare le metriche come Fan in, che rappresenta il numero di attributi pubblici più il numero di metodi pubblici all'interno della classe, o come Estensione utente, che indica il numero di componenti esterni che utilizzano attributi o metodi della classe. Quanto più alti sono questi valori, tanto maggiore è il rischio di regressione nel caso di modifiche alla classe. Tali classi dovrebbero essere verificate in modo approfondito.
  • Concentrarsi sui componenti più complessi. Gli indicatori di complessità sono principalmente il numero di complessità ciclomatica (V(g)) e il numero di istruzioni all'interno del codice. Tipicamente, il valore V(g) varia tra 1 e 10, dove 1 significa che il codice non presenta ramificazioni.
  • Anche se tutti i metodi delle classi vengono verificati singolarmente, è consigliabile definire delle verifiche a livello di classe. Ciò non significa che sia necessario verificare ciascuna classe singolarmente. Ad esempio, se si dispone di poche classi che sono abbinate così strettamente che per verificarne una è necessario effettuare lo stub delle altre, è possibile prendere in considerazione la verifica di un piccolo gruppo composto da 3 a 10 classi.
  • Identificare i sottosistemi o i grandi gruppi che dovrebbero essere verificati come un'unità. Un sottosistema dovrebbe essere verificato come un'unità quando risponde a uno dei criteri che seguono:
    • Si dispone di classi con interdipendenze che si desidera consegnare a un altro sviluppatore.
    • Si dispone di classi che interagiscono al proprio interno e con altre classi di cui si è effettuato lo stub durante la verifica a livello di classe.
    Utilizzare l'indicatore di livello per valutare il livello di dipendenza di una classe in un grafico di chiamata dell'applicazione.
  • Una volta che è stata eseguita una prima serie di verifiche, il tasso di copertura delle linee (Linea) e il numero di verifiche che si applicano a un componente (Verifiche) consentiranno di identificare qualsiasi componente che non è stato ancora sufficientemente coperto dalle verifiche precedenti.

Riferimenti correlati
Riferimento metriche statiche

Termini di utilizzo | Feedback
(C) Copyright IBM Corporation 2000, 2004. Tutti i diritti riservati.