Descripción general de las pruebas de caja negra
Black Box Testing es un método de prueba de software en el que el probador desconoce la estructura interna o el diseño o la implementación del elemento que debe probarse.
¿Qué son las pruebas de software?
La prueba de software es el procedimiento de evaluar un sistema con la intención de encontrar errores. Se realiza para verificar si el sistema cumple con los requisitos especificados. Las pruebas miden la calidad general del sistema en términos de su corrección, integridad, usabilidad, rendimiento y otros atributos funcionales y no funcionales.
La prueba de caja negra es una técnica de prueba de software que se centra en el análisis de la funcionalidad del software, en comparación con los mecanismos internos del sistema. Las pruebas de caja negra se desarrollaron como un método para analizar los requisitos del cliente, las especificaciones y las estrategias de diseño de alto nivel. Un probador de software de caja negra seleccionaría un conjunto de entrada válido e inválido y condiciones de ejecución de código y verificaría las respuestas de salida válidas. La prueba de caja negra también se conoce como prueba funcional o prueba de caja cerrada.
Por ejemplo, un motor de búsqueda de una aplicación. En un motor de búsqueda, un usuario ingresaría texto en la barra de búsqueda del navegador. El motor de búsqueda luego localizaría y recuperaría la salida de datos de usuario relacionada. Lo que sucede detrás de escena es desconocido para el usuario. Por lo tanto, la implementación interna no le comprende.
Las ventajas de las pruebas de caja negra incluyen:
- Simplicidad: facilita la prueba de diseños de alto nivel y aplicaciones complejas
- Conserva los recursos: los evaluadores se centran en la funcionalidad del software.
- Casos de prueba: centrándose en la funcionalidad del software para facilitar el desarrollo rápido de casos de prueba.
- Proporciona flexibilidad: no se requieren conocimientos de programación específicos.
Un ejemplo
El probador probaría las páginas web, es decir, a través de clics y pulsaciones de teclas utilizando un navegador al proporcionar entradas y sin el conocimiento de las estructuras internas, verificando así las salidas contra los resultados esperados.
Herramientas utilizadas para pruebas de caja negra
Las herramientas de prueba de caja negra dependen básicamente del tipo de prueba de caja negra que esté implementando.
- Las pruebas funcionales / de regresión se pueden hacer a través de QTP o Selenium
- Las pruebas no funcionales se pueden hacer a través de LoadRunner o Jmeter.
Niveles
En Black Box Testing, los siguientes niveles son para pruebas de software:
- Pruebas de integración
- Prueba de sistema
- Test de aceptación
A medida que el nivel es más alto, la caja sería más grande y más compleja y también entra en juego una mayor cantidad de pruebas de caja negra.
Definición de prueba de caja negra
La prueba de caja negra se puede definir como una técnica de prueba en la que se prueba la funcionalidad de la Aplicación bajo prueba (AUT), pero se pasa por alto la estructura del código interno, los detalles de implementación y cualquier conocimiento de las rutas internas del software.
Comprender las pruebas de caja negra
Las pruebas de caja negra se refieren a todas las especificaciones y requisitos de software. Black Box Testing solo se enfoca en las entradas y salidas del sistema de software y no molesta en absoluto con respecto al conocimiento interno del software.
¿Cómo hace Black Box Testing que el trabajo sea tan fácil?
Existe el Ciclo de Vida de Pruebas de Software, es decir, STLC, que es de prueba de caja negra, que es relativo a cada etapa del Ciclo de Vida de Desarrollo de Software.
- En la etapa inicial o primera de STLC, se recopilan los requisitos del producto. Esto se conoce como fase de recopilación de requisitos.
- La fase que sigue es la fase de Planificación de prueba y Análisis de prueba. Los entregables de esta fase generalmente son tipos de pruebas que se realizarán según el proyecto y un plan de prueba para determinar los riesgos y la mitigación de estos riesgos.
- La tercera fase es la fase de diseño en la que los casos de prueba, los scripts de prueba se preparan con la ayuda de los documentos de requisitos de software o el documento de requisitos comerciales.
- La última etapa se conoce como la fase de ejecución de prueba. Como su nombre lo indica, en esta etapa se ejecutan todos los casos de prueba o scripts. Todos los errores encontrados se informan, corrigen y vuelven a probar.
¿Qué puedes hacer con Black Box Testing?
A continuación se explican algunas de las principales estrategias de prueba utilizadas en Black Box Testing:
- Prueba de clase de equivalencia
- Prueba de valor límite
- Prueba de tabla de decisiones
- Prueba de causa y efecto
- Prueba basada en requisitos
- Pruebas de compatibilidad
Prueba de clase de equivalencia
Se prefiere este tipo de prueba, ya que ayuda a minimizar los casos de prueba a un nivel en el que las posibilidades de cobertura de requisitos sean óptimas.
Esto se hace en los siguientes dos pasos:
1. Identificación y partición en clases de equivalencia: Al principio, los datos de entrada se dividen en un mínimo de dos conjuntos: el primer conjunto contiene una lista de valores de entrada válidos y el segundo conjunto contiene la lista de valores de entrada no válidos. Por ejemplo, si hay un cuadro de edad que puede contener la edad en el rango de 20-40, los valores de entrada válidos pueden ser 21, 25, 30, 39, etc. y los valores de entrada no válidos pueden ser cualquier valor menor que 20 o mayor que 40 como 10, 15, 45, 55, etc.
2. Creación de casos de prueba : se asigna un número de identificación único a cada clase de entrada válida y clase de entrada no válida, y luego los casos de prueba se escriben con la intención de cubrir los dos conjuntos de clases de entrada.
Prueba de valor límite
La prueba del valor límite básicamente se centra en los valores límite. Evalúa si un cierto rango de valores sería aceptable o no por el sistema. La prueba de valor límite es útil para reducir / minimizar el número de casos de prueba. La prueba de valor límite es más adecuada para los sistemas donde la entrada se encuentra dentro de ciertos rangos.
Prueba de tabla de decisiones
Una tabla de decisiones demuestra las causas y sus efectos simultáneos en forma de matriz. En la prueba de la tabla de decisiones existe una combinación única en cada columna.
Gráfica de causa-efecto
Las gráficas de causa-efecto desarrollan una relación entre las causas (entradas lógicas) con el efecto correspondiente (Acciones). Se representan con la ayuda de gráficos booleanos. Los pasos a seguir son los siguientes:
- Identificación de entradas y salidas.
- Desarrollo de gráfico causa-efecto.
- Transformación del gráfico en la tabla de decisiones.
- Conversión de las reglas de la tabla de decisiones en casos de prueba.
Prueba basada en requisitos
Este tipo de prueba incluye verificar si los requisitos mencionados en el SRS o la Especificación de requisitos de software son válidos o no.
Pruebas de compatibilidad
Para ofrecer funcionalidad, tanto los productos como la infraestructura dependen del resultado de las ejecuciones de casos de prueba. Independientemente de los cambios realizados en los parámetros de infraestructura, todavía se espera que el producto funcione correctamente. Algunos de los parámetros que generalmente afectan la compatibilidad del software se enumeran a continuación:
- Procesadores Pentium 3 o Pentium 4 y la cantidad de procesadores utilizados
- Arquitectura de 32 bits o 64 bits
- Servidores de bases de datos o cualquier otro componente de fondo
- Tipo de sistema operativo (Windows, Linux, etc.).
Trabajando con pruebas de caja negra
Los siguientes son los pasos básicos necesarios para realizar Black Box Testing.
- En primer lugar, se tratan las especificaciones y requisitos del sistema.
- En segundo lugar, el probador elegiría entradas lógicas, es decir, escenarios de prueba positivos para verificar si SUT los ha procesado correctamente o no. Además, las entradas inválidas también, es decir, el escenario de prueba negativo también se elige para verificar que el SUT pueda detectarlas.
- En tercer lugar, los evaluadores determinarían las salidas esperadas para todas las entradas válidas.
- Cuarto, el probador de software crea casos de prueba con las entradas seleccionadas y válidas.
- En quinto lugar, se ejecutan los casos de prueba creados.
- En sexto lugar, los probadores de software distinguen entre las salidas reales con las salidas esperadas y verifican si son las mismas.
- Por último, si se encuentran, se reparan y se vuelven a probar.
Ventajas
- Las pruebas de recuadro negro siempre se ejecutan desde el punto de vista del usuario, ya que ayudaría a exponer las discrepancias significativamente.
- Los probadores de caja negra tampoco necesitan conocer ningún lenguaje de programación.
- Los probadores de caja negra no necesitan saber cómo se ha implementado el software.
- Los probadores diseñan los casos de prueba relacionados con la caja negra tan pronto como las especificaciones estén en la etapa completa.
Desventajas
- Dado que no se necesitan conocimientos técnicos o de programación, puede haber instancias para ignorar todas las condiciones válidas y posibles del escenario que debe probarse.
- Hay posibilidades de menos pruebas e ignorancia de todas y cada una de las entradas posibles y sus pruebas de salida debido a limitaciones de tiempo (tiempo estipulado).
- La cobertura de prueba completa y terminada a menudo no es posible para proyectos complejos y grandes.
¿Por qué deberíamos usar Black Box Testing?
Las herramientas de prueba de caja negra son básicamente grabaciones y reproducción. Estas herramientas registran los casos de prueba en forma de secuencias de comandos como TSL, JavaScript, secuencia de comandos VB, etc. Todas estas herramientas se utilizan básicamente para pruebas de regresión con el fin de verificar si la nueva compilación proporcionada tiene algún defecto en la funcionalidad de la aplicación que ya funciona bien. .
Alcance
Los tipos destacados y más importantes de Black Box Testing son los siguientes:
- Pruebas funcionales: este tipo de prueba de caja negra tiene que ver con los requisitos funcionales del sistema y es ejecutado por probadores de software.
- Pruebas no funcionales: este tipo de prueba de caja negra no se refiere a la prueba de la funcionalidad particular, sino a los requisitos no funcionales, como el rendimiento, la usabilidad, la escalabilidad y mucho más.
- Pruebas de regresión: las pruebas de regresión se ejecutan después de corregir un código, cualquier actualización de código o cualquier otro mantenimiento del sistema se realiza para verificar si el nuevo código no ha afectado la funcionalidad existente.
Las diferencias
Black Box Testing es la técnica de prueba de software en la que el probador desconoce la estructura interna o el diseño o la implementación del producto que se está probando.
White Box Testing es una técnica de prueba de software en la que un probador conoce la estructura interna o el diseño o la implementación del producto que se está probando.
| Prueba de caja negra | Prueba de caja blanca |
| La prueba de caja negra es en la que se desconoce la estructura interna o el programa o el código. | La prueba de caja blanca es donde el probador tiene conocimiento sobre la estructura interna del software |
| Generalmente lo realizan probadores de software. | Generalmente lo realizan los desarrolladores de software. |
| Aquí, no se requiere absolutamente ningún conocimiento de implementación. | Aquí, se requiere conocimiento de implementación. |
| También se le puede llamar prueba de software externa / externa. | También se puede llamar como prueba de software interno / interno. |
| La prueba de caja negra es la prueba funcional del software. | La prueba de caja blanca es la prueba estructural del software. |
| Esta prueba puede iniciarse sobre la base del documento de especificaciones de requisitos. | Este tipo de prueba de software se inicia después de un documento de diseño detallado. |
| Aquí no se requiere conocimiento del lenguaje de programación. | Aquí es obligatorio tener conocimiento de al menos un lenguaje de programación. |
| Es básicamente una prueba de comportamiento del software. | Es la prueba lógica básica del software. |
| Se aplica principalmente a los niveles más altos de prueba. | Se aplica principalmente a los niveles más bajos de prueba. |
| También se llama prueba de comportamiento. | También se llama prueba de caja transparente o de vidrio. |
| Las pruebas de caja negra requieren menos tiempo que las pruebas de caja blanca. | Las pruebas de caja blanca requieren más tiempo que las pruebas de caja negra. |
| La prueba de caja negra no es apropiada para la prueba de algoritmos. | La prueba de caja blanca es apropiada para la prueba de algoritmos. |
| Se puede lograr mediante métodos de prueba y error. | Los límites internos o internos de los datos junto con su dominio se pueden probar a fondo. |
| Por ejemplo: buscar algo en Google con la ayuda de palabras clave | Por ejemplo: Usar entradas para verificar y verificar los bucles. |
Tipos
| Tipos
|
Conclusión:
Todos los temas discutidos son temas básicos y avanzados relacionados con las pruebas de caja negra y la esencia de todas sus técnicas y métodos.
Dado que es casi imposible probar todos y cada uno junto con la participación humana y eso también con una precisión del 100 por ciento, pero si los métodos ya especificados se usan de manera muy efectiva, sin dudas, mejorará la calidad del sistema. Por lo tanto, para finalizar, las pruebas de caja negra son un método muy efectivo para identificar los defectos y verificar la funcionalidad del sistema.
Artículos recomendados
Esta ha sido una guía para Black Box Testing. Aquí discutimos cómo se realiza Black Box Testing con la ayuda de ejemplos y diferentes técnicas de Black Box Testing con herramientas. También puede consultar nuestros otros artículos sugeridos para obtener más información:
- Prueba de caja blanca
- Prueba de preguntas de la entrevista
- ¿Qué es el hipervisor?
- Preguntas de la entrevista de prueba del juego