Pruebas de software
Testing de software – Pruebas dinámicas
OBJETIVOS DE LAS PRUEBAS
• La prueba es un proceso de ejecución de un programa con la
intención de descubrir un error (no busca “no encontrar errores”
sino “sí encontrar errores”)
• Un buen caso de prueba es aquel que tiene una alta probabilidad
de descubrir un error no descubierto hasta entonces
• Una prueba tiene éxito si descubre un error no detectado hasta
entonces
Verificación y validación
Inspecciones vs pruebas
• Inspección:
• Técnicas estáticas: no se necesita ejecutar sw
• Pruebas:
• Técnicas dinámicas: ejecución del software
Inspecciones
• Analizan y comprueban las representaciones del sistema (ERS,
modelos, código fuente)
• En todas las etapas del proceso
• No se necesita ejecutar software
• Localizan defectos de datos, controles, interfaz. Detectan
anomalías como código no utilizado, variables sin inicializar, etc.
PRUEBAS
• Implican ejecutar una implementación del sw con datos de prueba
• Se examinan salidas del software y entorno operacional
EQUIVOCACION / DEFECTO / FALLA
• Equivocación
• Una acción humana que produce un resultado incorrecto
• Defecto
• Paso, proceso o definición de dato incorrecto
• Ausencia de cierta características
• Falla
• Resultado de ejecución incorrecto. Es el resultado obtenido y distinto al
resultado esperado.
EQUIVOCACION / DEFECTO / FALLA
• Una equivocación llega a uno o más defectos, que están presentes
en el código
• Un defecto lleva a cero, una o más fallas
• La falla es la manifestación del defecto
• Una falla tiene que ver con uno o más defectos
CASOS DE PRUEBA
• Concepto de casos de prueba
• ¿Quién define los casos de prueba?
• ¿Quién los ejecuta?
• Importancia de los datos de prueba, preparación de lotes, etc.
Tipos de pruebas
PRUEBAS DE UNIDAD
• Pruebas de unidad: componentes individuales
• Objetivo: encontrar defectos en componentes (funciones, clases,
otros componentes)
• Diseñar las pruebas que incluyan
• Pruebas aisladas de todas las operaciones asociadas con el objeto
• Asignación y consulta de todos los atributos asociados con el objeto
• Ejecutar el objeto en todos sus posibles estados
SMOKE TEST
• Test inicial. Se realiza al comienzo del proceso de pruebas.
• El tiempo de ejecución del smoke test completo debe ser corto.
Los casos por lo general son positivos y lo que se espera encontrar
es problemas en el proceso de despliegue (deploy) o que algún
caso de uso clave en las pruebas, tiene algún problema que no
podrá realizarse una prueba completa
• Busca asegurar que la funcionalidad básica del software funciona
correctamente
• Sirve para quedarnos tranquilos que “por arriba” los casos de uso
principales van a poder ser testeados.
Pruebas del sistema (integración)
• Integrar dos o mas componentes y probar el sistema integrado
• Comprobar
• Componentes funcionan juntos
• Llamados correctamente
• Transfieren datos correctos
• Incluir pruebas de rendimiento (estrés) e interfaz entre
componentes
PRUEBAS DE REGRESIÓN
Pruebas de Errores
integración
Corrección
Pruebas de Cambian aspectos de la
regresión configuración del sw
No introducir comportamiento
indeseable o errores adicionales
PRUEBAS DE ACEPTACIÓN (Uat)
• Denominado UAT (User Acceptance Testing)
• Este tipo de pruebas debe ser realizado por el cliente para quien
fue desarrollado el cambio o producto.
• Son básicamente pruebas funcionales, sobre el sistema completo,
y buscan una cobertura de la especificación de los requisitos y del
manual del usuario.
• Estas pruebas nunca deben realizan durante el desarrollo o
testing, pues sería impresentable al cliente; sino que se realizan
sobre el producto terminado
Generación de casos de prueba
Técnicas básicas
Generación de casos de prueba
• Condiciones de borde
• Tipos de datos
• Tamaños de datos
• Conjunto de valores
• Datos obligatorios
Condiciones de borde
• Se utiliza en el caso de campos que aceptan valores numéricos.
• Se deben identificar los intervalos válidos y los inválidos. Por
ejemplo, si la edad puede estar comprendida entre 18 y 25 años,
ambos incluidos, entonces:
• Intervalo válidos: [18,25]
• Intervalos inválidos: (-∞,18) y (25,+ ∞)
TIPOS DE DATOS
• Todo dato que deseamos probar tiene definido un tipo de dato
específico, ya sea un número, un texto, etc.
• Debe probarse qué pasa cuando a un valor se le carga cada uno de los
siguientes tipos de datos:
• Número entero
• Número decimal
• Número negativo
• Texto
• Alfanumérico
• Signos o símbolos
TAMAÑO DE DATOS
• Para el caso de los campos de texto debe verificarse que el
tamaño ingresado es el correcto.
• Por ejemplo si tenemos un campo Nombre que acepta 20
caracteres, deberíamos verificar qué pasa si el usuario ingresa 21
caracteres.
• Entonces deberíamos generar casos de prueba para cada una de
las posibilidades:
• Nombre de tamaño 20
• Nombre de tamaño 21
CONJUNTO DE VALORES (DOMINIO)
• Algunos campo tienen una cantidad acotada de valores posibles. Por
ejemplo, el campo Sexo tendrá Masculino y Femenino.
• Entonces deberíamos generar casos de prueba para cada una de las
posibilidades:
• Sexo válido: Masculino
• Sexo inválido: JJ
• No debe olvidar también algunos dominios como los existentes en el
email: un correo electrónico debe tener un carácter @ y un carácter .
luego de la arroba
Datos obligatorios
• Debe probarse que los datos obligatorios se encuentren realmente
completados
• Para cada uno de esos datos obligatorios debe generarse un caso
de prueba con el dato vacío y otro caso de prueba con el dato con
sólo espacios
RELACIÓN ENTRE DATOS
• Una vez que se probaron cada uno de los datos debe verificarse la
relación entre ellos.
• Por ejemplo, si puede elegir Tipo de Pago y elije Tarjeta, entonces
debe ingresar el numero de la tarjeta
• Del caso anterior se deriva un caso de prueba:
• Tipo de pago = Tarjeta y Sin nro tarjeta ingresada
Generación de casos de prueba
Complejidad ciclomática
Complejidad ciclomática
• Tiene su origen en el paradigma imperativo
• Aplicable en programación orientada a objetos con ciertas
particularidades y consideraciones
Complejidad ciclomática
• La Complejidad Ciclomática (Cyclomatic Complexity) es una métrica del
software que proporciona una medición cuantitativa de la complejidad lógica de
un programa. Es una de las métricas de software mas ampliamente aceptada, ya
que ha sido concebida para ser independiente del lenguaje.
• Esta métrica, propuesta por Thomas McCabe en 1976, se basa en el diagrama de
flujo determinado por las estructuras de control de un determinado código. De
dicho análisis se puede obtener una medida cuantitativa de la dificultad de de
crear pruebas automáticas del código y también es una medición orientativa de
la fiabilidad del mismo.
• Fuente: [Link]
Complejidad ciclomática
• Grafos de flujos:
• Nodos (N): cada uno de los círculos
• Aristas (A): cada una de las líneas
• Complejidad ciclomática (CC) = A – N + 2
Ejemplo 1
• N=5
• A=7
• Complejidad Ciclomática
• CC = A – N + 2
• CC = 7 – 5 + 2
• CC = 4
Ejemplo 2
• El software corresponde a un colegio que está inscribiendo
alumnos para el próximo año
• Se verifica si la primera letra del nombre del alumno es posterior
aP
• Si es posterior se genera un ticket que el alumno debe llevar a la
Oficina de Inscripciones
• Si es anterior (o igual) a P debe cargarse una solicitud de permiso
especial. Esta solicitud debe ser aprobada por el jefe. Si el jefe la
aprueba entonces se genera el ticket para Oficina de
Inscripciones, sino se rechaza su inscripción.
EJEMPLO 2
• Si primera letra es posterior a P
• (Por SI) Generar Ticket
• (Por NO) Cargar Solicitud Permiso
• ¿Jefe aprueba?
• (Por SI) Generar Ticket
• (Por NO) Rechazar Inscripción
• N=8
• A=9
• Complejidad ciclomática
• CC = A – N + 2
• CC = 9 – 8 + 2
• CC = 3
CASOS DE PRUEBA
• Se debe definir por lo menos un caso de prueba para cada uno de
los caminos existentes en el grafo.
• La cantidad de caminos del grafo es la complejidad ciclomática
