ESTRATEGIAS DE PRUEBA DEL SW

CONTENIDO
Introduccin Un enfoque estratgico Aspectos estratgicos de un software Prueba de unidad Prueba de integracin Prueba de Validacin Prueba del sistema El arte de la depuracin

ESTRATEGIAS DE PRUEBA DEL SW

Integra las tcnicas de diseo de casos de prueba en una serie de pasos bien planificados que dan como resultado una correcta construccin del software.
Tambin describe un mapa con los pasos que hay que llevar acabo como parte de la prueba, cuando se debe planificar y realizar esos pasos, cuanto esfuerzo, tiempo y recursos se van a requerir.

UN ENFOQUE ESTRATGICO PARA LAS PRUEBAS DEL SW

Para realizar pruebas efectivas se debe efectuar RTF antes de la prueba (esto elimina errores) Las pruebas comienzan a nivel de modulo y trabajan hacia fuera. (hacia la integracin del sistema) Segn el momento son apropiadas diferentes tcnicas de prueba. La prueba la lleva acabo el responsable del desarrollo del SW. La prueba y la depuracin son actividades diferentes, pero la depuracin se debe incluir en cualquier estrategia de prueba. Bebe incluir Bajo nivel y Alto nivel

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 PARA 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

Seria factible considerar que el proceso de ingeniera de software es equiparable a la espiral. Tambin es posible ver una estrategia para las pruebas.

UNA ESTRATEGIA DE PRUEBA DEL SW

Si se considera el proceso desde el punto de vista procedimental La prueba consiste en una

Requisitos
Diseo

Pruebas de alto nivel

serie de cuatro pasos

Prueba de Integracin Prueba de unidad

Codificacin Direccin del la prueba

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?

Cuando debemos probar?

Una respuesta La prueba nuca termina ya que el responsable carga o pasa el problema al cliente Otra respuesta algo cnica es Se termina la prueba

cuando se agota el tiempo o el dinero disponible para cada efecto

ASPECTOS ESTRATGICOS
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 (facilidad mant y uso).

Establecer los objetivos de la prueba de manera explicita (la efectividad y la cobertura el costo encontrar y corregir errores). Comprender que usuarios van a manejar el SW y desarrollar un perfil para cada categora de usuario.

ASPECTOS ESTRATGICOS

Desarrollar un plan de prueba que haga hincapi en la prueba de ciclo rpido.

Construir un SW robusto diseado para probarse as mismo (tcnicas antierror diagnosticar).

Usar revisiones tcnicas formales y efectivas como filtro antes de la prueba. Llevar acabo revisiones tcnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Desarrollar un enfoque de mejora continua al proceso de prueba. Debera medirse la estrategia de prueba.

PRUEBA DE UNIDAD.

La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo del software(Mdulo). Las pruebas de unidad es un

proceso para probar los subprogramas, las subrutinas, los procedimientos individuales o las clases en un programa.

Aqu se prueban los caminos de control importantes, con el fin de descubrir errores dentro del mbito de un mdulo.

QU ERRORES SON LOS MS 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?

Es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactan correctamente a travs de sus interfaces
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 interaccin.

TIPOS DE INTEGRACIN.
La primera es no incremental big bang. Se combinan todos los mdulos por anticipado, se prueba todo el producto. La segunda es una integracin 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

EJEMPLO.

Integracin descendente

M1
M2 M3 M4

M5
M8

M6

M7

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 (eliminar el efecto onda).

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 un mecanismo para proyectos crticos por tiempos, permitiendo que el equipo de software valore su proyecto sobre una base slida.

COMENTARIOS DE LA PRUEBA
La desventaja de la integracin descendente es la necesidad de resguardos. La principal desventaja de la integracin ascendente es que el el

programa como entidad no existe hasta que se haya aadido el ultimo mdulo.
La seleccin de una estrategia de integracin depende de las caractersticas del software y, a veces de la planificacin del proyecto, en algunos de los casos se puede usar un enfoque combinado(denominado pruebas Sndwich).

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.

CRITERIOS DE LA PRUEBA DE VALIDACIN

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.

