PRUEBAS DEL

SOFTWARE
 Introducc
ión
• ¿Es posible construir software que no falle?.
• Hoy en día estamos acostumbrados a que el software
falle.
• Al construir software habitualmente se comenten
errores.
• En la industria, la técnica para solucionar los problemas
derivados de dichos errores, serán las pruebas de
software (‘testing’)
• Esta técnica consiste en una serie de pasos realizados
antes y después de la construcción de este software.
 Introducc
ión
Analice las siguientes percepciones que tienen los
desarrolladores acerca de las pruebas:
• “Las pruebas son el proceso de demostrar que no hay
errores presentes”.
• “El propósito de las pruebas es demostrar que un
programa realiza las funciones indicadas
correctamente”.
• “Las pruebas son el proceso de establecer confianza en
que un programa hace lo que se supone que debe
hacer” .
 Introducción
Analice las siguientes percepciones que tienen los
desarrolladores acerca de las pruebas:
El desarrollador desea salir bien de las pruebas
• No me equivoco
• Cumple con los requerimientos
• Está a tiempo
• De acuerdo al presupuesto
 Definición
¿Qué es probar software?
• Probar es el proceso ejecución de un programa con el fin de
encontrar errores.

¿Por qué Probar Software?

• Para demostrar que un programa tiene fallos, por tanto,
hay la probabilidad de encontrar errores.
 Definició
n
Las pruebas de software, es el procesos que permite
verificar y revelar la calidad de un producto software
• El testing puede probar la presencia de errores pero no
la ausencia de ellos
 Conceptos
fundamentales
• Verificación: El proceso de evaluación de un
sistema o de uno de sus componentes para
determinar si los productos de una fase dada
satisfacen las condiciones impuestas al comienzo
de dicha fase.
Conceptos
fundamentales

Validación: El proceso
de evaluación de un
sistema o de uno de sus
componentes durante o
al final del proceso de
desarrollo para
determinar si satisface
los requisitos marcados
por el usuario.
Conceptos
fundamentales
 Conceptos
fundamentales
Técnicas para Verificación y Validación
 Conceptos
fundamentales
Técnicas para Verificación y Validación
 Conceptos
fundamentales
• Para entender las pruebas se debe diferenciar los
términos error, fallo y defecto.
• Estos conceptos están relacionados entre si, pero
tienen significados diferentes
 Conceptos
fundamentales
Error (error): Una equivocación humana
Defecto (defect, fault, «bug»): «Se produce
cuando una persona comete un error.
• Fallo (failure): «La incapacidad de un sistema o de
alguno de sus componentes para realizar las
funciones requeridas dentro de los requisitos de
rendimiento especificados»
 Conceptos
fundamentales
Un resultado incorrecto ----- Fallo

Una acción humana que conduce a un resultado

incorrecto ----- Error

Se comete un error ----- Defecto

Relación entre error,
defecto y fallo
Objetivos de la Prueba.
• La prueba es el proceso de ejecución de un
programa con la intención de descubrir un error.
• El objetivo principal de las pruebas es aportar
calidad al producto que se está desarrollando.
 Proceso de la
Prueba
Cómo se llevan a cabo las pruebas?
• Verificando el comportamiento del programa sobre
un conjunto de casos de prueba.
• Los casos de prueba se generarán mediante
técnicas y estrategias específicas de pruebas
• Estas técnicas ayudan a conseguir la búsqueda de
los errores de un programa.
Ciclo de las
Pruebas
Ciclo completo de las
Pruebas
El proceso de
Prueba
 Preguntas
• Cuando se descubre un error la prueba ha tenido éxito
o ha fracasado?
• Las pruebas pueden determinar la presencia de
defectos, pero no su ausencia?
• Cual es la diferencia entre verificación y validación?
• Las pruebas hacen parte de Verificación o de la
validación?
• ¿Es posible encontrar todos los errores de un
programa?
• Probar en etapas tempranas disminuye costos de
errores?
Tipos de
pruebas
 Técnicas de
Prueba
• Enfoque estructural o de caja blanca.
Basadas en información sobre cómo el software ha
sido diseñado o codificado

• Enfoque funcional o de caja negra.

Los casos de prueba se basan sólo en el
comportamiento de entrada/salida
 Técnica de caja
negra

