Pruebas de Software Pgina 1

PRUEBAS DE UNIDAD

La prueba de unidad se centra en la verificacin de los elementos ms pequeos del software que se puedan
probar (unidades). Normalmente, las pruebas de unidad se aplican a componentes representados en el modelo
de implementacin para verificar que se cubren los flujos de control y los flujos de datos y que funcionan
como se esperaba. El implementador realiza la prueba de unidad mientras se desarrolla la unidad. Los detalles
de la prueba de unidad se describen en la disciplina de implementacin.

Las pruebas de diseo y de implementacin que se centran en la estructura interna de una unidad se basan en
el conocimiento de la implementacin de la unidad (enfoque de caja blanca). El diseo y la implementacin
de pruebas para verificar los comportamientos observables de una unidad y sus funciones no se basan en el
conocimiento de la implementacin y por lo tanto se conocen como enfoque de caja negra.

Ambos enfoques se utilizan para disear e implementar diferentes tipos de pruebas necesarios para probar las
unidades satisfactoriamente y completamente.

Enfoque de prueba de caja blanca

Un enfoque de prueba de caja blanca debe adoptarse para verificar la estructura interna de una unidad.
Tericamente, debe probar todas las vas de acceso a travs del cdigo, pero esto slo es posible en unidades
muy simples. Como mnimo, debe ejercer todas las vas de acceso decisin a decisin (va de acceso DD) por
lo menos una vez porque entonces ejecuta todas las sentencias una vez. Una decisin suele ser una sentencia
if, y una va de acceso DD es una va de acceso entre dos decisiones.

Para alcanzar este nivel de cobertura de la prueba, se recomienda que escoja los datos de prueba para que
todas las decisiones se evalen de todos los modos posibles.

Enfoque de prueba de caja negra

El objetivo de una prueba de caja negra es verificar la funcin y el comportamiento observable especificado
de la unidad sin conocer cmo implementa la unidad la funcin y el comportamiento. Las pruebas de caja
negra se centran y se basan en la entrada y la salida de la unidad.

Derivar las pruebas de la unidad basndose en el enfoque de caja negra, utiliza los argumentos de entrada y de
salida de las operaciones de la unidad, y/o el estado de salida para su evaluacin. Por ejemplo, la operacin
puede incluir un algoritmo (que requiere dos valores como entrada y devolucin de una tercera como salida),
o iniciar el cambio en el estado de un objeto o de un componente, como aadir o suprimir un registro de base
de datos. Deben probarse totalmente. Para probar una operacin, debe derivar suficientes guiones de prueba
para verificar lo siguiente:

La operacin ha devuelto un valor apropiado para cada valor vlido utilizado como entrada.
La operacin ha devuelto un valor apropiado para cada valor no vlido utilizado como entrada.
Un estado de salida apropiado ocurre para cada estado de entrada vlido.
Un estado de salida apropiado ocurre para cada estado de entrada no vlido.




Pruebas de Software Pgina 2

TECNICAS DE PRUEBA DE CAJA BLANCA O ESTRUCTURALES

A este tipo de tcnicas se le conoce tambin como Tcnicas de Caja Transparente o de Cristal. Este mtodo se
centra en cmo disear los casos de prueba atendiendo al comportamiento interno y la estructura del
programa. Se examina as la lgica interna del programa sin considerar los aspectos de rendimiento.

El objetivo de la tcnica es disear casos de prueba para que se ejecuten, al menos una vez, todas las
sentencias del programa, y todas las condiciones tanto en su vertiente verdadera como falsa.

