PRUEBAS DE CAJA BLANCA

PRUEBAS DE SOFTWARE
Ing. Juan Carlos TORRES LOZANO
 REGLAS DE NETIQUETA

USO DE LA CÁMARA

MANTENER EL MICRÓFONO APAGADO

LEVANTAR LA MANO PARA PREGUNTAR

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO
 • Conocer y aplicar las pruebas
de caja blanca.

OBJETIVOS
DE
LA CLASE

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 DEFINICIONES

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBAS DE CAJA BLANCA

• Estas pruebas se centran en probar el comportamiento

interno y la estructura del programa examinando la lógica
interna.
 Se ejecutan todas las sentencias (al menos una vez).
 Se recorren todos los caminos independientes de cada módulo.
 Se comprueban todas las decisiones lógicas.
 Se comprueban todos los bucles.
 Finalmente, en todos los casos se intenta provocar situaciones
Lógica interna de un programa
extremas o límites.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBAS DE INTERFACES ENTRE MÓDULOS
O CLASES

• En las pruebas de interfaces internas entre funciones o métodos es necesario comprobar que
los argumentos de llamadas a funciones y la consistencia de las definiciones de variables
globales entre los módulos.
• Las pruebas de interfaces internas corresponden al conjunto de pruebas unitarias, que
están enfocadas a verificar el correcto funcionamiento de un módulo o clase aisladamente
del resto.
• Para probar adecuadamente las interfaces externas se ha de verificar que el flujo de datos
intercambiado entre clases o módulos es el correcto. Este tipo de pruebas es una parte de las
pruebas de integración.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBA DE ESTRUCTURAS DE DATOS
LOCALES

• Estas pruebas aseguran la integridad de los datos durante todos los pasos de la
ejecución del módulo.
• Se comprueban las referencias de datos, la posible utilización de variables no
inicializadas, no salirse del límite de matrices o vectores, la correcta declaración de
datos y el hecho de no realizar comparaciones entre variables de distinto tipo, como
aspectos más importantes.
• Además se localizan errores derivados del uso de variables, tales como overflow,
underflow, división por cero, etc.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBA DEL CAMINO BÁSICO

• Se definen para este tipo de pruebas un conjunto básico de caminos de ejecución

usando una medida calculada previamente de la complejidad del modulo llamada
complejidad ciclomática, propuesta por McCabe, que se basa en el grafo de flujo.
• La complejidad ciclomática indica el número de caminos básicos a probar y
responde a la siguiente fórmula:

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBA DEL CAMINO BÁSICO

• Los pasos a seguir para realizar las pruebas de camino básico son:
1. Dibujar el grafo de flujo.
2. Determinar la complejidad ciclomática del grafo.
3. Determinar los caminos linealmente independientes.
4. Preparar los casos de prueba que forzarán la ejecución de cada camino.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBA DEL CAMINO BÁSICO

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 EJEMPLO 1. PRUEBA DEL CAMINO BÁSICO

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 EJEMPLO 1. PRUEBA DEL CAMINO BÁSICO

• Se halla la complejidad ciclomática: V(G) = Aristas – Nodos 2.

• En este caso, V(MCD) = 7 – 6 + 2 = 3. La complejidad ciclomática en este caso es 3, lo que
significa que hay tres caminos linealmente independientes.
• La tabla muestra los tres posibles caminos hallados con los valores correspondientes de “x” y
de “y”, así como el valor de retorno para cada uno de ellos.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBAS DE CONDICIONES LÍMITE

• En primer lugar es necesario representar de forma gráfica los bucles para, posteriormente,
validar la construcción de los bucles, que pueden ser simples, anidados, concatenados y no
estructurados.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBAS DE CONDICIONES LÍMITE

• Para los bucles simples, siendo n el número máximo de pasos, hay que realizar las
siguientes iteraciones, con sus correspondientes pruebas para garantizar que cada
tipo de bucle queda adecuadamente probado:
 Pasar por alto el bucle.
 Pasar una sola vez.
 Pasar dos veces.
 Hacer m pasos con m < n.
 Hacer n - 1, n y n + 1 pasos.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBAS DE CONDICIONES LÍMITE

• En el caso de los bucles anidados, se comienza por el bucle más interno progresando hacia fuera.
• Los bucles concatenados pueden ser independientes. En este caso, se realizan las mismas pruebas
que si fueran de bucles simples. En el caso de que no sean independientes, se aplica el enfoque de
los bucles anidados.
• Los bucles no estructurados necesitan ser rediseñados ya que comprometen la calidad del diseño y,
una vez hecho esto, se tratan como el tipo de bucle que haya resultado. A día de hoy, aunque
instrucciones como goto todavía forman parte de muchos lenguajes de programación, la
programación no estructurada en lenguajes de alto nivel está completamente desaconsejada.
• Un código no estructurado es difícil de leer y, por tanto, difícil de mantener.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBAS DE CONDICIÓN

