Tipos de Prueba de Software

5/11/2018 Tipos de Prueba de Software - slidepdf.com

http://slidepdf.com/reader/full/tipos-de-prueba-de-software 1/6

REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA

LA EDUCACIÓN SUPERIOR

ALDEA UNIVERSITARIA SOCIALISTA

CIUDAD ANGOSTURA

MISION SUCRE

ING. EN SISTEMAS

Prof. (a): INTEGRANTE:

Domingo Méndez Fernando Flores C.I. 11.724.856

Ciudad Bolívar, Noviembre 2011



Pruebas de Software:

Las pruebas de software son una parte del proceso de aseguramiento de calidad.

Realizar pruebas a un sistema de información 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 evaluación de algún 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 escogerán 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 función matemática, 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 desempeño en el equipo, el tiempo de retardo de las salidas hasta el nivel de recuperación del

sistema luego de fallas o caídas sean estas producidas por manejo incorrecto de datos, equipo, o

producidas externamente como cortes de energía.

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 organización por lo que la prueba de caja negra

no termina una vez que salió del laboratorio. La prueba con intervención del usuario es un pequeño



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 cuestión

de datos de prueba. Esta parte de la prueba no podría hacerse sin que el usuario haya tenido previo

contacto con los prototipos del sistema, y para los testers una efectiva interacción 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 también podrían ser cajas negras, entendiendo qué es lo que

hace, pero sin dar importancia a cómo 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:

También se le conoce como prueba de caja transparente y Se realizan para verificar líneas

específicas de código de manera de ver que funcionan tal como están definidas.

Para esta prueba se consideran tres importantes puntos:

Conocer el desarrollo interno del programa, determinante en el análisis de coherencia y

consistencia del código.

Considerar las reglas predefinidas por cada algoritmo.

Comparar el desarrollo del programa en su código con la documentación pertinente.

La primera parte de esta prueba es el análisis estático.

Análisis estático Manual

Inspección: Determina si el código esta completo y correcto, como también las

especificaciones.

Walkthrough: Interrelación informal entre testers, creadores y usuarios del sistema.

Análisis estático Automático



Verificación estática: Compara los valores generados por el Programa con los rangos de

valores predefinidos haciendo una Descripción del funcionamiento de los procedimientos en

términos booleanos determinando los puntos de falla.

Ejecución simbólica: Hace un seguimiento de la comunicación entre funciones, módulos,

aplicaciones, luego de que todas las partes hayan sido verificadas por separado.

La segunda parte de esta es el análisis dinámico. Para esto se cuenta con diferentes tipos de herramientas.

Análisis de cobertura: Examina las extensiones del código, haciendo una caja blanca por

modulo.

Trafico: Sigue todos los caminos de comunicación entre módulos guardando los valores de las

variables en cada uno de ellos.

Simulador: Simula partes del sistema para el cual el hardware no está habilitado.

Sintonía: Testea los recursos utilizados durante la ejecución del programa.

Prueba de certeza: Examina las construcciones lógicas del programa.

Aunque las pruebas de caja blanca son aplicables a varios niveles unidad, integración y sistema,

habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de

ejecución dentro de cada unidad función, clase, módulo, etc. pero también pueden testear los flujos

entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.

A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos de

prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, pese a

garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.

Las principales técnicas de diseño de pruebas de caja blanca son:

Pruebas de flujo de control

Pruebas de flujo de datos

Pruebas de bifurcación (branch testing)

Pruebas de caminos básicos



Prueba de Stress:

Es el acto de asegurar que el sistema funciona como se espera bajo grandes volúmenes de

transacciones, usuarios, carga y además revisión técnica. Además 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 aplicación en los momentos de carga extrema y ayuda a los

administradores para determinar si la aplicación 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 aíslan los servicios y componentes que

conforman el sistema, se infieren los métodos de navegación, de funcionamiento y de interfaz de

estos servicios y componentes y se crea un cliente de prueba que llame a dichos métodos. Para

aquellos métodos 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 más de lo que la aplicación podría experimentar en condiciones

normales. Utilice, por ejemplo, un bucle de 1 – 10.000.000 lo más rápidamente posible y observe si

hay problemas evidentes. La comprobación de cada DLL ayuda a identificar errores más importantes

con el componente.



Prueba de Stress de Integración:

Después de forzar cada componente individual, deberá someter a una situación de stress a

toda la aplicación con todos sus componentes y servicios. Las pruebas de stress de integración estání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 aplicación. Las pruebas de

integración comienzan con una comprobación básica 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

aplicación. Las secuencias de comandos de prueba deberán probar la aplicación de acuerdo con el uso

previsto. Por ejemplo, si la aplicación muestra una página Web que un 99% de los clientes

simplemente visitará y en la que sólo un 1% comprará realmente, tiene sentido proporcionar

secuencias de comandos de prueba que fuercen la búsqueda y las distintas funciones de exploración.

Por supuesto, la cesta de la compra también debe comprobarse, pero el uso previsto sugiere que la

mayoría de las pruebas deberían centrarse en las funciones de búsqueda. Intente prolongar siempre la

duración de las pruebas, tanto como se lo permitan el calendario y el presupuesto. En lugar de realizar

pruebas durante unos cuantos días o una semana, prolongue el período de pruebas a un mes, un

trimestre o un año y observe cómo funciona la aplicación durante un período de tiempo más largo.

Prueba de Huracán:

Se utilizan para simular efectos cíclicos dentro de una tarea, ósea hacen referencias a algunos

tipos de pruebas en sistemas en forma de ciclos repetitivos para contemplar el diagnostico.

El espécimen 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 módulos,

submódulos y partes de componentes de un sistema.

Tipos de Prueba de Software

Documents

Transcript of Tipos de Prueba de Software