Mtodos de Prueba del Software

1
Métodos de Prueba del Software

• Jaime Ramírez
• Unidad de Programación

2
Contenido

• Definiciones básicas
• Principios de la Prueba
• Tipos de Pruebas
• Métodos de Prueba
• Revisiones de Código
• Recomendaciones para el Proyecto

3
Definiciones básicas

• Se llama Prueba del Software al proceso en el que
  se ejecuta un programa con el objetivo de
  detectar fallos (o errores).
• Un Defecto provoca un fallo.
• Se llama Depuración al proceso en el que se
  localiza el defecto que es la causa de un fallo,
  se determina la forma de corregirlo, se evalúa el
  efecto de la corrección y se lleva a cabo la
  corrección.
• Un Caso de Prueba se especifica indicando
• Alcance de la prueba.
• Entradas a proporcionar al programa.
• Salidas esperadas.

4
Principios de la Prueba (i)

• Un buen caso de prueba es el que tiene una alta
  probabilidad de mostrar un defecto no descubierto
  hasta entonces.
• Una prueba tiene éxito si descubre un defecto no
  detectado hasta entonces.
• No son posibles las pruebas exhaustivas.
• se deben escoger los mejores casos de prueba.
• no se puede asegurar la ausencia de defectos.

5
Principios de la Prueba (ii)

• Principio de Pareto aplicado a la Prueba
• El 80 de los defectos descubiertos durante las
  pruebas surgen al hacer un seguimiento del 20 de
  todos los módulos del programa

• Conviene aislar módulos sospechosos y probarlos
  concienzudamente.

6
Principios de la Prueba (iii)

• Si las pruebas las realiza alguien ajeno a la
  implementación, serán más efectivas.
• La prueba se puede llevar hasta el 50 o 60 del
  esfuerzo dedicado al proyecto ? es muy importante
  seleccionar bien las pruebas que se van a
  realizar.

7
Tipos de Pruebas (i)

• La Prueba Modular consiste en la prueba de cada
  módulo aislado del resto del sistema.
• Comprobación de las POSTs de los subprogramas.
• La Prueba de Integración se realiza a medida que
  los diferentes módulos del sistema se integran en
  el mismo. El objetivo fundamental de esta prueba
  es comprobar que las interfaces entre los
  distintos módulos son correctas.
• Corrección en los tipos y en la sintaxis en la
  invocación de procedimientos y funciones.

8
Tipos de Pruebas (ii)

• Prueba de Integración (sigue...)
• Se pueden utilizar tres posibles estrategias de
  integración
• De arriba a abajo (top-down) Consiste en empezar
  la integración y la prueba por los módulos que
  están en los niveles superiores de abstracción, e
  integrar incrementalmente los niveles inferiores.
• De abajo a arriba (bottom-up) Consiste en
  empezar la integración y la prueba por los
  módulos que están en los niveles inferiores de
  abstracción, e integrar incrementalmente los
  niveles superiores.
• De big-bang Consiste en integrar y probar todo
  al mismo tiempo.

9
Tipos de Pruebas (iii)Ejemplo Integración
Bottom-Up
Dibujar
Curva_C
Pluma
Papel
10
Tipos de Pruebas (iv)Ejemplo Integración
Bottom-Up
P_Papel
Papel
11
Tipos de Pruebas (v)Ejemplo Integración Bottom-Up
P_Pluma
P_Papel
Pluma
Papel
12
Tipos de Pruebas (vi)Ejemplo Integración
Bottom-Up
P_Curva_C
P_Pluma
Curva_C
P_Papel
P_Papel
Pluma
Pluma
Papel
Papel
13
Tipos de Pruebas (vii)Ejemplo Integración
Bottom-Up
P_Curva_C
Dibujar
Curva_C
P_Pluma
P_Papel
Pluma
Papel
14
Tipos de Pruebas (y viii)

• La Prueba del Sistema se realiza cuando se han
  integrado todos los módulos, y su objetivo es
  comprobar que el sistema satisface los requisitos
  del usuario, tanto los funcionales como los no
  funcionales.
• La Prueba de Aceptación se realiza una vez que el
  sistema se ha implantado en su entorno real de
  funcionamiento, y su objetivo es demostrar al
  usuario que el sistema satisface sus necesidades.

15
Métodos de Prueba

• Enfoque sistemático que ayuda a encontrar buenos
  conjuntos de casos de prueba, y a determinar su
  grado de cobertura.
• Dos enfoques alternativos
• Caja negra se comprueban las funcionalidades sin
  tener en cuenta la estructura interna.
• Caja blanca se comprueban los componentes
  internos (módulos, subprogramas, bucles,
  condiciones, etc.).
• Se deben combinar ambos enfoques
• Obtener un conjunto de casos de prueba
  razonablemente riguroso utilizando métodos de
  caja negra.
• Completar el conjunto con casos de prueba
  generados con métodos de caja blanca con la vista
  puesta en las partes del programa
  algorítmicamente más complejas.

16
Métodos de Caja Negra

