Ingeniera de Software

Clase 09:
Tcnicas de Pruebas
Hugo R. Cordero S.

Clase 1

Objetivos
2

Conocer las diferentes tcnicas de ejecucin de

pruebas.
Conocer algunas herramientas para la ejecucin de
pruebas.

Temas
3

La prueba en el ciclo de vida

Prueba de Caja Blanca
Prueba de Camino Bsico
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
Ingeniera de software
As se ejecuta un programa y mediante tcnicas
experimentales se trata de descubrir que errores
tiene

Pruebas de Software
5

Una definicin de "testing" es:

proceso de evaluacin de un producto desde un punto de

vista crtico, 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 reaccin.
Por supuesto, nunca se debe testear el software en un
entorno de produccin
"El testing puede probar la presencia de errores pero
no la ausencia de ellos", E. W. Dijkstra

La importancia de la deteccin
oportuna

En la cadena de valor del desarrollo de un software

especfico, 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 tamao, y costos
Hoy en da es crucial verificar y evaluar la calidad de lo
construido de modo de minimizar el costo de su
reparacin

La importancia de la deteccin
oportuna

Mientras antes se detecte una falla, ms barato es su

correccin
El proceso de prueba es un proceso tcnico
especializado de investigacin que requiere de
profesionales altamente capacitados en lenguajes de
desarrollo, mtodos y tcnicas 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 Diseo de Casos de

Prueba

Enfoque estructural o de caja blanca

Enfoque funcional o de caja negra

Enfoque Aleatorio

Pruebas de Caja Blanca

9

Busca garantizar que se ejecuten por lo menos una vez

todos los caminos independientes de cada mdulo
Probar todas las decisiones lgicas en sus vertientes
verdadera y falsa
Ejecuta todos los bucles en sus lmites y con sus lmites
operacionales
Ejercita las estructuras internas de datos para asegurar
su validez

Criterios de Cobertura lgica

10

Cobertura de Sentencias
Cobertura de Condiciones
Criterios de decisin/Condicin
Criterio de Condicin Mltiple
Criterio de Cobertura de Caminos

Menos Riguroso
(Mas Barato)

Ms Riguroso
(Ms Caros)

Grafo de Flujo de las Estructuras

Bsicas de programa
11
11

Secuencia

Si x Entonces
(If x Then Else)

Hacer hasta x
(Do Until x)
Repetir

Mientras x Hacer
(While x Do )

Separar todas las condiciones

Agrupar sentencias simples en bloques
Numerar todos los bloques y tambin las condiciones

Variantes de Prueba de Caja

Blanca
12

Prueba del Camino Bsico

Prueba de Condicin

Prueba de Flujo de Datos

Prueba de Bucles

Prueba del camino Bsico

13

Complejidad Ciclomtica (La complejidad de

McCabe V (G))
La

mtrica de McCabe ha sido muy popular en el

diseo de pruebas

Es

un indicador del nmero de caminos independientes

que existen en un grafo

Diagramas de Flujo
14

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
Fjese que cada nuevo camino
introduce una nueva arista.
Cul es el nuevo camino?
Grafo de Flujo
Representa el Flujo de control
lgico mediante notacin
ilustrada

Complejidad ciclomtica
15

La complejidad ciclomtica es
una mtrica del software
que proporciona una
medicin cuantitativa de
la complejidad lgica de
un programa

Un camino independiente es
cualquier camino del programa
que introduce, por lo menos, un
nuevo conjunto de sentencias de
proceso o una nueva condicin

Definicin: Es el nmero
de caminos
independientes del
conjunto bsico
de un programa y nos da
un lmite superior para
el
nmero de pruebas que se
deben realizar para
asegurar
que se ejecuta cada
sentencia al menos una
vez

16

Formas de calcular la complejidad

ciclomtica V(G)
V (G) = a n + 2
V (G) = r
V (G) = c + 1
Donde

: # de arcos o aristas del grafo

n : # de nodos
r : # de regiones cerradas del grafo
c : # de nodos de condicin

17

Determinamos la complejidad
ciclomtica
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 condicin + 1 = 6

Ejemplo de clculo de V(G)

18

1
a1

a2

a3

a4

Regin 1

a5

a6

a7

Regin 2

a8

a9

Regin 3

a10
a11

7
a13

10
Regin 5

11

V (G) = 5 Regiones
Cerradas

a12

Regin 4

V (G) =14-11+2=5

a14

V (G) = 4+1= 5
Condiciones

Ejemplo de clculo de V(G)

19

V (G) = 3

20

Qu es lo que se logra con la

complejidad ciclomtica?

V (G) marca el lmite mnimo de casos de prueba

para un programa
Cuando V (G) >10 la probabilidad de defectos en
el mdulo o programa crece mucho entonces quizs
sea interesante dividir el mdulo.

Prueba del camino Bsico

21

Pasos para la obtencin de Casos de Prueba

1.
2.
3.
4.

Dibujar el grafo de flujo

Calcular la complejidad ciclomtica
Determinar un conjunto bsico
Preparar los casos de prueba para el camino bsico

Ejemplo prueba del camino Bsico

22

Ejemplo, teniendo la siguiente LDP:

Ejemplo prueba del camino Bsico

23

Determinamos los caminos independientes:

Ejemplo prueba del camino Bsico

24

Calculamos la complejidad ciclomtica para el

ejemplo: V(G) = 3
Identificamos los casos de prueba:

Prueba de Condicin
25

Condicin Simple
Variable