Como se ha indicado ya, puede ser impracticable realizar una prueba exhaustiva de todos los caminos de un
programa. Por ello se han definido distintos criterios de cobertura lgica, que permiten decidir qu sentencias
o caminos se deben examinar con los casos de prueba. Estos criterios son:

Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada sentencia en el
programa se ejecute, al menos, una vez.
Cobertura de Decisin: Se escriben casos de prueba suficientes para que cada decisin en el
programa se ejecute una vez con resultado verdadero y otra con el falso, pero tambin todas las
posibles ramas de un switch.
Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada condicin en una
decisin tenga una vez resultado verdadero y otra falso.
Cobertura Decisin/Condicin: Se escriben casos de prueba suficientes para que cada condicin en
una decisin tome todas las posibles salidas, al menos una vez, y cada decisin tome todas las
posibles salidas, al menos una vez.
Cobertura de Condicin Mltiple: Se escriben casos de prueba suficientes para que todas las
combinaciones posibles de resultados de cada condicin se invoquen al menos una vez.
Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos los
caminos de un programa. Entendiendo camino como una secuencia de sentencias encadenadas desde
la entrada del programa hasta su salida.
Prueba de Bucles: Es una tcnica que se centra exclusivamente en la validez de las construcciones
de bucles (simples, anidados, concatenados y no estructurados). Comprueba el nmero de bucles o
iteraciones que han sido ejecutados cero veces (excepto para bucles do..while), una vez y ms de una
vez.


COBERTURA DE CAMINO

La aplicacin de este criterio de cobertura asegura que los casos de prueba diseados permiten que todas las
sentencias del programa sean ejecutadas al menos una vez y que las condiciones sean probadas tanto para su
valor verdadero como falso.

Una de las tcnicas empleadas para aplicar este criterio de cobertura es la Prueba del Camino Bsico. Esta
tcnica se basa en obtener una medida de la complejidad del diseo procedimental de un programa (o de la
lgica del programa). Esta medida es la complejidad ciclomtica de McCabe, y representa un lmite superior
para el nmero de casos de prueba que se deben realizar para asegurar que se ejecuta cada camino del
programa.

Los pasos a realizar para aplicar esta tcnica son:

Representar el programa en un grafo de flujo.
Calcular la complejidad ciclomtica.
Determinar el conjunto bsico de caminos independientes.
Derivar los casos de prueba que fuerzan la ejecucin de cada camino.

Pruebas de Software Pgina 3

A continuacin, se detallan cada uno de estos pasos.

Representar el programa en un grafo de flujo:

El grafo de flujo se utiliza para representar flujo de control lgico de un programa. Para ello se utilizan los
tres elementos siguientes:

Nodos: representan cero, una o varias sentencias en secuencia. Cada nodo comprende como mximo
una sentencia de decisin (bifurcacin).
Aristas: lneas que unen dos nodos.
Regiones: reas delimitadas por aristas y nodos. Cuando se contabilizan las regiones de un programa
debe incluirse el rea externa como una regin ms.
Nodos predicado: cuando en una condicin aparecen uno o ms operadores lgicos (AND, OR,
XOR, ...) se crea un nodo distinto por cada una de las condiciones simples. Cada nodo generado de
esta forma se denomina nodo predicado.

La siguiente figura muestra un ejemplo de condicin mltiple.



As, cada construccin lgica de un programa tiene una representacin. La siguiente figura muestra la
representacin en grafo de flujo de las estructuras lgicas de un programa.


Pruebas de Software Pgina 4

La siguiente figura muestra un grafo de flujo del diagrama de mdulos correspondiente. Ntese cmo la
estructura principal corresponde a un while, y dentro del bucle se encuentran anidados dos constructores if.



Calcular la complejidad ciclomtica:

La complejidad ciclomtica es una mtrica del software que proporciona una medida cuantitativa de la
complejidad lgica de un programa. En el contexto del mtodo de prueba del camino bsico, el valor de la
complejidad ciclomtica define el nmero de caminos independientes de dicho programa, y por lo tanto, el
nmero de casos de prueba a realizar. Posteriormente veremos cmo se identifican esos caminos, pero rimero
veamos cmo se puede calcular la complejidad ciclomtica a partir de un grafo de flujo, para obtener el
nmero de caminos a identificar.

Existen varias formas de calcular la complejidad ciclomtica de un programa a partir de un grafo de flujo:

