m
m

¿Qué es probar software?

Algunas definiciones incorrectas:
‡ Probar es demostrar que no hay errores presentes en un programa.
‡ El propósito de probar es mostrar que el programa realiza correctamente las funciones
esperadas.
La definición Correcta
‡ Probar es el proceso ejecución de un programa con el fin de encontrar errores.
¿Por qué Probar Software?
!
  


ëtras Definiciones
‡ Verificar.
‡ Validar.
‡ Pruebas.
‡ Caso de Prueba.
‡ Defecto.
‡ Fallo.
‡ Error.

m 

 


 
m
!

La prueba es el proceso de ejecución de un programa con la intención de descubrir
un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error
no descubierto hasta entonces.
Una prueba tiene éxito si descubre un error no detectado hasta entonces.
!m m!m
!

A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos
del cliente.
Las pruebas deberían planificarse mucho antes de que empiecen.
Las pruebas deberían empezar por ´lo pequeñoµ y progresar hacia ´lo grandeµ.
 !m m!m
!


o son posibles las pruebas exhaustivas.

Para ser más eficaces (pruebas con la más alta probabilidad de encontrar errores), las pruebas
deberían ser realizadas por un equipo independiente.
 !m m!m
!


Se debe inspeccionar a conciencia el resultado de cada prueba para, así, poder descubrir
posibles síntomas de defectos.
Cada caso de prueba debe definir el resultado de salida esperado.
Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no
válidos e inesperados.
!m m!m
!


Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo)
‡ Probar si el software no hace lo que debe hacer
‡ Probar si el software hace lo que no debe hacer, es decir si provoca efectos
secundarios
Se deben evitar los casos desechables.
!m m!m
!

o deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos
en los programas, y dedicando pocos recursos a las pruebas.
La experiencia indica que donde hay un defecto hay otros.
Las pruebas son una tarea creativa como el desarrollo de software.

mm
!

ëperatividad
ëbservabilidad
Controlabilidad
Capacidad de descomposición
Simplicidad
Estabilidad
Facilidad de comprensión
  

!

Debe tener una alta probabilidad de encontrar un error.

o debe ser redundante.
Debe ser la mejor de todas las posibles.
o debe ser ni demasiado sencilla ni demasiado compleja.
!!

La depuración (localización y corrección de defectos).

El análisis de la estadística de errores.

m!

!

 m
!

Enfoque estructural o de caja blanca.

Enfoque funcional o de caja negra.

Enfoque Aleatorio.
 !


 


Öaranticen 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.
m
m 

m

Cobertura de Sentencias.
Cobertura de decisiones.
Cobertura de Condiciones. K
 
Criterios de decisión/Condición.
K  
Criterio de Condición Múltiple.
Criterio de Cobertura de Caminos (impracticable)

K 

K 

 




m
!


Î Î


 

     K
 


 


 
  
Separar todas las condiciones
Agrupar sentencias ¶simples· en bloques
umerar todos los bloques y tambien las condiciones
 
  
!


!m

  
!  
"

# 
$  
!$ 
# $ %

·
!
&  
 '

 (
)

  
* )

!
& +
 &
$$ #  '
,
(
 (


$ 
(
 (
 

! 
$ 
  
*     
*  
·
(,
!  
"

# 
$    
(!

 
 -
#  #
!$  # $ %
·
(!
··
   

m

!



 


a) Prueba del Camino Básico.

b) Prueba de Condición.

c) Prueba de Flujo de Datos.

d) Prueba de Bucles.
!

m  m
Complejidad Ciclomatica(La complejidad de McCabe V (Ö))

' 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.

 




!m
m
m


V (Ö) = a ² n + 2
V (Ö) = r
V (Ö) = 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.


 
!m

m
m

V (Ö) marca el límite mínimo de casos de prueba para un programa.

Cuando V (Ö) >10 la probabilidad de defectos en el módulo o programa crece mucho

entonces quizás sea interesante dividir el módulo.
!

·
·
 



 %
· a) V (Ö) =14-11+2=5

 

 %
 


  %

b) V (Ö) = 5 Regiones
·

··

·
Cerradas.
 %

 
·
·
 c) V (Ö) = 4+1= 5
·
 %
 Condiciones
··
!
 mm
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.



m
!

 mm 
Prueba de Ramificaciones.

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


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.

!
 
6ipos de pruebas:

‡ Bucles simples.

‡ Bucles Anidados.

‡ Bucles Concatenados.

‡ Bucles no estructurados.
!


 

mntenta encontrar errores de las siguientes categorías:
‡ Funciones mncorrectas o Ausentes.
‡ Errores de mnterfaz.
‡ Errores en estructuras de datos o acceso a bases de datos externas.
‡ Errores de rendimiento.
‡ Errores de inicialización y terminación.
!


 

Variantes de pruebas de caja negra.

‡ a) Métodos de prueba basados en grafos.

‡ b) Partición Equivalente.
‡ c) Análisis de valores límite.
‡ d) Prueba de Comparación.
‡ e) Conjetura de Errores.

!



 

Pasos a seguir para una prueba de caja
egra:
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 relaciónes esperadasµ
!

mm m


Pasos para identificar clases de equivalencia.

1. mdentificación de las condiciones de entrada del programa.

2. mdentificar las clases de equivalencia:

a) Datos válidos.
b) Datos no válidos.
!

mm m


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.
 !

m
 m

!m
m 

m
 
!
 
!!m
 m   
!
m 


#%
# 
 .#  
#

#
%## /  35$#&7300
35$#&7300
 !"#$%&'() *& 13004/5$#&4666
1300 4/5$#&4666 !5$#&8666
+,$ -./&*0*$12 9 & '*:+ ;&
($
? *&' ?
!.;.$ *%$<$/.;=. > $'/.;./% ; ' /.;./% ; '
&, ;./$5* @A' ?/.;./% ; '
 BC () D
' #
 B ,5'$%&D 13 $*#)*.&; *
*. =.'$#)$ *% ' · B!.#&<./%);.D EA=$.
<&*&'1
··0 %$;& <&*&'1
··0

mm
mm


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.
!
!

m
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.
 



Enumerar una lista de equivocaciones que pueden cometer los desarrolladores.

Öenerar casos de prueba en base a dicha lista.
La generación de casos se obtiene en base a la intuición o la experiencia.
!



m

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.
 m m
m

Fairley R. m
 
 .

Pressman, R.S. m
 

   

.