Lgica: True/False
Expresin relacional: E1 (operador relacional) E2
E1

y E2 son expresiones aritmticas

Operador Relacional (<, <=, >, >=, =, )

Condicin Compuesta
Condiciones

simples
Operadores lgicos: NOT, AND, OR
Parntesis

Estrategias Prueba de Condiciones

26

Prueba de Ramificaciones
Condicin

Verdadera
Condicin Falsa
Cada condicin simple

Prueba de Dominio
E1<operador-relacional>E2
Se necesitan 2n (n>0) pruebas como mximo
para encontrar errores

Ejemplo Prueba de Condiciones

27

Ejemplo de Prueba de Condicin:

Prueba de Condicin
28

Ventajas

La cobertura de la prueba de una condicin es

sencilla
La cobertura de la prueba de las condiciones de un
programa da una orientacin para generar
pruebas adicionales del programa

Prueba de flujo de datos

29

Esta tcnica 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 proteccin 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 condicin o
bloque (seleccionando un camino del programa,
determinamos si el camino es factible para el
programa)

Prueba de Bucles
30

Tipos de pruebas:

Bucles simples
Bucles Anidados
Bucles Concatenados
Bucles no estructurados

Prueba de Bucles
31

Bucles Simples

Saltar el bucle
Pasar slo 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

32

Intenta encontrar
categoras:

errores

de

las

siguientes

Funciones Incorrectas o Ausentes

Errores de Interfaz
Errores en estructuras de datos o acceso a bases de
datos externas
Errores de rendimiento
Errores de inicializacin y terminacin

Pruebas de Caja Negra

33

Variantes de pruebas de caja negra:

Mtodos de prueba basados en grafos

Particin Equivalente
Anlisis de valores lmite
Prueba de Comparacin
Conjetura de Errores

Mtodos de prueba basados en

grafos
34

Pasos a seguir para una prueba de caja negra:

1.

2.

Entender los objetos que se van a modelar y las

relaciones que conectan a estos.
Definir una serie de pruebas que verifique que
todos los objetos tienen entre ellos la relaciones
esperadas

Particin equivalente
35

Divide el dominio de entrada en clases de datos

Consiste en identificar las clase de equivalencia
(conjunto de estados vlidos o invlidos para
condiciones de entrada
Pasos para identificar clases de equivalencia:
1.
2.

Identificacin de las condiciones de entrada del

programa
Identificar las clases de equivalencia:
a)
b)

Datos vlidos
Datos no vlidos

Particin equivalente
36

Pasos para identificar casos de prueba:

1.

2.

3.

Asignar un nmero nico para cada clase de

equivalencia
Escribir casos de pruebas para todas las clases
vlidas
Escribir casos de pruebas para todas las clases no
vlidas

Ejemplo de clases de equivalencia

37

Aplicacin bancaria en la que el operador debe

proporcionar un cdigo, un nombre y una operacin:

Anlisis de valores lmite

38

Las reglas para identificar las clases son:

1.

2.

3.
4.

Si una condicin de entrada especifica un rango que deben

generar casos para los extremos.
Si la condicin de entrada especifica un nmero finito y
consecutivo de valores, escribir casos para los nmeros
mximo, mnimo, uno ms del mximo y uno menos del
mnimo de valores
Usar la regla 1 para la condicin de salida.
Usar la regla 2 para cada condicin de salida.

Prueba de Comparacin
39

Se desarrollan versiones independientes de una

aplicacin 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 comparacin en tiempo real de los
resultados

Conjetura de Errores
40

Enumerar una lista de equivocaciones que pueden

cometer los desarrolladores
Generar casos de prueba en base a dicha lista
La generacin de casos se obtiene en base a la
intuicin o la experiencia

Pruebas Aleatorias
41

Se simula los posibles datos de entrada en la

secuencia y frecuencia que pueden aparecer en la
practica
Si el proceso de generacin se ha realizado
correctamente, se crearn eventualmente todas las
posibles entradas del programa en todas las
posibles combinaciones y permutaciones
Baja probabilidad de encontrar errores

En Resumen
42

Si su software fuera un edificio, se parecera ms a uno de

la izquierda o de la derecha?

Resumen
43

En la cadena de valor del desarrollo de un software especfico,

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 Bsico, pruebas de Condicin, pruebas de
Flujo de Datos y prueba de Bucles
La complejidad ciclomtica es el nmero de caminos
independientes del conjunto bsico de un programa y nos da un
lmite superior para el nmero 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 mtodos de
prueba basados en grafos, particin equivalente, anlisis de
valores lmite, prueba de comparacin y conjetura de errores

Preguntas?
44

Qu tcnicas aplicara para las pruebas de

caja negra?

Referencias
45

Eric Braude, Ingeniera de Software. Una perspectiva orientada a

objetos (1ra. Edicin)

Roger S. Pressman, Ingeniera de Software: Un enfoque prctico

(7ma edicin)

Captulo 18: Prueba de aplicaciones convencionales

Ingeniera de Software. Un enfoque desde la gua SWEBOK (1ra.

edic.), Salvador Snchez, Miguel ngel Sicilia, Daniel Rodrguez

Captulo 8, Pruebas de unidades

Captulo 9, Integracin, verificacin y validacin del sistema

Captulo 7: Pruebas

Guillermo Pantaleo, Ludmila Rinaudo, Ingeniera de Software

(1ra. Edicin)

Captulo 16, Pruebas de software

Captulo 17, Proceso de pruebas de software