testing - seguridad - Caja negra vs Prueba de caja blanca

pruebas de seguridad de software (15)

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

Un conjunto rápido de definiciones de wikipedia:

Prueba de caja negra

toma 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 prueba selecciona entradas válidas y no válidas y determina la salida correcta. No hay conocimiento de la estructura interna del objeto de prueba.

Prueba de caja blanca

usa una perspectiva interna del sistema para diseñar casos de prueba basados en la estructura interna. Requiere habilidades de programación para identificar todas las rutas a través del software. El probador elige entradas de casos de prueba para hacer trayectos 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 probado y medido; un ejemplo es la prueba en circuito (ICT).

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

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

"Ambos" se ha mencionado anteriormente, y es la respuesta obvia ... pero la OMI, la prueba de caja blanca va más allá de las pruebas de la unidad 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 de caja blanca común, es decir, ejecutar algunos escenarios o pruebas, y examinar los resultados en busca de agujeros en las pruebas. Incluso si las pruebas unitarias tienen un 100% de cc, la medición de cc en escenarios de usuarios comunes puede revelar código que posiblemente necesite más pruebas.

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 de solo bb podría requerir que el probador "adivinar" a qué valores sería bueno para probar, mientras que un enfoque de 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 .

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

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

Creo que en cualquier caso de prueba, debería haber resultados esperados dados por la especificación utilizada y no determinados por la forma en que el evaluador decide interpretar la especificación, ya que esto puede generar problemas donde cada uno piensa que es correcto y culpar al otro por el problema.

* Prueba de Black-Box: si el código fuente no está disponible, los datos de prueba se basan en la función del software sin importar cómo se implementó. -strong textExamples de black-box testing son: pruebas de valor límite y partición de equivalencia.

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

Black Box Testing es un método de prueba de software en el que el probador NO conoce la estructura / diseño / implementación internos 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 internos del elemento que se está probando.

Black Box Testing: Black Box testing es solo observación sin necesidad Conocimiento interno o estructura del producto de software. simplemente poniendo entrada de datos válida y no válida y esperando el resultado correcto. aquí el probador encuentra el defecto pero no puede encontrar la ubicación de la prueba 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 de valor de frontera 3. Tabla de decisión 4. Diagrama de transición de 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í vamos a verificar el lazo, la condición y la ramificación. aquí encontramos no solo el defecto sino también la ubicación del defecto.

Técnicas de prueba de la caja blanca: 1. Cobertura de la declaración 2. Cobertura de la decisión 3. Cobertura de la sucursal 4. Cobertura de la ruta.

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

De todos modos, debería ser difícil para QA realizar pruebas de caja blanca, ya que la mayoría de los tipos de QA no son técnicos, por lo que suelen probar características a través de la IU (como usuarios).

Un paso más allá, creo que los desarrolladores también deberían enfocarse en las pruebas de caja negra . No estoy de acuerdo con esta asociación generalizada entre las pruebas unitarias y las pruebas 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 qué hace, no cómo. Además, las pruebas de caja blanca implican que usted sabe cómo el método cumplirá con su contrato, lo cual 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.

En mi experiencia, la mayoría de los desarrolladores migran naturalmente hacia las pruebas de caja blanca. Como necesitamos asegurarnos de que el algoritmo subyacente sea "correcto", tendemos a enfocarnos más en las partes internas. 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 no lo hacen realmente, y con frecuencia no son muy buenos en eso.

Eso no quiere decir que los evaluadores deberían mantenerse a oscuras 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 un poco abierto, pero al final ambos son igualmente importantes.

¿Que es peor?

software que hace lo que necesita hacer, pero internamente tiene problemas?
software que se supone que funciona si mira las fuentes, pero no?

Mi respuesta: ninguno de los dos es totalmente aceptable, pero no se puede probar que el software sea 100% libre de errores. Entonces vas a tener que hacer algunas concesiones. La opción dos es más directamente notificable a los clientes, por lo que tendrá problemas con eso más pronto. En el largo plazo, la opción uno será problemática.

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

mientras

Las pruebas de caja blanca se refieren a pruebas unitarias. donde todos los escenarios y resultados esperados se pueden pronosticar efectivamente. es decir, entrada y salida esperada. Esto se puede conocer como prueba de bajo nivel.

Solo estoy parcialmente de acuerdo con la respuesta mejor 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 deberían ser el énfasis para los evaluadores / QA".
Estoy de acuerdo en que las pruebas de caja blanca deberían ser el énfasis para los desarrolladores, pero no estoy de acuerdo con que las pruebas de Caja blanca sean solo pruebas unitarias.

Estoy de acuerdo con la definición here que establece que el método White Box Testing es aplicable a los siguientes niveles de pruebas de software:

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

White Box Testing es igual a Software Unit Test. El desarrollador o un probador de nivel de desarrollo (por ejemplo, otro desarrollador) se asegura de que el código que ha escrito esté funcionando correctamente de acuerdo con los requisitos de nivel detallados antes de integrarlo en el sistema.

Black Box Testing es igual a Pruebas de Integración. El comprobador asegura que el sistema funciona de acuerdo con los requisitos en un nivel funcional.

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

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

Caja negra

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

2 Técnicas utilizadas son:

· Partición de equivalencia

· Análisis de valores de frontera

· Error al adivinar

· Condiciones de carrera

· Grafica de causa-efecto

· Prueba de sintaxis

· Prueba de transición de estado

· Matriz de gráficos

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:

· Prueba de ruta básica

· Notación de flujo de gráficos

· Control de estructura de prueba

Prueba de condición
Prueba de flujo de datos

· 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.

* Prueba de caja negra: es la prueba a nivel del sistema para verificar la funcionalidad del sistema, para garantizar que el sistema realice todas las funciones para las que fue diseñado, principalmente para descubrir defectos encontrados en el punto del usuario. Es mejor contratar a un probador profesional para que bloquee su sistema, porque el desarrollador usualmente lo prueba con la perspectiva de que los códigos que ha escrito son buenos y cumple con los requisitos funcionales de los clientes para poder perder un montón de cosas (yo no no ofender a nadie)
Whitebox es la primera prueba que se realiza en el SDLC. Esto es para descubrir fallas como errores de tiempo de ejecución y errores de compilación. Puede ser hecho por probadores o por el propio desarrollador. Pero creo que siempre es mejor que la persona que lo escribió lo pruebe . Él los entiende más que otra persona. *

Las pruebas de caja negra deberían ser el énfasis para probadores / QA.
Las pruebas de caja blanca 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 ¿Qué es más importante? Prueba de caja blanca o prueba de caja negra . Yo también creo que ambos son importantes, pero es posible que desee consultar este artículo de IEEE que afirma que las pruebas de caja blanca son más importantes.

Por lo general, la prueba de caja blanca no es posible 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 transversales (vista dinámica de la lógica de prueba), las pruebas de caja blanca serían no solo posibles sino también una opción preferida para los evaluadores. Dado que dicho esto, será necesario tomar una decisión que requiera mucha experiencia, los probadores deben ser no solo buenos evaluadores, sino también buenos programadores o más que buenos programadores.