Un problema tpico es la delegacin de culpabilidad, esto ocurre cuando se descubre un error y cada uno de los creadores de cada elemento del sistema echa la culpa del problema a los otros. Se debe anticipar a los posibles problemas y: 1.disear caminos de manejo de errores que prueben toda la informacin procedente de los elementos del sistema; 2.llevar a cabo una serie de pruebas que simulen la presencia de datos en mal estado o de otros posibles errores en la interfaz del software; 3.registrar los resultados de las pruebas como evidencia en el caso de que se le seale con el dedo; 4.participar en la planificacin y el diseo de pruebas del sistema para asegurarse de que el software se prueba de forma adecuada.

PRUEBA DEL SISTEMA.

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 re-arranque. 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 e 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 RESISTENCIA (STRESS)

La prueba de resistencia ejecuta un sistema de forma que
1.incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cmo responden las funciones de entrada; 2.disear pruebas especiales que generen diez, interrupciones por segundo, cuando las normales son una o dos; 3.ejecutar casos de prueba que requieran el mximo de memoria o de otros recursos; 4.disear casos de prueba que puedan dar problemas en un sistema operativo virtual

demande recursos en cantidad, frecuencia o volmenes anormales. Por ejemplo:

PRUEBA DE RENDIMIENTO.
La prueba de rendimiento est diseada para probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del proces de la prueba. Incluso al nivel de unidad, se debe asegurar el rendimiento de los mdulos individuales a medida que se llevan a cabo las pruebas de caja blanca. Sin embargo, hasta que no estn completamente integrados todos los elementos del sistema no se puede asegurar realmente el rendimiento del sistema.

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. Aunque la depuracin puede y debe ser un proceso ordenado, sigue teniendo mucho de arte. Un ingeniero del software, al evaluar los resultados de una prueba, se encuentra frecuentemente con una indicacin sintomtica de un problema en el software. Es decir, la manifestacin externa de un error, y la causa interna del error pueden no estar relacionadas de una forma obvia. El proceso mental, apenas comprendido, que conecta un sntoma con una causa es la depuracin.

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: 1. se encuentra la causa, se corrige y se elimina; 2. o no se encuentra la causa. En este ltimo caso, la persona que realiza la depuracin debe sospechar la causa, disear un caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrs a la correccin del error de una forma iterativa. Durante la depuracin encontramos errores que van desde lo ligeramente inesperado (por ejemplo, un formato de salida incorrecto) hasta lo catastrfico (por ejemplo, el sistema falla, producindose serios daos econmicos o fsicos).

EL PROCESO DE DEPURACIN

CONSIDERACIONES PSICOLGICAS
Desafortunadamente, todo parece indicar que la habilidad en la depuracin es un rasgo innato del ser humano. A ciertas personas se les da bien y a otras no. Aunque las manifestaciones experimentales de la depuracin estn abiertas a muchas interpretaciones, se han detectado grandes variaciones en la destreza para la depuracin de distintos programadores con el mismo bagaje de formacin y de experiencia.

ENFOQUES DE LA DEPURACIN.
Depuracin por fuerza bruta es la ms comn y menos eficiente a la hora de aislar la causa del error en el software. Aplicamos la depuracin por fuerza bruta cuando todo lo dems falla. La vuelta atrs es un enfoque ms normal porque se puede usar con xito para pequeos programas. Partiendo del lugar donde se descubre el sntoma, se recorre hacia atrs el cdigo fuente hasta que se llega a la posicin de error. Pero a medida que aumenta el nmero de lneas del cdigo, el nmero de posibles caminos de vuelta se hace difcilmente manejable. la depuracin eliminacin de causas se manifiesta mediante induccin o deduccin e introduce el concepto de particin binaria. Los datos relacionados con la ocurrencia del error se organizan para aislar las posibles causas. Se llega a una hiptesis de causa y se usan los datos anteriores para probar o revocar la hiptesis

BIBLIOGRAFIA

Fairley R. Ingeniera de Software. Pressman, R.S. Ingeniera del Software. Un enfoque prctico.