Prueba de caja negra vs caja blanca

La prueba de Caja Blanca es igual a la Prueba de Unidad de Software. El desarrollador o un comprobador de nivel de desarrollo (por ejemplo, otro desarrollador) se asegura de que el código que ha escrito funciona correctamente de acuerdo con los requisitos de nivel detallados antes de integrarlo en el sistema.

La prueba de Caja Negra es igual a la Prueba de Integración. El comprobador garantiza que el sistema funcione de acuerdo con los requisitos a nivel funcional.

Ambos enfoques de prueba son igualmente importantes en mi opinión.

Una prueba unitaria completa detectará defectos en la etapa de desarrollo y no después de que el software se haya integrado en el sistema. Una prueba de caja negra a nivel de sistema asegurará que todos los módulos de software se comporten correctamente cuando se integran juntos. Una prueba unitaria en la etapa de desarrollo no detectaría estos defectos, ya que los módulos generalmente se desarrollan independientemente unos de otros.

Caja negra

1 Se centra en la funcionalidad del sistema Se centra en la estructura (Programa) del sistema

2 Las técnicas utilizadas son:

* Partición de equivalencia

* Análisis del valor límite

* Error adivinando

* Condiciones de carrera

* Gráfica de causa-efecto

* Pruebas de sintaxis

* Pruebas de transición de estado

· Matriz gráfica

El probador puede ser no técnico

Ayuda a identificar la vaguedad y contradicción en las especificaciones funcionales

Caja Blanca

Las técnicas utilizadas son:

* Pruebas de Ruta de Base

* Notación del Gráfico de Flujo

* Pruebas de la Estructura de Control

1. Pruebas de estado

2. Pruebas de flujo de datos

* Pruebas de bucle

1. Simple Bucles

2. Bucles Anidados

3. Bucles Concatenados

4. Bucles no estructurados

   El probador debe ser técnico

   Ayuda a identificar los problemas lógicos y de codificación.

"Ambos" se ha dicho anteriormente, y es la respuesta obvia...pero IMO, las pruebas de caja blanca van mucho más allá de las pruebas unitarias de desarrollador (aunque supongo que podría depender de dónde se traza la línea entre blanco y negro). Por ejemplo, el análisis de cobertura de código es un enfoque común de caja blanca, es decir, ejecutar algunos escenarios o pruebas, y examinar los resultados en busca de agujeros en las pruebas. Incluso si las pruebas unitarias tienen 100% cc, la medición de cc en escenarios de usuario comunes puede revelar código que potencialmente puede necesitar aún más prueba.

Otro lugar donde las pruebas de caja blanca ayudan es examinar tipos de datos, constantes y otra información para buscar límites, valores especiales, etc. Por ejemplo, si una aplicación tiene una entrada que toma una entrada numérica, un enfoque solo bb podría requerir que el probador "adivine" qué valores serían buenos para probar, mientras que un enfoque wb puede revelar que todos los valores entre 1-256 se tratan de una manera, mientras que los valores más grandes se tratan de otra manera...y tal vez el número 42 tiene todavía otra ruta de código.

Por lo tanto, para responder a la pregunta original, tanto bb como wb son esenciales para una buena prueba.

En mi experiencia, la mayoría de los desarrolladores migran naturalmente hacia las pruebas de caja blanca. Dado que necesitamos asegurarnos de que el algoritmo subyacente sea "correcto", tendemos a centrarnos más en los aspectos internos. Pero, como se ha señalado, las pruebas de caja blanca y negra son importantes.

Por lo tanto, prefiero que los probadores se centren más en las pruebas de la Caja Negra, para cubrir el hecho de que la mayoría de los desarrolladores realmente no lo hacen, y con frecuencia no son muy buenos en ello.

Eso no quiere decir que los probadores debe mantenerse en la oscuridad sobre cómo funciona el sistema, solo que prefiero que se centren más en el dominio del problema y cómo interactúan los usuarios reales con el sistema, no si la función someMethod(int x) lanzará correctamente una excepción si x es igual a 5.

