Prueba de caja negra
Black Box Testing es un método de prueba de software en el que se prueban las funcionalidades de las aplicaciones de software sin tener conocimiento de la estructura del código interno, los detalles de implementación y las rutas internas. Black Box Testing se centra principalmente en la entrada y salida de aplicaciones de software y se basa completamente en los requisitos y especificaciones del software. También se conoce como prueba de comportamiento.
La Black-Box anterior puede ser cualquier sistema de software que desee probar. Por ejemplo, un sistema operativo como Windows, un sitio web como Google, una base de datos como Oracle o incluso su propia aplicación personalizada. En Black Box Testing, puede probar estas aplicaciones con solo centrarse en las entradas y salidas sin conocer su implementación de código interno. Considere el siguiente video tutorial-
Haga clic aquí si el video no es accesible
Cómo hacer pruebas de BlackBox
A continuación se muestran los pasos genéricos que se siguen para realizar cualquier tipo de Black Box Testing.
- Inicialmente, se examinan los requisitos y especificaciones del sistema.
- El probador elige entradas válidas (escenario de prueba positivo) para verificar si SUT las procesa correctamente. Además, se eligen algunas entradas no válidas (escenario de prueba negativo) para verificar que el SUT puede detectarlas.
- El probador determina las salidas esperadas para todas esas entradas.
- El probador de software construye casos de prueba con las entradas seleccionadas.
- Se ejecutan los casos de prueba.
- El probador de software compara las salidas reales con las salidas esperadas.
- Los defectos, si los hay, se reparan y se vuelven a probar.
Tipos de pruebas de caja negra
Hay muchos tipos de pruebas de caja negra, pero las siguientes son las más importantes:
- Prueba funcional : este tipo de prueba de caja negra está relacionado con los requisitos funcionales de un sistema; lo hacen probadores de software.
- Prueba no funcional : este tipo de prueba de caja negra no está relacionada con la prueba de una funcionalidad específica, sino con requisitos no funcionales como el rendimiento, la escalabilidad y la usabilidad.
- Prueba de regresión: la prueba de regresión se realiza después de las correcciones del código, las actualizaciones o cualquier otro mantenimiento del sistema para verificar que el nuevo código no haya afectado el código existente.
Herramientas utilizadas para las pruebas de caja negra:
Las herramientas utilizadas para las pruebas de caja negra dependen en gran medida del tipo de prueba de caja negra que esté realizando.
- Para las pruebas funcionales / de regresión que puede utilizar: QTP, Selenium
- Para pruebas no funcionales, puede utilizar: LoadRunner, Jmeter
Técnicas de prueba de caja negra
A continuación se muestran las estrategias de prueba más destacadas entre las muchas que se utilizan en las pruebas de caja negra
- Prueba de clase de equivalencia: se utiliza para minimizar el número de posibles casos de prueba a un nivel óptimo mientras mantiene una cobertura de prueba razonable.
- Prueba de valor límite : la prueba de valor límite se centra en los valores en los límites. Esta técnica determina si un cierto rango de valores son aceptables por el sistema o no. Es muy útil para reducir el número de casos de prueba. Es más adecuado para los sistemas donde una entrada está dentro de ciertos rangos.
- Prueba de la tabla de decisiones : una tabla de decisiones coloca las causas y sus efectos en una matriz. Hay una combinación única en cada columna.
Comparación de las pruebas de caja negra y caja blanca:
| Prueba de caja negra | Prueba de caja blanca |
|---|---|
| El enfoque principal de las pruebas de caja negra es la validación de sus requisitos funcionales. | Las pruebas de caja blanca (pruebas unitarias) validan la estructura interna y el funcionamiento de su código de software |
| Las pruebas de caja negra brindan abstracción del código y se enfocan en el esfuerzo de prueba del comportamiento del sistema de software. | Para realizar pruebas de caja blanca, el conocimiento del lenguaje de programación subyacente es esencial. Los sistemas de software actuales utilizan una variedad de lenguajes y tecnologías de programación y no es posible conocerlos todos. |
| La prueba de caja negra facilita la comunicación de prueba entre módulos | La prueba de caja blanca no facilita la comunicación de prueba entre módulos |
Ciclo de vida de desarrollo de software y pruebas de caja negra (SDLC)
Las pruebas de caja negra tienen su propio ciclo de vida llamado Ciclo de vida de pruebas de software (STLC) y son relativas a cada etapa del Ciclo de vida de desarrollo de software de la Ingeniería de software.
- Requisito : esta es la etapa inicial de SDLC y en esta etapa, se recopila un requisito. Los probadores de software también participan en esta etapa.
- Análisis y planificación de pruebas: se determinan los tipos de pruebas aplicables al proyecto. Se crea un Plan de Prueba que determina los posibles riesgos del proyecto y su mitigación.
- Diseño : en esta etapa, los casos de prueba / scripts se crean sobre la base de los documentos de requisitos de software
- Ejecución de la prueba : en esta etapa se ejecutan los casos de prueba preparados. Los errores, si los hay, se corrigen y se vuelven a probar.