INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y

CIENCIAS SOCIALES Y ADMINISTRATIVAS

UNIDAD DE APRENDIZAJE: INGENIERÍA DE PRUEBAS

PROFESOR: GARCIA RODRIGUEZ JOSE LUIS

ALUMNO: TOLENTINO SÁNCHEZ MARCO TEVI

SECUENCIA: 5NM70

2.2.4 Pruebas de caja blanca

1
 INDICE
INTRODUCCIÓN…………………………………………………………………………………………… 3
OBJETIVO …….……………………………………………………………………………………………….3
MISION …….……………………………………………………………………………….………………….3
VISION …….………………………………………………………………………………………..………….3
ALCANCE…….……………………………………………………………………………………………..….3
DESARROLLO…………………………………………………………………………………………………4
CONCLUSIÓN ………………………………………………………………………………………….….11
REFERENCIAS………………………………..……………………………………………….……………12

2
 INTRODUCCION

Las pruebas en el software son muy importantes ya que estas nos ayudan a
detectar errores a un tiempo temprano y asi poder corregirlo a la hora de entregar
el software final dentro de ellas esta la prueba de caja blanca o también conocida
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.

OBJETIVO

Conocer a detalle en que consiste la prueba de caja blanca asi como sus
características y que es lo que nos puede ayudar.

MISION

Tener el conocimiento necesario para llevar a cabo las pruebas de caja blanco
haciendo buen uso de las técnicas.

VISION

Poder aplicar las pruebas de caja blanca en sus diferentes etapas y tipos en un
desarrollo de software.

ALCANCE

Una vez conociendo la parte teórica de las pruebas de caja blanca llevarlos a cabo
durante el desarrollo de un software para asi poder contrarrestar los errores que
se presente.

3
 DESARROLLO

Pruebas de caja blanca es una técnica de prueba de software en la que se prueba

la estructura interna, el diseño y la codificación del software para verificar el flujo
de entrada y salida y para mejorar el diseño, la usabilidad y la seguridad. En una
prueba de caja blanca, los probadores aparecen en el código, por lo que se
denomina prueba de caja limpia, prueba de caja abierta, prueba de caja
transparente, prueba basada en código y prueba de caja de vidrio.

Es una de las dos partes del enfoque de Box Testing para las pruebas de
software. Su contraparte son las pruebas de Blackbox, las pruebas de usuario
externo o de usuario final. Las pruebas de caja blanca en ingeniería de software,
por otro lado, se basan en el funcionamiento interno de una aplicación e implican
pruebas internas.

El término «WhiteBox» se utilizó debido al concepto de caja transparente. El

cuadro transparente o el nombre WhiteBox simboliza la capacidad de ver a través
de la capa exterior del software (o «caja») en su funcionamiento interno. Del
mismo modo, la «caja negra» en «Prueba de caja negra» símbolo que no puede
ver el funcionamiento interno del software para que solo se pueda probar la
experiencia del usuario final.

4
La prueba de caja blanca implica probar el código del software para lo siguiente:

 Agujeros de seguridad internos

 Rutas rotas o mal estructuradas en los procesos de codificación
 Las entradas específicas fluyen a través del código
 Rendimiento esperado
 Funcionalidad de bucle condicional
 Pruebe cada enunciado, objeto y función individualmente

Estas se basan en el diseño de Casos de Prueba que usa la estructura de control

del diseño procedimental para derivarlos. Mediante las pruebas de Caja Blanca el
ingeniero de software puede obtener Casos de Prueba que:

 Garanticen que se ejerciten por lo menos una vez todos los caminos
independientes de cada módulo, programa o método.
 Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
 Ejecuten todos los bucles en sus límites operacionales.
 Ejerciten las estructuras internas de datos para asegurar su validez.

La prueba se puede realizar a nivel de sistema, integración y unidad para el

