UNIDAD Nº: 4 Pruebas o Inspecciones

dinámicas relacionados a ISTQB

Partición Equivalente
Tipos de Pruebas y Niveles de Pruebas
 Agenda

• Introducción
– Particiones equivalentes
– Valores límites
• Pruebas Funcionales
• Pruebas de Regresión
• Niveles de Prueba
• Pruebas de Sistemas
• Pruebas de Aceptacion
• Conclusiones
INTRODUCCIÓN
PARTICIONES
EQUIVALENTES
Particiones Equivalentes

– dividir (partición) de las entradas, salidas, etc en zonas

que son iguales (equivalentes)
– hipótesis: si un valor funciona, todo funciona
– una de cada partición mejor que todas de una
No válido válido No válido

0 1 100 101
Particiones Equivalentes

• Ejemplo:
– Aplicación toma números enteros de dos dígitos (A y B)
– Suma el resultado de A + B
• Posibles valores de A y B de -99 a 99.
• Posibles combinaciones de pruebas son 199 x 199 =
39601.
• No es posible ejecutar todos las pruebas posibles.
• Debemos encontrar pruebas efectivas que
representen al resto.
Particiones Equivalentes

Variable Partición Partición Casos límite y Notas

Equivalente - Equivalente - especiales
Caso Válido Caso Inválido
A -99 a 99 > 99 99, 100
< -99 -99, -100

B -99 a 99 > 99 99, 100

< -99 -99, -100

Suma -198 a 198 > 198 (-99,-99) No se conoce

< -198 (-99,99) como probar
(99,-99) partición de
(99,99) caso inválido
Valores Limites

• fallas tienden a esconderse cerca de las fronteras

• buen lugar para buscar las faltas
• los valores de prueba en ambos lados de los límites

No válido válido No válido

0 1 100 101
Ejemplo Particiones Equivalentes

• rangos numéricos.
• códigos de caracteres.
• tamaño de variables (pensar binario y dígitos).
• longitud de cadena concatenada.
• tamaño de un archivo.
• número de acciones (ventanas abiertas, repeticiones de
ejecución).
• periodos de tiempo.
PRUEBAS
FUNCIONALES
Pruebas Funcionales

• Una prueba funcional es una prueba basada en la

ejecución, revisión y retroalimentación de las
funcionalidades previamente diseñadas para
el software. La pruebas funcionales se hacen
mediante el diseño de modelos de prueba que
buscan evaluar cada una de las opciones con las que
cuenta el paquete informático.
Pruebas basadas en escenarios

• Los escenarios reflejan casos del uso real del

software.
• Los escenarios son desarrollados desde el punto de
vista de usuarios experimentados. Deben reflejar
interacciones complejas y reales.
• Basadas en: entrevistas a los stekeholders, casos de
uso, historias de usuarios y guiones.
• Se utilizan instancias de uno o más casos de uso para
probar algo útil, interesante y complejo de la
aplicación.
Pruebas basadas en escenarios

• Bosquejo de un Caso de uso

• Tiene normalmente un flujo básico (“Camino feliz”)
• Varios flujos alternativos
– Variantes regulares
– Casos extraños
– Flujos Excepcionales manejo de situaciones de error

“Camino feliz”
Pasos para identificar los escenarios de los casos de
uso

• A partir de la especificación del caso de uso se

elabora el grafo de flujo de eventos.
• Utilizando el grafo de flujo de eventos se determina
la complejidad ciclomática (CAMINOS QUE TIENES
QUE PROBAR)del caso de uso.
• Los caminos independientes determinan un
conjunto posible de escenarios para desarrollar las
pruebas.
Casos de Uso: Retirar Dinero

• Flujo Básico
1. Permite retirar dinero
• Flujos Alternativos
1. Insuficiente dinero en el cajero.
2. Monto a retirar excede el saldo de la cuenta.
3. Monto a retirar excede del monto máximo de
retiro.
4. Cliente sobrepasó el monto máximo de retiro
diario en una cuenta.
Escenario: Retiro de dinero exitoso

• El cliente inserta la tarjeta.

• El sistema lee la banda magnética de la tarjeta.
• El cliente ingresa su PIN.
• El sistema valida el PIN.
• El sistema solicita el tipo de transacción.
• El cliente selecciona “retiro de dinero”.
• El cliente Ingresa el monto a retirar.
• El sistema verificar existencia de dinero en el cajero y en la
cuenta del cliente.
• El sistema solicita autorización al banco.
• El sistema entrega: el dinero, el recibo y la tarjeta.
 Casos de Pruebas: Retiro Exitoso

Escenario/ Tarjeta / PIN Monto a Saldo en Dinero en Número Resultado

Condición Lectora Retirar la cuenta el cajero de esperado
cuenta
Retiro Exitoso 123456 2501 500 2500 10000 4585-4578 Saldo Cuenta
= 2000
Escenario: Insuficiente dinero en el
Cajero
El cliente inserta la tarjeta.
El sistema lee la banda magnética de la tarjeta.
El cliente ingresa su PIN.
El sistema valida el PIN.
El sistema solicita el tipo de transacción.
El cliente selecciona “retiro de dinero”.
El cliente Ingresa el monto a retirar.
El sistema verificar existencia de dinero en el cajero y en la
cuenta del cliente.
El sistema muestra un mensaje de advertencia.
El cliente selecciona cancelar.
 Casos de Pruebas: Insuficiente dinero en el
Cajero

Escenario/ Tarjeta / PIN Monto Saldo en Dinero Número Resultado

Condición Lectora ingresado la en el de cuenta esperado
cuenta cajero

