INGENIERIA DEL SOFTWARE Un enfoque practico Roger S. Pressman





Estrategias de prueba
de software









Tabla de contenido
Pág.

INTRODUCCIÓN














ESTRATEGIAS DE PRUEBA DE SOFTWARE

UN ENFOQUE ESTRATÉGICO PARA LAS PRUEBAS DEL SW
Las pruebas comienzan a nivel de modulo y trabajan hacia fuera.
Según el momento son apropiadas diferentes técnicas de prueba.
La prueba la lleva acabo el responsable deldesarrollo del SW.
La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba.
VERIFICACIÓN Y VALIDACIÓN
La verificación se refiere al conjunto de actividades que asegura que el software efectúa adecuadamente sus funciones.
La validación se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta alo requerimientos del cliente.
Bohem, lo define de otra forma:
Verificación “¿Estamos construyendo el producto correctamente?”
Validación “¿Estamos construyendo el producto correcto?”
ORGANIZACIÓN PARA LAS PRUEBAS DEL SW
No es correcto:
Que el responsable del desarrollo no debería entrar en la prueba.
El SW debe ser puesto a salvo de personas que puedan probarlo de forma despiadada.
Losencargados de la prueba solo aparecen cuando comienzan las etapas de la prueba.
CRITERIOS PARA COMPLETAR LA PRUEBA
Cuando se efectúan las pruebas del SW surgen unas preguntas clásicas:
¿Cuándo hemos terminado la prueba? ¿Cómo sabemos que hemos probado lo suficiente?
‘¿Cuándo debemos probar?’
“La prueba nuca termina ya que el responsable carga o pasa el problema al cliente”
Otra respuestaalgo cínica es “Se termina la prueba cuando se agota el tiempo o el dinero disponible para cada efecto”
ASPECTOS ESTRATÉGICOS
Ton Gilb, plantea que se deban abordar los siguientes puntos si se desea implementar con éxito una estrategia de prueba del SW:
Especificar los requisitos del producto de manera cuantificable mucho antes que comiencen las pruebas.
Establecer los objetivos de la pruebade manera explícita.
Comprender que usuarios van a manejar el SW y desarrollar un perfil para cada categoría de usuario.
Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido.
Construir un SW 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 evaluarla 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.
PRUEBA DE UNIDAD
La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software (Módulo). Aquí se prueban los caminos de control importantes, con el fin de descubrir errores dentro del ámbito de unmódulo.
¿ERRORES MÁS COMUNES DURANTE LA PRUEBA DE UNIDAD?
Procedencia aritmética incorrecta mal aplicada
Operaciones de modo mezcladas.
Inicializaciones incorrectas.
Falta de precisión.
Representación incorrecta de una expresión.
PRUEBA DE INTEGRACIÓN.
“Si todos funcionan bien ¿Por qué dudar de que no funcionen todos juntos?”
La prueba de Integración es una técnica sistemática paraconstruir la estructura del programa mientras que al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción. Su objetivo es recoger los módulos mediante la prueba de unidad y construir una estructura.
TIPOS DE INTEGRACIÓN
La primera es no incremental “big bang”. Se combinan todos los módulos por anticipado, se prueba todo el producto.
La segunda esuna integración incremental en donde se desarrollan módulos pequeños y funcionales que hacen que los errores sean más fácil de aislar y corregir.
LA PRUEBA DE REGRESIÓN
Cada vez que se añade un nuevo módulo 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 cabo anteriormente...