Ingeniería de Software

Clase 11:
Técnicas de Pruebas

Hugo R. Cordero S.
Clase 1
 Objetivos
2

 Conocer las diferentes técnicas de ejecución de

pruebas.
 Conocer algunas herramientas para la ejecución de
pruebas.
 Temas
3

 La prueba en el ciclo de vida

 Prueba de Caja Blanca
 Prueba de Camino Básico
 Pruebas de estructuras de control
 Prueba de Caja Negra
 Pruebas de Software
4

• Son los procesos que permiten verificar y revelar la

calidad de un producto software
• Las pruebas de software se integran dentro de las
diferentes fases del Ciclo del software dentro de la
Ingeniería de software
• Así se ejecuta un programa y mediante técnicas
experimentales se trata de descubrir que errores
tiene
 Pruebas de Software
5

 Para determinar el nivel de calidad se deben efectuar

unas medidas o pruebas que permitan comprobar el
grado de cumplimiento respecto de las especificaciones
iniciales del sistema
 Las pruebas de software, testing o beta testing es un
proceso usado para identificar posibles fallos de
implementación, calidad, o usabilidad de un programa
 Básicamente es una fase en el desarrollo de software
consistente en probar las aplicaciones construidas
 Pruebas de Software
6

Una definición de "testing" es:

 proceso de evaluación de un producto desde un punto de
vista crítico, donde el "tester" (persona que realiza las
pruebas) somete el producto a una serie de acciones
inquisitivas, y el producto responde con su
comportamiento como reacción.
 Por supuesto, nunca se debe testear el software en un
entorno de producción
 "El testing puede probar la presencia de errores pero
no la ausencia de ellos", E. W. Dijkstra
 La importancia de la detección
7
oportuna
• En la cadena de valor del desarrollo de un software
específico, el proceso de prueba es clave a la hora de
detectar errores o fallas
• Conceptos como estabilidad, escalabilidad, eficiencia y
seguridad se relacionan a la calidad de un producto bien
desarrollado. Las aplicaciones de software han crecido en
complejidad y tamaño, y costos
• Hoy en día es crucial verificar y evaluar la calidad de lo
construido de modo de minimizar el costo de su
reparación
 La importancia de la detección
8
oportuna
• Mientras antes se detecte una falla, más barato es su
corrección
• El proceso de prueba es un proceso técnico
especializado de investigación que requiere de
profesionales altamente capacitados en lenguajes de
desarrollo, métodos y técnicas de pruebas y
herramientas especializadas
• El conocimiento que debe manejar un ingeniero de
prueba es muchas veces superior al del desarrollador
de software
 Enfoque de Diseño de Casos de
9
Prueba

 Enfoque estructural o de caja blanca

 Enfoque funcional o de caja negra

 Enfoque Aleatorio
 Pruebas de Caja Blanca
10

 Busca garantizar que se ejecuten por lo menos una vez

todos los caminos independientes de cada módulo
 Probar todas las decisiones lógicas en sus vertientes
verdadera y falsa
 Ejecuta todos los bucles en sus límites y con sus límites
operacionales
 Ejercita las estructuras internas de datos para asegurar
su validez
 Criterios de Cobertura lógica
11

 Cobertura de Sentencias Menos Riguroso

