Las pruebas de caja negra, es una técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software.
En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del sistema, sin preocuparnos en tener conocimiento de la estructura interna del programa de software. Para obtener el detalle de cuáles deben ser esas entradas y salidas, nos basamos únicamente en los requerimientos de software y especificaciones funcionales.
En este artículo, te presentamos ejemplos de cómo definir pruebas de caja negra, para esto, usaremos casos tanto de requerimientos funcionales y como no funcionales de software.
Inicia tu viaje en QA hoy con el curso Software Testing desde cero : MasterClass todo en 1 🚀🎯 en Udemy. Domina pruebas ágiles, APIs, y automatización. ¡No esperes más, inscríbete ahora!
PMOInformatica presenta: Ejemplos de pruebas de caja negra.
Tal como vimos en nuestro artículo sobre la definición de pruebas de caja negra según el ISTQB, existen distintas técnicas para realizar pruebas de caja negra de software, te sugerimos revisar el artículo para obtener información general sobre que son las pruebas de caja negra.
A continuación enumeramos los ejemplos, presentando para cada uno los datos de entrada y resultado esperado.
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.
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:
> Ejemplos de requerimientos funcionales de software
También Visita nuestra página de Recursos en Pruebas de Software
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.
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.
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.
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).
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.
Domina el mundo del QA con el Curso completo de la certificación QA - ISTQB Foundation Level.
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.
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.
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.
Los ejemplos de casos de prueba elaborados a partir de requerimientos no funcionales, fueron tomados de nuestro artículo:
> Ejemplos de requerimientos no funcionales de software
> Requerimientos funcionales de un sistema de ventas
> Ejemplos de requerimientos funcionales
¿Has implementado pruebas de caja negra en tu organización?, ¿Cuáles técnicas de pruebas de caja negra has aplicado y como te han resultado?
¿Quieres obtener completamente gratis y directamente plantillas, artículos y otros recursos de pruebas de software?, entonces siguenos en nuestras redes sociales:
PMOInformatica presenta: Ejemplos de pruebas de caja negra.
Las técnicas de pruebas de caja negra
Tal como vimos en nuestro artículo sobre la definición de pruebas de caja negra según el ISTQB, existen distintas técnicas para realizar pruebas de caja negra de software, te sugerimos revisar el artículo para obtener información general sobre que son las pruebas de caja negra.
> Las pruebas de caja negra según el ISTQB
Al estar basadas en los requerimientos de software y en las entradas y salidas de cada funcionalidad, al definir una prueba de caja negra lo principal es identificar los datos de prueba (entradas) y el resultado esperado del sistema al ingresar esos datos, bien sean los datos de salida o algún comportamiento específico.
Los ejemplos de pruebas de caja negra que presentamos, siguen el formato de nuestra plantilla para el diseño de casos de prueba, que puedes descargar en el siguiente enlace:
> Plantilla de casos de prueba
Al estar basadas en los requerimientos de software y en las entradas y salidas de cada funcionalidad, al definir una prueba de caja negra lo principal es identificar los datos de prueba (entradas) y el resultado esperado del sistema al ingresar esos datos, bien sean los datos de salida o algún comportamiento específico.
Formato para el registro de los casos de prueba
Los ejemplos de pruebas de caja negra que presentamos, siguen el formato de nuestra plantilla para el diseño de casos de prueba, que puedes descargar en el siguiente enlace:
> Plantilla de casos de prueba
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:
> Ejemplos de requerimientos funcionales de software
Conviértete en experto en testing
Software Testing desde cero : MasterClass todo en 1 (2024)
Emprende tu viaje hacia una exitosa carrera en QA. Aprenderás desde cero sobre pruebas ágiles, APIs, y automatización con herramientas líderes en la industria como Selenium y Cypress.
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.
Certifícate en ISTQB
ISTQB Certified Tester Foundation Level (CTFL 4.0)
Domina el mundo del QA con el Curso completo de la certificación QA - ISTQB Foundation Level.
Prepárate para triunfar con prácticas intensivas + un Examen de prueba.
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.
Los ejemplos de casos de prueba elaborados a partir de requerimientos no funcionales, fueron tomados de nuestro artículo:
> Ejemplos de requerimientos no funcionales de software
Ejemplos de como definir requerimientos funcionales
> Requerimientos funcionales de un sistema de ventas
> Ejemplos de requerimientos funcionales
¿Y qué opinas tú?
¿Has implementado pruebas de caja negra en tu organización?, ¿Cuáles técnicas de pruebas de caja negra has aplicado y como te han resultado?
¿Buscas más información de pruebas de software?
¿Quieres obtener completamente gratis y directamente plantillas, artículos y otros recursos de pruebas de software?, entonces siguenos en nuestras redes sociales:
No hay comentarios :
Publicar un comentario