tipos software seguridad pruebas proceso niveles integracion funcionales ejemplos unit-testing testing white-box black-box-testing

unit-testing - seguridad - testing de software ejemplos



Pruebas unitarias, pruebas de caja negra y pruebas de caja blanca (4)

¿Qué son las pruebas unitarias, las pruebas de caja negra y las pruebas de caja blanca? Busqué en Google pero toda la explicación que encontré fue muy técnica. ¿Alguien puede contestar esta pregunta de una manera simple con un ejemplo apropiado?


Blackbox Testing: esta es siempre una prueba basada en el usuario o el cliente donde la prueba se realiza según el requisito proporcionado. Esta prueba es realizada por probadores solamente.

Pruebas de Whitebox: Esto es para verificar el flujo de la base de código. Probando el flujo de la declaración de condición, la instrucción de bucle, etc. Esto es principalmente por parte del desarrollador prospectivo.

Prueba de unidad: esto es parte de la prueba de caja blanca, ya que prueba cada método en código con sus datos de prueba y lo afirma. Hoy en día, esto lo hacen los evaluadores y la compañía, esta habilidad del evaluador es donde pueden entender el código y los algoritmos.


En las pruebas de caja negra, no le importa cómo funcionan los elementos internos de lo que se está probando. Usted invoca la API expuesta y verifica el resultado; no te importa lo que hizo la prueba para darte el resultado.

En las pruebas de caja blanca, le importa cómo funcionan los elementos internos de lo que se está probando. Entonces, en lugar de solo verificar la salida de su cosa, puede verificar que las variables internas de la cosa que se está probando son correctas.

La prueba unitaria es una forma de probar componentes de software. La "Unidad" es lo que se está probando. Puede hacer pruebas de caja blanca y negra con pruebas unitarias; El concepto es ortogonal a las pruebas de caja blanca / negra.


Prueba de caja negra:

  1. Tester es un humano y no el desarrollador
  2. El probador no sabe cómo se implementó el sistema *
  3. Tester informará un problema cuando la respuesta del sistema a cualquier paso de la prueba no sea el resultado esperado.

Prueba de caja blanca:

  1. Tester es un humano y no el desarrollador
  2. Tester sabe cómo se implementó el sistema *
  3. Tester informará un problema cuando la respuesta del sistema a cualquier paso de la prueba no sea el resultado esperado y es más probable que detecte un problema con el caso de prueba en sí o con el sistema a pesar de recibir los resultados esperados.

Examen de la unidad:

  1. Por lo general, Tester es un código que prueba un módulo particular dentro de un sistema. Por ejemplo, en Java, un proyecto puede tener una clase llamada Student y una clase de prueba llamada StudentTest. Para cada una de las funciones en Student (como getGrades ), StudentTest puede tener 0 o más funciones para probarlas (como getGradesTest ). Esta es solo una de esas maneras de hacerlo.
  2. El código de prueba normalmente solo conoce la salida esperada para varias entradas para una parte de un sistema.
  3. Las pruebas unitarias a menudo se ejecutan antes de enviar el código o se ejecutan automáticamente al crear una aplicación para implementar. El objetivo es evitar que se introduzcan tantos errores en el sistema al agregar, cambiar o eliminar funciones.

* La cantidad de conocimiento conocido entre un probador de caja negra y un probador de caja blanca varía de una organización a otra. Por ejemplo, lo que considero pruebas de usabilidad, otra compañía podría llamar pruebas de caja negra. Un probador de caja blanca en algunas compañías puede ser otro desarrollador (control de calidad del desarrollador), mientras que otra organización puede no permitir que un desarrollador complete las aprobaciones de prueba. Un probador de caja negra podría ser alguien que solo tiene una lista de instrucciones que deben seguir y validar, o puede ser alguien que generalmente sabe cómo funciona el sistema, pero no a un nivel particularmente detallado. Por ejemplo:

Un probador de caja negra puede o no identificar un problema a pesar de un caso de prueba que coincide con las expectativas, como un caso de prueba de comercio electrónico que omite el paso de recopilar una dirección de envío de salida de invitado.

Esencialmente, las pruebas de caja blanca y caja negra rara vez se implementan estrictamente. La mayoría de las organizaciones tienen pruebas unitarias, pruebas de desarrollador (que pueden o no estar documentadas formalmente, depende de las implicaciones de una falla), evaluadores de control de calidad (negro, blanco y todos los tonos de gris en el medio) y pruebas de usuario / firmas comerciales. off (las personas que deberían participar en el proyecto, pero en organizaciones mal administradas solo aparecen al principio y al final, y envían un proyecto completo para que lo diseñe justo antes de la implementación).


Una explicación muy poco técnica que carece de detalles ... Aquí viene ...

  • Blackbox Testing: prueba una aplicación sin ningún conocimiento de cómo funciona la aplicación interna

  • Whitebox Testing: prueba una aplicación con conocimiento de cómo funciona el interno, como tener el código fuente al lado mientras realiza la prueba.

  • Pruebas unitarias: Aquí es donde se crean pruebas que interactúan directamente con su aplicación. Verificará una función en su aplicación y assert que la respuesta debe devolver con el value X Las pruebas unitarias generalmente son creadas, pero no siempre por los mismos desarrolladores, mientras que si una empresa hace pruebas de caja blanca y caja negra, cualquiera puede realizarlas.

Esta es una explicación muy básica.