Prueba de caja negra vs caja blanca

https://stackoverflow.com/questions/402161

03-07-2019
|

Pregunta

¿Qué tipo de prueba diría que debería ser el énfasis (para los evaluadores / QA) y por qué?

Un conjunto rápido de definiciones de wikipedia:

Pruebas de caja negra

adopta una perspectiva externa del objeto de prueba para derivar casos de prueba. Estas pruebas pueden ser funcionales o no funcionales, aunque generalmente son funcionales. El diseñador de pruebas selecciona entradas válidas e inválidas y determina la salida correcta. No se conoce la estructura interna del objeto de prueba.

Pruebas de caja blanca

utiliza una perspectiva interna del sistema para diseñar casos de prueba basados ??en la estructura interna. Requiere habilidades de programación para identificar todos los caminos a través del software. El probador elige entradas de casos de prueba para realizar recorridos a través del código y determina las salidas apropiadas. En las pruebas de hardware eléctrico, cada nodo en un circuito puede ser sondado y medido; un ejemplo es la prueba en circuito (ICT).

edit: solo para aclarar un poco más, me doy cuenta de que ambos son importantes, pero generalmente están separados entre dev y QA.

¿Es importante el conocimiento interno para el probador / control de calidad? He escuchado argumentos de que probar con este conocimiento en mente les permite probar mejor los problemas, pero también he escuchado argumentos de que este conocimiento puede distraer las necesidades funcionales y promover la prueba a código " en lugar de a la solución prevista.

Solución

Las pruebas de caja negra deben ser el énfasis de los evaluadores / control de calidad.
Las pruebas de recuadro blanco deberían ser el énfasis para los desarrolladores (es decir, pruebas unitarias).
Las otras personas que respondieron esta pregunta parecían haber interpretado la pregunta como Lo que es más importante, la prueba de caja blanca o la prueba de caja negra . Yo también creo que ambos son importantes, pero es posible que desee revisar este IEEE article que afirma que la prueba de caja blanca es más importante.

Otros consejos

Prueba de caja blanca es igual a Prueba de unidad de software. El desarrollador o un probador de nivel de desarrollo (por ejemplo, otro desarrollador) se asegura de que el código que ha escrito funcione correctamente de acuerdo con los requisitos de nivel detallados antes de integrarlo en el sistema.

Prueba de caja negra es igual a Prueba de integración. El probador asegura que el sistema funciona de acuerdo con los requisitos a nivel funcional.

En mi opinión, ambos enfoques de prueba son igualmente importantes .

Una prueba de unidad 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 del sistema garantizará que todos los módulos de software se comporten correctamente cuando se integren juntos. Una prueba de unidad en la etapa de desarrollo no detectaría estos defectos, ya que los módulos generalmente se desarrollan de forma independiente entre sí.

Black Box

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

2 Las técnicas utilizadas son:

& # 183; Particionamiento de equivalencias

& # 183; Análisis de valor límite

& # 183; Error al adivinar

& # 183; Condiciones de carrera

& # 183; Graficación causa-efecto

& # 183; Pruebas de sintaxis

& # 183; Pruebas de transición de estado

& # 183; Matriz de grafos

El probador puede ser no técnico

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

Caja blanca

Las técnicas utilizadas son:

& # 183; Prueba de ruta de base

& # 183; Notación del gráfico de flujo

& # 183; Pruebas de estructura de control

Prueba de condición
Pruebas de flujo de datos

& # 183; Prueba de bucle

Bucles simples
Bucles anidados
Bucles concatenados
Bucles no estructurados

El probador debe ser técnico

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

El control de calidad debe centrarse en pruebas de caja negra . El objetivo principal del control de calidad es probar lo que hace el sistema (¿cumplen las características con los requisitos?), No cómo lo hace.

De todos modos, debería ser difícil para el control de calidad realizar pruebas de caja blanca, ya que la mayoría de ellos no son expertos en tecnología, por lo que generalmente prueban las 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 recuadro negro . No estoy de acuerdo con esta asociación generalizada entre las pruebas unitarias y las pruebas de la caja blanca, pero puede ser solo una cuestión de vocabulario / escala. En la escala de una prueba de unidad, 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. Además, las pruebas de caja blanca implican que sabes cómo el método cumplirá su contrato, eso me parece incompatible 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.