desarrollo de software. Verificar el flujo de trabajo de su aplicación es uno de los
principales objetivos de las pruebas de caja blanca. Implica probar un conjunto de
entradas predefinidas con salidas esperadas o requeridas, de modo que no tenga
un error cuando resulte en una entrada en particular.

¿Cómo se hacen las pruebas de caja blanca?

Para darle una explicación simplificada de las pruebas de caja blanca, la hemos
compartido dos pasos básicos. Los probadores hacen esto cuando prueban una
aplicación usando la técnica de prueba de caja blanca:

5
ACERCA DEL CÓDIGO FUENTE

Lo primero que suele hacer un evaluador es aprender y comprender el código

fuente de la aplicación. Debido a que las pruebas de caja blanca implican probar el
funcionamiento interno de una aplicación, el evaluador debe estar muy
familiarizado con los lenguajes de programación utilizados en las aplicaciones que
está probando. Además, la persona que realiza la prueba debe estar muy
familiarizada con las prácticas de codificación segura. La seguridad es a menudo
uno de los principales objetivos de las pruebas de software. El evaluador debe
poder detectar problemas de seguridad y prevenir ataques de piratas informáticos
y usuarios ingenuos que pueden inyectar, consciente o inconscientemente, código
malicioso en la aplicación.

CREAR CASOS DE PRUEBA Y RENDIMIENTO

El segundo paso básico para las pruebas de caja blanca es probar el código
fuente de la aplicación para determinar el flujo y la estructura adecuados. Una
forma es escribir más código para probar el código fuente de la aplicación. El
probador no desarrollará muchas pruebas para cada proceso o conjunto de
procesos en la aplicación. Este método requiere que el evaluador tenga un
conocimiento personal del código y esto a menudo lo hace el desarrollador. Otros
métodos incluyen Prueba manual, prueba y prueba de error y uso de herramientas
de prueba.

Técnicas de prueba de caja blanca

La principal técnica de prueba de caja blanca es el análisis de cobertura de

código. El análisis de cobertura de código elimina las lagunas en un Caso de
prueba suite. Identifica áreas de un programa que no implementan una serie de
casos de prueba. Una vez que se identifican las lagunas, crea casos de prueba
para verificar partes del código que no se han probado, aumentando así la calidad
del producto de software.
6
Hay herramientas automatizadas disponibles para analizar la cobertura del
Código. A continuación, se muestran algunas técnicas de análisis de cubiertas que
puede utilizar un probador de cajas:

Cubierta de declaración: – Esta técnica requiere que todas las declaraciones

posibles en el código se prueben al menos una vez durante el proceso de prueba
de Ingeniería de software.

Cubierta de rama – Esta técnica comprueba todas las rutas posibles (if-else y
otros bucles condicionales) para una aplicación de software.

Camino básico

La prueba del camino básico es una técnica de prueba de la Caja Blanca

propuesta por Tom McCabe.

Esta técnica permite obtener una medida de la complejidad lógica de un diseño y

usar esta medida como guía para la definición de un conjunto básico.

La idea es derivar casos de prueba a partir de un conjunto dado de caminos

independientes por los cuales puede circular el flujo de control. Para obtener dicho
conjunto de caminos independientes se construye el Grafo de Flujo asociado y se
calcula su complejidad ciclomática. Los pasos que se siguen para aplicar esta
técnica son:

 A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.
 Se calcula la complejidad ciclomática del grafo.
 Se determina un conjunto básico de caminos independientes.
 Se preparan los casos de prueba que obliguen a la ejecución de cada
camino del conjunto básico.

7
Los casos de prueba derivados del conjunto básico garantizan que durante la
prueba se ejecuta por lo menos una vez cada sentencia del programa.

Las siguientes son técnicas importantes de prueba de Caja Blanca.

 Cubierta de declaración.
 Cobertura de decisiones.
 Cubierta de rama.
 Cobertura condicional.
 Cobertura multicondicional.
 Cubierta de máquina de estado terminada.
 Cubierta de sendero.
 Prueba de flujo controlado.
 Prueba de flujo de datos.

