Pruebas de caja blanca (también conocida como la prueba clara caja , la prueba de caja de vidrio , pruebas de caja transparente , y pruebas estructurales ) es un método de pruebas de software que las estructuras pruebas internas o funcionamiento de una aplicación, en contraposición a su funcionalidad (es decir, negro-box pruebas ). En las pruebas de caja blanca, se utiliza una perspectiva interna del sistema, así como habilidades de programación, para diseñar casos de prueba. El probador elige entradas para ejercitar rutas a través del código y determinar las salidas esperadas. Esto es análogo a probar nodos en un circuito, por ejemplo , pruebas en circuito (ICT). Las pruebas de caja blanca se pueden aplicar en la unidad ,Integración y niveles de sistema del proceso de prueba de software. Aunque los probadores tradicionales tendían a pensar que las pruebas de caja blanca se realizaban a nivel de unidad, en la actualidad se utilizan para la integración y las pruebas de sistemas con más frecuencia. Puede probar rutas dentro de una unidad, rutas entre unidades durante la integración y entre subsistemas durante una prueba a nivel de sistema. Aunque este método de diseño de prueba puede descubrir muchos errores o problemas, tiene el potencial de pasar por alto partes no implementadas de la especificación o requisitos faltantes. Cuando las pruebas de caja blanca están impulsadas por el diseño, [1] es decir, impulsadas exclusivamente por especificaciones acordadas de cómo se requiere que se comporte cada componente del software (como en los procesos DO-178C e ISO 26262 ), las técnicas de prueba de caja blanca pueden lograr evaluación de requisitos no implementados o faltantes.
Las técnicas de diseño de prueba de caja blanca incluyen los siguientes criterios de cobertura de código :
- Prueba de flujo de control
- Prueba de flujo de datos
- Prueba de rama
- Cobertura de estados de cuenta
- Cobertura de decisiones
- Cobertura de decisión / condición modificada
- Prueba de ruta principal
- Prueba de ruta
Descripción general
La prueba de caja blanca es un método para probar la aplicación a nivel del código fuente. Estos casos de prueba se derivan del uso de las técnicas de diseño mencionadas anteriormente: prueba de flujo de control, prueba de flujo de datos, prueba de rama, prueba de ruta, cobertura de declaración y cobertura de decisión, así como cobertura de condición / decisión modificada. Las pruebas de caja blanca son el uso de estas técnicas como pautas para crear un entorno libre de errores al examinar todo el código. Estas técnicas de prueba de caja blanca son los componentes básicos de las pruebas de caja blanca, cuya esencia es la prueba cuidadosa de la aplicación a nivel de código fuente para reducir los errores ocultos más adelante. [2] Estas diferentes técnicas ejercitan todas las rutas visibles del código fuente para minimizar los errores y crear un entorno libre de errores. El objetivo de las pruebas de caja blanca es la capacidad de saber qué línea del código se está ejecutando y poder identificar cuál debería ser la salida correcta. [2]
Niveles
- Prueba unitaria . Las pruebas de caja blanca se realizan durante las pruebas unitarias para garantizar que el código funcione según lo previsto, antes de que ocurra la integración con el código probado previamente. Las pruebas de caja blanca durante las pruebas unitarias detectan potencialmente muchos defectos desde el principio y ayudan a abordar los defectos que ocurren más adelante después de que el código se integra con el resto de la aplicación y, por lo tanto, reduce el impacto de los errores más adelante en el desarrollo. [2]
- Pruebas de integración . Las pruebas de caja blanca en este nivel están escritas para probar las interacciones de las interfaces entre sí. La prueba de nivel de unidad aseguró que cada código se probó y funcionara en consecuencia en un entorno aislado y la integración examina la corrección del comportamiento en un entorno abierto mediante el uso de pruebas de caja blanca para cualquier interacción de interfaces que sea conocida por el programador. [2]
- Prueba de regresión . Las pruebas de caja blanca durante las pruebas de regresión son el uso de casos de prueba de caja blanca reciclados en los niveles de prueba de unidad e integración. [2]
Procedimiento básico
Los procedimientos básicos de las pruebas de caja blanca requieren que el evaluador tenga un conocimiento profundo del código fuente que se está probando. El programador debe tener un conocimiento profundo de la aplicación para saber qué tipos de casos de prueba crear, de modo que todas las rutas visibles se utilicen para las pruebas. Una vez que se entiende el código fuente, se puede analizar el código fuente para crear casos de prueba. Los siguientes son los tres pasos básicos que siguen las pruebas de caja blanca para crear casos de prueba:
- La entrada implica diferentes tipos de requisitos, especificaciones funcionales, diseño detallado de documentos, código fuente adecuado y especificaciones de seguridad. [ cita requerida ] Esta es la etapa de preparación de las pruebas de caja blanca para presentar toda la información básica.
- El procesamiento implica realizar análisis de riesgo para guiar todo el proceso de prueba, plan de prueba adecuado, ejecutar casos de prueba y comunicar los resultados. [ cita requerida ] Esta es la fase de creación de casos de prueba para asegurarse de que prueban a fondo la aplicación y los resultados dados se registran en consecuencia.
- El resultado implica la preparación de un informe final que abarque todos los preparativos y resultados anteriores. [ cita requerida ]
Ventajas
- Los efectos secundarios de tener conocimiento del código fuente son beneficiosos para realizar pruebas exhaustivas. [ cita requerida ]
- La optimización del código se vuelve fácil a medida que se exponen cuellos de botella poco visibles. [ cita requerida ]
- Da introspección al programador porque los desarrolladores describen cuidadosamente cualquier implementación nueva. [ cita requerida ]
- Proporciona trazabilidad de las pruebas desde la fuente, lo que permite que los cambios futuros en la fuente se capturen fácilmente en las pruebas recién agregadas o modificadas. [3]
- Fácil de automatizar. [4]
- Proporciona reglas claras basadas en ingeniería sobre cuándo detener las pruebas. [5] [4]
Desventajas
- Las pruebas de caja blanca se escriben para probar los detalles de una implementación específica. Esto significa que las pruebas fallarán cuando la implementación cambie, ya que la prueba está estrechamente acoplada a la implementación. Por lo tanto, se debe realizar un trabajo adicional para actualizar las pruebas para que coincidan con la implementación nuevamente cuando se cambie la implementación. Por otro lado, con las pruebas de caja negra, las pruebas son independientes de la implementación, por lo que aún se ejecutarán con éxito si la implementación cambia, pero el resultado o los efectos secundarios de la implementación no.
- El código bajo prueba podría reescribirse para implementar la misma funcionalidad de una manera diferente que invalide los supuestos incluidos en la prueba. Esto podría resultar en pruebas que fallan innecesariamente o, en el peor de los casos, pruebas que ahora dan falsos positivos y enmascaran errores en el código. Porque la prueba de caja blanca nunca se escribió de manera que pruebe el comportamiento previsto del código bajo prueba, sino solo de modo que la implementación específica haga lo que hace.
- Las pruebas de caja blanca aportan complejidad a las pruebas porque el probador debe tener conocimiento del programa, o el equipo de prueba debe tener al menos un muy buen programador que pueda comprender el programa a nivel de código. Las pruebas de caja blanca requieren un programador con un alto nivel de conocimiento debido a la complejidad del nivel de prueba que se debe realizar. [ cita requerida ]
- En algunas ocasiones, no es realista poder probar todas y cada una de las condiciones existentes de la aplicación y algunas condiciones no se probarán. [ cita requerida ]
- Las pruebas se centran en el software tal como existe y es posible que no se descubra la funcionalidad faltante. [ cita requerida ]
Vista moderna
Una visión más moderna es que la dicotomía entre las pruebas de caja blanca y las pruebas de caja negra se ha difuminado y se está volviendo menos relevante. Mientras que "caja blanca" originalmente significaba usar el código fuente y caja negra significaba usar requisitos, las pruebas ahora se derivan de muchos documentos en varios niveles de abstracción. El punto real es que las pruebas generalmente se diseñan a partir de una estructura abstracta, como el espacio de entrada, un gráfico o predicados lógicos, y la pregunta es de qué nivel de abstracción derivamos esa estructura abstracta. [4] Puede ser el código fuente, los requisitos, las descripciones del espacio de entrada o uno de los muchos tipos de modelos de diseño. Por lo tanto, la distinción "caja blanca / caja negra" es menos importante y los términos son menos relevantes. [ cita requerida ]
Hackear
En las pruebas de penetración , las pruebas de caja blanca se refieren a un método en el que un hacker de sombrero blanco tiene pleno conocimiento del sistema que está siendo atacado. El objetivo de una prueba de penetración de caja blanca es simular un infiltrado malintencionado que tiene conocimiento y posiblemente credenciales básicas para el sistema de destino.
Ver también
Referencias
- ^ Stacy Nelson (junio de 2003), Procesos de certificación de NASA / CR – 2003-212806 para software aeroespacial de seguridad crítica y de misión crítica (PDF) , Centro de investigación de Ames , p. 25,
[Glosario] Pruebas de caja blanca: pruebas basadas en el diseño en las que los ingenieros examinan el funcionamiento interno del código
- ^ a b c d e Williams, Laurie . "Prueba de caja blanca" (PDF) : 60–61, 69 . Consultado el 13 de febrero de 2013 . Cite journal requiere
|journal=
( ayuda )[ verificación necesaria ] - ^ Carpeta, Bob (2000). Prueba de sistemas orientados a objetos . Addison-Wesley Publishing Company Inc.
- ^ a b c Ammann, Paul; Offutt, Jeff (2008). Introducción a las pruebas de software . Prensa de la Universidad de Cambridge. ISBN 978-0-521-88038-1.
- ^ Myers, Glenford (1979). El arte de las pruebas de software . John Wiley e hijos.
enlaces externos
- BCS SIGIST (Grupo de interés especializado en pruebas de software de la British Computer Society): http://www.testingstandards.co.uk/Component%20Testing.pdf Estándar para pruebas de componentes de software ], Borrador de trabajo 3.4, 27 de abril de 2001.
- http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf tiene más información sobre las pruebas de flujo de control y las pruebas de flujo de datos.
- http://research.microsoft.com/en-us/projects/pex/ Pex: pruebas automatizadas de caja blanca para .NET