ESTRATEGIAS DE PRUEBAS DE SOFTWARE
ING. ALEJANDRA COLINA V
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Términos básicos
Aspectos estratégico para la prueba de software
Estrategias de prueba para software convencional
Estrategias de prueba para software orientado a objetos
Estrategias de prueba para WebApps
Pruebas de validación
Pruebas de sistema
El arte de la depuración
ESTRATEGIAS DE PRUEBA DE SOFTWARE
• Términos básicos
• Conjunto de actividades que se planean por adelantado y se realiza de forma sistemática para verificar el comportamiento de un programa en un conjunto finito.
Pruebas
• Guía que describe los pasos que se realizan como parte de la prueba
Estrategia de Prueba
ESTRATEGIAS DE PRUEBA DE SOFTWARE
• Términos básicos
• Conjunto de pasos que incluyen métodos de prueba y técnicas de diseño de casos de prueba específicos.
Plantilla de pruebas
• Conjunto de condiciones o variables bajo las cuáles se determinará si una software o una característica de éstos es parcial o completamente satisfactoria.
Casos de pruebas
ESTRATEGIAS DE PRUEBA DE SOFTWARE
La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas.
Es un proceso de ejecución de un programa con la intención de descubrir un error, no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.
ESTRATEGIAS DE PRUEBA DE SOFTWARE
La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del software.
Objetivos:
Detectar defectos en el software.
Verificar la integración adecuada de los componentes.
Verificar que todos los requisitos se han implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.
Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
ESTRATEGIAS DE PRUEBA DE SOFTWARE
EJEMPLO.
Cómo PROBAR un Automóvil antes de comprarlo.
¿Qué exámenes y/o comprobaciones debemos hacer antes de comprarlo?
1. Desde el punto de vista del usuario no podemos repetir todas las pruebas que realizo el fabricante antes de lanzarlo al mercado.
2. Debemos de limitar las pruebas a comprobaciones factibles a través de Internet o en el concesionario.
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Validar el financiamiento de la compra
Que nos guste
Comprobar el grado de confort
Capacidad, versatilidad, mantenibilidad Prestaciones:
Gasto de combustible / 100km
Tipo de combustible
Tiempo mínimo de conseguir velocidad
Estabilidad en curvas
Estabilidad en alta velocidad
Tiempo promedio entre mantenimientos
ESTRATEGIAS DE PRUEBA DE SOFTWARE
¿Cómo se relaciona este ejemplo con las pruebas de Software?
Tipo de Prueba Nombre Técnico Examinar el automóvil sin
conducirlo
Pruebas estáticas Comprobar características sin
conducirlos
Pruebas funcionales y estructurales
Probar al conducirlo Prueba de rendimiento
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Para realizar una prueba efectiva, debe realizarse revisiones técnicas efectivas
La prueba comienza en los componentes y opera “hacia afuera”, hacia la integración de todo el sistema de computo
Diferentes técnicas de prueba son adecuadas para distintos enfoques y en diferentes momentos
Las pruebas son realizadas por el desarrollador y un grupo de prueba independiente
Prueba y depuración no son iguales, pero se contienen entre si.
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Tipos de pruebas De alto nivel
Validan las principales funciones del sistema a partir de los requerimientos del cliente
De bajo nivel
Se diseñan con la finalidad de verificar que un pequeño segmento de código fuente se implemento correctamente.
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Prueba de Software
elemento
amplio
Verificación Validación
¿Construimos el producto correctamente?
¿Construimos el producto correcto?
VS
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Conjunto de tareas que garantizan que el software implementa correctamente una función especifica
Conjunto de diferentes tareas que aseguran que el software que se construye sigue los requerimientos del
cliente.
Verificación
Validación
ESTRATEGIAS DE PRUEBA DE SOFTWARE
La V&V incluyen un gama variedad de actividades relacionadas con la CALIDAD, entre ellas están:
Revisión de base de datos
Análisis de algoritmos
Pruebas de desarrollo
Pruebas de usabilidad
Pruebas de calificación
Pruebas de aceptación
Pruebas de instalación
Revisiones técnicas
Auditorias de calidad y configuración
Monitoreo de rendimiento
Simulación
Estudio de Factibilidad
Revisión de documentación
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Organización de las pruebas de Software
¿Quién conoce mejor el programa que sus desarrolladores?
Hay intereses con efectos negativos.
Desde el punto de vista PSICOLOGICO las fases de análisis y diseño son tareas Constructivas.
Se ve con buenos ojos la construcción del software y con desconfianza tratar de derrumbarlo
Con la PRUEBAS se intenta “romper” la construcción.
Es por ello que se consideran Destructivas.
En resumen, los errores estarán presentes y quien los encontrará?
EL CLIENTE
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Organización de las pruebas de Software
FALSOS MITOS…
Que el desarrollador no debe hacer pruebas en absoluto.
Que el software debe “ponerse contra la pared” que lo separe de extraños para probarlo sin piedad.
Que el personal que realice las pruebas debe involucrarse solo cuando se inician la fase de pruebas
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Organización de las pruebas de Software
El desarrollador es responsable de:
Pruebas de unidades individuales (componentes) del programa
Pruebas de integración
El grupo de prueba independiente (GPI) pretende “remover los problemas inherentes que están asociados con dejar” al desarrollador probar lo que construyo.
Permiten eliminar el conflicto de intereses que de cualquier manera pueden estar presentes
Se realizara un trabajo conjunto entre el GPI y el desarrollador
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Visión General
El Proceso de Software se puede ver como en espiral.
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Visión General
Una estrategia de prueba de software también puede verse en el contexto de espiral.
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Visión General
Prueba de Unidad se concentra en cada unidad del software
Prueba de Integración se centra en el diseño y la construcción de la arquitectura del software
Prueba de Validación se confrontan requerimientos contra el software que se construyo
Prueba de Sistema donde se prueba como un todo el software y otros elementos del sistema
En resumen, se tiene
ESTRATEGIAS DE PRUEBA DE SOFTWARE
Visión General
• Desde el punto de vista procedimental UNA ESTRATEGIA DE PRUEBA son una serie de pasos secuenciales:
Pruebas de Sistemas
Pruebas de Validación
ESTRATEGIAS DE PRUEBA DE SOFTWARE
• Criterios para completar las pruebas
Cada vez que se tratan de las pruebas del Software surgen unas preguntas clásicas:
¿Cuándo hemos terminado la prueba?
¿Cómo sabemos que hemos probado lo suficiente?
Una respuesta a la “La prueba nuca termina ya que el responsable carga o pasa el problema al cliente”
Otra respuesta algo cínica es “Se termina la prueba cuando se agota el tiempo o el dinero disponible para cada efecto”
“¿Cuando debemos probar?”
Aspectos estratégicos
Tom Gilb, plantea que se deban abordar los siguientes puntos si se desea implementar con éxito una estrategia de prueba
• Especificar los requisitos del producto de manera cuantificable mucho antes que comiencen las pruebas.
• Establecer los objetivos de la prueba de manera explicita (La efectividad de la prueba, la cobertura, el costo por descubrir y corregir defectos, etc.)
• Comprender que usuarios van a manejar el software y desarrollar un perfil para cada categoría de usuario.
Aspectos estratégicos
Tom Gilb, plantea que se deban abordar los siguientes puntos si se desea implementar con éxito una estrategia de prueba
• Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido.
• Construir un software robusto diseñado para probarse así mismo.
• Usar revisiones técnicas formales y efectivas como filtro antes de la prueba.
• Llevar acabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba.
• Desarrollar un enfoque de manera continua al proceso de prueba. Debería medirse la estrategia de prueba.
Aspectos estratégicos
“Probar solo los requerimientos del usuario final es como inspeccionar un edificio con base en el trabajo
realizado por el decorador de interiores a costa de cimientos, vigas y plomería”
Boris Beizer.
Estrategias de prueba para software convencional
• Prueba de Unidad
• Se centra los esfuerzos en la unidad mas pequeña del diseño de software: el componente o modulo
• Se enfocan en la lógica de procesamiento interno y de las estructuras de datos dentro de la frontera de un componente
• Se realiza en paralelo para múltiples componentes
Estrategias de prueba para software convencional
• Prueba de Unidad
¿Qué errores se encuentran comunes en las pruebas de Unidad?
• Falta de precisión
• Representación incorrecta de una expresión
• Operaciones de modo mezcladas
• Inicializaciones incorrectas
Estrategias de prueba para software convencional
• Prueba de Integración
Si todos funcionan bien.
¿Por qué dudar de que no funcionen todos juntos?
Existen muchas razones por las cuales un grupo de módulos que funcionan correctamente de forma independiente no lo hacen bien al trabajar juntos, entre las que están:
• El acceso a estructuras de datos globales
• La duplicidad en nombres de variables
• La actualización de datos
• La no uniformidad en el diseño de la interfaz
Estrategias de prueba para software convencional
• Prueba de Integración
Es una técnica sistemática para construir la arquitectura del software mientras se llevan a cabo pruebas para descubrir errores asociados con la interfaz.
La mejor forma de aplicar una prueba de integración, está aplicando un enfoque incremental, es decir, ir integrando los módulos poco a poco, con lo cual podemos aislar la detección de errores.
Estrategias de prueba para software convencional
Tipos de Prueba de Integración
• No incremental como lo es el enfoque “big bang”, consiste en integrar todos los módulos y una vez juntos probar el sistema esperando la explosión de errores que se puede generar.
• Integración incremental en donde se desarrollan módulos pequeños y funcionales que hacen que los errores sean mas fáciles de aislar y corregir
Pueden llevarse a efecto de diferentes formas
• Integración descendente
• Integración ascendente
• Por regresión.
• Prueba de humo
Estrategias de prueba para software convencional
• Integración Ascendente
Es un modelo de integración no incremental, en donde la construcción del diseño empieza de los módulos atómicos Los módulos son integrados de abajo hacia arriba, por ello el proceso requerido de los módulos subordinados siempre estará disponible elimina la necesidad de resguardos
Estrategias de prueba para software convencional
• Prueba de Regresión
Cada vez que se añade un nuevo modulo como parte de una prueba de integración el software cambia
La prueba de regresión es volver a ejecutar un subconjunto de pruebas que se han llevado a cao anteriormente para asegurar se de que los cambios no han propagado efectos colaterales no deseados
Estrategias de prueba para software convencional
• Prueba de Humo
• Es un método de prueba de integración que se utiliza cuando se ha desarrollado un software “empaquetado”.
• Es diseñado como mecanismo para proyectos critico por tiempos, permitiendo que el equipo de software valores su proyecto sirve una base solida
Estrategias de prueba para software convencional
Integración Descendente
• Necesidad de resguardos
Integración Ascendente
• El programa como entidad no existe hasta que se ha añadido el ultimo modulo
La selección de una estrategia de integración depende de las características del software y, a veces de a planificación del proyecto, en algunas de los casos se puede usar un enfoque combinado
Estrategias de prueba para software orientado a objetos
Prueba de Unidad en el contexto OO
• En el contexto de OO el concepto de unidad cambia.
• Se hace referencia al encapsulamiento determinando las clases y objetos
• Cada clase y cada instancia de una clase empaqueta los atributos (datos) y las operaciones que manipulan esos datos
• Una clase encapsulada en el foco de la prueba de unidad
• Ya no es posible probar una sola operación aislada sino mas bien como parte de una clase.
• La prueba se centra en las operaciones encapsuladas por la clases y el comportamiento de esta.
Estrategias de prueba para software orientado a objetos
Prueba de Integración en el contexto OO
• En el caso del software OO no existe una estructura de control jerárquica
• Hay dos pruebas para la integración OO Prueba basada en subprocesos
• Conjunto de clases requerido para responder a una entrada o un evento del sistema. Cada subproceso se integra y valida individualmente
Prueba basada en el uso:
• Se empieza en la construcción del sistema con las pruebas de clases independientes. Luego se llama a las clases dependientes usadas por las clases independiente
• Se sigue este proceso de capas de prueba de clases dependiente hasta construir todo el sistema
