Diferencia entre revisiones de «Pruebas de caja blanca»

← Ir a diferencia anterior Ir a siguiente diferencia →

Contenido eliminado Contenido añadido

En renglón

Revisión del 15:17 5 feb 2021

Las pruebas de caja blanca (también conocidas como MMG) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. El ingeniero de pruebas escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados.

Al estar basadas en una implementación concreta, si esta se modifica, por regla general las pruebas también deberán rediseñarse.

Aunque las pruebas de caja blanca son aplicables a varios niveles MMG —unidad, integración y sistema—, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.) pero también pueden probar los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.

A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.

Las principales técnicas de diseño de pruebas de caja blanca son:

Pruebas de flujo de control
Pruebas de flujo de datos
Pruebas de bifurcación (branch testing)
Pruebas de caminos básicos

Hacking

En los análisis de vulnerabilidades y pruebas de penetración de sistemas informáticos (Pentest), las pruebas de caja blanca hacen referencia a una metodología donde el ciberdelincuente posee conocimiento total y absoluto del sistema que pretende atacar. El objetivo de estos tests, que perciben el sistema de forma transparente, es simular el comportamiento de un intruso malicioso que contase con permisos de acceso e información precisa acerca del sistema.

Véase también

Enlaces externos

http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf contiene información sobre pruebas de control de flujo y de datos (en inglés).

http://research.microsoft.com/en-us/projects/pex/ Pex - pruebas de caja blanca automatizadas para la plataforma .NET (en inglés).

Datos: Q1066228
Multimedia: White-box testing / Q1066228

@@ Línea 1: / Línea 1: @@
-Las '''pruebas de caja blanca''' (también conocidas como ''pruebas de caja de cristal'' o ''pruebas estructurales'') se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al [[código fuente]]. El ingeniero de pruebas escoge distintos valores de entrada para examinar cada uno de los posibles [[flujos de ejecución]] del programa y cerciorarse de que se devuelven los valores de salida adecuados.
+Las '''pruebas de caja blanca''' (también conocidas como MMG) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al [[código fuente]]. El ingeniero de pruebas escoge distintos valores de entrada para examinar cada uno de los posibles [[flujos de ejecución]] del programa y cerciorarse de que se devuelven los valores de salida adecuados.
 Al estar basadas en una implementación concreta, si esta se modifica, por regla general las pruebas también deberán rediseñarse.
-Aunque las pruebas de caja blanca son aplicables a varios niveles —[[Pruebas de unidad|unidad]], [[Pruebas de integración|integración]] y [[pruebas de sistema|sistema]]—, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecución dentro de cada unidad ([[Función (informática)|función]], [[Clase (informática)|clase]], [[Módulo (informática)|módulo]], etc.) pero también pueden probar los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.
+Aunque las pruebas de caja blanca son aplicables a varios niveles MMG —[[Pruebas de unidad|unidad]], [[Pruebas de integración|integración]] y [[pruebas de sistema|sistema]]—, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecución dentro de cada unidad ([[Función (informática)|función]], [[Clase (informática)|clase]], [[Módulo (informática)|módulo]], etc.) pero también pueden probar los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.
 A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de [[casos de prueba]], podría pasar por alto partes incompletas de la [[especificación]] o [[Requisito (sistemas)|requisito]]s faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.