Estrategia de pruebas de software

Estrategias de prueba del software

Proporciona una gua que describe los pasos que deben realizarse como parte de la prueba, cuando planear y llevar a cabo estos pasos y cuanto esfuerzo, tiempo y recursos se requerirn.

Un enfoque estratgico para las pruebas del SW

La prueba comienza en los componentes y opera hacia afuera,

hacia la integracin de todo el sistema.

Segn el momento son apropiadas diferentes tcnicas de prueba.

La prueba la lleva acabo el responsable del desarrollo del SW y para

proyectos grandes un grupo de prueba independiente.

La prueba y la depuracin son actividades diferentes, pero la

depuracin se debe incluir en cualquier estrategia de prueba.

Verificacin y Validacin (V &V)

La verificacin se refiere al conjunto de actividades que asegura que

el software implementa adecuadamente una funcin especfica.

La validacin se refiere a un conjunto diferente de actividades que

aseguran que el software construido se ajusta a lo requerimientos del cliente.

Bohem, lo define de otra forma:

Verificacin Estamos construyendo el producto correctamente? Validacin Estamos construyendo el producto correcto?

Organizacin de las pruebas del SW

No es correcto
El responsable del desarrollo no debera entrar en la prueba.

El SW debe ser puesto a salvo de personas que puedan probarlo

de forma despiadada.
Los encargados de la prueba solo aparecen cuando comienzan las

etapas de la prueba.

Una estrategia de prueba del SW

La prueba en el contexto de espiral

Una estrategia de prueba del SW

Desde el punto de vista procedimental

Requisitos
Diseo Codificacin Direccin del la prueba

Pruebas de alto nivel

Prueba de Integracin Prueba de unidad

Etapas de prueba del SW

Criterios para completar la prueba

Cada vez que se tratan de las pruebas del SW surgen unas preguntas clsicas:
Cundo hemos terminado la prueba? Cmo sabemos que hemos probado lo suficiente?

Aspectos estratgicos
Ton Gilb plantea que una estrategia de SW triunfar cuando quienes prueban el software:
Especifican los requerimientos del producto en forma cuantificable

mucho antes que comiencen las pruebas.

Establecen los objetivos de la prueba de manera explicita. Construyen un SW robusto diseado para probarse as mismo. Realizan revisiones tcnicas para valorar la estrategia de prueba y

los casos de prueba.

Prueba de unidad
La prueba de unidad centra el proceso de verificacin en la unidad mas pequea del diseo del software(Mdulo). Aqu se prueban los caminos de control importantes, con el fin de descubrir errores dentro del mbito de un mdulo.

Errores mas comunes durante la prueba de unidad

1. 2. 3. 4. 5.

Procedencia aritmtica incorrecta mal aplicada Operaciones de modo mezcladas. Inicializaciones incorrectas. Falta de precisin. Representacin incorrecta de una expresin.

Prueba de Integracin
Si todos funcionan bien Por qu dudar de que no funcionen todos juntos?

La prueba de Integracin es una tcnica sistemtica para construir la estructura del programa mientras que al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interfaz.

Tipos de integracin

No incremental big bang. Se combinan todos los mdulos por anticipado, se prueba todo el producto.

Incremental en donde se desarrollan mdulos pequeos y funcionales que hacen que los errores sean ms fcil de aislar y corregir.

Integracin descendente
Es una estrategia de integracin incremental a la construccin de la estructura de programas, en cual se integran los mdulos movindose en direccin hacia abajo por la jerarqua de control comenzando con el mdulo principal . Los mdulos subordinados al mdulo de control principal se incorpora en la estructura, de forma primero-en-profundidad, primero-en-anchura

Integracin ascendente
Es un modelo de integracin no incremental, en donde la construccin del diseo empieza de los mdulos atmicos (es decir, mdulos de los niveles mas bajos de la estructura del programa). Dado que los mdulos se integran de abajo hacia arriba, el proceso requerido de los mdulos subordinados siempre est disponible y elimina la necesidad de resguardos.

La prueba de regresin

