Pruebas de Software

Material preparado por Rubby Casallas

Maestría en Ingeniería de Software

Departamento de Sistemas y

Computación

Universidad de los Andes1

Agenda

Pruebas de Programas

Metodología de Pruebas

Los Niveles de Prueba

Diseño de Casos de Prueba

2

Pruebas de Programas

Pruebas de programas es el proceso de

ejecutar programas con el propósito de

encontrar errores

Se puede mostrar la presencia de un error

pero no la ausencia [Dijkstra]

Debería ser visto como el último recurso

para encontrar errores

3

Proceso de Pruebas de Programas

4

Preparar Casos

de Prueba

Ejecutar Casos

de Prueba

Seleccionar y Priorizar los

errores para corrección

Corregir

Congelar versión del

Sw para Pruebas

Errors

Detectados?Version

Acceptada

NO

SI

Verificar Correcciones Congelar versión

corregida del Sw

Hacer Pruebas Totales o

parciales de Regresión

Proceso de Pruebas de Programas:

Depuración

5

Diagnosticar Error

Planificar Cambios

Actualizar Diseño Arquitec.

Actualizar Diseño Detallado

Actualizar código

Actualizar Requerimientos

Probar los Cambios

Seleccionar casos deprueba para probar los cambios

Selecionar casos dePrueba para Pruebas de Regresión

Pruebas de Regresión

?

Ciclo en V

6

Definición de Requerimientos

Análisis Requirementos

Diseño Arquitectura

Diseño Detallado

Programación

PruebasUnitarias

PreparacionPruebas Unit.

PruebasIntegración

Preparación Integración

PruebasSIstema

Preparación Pruebas Sistema

Preparación Pruebas Aceptación

PruebasAceptación

Técnicas de Prueba

Caja blanca o pruebas estructurales

El conocimiento del diseño interno del software se

usa para desarrollar los casos de pruebas

Caja negra o pruebas funcionales

Los casos de prueba son diseñados basados sólo

en la especificación externa del software

Pruebas basadas en escenarios o casos de

uso

Actuar como un usuario final y crear escenarios

reales para detectar errores

7

Técnicas de Prueba (2)

Pruebas Selectivas

Generar más casos de prueba para las funciones

o componentes que son más usados

Probar más rigurosamente las funciones o

componentes más críticos

Generar mas casos de prueba para las funciones

o componentes más complejos

8

Pruebas Unitarias

Descripción

Su propósito es encontrar errores en la lógica,

datos o algoritmos en componentes o

subsistemas individuales

Realizado por los desarrolladores del

componente

Técnica de prueba: Caja blanca

9

Pruebas Unitarias (2)

Guías para generar casos de prueba

Tratar de detectar errores en los algoritmos y la

lógica

Tratar de detectar errores en la manipulación de

las estructuras de datos

Tratar de detectar errores en el llamado a otros

módulos

Identificar todos los caminos posibles del módulo

y tratar de hacer casos de prueba que los cubran

Tratar de detectar errores usando datos límites

10

Pruebas de Integración

Descripción

Su propósito es encontrar errores en las

interfaces entre los módulos

Realizado por los desarrolladores de los módulos

que serán integrados

Técnica de Prueba: Caja negra basado en las

especificaciones de las interfaces

11

Pruebas de Integración (2)

Guías para generar casos de prueba

Tratar de detectar errores en los formatos de

intercambio de datos

Tratar de detectar errores en en el orden en que

interactúan los módulos, la sincronización y los

tiempos de respuesta

12

Pruebas de Sistema

Descripción

Su propósito es encontrar errores en el

comportamiento del sistema de acuerdo con la

especificación de requerimientos

Realizado por un grupo diferente al de desarrollo

Técnica de Prueba: Caja negra basado en los

requerimientos y en escenarios reales

13

Pruebas de Sistema (2)

Guías para generar casos de prueba

Verificar que la funcionalidad del sistema es

correcta y completa

Verificar que el sistema tiene la capacidad

volumétrica, de robustez y que se comporta bien

ante fallas

14

Pruebas de Aceptación

Descripción

Su propósito es verificar que el sistema satisface

