Post on 10-Sep-2020
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