Complejidad Ciclomtica

La Complejidad Ciclomtica (en ingls, Cyclomatic Complexity) es una mtrica del

software que proporciona una medicin cuantitativa de la complejidad lgica
de un programa.
El resultado obtenido en el clculo de la complejidad ciclomtica define el nmero
de caminos independientes dentro de un fragmento de cdigo y determina la cota
superior del nmero de pruebas que se deben realizar para asegurar que se
ejecuta cada sentencia al menos una vez, (es decir, un if, else, for, while, etc)
La complejidad se mide de acuerdo al siguiente ranking:
# Mtodos

1-10
11-20
21-50
50

Categora
Programa Simple, sin mucho
riesgo.
Ms complejo, riesgo moderado.
Complejo, Programa de alto
riesgo.
Programa no testeable, Muy alto
riesgo.

De esta manera se encuentra que un valor 10 es un lmite superior prctico para el

tamao de un mdulo. Cuando la complejidad supera dicho valor se hace muy
difcil probarlo, entenderlo y modificarlo. La limitacin deliberada de la complejidad
en todas las fases del desarrollo ayuda a evitar los problemas asociados a
proyectos de alta complejidad.
Dentro de Sonar esto se puede ver en el cuadrado denominado Complexity:

Donde podemos observar que tenemos 2.6 de media por mtodo y 9.9 de media
por clase (cifras ambas muy engaosas). Ya que si pulsamos sobre mtodos (por
ejemplo) podemos ver que hay mtodos que suben hasta un valor de 61 en la
complejidad ciclomtica.

Para calcular la complejidad ciclomtica se tiene la siguiente frmula:

