You are on page 1of 45

Pruebas Funcionales

Sesión 07
Ing. Henry Joe Wong Urquiza
pcsihewo@upc.edu.pe
Agenda

• Logro
• Introducción
• Pruebas en base a requerimientos
• Pruebas Funcionales
• Diseño de Casos de Pruebas
• Herramientas para las pruebas funcionales
• Conclusiones
LOGRO
Logro

El estudiante al finalizar la
unidad realiza pruebas
funcionales en base a
requerimiento usando
herramientas CASE en
plataformas .NET y Java.
INTRODUCCIÓN
Caja Blanca

Entrada Salida
Caja Negra

Entrada Salida
Pruebas de C.B. y C.N.

2-64 chars.
Nombre del cliente
Número de cuenta 6 digits, 1st
non-zero
Monto del préstamo
Solicitado £500 to £9000
Plazo del préstamo
Cuota mensual 1 to 30 years

Minimum £10
Plazo:
Reembolso:
Tasa de interés:
Total pagado:
Pruebas de C.B. y C.N.
Nombre del cliente
Número de caracteres:

1 2 64 65
no valido valido No valido
Caracteres válidos: A-Z
Cualquier
-’ a-z
space otro
Condiciones Particiones Particiones Límites Límites no
válidas no válidas válidos válidos
Nombre del 2 a 64 chars < 2 chars 2 chars 1 chars
cliente > 64 chars 64 chars 65 chars
valid chars invalid chars 0 chars
Pruebas de C.B. y C.N.
Número de Cuenta
válido: non-zero
Primer caracter:
No válido: zero

Número de dígitos:
5 6 7
No válido No válido
válido

Condiciones Particiones Particiones no Límites Límites no


válidas válidas válidos válidos
Número de 6 digits < 6 digits 100000 5 digits
st
Cuenta 1 non-zero > 6 digits 999999 7 digits
1st digit = 0 0 digits
non-digit
Pruebas de C.B. y C.N.
Monto del Préstamo

499 500 9000 9001

No válido válido No válido

Condiciones Particiones Particiones Límites Límites no


válidas no válidas válidos válidos
Monto del 500 - 9000 < 500 500 499
préstamo >9000 9000 9001
0
non-numeric
null
Pruebas de C.B. y C.N.

Plantilla de Condiciones

Condiciones Particiones Tag Particiones Tag Límites Tag Límites no Tag


válidas no válidas válidos válidos
Nombre de 2 - 64 V1 < 2 chars X1 2 chars B1 1 char D1
Cliente chars V2> 64 chars X2 64 chars B2 65 chars D2
valid chars invalid char X3 0 chars D3
Número de 6 digits V3 < 6 digits X4 100000 B3 5 digits D4
st
cuenta 1 non- V4 > 6 digits X5 999999 B4 7 digits D5
zero 1st digit = 0 X6 0 digits D6
non-digit X7
Monto de 500 - 9000 V5 < 500 X8 500 B5 499 D7
préstamo >9000 X9 9000 B6 9001 D8
0 X10
non-integer X11
null X12
Pruebas de C.B. y C.N.

Diseño de Casos de Pruebas

Caso New Tags


Descripción Resultado Esperado
Prueba Covered
1 Name: John Smith Term: 3 years V1, V2,
Acc no: 123456 Repayment: 79.86 V3, V4,
Loan: 2500 Interest rate: 10% V5 .....
Term: 3 years Total paid: 2874.96

2 Name: AB Term: 1 year B1, B3,


Acc no: 100000 Repayment: 44.80 B5, .....
Loan: 500 Interest rate: 7.5%
Term: 1 year Total paid: 537.60
PRUEBAS EN BASE A
REQUERIMIENTOS
Pruebas en base a requerimientos

• Los requerimientos deben ser escritos de tal manera


que de ellos se puede generar los casos de pruebas.
• Las pruebas basadas en requerimientos son una
aproximación sistemática al diseño de casos de
pruebas donde el usuario acepto que cada
requerimiento es lo que pidió.
• Este tipo de pruebas son pruebas de validación en
lugar de pruebas de defectos, porque el tester
intenta demostrar que el sistema tiene
implementado todo lo que pidió
PRUEBAS FUNCIONALES
Pruebas Funcionales