(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
Más Riguroso
(Más Caros)
 Grafo de Flujo de las Estructuras
12
Básicas de programa
12

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 también las condiciones
 Variantes de Prueba de Caja
13
Blanca
 Prueba del Camino Básico

 Prueba de Condición

 Prueba de Flujo de Datos

 Prueba de Bucles
 Prueba del camino Básico
14

 Complejidad Ciclomática (La complejidad de

McCabe V (G))

 La métrica de McCabe ha sido muy popular en el

diseño de pruebas

 Esun indicador del número de caminos independientes

que existen en un grafo
 Diagramas de Flujo
15

Diagrama de Flujo
Representa la estructura y
control del programa
camino 1: 1-11
camino 2: 1-2-3-4-5-10-1-11
camino 3: 1-2-3-6-8-9-10-1-11
camino 4: 1-2-3-6-7-9-10-1-11
Fíjese que cada nuevo camino
introduce una nueva arista.
Cuál es el nuevo camino?

Grafo de Flujo
Representa el Flujo de control
lógico mediante notación
ilustrada
 Complejidad ciclomática
16
La complejidad ciclomática es
una métrica del software
que proporciona una
medición cuantitativa de
la complejidad lógica de
un programa
número de pruebas que se
Un camino independiente es
cualquier camino del programa
que introduce, por lo menos, un
nuevo conjunto de sentencias de
proceso o una nueva condición
Definición: Es el número
de caminos
independientes del
conjunto básico
de un programa y nos da
un límite superior para
el
deben realizar para
asegurar
que se ejecuta cada
sentencia al menos una
vez
 Formas de calcular la complejidad
17
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
 Determinamos la complejidad
18
ciclomática

Se determina aplicando uno de los

algoritmos descritos anteriormente
Se debe tener en cuenta que se puede
determinar V(G) sin desarrollar el grafo de
flujo, contando todas las sentencias
condicionales del programa

V(G) = 6 regiones
V(G) = 17 aristas - 13 nodos +2 = 6
V(G) = 5 nodos condición + 1 = 6
 Ejemplo de cálculo de V(G)
19

1
a1
a2 a3
2
a4  V (G) =14-11+2=5
3 Región 1
a5
a6 a7
4
Región 2 a8  V (G) = 5 Regiones
5 Región 3
a9
a10 Cerradas
6
a11 a12

Región 4
7 8
a13 a14  V (G) = 4+1= 5
9
10
Condiciones
Región 5
11
 Ejemplo de cálculo de V(G)
20

 V (G) = 3
 ¿Qué es lo que se logra con la
21
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.
 Prueba del camino Básico
22

 Pasos para la obtención de Casos de Prueba

1. Dibujar el grafo de flujo
2. Calcular la complejidad ciclomática
3. Determinar un conjunto básico
4. Preparar los casos de prueba para el camino básico
 Ejemplo prueba del camino Básico
23

 Ejemplo, teniendo la siguiente LDP:

 Ejemplo prueba del camino Básico
24

 Determinamos los caminos independientes:

 Ejemplo prueba del camino Básico
25

 Calculamos la complejidad ciclomática para el

ejemplo: V(G) = 3

 Identificamos los casos de prueba:

 Prueba de Condición
26

 Condición Simple
 Variable Lógica: True/False
 Expresión relacional: E1 (operador relacional) E2
 E1y E2 son expresiones aritméticas
 Operador Relacional (<, <=, >, >=, =, ≠)

 Condición Compuesta
 Condicionessimples
 Operadores lógicos: NOT, AND, OR

 Paréntesis
 Estrategias Prueba de Condiciones
27

 Prueba de Ramificaciones
 Condición Verdadera
 Condición Falsa

 Cada condición simple

 Prueba de Dominio
E1<operador-relacional>E2
Se necesitan 2n (n>0) pruebas como máximo
para encontrar errores
 Ejemplo Prueba de Condiciones
28

 Ejemplo de Prueba de Condición:

 Prueba de Condición
29

 Ventajas
• La cobertura de la prueba de una condición es
sencilla
• La cobertura de la prueba de las condiciones de un
programa da una orientación para generar
pruebas adicionales del programa
 Prueba de flujo de datos
30

 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
 Son útiles para seleccionar caminos de prueba de un
programa que contenga sentencias if o bucles
anidados
 Necesitamos conocer la estructura de cada condición o
bloque (seleccionando un camino del programa,
determinamos si el camino es factible para el
programa)
 Prueba de Bucles
31

Tipos de pruebas:
• Bucles simples
• Bucles Anidados
• Bucles Concatenados
• Bucles no estructurados
 Prueba de Bucles
32

 Bucles Simples
• Saltar el bucle
• Pasar sólo una vez por el bucle
• Pasar dos veces por el bucle
• Hacer m pasos del bucle con m < n
• Hacer n-1, n y n+1 pasos por el bucle
 Bucles no estructurados:
• Corregir!
 Pruebas de Caja Negra
33

 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
 Pruebas de Caja Negra
34

 Variantes de pruebas de caja negra:

• Métodos de prueba basados en grafos
• Partición Equivalente
• Análisis de valores límite
• Prueba de Comparación
• Conjetura de Errores
 Métodos de prueba basados en
35
grafos
 Pasos a seguir para una prueba de caja negra:
1. Entender los objetos que se van a modelar y las
relaciones que conectan a estos.
2. Definir una serie de pruebas que verifique que
“todos los objetos tienen entre ellos la relaciones
esperadas”
 Partición equivalente
36

 Divide el dominio de entrada en clases de datos

 Consiste en identificar las clase de equivalencia
(conjunto de estados válidos o inválidos para
condiciones de entrada
 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
 Partición equivalente
37

 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
38

 Aplicación bancaria en la que el operador debe

proporcionar un código, un nombre y una operación:
 Análisis de valores límite
39

 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
3. Usar la regla 1 para la condición de salida.
4. Usar la regla 2 para cada condición de salida.
 Prueba de Comparación
40

 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
 Conjetura de Errores
41

 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
 Pruebas Aleatorias
42

 Se simula los posibles datos de entrada en la

secuencia y frecuencia que pueden aparecer en la
practica
 Si el proceso de generación se ha realizado
correctamente, se crearán eventualmente todas las
posibles entradas del programa en todas las
posibles combinaciones y permutaciones
 Baja probabilidad de encontrar errores
 En Resumen
43

 ¿Si su software fuera un edificio, se parecería más a uno de

la izquierda o de la derecha?
 Resumen
44

 En la cadena de valor del desarrollo de un software específico,

el proceso de prueba es clave a la hora de detectar errores o
fallas
 Las pruebas de Caja Blanca se puede terminar a partir de la
prueba del Camino Básico, pruebas de Condición, pruebas de
Flujo de Datos y prueba de Bucles
 La complejidad ciclomática es el número de caminos
independientes del conjunto básico de un programa y nos da un
límite superior para el número de pruebas que se deben realizar
para asegurar que se ejecuta cada sentencia al menos una vez.
 Para las pruebas de Caja Negra se pueden aplicar métodos de
prueba basados en grafos, partición equivalente, análisis de
valores límite, prueba de comparación y conjetura de errores
 ¿Preguntas?
45

 ¿Qué técnicas aplicaría para las pruebas de

caja negra?
 Referencias
46

 Eric Braude, Ingeniería de Software. Una perspectiva orientada a

objetos (1ra. Edición)
 Capítulo 8, Pruebas de unidades
 Capítulo 9, Integración, verificación y validación del sistema
 Roger S. Pressman, Ingeniería de Software: Un enfoque práctico
(7ma edición)
 Capítulo 18: Prueba de aplicaciones convencionales
 Ingeniería de Software. Un enfoque desde la guía SWEBOK (1ra.
edic.), Salvador Sánchez, Miguel Ángel Sicilia, Daniel Rodríguez
 Capítulo 7: Pruebas
 Guillermo Pantaleo, Ludmila Rinaudo, Ingeniería de Software
(1ra. Edición)
 Capítulo 16, Pruebas de software
 Capítulo 17, Proceso de pruebas de software