stringtranslate.com

Pruebas de caja blanca

La prueba de caja blanca (también conocida como prueba de caja transparente , prueba de caja de vidrio , prueba de caja transparente y prueba estructural ) es un método de prueba de software que prueba las estructuras internas o el funcionamiento de una aplicación, a diferencia de su funcionalidad (es decir, prueba de caja negra). pruebas ). En las pruebas de caja blanca, se utiliza una perspectiva interna del sistema para diseñar casos de prueba. El evaluador elige entradas para explorar rutas a través del código y determinar los resultados esperados. Esto es análogo a probar nodos en un circuito, por ejemplo, pruebas en circuito (TIC). Las pruebas de caja blanca se pueden aplicar a nivel 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 mayor frecuencia para pruebas de integración y sistemas. 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 prueba de caja blanca pueden lograr 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

La prueba de caja blanca es un método para probar la aplicación al 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 rama, pruebas de ruta, cobertura de declaraciones y cobertura de decisiones, así como cobertura de condiciones/decisiones modificadas. La prueba de caja blanca es el uso de estas técnicas como pautas para crear un entorno libre de errores examinando 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 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. Examen de la unidad . 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 se realice 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, 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 están escritas para probar las interacciones de las interfaces entre sí. Las pruebas a nivel de unidad aseguraron que cada código fuera probado 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 conocidas por el programador. [2]
  3. Pruebas de regresión . Las pruebas de caja blanca durante las pruebas de regresión consisten en el uso de casos de prueba de caja blanca reciclados en los niveles de prueba unitaria 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 para que se utilicen todos los caminos visibles para las pruebas. Una vez que se comprende el código fuente, se puede analizar 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:

  1. La entrada implica diferentes tipos de requisitos, especificaciones funcionales, diseño detallado de documentos, código fuente adecuado y especificaciones de seguridad. [ cita necesaria ] 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 necesaria ] Esta es la fase de creación de casos de prueba para asegurarse de que prueben exhaustivamente la aplicación y que los resultados proporcionados se registren en consecuencia.
  3. El resultado implica la preparación de un informe final que abarque todos los preparativos y resultados anteriores. [ cita necesaria ]

Ventajas

  1. Los efectos secundarios de tener conocimiento del código fuente son beneficiosos para las pruebas exhaustivas. [ cita necesaria ]
  2. La optimización del código se vuelve fácil a medida que se exponen cuellos de botella discretos. [ cita necesaria ]
  3. Le da al programador introspección porque los desarrolladores describen cuidadosamente cualquier implementación nueva. [ cita necesaria ]
  4. Proporciona trazabilidad de las pruebas desde el origen, lo que permite capturar fácilmente cambios futuros en el origen en las pruebas recién agregadas o modificadas. [3]
  5. Fácil de automatizar. [4]
  6. Proporciona reglas claras 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 acoplada a la implementación. Es necesario realizar trabajo adicional para actualizar las pruebas para que coincidan nuevamente con la implementación cuando se cambie. 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 exitosamente si la implementación cambia pero el resultado o los efectos secundarios de la implementación no.
  2. El código bajo prueba podría reescribirse para implementar la misma funcionalidad de una manera diferente que invalide las suposiciones incorporadas en la prueba. Esto podría dar lugar a pruebas que fallen innecesariamente o, en el peor de los casos, pruebas que ahora den falsos positivos y enmascaren errores en el código. La prueba de caja blanca nunca se escribió de manera que pruebe el comportamiento previsto del código bajo prueba, sino solo de manera que la implementación específica haga lo que hace.
  3. Las pruebas de caja blanca aportan complejidad a las pruebas porque el evaluador debe tener conocimiento del programa, o el equipo de pruebas 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 debe 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 descubran las funciones faltantes.

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 desdibujado 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 verdadero punto 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 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 necesaria ]

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 usuario interno malicioso que tiene conocimiento y posiblemente credenciales básicas para el sistema de destino.

Ver también

Referencias

  1. ^ Stacy Nelson (junio de 2003), NASA/CR–2003-212806 Procesos de certificación para software aeroespacial de misión crítica y seguridad crítica (PDF) , Centro de investigación Ames , p. 25, [Glosario] Pruebas de caja blanca: pruebas basadas en diseño donde los ingenieros examinan el funcionamiento interno del código
  2. ^ abcde Williams, Laurie . "Pruebas de caja blanca" (PDF) . págs. 60–61, 69. Archivado desde el original (PDF) el 3 de marzo de 2016 . Consultado el 13 de febrero de 2013 .[ se necesita verificación ]
  3. ^ Carpeta, 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. Prensa de la Universidad de Cambridge. ISBN 978-0-521-88038-1.
  5. ^ Myers, Glenford (1979). El arte de las pruebas de software . John Wiley e hijos. ISBN 9780471043287.

enlaces externos