Cada vez que se aade un nuevo modulo como parte de una prueba de integracin el software cambia. La prueba de regresin es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados.

Prueba de humo
La prueba de humo es un mtodo de prueba de integracin que es comnmente utilizada cuando se ha desarrollado un software empaquetado. Es diseado como una mecanismo para proyectos crticos por tiempos, permitiendo que el equipo de software valore su proyecto sobre una base slida. Se clasifican en: Pruebas funcionales: Ejercer el programa completo con varias entradas. Pruebas unitarias: Ejercicio de las funciones individuales, subrutinas, o los mtodos de los objetos

Beneficios sobre proyectos complejos y cruciales en el tiempo

La calidad del producto final mejora. El diagnostico y la correccin de errores se simplifican. El progreso es mas fcil de valorar.

Prueba de Validacin
La validacin puede definirse de muchas formas, pero una simple definicin es que la validacin se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente.

Pruebas Alfa y Beta

La prueba alfa se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. La prueba beta se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no est presente normalmente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no puede ser controlado por el desarrollador.

Prueba del sistema

Las pruebas de sistema buscan discrepancias entre el programa y sus objetivos o requerimientos, enfocndose en los errores hechos durante la transicin del proceso al disear la especificacin funcional.
Esto hace a las pruebas de sistema un proceso vital de pruebas, ya que en trminos del producto, nmero de errores hechos, y severidad de esos errores, es un paso en el ciclo de desarrollo generalmente propenso a la mayora de los errores.

Prueba de recuperacin
La prueba de recuperacin es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente. Si la recuperacin es automtica hay que evaluar la correccin de la inicializacin, de los mecanismos de recuperacin del estado del sistema, de la recuperacin de datos y del proceso de rearranque. Si la recuperacin requiere la intervencin humana, hay que evaluar los tiempos medios de reparacin (TMR) para determinar si estn dentro de unos lmites aceptables.

Prueba de seguridad
Este acceso al sistema incluye un amplio rango de actividades: piratas informticos que intentan entrar en los sistemas por deporte. Empleados disgustados que intentan penetrar por venganza. Individuos deshonestos que intentan penetrar para obtener ganancias personales ilcitas. La prueba de seguridad intenta verificar que los mecanismos de proteccin incorporados en el sistema lo protegern, de hecho, de accesos impropios.

Prueba de rendimiento
Realizada para determinar cmo un sistema lleva a cabo en trminos de capacidad de respuesta y estabilidad bajo una carga de trabajo en particular.

Tambin puede servir para investigar, medir, validar o verificar la calidad de los atributos del sistema, tales como la escalabilidad , la fiabilidad y el uso de los recursos.
Tipos: Pruebas de carga. Pruebas de estrs. Pruebas de resistencia.

Prueba de despliegue
Tambin llamada prueba de configuracin.
Ejercita el software en cada entorno en el que debe

operar.

Examina todos los procedimientos de instalacin y

software de instalacin especializado para los clientes.

El arte de la depuracin
La depuracin ocurre como consecuencia de una prueba efectiva. Es decir, cuando un caso de prueba descubre un error, la depuracin es el proceso que provoca la eliminacin del error.

La depuracin no es una prueba, pero siempre ocurre como consecuencia de la prueba. El proceso de depuracin siempre tiene uno de los dos resultados siguientes: Se encuentra la causa, se corrige y se elimina. No se encuentra la causa.

Por qu es tan difcil la depuracin?

Caractersticas de algunos errores dan algunas pistas:

El sntoma y la causa pueden ser geogrficamente remotos. El sntoma puede desaparecer(temporalmente) cuando se corrige otro

error. El sntoma puede ser causado por un error humano que no se rastrea fcilmente.

Tcticas de depuracin
Por fuerza bruta. Vuelta atrs. Eliminacin de la causa.

Correccin del error

Tres preguntas simples a plantearse antes de hacer la correccin:
La causa del error se produce en otra parte del programa? Qu siguiente error puede introducirse con la correccin

que esta a punto de realizar?

Qu debi hacerse para evitar este error desde el principio?

Muchas Gracias !!!