EL INTERNET ES TAN GRANDE, TAN PODEROSO Y SIN SENTIDO QUE

PARA ALGUNAS PERSONAS ES UN SUSTITUTO COMPLETO PARA LA

VIDA (ANDREW BROWN)

INGENIERIA 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

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 bibliográficas
 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
CAMINAR SOBRE AGUA Y DESARROLLAR SOFTWARE EN BASE A UNA
ESPECIFICACION ES TAN SENCILLO, SI AMBOS ESTAN CONGELADOS
(EDWARD V BERARD)