Las técnicas de caja negra o funcionales, realizan pruebas sobre

la interfaz del programa a probar, entendiendo por interfaz las
entradas y salidas de dicho programa.
 Técnica de Caja
Negra.
• Consideran la función específica para la cuál fue creado el
producto (lo que hace).
• Las pruebas se llevan a cabo sobre la interfaz del sistema.
• Reduce el número de casos de prueba mediante la
elección de condiciones de entrada y salida válidas y no
válidas que ejercitan toda la funcionalidad del sistema.
• No es necesario conocer la lógica del programa,
únicamente la Funcionalidad que debe realizar.
 Técnica de Caja
Negra.
• Intenta encontrar errores de las siguientes
categorías:
• Funciones Incorrectas o Ausentes.
• Errores de Interfaz.
• Errores en estructuras de datos o acceso a bases de
datos externas.
• Errores de rendimiento.
• Errores de inicialización y terminación.
 Técnica de Caja
Negra.
Técnicas de pruebas de caja negra.

• Partición Equivalente (clases equivalencia).

• Análisis de valores límite.
• Métodos de prueba basados en grafos.
• Prueba de Comparación.
• Conjetura de Errores.
 Técnica de Caja Negra.
Método clase de
equivalencia
• Se basa en la división del campo de entrada en un
conjunto de clases de datos denominadas clases de
equivalencia.
• Clase de equivalencia: Un conjunto de datos de
entrada que definen estados válidos y no válidos
del sistema.
–Clase válida: genera un valor esperado
–Clase no válida: genera un valor inesperado
• Se obtienen a partir de las condiciones de entrada
descritas en las especificaciones.
 Técnica de Caja Negra.
Método clase de
equivalencia
Criterios de identificación de las clases de
equivalencias
 Técnica de Caja Negra.
Método clase de
equivalencia
Pasos para identificar clases de equivalencia.
1. Identificación de las condiciones de entrada del
programa.
2. Identificar las clases de equivalencia:
a) Datos válidos.
b) Datos no válidos.
 Técnica de Caja Negra.
Método clase de
equivalencia

Pasos para identificar casos de prueba.

1. Asignar un número único para cada clase de

equivalencia.
2. Escribir casos de pruebas para todas las clases válidas.
3. Escribir casos de pruebas para todas las clases no
válidas.
 Ejemplo de clases de
equivalencia
Aplicación bancaria en la que el
operador debe proporcionar un
código, un nombre y una operación.

Condición de
Clases Válidas Clases Inválidas
Entrada
Código de Área 2) Código < 200.
# de 3 dígitos que no 1) 200≤ código ≤ 999 3) Código > 999.
empieza con 0 ni 1: 4) No es número.
Nombre 6) Menos de 6
Para identificar la 5) Seis caracteres. caracteres.
operación 7) Más de 6 caracteres.
8) “Cheque”
Orden 9) “Depósito” 12) Ninguna orden
Una de las Siguientes 10) “Pago factura” válida
11)“Retiro de fondos”
Caso de prueba: Es un conjunto de
entradas, condiciones de ejecución y
resultados esperados, que son desarrollados
para cumplir con un objetivo en particular

Dato Resultado
Valor Escenario
entrada esperado
Correcto /
incorrecto
Clases de equivalencia

TALLER

Ingenieria de Software II -
Universidad Popular del Cesar
 TALLER
Considérese una aplicación bancaria, donde el usuario puede conectarse al
banco por Internet y realizar una serie de operaciones bancarias. Una vez
accedido al banco con las consiguientes medidas de seguridad (clave de
acceso y demás), la información de entrada del procedimiento que gestiona
las operaciones concretas a realizar por el usuario requiere la siguiente
entrada:
• Código del banco. Número de tres dígitos. En este último caso, el primero
de ellos tiene que ser mayor que 1.
• Código de sucursal. Un número de cuatro dígitos. El primero de ellos
mayor de 0.
• Número de cuenta. Número de cinco dígitos.
• Clave personal. Valor alfanumérico de cinco posiciones.
• Orden. Este valor se introducirá según la orden que se desee realizar.
Puede estar en blanco o ser una de las dos cadenas siguientes:
• “Talonario”
• “Movimientos”.
 Técnica de Caja Negra.
Método de análisis de
valores limite

