Guía SENA 2018
Testing- pruebas
Temas a tratar:
1. Técnicas basadas en la especificación o Técnicas de caja negra
2. Técnicas basadas en la estructura o técnicas de Caja blanca
3. Técnicas basadas en la experiencia
4. Selección de las técnicas de prueba
Instructora: Carolina Mesa Martínez
Introducción
El tester participa de todas las etapas del proceso de desarrollo de software, colaborando
para asegurar la máxima calidad del producto. Su perfil conjuga un conjunto de
habilidades con el conocimiento del negocio, de la aplicación bajo prueba y de cómo
planificar, diseñar, ejecutar y administrar las pruebas.
¿Qué es la prueba de la caja negra?
Las pruebas de caja negra son, ni más ni menos que, pruebas funcionales
dedicadas a “mirar” en el exterior de lo que se prueba. Estas pruebas se
denominan de varias formas, pruebas de caja “opaca”, pruebas de
entrada/salida,pruebas inducidas por datos…los sinónimos son muchos y muy
variados
¿Cuáles son las pruebas de caja blanca?
En programación, se denomina cajas blancas a un tipo de pruebas de software
que se realiza sobre las funciones internas de un módulo. Así como las pruebas
de cajanegra ejercitan los requisitos funcionales desde el exterior del módulo, las
de caja blanca están dirigidas a las funciones internas.
3. hacer una comparación entre las pruebas de caja negra vs pruebas de caja blanca.
Basado en el siguiente formato complete mínimo 7 comparaciones:
Caja Negra Caja Blanca
No conoce los detalles internos del programa Conoce la estructura interna del programa
4. Ejemplos de pruebas de caja negra
A continuación enumeramos los ejemplos, presentando para cada uno los datos de entrada y
resultado esperado.
Ejemplo 1: Envió de correo electrónico al
registrarse una transacción.
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 de uso
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.
Caso 1.3: Datos de entrada: Registrar factura de cliente. Resultado esperado (Salida): El sistema
envía un correo electrónico al departamento de facturación y al cliente.
Caso 1.4: Datos de entrada: Registrar cobro. Resultado esperado (Salida): El sistema envía un
correo electrónico al departamento de cuentas por cobrar y al agente comercial (vendedor) que
lleva la cuenta del cliente.
Ejemplo 2: Ingreso de pedidos de compra por
debajo y por encima de límites de aprobación.
Descripción del caso: Los pedidos de compra que excedan el monto establecido en el flujo de
liberaciones de pedidos configurados, deberán pasar por las aprobaciones establecidas en dicho
flujo de aprobación.
Técnica de pruebas de caja negra: Requerimiento funcional / Caso de uso
Caso 2.1: Datos de entrada: Pedido de compra con un monto inferior al primer límite de aprobación
configurado. Resultado esperado (Salida): El sistema registra el pedido con estatus “aprobado”.
Caso 2.2: Datos de entrada: Pedido de compra con un monto superior al primer límite de
aprobación configurado. Resultado esperado (Salida): El sistema coloca el pedido con estado
“pendiente de aprobación” y lo clasifica en la bandeja de entrada del aprobador. El aprobador
puede configurarse en el sistema (usando el nombre de usuario).
Caso 2.3: Datos de entrada: Modificar el límite de aprobación y registrar un pedido de compra con
un monto inferior al nuevo límite. Resultado esperado (Salida): El sistema registra el pedido con
estatus “aprobado”.
Caso 2.4: Datos de entrada: Modificar el límite de aprobación y registrar un pedido de compra con
un monto superior al nuevo límite. Resultado esperado (Salida): El sistema coloca el pedido con
estado “pendiente de aprobación” y lo clasifica en la bandeja de entrada del aprobador. El
aprobador puede configurarse en el sistema (usando el nombre de usuario).
Los ejemplos de casos de prueba elaborados a partir de requerimientos funcionales y casos de
uso, fueron tomados de nuestro artículo:
Ejemplo 3: Campo de texto que solo acepta
caracteres alfabéticos.
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 3.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 3.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.
Caso 3.3: Datos de entrada: cadena de 7 caracteres, solo de caracteres alfabéticos. Resultado
esperado (Salida): La aplicación permite el ingreso del dato.
Caso 3.4: Datos de entrada: cadena de 11 caracteres. Resultado esperado (Salida): La aplicación
no permite el ingreso del dato y muestra un mensaje de error.
Ejemplo 4: Campo de texto que solo acepta
caracteres alfabéticos (Análisis de valores borde).
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 4.1: Datos de entrada: cadena de 6 caracteres, sólo caracteres alfabéticos. Resultado
esperado (Salida): La aplicación permite el ingreso del dato.
Caso 4.2: Datos de entrada: cadena de 10 caracteres, sólo caracteres alfabéticos. Resultado
esperado (Salida): La aplicación permite el ingreso del dato.
Caso 4.3: Datos de entrada: cadena de 6 caracteres, con caracteres no alfabéticos. Resultado
esperado (Salida): La aplicación no permite el ingreso del dato y muestra un mensaje de error.
Caso 4.3: Datos de entrada: cadena de 10 caracteres, con caracteres no alfabéticos. Resultado
esperado (Salida): La aplicación no permite el ingreso del dato y muestra un mensaje de error.
Ejemplo 5: Ingreso de datos en un campo
numérico.
Descripción de la situación: Supongamos que tenemos una aplicación que posee una pantalla
para el ingreso de un valor numérico, como por ejemplo un monto (en alguna moneda), cuyo valor
debe estar entre 1 y 1.000. Por lo tanto, todo valor menor que 1 y mayor a 1.000 es invalido.
Técnica de pruebas de caja negra: Partición de equivalencias y análisis de valores borde.
Caso 5.1: Datos de entrada: 450. Resultado esperado (Salida): La aplicación permite el ingreso del
dato.
Caso 5.2: Datos de entrada: 1 (Valor borde). Resultado esperado (Salida): La aplicación permite el
ingreso del dato.
Caso 5.3: Datos de entrada: 1.000 (Valor borde). Resultado esperado (Salida): La aplicación
permite el ingreso del dato.
Caso 5.4: Datos de entrada: 0. Resultado esperado (Salida): La aplicación no permite el ingreso
del dato y muestra un mensaje de error.
Caso 5.5: Datos de entrada: 1.001. Resultado esperado (Salida): La aplicación no permite el
ingreso del dato y muestra un mensaje de error.
Ejemplo 6: Ingreso de un campo fecha.
Descripción de la situación: Se tiene una aplicación en la cual se registra una transacción
administrativa o de contabilidad, que posee un campo fecha. Según la especificación funcional, el
campo fecha solo acepta fecha iguales o anteriores al día actual. Es decir, el ingreso de fechas en
el futuro no está permitido.
Técnica de pruebas de caja negra: Partición de equivalencias y análisis de valores borde.
Caso 6.1: Datos de entrada: Fecha de hoy (Valor borde). Resultado esperado (Salida): Se permite
el ingreso de la transacción (mensaje de éxito).
Caso 6.2: Datos de entrada: Fecha de hoy más un día (Fecha de mañana). Resultado esperado
(Salida): No se permite el ingreso de la transacción y se muestra un mensaje de error.
Caso 6.3: Datos de entrada: Fecha del día de ayer. Resultado esperado (Salida): Se permite el
ingreso de la transacción (mensaje de éxito).
Ejemplo 7: Visualización en diversos navegadores
web.
Descripción de la situación: La pantalla de tablero Dashboard, debe poder visualizarse con los
navegadores web Chrome, Firefox e Internet Explorer.
Técnica de pruebas de caja negra: Requerimiento funcional / Caso de uso
Caso 7.1: Datos de entrada: Acceder a pantalla Dashboard desde el navegador Google Chrome.
Resultado esperado (Salida): La pantalla se visualiza correctamente y el diseño es “Responsive” a
los cambios en el tamaño de pantalla y resolución.
Caso 7.2: Datos de entrada: Acceder a pantalla Dashboard desde el navegador Internet Explorer.
Resultado esperado (Salida): La pantalla se visualiza correctamente y el diseño es “Responsive” a
los cambios en el tamaño de pantalla y resolución.
Caso 7.3: Datos de entrada: Acceder a pantalla Dashboard desde el navegador Firefox. Resultado
esperado (Salida): La pantalla se visualiza correctamente y el diseño es “Responsive” a los
cambios en el tamaño de pantalla y resolución.
Ejemplo 8: Descuento para nuevos clientes y uso
de cupones de descuento.
Descripción de la situación: Se tiene una aplicación de comercio electrónico. En la aplicación,
todo cliente que se esté registrando por primera vez en la suscripción a la membresía Premium,
recibe un 15% de descuento en su primera compra bajo el programa.
Adicionalmente, el cliente puede usar un cupón electrónico (distribuido por la empresa en diversos
medios). El descuento de 15% de primera compra y el cupón no se pueden usar simultáneamente.
Técnica de pruebas de caja negra: Tablas de decisión.
Para definir los casos de prueba, podemos usar la siguiente tabla de decisión:
Condición Regla 1 Regla 2 Regla 3
Registrado por primera vez (15%). Verdadero Falso Verdadero
Cliente usa cupón (20%). Falso Verdadero Verdadero
Resultado
Descuento 15% 20% X
Con la información de la tabla de decisión, se definen los siguientes casos de prueba:
Caso 8.1: Datos de entrada: Cliente se enrola en programa de compras Premium, no usa cupón.
Resultado esperado (Salida): El sistema asigna un descuento del 15% en la primera compra.
Caso 8.2: Datos de entrada: Cliente no se enrola en programa de compras Premium, usa cupón.
Resultado esperado (Salida): El sistema asigna un descuento del 20% en la compra.
Caso 8.3: Datos de entrada: Cliente se enrola en programa de compras Premium, usa cupón..
Resultado esperado (Salida): El sistema no permite asignar el cupón y por ende no procede la
transacción.
Requerimientos no funcionales
Ejemplo 9: Capacidad de procesamiento del
sistema.
Descripción de la situación: El sistema debe ser capaz de procesar N transacciones por
segundo. Esto se medirá por medio de la herramienta.
Técnica de pruebas de caja negra: Prueba no funcional.
Caso 9.1: Datos de entrada: Utilizar SoapUI para simular una cantidad de transacciones inferior al
límite establecido. Resultado esperado (Salida): Las transacciones son procesadas
adecuadamente y sin error por la aplicación.
Caso 9.2: Datos de entrada: Utilizar SoapUI para simular una cantidad de transacciones superior al
límite establecido. Resultado esperado (Salida): Al llegar al límite de su capacidad funcional, el
sistema colapsa o se inhibe, esto no necesariamente ocurre en el umbral establecido, sino que
puede ocurrir a un valor superior. Nunca debe ocurrir en un valor de transacciones por segundo
inferior al umbral.
Ejemplo 10: Usuarios concurrentes en el sistema.
Descripción de la situación: El sistema debe ser capaz de operar adecuadamente con hasta
100.000 usuarios con sesiones concurrentes.
Técnica de pruebas de caja negra: Prueba no funcional.
Caso 9.1: Datos de entrada: Utilizar SoapUI para simular menos de 100 mil sesiones concurrentes.
Resultado esperado (Salida): Las sesiones son procesadas adecuadamente y sin error por la
aplicación.
Caso 9.2: Datos de entrada: Utilizar SoapUI para simular más de 100 mil sesiones concurrentes.
Resultado esperado (Salida): Al llegar al límite de su capacidad funcional, el sistema colapsa o se
inhibe, esto no necesariamente ocurre en el umbral establecido, sino que puede ocurrir a un valor
superior. Nunca debe ocurrir en un valor de transacciones por segundo inferior al umbral.
Ejercicios ejemplo caja negra