• La elección de los casos de prueba no se va a
  basar en el conocimiento que se tenga acerca de
  la estructura del objeto, sino en el conocimiento
  acerca de la funcionalidad deseada.
• Casi siempre el número de combinaciones de
  entradas (válidas o inválidas) es muy elevado ?
  Las pruebas de caja negra exhaustivas casi
  siempre son imposibles.
• Algunos métodos de caja negra son
• Clases de equivalencia.
• Análisis de valores límite.
• Grafo causa-efecto.

17
Métodos de Caja Negra(Clases de Equivalencia)

• Consiste en dividir las posibles entradas al
  sistema en clases de equivalencia, de tal forma
  que todos los miembros de una misma clase de
  equivalencia reciban el mismo tratamiento.
• La partición se puede realizar teniendo en cuenta
  condiciones que deben cumplir las entradas.
• Se diseñan los casos de prueba de manera que
• Abarquen el mayor números de clases.
• Dos casos no prueben las mismas clases.

18
Métodos de Caja Negra(Ejemplo de C. de
Equivalencia)
19
Métodos de Caja Negra(Ejemplo de C. de
Equivalencia)

• Casos válidos
• 300 Nomina Depósito (1) (5) (9)
• 400 Viajes Cheque (1) (5) (8)
• 500 Coches Pago Factura (1) (5) (10)
• 600 Comida Retirada Fondos (1) (5) (11)
• Casos No Válidos
• 180 (2)
• 1032 (3)
• XY (4)
• ltCRgt (6)
• Regalos (7)
• Casa (12)

20
Métodos de Caja Negra(Valores Límite)

• Los errores se esconden en los rincones y se
  aglomeran en los límites.
• Consiste en seleccionar como casos de prueba
  aquellos valores de entrada que caen en la
  frontera de las clases de equivalencia (justo a
  un lado, justo al otro y justo en la frontera).
• Este método complementa al de las clases de
  equivalencia.

21
Métodos de Caja Negra(Grafo Causa-Efecto)

• Consiste en crear un grafo causa/efecto a partir
  de las especificaciones, y seleccionar
  suficientes casos de prueba como para asegurar la
  cobertura del grafo.
• Se llama causas a las características de los
  datos de entrada.
• Los efectos son las clases de salidas que puede
  proporcionar el programa.

22
Métodos de Caja Blanca o Transparente

• El programa que se desea probar se ve como una
  caja transparente ?
• La elección de los casos de prueba se va a basar
  en el conocimiento que se tenga acerca de la
  estructura del programa.
• Dependiendo del grado de cobertura que se desea
  lograr (ordenados de menos a más exhaustivos)
• Cobertura de sentencias.
• Cobertura de decisiones.
• Cobertura de condiciones.
• Cobertura de decisiones/condiciones.
• Cobertura de condiciones múltiples.
• Cobertura de caminos.

23
Métodos de Caja Blanca(Cobertura de Camino
Básico)

• La cobertura de caminos con bucles es
  impracticable.
• Aprox. factible a la cobertura de caminos C. de
  camino básico.
• Todo programa se puede representar mediante un
  grafo de flujo de control, donde cada nodo
  representa una condición o una secuencia de
  sentencias.
• Se deben diseñar los casos de prueba necesarios
  para cubrir todos los caminos independientes.
• Un camino independiente se diferencia de los
  otros en al menos una sentencia o en una
  condición (arista).
• Caminos Aristas nodos 2 Regiones

24
Métodos de Caja Blanca(Ejemplo de C. de Camino
Básico)

• 1 Enc False
• 2 I 1
• 3 while (not Enc)
• 4 and then (IltN) loop
• 5 if V(I) Elem
• then
• 6 Enc True
• else
• 7 I I 1
• end if
• 8 end loop
• 9 FIN

6
1, 2
3
4
5
8
9
7

• Caminos independientes
• 1-2-3-9 (imposible!)
• 1-2-3-4-9
• 1-2-3-4-5-6-8-.....
• 1-2-3-4-5-7-8-.....

• Casos de Prueba
• Elem ?V 1,3
• Elem ?V 2,4

25
Revisiones de Código

• Comprobación de escritorio (desk checking).
• Comprobación por pares o iguales (peer review).
• Inspección
• Un grupo de desarrolladores se asegura de que el
  código fuente cumple una serie de condiciones
  (checklist)
• Inicialización de variables, control de límites
  de arrays, liberación de memoria dinámica, etc.
• Walkthrough o visita guiada
• La realiza un grupo en el que al menos está el
  programador del código fuente a revisar
• Una persona ajena al código fuente prepara un
  conjunto de casos de prueba.
• Se ejecuta mentalmente en grupo el código para
  los casos de prueba. Ejecución guiada por el
  programador del código.
• Se plantean preguntas al programador del código.

26
Recomendaciones para el Proyecto

• Escribir un programa de prueba para cada paquete.
• Integrar paquetes siguiendo una estrategia
  bottom-up.
• Probar el programa para los valores límite, y
  para valores de entrada inválidos.
• Realizar revisiones en grupo del código fuente.
• Permitir a alguien ajeno al proyecto que juegue
  con vuestro programa.