• Se basa en la evidencia experimental de que los errores

suelen aparecer con mayor probabilidad en los extremos
de los campos de entrada.

• Un análisis de las condiciones límites de las clases de

equivalencia aumenta la eficiencia de la prueba.

• Condiciones límites: valores justo por encima y por debajo

de los márgenes de la clase de equivalencia.
 Técnica de Caja Negra.
Método de análisis de
valores limite

Las reglas para identificar las clases son:

1. Si una condición de entrada especifica un rango que

deben generar casos para los extremos.
2. Si la condición de entrada especifica un número finito
y consecutivo de valores, escribir casos para los
números máximo, mínimo, uno más del máximo y
uno menos del mínimo de valores
 Técnica de Caja Negra.
Análisis de valores
limite
Las reglas para identificar las clases son:
Técnica de Caja
Negra.
Análisis de valores
limite
 Técnica de Caja Negra.
Prueba de
Comparación

• Se desarrollan versiones independientes de una

aplicación con las mismas especificaciones.
• Probar todas las versiones con los mismos datos de
prueba.
• Luego se ejecutan las versiones en paralelo y se
hace una comparación en tiempo real de los
resultados.
 Técnica de Caja Negra.

Conjetura de Errores

• Enumerar una lista de equivocaciones que pueden

cometer los desarrolladores.
• Generar casos de prueba en base a dicha lista.
• La generación de casos se obtiene en base a la
intuición o la experiencia.

Ingenieria de Software II -
Universidad Popular del Cesar
 Técnica de Caja
•. Blanca
 Técnica de Caja
Blanca
• Garanticen que se ejercita por lo menos una vez todos
los caminos independientes de cada módulo.
• Ejerciten todas las decisiones lógicas en sus vertientes
verdadera y falsa.
• Ejecuten todos los bucles en sus límites y con sus límites
operacionales.
• Ejerciten las estructuras internas de datos para asegurar
su validez.
 Técnica de Caja
Blanca
Criterios de
Cobertura
La cobertura es una medida porcentual quelógica
indica la
cantidad de código. Menos Riguroso
• Cobertura de Sentencias. (Mas Barato)

• Cobertura de decisiones.
• Cobertura de Condiciones.
• Criterios de decisión/Condición.
• Criterio de Condición Múltiple.
• Criterio de Cobertura de Caminos (impracticable)
Más Riguroso
(Más Caros)
 Técnica de Caja
Blanca
Criterios de
Cobertura lógica
Cobertura de Sentencias: Que cada sentencia se ejecute al
menos una vez
Cobertura de decisiones: Que cada decisión tenga, por lo menos
una vez, un resultado verdadero y, al menos una vez, uno falso.
Cobertura de Condiciones: Que cada condición de cada decisión
adopte el valor verdadero al menos una vez y el falso al menos
una vez.
Criterios de decisión/Condición: Que se cumplan a la vez el
criterio de condiciones y el de decisiones.
Criterio de Condición Múltiple: La evaluación de las condiciones
de cada decisión no se realiza de forma simultánea.
Criterio de Cobertura de Caminos (impracticable)
 Variantes de Técnica de Caja
Blanca
• a) Prueba del Camino Básico.

• b) Prueba de Condición.

• c) Prueba de Flujo de Datos.

• d) Prueba de Bucles.
 Técnica de Caja Blanca
Prueba del camino Básico

El código se expresa en forma de grafo, siguiendo

cuatro pasos:
1. Elaborar un grafo de flujo asociado al programa.
2. Calcular la complejidad ciclomatica
3. Seleccionar un conjunto de caminos básicos.
4. Generar casos de pruebas para cada uno de los
caminos
 Grafo de Flujo de las
Estructuras Básicas
de programa

X X

Secuencia Si x Entonces… Hacer … hasta x Mientras x Hacer …

(If x Then … Else…) (Do … Until x) (While x Do … )
Repetir
• Separar todas las condiciones
• Agrupar sentencias ‘simples’ en bloques
• Numerar todos los bloques y tambien las condiciones
Grafo de Flujo
de un
programa
Grafo de
Flujo de un
programa
 Grafo de Flujo de un