• Las condiciones en una sentencia pueden ser, esencialmente, simples o compuestas. Una
condición simple puede ser una variable lógica (TRUE o FALSE) o una expresión relacional
de la siguiente forma: E1 (operador relacional) E2, donde E1 y E2 son expresiones
aritméticas y el operador relacional es del tipo <,<=,>,>=,=, ?#.
• Las condiciones compuestas están formadas por varias condiciones simples, operadores
lógicos del tipo NOT, AND, OR y paréntesis.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBAS DE CONDICIÓN

• Los errores más comunes que se producen en una condición y que, por tanto, hay que
comprobar son:
 Error en el operador lógico: que sean incorrectos, desaparecidos, sobrantes, etc.
 Error en la variable lógica.
 Error en la expresión aritmética.
 Error en el operador relacional.
 Error en los paréntesis.
• En las decisiones, es necesario hacer pruebas de ramificaciones, que consisten en probar la
rama verdadera y la rama falsa y cada condición simple.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 PRUEBAS DE CONDICIÓN

• En general, existen los siguientes tipos de pruebas relacionadas con las condiciones y
decisiones:
 De cobertura de decisión.
 De cobertura de condición.
 De cobertura de decisión/condición.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 EJEMPLO 2. PRUEBAS DE CONDICIÓN

• El siguiente ejemplo define los casos de prueba aplicando las coberturas de decisión y de
decisión/condición a partir de este fragmento de código:

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 EJEMPLO 2. PRUEBAS DE CONDICIÓN

• Se generan a continuación los casos de prueba necesarios para obtener una cobertura
completa de decisiones.
• En el código hay tres decisiones:

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 EJEMPLO 2. PRUEBAS DE CONDICIÓN

• Cada decisión debe tomar al menos una vez el valor verdadero y otra el valor falso. Los
datos concretos para los casos de prueba podrían ser los siguientes:

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 EJEMPLO 2. PRUEBAS DE CONDICIÓN

• Para cubrir todas las decisiones se deben definir los siguientes casos:
• Caso de prueba 1: D1 =Verdadero; D2=Verdadero; D3=Verdadero
h=10; m=30; s=50
• Caso de prueba 2: D1=Verdadero; D2=Verdadero; D3=Falso
h=10; m=30; s=70
• Caso de prueba 3: D1 =Verdadero; D2 =Falso
h=10; m=60
• Caso de prueba 4: D1=Falso
h=24

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 EJEMPLO 2. PRUEBAS DE CONDICIÓN

• Se generan seguidamente los casos de prueba necesarios para obtener una cobertura
completa de decisión/condición.
• En el código hay tres decisiones. Cada una de ellas comprende dos condiciones.

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 EJEMPLO 2. PRUEBAS DE CONDICIÓN

• Hay que garantizar que cada condición tome al menos una vez el valor verdadero y otra el
valor falso, garantizando además que se cumpla la cobertura de decisión. Los datos
concretos para los casos de prueba podrían ser los siguientes:

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 EJEMPLO 2. PRUEBAS DE CONDICIÓN

• Si se utilizan los datos de C1.1 y C1.2 que hacen que tomen los valores VERDADERO
simultáneamente, la decisión D1 tomará también el valor VERDADERO. Para que tome el
valor FALSO, no se puede hacer que C1.1 y C1.2 tomen los valores FALSO
simultáneamente, y habrá que considerar dos casos: C1.1=V, C1.2=F y C1.1=F, C1.2=V para
que la decisión D1 tome también el valor FALSO cubriendo todas las condiciones.
• Lo mismo ocurre con C2.1 y C2.2 y con C3.1 y C3.2.
• Caso de prueba 1: C1.1=Verdadero, C1.2=Verdadero, C2.1= Verdadero, C2.2= Verdadero,
C3.1= Verdadero, C3.2= Verdadero
h=10; m=30; s=50

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO

 EJEMPLO 2. PRUEBAS DE CONDICIÓN

• Caso de prueba 2: C1.1= Verdadero, C1.2= Verdadero, C2.1= Verdadero,

C2.2= Verdadero, C3.1= Verdadero, C3.2= Falso
h=10; m=30; s=70
• Caso de prueba 3: C1.1= Verdadero, C1.2= Verdadero, C2.1= Verdadero,
C2.2= Verdadero, C3.1= Falso, C3.2= Verdadero
h=10; m=30; s= -1
• Caso de prueba 4: C1.1= Verdadero, C1.2= Verdadero, C2.1= Verdadero, C2.2= Falso
h=10; m=30
• Caso de prueba 5: C1.1= Verdadero, C1.2= Verdadero, C2.1= Falso, C2.2= Verdadero
h=10; m= -1
• Caso de prueba 6: C1.1= Verdadero, C1.2= Falso
h=10
• Caso de prueba 7: C1.1= Falso, C1.2= Verdadero
h= -1
PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO
 • Aplicar las pruebas de cada uno de los
ejemplo en un caso.

ACTIVIDAD

PRUEBAS DE SOFTWARE Ing. Juan Carlos TORRES LOZANO