REPBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA EDUCACIN SUPERIOR ALDEA UNIVERSITARIA SOCIALISTA CIUDAD ANGOSTURA

MISION SUCRE ING. EN SISTEMAS

Prof. (a): Domingo Mndez

INTEGRANTE: Fernando Flores C.I. 11.724.856

Ciudad Bolvar, Noviembre 2011

Pruebas de Software:

Las pruebas de software son una parte del proceso de aseguramiento de calidad. Realizar pruebas a un sistema de informacin no significa necesariamente que el proceso de desarrollo este asegurado y que tampoco que de forma directa este mejorando. Es una actividad en la cual un sistema o uno de sus componentes se ejecutan en circunstancias previamente especificadas, los resultados se observan, registran y se realiza una evaluacin de algn aspecto.

Tipos de Pruebas:

Pruebas de Caja Negra:

Esta prueba verifica que el tem que se est 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 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 con dominio de los datos entrantes. 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. En otras palabras, de una caja negra nos interesar su forma de interactuar con el medio que le rodea, en ocasiones, otros elementos que tambin podran ser cajas negras, entendiendo qu es lo que hace, pero sin dar importancia a cmo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

Pruebas de Caja Blanca:

Tambin se le conoce como prueba de caja transparente y Se realizan para verificar lneas especficas de cdigo de manera de ver que funcionan tal como estn definidas. 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 primera parte de esta prueba es 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.

La segunda parte de esta es el anlisis dinmico. Para esto se cuenta con diferentes tipos 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 est habilitado. Sintona: Testea los recursos utilizados durante la ejecucin del programa. Prueba de certeza: Examina las construcciones lgicas del programa. Aunque las pruebas de caja blanca son aplicables a varios niveles unidad, integracin y sistema, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecucin dentro de cada unidad funcin, clase, mdulo, etc. pero tambin pueden testear los flujos entre unidades durante la integracin, e incluso entre subsistemas, durante las pruebas de sistema. A pesar de que este enfoque permite disear pruebas que cubran una amplia variedad de casos de prueba, podra pasar por alto partes incompletas de la especificacin o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecucin del cdigo analizado. Las principales tcnicas de diseo de pruebas de caja blanca son:

Pruebas de flujo de control Pruebas de flujo de datos Pruebas de bifurcacin (branch testing) Pruebas de caminos bsicos

Prueba de Stress:

Es el acto de asegurar que el sistema funciona como se espera bajo grandes volmenes de transacciones, usuarios, carga y adems revisin tcnica. Adems se enfoca en evaluar el comportamiento del sistema bajo condiciones anormales como extrema carga, memoria insuficiente, no disponibilidad de servicio o hardware o recursos compartidos limitados. La misma permite comprender mejor como y que reas del sistema colapsaran, de este modo es posible planificar contingencias y actualizar el mantenimiento, planear y asignar recursos de antemano. De manera de determinar la solidez de la aplicacin en los momentos de carga extrema y ayuda a los administradores para determinar si la aplicacin rendir lo suficiente en caso de que la carga real supere a la carga esperada.

Tipos de Prueba de Stress:

Prueba de Stress de Componentes:

Con las pruebas de stress de los componentes, se aslan los servicios y componentes que conforman el sistema, se infieren los mtodos de navegacin, de funcionamiento y de interfaz de estos servicios y componentes y se crea un cliente de prueba que llame a dichos mtodos. Para aquellos mtodos que tienen acceso a un servidor de base de datos o a cualquier otro componente, puede crear un cliente que proporcione datos simulados en el formato previsto. El equipo de prueba inserta datos simulados una y otra vez mientras observa los resultados. La idea es forzar cada componente de forma aislada ms de lo que la aplicacin podra experimentar en condiciones normales. Utilice, por ejemplo, un bucle de 1 10.000.000 lo ms rpidamente posible y observe si hay problemas evidentes. La comprobacin de cada DLL ayuda a identificar errores ms importantes con el componente.

Prueba de Stress de Integracin:

Despus de forzar cada componente individual, deber someter a una situacin de stress a toda la aplicacin con todos sus componentes y servicios. Las pruebas de stress de integracin estn ntimamente relacionadas con las interacciones con otras estructuras de datos, procesos y servicios tanto de los componentes internos como de otros servicios externos de la aplicacin. Las pruebas de integracin comienzan con una comprobacin bsica del funcionamiento. Es necesario que conozca los recorridos codificados y las situaciones a las que se enfrentan los usuarios, que comprenda lo que intentan hacer estos y que identifique todas las maneras en las que el usuario se mueve por la aplicacin. Las secuencias de comandos de prueba debern probar la aplicacin de acuerdo con el uso previsto. Por ejemplo, si la aplicacin muestra una pgina Web que un 99% de los clientes simplemente visitar y en la que slo un 1% comprar realmente, tiene sentido proporcionar secuencias de comandos de prueba que fuercen la bsqueda y las distintas funciones de exploracin. Por supuesto, la cesta de la compra tambin debe comprobarse, pero el uso previsto sugiere que la mayora de las pruebas deberan centrarse en las funciones de bsqueda. Intente prolongar siempre la duracin de las pruebas, tanto como se lo permitan el calendario y el presupuesto. En lugar de realizar pruebas durante unos cuantos das o una semana, prolongue el perodo de pruebas a un mes, un trimestre o un ao y observe cmo funciona la aplicacin durante un perodo de tiempo ms largo.

Prueba de Huracn:

Se utilizan para simular efectos cclicos dentro de una tarea, sea hacen referencias a algunos tipos de pruebas en sistemas en forma de ciclos repetitivos para contemplar el diagnostico. El espcimen puede ser cualquier tipo de elemento usado en cualquier tipo de subcomponente o modulo del sistema auditado. Normalmente las pruebas de huracanes se hacen en mdulos, submdulos y partes de componentes de un sistema.