" Ambos " se ha indicado anteriormente, y es la respuesta obvia ... pero en mi opinión, la prueba de caja blanca va mucho más allá de la prueba de la unidad de desarrollador (aunque supongo que podría depender de dónde dibuje 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, ejecuta algunos escenarios o pruebas y examina los resultados buscando agujeros en las pruebas. Incluso si las pruebas unitarias tienen un 100% de cc, la medición de cc en escenarios de usuario comunes puede revelar código que posiblemente necesite aún más pruebas.

Otro lugar donde las pruebas de recuadro blanco ayudan es examinar los 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 de solo bb podría requerir el probador para "adivinar" a qué valores serían buenos para la prueba, 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 otra ruta de código.

Entonces, 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. Ya 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 evaluadores se centren más en las pruebas de Black Box, para cubrir el hecho de que la mayoría de los desarrolladores realmente no lo hacen, y con frecuencia no son muy buenos en eso.

Eso no quiere decir que los evaluadores deben 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 los usuarios reales interactúan 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 igualmente importantes.

¿Qué es peor?

software que hace lo que debe hacer, pero tiene problemas internos?
software que se supone que funciona si miras las fuentes, pero no?

Mi respuesta: Ninguno de los dos es totalmente aceptable, pero no se puede demostrar que el software esté 100% libre de errores. Entonces tendrás que hacer algunas compensaciones. La opción dos es más directa para los clientes, por lo que tendrá problemas con eso antes. A la larga, la opción uno será problemática.

Prueba de caja negra: la prueba de caja negra es solo una observación, sin necesidad de conocimiento interno o estructura del producto de software. simplemente ingresando datos válidos e inválidos y esperando el resultado correcto. aquí el probador encuentra el defecto pero no puede encontrar la ubicación de la prueba de defect.black box realizada en todos los niveles de prueba.

Las técnicas de prueba de caja negra son: 1. Partición de equivalencia 2. Análisis del valor límite 3. Tabla de decisiones 4. Diagrama de transición del estado 4. Diagrama de caso de uso

Prueba de caja blanca: la caja blanca está probando, 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 de la declaración 2. Cobertura de decisiones 3. Cobertura de sucursal 4. Cobertura de ruta.

Por lo general, las pruebas de caja blanca no son posibles para los evaluadores. Por lo tanto, la única respuesta viable para los evaluadores 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 objetivo como contratos (vistos 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), la prueba de caja blanca no solo sería posible sino también una toma preferida para los probadores. Dicho esto, tendrá que ser una toma exigente de experiencia, los evaluadores deben ser no solo buenos probadores, sino también buenos programadores o más que buenos programadores.

Black Box Testing es un método de prueba de software en el que el probador NO conoce la estructura interna / diseño / implementación del elemento que se está probando. White Box Testing es un método de prueba de software en el que el probador conoce la estructura / diseño / implementación interna del elemento que se está probando.

¿Qué constituye "conocimiento interno"? ¿Saber que tal y cual algoritmo se usó para resolver un problema califica o el comprobador tiene que ver cada línea de código para que sea "interno"? ""

Creo que en cualquier caso de prueba, debería haber resultados esperados dados por la especificación utilizada y no determinados por cómo el evaluador decide interpretar la especificación, ya que esto puede llevar a problemas en los que cada uno piensa que están en lo cierto y culpar al otro por el problema.

* Prueba de recuadro negro: es la prueba a nivel del sistema para verificar la funcionalidad del sistema, para garantizar que el sistema realiza todas las funciones para las que fue diseñado, principalmente para descubrir defectos encontrados en el punto del usuario. Es mejor contratar un probador profesional para poner en caja negra su sistema, porque el desarrollador generalmente prueba con una perspectiva de que los códigos que ha escrito son buenos y cumplen con los requisitos funcionales de los clientes para que pueda perderse muchas cosas (no no significa 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 hacerlo tanto los probadores como el propio desarrollador, pero creo que siempre es mejor que la persona que escribió el el código lo prueba. Él los entiende más que otra persona. *

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 los trabajos internos de mi código.

Solo quiero que se rompan mis pruebas 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 un doble trabajo simplemente porque mis pruebas de unidad estaban fuertemente ligadas al código y necesito mantener tanto el código de aplicación como el de prueba.

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

Otros 5 centavos: casi nunca uso marcos de trabajo burlones, porque cuando me parece necesariamente burlarme de algo prefiero desacoplar mi código, y sí, en muchos casos eso es muy posible (especialmente si no está trabajando en código heredado) ) :-)

* Prueba de caja negra: Si el código fuente no está disponible, los datos de prueba se basan en la función del software, independientemente de cómo se implementó. Los ejemplos de texto fuerte de las pruebas de caja negra son: prueba de valor de límite y partición de equivalencia.

* Prueba de caja blanca: Si el código fuente del sistema bajo prueba está disponible, entonces los datos de prueba se basan en la estructura de este código fuente. -Los ejemplos de pruebas de caja blanca son: pruebas de ruta y pruebas de flujo de datos.

Simple ... La prueba de Blackbox también se conoce como prueba de integración o prueba de pantalla de humo. Esto se aplica principalmente en un entorno distribuido que se basa en la arquitectura dirigida por eventos. Usted 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 debe funcionar de forma autónoma. Esto puede denominarse prueba de alto nivel

mientras

La prueba de caja blanca se refiere a la prueba de unidad. donde todos los escenarios y resultados esperados pueden ser pronosticados efectivamente. es decir, entrada y salida esperada. Esto se puede denominar prueba de bajo nivel

Solo estoy parcialmente de acuerdo con la respuesta más calificada para esta pregunta. ¿Qué tipo de prueba diría que debería ser el énfasis (para probadores / QA) y por qué?

Estoy de acuerdo en que: " Las pruebas de caja negra deben ser el énfasis para probadores / QA. "
Estoy de acuerdo en que las pruebas de caja blanca deberían ser el énfasis para desarrolladores, pero no estoy de acuerdo con que las pruebas de White Box sean solo unidades pruebas.

Estoy de acuerdo con la definición aquí que establece que el método de prueba de White Box es aplicable al siguientes niveles de prueba de software:

Prueba de la unidad: para probar rutas dentro de una unidad
Pruebas de integración: para probar rutas entre unidades
Pruebas del sistema: para probar rutas entre subsistemas

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow