stringtranslate.com

Prueba de caja blanca

Las pruebas de caja blanca (también conocidas como pruebas de caja transparente , pruebas de caja de vidrio , pruebas de caja transparente y pruebas estructurales ) son un método de prueba de software que prueba las estructuras internas o el funcionamiento de una aplicación, en lugar de su funcionalidad (es decir, pruebas de caja negra ). En las pruebas de caja blanca, se utiliza una perspectiva interna del sistema para diseñar casos de prueba. El evaluador 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 los niveles de unidad , integración y sistema del proceso de prueba de software. Aunque los evaluadores tradicionales tendían a pensar que las pruebas de caja blanca se realizaban a nivel de unidad, hoy en día se utilizan con más frecuencia para pruebas de integración y sistema. 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 pruebas 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 sobre cómo debe comportarse cada componente del software (como en los procesos DO-178C e ISO 26262 ), las técnicas de pruebas de caja blanca pueden lograr la evaluación de requisitos no implementados o faltantes.

Las técnicas de diseño de pruebas de caja blanca incluyen los siguientes criterios de cobertura de código :

Descripción general

Las pruebas de caja blanca son un método para probar la aplicación a nivel del código fuente. Estos casos de prueba se derivan mediante el uso de las técnicas de diseño mencionadas anteriormente: pruebas de flujo de control , pruebas de flujo de datos, pruebas de ramificación, pruebas de ruta, cobertura de declaraciones y cobertura de decisiones, así como cobertura de condiciones/decisiones modificadas. Las pruebas de caja blanca son el uso de estas técnicas como pautas para crear un entorno libre de errores mediante el examen de 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 del código fuente para reducir los errores ocultos más adelante. [2] Estas diferentes técnicas ejercitan cada ruta visible 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 el resultado correcto. [2]

Niveles

  1. Pruebas unitarias . Las pruebas de caja blanca se realizan durante las pruebas unitarias para garantizar que el código funcione como se espera, antes de que se realice la integración con el código probado previamente. Las pruebas de caja blanca durante las pruebas unitarias pueden detectar muchos defectos en una etapa temprana y ayudan a abordar los defectos que ocurren más adelante, una vez que el código se integra con el resto de la aplicación, y, por lo tanto, reducen el impacto de los errores más adelante en el desarrollo. [2]
  2. Pruebas de integración . Las pruebas de caja blanca en este nivel se escriben para probar las interacciones de las interfaces entre sí. Las pruebas de nivel unitario se aseguraron de que cada código se probara y funcionara como corresponde 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 sean conocidas por el programador. [2]
  3. Pruebas de regresión . Las pruebas de caja blanca durante las pruebas de regresión consisten en utilizar casos de prueba de caja blanca reciclados en los niveles de pruebas unitarias y de 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 se utilicen todos los caminos visibles para las pruebas. Una vez que se comprende el código fuente, se puede analizar para crear los casos de prueba. A continuación, se detallan los tres pasos básicos que siguen las pruebas de caja blanca para crear los casos de prueba:

  1. 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.
  2. El procesamiento implica realizar un análisis de riesgos para guiar todo el proceso de prueba, un 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 exhaustivamente la aplicación y los resultados dados se registran en consecuencia.
  3. El resultado implica la preparación de un informe final que abarque todos los preparativos y resultados anteriores. [ cita requerida ]

Ventajas

  1. Los efectos secundarios de tener el conocimiento del código fuente son beneficiosos para realizar pruebas exhaustivas. [ cita requerida ]
  2. La optimización del código se vuelve fácil a medida que se exponen los cuellos de botella discretos. [ cita requerida ]
  3. Proporciona introspección al programador porque los desarrolladores describen cuidadosamente cualquier nueva implementación. [ cita requerida ]
  4. Proporciona trazabilidad de las pruebas desde la fuente, lo que permite capturar fácilmente los cambios futuros en la fuente en las pruebas recientemente agregadas o modificadas. [3]
  5. Fácil de automatizar. [4]
  6. Proporciona reglas claras y basadas en ingeniería sobre cuándo detener las pruebas. [5] [4]