los requerimientos del cliente (en el sitio del

cliente)

Realizado por un grupo de usuarios finales

Técnicas de Prueba: Caja negra basado en los

requerimientos y en escenarios reales

Guías para generar casos de prueba

Similar a pruebas del sistema

15

Pruebas de Regresión

Descripción

Su propósito es verificar que, después de un

cambio, las partes no cambiadas del sistema se

siguen comportanto igual (no hay efectos de

borde)

Están asociadas al mantenimiento de Software

16

Diseño de Casos de Prueba

Conceptos

Estructura del Espacio de Pruebas

Diseño de Casos de Prueba

17

Conceptos

Espacio de Prueba

Conjunto de todos los posibles casos de Prueba

Pruebas de subdominios

Subconjuntos del espacio de Prueba

Línea de Prueba (Test Suite)

Conjunto de casos de prueba que serán

ejecutados en una fase

18

Conceptos (2)

Testbed/Test Harness

Software adicional desarrollado para soportar la

ejecución de los casos de prueba

Prueba de Cubrimiento

Grado en el cual los casos de prueba “pasan” por

el código siendo probado

19

Estructura del Espacio de Pruebas

Taxonomía de los Casos de Prueba

Pruebas Funcionales: Considerar solamente

entradas válidas al sistema y condiciones

normales de operación.

Pruebas de Robustez: Considerar datos de

entrada inválidos, secuencias invalidas de

comandos/acciones, etc.

Pruebas de Frontera: Considerar valores/tamaños

mínimos y máximos para datos de entrada, carga

del sistema mínima y máxima, etc.

20

Estructura del Espacio de Pruebas (2)

Taxonomía de los Casos de Prueba

Pruebas de tolerancia a fallas: Considerar

condiciones anormales de operación, fallas

hardware y software de la plataforma

computacional sobre la que funciona el software

en prueba.

21

Diseño de los Casos de Prueba

Hacer una lista de los propósitos de prueba

Usar la taxonomía de los casos de prueba como

guía

22

Diseño de los Casos de Prueba (2)

Por cada propósito de prueba, hacer una lista

de casos de prueba

Construir una versión preliminar de la lista de

casos de prueba a partir de los escenarios típicos

relacionados con el propósito de prueba

Enriquecer la lista de casos de prueba,

analizando las posibles variaciones o casos

especiales de los escenarios considerados

23

Diseño de los Casos de Prueba (3)

Usar como guía la siguiente lista de chequeo:

¿Cuales son los errores típicos encontrados en

productos similares probados en el pasado, y que

casos de prueba se usaron para revelarlos?

En pruebas del sistema y pruebas de aceptación

¿Qué casos es probable que los desarrolladores

hubieran pasado por alto (desde el punto de vista del

experto del negocio o dominio de aplicación)?

En pruebas de unidad y pruebas de integración ¿qué

características complejas del diseño pudieron haber

sido implementadas de forma incorrecta?

24

Diseño de los Casos de Prueba (4)

En pruebas del sistema y pruebas de aceptación

¿Qué aspectos complejos acerca de los

requerimientos pudieron haber sido mal

interpretados por los desarrolladores?

¿Qué casos triviales pudieran haber sido no

tenidos en cuenta en la implementación?

25

Diseño de los Casos de Prueba (5)

Para cada caso de prueba, especificar los

pasos para realizar la prueba y los criterios

de aceptación de la prueba, tal como se

indica en el formato:

26

Diseño de los Casos de Prueba (6)

Caso de uso

Procedimiento

Criterios de aceptación

Procedimiento

Criterios de aceptación

...

Caso de uso

...

...

27

Diseño de los Casos de Prueba (7)

Para cada caso de prueba se debe

especificar

Instrucciones de prueba: lista de pasos a seguir

por los usuarios encargados de ejecutar la prueba

Criterios de aceptación: lista de condiciones

(predicados) que deben satisfacerse para

determinar el éxito de la prueba, incluyendo

restricciones sobre los datos de salida esperados,

y condiciones que deben cumplirse en el estado

interno del sistema (ej. valores de algunas tablas)

después de ejecutar el caso de prueba

28