• Validan que la aplicación funcione como está


especificada
• Pruebas basadas en casos de uso y escenarios de
negocios
• Desde el punto de vista del usuario final (caja-negra)
• Pueden automatizarse usando scripts o herramientas
como Rational Funcional Tester o Microsoft Visual
Studio 2008 Test Edition
Pruebas Funcionales

• Se enfocan en tres tipos fundamentales

Módulo • Requerimientos específicos al módulo


Independiente • Basadas en casos de uso individuales

• Requerimientos que cubren varios


Integración de módulos
Módulos
• Basadas en casos de uso más complejos

• Escenarios complejos con distintos


Escenarios de actores
Negocios
• Cubren varios casos de uso
Módulo Independiente
• Un módulo es una unidad mediana o grande de programación.
• Es más grande que un método o clase e inclusivamente que una
librería.
• Por ejemplo, aplicaciones bancarias pueden incluir los siguientes
dos:
• Ventanilla: maneja las cuentas de los clientes desde ventanilla
• Web: maneja las cuentas de los clientes desde la Web
• Una aplicación de terminal de exportación incluiría los siguientes :
• Terminal: maneja los proceso y servicios del terminal
• Comercial: maneja las cobranzas y los comprobantes de pago
• Seguridad: permite crear y modificar usuarios y clientes de la
aplicación
Integración de Módulos
• Una prueba de integración involucra uno o más módulos.
• Por ejemplo, en una aplicación de escritorio para acceder
inventarios se es necesario tener credenciales (una cuenta de
usuario y contraseña). La aplicación es diseñada usando dos
módulos:
• Inventarios
• Seguridad
• Las pruebas de integración cubren interacción de dos o tres
módulos aproximadamente
• Por ejemplo, crear un usuario que ingrese a la aplicación y
acceda a un inventario.
Escenarios de Negocios
• Cubren escenarios de uso complejos, involucrando comúnmente a
más de un actor.
• Cubre gran funcionalidad de la aplicación (implementación de
punta-a-punta) usando variedad de opciones, formularios,
usurarios, comunicaciones y otras opciones operativas.
• Características de un buen escenario de negocios:
• Motivador
• ¿Por qué es importante?
• Creíble
• Complejo
• Nos trae al poder
12 Formas de Escribir Escenarios de
Negocios

• En grupo realizar la lectura del PDF


recomendado y realizar presentación
resumen.
http://www.kaner.com/pdfs/ScenarioIntroVer4.
pdf
DISEÑO DE CASOS DE
PRUEBAS
Diseño de Casos de Pruebas

• El diseño de los casos de pruebas son una parte de


las Pruebas de Sistemas, que es la herramienta
básica para realizar las pruebas de una aplicación.
• Se tiene que especificar correctamente los valores de
entrada para saber cuales serán los valores
esperados.
• Para diseñar un caso de prueba, se tiene que
seleccionar un modulo o característica del sistema ha
probar. En función ha eso se genera la suite de datos.
Diseño de Casos de Pruebas

Datos de Informe de
• Diseñar Casos de Pruebas • Ejecutar el Pruebas
Pruebas • Preparar datos de Programa con los • Comparar
Pruebas datos de Pruebas resultados
esperados con los
valores obtenidos
Casos de Resultados de
Pruebas las Pruebas
HERRAMIENTAS PARA LAS
PRUEBAS FUNCIONALES
¿Como realizar un enfoque ágil para Pruebas
Automatizadas?

• Necesitamos un entorno altamente colaborativo.


Equipos multidisciplinares, capaces de producir
incrementos y mejoras en el software con la calidad
esperada. En un equipo hay gente de distinto tipo:
– Una parte técnica (distintos perfiles de desarrollo, sistemas etc.).
– Una parte de negocio (Product Owner).
– Los testers, están entre la parte técnica y la de negocio. Ayudan por
un lado a la parte de negocio a traducir lo que el cliente quiere en
pruebas, que será lo que debe cumplir el software, lo que en
definitiva tienen que implementar los desarrolladores.
¿Como realizar un enfoque ágil para Pruebas
Automatizadas?

