1
Pruebas de Software
R. Casallas
Dpto. de Ingeniería de Sistemas y Computación
Universidad de los Andes
Agenda
Pruebas de Programas
Los Niveles de Prueba
3
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
Preparar Casos
de Prueba Ejecutar Casosde Prueba
Seleccionar y Priorizar los errores para corrección
Corregir Congelar versión del
Sw para Pruebas
Errors
Detectados? VersionAcceptada NO
SI
Verificar Correcciones Congelar versión corregida del Sw Hacer Pruebas Totales o parciales de Regresión
5
Proceso de Pruebas de Programas:
Depuración
Diagnosticar
Error Planificar Cambios
Actualizar Diseño Arquitec.
Actualizar Diseño Detallado
Actualizar código Actualizar Requerimientos
Probar los Cambios Seleccionar casos de prueba para probar los cambios
Selecionar casos de Prueba para Pruebas de Regresión
Pruebas de Regresión
?
Definición de Requerimientos
Análisis Requirementos Diseño Arquitectura Diseño Detallado Programación Pruebas Unitarias Preparacion Pruebas Unit. Pruebas Integración Preparación Integración Pruebas SIstema Preparación Pruebas Sistema Preparación Pruebas Aceptación Pruebas Aceptación
7
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
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
9
Agenda
Introducción
Inpecciones
Pruebas de Programas
Metodología de Pruebas
Los Niveles de Prueba
Diseño de Casos de Prueba
Pruebas Unitarias (1)
Descripción
Su propósito es encontrar errores en la lógica,
datos o algoritmos en componentes o subsistemas individuales
11
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
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
13
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
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
15
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
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
17
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
Agenda
Introducción
Pruebas de Programas
Metodología de Pruebas
Los Niveles de Prueba
Diseño de Casos de Prueba
Conceptos
19
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
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
21
Estructura del Espacio de Pruebas
Taxonomia 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.
Estructura del Espacio de Pruebas (2)
Taxonomia de los Casos de Prueba
Pruebas de tolerancia a fallas: considerar
condiciones anormales de operación, fallas hardware y software de la plataforma
23
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
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
Complementar la lista de casos de prueba,
25
Diseño de los Casos de Prueba (3)
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?
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
27
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:
Diseño de los Casos de Prueba (6)
Caso de uso
Procedimiento
Criterios de aceptación
Procedimiento
Criterios de aceptación
...
Caso de uso
...
29
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