L N + 2P
Dnde:
L = nmero de aristas/enlaces en un grafo
N = nmero de nodos en un grafo
P = nmero de partes desconectadas del grafo (por ejemplo un grafo invocado y
una subrutina

Tcnicas de Caja Blanca

Qu es?

Las tcnicas de Caja Blanca son tcnicas dinmicas de diseo de pruebas.

Las pruebas de Caja Blanca exploran la estructura de los programas. En
vez de probar la totalidad del cdigo, se aseguran que una serie de
elementos particulares del cdigo funcionan correctamente.

Para qu sirve?

Orientadas a la medicin de la cobertura de las pruebas realizadas.

Se emplea durante el diseo de casos de prueba, en combinacin con

tcnicas de Caja Negra, para aadir casos de pruebas adicionales distintos
a las pruebas ya existentes, aumentando as la cobertura de pruebas.

Caractersticas

Tambin llamadas tcnicas estructurales ya que se basan en la

estructura del cdigo.

Existen dos tipos principalmente: Pruebas de Decisin y Pruebas de

Sentencia.

Cundo se utiliza?

Durante el diseo de casos de prueba en combinacin con tcnicas de Caja

Negra.

En cualquiera de los niveles de pruebas, pero especialmente en los niveles

de pruebas Unitarias y de Integracin.

Tipos

Pruebas de Sentencia
o Con este tipo de pruebas se irn probando las distintas sentencias a
lo largo del cdigo, de forma que se obtenga una cobertura de
sentencia total si se prueban, al menos una vez, todas las sentencias
ejecutables del cdigo.
o La cobertura de sentencias no est considerada como una medida
adecuada para probar la efectividad:
Cobertura = (N de sentencias ejecutables ejecutadas / N
sentencias ejecutables) x 100.

Pruebas de Decisin
o El objetivo de estas pruebas es asegurar que las decisiones lgicas
de un programa son realizadas adecuadamente.
o Para probar una decisin, las condiciones asociadas deben probarse
tanto cuando son verdaderas como cuando son falsas, de esta
forma, se garantiza que todas las posibles salidas se han verificado.

o Las pruebas de decisin tambin tienen una medida de cobertura:

Cobertura = (N de sentencias probadas / N decisiones totales en un
programa) x 100
o La cobertura de decisin incluye a la cobertura de sentencia, siendo
por lo tanto, ms rigurosa. Un 100% de cobertura de decisiones
siempre garantiza un 100% de cobertura de sentencias, per no al
revs.

Ejemplo

1. Pruebas de sentencia y decisin

En la siguiente figura podemos ver el diagrama de flujo de una mquina
dispensadora de bebidas.

A priori, podramos disear los siguientes casos de prueba:

o Test 1: Seleccin de Fro
o Test 2: Seleccin de Caliente, leche y azcar
Si analizamos los casos de prueba, todas las sentencias (representadas
por rectngulos) han sido cubiertas por los dos tests, por lo que obtenemos
el 100% de cobertura de sentencias.
Si continuamos con el anlisis, observaremos que los casos de prueba no
estn teniendo en cuenta las posibles salidas No ante las preguntas de
leche? y azcar?; por lo tanto, tenemos dos condiciones que no han
sido cubiertas todava. Entre los dos casos de prueba, hemos cubierto slo
4 de las 6 decisiones posibles, por lo que, nuestra cobertura de decisin es
de 4/6, o de un 67%
En este punto necesitaramos aadir casos de prueba adicionales para
alcanzar el 100% de la cobertura de decisin, por ejemplo:
o Test 3: Seleccin Caliente, sin leche y sin azcar

Esta prueba cubre las dos decisiones negativas a la vez con lo que
obtendramos el 100% de la cobertura de decisin

Revisin entre pares (PEER REVIEW)

Qu es?

Es una tcnica esttica de revisin sobre productos de trabajo, ya sea cdigo

fuente, documentos de especificacin de requisitos, diseos funcionales, diseos
tcnicos, planificaciones...
Para qu sirve?

Se emplea durante las revisiones documentales para mejorar la calidad y

productividad del desarrollo software. Ayuda a encontrar defectos como
desviaciones de los estndares, defectos de requisitos, defectos de diseo,
mantenibilidad insuficiente o especificaciones de interfaz incorrectas.
Caractersticas

Es una tcnica esttica, no ejecuta cdigo.

Complementan a las pruebas dinmicas, no las sustituyen.
Reduce el nmero de defectos en etapas tempranas del ciclo de vida del producto,
que redunda en la reduccin de esfuerzos y costes en la futura resolucin de
defectos.
En el equipo de revisores, se incluye una persona con un puesto similar al del
autor del artefacto (par).

Cundo se utiliza?

Durante la revisin de los principales documentos generados por el equipo de

Desarrollo.

En cualquiera de las fases de desarrollo que generen documentacin o cdigo

fuente.

Inconvenientes y/o errores a evitar

No contar con el tiempo suficiente para realizar la preparacin de la

revisin.
Estructurar el equipo de revisin sin tener en cuenta su experiencia,
conocimiento y habilidades.
No posponer la reunin si alguno de los miembros clave no est disponible.
Sobrepasar las dos horas de revisin. Si el producto a revisar es muy
extenso, se deben planificar varias sesiones.

Mtodo de desarrollo: Pasos

Preparacin
Revisin
Implementacin
Cierre

Mtodo de desarrollo: Detalle

Preparacin
Se identifican y documentan los productos que necesitarn revisarse mediante una
revisin entre pares, segn la complejidad y criticidad de los productos.
Se forma el equipo de revisores en funcin del artefacto a revisar. En general, un
artefacto debe ser revisado por:

El autor
Alguien que base su trabajo posterior en el artefacto bajo revisin
Compaeros del autor (pares)
Cualquier responsable de un componente con el que el artefacto bajo revisin
interacte
Se identifican los estndares que se van a usar en la revisin y se establecen
criterios de conformidad.
El autor informa a los revisores sobre la disponibilidad del producto para su
revisin.
El autor distribuye a los revisores el producto a revisar y los documentos de
soporte a la revisin, como por ejemplo, listas de indicadores de revisin
documental.
Se fija la fecha de la revisin.
Revisin
Los revisores estudian el producto de trabajo junto con los documentos de soporte
y anotan sus conclusiones.
Los revisores registran los defectos detectados en la herramienta de gestin de
defectos y/o en los informes de revisin.
Los revisores reportan al autor tanto los defectos detectados como los productos
revisados.
El autor repasa los defectos detectados conjuntamente con los revisores hasta que
se logra el consenso por todas las partes. Se actualiza el registro de defectos si
fuera necesario.
Implementacin
El autor revisa el registro de defectos actualizado, e identifica las acciones
apropiadas para su correccin.

El autor subsana los defectos creando una nueva versin del documento que
entrega a los revisores.
Los revisores revisan de nuevo el artefacto con respecto al registro de revisin y
dan su aprobacin si procede. Si no estuvieran de acuerdo con alguna
subsanacin, los revisores informaran al autor y actualizaran de nuevo el registro
de defectos.
Cierre
Una vez aprobado el artefacto, los revisores actualizan el esfuerzo invertido en la
revisin, incluyendo las revisiones sobre las subsanaciones, y el tamao del
artefacto.

Pruebas de Caja Negra

Concep
to:

La prueba de Caja Negra se centra

principalmente en los requisitos
funcionales del software.

Estas pruebas permiten obtener un conjunto de condiciones de entrada que

ejerciten completamente todos los requisitos funcionales de un programa. En ellas
se ignora la estructura de control, concentrndose en los requisitos funcionales del
sistema y ejercitndolos.
La prueba de Caja Negra no es una alternativa a las tcnicas de prueba de la Caja
Blanca, sino un enfoque complementario que intenta descubrir diferentes tipos de
errores a los encontrados en los mtodos de la Caja Blanca. Muchos autores
consideran que estas pruebas permiten encontrar:
1. Funciones incorrectas o ausentes.
2. Errores de interfaz.
3. Errores en estructuras de datos o en accesos a las Bases de Datos externas.
4. Errores de rendimiento.
5. Errores de inicializacin y terminacin.

Para preparar los casos de pruebas hacen falta un nmero de datos que ayuden a
la ejecucin de los estos casos y que permitan que el sistema se ejecute en todas
sus variantes, pueden ser datos vlidos o invlidos para el programa segn si lo
que se desea es hallar un error o probar una funcionalidad. Los datos se escogen
atendiendo a las especificaciones del problema, sin importar los detalles internos
del programa, a fin de verificar que el programa corra bien.
Para desarrollar la prueba de caja negra existen varias tcnicas, entre ellas estn:
1. Tcnica de la Particin de Equivalencia: esta tcnica divide el campo de entrada
en clases de datos que tienden a ejercitar determinadas funciones del software.
2. Tcnica del Anlisis de Valores Lmites: esta Tcnica prueba la habilidad del
programa para manejar datos que se encuentran en los lmites aceptables.

3. Tcnica de Grafos de Causa-Efecto: es una tcnica que permite al encargado de la

prueba validar complejos conjuntos de acciones y condiciones.