Republica Bolivariana de Venezuela Ministerio del poder popular para la educacin Superior Instituto Universitario de Tecnologa Antonio Ricaurte

IUTAR, Cagua. Edo Aragua

Alumno: Yumary Hernndez Jos Capo Misleydis Lemus Jos Valencia Cagua, 06 de Febrero de 2013 CI.24332421 CI.18702519 CI.18552786 CI.15275367

Pruebas de 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. Las pruebas de sistema no son procesos para probar las funciones del sistema o del programa completo, porque sta sera redundante con el proceso de las pruebas funcionales. Las pruebas del sistema tienen un propsito particular: para comparar el sistema o el programa con sus objetivos originales (Requerimientos funcionales y no funcionales). Dado este propsito, se presentan dos implicaciones 1. Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba del sistema es el proceso de procurar demostrar cmo el programa, en su totalidad, no resuelve sus objetivos o requerimientos. 2. Las pruebas de sistema, por definicin, son imposibles si no estn los requerimientos por escrito, mensurables para el producto.

Pruebas Funcionales La prueba funcional es un proceso para procurar encontrar discrepancias entre el programa y la especificacin funcional. Una especificacin funcional es una descripcin exacta del comportamiento del programa desde el punto de vista del usuario final. La prueba funcional normalmente es una actividad de caja negra. Para realizar una prueba funcional, la especificacin se analiza para derivar un sistema de casos de prueba utilizando las diferentes tcnicas de caja negra.

Se confa en el proceso de pruebas unitarias para alcanzar los criterios deseados de cobertura de caja blanca.

Pruebas de Integracin Tienen como objetivo validar la correcta operacin entre los diferentes mdulos del sistema. El objetivo es demostrar que las interfaces de cada mdulo funcionan correctamente. Conjunto de pruebas unitarias, funcionales, de regresin y/o de aceptacin que se realizan las probar el software. Incluye tambin comprobar que lo programado por los diferentes desarrollados no choca entre s y que funcionar en un entorno real. Se comprueba la compatibilidad y funcionalidad de los interfaces entre las distintas partes que componen un sistema, estas partes pueden ser mdulos, aplicaciones individuales, aplicaciones cliente/servidor, etc. Este tipo de pruebas es especialmente relevante en aplicaciones distribuidas. Esta se usa si tu sistema usa otros servicios o sistemas externos a l, la corre el desarrollador y tambin un tester. PE: Mi aplicacin adems de generar un pdf lo enva por email, encolndolo en un servidor de correo, pruebo que el server de correo encole bien el mensaje y que agregue toda la informacin y el adjunto.

PRUEBAS DE CAJA BLANCA

Consiste en realizar pruebas para verificar que lneas especficas de cdigo funcionan tal como esta definido. Tambin se le conoce como prueba de caja-transparente. La prueba de la caja blanca es un mtodo de diseo de casos de prueba

que usa la estructura de control del diseo procedimental para derivar los casos de prueba. Las pruebas de caja blanca intentan garantizar que: Se ejecutan al menos una vez todos los caminos independientes de cada mdulo Se utilizan las decisiones en su parte verdadera y en su parte falsa Se ejecuten todos los bucles en sus lmites Se utilizan todas las estructuras de datos internas. Para esta prueba se consideran tres importantes puntos. Conocer el desarrollo interno del programa, determinante en el anlisis de coherencia y consistencia del cdigo. Considerar las reglas predefinidas por cada algoritmo. Comparar el desarrollo del programa en su cdigo con la documentacin pertinente. La prueba se divide en dos partes que son: a. El anlisis esttico Anlisis esttico Manual Inspeccin: Determina si el cdigo esta completo y correcto, como tambin las especificaciones. Walkthrough: Interrelacin informal entre testers, creadores y usuarios del sistema. Anlisis esttico Automtico Verificacin esttica: Compara los valores generados por el programa con los rangos de valores predefinidos haciendo una descripcin del funcionamiento de los procedimientos en trminos booleanos determinando los puntos de falla. Ejecucin simblica: Hace un seguimiento de la comunicacin entre funciones, mdulos, aplicaciones, luego de que todas las partes hayan sido verificadas por separado. b. El anlisis dinmico Para esto se cuenta con diferente tipo de herramientas. Anlisis de cobertura: Examina las extensiones del cdigo, haciendo una caja blanca por modulo. Trafico: Sigue todos los caminos de comunicacin entre mdulos guardando los valores de las variables en cada uno de ellos. Simulador: Simula partes del sistema para el cual el hardware no esta habilitado.

 Sintona: Testea los recursos utilizados durante la ejecucin del programa. Prueba de certeza: Examina las construcciones lgicas del programa.

PRUEBAS DE CAJA NEGRA

La prueba verifica que el tem se esta probando, cuando se dan las entradas apropiadas produce los resultados esperados. Los datos de prueba se escogern atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que el programa corra bien. El mtodo de la caja negra se centra en los requisitos fundamentales del software y permite obtener entradas que prueben todos los requisitos funcionales del programa. Con este equipo de pruebas se intenta encontrar: Funciones incorrectas o ausentes. Errores de interfaz Errores en estructuras de datos o en accesos a las bases de datos externas. Errores de rendimiento. Errores de inicializacin y terminacin. Con la aplicacin de esa tcnica se obtiene un conjunto de pruebas que: Reduce el nmero de casos de pruebas y nos dicen algo sobre la presencia o ausencia de errores. a. Particin equivalente: Una particin equivalente es un mtodo de prueba de caja negra que divide el dominio de entrada de un programa en clases de

