¿Cuáles son las técnicas de prueba de caja blanca, negra y gris?

Pruebe enfoques o métodos , es decir, formas o medios sobre cómo podemos probar la aplicación bajo prueba (AUT) de manera efectiva. ¿Comenzará a probar en paralelo con el desarrollo o solo después de que se complete el desarrollo? ¿Qué pasa con las pruebas a nivel de código? es decir, revisiones de código para garantizar que se sigan las mejores prácticas. ¿Serán solo revisiones o realmente ejecutará la aplicación para identificar defectos? ¿Qué tal utilizar alguna herramienta de automatización para facilitar el proceso? ¿O será híbrido? Como habrás adivinado, hay varios enfoques o métodos para probar una aplicación. En general, estos se dividen como se explica en este artículo.

Enfoque preventivo

” Prevenir es mejor que curar “, ¡Sí! Lo mismo se aplica a las pruebas de software. Las pruebas están diseñadas en una etapa temprana, es decir, encontrar infinitas formas de probar y romper su software antes de que salga a producción. Identifique o pronostique los riesgos temprano y planifique en consecuencia. Ser proactivo siempre paga: puede evitar ciertos tipos de defectos antes de que comience la ejecución real de la prueba.

Enfoque reactivo

Sensible – como en las pruebas se diseñan después de que se completa el desarrollo de software. Reacciona cuando se produce el problema (defecto). En otras palabras, trabaja más noches y fines de semana 🙂 podría resultar en una reevaluación del plan de prueba o actividades de prueba. Es costoso y se basa en una mentalidad de fracaso. Es como esperar hasta que hayas perdido el juego para estudiar cómo te derrotó tu oponente durante el juego ( reactivo ) en lugar de explorar a tu oponente mucho antes del juego, aprender sus fortalezas y debilidades y estar preparado para ganar el juego antes de que sea jugado ( preventivo ).

Prueba de caja negra (funcional)

¿Puedes ver lo que hay dentro de una caja negra cerrada? No, verdad? Del mismo modo , el método de caja negra trata el AUT como una caja negra (sin conocimiento de su estructura interna). Resultado: no nos preocupa cómo se mantiene / cambia la estructura interna de la aplicación hasta que la funcionalidad externa funciona como se espera (según los requisitos). Saber qué hace la aplicación es más importante que saber cómo lo hace. Este es el método de prueba más utilizado para las pruebas de Sistema y Aceptación, ya que no requiere profesionales con conocimientos de codificación y también proporciona una perspectiva externa del AUT (como usuario final que no tiene conocimiento del código real).

Por ejemplo , solo nos preocupa si el usuario puede ver televisión, cambiar canales y volumen, etc.

Prueba de caja blanca (estructural)

Es obvio, simplemente invierta el enfoque. Como se trata de un recuadro blanco >> podemos ver lo que contiene, es decir, la estructura interna, y usar ese conocimiento para expandir la cobertura para probar cada flujo posible a nivel de código. Por ejemplo: cobertura de estado de cuenta, cobertura de sucursal o cobertura de ruta . Requiere habilidades de programación y generalmente se prefiere solo para los niveles de prueba de Unidad e Integración. Puede llamarlo por diferentes nombres: Clear-box, Glass-box o Transparent-box hasta donde pueda ver el contenido interno de la caja :-).

Por ejemplo, nos preocupa si el circuito interno del televisor está diseñado correctamente.

Prueba de caja gris

Como habrás adivinado, un enfoque híbrido , es decir, aprovechando la fuerza de ambos, es la combinación de pruebas de caja blanca y caja negra. No está completo pero el probador aún tiene poco conocimiento sobre la estructura interna del AUT.

Pruebas estáticas (verificación)

Estático como en inmóvil, el código no se ejecuta. Más bien, el código, los requisitos, el diseño y otros documentos se revisan manualmente para encontrar errores (como fallas de código o código potencialmente malicioso) antes de que los casos de prueba se ejecuten realmente para verificar la funcionalidad. El beneficio: ¡ahorra esfuerzo al identificar errores antes! Existen diferentes técnicas aceptadas por la industria para la revisión, tales como revisiones informales, revisiones técnicas, recorridos, inspección y revisiones de códigos .

Pruebas dinámicas (validación)

Dinámico como en activo: el código se ejecuta. ¿Cómo? Al ejercitar los diferentes flujos funcionales o no funcionales del AUT en un entorno de tiempo de ejecución desde la interfaz de usuario (por ejemplo, página web). El objetivo: confirmar que el AUT está trabajando de acuerdo con los requisitos del cliente. Las pruebas dinámicas se realizan en todos los niveles de prueba y pueden ser pruebas de caja negra o caja blanca.

