SUPERIOR DE HUETAMO

INGENIERIA EN SISTEMAS COMPUTACIONALES 5/28/12 DESARROLLO DE PROYECTOS DE SOFTWARE TEMA: 4.3.-Tecnicas de Diseo de Casos de Pruebas 4.4.-Enfoque PRCTICO Recomendado para el Diseo de Casos PROFRA.: iNG. mariela yannin magaaz Haga clic para modificar el guitierrez. estilo de subttulo del integrantes:
patrn B. PAOLA AGUIRRE

JOCELYN cRUZ BERNARDO MEZA RAUL MORENO FREDY DIAZ

5/28/12

Por qu probar?

Las fallas de software ocasionan graves prdidas econmicas; stos son 100 a 1000 veces ms costosos de encontrar y reparar despus de la construccin.

5/28/12

PRUEBA DE UNIDAD.
La prueba de unidad centra el proceso de verificacin en la menor unidad 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.

5/28/12

QU ERRORES SON LOS MS COMUNES DURANTE LA PRUEBA DE UNIDAD :

1.

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

2. 3. 4. 5.

5/28/12

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 interaccin.

5/28/12

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.

5/28/12

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

5/28/12

EJEMPLO.

Integracin descendente

M1 M2 M5 M8 M6 M3 M7 M4

5/28/12

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.

5/28/12

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.

5/28/12

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.

5/28/12

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.

5/28/12

PRUEBA DEL SISTEMA.

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.

5/28/12

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.

5/28/12

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.

5/28/12

La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volmenes anormales. Por ejemplo:
1.

PRUEBA DE RESISTENCIA (STRESS)

2.

3.

4.

Incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cmo responden las funciones de entrada; Disear pruebas especiales que generen diez, interrupciones por segundo, cuando las normales son una o dos; Ejecutar casos de prueba que requieran el mximo de memoria o de otros recursos; Disear casos de prueba que puedan dar problemas en un sistema operativo virtual

5/28/12

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.

5/28/12

Pruebas de regresin
Las posibilidades de que se produzcan este tipo de problemas depender mucho de la calidad de la codificacin y de la seccin del cdigo que se est tocando, ya que no es lo mismo tocar una clase con un altoacoplamientoque otra.

5/28/12

Pruebas de Aceptacin.
El objetivo de las pruebas de aceptacin es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptacin, desde el punto de vista de su funcionalidad y rendimiento. Las pruebas de aceptacin son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecucin y aprobacin final corresponden al usuario.

5/28/12

Pruebas de instalacin.
Algunos

tipos de sistemas de software tienen complicados procedimientos de instalacin. Las pruebas de los procedimientos de instalacin es una parte importante del proceso de prueba del sistema. Esto es particular de un sistema automatizado de instalacin que sea parte del paquete del programa.

5/28/12

Pruebas de utilidad
Es asegurar que la aplicacin satisfacen los re requerimientos establecidos. Una manera de a ser esto es cuantificar el nivel de satisfaccin que informan los usuarios al usar la aplicacin.

5/28/12

Las pruebas de sistema. Son pruebas de integracin del

sistema de informacin completo, y permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y tcnicas se cumplen. Dan una visin muy similar a su comportamiento en el entorno de produccin.

5/28/12

Pruebas de interfaz
Consiste

en probar la interfaz de usuario para garantizar que cumple los estndares y requerimientos definidos. Usualmente se refiere a la prueba de interfaz de usuario grfica.

5/28/12

Anlisis de valores lmite (AVL)

Esta

tcnica complementa a la de particin equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la eleccin de casos de prueba "en los bordes" de la clase. En lugar de centrarse solamente en las condiciones de entrada, el AVL deriva casos de prueba tambin para el campo de salida.

5/28/12

1.

Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben disear casos de prueba para los valores a y b y para valores justo por debajo y justo por encima de a y b, respectivamente. 2. Si una condicin de entrada especifica un nmero de valores, se deben desarrollar casos de prueba que ejerciten los valores mximo y mnimo. Tambin se deben probar los valores justo por debajo del mximo y del mnimo. 3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ej.

5/28/12 Pruebas de desarrolladores y artefactos En esta seccion se revisaran los artefactos involucrados en el proceso de pruevas de integracion .- modelo de casos de uso : uso tipico se la aplicacin y de los diagramas de secuencia para cada prueba. .- procedimiento de prueba: la manera en que se deben estableser y ejecutar las pruebas, y evaluar los resultados. .- evaluacion de prueba: resumen, detalles y efectos de los defectos encontrados. Plan de pruebas: plan global para realizar las pruebas, incluye el orden. .-Componentes delas pruebas: codigo fuente par als pruebas en si y para el codigo de la aplicacionque se debe probar. .- defectos: informes de los defectos decubirtos como resultado de este proceso clasificxado por la severidad y tipo.

5/28/12

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