datos. El diseo de casos de prueba para la particin equivalente se basa en la evaluacin de las clases de equivalencia. Anlisis de valores limite: Nos lleva a elegir las pruebas que nos ejecuten los valores lmite, con esta tcnica se complementa la particin equivalente. b. Prueba de comparacin: Esta tcnica consiste en la comparacin de salidas de un mismo software pero de sus diferentes versiones. Esta prueba implica una variada seleccin de los datos de prueba as como una buena interpretacin de los resultados para determinar el nivel de optimizacin de la funcionalidad del sistema. Se ha determinado con diferentes estudios estadsticos, que el software no debe ser probado por el creador o grupo de creadores del sistema ya que el extenso conocimiento de la estructura interna del programa limita la variedad de datos probados o el encaminamiento de las pruebas es hacia ciertos rasgos del programa olvidando otras partes del software poco valoradas por su simpleza en la creacin. Segn C. Kaner en su libro Testing Computer Software de 1993, el aspecto humano es esencial en la prueba de caja negra aplicando factibles sucesos de la vida real a la prueba, errores de tipeo, trabajar en aplicaciones equivocadas creyendo trabajar en la aplicacin deseada, etc., pero sucede que los programadores han pasado tanto tiempo en la creacin del sistema y al ser la prueba de caja negra una de las mas tempranas sus hechos factibles de la vida real estn entre el begin y el end de cada aplicacin. La prueba de caja negra ha hecho que cada organizacin dedicada al desarrollo de software contemple dentro de ella un departamento especial dedicado a las pruebas. El principal objetivo es determinar la funcionalidad del software y parte de tratar al programa como si fuera una funcin matemtica, estudiando si las respuestas o salidas son codominio de los datos entrantes (dominio). La prueba de caja negra tiene otras metas, determinar la eficiencia del programa desde el desempeo en el equipo, el tiempo de retardo de las salidas hasta el nivel de recuperacin del sistema luego de fallas o cadas sean estas producidas por manejo incorrecto de datos, equipo, o producidas

externamente como cortes de energa. La prueba de caja negra debe cubrir el espectro entero de sucesos factibles, de esto se debe ocupar el departamento de prueba, pero nunca se sabe si se han cubierto todos los casos o gran parte de ellos, no olvidemos que los testers pertenecen a la organizacin por lo que la prueba de caja negra no termina una vez que sali del laboratorio. La prueba con intervencin del usuario es un pequeo periodo de tiempo en el cual el usuario bajo el asesoramiento de testers, se desenvuelve en el software y examina la operabilidad de los datos que el maneja. El usuario dar la puntada final en la cuestin de datos de prueba. Esta parte de la prueba no podra hacerse sin que el usuario haya tenido previo contacto con los prototipos del sistema, y para los testers una efectiva interaccin con Herramientas case.

PRUEBAS UNITARIAS

Estas pruebas las corre el desarrollador, cada vez que va probando pedazos de cdigo o scripts para ver si todo funciona como el desea. Estas pruebas son muy tcnicas. Ejemplo: probar una consulta, probar que un pedazo de cdigo envi algo a imprimir, probar que una funcin devuelva un flag, etc. Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:

Automatizable: no debera requerirse una intervencin manual. Esto es

especialmente til para integracin contina. Completas: deben cubrir la mayor cantidad de cdigo. Repetibles o Reutilizables: no se deben crear pruebas que slo puedan ser ejecutadas una sola vez. Tambin es til para integracin continua. Independientes: la ejecucin de una prueba no debe afectar a la ejecucin de otra. Profesionales: las pruebas deben ser consideradas igual que el cdigo, con la misma profesionalidad, documentacin, etc. Ventajas El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de cdigo debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas bsicas: a. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el cdigo para mejorar su estructura (lo que se ha dado en llamar refactorizacin), puesto que permiten hacer pruebas sobre los cambios y as asegurarse de que los nuevos cambios no han introducido errores. b. Simplifica la integracin: Puesto que permiten llegar a la fase de integracin con un grado alto de seguridad de que el cdigo est funcionando correctamente. De esta manera se facilitan las pruebas de integracin. c. Documenta el cdigo: Las propias pruebas son documentacin del cdigo puesto que ah se puede ver cmo utilizarlo. d. Separacin de la interfaz y la implementacin: Dado que la nica interaccin entre los casos de prueba y las unidades bajo prueba son las interfaces de estas ltimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el

comportamiento de objetos complejos. e. Los errores estn ms acotados y son ms fciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.

Limitaciones Es importante darse cuenta de que las pruebas unitarias no descubrirn todos los errores del cdigo. Por definicin, slo prueban las unidades por s solas. Por lo tanto, no descubrirn errores de integracin, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Adems, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias slo son efectivas si se usan en conjunto con otras pruebas de software.