Tipos de prueba de caja blanca

 Prueba de unidad: A menudo es el primer tipo de prueba que se realiza a

pedido. Examen de la unidad se realiza en cada unidad o bloque de código
a medida que se desarrolla. La prueba unitaria la realiza básicamente el
programador. Como desarrollador de software, usted desarrolla y prueba
algunas líneas de código, una sola función o un objeto para asegurarse de
que funciona antes de que Unit Testing continúe ayudando a identificar la
mayoría de los errores, en las primeras etapas del ciclo de vida del
desarrollo de software. Las fallas identificadas en esta etapa son más
baratas y fáciles de solucionar.

 Prueba de pérdida de memoria: Las pérdidas de memoria son una de las

principales causas de que las aplicaciones se ejecuten más lentamente. Un
especialista en control de calidad con experiencia en la detección de fugas

8
 de memoria es esencial en los casos en los que tiene una aplicación de
software de ejecución lenta.
 Caja blanca Prueba de penetración: En esta prueba, el probador /
desarrollador tiene información completa sobre el código fuente de la
aplicación, información detallada de la red, direcciones IP involucradas y
toda la información del servidor en el que se ejecuta la aplicación. El
objetivo es atacar el código desde varios ángulos para exponer las
amenazas a la seguridad.
 Prueba de transformación de caja blanca: Las pruebas de mutación se
utilizan a menudo para determinar las mejores técnicas de codificación para
ampliar una solución de software.
 De Cobertura de Sentencias: Comprueba que todas las sentencias se
ejecuten al menos una vez.
 De Cobertura de Decisión: Ejecuta casos de prueba de modo que cada
decisión se pruebe al menos una vez a Verdadero (True) y otra a Falso
(False).
 De Cobertura de Condición: Ejecuta un caso de prueba a True y otro a
False por cada condición, teniendo en cuenta que una decisión puede estar
formada por varias condiciones.
 De Cobertura de Condición/Decisión: Se realizan las pruebas de cobertura
de condición y las de decisión a la vez.
 De Condición Múltiple: Cada decisión multicondición se traduce a una
condición simple, aplicando posteriormente la cobertura de decisión.
 De Cobertura de Caminos: Se escriben casos de prueba suficientes para
que se ejecuten todos los caminos de un programa. Entendiéndose camino
como una secuencia de sentencias encadenadas desde la entrada del
programa hasta su salida

Beneficios de las pruebas de caja blanca

 Optimice el código encontrando errores ocultos.

9
  Los casos de prueba de caja blanca se pueden automatizar fácilmente.
 La prueba se vuelve más completa ya que generalmente se cubren todas
las rutas de código.
 Las pruebas pueden comenzar temprano en SDLC incluso si no hay una
GUI disponible.

Desventajas de las pruebas de Caja blanca.

 Las pruebas de caja blanca pueden ser bastante complicadas y costosas.

 Los desarrolladores que crean casos de prueba suelen detectar una caja
blanca. Las pruebas de caja blanca de los desarrolladores no pueden dar
lugar a errores de producción.
 Las pruebas de caja blanca requieren recursos profesionales, con una
comprensión detallada de la programación y la implementación.
 Se necesita una prueba de tiempo en un recuadro blanco, más aplicaciones
registradas se toman el tiempo para hacer una prueba completa.

10
 CONLUSIÓN

Después de conocer cada uno de los tipos, características de la caja blanca

podemos observar que estas pruebas nos pueden ayudar mucho durante el
desarrollo de software ya que nos ayudan a mejorar la calidad de nuestro sistema
y a detectar errores que podemos corregir.

11
 REFERENCIAS

ŚWidziński, R. (2022). Modern CMake for C++: Discover a better approach to building,

testing, and packaging your software. Packt Publishing.

Foundations of Software Testing ISTQB Certification, 4th edition (4a edición). (2019).

Cengage Learning EMEA.

Ian, S. (2022). Software Engineering. Sommerville Ian.

12