1. Pruebas del Software
Maestrantes:
Gladys María Rodríguez
Domingo Florentino Muñoz
Margarita Cepeda Gómez
Bonao, julio 2012
2. Introducción a las pruebas del software
Pruebas: concepto y objetivos
Objetivos de las pruebas
Encontrar defectos en el software
Una prueba tiene éxito si descubre un defecto
Una prueba fracasa si hay defectos pero no los
descubre
Pruebas de Verificación
Ver si cumple las especificaciones de diseño
Pruebas de Validación
Ver si cumple los requisitos del análisis
3. Introducción a las pruebas del software
Pruebas del Software
El proceso de pruebas del software tiene dos objetivos:
1. Demostrar al desarrollador y al cliente que el software
satisface sus requerimientos.
Para el software a medida, significa que debe haber al menos
una prueba para cada requerimiento del sistema y del usuario.
Para software genérico, significa que debe haber pruebas para
todas las características del sistema que se incorporarán en la
entrega del producto.
Este objetivo conduce a las pruebas de validación => se
espera que el sistema funcione correctamente usando un
conjunto determinado de casos de prueba que reflejan el
uso esperado de aquél.
4. Introducción a las pruebas del software
Pruebas del Software
2. Descubrir defectos en el software: que su
comportamiento es incorrecto, no deseable o no cumple
su especificación.
La prueba de defectos está relacionada con la
eliminación de todos los comportamientos no deseables.
Ej: caídas del sistema, interacciones no permitidas con
otros sistemas, cálculos incorrectos y corrupción de
datos.
Este objetivo conduce a la prueba de defectos, cuando
los casos de prueba se diseñan para exponer los
defectos.
5. Introducción a las pruebas del software
Modelo del Proceso de Pruebas del
Software
6. Introducción a las pruebas del software
Pruebas de “caja blanca”
Concepto y terminología
Pruebas en que se conoce el código a probar
Caja blanca (clear box: caja clara o transparente)
Se procura ejercitar cada elemento del código
Algunas clases de pruebas
Pruebas de cubrimiento
Pruebas de condiciones
Pruebas de bucles
7. Introducción a las pruebas del software
Pruebas de cubrimiento
Ejecutar al menos una vez cada sentencia
Se necesitan varios casos de prueba
Determinar posibles “caminos” independientes
Cada condición debe cumplirse en un caso y en otro
no. En general, se necesitan tantos casos como
condiciones, más uno (número ciclomático)
Puede ser imposible cubrir el 100%
Código que nunca se ejecuta: condiciones imposibles
Ejemplo: detección y notificación de errores internos
en un código sin errores
8. Introducción a las pruebas del software
Pruebas de condiciones
Cumplir o no cada parte de cada condición
Se necesitan varios casos de prueba
Determinar expresiones simples en las condiciones
Una por cada operando lógico o comparación
Cada expresión simple debe cumplirse en un caso y
en otro no, siendo decisiva en el resultado
Puede ser imposible cubrir el 100%
Expresiones simples no independientes
PRUEBAS-8
9. Introducción a las pruebas del software
Pruebas de bucles
Conseguir números de repeticiones especiales
Bucles simples
Repetir cero, una y dos veces
Repetir un número medio (típico) de veces
Repetir el máximo-1, máximo y ¡máximo +1!
Bucles anidados
Repetir un número medio (típico) los bucles internos,
el mínimo los externos, y variar las repeticiones del
bucle intermedio ensayado.
Ensayarlo con cada nivel de anidamiento
PRUEBAS-9
10. Introducción a las pruebas del software
Pruebas de “caja negra”
Concepto y terminología
Pruebas en que se conoce sólo la interfaz
Caja negra (black box: caja opaca)
Se procura ejercitar cada elemento de la interfaz
Algunas clases de pruebas
Cubrimiento invocar todas las funciones (100%)
Clases de equivalencia de datos
Pruebas de valores límite
11. Introducción a las pruebas del software
Pruebas de valores límite
Complemento a las particiones de equivalencia
Varios casos de prueba por cada partición
Valores típicos, intermedios
Valores primero y segundo del rango
Valores penúltimo y último
Valores vecinos fuera del rango (en otra partición)
Motivación
Los programadores se equivocan con más frecuencia
al tratar los valores en la frontera (Ej: > en vez de )
12. Introducción a las pruebas del software
Estrategias de prueba del software
Contenido
Pruebas de unidades
Pruebas de integración
Pruebas de regresión
Pruebas de validación
13. Introducción a las pruebas del software
Pruebas sin estrategia
Motivación
Las pruebas son incómodas
La pruebas son aburridas
“Estoy seguro de que lo he codificado bien”
Probar todo junto, al final - Big-Bang
Falla por todas partes
Muy difícil diagnosticar las causas de los fallos
Muy costoso de arreglar
Resultado productos finales defectuosos
14. Introducción a las pruebas del software
Actividades de prueba de software
Actividades de desarrollo
Doc. Requisitos
Análisis
P. validación
Diseño
P. integración
Doc. Diseño
Codificación P. unidades
Cod. Módulos
Integración
Cód. Completo
Mantenimiento
15. Introducción a las pruebas del software
Pruebas de Unidad
Se concentra en el esfuerzo de verificación de la
unidad más pequeña del diseño del software: el
componente o módulo del software.
Las pruebas de unidad se concentran en la lógica del
procesamiento interno.
Este tipo de prueba se puede aplicar en paralelo a
varios componentes.
16. Introducción a las pruebas del software
Pruebas de unidades
Se prueba cada módulo
Programa
de prueba
Módulo en
pruebas
Reales o
simulados
Otros Otros (stubs)
módulos módulos
17. Introducción a las pruebas del software
Pruebas de Integración
“Si todo funciona bien individualmente, ¿por qué dudan que
funcione cuando se une?
La prueba de integración es una técnica sistemática para
construir la arquitectura del software, mientras, al mismo
tiempo, se aplican las pruebas para descubrir errores asociados
con la interfaz.
El objetivo es tomar componentes a los que se aplicó una
prueba de unidad y construir una estructura de programa que
determine el diseño.
A menudo se tiende a intentar una integración que no sea
incremental (enfoque “big bang”), se combinan todos los
componentes por anticipado, se prueba todo el programa como
un todo.
18. Introducción a las pruebas del software
Pruebas de integración
La principal dificultad que surge en las pruebas de
integración es localizar los errores.
Hay interacciones complejas entre los componentes del sistema,
y cuando se descubre una salida anómala, es difícil identificar
dónde ha ocurrido el error.
Para facilitar la localización de errores, debería utilizarse una
aproximación incremental para la integración y pruebas del
sistema.
Inicialmente, debería integrarse una configuración del sistema
mínima y probar este sistema.
A continuación, deberían añadirse componentes a esta
configuración mínima y probar después de añadir cada
incremento.
19. Introducción a las pruebas del software
Pruebas de regresión
Repetir las pruebas tras cada modificación
Repetir sólo pruebas de verificación
Pruebas de unidades
Pruebas de integración
Conservar y actualizar los programas de prueba
Usar herramientas de ejecución automática de las
pruebas
20. Introducción a las pruebas del software
Pruebas de Regresión
Cuando se integra un nuevo incremento, hay que
volver a ejecutar las pruebas para incrementos
previos, así como las nuevas pruebas requeridas
para verificar la nueva funcionalidad del sistema.
Volver a ejecutar un conjunto existente de pruebas se
denomina pruebas de regresión.
Si las pruebas de regresión nos muestran problemas,
entonces hay que verificar si éstos son problemas en el
incremento previo o si son debidos al incremento
añadido de funcionalidad.
21. Introducción a las pruebas del software
Pruebas de Validación
Las pruebas de validación empiezan tras la culminación de la
prueba de integración, cuando se han ejercitado los
componentes individuales. Se ha terminado de ensamblar el
software como paquete y se han descubierto y corregido los
errores de interfaz.
La prueba se concentra en las acciones visibles para el usuario
y en la salida del sistema que éste puede reconocer.
La validación se define de una forma simple en que se alcanza
cuando el software funciona de tal manera que satisface las
expectativas razonables del cliente (especificación de
requisitos-criterios de validación.
22. Introducción a las pruebas del software
Pruebas de validación
Comprobar que se satisfacen los requisitos
Se usan la mismas técnicas, pero con otro objetivo
No hay programas de prueba, sino sólo el código
final de la aplicación
Se prueba el programa completo
Uno o varios casos de prueba por cada requisito o
caso de uso especificado
Se prueba también rendimiento, capacidad, etc. (y no
sólo resultados correctos)
Pruebas alfa (desarrolladores) y beta (usuarios)
23. Introducción a las pruebas del software
Pruebas del Sistema
Al final del desarrollo el software se incorpora a otros
elementos del sistema (hardware, personas, información) y se
realiza una serie de pruebas de integración del sistema y de
validación.
Estas pruebas están más allá del alcance del proceso del
software y no las realizan únicamente los ingenieros de
software.
Sin embargo, los pasos dados durante el diseño y la prueba del
software mejorarán en gran medida la probabilidad de tener
éxito en la integración del software del sistema mayor.
24. Introducción a las pruebas del software
Pruebas del Sistema
Prueba de seguridad
La interrupción abarca un amplio rango de
actividades: hackers
La prueba de seguridad comprueba que los
mecanismos de protección integrados en el sistema
realmente lo protejan de irrupciones inapropiadas.
Durante la prueba de seguridad quién la aplica
desempeña el papel del individuo que desea entrar en
el sistema.
25. Introducción a las pruebas del software
Pruebas del Sistema
Prueba de resistencia
Las pruebas de resistencia están diseñadas para confrontar los
programas con situaciones anormales.
La prueba de resistencia ejecuta un sistema de tal manera que
requiera una frecuencia o un volumen anormal de recursos
La persona que aplica la prueba tratará de sobrecargar el programa.
Una variante de la prueba de resistencia es una técnica denominada
prueba de sensibilidad.
Las pruebas de sensibilidad tratan de descubrir combinaciones de
datos dentro de las clases de entrada válidas que causen
inestabilidad o procesamiento inapropiado.
26. Introducción a las pruebas del software
Pruebas del Sistema
Prueba de desempeño
La prueba de desempeño está diseñada para probar el
desempeño del software en tiempo de ejecución dentro del
contexto de un sistema integrado.
La prueba de desempeño se aplica en todos los pasos del
proceso de la prueba, incluso al nivel de la unidad, el
desempeño de un módulo individual debe evaluarse mientras
se realizan las pruebas.
Sin embargo no es sino hasta que se encuentren totalmente
integrados todos los elementos del sistema que es posible
asegurar el verdadero desempeño del sistema.
27. Introducción a las pruebas del software
Diseño de casos de prueba
El diseño de casos de prueba es parte de las pruebas de
componentes y sistemas.
Consiste en diseñar los casos de prueba (entradas y
salidas esperadas) para probar el sistema.
El objetivo es crear un conjunto de casos de prueba
que sean efectivos descubriendo defectos en los
programas y muestren que el sistema satisface sus
requerimientos.
Para diseñar un caso de prueba, se selecciona una
característica del sistema o componente que se está
probando.
28. Introducción a las pruebas del software
Pruebas basadas en
requerimientos
Un principio general es que los requerimientos
deben poder probarse.
Los requerimientos deberían ser escritos para
que se pueda diseñar una prueba y un
observador pueda comprobar que los mismos se
satisfacen.
En las pruebas basadas en requerimientos el
usuario considera cada requerimiento y deriva
un conjunto de pruebas para cada uno de ellos.
29. Introducción a las pruebas del software
Automatización de las Pruebas
Las pruebas son una fase cara y laboriosa del
proceso del software.
Estas herramientas ofrecen una serie de
facilidades y pueden reducir mucho los costos
de las pruebas.
Ya vimos las pruebas de regresión.
Cada prueba individual se puede implementar
como un objeto y un ejecutador de pruebas
ejecuta todas las pruebas.
Las pruebas deben escribirse para que indiquen
si el sistema probado funciona como se
esperaba.
30. Introducción a las pruebas del software
Automatización de las Pruebas
Las pruebas son una fase cara y laboriosa del
proceso del software.
Estas herramientas ofrecen una serie de
facilidades y pueden reducir mucho los costos
de las pruebas.
Ya vimos las pruebas de regresión.
Cada prueba individual se puede implementar
como un objeto y un ejecutador de pruebas
ejecuta todas las pruebas.
Las pruebas deben escribirse para que indiquen
si el sistema probado funciona como se
esperaba.
32. Introducción a las pruebas del software
Automatización de las Pruebas
1. Gestor de pruebas. Gestiona la ejecución de las pruebas del
programa.
Mantiene un registro de los datos de las pruebas, resultados
esperados y facilidades probadas del programa.
2. Generador de datos de prueba. Genera datos de prueba para
el programa a probar.
Se logra seleccionando datos de una base de datos o
utilizando patrones para generar datos aleatorios.
3. Oráculo. Predice resultados esperados de las pruebas.
Pueden ser versiones previas del programa o sistemas de
prototipos.
33. Introducción a las pruebas del software
Automatización de las Pruebas
Las pruebas back-to-back implican ejecutar el oráculo y
el programa a probar, en paralelo.
Las diferencias entre sus salidas son resaltadas.
4. Comparador de ficheros. Compara los resultados de las
pruebas del programa con los resultados de pruebas
previas e informa de las diferencias entre ellos.
Se utilizan en pruebas de regresión, donde se comparan
los resultados de ejecutar diferentes versiones.
34. Introducción a las pruebas del software
Automatización de las Pruebas
5. Generador de informes. Proporciona informes y facilidades
de generación para los resultados de las pruebas.
6. Analizador dinámico. Añade código a un programa para
contar el número de veces que se ha ejecutado cada sentencia.
Después de las pruebas, se genera un perfil de ejecución que
muestra cuántas veces se ha ejecutado cada sentencia del
programa.
7. Simulador. Hay varios tipos de simuladores.
Los simuladores de la máquina objetivo simulan la
máquina sobre la que se ejecuta el programa.
35. Introducción a las pruebas del software
Resumen
1. Prueba de unidad: es la prueba de cada módulo, que normalmente
realiza el propio personal de desarrollo en su entorno
2. Prueba de integración: con el esquema del diseño del software, los
módulos probados se integran para comprobar sus interfaces en el trabajo
conjunto
3. Prueba de validación: el software totalmente ensamblado se prueba
como un todo para comprobar si cumple los requisitos funcionales y de
rendimiento, facilidad de mantenimiento, recuperación de errores, etc.
4. Prueba del sistema: el sw. ya validado se integra con el resto del sistema
(rendimiento, seguridad, recuperación y resistencia)
5. Prueba de aceptación: el usuario comprueba en su propio entorno de
explotación si lo acepta como está o no
36. Introducción a las pruebas del software
Relación entre productos de desarrollo y niveles de prueba
Requisitos de Pruebas de
usuario aceptación
Especificación de
Pruebas de sistema
requisitos
Diseño modular Pruebas de integración
Especificación
Pruebas de unidad
lógica del módulo
Código
37. Introducción a las pruebas del software
Pruebas de Caja Negra y Caja
Blanca
Hay dos maneras de probar cualquier producto construido:
1. Si se conoce la función específica para la que se diseño el producto, se aplican
pruebas, que demuestren que cada función es plenamente operacional, mientras se
buscan los errores de cada función. (Prueba de Caja Negra)
2. Si se conoce el funcionamiento interno del producto, se aplican pruebas para
asegurarse de que todas las “piezas encajan”, es decir, que las operaciones internas
se realizan de acuerdo a las especificaciones, y que se han probado todos los
componentes internos de manera adecuada. (Prueba de Caja Blanca)