Es una puerta un poco abierta, pero al final ambos son igual de importantes.

¿Qué es peor?

1. Software que hace lo que tiene que hacer, pero internamente tiene problemas?

2. Software que se supone que funciona si miras las fuentes, pero no lo hace?

Mi respuesta: Ninguno de los dos es totalmente aceptable, pero no se puede demostrar que el software sea 100% libre de errores. Así que vas a tener que hacer algunas concesiones. La opción dos es más notoria directamente a los clientes, así que vas a tener problemas con eso antes. A largo plazo, la opción uno va a ser problemática.

Prueba de la caja Negra: La prueba de la Caja Negra es apenas observación ningún Conocimiento interno de la necesidad o estructura del producto de software. simplemente introduciendo datos válidos e inválidos y esperando el resultado correcto. aquí el probador encuentra el defecto pero no puede encontrar la Ubicación del defecto.prueba de caja negra realizada en todos los niveles de prueba.

Las técnicas de prueba de la caja negra son: 1. Partición de equivalencia 2. Análisis del Valor Límite 3. Cuadro de decisiones 4. Diagrama de Transición de Estados 4. Diagrama de casos de uso

Blanco Prueba de caja: La caja blanca está probando que requiere el conocimiento de la lógica interna y la estructura del producto de software. aquí comprobaremos el bucle, la condición y la rama. aquí encontramos no solo el defecto sino también la ubicación del defecto.

Técnicas de prueba de caja blanca: 1. Cobertura del Estado de Cuenta 2. Cobertura de la Decisión 3. Cobertura de Sucursales 4. Cobertura de Ruta.

• Por lo general, la prueba de caja blanca no es posible para los probadores. Por lo tanto, la única respuesta viable para los probadores es enfatizar el enfoque de caja negra.

• Sin embargo, con la programación orientada a aspectos y la metodología de diseño por contrato, cuando los objetivos de prueba se programan en el código de destino como contratos (visto desde la vista estática de un programa), y / o cuando la lógica temporal de prueba se programa en el código como cortes cruzados( vista dinámica de la lógica de prueba), sería no solo posible, sino también una toma preferida para los probadores. Dicho esto, tendrá que ser una toma de experiencia exigente, los probadores deben ser no solo buenos probadores, sino también buenos programadores o más que buenos programadores.

QA debe centrarse en Black box testing. El objetivo principal de QA es probar lo que hace el sistema (¿cumplen las características los requisitos?), no cómo lo hace.

De todos modos, debería ser difícil para QA hacer pruebas de caja blanca, ya que la mayoría de los chicos de QA no son chicos de tecnología, por lo que generalmente prueban características a través de la interfaz de usuario (como los usuarios).

Un paso más allá, creo que los desarrolladores también deberían centrarse en Pruebas de caja negra. No estoy de acuerdo con esta asociación generalizada entre las pruebas unitarias y prueba de caja blanca, pero puede ser solo una pregunta un vocabulario / escala. En la escala de una prueba unitaria, el Sistema Bajo Prueba es una clase/método que tiene contrato (a través de su firma) y el punto importante es probar lo que hace, no cómo. Por otra parte la prueba de la caja blanca implica que usted sabe cómo el método llenará su contrato, que me parece incompatile con TDD.

En mi humilde opinión, si su SUT es tan complejo que necesita hacer pruebas de caja blanca, generalmente es hora de refactorizar.

¿Qué constituye, "conocimiento interno?"¿Saber que tal y tal algoritmo fue usado para resolver un problema califica o el probador tiene que ver cada línea de código para que sea "interno"?"

Creo que en cualquier caso de prueba, debe haber resultados esperados dados por la especificación utilizada y no determinados por cómo el probador decide interpretar la especificación, ya que esto puede conducir a problemas donde cada uno piensa que tiene razón y culpar al otro por el problema.

