Métricas estáticas

Las métricas de análisis estáticas detalladas del componente sometido a prueba (CUT) pueden ayudarle a decidir cómo priorizar las pruebas. Hay métricas que analizan la arquitectura de los componentes, la complejidad de los componentes y la cobertura de las pruebas.

Las métricas estáticas se visualizan en el asistente Prueba de componente Java nuevo, tras haber seleccionado los archivos fuente que componen el CUT. En este punto puede ordenar, ocultar y mostrar los datos en orden para determinar la mejor estrategia de prueba:

Utilizar métricas para planificar las pruebas

Las siguientes sugerencias pueden resultar de utilidad para planificar las pruebas:
  • Concéntrese en los componentes de pruebas que proporcionen la mayor cobertura. La métrica de ramificado (fan-out) representa el número de usos de métodos o atributos definidos fuera de la clase. Este es un indicativo de las clases que tienen una alta repercusión sobre la cobertura. La prueba de clases con una puntuación alta de ramificado y sin apéndices le permitirá probar rápidamente un amplio porcentaje del código. Por otra parte, las pruebas de unidades estrictas en esas clases (utilizando apéndices para aislar componentes) requerirán mucho trabajo para crear muchos apéndices.
  • Concéntrese en probar los componentes que sean indispensables funcionalmente. Observe las métricas como Fan-in, que es el número de atributos públicos más el número de métodos públicos de la clase, o Ext User, que indica el número de componentes externos que utilizan atributos o métodos de la clase. Cuanto más altos sean estos valores, mayor será el riesgo de regresión si se realizan cambios en la clase. Por consiguiente, estas clases deberán probarse a fondo.
  • Concéntrese en los componentes más complejos. Los indicadores de complejidad son principalmente el número de complejidad ciclomática (V(g)) y el número de sentencias en el código. Normalmente, V(g) varía entre 1 y 10, donde un valor de 1 significa que el código no tiene ramificaciones.
  • Aunque pruebe todos los métodos de las clases individualmente, asegúrese de definir pruebas a nivel de clase. Esto no significa necesariamente que necesite probar cada clase individual. Por ejemplo, si tiene unas cuantas clases emparejadas tan estrechamente que para probar una clase necesita crear apéndices de las demás, podría interesarle probar un pequeño clúster de entre 3 y 10 clases juntas.
  • Identifique los subsistemas o los clústeres grandes que deberán probarse como una unidad. Un subsistema deberá probarse como una unidad cuando cumpla cualquiera de los siguientes criterios:
    • Tiene clases con interdependencias que necesita entregar a otro desarrollador.
    • Tiene clases interactuando entre ellas y con otras clases que ha puesto como apéndice durante las pruebas a nivel de clase.
    Utilice el indicador de nivel para evaluar el nivel de dependencia de una clase en el gráfico de llamada de la aplicación.
  • Una vez se ha realizado una primera serie de pruebas, la cadencia de cobertura de línea (Línea) y el número de pruebas aplicables a un componente (Pruebas) le permiten identificar los componentes que las pruebas anteriores no han cubierto lo suficiente.

Consulta relacionada
Consulta de métricas estáticas

Condiciones de uso | Comentarios
(C) Copyright IBM Corporation 2000, 2004. Reservados todos los derechos.