1. El nmero de regiones del grafo coincide con la complejidad ciclomtica, V(G).
V(G) = Nmero de Regiones
2. La complejidad ciclomtica, V(G), de un grafo de flujo G se define como:
V(G) = Aristas Nodos + 2
3. La complejidad ciclomtica, V(G), de un grafo de flujo G se define como:
V(G) = Nodos Predicado + 1

La siguiente figura representa, por ejemplo, las cuatro regiones del grafo de flujo, obtenindose as la
complejidad ciclomtica de 4. Anlogamente se puede calcular el nmero de aristas y nodos predicados para
confirmar la complejidad ciclomtica. As:

V(G) = Nmero de Regiones = 4

V(G) = Aristas Nodos + 2 = 11-9 + 2 = 4

V(G) = Nodos Predicado + 1 = 3 +1 = 4

Pruebas de Software Pgina 5



Esta complejidad ciclomtica determina el nmero de casos de prueba que deben ejecutarse para garantizar
que todas las sentencias de un programa se han ejecutado al menos una vez, y que cada condicin se habr
ejecutado en sus vertientes verdadera y falsa. Veamos ahora, cmo se identifican estos caminos.


Determinar el conjunto bsico de caminos independientes:

Un camino independiente es cualquier camino del programa que introduce, por lo menos, un nuevo conjunto
de sentencias de proceso o una condicin, respecto a los caminos existentes. En trminos del diagrama de
flujo, un camino independiente est constituido por lo menos por una arista que no haya sido recorrida
anteriormente a la definicin del camino. En la identificacin de los distintos caminos de un programa para
probar se debe tener en cuenta que cada nuevo camino debe tener el mnimo nmero de sentencias nuevas o
condiciones nuevas respecto a los que ya existen. De esta manera se intenta que el proceso de depuracin sea
ms sencillo.

Este mtodo permite obtener V(G) caminos independientes cubriendo el criterio de cobertura de decisin y
sentencia.
As por ejemplo, para la el grafo de la figura anterior los cuatro posibles caminos independientes generados
seran:

Camino 1: 1-9
Camino 2: 1-2-4-8-1-9
Camino 3: 1-2-3-5-7-8-1-9
Camino 4: 1-2-5-6-7-8-1-9

Estos cuatro caminos constituyen el camino bsico para el grafo de flujo correspondiente.


Derivar los casos de prueba que fuerzan la ejecucin de cada camino:

El ltimo paso es construir los casos de prueba que fuerzan la ejecucin de cada camino. Una forma de
representar el conjunto de casos de prueba es como se muestra en la siguiente tabla.




Pruebas de Software Pgina 6

Nmero del Camino Caso de Prueba Resultado Esperado







PRUEBA DE BUCLES

Bucles Simples: se aplica el siguiente conjunto de pruebas:

Pasar por alto o ignorar el bucle.
Pasar una sola vez por el bucle.
Pasar dos veces por el bucle.
Hacer m pasos por el bucle con m < n (donde n es el nmero mximo de iteraciones).
Hacer n - 1, n y n + 1 pasos por el bucle.




Bucles Anidados: se aplica el siguiente conjunto de pruebas:

Comenzar por el bucle ms interior. Establecer o configurar los dems bucles con sus valores
mnimos.
Llevar a cabo las pruebas de bucles simples para el bucle ms interior, mientras se mantienen los
parmetros de iteracin de los bucles externos en sus valores mnimos. Aadir otras pruebas para
valores fuera de rango o excluidos.
Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle, pero manteniendo todos los
bucles externos en sus valores mnimos y los dems bucles anidados en sus valores tpicos.
Continuar hasta que se hayan probado todos los bucles.



Pruebas de Software Pgina 7

Bucles Concatenados: se aplica el siguiente conjunto de pruebas:

Estos bucles se pueden probar utilizando el enfoque de bucles simples, siempre y cuando cada uno
de los bucles sea independiente del resto de lo contrario se debe emplear el enfoque de bucles
anidados.



Bucles no Estructurados:

Siempre que sea posible estos bucles deben redisearse, corregir a bucles estructurados.