• Si los programadores termina de implementar algo,


pero el Product Owner no da el visto bueno,
realmente la funcionalidad no está terminada.
• Lo mismo, si QA no da la conformidad a la tarea.
• Si desarrollo espera feedback por parte de QA y no
se lo da, tampoco es agilidad.

Testers, Programadores, Product Owner…Son un equipo con un objetivo común


Pruebas Automatizadas para las
metodologías agiles

• Un equipo de testing le es muy dificultoso realizar


pruebas de regresión, cada vez que los
programadores realizan una integración se genera
un proceso muy lento y pesado
• Es por eso que debemos de poder balancear entre
pruebas manuales y automatizadas
• Un conjunto de pruebas automatizadas va a permitir
validar mi producto de manera mas rápida, acá es
donde se debe de aplicar una plataforma de
Integración Continua
Automatizar Pruebas no significa que eliminemos las
Pruebas Manuales

• Las pruebas que se suelen automatizar podríamos


considerarlas verificaciones: una máquina no piensa
• Automatizar las pruebas va a facilitarle el trabajo a
los testers, en el sentido de que pueden dedicarse al
testing de verdad, nuevo, que vaya aportando valor
en cada iteración:
– Testeo de nuevas funcionalidades,
– Búsqueda de errores más difíciles de encontrar,
– Probar nuevas casuísticas
Las Pruebas Automatizadas
ayudan al equipo de
Desarrolladores
Para el mes que
viene estará todo
automatizado,
¿no?
¡Ah, genial! Si
automatizamos las
pruebas…¡Nos
ahorraremos a los
testers manuales!
¡Sí, automaticemos
pruebas! Tú enséñanos
a automatizar pruebas
con eso de Selenium ,
que le das al botoncito,
tocas cuatro cosas y
vas grabando lo que
haces.
¿Por dónde empezamos a automatizar?

• Dentro de lo que es el testing, existen distintos tipos de


pruebas, cada una orientada a detectar y prevenir ciertos
tipos de errores en el software
• Lo primero que pensamos en automatizar son las pruebas del
tipo “record & play”, por ejemplo con Selenium IDE.
• La automatización de pruebas funcionales no lo es
todo, porque la interfaz de usuario es la parte más propensa
a cambios de toda la aplicación, y para automatizar pruebas y
tener fiabilidad sobre lo que estamos ejecutando
necesitamos cierta estabilidad
¿Por dónde empezamos a automatizar?

• La automatización de pruebas se tiene que


hacer de manera incremental, desde pruebas
unitarias hasta pruebas integrales
¿Cuándo automatizar?

• El aspecto primordial que permite determinar


si es mejor o no automatizar responde a la
pregunta: “¿cada cuánto hacemos nuevas
versiones de nuestro software?”.
¿Cuándo automatizar?

• Hay determinados casos en los que por más


que nos empeñemos deberemos realizar la
prueba manualmente, pues la automatización
puede ser técnicamente compleja.
Cuadrantes del Testing Ágil
Pirámide de Cohn
Pirámide de Cohn

• Muchos test unitarios automatizados, porque


de esa manera validamos que los métodos se
encuentren estables
• Bastantes tests a nivel de API, integración de
componentes, servicios, que son los más
estables y candidatos a automatizar.
• Menos test de interfaces graficas
Pirámide de Cohn y Cuadrante del Testing
Agil
CONCLUSIONES
Conclusiones

• Validan que la aplicación funcione como están


especificadas en los casos de uso que fueron
tomados de los clientes.
Gracias!

Ing. Henry Joe Wong Urquiza


Docente UPC
E-Mail: pcsihewo@upc.edu.pe
Gtalk: hwongu@gmail.com
Facebook: facebook.com/HenryJoeWongUrquiza
Blog Personal: programandoconcafe.com
Linkedin: pe.linkedin.com/in/hwongu
Google Plus: gplus.to/hwongu
Twitter: @hwongu
Skype: hwongu

You might also like