Pruebas de software: métodos

Existen diferentes métodos que se pueden utilizar para las pruebas de software. Este capítulo describe brevemente los métodos disponibles.

Prueba de caja negra

La técnica de prueba sin tener ningún conocimiento del funcionamiento interior de la aplicación se denomina prueba de caja negra. El evaluador ignora la arquitectura del sistema y no tiene acceso al código fuente. Por lo general, mientras realiza una prueba de caja negra, un probador interactuará con la interfaz de usuario del sistema proporcionando entradas y examinando salidas sin saber cómo y dónde se trabajan las entradas.

La siguiente tabla enumera las ventajas y desventajas de las pruebas de caja negra.

Ventajas	Desventajas
Muy adecuado y eficiente para grandes segmentos de código.	Cobertura limitada, ya que solo se realiza un número seleccionado de escenarios de prueba.
No se requiere acceso con código.	Pruebas ineficientes, debido al hecho de que el evaluador solo tiene conocimientos limitados sobre una aplicación.
Separa claramente la perspectiva del usuario de la perspectiva del desarrollador a través de roles claramente definidos.	Cobertura ciega, ya que el probador no puede apuntar a segmentos de código específicos o áreas propensas a errores.
Un gran número de probadores con habilidades moderadas puede probar la aplicación sin conocimientos de implementación, lenguaje de programación o sistemas operativos.	Los casos de prueba son difíciles de diseñar.

Prueba de caja blanca

Las pruebas de caja blanca son la investigación detallada de la lógica interna y la estructura del código. La prueba de caja blanca también se llamaglass testing o open-box testing. En orden para realizarwhite-box Al probar una aplicación, un evaluador necesita conocer el funcionamiento interno del código.

El probador debe echar un vistazo dentro del código fuente y averiguar qué unidad / fragmento del código se comporta de manera inapropiada.

La siguiente tabla enumera las ventajas y desventajas de las pruebas de caja blanca.

Ventajas	Desventajas
A medida que el evaluador tiene conocimiento del código fuente, resulta muy fácil averiguar qué tipo de datos pueden ayudar a probar la aplicación de manera eficaz.	Debido al hecho de que se necesita un probador calificado para realizar las pruebas de caja blanca, los costos aumentan.
Ayuda a optimizar el código.	A veces es imposible mirar en cada rincón y esquina para descubrir errores ocultos que pueden crear problemas, ya que muchos caminos no se probarán.
Se pueden eliminar líneas adicionales de código que pueden provocar defectos ocultos.	Es difícil mantener las pruebas de caja blanca, ya que requiere herramientas especializadas como analizadores de código y herramientas de depuración.
Debido al conocimiento del probador sobre el código, se alcanza la máxima cobertura durante la escritura del escenario de prueba.

Prueba de caja gris

La prueba de caja gris es una técnica para probar la aplicación con un conocimiento limitado del funcionamiento interno de una aplicación. En las pruebas de software, la frase cuanto más sepa, mejor tiene mucho peso al probar una aplicación.

Dominar el dominio de un sistema siempre le da al evaluador una ventaja sobre alguien con un conocimiento limitado del dominio. A diferencia de las pruebas de caja negra, donde el evaluador solo prueba la interfaz de usuario de la aplicación; en las pruebas de caja gris, el probador tiene acceso a los documentos de diseño y la base de datos. Con este conocimiento, un evaluador puede preparar mejores datos de prueba y escenarios de prueba mientras elabora un plan de prueba.

Ventajas	Desventajas
Ofrece beneficios combinados de pruebas de caja negra y caja blanca siempre que sea posible.	Dado que el acceso al código fuente no está disponible, la capacidad de revisar el código y la cobertura de prueba es limitada.
Los probadores de caja gris no se basan en el código fuente; en su lugar, se basan en la definición de la interfaz y las especificaciones funcionales.	Las pruebas pueden ser redundantes si el diseñador de software ya ha ejecutado un caso de prueba.
Basado en la información limitada disponible, un probador de caja gris puede diseñar escenarios de prueba excelentes, especialmente en torno a protocolos de comunicación y manejo de tipos de datos.	Probar cada flujo de entrada posible no es realista porque tomaría una cantidad de tiempo irrazonable; por lo tanto, muchas rutas de programas no se probarán.
La prueba se realiza desde el punto de vista del usuario y no del diseñador.

Una comparación de métodos de prueba

La siguiente tabla enumera los puntos que diferencian las pruebas de caja negra, las pruebas de caja gris y las pruebas de caja blanca.

Prueba de caja negra	Prueba de caja gris	Prueba de caja blanca
No es necesario conocer el funcionamiento interno de una aplicación.	El evaluador tiene un conocimiento limitado del funcionamiento interno de la aplicación.	Tester tiene pleno conocimiento del funcionamiento interno de la aplicación.
También conocido como prueba de caja cerrada, prueba basada en datos o prueba funcional.	También conocido como prueba translúcida, ya que el probador tiene un conocimiento limitado del interior de la aplicación.	También conocido como prueba de caja transparente, prueba estructural o prueba basada en código.
Realizado por usuarios finales y también por probadores y desarrolladores.	Realizado por usuarios finales y también por probadores y desarrolladores.	Normalmente lo hacen probadores y desarrolladores.
Las pruebas se basan en expectativas externas: se desconoce el comportamiento interno de la aplicación.	Las pruebas se realizan sobre la base de diagramas de flujo de datos y diagramas de bases de datos de alto nivel.	El funcionamiento interno es completamente conocido y el probador puede diseñar los datos de prueba en consecuencia.
Es exhaustivo y el que menos tiempo requiere.	En parte lento y exhaustivo.	El tipo de prueba más exhaustivo y que requiere más tiempo.
No apto para pruebas de algoritmos.	No apto para pruebas de algoritmos.	Adecuado para pruebas de algoritmos.
Esto solo se puede hacer mediante el método de prueba y error.	Los dominios de datos y los límites internos se pueden probar, si se conocen.	Los dominios de datos y los límites internos se pueden probar mejor.