programa
(Pseudocodigo )
Abrir Archivos;
Leer archivo ventas, al final indicar no mas registros
Limpiar linea de impresión
1
WHILE (Haya registros ventas) DO 2
Total Nacional = 0
Total Extranjero = 0 3
WHILE (haya reg. ventas) y (mismo producto) DO
IF (Nacional) THEN
4

Sumar venta Nacional a Total Nacional 5

ELSE
Sumar venta extranjero a total extranjero 6
a12
END IF
Leer Archivo ventas, al final indicar no mas registros 7 8
END WHILE
9
Escribir línea de listado
Limpiar área de impresión 10
END WHILE
11
Cerrar Archivos
 Prueba del camino
Básico
• Complejidad Ciclomatica(La complejidad de
McCabe V (G))

• La métrica de McCabe ha sido muy popular en el diseño

de pruebas.

• Es un indicador del número de caminos independientes

que existen en un grafo.
 Formas de Calcular
la Complejidad
Ciclomática V(G)
• V (G) = a – n + 2
• V (G) = r
• V (G) = c + 1
Donde
• a : # de arcos o aristas del grafo.
• n : # de nodos.
• r : # de regiones cerradas del grafo.
• c : # de nodos de condición.
 ¿Qué es lo que se logra
con la complejidad
ciclomática?

• V (G) marca el límite mínimo de casos de prueba

para un programa.

• Cuando V (G) >10 la probabilidad de defectos en el

módulo o programa crece mucho entonces quizás
sea interesante dividir el módulo.
Ejemplo de
calculo de V
(G)
 Ejemplo de
calculo de V
1
a1
(G)
a2 a3
2
a4
3 Región 1
• a) V (G) =14-11+2=5
a5
a6 a7
4
Región 2a8
5 Región 3
• b) V (G) = 5 Regiones
a9
a10
6 Cerradas.
a11 a12

Región 4
7 8
a13
9
a14 • c) V (G) = 4+1= 5
10 Condiciones
Región 5
11
 Taller

import java.util.*;
public class MayorDeTres {
 public static void main(String[] args) {
      Scanner sc = new Scanner(System.in);
      int n1, n2, n3;
      System.out.print("Introduzca primer número: ");
      n1 = sc.nextInt();
     System.out.print("Introduzca segundo número: ");
      n2 = sc.nextInt();
      System.out.print("Introduzca tercer número: ");
        n3 = sc.nextInt();
        if(n1 > n2)
           if(n1>n3)
              System.out.println("El mayor es: " + n1);
           else
              System.out.println("el mayor es: " + n3);
        else
if(n2>n3)
              System.out.println("el mayor es: " + n2);
                else
              System.out.println("el mayor es: " + n3);
    }}
 PREGUNTAS
Lecciones aprendidas

Ingenieria de Software II -
Universidad Popular del Cesar
 Prueba de
Condición
La cobertura de la prueba de las condiciones de un
programa da una orientación para generar pruebas
adicionales del programa.
• Prueba de Ramificaciones.
• Prueba de Dominio.
E1<operador-relacional>E2
Se necesitan 2n (n>0) pruebas como máximo
para encontrar errores.
 Prueba de flujo
de datos
• Esta técnica selecciona caminos de un programa
de acuerdo a las definiciones y uso de las
variables.

• El enfoque de prueba de flujo de datos es

efectivo para la protección contra errores.
 Prueba de
bucles
Tipos de pruebas:

• Bucles simples.

• Bucles Anidados.

• Bucles Concatenados.

• Bucles no estructurados.
 Ejercicio
Se desean realizar pruebas de la caja negra sobre un programa
utilizado por una empresa que toma como entrada los siguientes
datos:
• Número-empleado es un campo de números enteros positivos de 3
dígitos (excluido el 000).
• Nombre-empleado es un campo alfanumérico de 20 caracteres.
• Meses-Trabajo es un campo que indica el número de meses que
lleva trabajando el empleado; es un entero positivo (incluye el 000)
de 3 dígitos.
• Directivo es un campo de un solo carácter que puede ser «D» para
indicar que el empleado es un directivo y «N» para indicar que no lo
es.
• Prima El programa asigna una prima (que se imprime en un listado) a
cada empleado, teniendo en cuenta al menos 12 meses de
antigüedad.
 BIBLIOGRAFI
A
• Fairley R. Ingeniería de Software.

• Pressman, R.S. Ingeniería del Software. Un enfoque

práctico.