Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

PRUEBAS DE CAJA NEGRA Y CAJA BLANCA

No description
by

Mauricio Carabali

on 26 September 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of PRUEBAS DE CAJA NEGRA Y CAJA BLANCA

Notes
Particiones de Equivalencia:
Análisis de Valores Límite:
Métodos Basados en Grafos.
PRUEBAS DE CAJA NEGRA Y CAJA BLANCA
PRUEBAS DE CAJA NEGRA Y CAJA BLANCA
La fase de pruebas es una de las más costosas del ciclo de vida software.La fase de pruebas es una de las más costosas del ciclo de vida software.

Una vez generado el código el software debe ser probado para descubrir el máximo de errores posibles antes de su entrega al cliente. Es probado para descubrir errores cometidos sin darse cuenta al realizar su diseño y construcción La prueba requiere una mayor cantidad del esfuerzo dedicado al proyecto que cualquier otra actividad de ingeniería del software.
PRUEBA DE CAJA BLANCA
Son pruebas estructurales. Conociendo el código y siguiendo su estructura lógica, se pueden diseñar pruebas destinadas a comprobar que el código hace correctamente lo que el diseño de bajo nivel indica y otras que demuestren que no se comporta adecuadamente ante determinadas situaciones. Ejemplos típicos de ello son las pruebas unitarias. Se centran en lo que hay codificado o diseñado a bajo nivel por lo que no es necesario conocer la especificación de requisitos, que por otra parte será difícil de relacionar con partes diseñadas a muy bajo nivel.
TECNICAS
Pruebas Hacking:
Es una prueba de penetración, en la cual se supone que el Hacker conoce todos los detalles del programa y se quiere averiguar que pasaría si un intruso entra en la misma.
Pruebas de flujo de control:
En estas pruebas se quiere encontrar errores en la parte lógica del programa. Utilizando las condiciones simples (operador-relación) o con condiciones complejas (N x [operador-relación]). Por ejemplo este encuentra errores con los paréntesis, con variables y hasta de operaciones aritméticas.
PRUEBAS DE CAJA NEGRA
Son pruebas funcionales. Se parte de los requisitos funcionales, a muy alto nivel, para diseñar pruebas que se aplican sobre el sistema sin necesidad de conocer como está construido por dentro (Caja negra). Las pruebas se aplican sobre el sistema empleando un determinado conjunto de datos de entrada y observando las salidas que se producen para determinar si la función se está desempeñando correctamente por el sistema bajo prueba. Las herramientas básicas son observar la funcionalidad y contrastar con la especificación.

Ejemplos típicos de pruebas de caja negra son la comprobación de valores límite, pruebas de integridad de la base de datos, pruebas de situaciones de excepción, o pruebas de rendimiento del sistema. Presentan una limitación en cuanto a que es prácticamente imposible reproducir todo el espectro por la innumerable cantidad de combinaciones de entrada posibles, agravada por el desconocimiento de la lógica interna.
Conclusion
El desarrollo de pruebas de caja blanca, no solo evalúa el comportamiento del usuario con la interfaz, sino que busca errores en el código fuente.
No es posible garantizar que un software o sistema jamás falle, tan solo se puede realizar pruebas que disminuyan este riesgo.
Las pruebas de caja negra, buscan verificar que la relación entre las entradas y las salidas sean correctas.
Pruebas de flujo de datos:
Por medio de esta herramienta se hace la selección mas adecuada del flujo de datos, para llegar a una resolución correcta. Esto para probar las variables y definiciones en el programa.
Pruebas de bifurcación (branch testing):
Como lo dice su titulo, es ligado a una bifurcación o para bucles. Con ella podemos definir si algún bucle esta correctamente implementado y si las lineas de código donde exista una condición es la mejor opción o si debería ser cambiada.
Pruebas de caminos básicos:
Esta prueba lo que demuestra es el conjunto de pasos base del programa, lo que quiere lograr es que cada sentencia de código se ejecute mínimo una vez. Acá se usan herramientas como grafos, diagramas de flujo, la complejidad ciclomática, entre otros.
La partición de equivalencia es un método de prueba de Caja Negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. La partición equivalente se dirige a una definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar. En otras palabras, este método intenta dividir el dominio de entrada de un programa en un número finito de clases de equivalencia. De tal modo que se pueda asumir razonablemente que una prueba realizada con un valor representativo de cada clase es equivalente a una prueba realzada con cualquier otro valor de dicha clase. Esto quiere decir que si el caso de prueba correspondiente a una clase de equivalencia detecta un error, el resto de los casos de prueba de dicha clase de equivalencia deben detectar el mismo error. Y viceversa, si un caso de prueba no ha detectado ningún error, es de esperar que ninguno de los casos de prueba correspondientes a la misma clase de equivalencia encuentre ningún error. El diseño de casos de prueba según esta técnica consta de dos pasos:

1. Identificar las clases de equivalencia.
2. Identificar los casos de prueba.

Las condicione límite son aquellas que se hayan en los márgenes de la clase de equivalencia, tanto de entrada como de salida. Por ello, se ha desarrollado el análisis de valores límite como técnica de prueba. Esta técnica nos lleva a elegir los casos de prueba que ejerciten los valores límite.

Análisis Causa-Efecto.

Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro.

Las pruebas de caja negra están especialmente indicadas en aquellos módulos que van a ser interfaz con el usuario (en sentido general: teclado, pantalla, ficheros, canales de comunicaciones, etc.) Este comentario no obsta para que sean útiles en cualquier módulo del sistema. Las pruebas de caja negra se apoyan en la especificación de requisitos del módulo. De hecho, se habla de "cobertura de especificación" para dar una medida del número de requisitos que se han probado.

VENTAJAS
Pruebas de Caja Negra
Ventajas: con ellas es fácil encontrar la función de un sistemas y poder probar esa capacidad y ver hasta que punto es capas de desarrollarse.
Desventajas: aveces estas pruebas pueden volverse complicadas si no se cuenta con datos suficientes para el estudio ya que un sistema puede tener maneras de ejecución complicadas y puede averiarse el sistema sin el debido cuidado.

Pruebas de caja blanca
Ventajas: es recomendable hacer estas pruebas si se tiene la oportunidad ya que por estas pruebas se conoce el funcionamiento interno de un sistema lo que si se aíslan los componentes de un sistema en cajas negras puede hacerse un prueba de caja blanca a cada componente lo que en consecuencia puede llegar a dar el funcionamiento de ese sistema o como es que trabaja.
Desventajas: para hacer una prueba de caja blanca se debe tener mucho cuidado en examinar los componentes de un sistema ya que cualquier dato incorrecto o datos perdidos ya sea por no vistos o incorrecto uso puede llevar a un sistema al colapso y si el sistema no es ensamblado correctamente puede tenerse por seguro que el sistema no cumplirá o bien todas sus funciones o no las cumplirá correctamente o simplemente no las cumplirá, esto es del punto de vista físico pero al estudiar un sistema del punto de vista logarítmico solo se deben aislar los logaritmos e identificar su funcionamiento aparte y luego su funcionamiento como un todo.
MAURICIO CARABALI
INGENIERIA DE SISTEMAS
UNIVERSIDAD ANTONIO NARIÑO
Full transcript