Nota : tanto las pruebas estáticas como las dinámicas se configuran para descubrir vulnerabilidades y errores de codificación dentro de AUT utilizando diferentes métodos.

Prueba manual

Espero que esto se explique por sí mismo. No se utilizan herramientas de automatización como Selenium o HPE UFT para probar el AUT. En cambio, los probadores diseñan los casos de prueba diseñados manualmente, es decir, verifican manualmente diferentes flujos funcionales / no funcionales. Se requiere conocimiento de negocios, dominio y aplicación para probar con éxito una aplicación. La ventaja : como no está programado, un probador puede seguir también pruebas ad-hoc mientras realiza la ejecución de la prueba (lo que resulta en más defectos :-)).

Pruebas automatizadas

¿No sería genial si la computadora puede ejecutar las pruebas en una aplicación por sí sola? ¡Sí! Software-testing-Software testing La prueba de automatización se refiere a un método de prueba en el que se utilizan herramientas como Selenium, UFT, JMeter, LoadRunner , etc. para escribir (o grabar y reproducir) los casos de prueba que luego puede ejecutar la computadora en en cualquier momento. La ventaja : por qué desperdiciar los esfuerzos manuales en pruebas que se repiten con frecuencia (es decir, pruebas de regresión). Además, las pruebas automatizadas se pueden ejecutar en diferentes máquinas con diferentes combinaciones de plataformas de sistema operativo, al mismo tiempo. La trampa : requiere habilidades de programación

Nota : La mayoría de los proyectos tendrán un enfoque híbrido utilizando pruebas manuales para pruebas funcionales y automatización para pruebas de regresión. De hecho, ambas técnicas de prueba son 100% necesarias y se complementan entre sí de múltiples maneras. Aunque las pruebas de automatización no pueden reemplazar a las pruebas manuales, el enfoque ahora se está desplazando hacia profesionales con experiencia en automatización manual +.

Como habrás adivinado, hay varios factores involucrados antes de decidir el método de prueba : tipo de aplicación, experiencia en recursos, limitaciones de presupuesto y tiempo, expectativas del cliente, riesgos del proyecto, etc.

Espero que tengas una idea justa sobre los diferentes enfoques / métodos de prueba .

La prueba de caja blanca no es más que probar las partes internas en la base de código de su software. La Prueba de la Unidad de Escritura para su base de código es un ejemplo perfecto y, por lo general, será realizada por su desarrollador. Escribir es muy barato y tiene muchas posibilidades de descubrir los defectos lo antes posible.

La caja gris es solo una mezcla de blanco y negro. Aquí estará expuesto a pequeños / más detalles de la base del código interno, la arquitectura, la tecnología del software y la otra mitad podría estar oculta. Por lo tanto, es posible que tengamos que crear un simulacro o código auxiliar para replicar el comportamiento oculto de las partes internas y luego probarlo o escribir una prueba automatizada para eso. Escribir pruebas de integración con la ayuda de simulacros y trozos son el ejemplo perfecto de las pruebas de caja gris en las que estará expuesto solo a código interno / código limitado de su software.

La prueba de caja negra es una técnica que se utiliza para probar el sistema en su conjunto, sin tener ningún conocimiento sobre el código, la arquitectura, las tecnologías y otros detalles. Por lo general, imitaremos las acciones / actividades de los Usuarios finales aquí. Hacer pruebas de sistema o escribir pruebas automatizadas utilizando Selenium para imitar las acciones de los usuarios finales en un navegador será un ejemplo perfecto para las técnicas de prueba de caja negra. Esto es muy costoso de escribir y los defectos identificados en esta fase también son un poco caros.

Prueba de caja blanca:

Se ocupa principalmente de la prueba de la lógica interna del código. Por lo tanto, uno debe tener un buen conocimiento de la codificación y la lógica. Necesita que el probador investigue el código y descubra qué unidad / declaración / fragmento del código no funciona correctamente.

Prueba de caja negra:

Aquí el probador prueba el software sin el conocimiento del funcionamiento interno o la lógica del código. Los datos se ingresan en la aplicación y el resultado se compara con los resultados esperados; lo que el programa hace con los datos de entrada o cómo llega el programa a los datos de salida no es una preocupación para el probador que realiza pruebas de caja negra.

Prueba de caja gris:

Es la combinación de Blackbox y pruebas de caja blanca. Aquí el probador tiene información limitada sobre la funcionalidad interna del sistema.

Te gustará este http://testingeducation.org/BBST …

La prueba de caja gris es una combinación de pruebas de caja negra y caja blanca.

Prueba de caja gris = Caja blanca + Prueba de caja negra.

También puede verificar la diferencia entre tres de ellos en White Box vs Gray Box vs Black Box Testing