NGENIERIA DE SOFTWARE

 
 
 
TEMA
PRUEBA DE CAJA NEGRA
 
 
ALUMNOS
GERMAN ANDRES MENDOZA RAMIREZ
DEIDER DAVID BLANCO MENGUAL
 
 
 
DOCENTE
NAYELI MEJIA RIVEIRA
 
 
FACULTAD DE INGENIERIA
 
PROGRAMA SISTEMAS
 
UNIVERCIDAD DE LA GUAJIRA
 
MAYO 2020
 PRUEBA DE CAJA NEGRA

Las pruebas de caja negra se definen como una técnica de

testing en la que se prueba la funcionalidad de una
aplicación ignorando la parte interna de dicha aplicación.
Esto quiere decir que se obvia la estructura del código, la
arquitectura, los detalles relacionados con la implementación
de los diferentes módulos, paquetes o rutas en la que se
compone el código.
 ¿QUÉ TIPO DE PRUEBAS DE CAJA NEGRA HAY?

• Clase de equivalencias
• Análisis de valores límites
• Tablas de decisiones
• Transición entre estados
• Pruebas de caso de uso
• Pruebas de historias de usuario
 CLASE DE EQUIVALENCIAS

• Consisten en diseñar y clasificar entradas de datos para una funcionalidad similar del
software, esperando que sean procesados de la misma manera.
 ANÁLISIS DE VALORES LÍMITES

• Se valen de los análisis de las pruebas de clase de equivalencias para obtener datos limites
que acaten las posibles causísticas de los datos. Basándose en criterios como la probabilidad
que se presenten más errores.
 TABLAS DE DECISIONES

• Las tablas de decisiones son una herramienta fundamental para la documentación de las
reglas de negocio que conllevan una alta complejidad.
 TRANSICIÓN ENTRE ESTADOS

• Se basan en los diferentes estados de un software.

Este diagrama de estados permite al tester visualizar información importante sobre el software,
como pueden ser las transiciones, entradas, salidas o eventos encadenados.
 PRUEBAS DE CASO DE USO

• Estas pruebas de caja negra se basan en la representación de las interacciones entre actores
(usuarios o sistemas que interactúan con nuestro software). Basándose en estas interacciones
se pueden diseñar casos de prueba.
 PRUEBAS DE HISTORIAS DE USUARIO

• Prueba muy utilizada en metodologías Ágiles como puede ser el Scrum. Los requerimientos
de usuario son preparados como historias de usuario.
• Estas historias de usuario describen una funcionalidad que puede ser desarrollada o probada
en una misma secuencia.
 ¿CÓMO SE REALIZAN LAS
PRUEBAS DE CAJA NEGRA?
Cada empresa o tester, tienen su estrategia a la hora de
aplicar este tipo de prueba, dependiendo del tipo de
aplicación o el tiempo asignado a pruebas, entre otros
factores, se realizan las pruebas de caja negra de una forma
más intensiva o más exploratorias.
Aun así, hay una secuencia de pasos a seguir media
estandarizada para poder realizar este tipo de prueba de
manera efectiva
 TÉCNICAS DE PRUEBAS DE CAJA NEGRA

• Partición de equivalencias
• Análisis de valores borde
• Tablas de decisión
• Transición entre estados
• Pruebas de casos de uso
 PARTICIÓN DE EQUIVALENCIAS

• Consiste en la división de los dominios de tipos de datos de entrada, evaluando su

comportamiento para un valor de cada clase. En base a esto, determinar un conjunto de
entradas válidas e inválidas para el programa, las cuales serán retomadas posteriormente.
 ANÁLISIS DE VALORES BORDE

• Se valen de los análisis de las pruebas de clase de equivalencias para obtener datos limites
que acoten las posibles causísticas de los datos. Basándose en criterios como la probabilidad
que se presenten mas errores.
Los valores máximos y mínimos son los valores límites.
Se pueden aplicar para datos válidos e inválidos.
 TABLAS DE DECISIÓN

• Las tablas de decisiones son una herramienta fundamental para la documentación de las
reglas de negocio que conllevan una alta complejidad.
Se crean a partir de las especificaciones funcionales y de las reglas de negocio.
Las entradas y salidas se representan en muchas ocasiones con valores booleanos (verdadero o
falso).
Las tablas de decisiones contienen secuencias de condiciones encadenadas con las
combinaciones de los valores booleanos para cada entrada de datos, así como su resultado
esperado de cada combinación.
 TRANSICIÓN ENTRE ESTADOS

Se basan en los diferentes estados de un software.

