tipos de prueba de software
DESCRIPTION
Tipos de Prueba de SoftwareTRANSCRIPT
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
5/11/2018 Tipos de Prueba de Software - slidepdf.com
http://slidepdf.com/reader/full/tipos-de-prueba-de-software 2/6
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
5/11/2018 Tipos de Prueba de Software - slidepdf.com
http://slidepdf.com/reader/full/tipos-de-prueba-de-software 3/6
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
5/11/2018 Tipos de Prueba de Software - slidepdf.com
http://slidepdf.com/reader/full/tipos-de-prueba-de-software 4/6
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
5/11/2018 Tipos de Prueba de Software - slidepdf.com
http://slidepdf.com/reader/full/tipos-de-prueba-de-software 5/6
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.
5/11/2018 Tipos de Prueba de Software - slidepdf.com
http://slidepdf.com/reader/full/tipos-de-prueba-de-software 6/6
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.