Desventajas

  1. 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 vinculada a la implementación. Se debe realizar un trabajo adicional para actualizar las pruebas de modo que coincidan nuevamente con la implementación cuando esta cambie. Por otro lado, con las pruebas de caja negra, las pruebas son independientes de la implementación y, por lo tanto, se ejecutarán correctamente si la implementación cambia, pero el resultado o los efectos secundarios de la implementación no lo hacen.
  2. El código que se está probando podría reescribirse para implementar la misma funcionalidad de una manera diferente que invalide las suposiciones incorporadas en la prueba. Esto podría dar como resultado pruebas que fallan innecesariamente o, en el peor de los casos, pruebas que ahora arrojan falsos positivos y ocultan errores en el código. La prueba de caja blanca nunca se escribió de manera que pruebe el comportamiento previsto del código que se está probando, sino solo de manera que la implementación específica haga lo que hace.
  3. Las pruebas de caja blanca agregan complejidad a las pruebas porque el evaluador debe tener conocimiento del programa o el equipo de prueba debe tener al menos un programador muy bueno 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 pruebas que se deben realizar.
  4. En algunas ocasiones, no es realista poder probar cada una de las condiciones existentes de la aplicación y algunas condiciones no se probarán.
  5. Las pruebas se centran en el software tal como existe y es posible que no se detecten las funcionalidades faltantes.

Visión moderna

Una visión más moderna es que la dicotomía entre pruebas de caja blanca y pruebas de caja negra se ha desdibujado y está perdiendo relevancia. 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] Eso puede ser el código fuente, los requisitos, las descripciones del espacio de entrada o uno de las docenas de 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 ]

Seco

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. [6] El objetivo de una prueba de penetración de caja blanca es simular un infiltrado malicioso que tiene conocimiento y posiblemente credenciales básicas para el sistema objetivo. Para una prueba de penetración de este tipo, normalmente se proporcionan credenciales administrativas para analizar cómo o qué ataques pueden afectar a las cuentas con privilegios elevados. [7] El código fuente puede ponerse a disposición para que lo utilice como referencia para el evaluador. Cuando el código es un objetivo en sí mismo, no se trata (solo) de una prueba de penetración, sino de una auditoría de seguridad del código fuente (o revisión de seguridad). [8]

Véase también

Referencias

  1. ^ Stacy Nelson (junio de 2003), NASA/CR–2003-212806 Certification Processes for Safety-Critical and Mission-Critical Aerospace Software (PDF) , Ames Research Center , pág. 25, [Glosario] Pruebas de caja blanca: pruebas basadas en el diseño en las que los ingenieros examinan el funcionamiento interno del código.
  2. ^ abcde Williams, Laurie . "White-Box Testing" (PDF) . págs. 60–61, 69. Archivado desde el original (PDF) el 3 de marzo de 2016 . Consultado el 13 de febrero de 2013 .[ verificación necesaria ]
  3. ^ Binder, Bob (2000). Prueba de sistemas orientados a objetos . Addison-Wesley Publishing Company Inc. ISBN 9780201809381.
  4. ^ abc Ammann, Paul; Offutt, Jeff (2008). Introducción a las pruebas de software. Cambridge University Press. ISBN 978-0-521-88038-1.
  5. ^ Myers, Glenford (1979). El arte de las pruebas de software . John Wiley and Sons. ISBN 9780471043287.
  6. ^ "Un modelo de prueba de penetración" (PDF) . Oficina Federal de Seguridad de la Información (BSI).
  7. ^ Baran, Ewelina. "Tipos de pruebas de penetración". Blaze Information Security GmbH . Consultado el 12 de septiembre de 2024 .
  8. ^ Sullivan, James. "¿Qué es la auditoría de código? Entender su propósito y proceso". 17 Web Dev, LLC . Consultado el 12 de septiembre de 2024 .

Enlaces externos