Mtricas estticas

Las mtricas de anlisis estticas detalladas del componente sometido a

prueba (CUT) pueden ayudarle a decidir cmo priorizar las pruebas. Hay
mtricas que analizan la arquitectura de los componentes, la complejidad de
los componentes y la cobertura de las pruebas.
Las mtricas estticas 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:

Mtricas de arquitectura: nivel de dependencia, abanico de entrada (fanin), ramificado (fan-out) y usuario externo (Ext user). Miden la
complejidad de las relaciones tales como llamadas a mtodo, herencia o
uso de variables.

Mtricas de complejidad de componentes: atributos, mtodos,

sentencias y V(g). Estas mtricas miden la complejidad del flujo de
control del cdigo fuente.

Mtricas de cobertura de las pruebas: lnea y pruebas. Las mtricas de

cobertura indican si es necesario realizar ms pruebas en el cdigo.
Lnea muestra el porcentaje de lneas de cdigo que cubren las pruebas.
Pruebas indica el nmero de pruebas utilizando directamente un mtodo
de la clase.

Utilizar mtricas para planificar las pruebas

Las siguientes sugerencias pueden resultar de utilidad para planificar las
pruebas:

Concntrese en los componentes de pruebas que proporcionen la mayor

cobertura. La mtrica de ramificado (fan-out) representa el nmero de
usos de mtodos o atributos definidos fuera de la clase. Este es un
indicativo de las clases que tienen una alta repercusin sobre la
cobertura. La prueba de clases con una puntuacin alta de ramificado y
sin apndices le permitir probar rpidamente un amplio porcentaje del
cdigo. Por otra parte, las pruebas de unidades estrictas en esas clases
(utilizando apndices para aislar componentes) requerirn mucho
trabajo para crear muchos apndices.

Concntrese en probar los componentes que sean indispensables

funcionalmente. Observe las mtricas como Fan-in, que es el nmero de
atributos pblicos ms el nmero de mtodos pblicos de la clase, o Ext
User, que indica el nmero de componentes externos que utilizan
atributos o mtodos de la clase. Cuanto ms altos sean estos valores,
mayor ser el riesgo de regresin si se realizan cambios en la clase. Por
consiguiente, estas clases debern probarse a fondo.

Concntrese en los componentes ms complejos. Los indicadores de

complejidad son principalmente el nmero de complejidad ciclomtica
(V(g)) y el nmero de sentencias en el cdigo. Normalmente, V(g) vara
entre 1 y 10, donde un valor de 1 significa que el cdigo no tiene
ramificaciones.

Aunque pruebe todos los mtodos de las clases individualmente,

asegrese 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 apndices de las dems, podra
interesarle probar un pequeo clster de entre 3 y 10 clases juntas.

Identifique los subsistemas o los clsteres grandes que debern

probarse como una unidad. Un subsistema deber probarse como una
unidad cuando cumpla cualquiera de los siguientes criterios:
o

Tiene clases con interdependencias que necesita entregar a otro

desarrollador.

Tiene clases interactuando entre ellas y con otras clases que ha

puesto como apndice durante las pruebas a nivel de clase.

Utilice el indicador de nivel para evaluar el nivel de dependencia de una clase

en el grfico de llamada de la aplicacin.
Una vez se ha realizado una primera serie de pruebas, la cadencia de
cobertura de lnea (Lnea) y el nmero de pruebas aplicables a un componente
(Pruebas) le permiten identificar los componentes que las pruebas anteriores
no han cubierto lo suficiente.