• *Prueba de caja negra: Es la prueba a nivel del sistema para verificar la funcionalidad del sistema, para asegurarse de que el sistema realiza todas las funciones para las que fue diseñado, principalmente para descubrir defectos encontrados en el punto de usuario. Es mejor contratar a un probador profesional para black box su sistema, ' coz el desarrollador por lo general las pruebas con una perspectiva de que los códigos que había escrito es bueno y cumple con los requisitos funcionales de los clientes por lo que podría perder un montón de cosas (No me refiero ofender a nadie)
• Whitebox es la primera prueba que se realiza en el SDLC.Esto es para descubrir errores como errores de tiempo de ejecución y errores de compilación Puede ser hecho por los probadores o por el propio Desarrollador, Pero creo que siempre es mejor que la persona que escribió el código lo pruebe.Él los entiende más que otra persona.*

La prueba de caja negra es un método de prueba de software en el que la estructura interna/ diseño/ implementación del elemento que se está probando NO es conocida por el probador. La prueba de caja blanca es un método de prueba de software en el que el probador conoce la estructura/ diseño/ implementación internos del artículo que se está probando.

* Pruebas de caja Negra: Si el código fuente no está disponible, los datos de prueba se basan en la función del software sin tener en cuenta cómo se implementó. - textExamples fuertes de la prueba de la caja negra son: prueba del valor del límite y partición de la equivalencia.

* Pruebas de caja blanca: Si el código fuente del sistema sometido a prueba está disponible, los datos de prueba se basan en la estructura de este código fuente. - Ejemplos de pruebas de caja blanca son: pruebas de ruta y pruebas de flujo de datos.

Simple...Las pruebas de Blackbox también se conocen como pruebas de integración o pruebas de pantalla de humo . Esto se aplica principalmente en un entorno distribuido que se basa en una arquitectura basada en eventos. Prueba un servicio basado en otro servicio para ver todos los escenarios posibles. Aquí no puede pronosticar completamente todos los resultados posibles porque cada componente de la aplicación SOA/Enterprise está destinado a funcionar de forma autónoma. Esto puede denominarse Prueba de alto nivel

Mientras que

Caja Blanca las pruebas se refieren a las pruebas unitarias. donde todos los escenarios esperados y la producción pueden ser efectivamente pronosticados. es decir, Entrada y salida esperada.Esto puede denominarse prueba de bajo nivel

Solo estoy parcialmente de acuerdo con la respuesta mejor valorada para esta pregunta. ¿Qué tipo de prueba dirías que debería ser el énfasis (para los evaluadores/QAs), y por qué?

1. Estoy de acuerdo en que: "Las pruebas de caja negra deben ser el énfasis para testers / QA."
2. Estoy de acuerdo en que las pruebas de caja blanca deben ser el énfasis para desarrolladores, pero no estoy de acuerdo en que la prueba de Caja Blanca es solo una unidad prueba.

Estoy de acuerdo con la definición aquí que establece que el método de prueba de Caja Blanca es aplicable a los siguientes niveles de pruebas de software:

• Pruebas unitarias: Para probar rutas dentro de una unidad
• Pruebas de integración: Para probar rutas entre unidades
• Pruebas del sistema: Para probar rutas entre subsistemas

Aquí están mis 5 centavos:

Como desarrollador, principalmente escribo pruebas para métodos (en una clase) como pruebas de caja blanca, simple porque no quiero que mi prueba se rompa solo porque cambio las obras internas de mi código.

Solo quiero que mis pruebas se rompan si el comportamiento de mi método cambia (por ejemplo, devuelve un resultado diferente al anterior).

Durante los últimos 20 años de desarrollo, simplemente me cansé de hacer hasta el doble de trabajo solo porque mis pruebas unitarias estaban fuertemente vinculadas al código y necesidad de mantener el código de aplicación y el código de prueba.

Creo que hacer código de desacoplamiento (también cuando pruebas de código) es una muy buena práctica.

Otros 5 centavos: Casi nunca uso frameworks de burla, porque cuando lo encuentro necesariamente para burlarme de algo, prefiero desacoplar mi código en su lugar , y sí, en muchos casos, eso es muy posible (especialmente si no está trabajando en código heredado): -)