Se representan en un diagrama de transición entre estados.
Este diagrama de estados permite al tester visualizar información importante sobre el software,
como pueden ser las transiciones, entradas, salidas o eventos encadenados.
Una tabla de estado nos permite ver las relaciones entre los estados del software y las entradas
de datos. Nos ayuda a ver posibles transiciones inválidas.
 PRUEBAS DE CASOS DE USO

Estas pruebas de caja negra se basan en la representación de las interacciones entre actores
(usuarios o sistemas que interactúan con nuestro software). Basándose en estas interraciones se
pueden diseñar casos de prueba.
Suelen ir acompañadas de precondiciones que deben cumplirse para los actores funcionen de
forma adecuada.
Cada caso de uso termina con postcondiciones que serán los resultados analizados después de
la ejecución.
Se suelen usar para definir las pruebas de aceptación en la que participan usuarios o clientes.
 EJEMPLOS
1. Descripción del caso: El sistema enviará un correo electrónico cuando se registre alguna de las
siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión de
factura a cliente y registro de cobro al cliente.
Técnica de pruebas de caja negra: Requerimiento funcional
• Caso 1.1: Datos de entrada: Registrar pedido de venta. Resultado esperado (Salida): El sistema envía
un correo electrónico al cliente como constancia que su pedido se ha recibido.
• Caso 1.2: Datos de entrada: Registrar despacho de mercancía al cliente. Resultado esperado (Salida):
El sistema envía un correo electrónico al cliente como constancia que se ha realizado el despacho.
 EJEMPLO 2
• Descripción del caso: Se tiene un campo de texto que solo acepta caracteres alfabéticos. La longitud del valor
ingresado debe estar entre 6 y 10 caracteres.

Técnica de pruebas de caja negra: Partición de equivalencias.

• Usando partición de equivalencias, se pueden establecer tres particiones, longitudes entre 0 y 5 caracteres
(partición inválida), longitudes entre 6 y 10 caracteres (partición válida), y longitudes mayores a 10 caracteres
(partición inválida). Además, el ingreso de caracteres no alfabéticos (por ejemplo un número), se considera
también dato inválido.
• Caso 1: Datos de entrada: cadena de 5 caracteres. Resultado esperado (Salida): La aplicación no permite el
ingreso del dato y muestra un mensaje de error.
• Caso 2: Datos de entrada: cadena de 7 caracteres, incluyendo uno o más caracteres no alfabéticos. Resultado
esperado (Salida): La aplicación no permite el ingreso del dato y muestra un mensaje de error.
 EJEMPLO 3
• Descripción del caso: Se tiene un campo de texto que solo acepta caracteres alfabéticos. La
longitud del valor ingresado debe estar entre 6 y 10 caracteres.

Técnica de pruebas de caja negra: Análisis de valores borde.

Tomando el ejemplo 1, podemos definir casos de prueba adicionales si tomamos los valores
borde, es decir dado que la aplicación acepta entre 6 y 10 caracteres, los valores borde
consistirían en ingresar cadenas de caracteres con estas longitudes. Usualmente las
condiciones de error se suelen presentar en estos valores borde, muchas veces relacionado
con el manejo inadecuado en programación de restricciones de tipo mayor o menor estricto.

Caso 1: Datos de entrada: cadena de 6 caracteres, sólo caracteres alfabéticos. Resultado

esperado (Salida): La aplicación permite el ingreso del dato.
 VIDEO EXPLICATIVO
• https://www.youtube.com/watch?v=NQAWaifeEbA
 CONCLUSIÓN

• Al desarrollar un nuevo software o sistema de información, la primera fase de

prueba a considerar es la fase de prueba unitaria. Como se mencionó anteriormente,
existen pruebas de caja negra, una de las cuales es analizar los datos de entrada y
salida, y la otra es analizar el proceso interno del sistema para evaluar posibles
inconsistencias. Sistema para corregirlos y pasar a una nueva etapa del proceso de
desarrollo del sistema. Podemos enfatizar que las pruebas unitarias son una forma de
probar el funcionamiento correcto de los módulos de código esto es para garantizar
que cada módulo funcione correctamente.
 REFERENCIAS BIBLIOGRAFICAS
• https://testingbaires.com/2017/02/26/pruebas-caja-negra-enfoque-practico/
• http://softwaretestingfundamentals.com/
• https://howtotesting.com/testing-funcional/pruebas-de-caja-negra/
• http://www.pmoinformatica.com/2017/02/pruebas-de-caja-negra-ejemplos.html
GRACIAS