Retiro Exitoso 123456 2501 500 2500 10000 4585-4578 Saldo Cuenta
= 2000

Cajero sin 654321 3050 2100 2500 2000 4687-4754 Mensaje:

fondos “Cajero sin
fondos”
Escenario: Monto Retirar Excede el
Saldo de la Cuenta
• El cliente inserta la tarjeta.
• El sistema lee la banda magnética de la tarjeta.
• El cliente ingresa su PIN.
• El sistema valida el PIN.
• El sistema solicita el tipo de transacción.
• El cliente selecciona “retiro de dinero”.
• El cliente Ingresa el monto a retirar.
• El sistema verificar existencia de dinero en el cajero y en la
cuenta del cliente.
• El sistema muestra un mensaje de advertencia.
• El cliente selecciona cancelar.
 Casos de Pruebas: Monto a Retirar Excede el saldo de la
cuenta

Escenario/ Tarjeta / PIN Monto Saldo en Dinero Número Resultado

Condición Lectora ingresado la cuenta en el de esperado
cajero cuenta

Retiro Exitoso 123456 2501 500 2500 10000 4585-4578 Saldo Cuenta
= 2000

Cajero sin 654321 2000 2500 2000 4687-4754 Mensaje:

fondos 3050 “Cajero sin
fondos”

Monto a retirar 457891 4578 1000 450 10000 8579-78914 Mensaje:

excede el saldo “Monto a
de la cuenta retirar excede
el saldo de la
cuenta”
Caso de Prueba: Cargo por retiro

• Si el retiro es mayor a $2000, se cobrará un cargo de $2

Descripción Otra información Resultado

Esperado

Retiro < $2000 Válida No se cobra cargo

Retiro > $2000 Válida Se cobra cargo

Retiro = $2000 Válida No se cobra cargo

Caso de Prueba: Impresión de Recibo

• Cuando el cajero no puede imprimir un recibo (falta de papel, etc.)

emitirá un mensaje adicional preguntándole al cliente si continua o
cancela la transacción

Descripción Otra información Resultado

Esperado

Retiro normal con recibo Válida Normal + recibo

Sin recibo – Falta de Válida Aviso sin recibo

papel

Sin recibo – Impresora Válida Aviso sin recibo

atascada
PRUEBAS DE
REGRESIÓN
Pruebas Regresión

• Se denominan Pruebas de regresión a cualquier tipo

de pruebas de software que intentan descubrir las
causas de nuevos errores, carencias de
funcionalidad, o divergencias funcionales con
respecto al comportamiento esperado del software,
inducidos por cambios recientemente realizados en
partes de la aplicación que anteriormente al citado
cambio no eran propensas a este tipo de error. Esto
implica que el error tratado se reproduce como
consecuencia inesperada del citado cambio en el
programa.
Tipos de Pruebas Regresión

• Clasificación de ámbito
– Local - los cambios introducen nuevos errores.
– Desenmascarada - los cambios revelan errores previos.
– Remota - Los cambios vinculan algunas partes del
programa (módulo) e introducen errores en ella.
• Clasificación temporal
– Nueva característica - los cambios realizados con respecto
a nuevas funcionalidades en la versión introducen errores
en otras novedades en la misma versión del software.
– Característica preexistente - los cambios realizados con
respecto a nuevas funcionalidades introducen errores en
funcionalidad existente de previas versiones.
NIVELES DE PRUEBA
Niveles de Pruebas
Pruebas Unitarias

• Evalúa el correcto funcionamiento de un módulo (función)

de código). Esto puede implicar

• https://www.youtube.com/watch?v=hWeKICBQuOk
Características de Pruebas Unitarias

• Características
– Automatizable
– Completas
– Reutilizables
– Independientes
 Si todos funcionan bien
¿Por qué dudar de que no
funcionen todos juntos?”
Pruebas Integración

• La prueba de Integración es una técnica

sistemática para construir la estructura del programa
mientras que al mismo tiempo, se llevan a cabo
pruebas para detectar errores asociados con la
interacción.
• Se realizan dentro del ámbito de desarrollo de
software y posterior a las pruebas unitarias.
• Se pruebas varios elementos unitarios que participan
en un proceso.
PRUEBAS DE
SISTEMAS
Pruebas Sistemas

• Buscan probar a la aplicación (o sistema) como un

todo.
• Están basadas en requerimiento (funcionales y no
funcionales).
• Se realizaran dentro del ámbito de testing.
Pruebas Sistemas

• Un problema típico es la «delegación de

culpabilidad», esto ocurre cuando se descubre un
error y cada uno de los creadores de cada elemento
del sistema echa la culpa del problema a los otros. Se
debe anticipar a los posibles problemas y:
– diseñar caminos de manejo de errores que prueben toda la información procedente de
los elementos del sistema;
– llevar a cabo una serie de pruebas que simulen la presencia de datos en mal estado o de
otros posibles errores en la interfaz del software;
– registrar los resultados de las pruebas como «evidencia» en el caso de que se le señale
con el dedo;
– participar en la planificación y el diseño de pruebas del sistema para asegurarse de que
el software se prueba de forma adecuada.
PRUEBAS DE
ACEPTACIÓN
Pruebas de Aceptación

• Estas pruebas las realiza el cliente. Son básicamente

pruebas funcionales, sobre el sistema completo, y
buscan una cobertura de la especificación de
requisitos y del manual del usuario. Estas pruebas no
se realizan durante el desarrollo, pues sería
impresentable al cliente; sino que se realizan sobre el
producto terminado e integrado o pudiera ser una
versión del producto o una iteración funcionad
pactada previamente con el cliente.
CONCLUSIONES
Conclusiones
Gracias!