Embed Size (px)
DESCRIPTION
Citation preview
GESTIÓN DE PRUEBAS
EN DESARROLLO SOFTWARE
25 de octubre de 2011 – Facultade de Informática
Agenda
I. ¿Qué software necesita pruebas?
II.¿Qué pruebas necesita mi software?
III.¿Cómo hago pruebas a mi software?
[pausa]
Taller de pruebas software
I. ¿Qué software necesita pruebas?
¿Qué sabemos de las pruebas software?
● ¿Para qué sirven?● ¿Cómo se hacen?● ¿Cuándo se hacen?● ¿Quién las hace?
¿Qué es un bug?
El software...● NO hace algo que debería● Hace algo que NO debería● Hace algo que NO dice su especificación● Hace algo que su especificación NO dice,
pero debería
¿Qué es un bug?
El software...● NO hace algo que debería● Hace algo que NO debería● Hace algo que NO dice su especificación● Hace algo que su especificación NO dice,
pero debería
...es difícil de entender, de usar, lento.
¿Qué los causa?
● Especificación– Porque no se escribe, no se detalla,
cambia constantemente o no se propaga
● Diseño– No se detalla suficiente, cambia y no se
comunica
● Código– Complejidad, documentación pobre,
presión, errores tontos
¿Cuánto cuestan?
● “El 50% del coste del proyecto”
● “Al menos 1/3 y probablemente más de 1/2 del coste del proyecto”
● “Al menos la mitad del coste de todas las demás actividades del proyecto”
¿Cuánto cuestan?
● ¡Más cuanto más tarde se detectan!
– Cuesta 0'10 € cambiar una especificación– Cuesta entre 1 y 10 € corregir un error
durante el desarrollo o las pruebas– Cuesta desde 100 € subsanarlo si lo
encuentra el cliente
¿Cuánto cuestan?
● ¡Más cuanto más tarde se detectan!
– Cuesta 0'10 € cambiar una especificación– Cuesta entre 1 y 10 € corregir un error
durante el desarrollo o las pruebas– Cuesta desde 100 € subsanarlo si lo
encuentra el cliente
… en el caso medio.
Mariner I, 1962
Intel Pentium FDIV, 1994
El rey león, 1994/95
Ariane 5, 1996
Mars Climate Orbiter, 1999
“Efecto 2000”
En el peor de los casos...
Therac-25, 1985/87
MIM-104 Patriot, 1991
London Ambulance Service, 2000-hoy
Toyota Prius, 2010
Definitivamente, no hacer pruebas resulta más caro
Definitivamente, no hacer pruebas resulta más caro
… y además el coste de mantenimiento cae drásticamente
cuando se prueba
Definitivamente, no hacer pruebas resulta más caro
… y además el coste de mantenimiento cae drásticamente
cuando se prueba bien
¿Para qué valen las pruebas?
● Las pruebas exitosas son las que encuentran errores
● Las pruebas no pueden demostrar que el software no tienefallos
● Las pruebas no puedendemostrar que elsoftware se ajusta a suespecificación
¿Para qué valen las pruebas?
● Las pruebas pueden mostrar lapresencia de errores
● Las pruebas pueden mostrar que los intentos de hacer fallar el software con respecto a su especificación fracasaron
● Las pruebas pueden mostrar que no se pudo encontrar ninguna disconformidad con respecto a la especificación
¿Para qué valen las pruebas?
● No se puede probar un programapor completo
● No siempre se pueden arreglar todos los errores que se encuentran
● A veces, cuantas más pruebas, menos errores se encuentran (paradoja del pesticida)
● Casi siempre, cuantos más errores se encuentran, más errores hay
¿Para qué valela gestión de pruebas?
● Debemos ser capaces de responder claramente y con cierta confianza a:
– ¿Está el producto listo?– ¿La cobertura de pruebas es suficiente?
● Si la respuesta es no...
debe estar claro por qué
¿Para qué valela gestión de pruebas?
● Las pruebas deben estar bien integradas con el ciclo de desarrollo y vida del proyecto, sea cual sea, para poder responder a
– Qué hay que probar– Cuándo se empieza a probar– Cuándo se para de probar– Quién hace qué– Cuáles son los resultados
II.¿Qué pruebas necesita mi software?
Historia
● Prehistoria (<1956): depuración– Objetivo: que el software se ejecute
● Edad Antigua (1957-1978): demostración– Objetivo: respaldar empíricamente que el
software cumple su especificación
● Edad Media (1979-1982): destrucción– Objetivo: forzar la aparición de errores
Historia
● Edad Moderna (1983-1987): evaluación– Objetivo: detectar errores en el diseño o en
la especificación
● Edad Contemporánea (>1998): prevención– Objetivo: prevenir errores de diseño y de
especificación● Métodologías ágiles● Test-driven development
¿Qué sabemos de las pruebas software?
Verificación
¿Desarrollamos el software
correctamente?
Validación
¿Desarrollamos el software correcto?
¿Qué sabemos de las pruebas software?
Verificación
¿Desarrollamos el software
correctamente?
(de acuerdo a su especificación)
Validación
¿Desarrollamos el software correcto?
(de acuerdo a la necesidad del
usuario)
¿Qué sabemos de las pruebas software?
● Niveles de prueba– Pruebas de unidad– Pruebas de integración– Pruebas de sistema– Pruebas de aceptación
¿Qué sabemos de las pruebas software?
● Técnicas de prueba– Dinámicas vs. Estáticas vs. Simbólicas
● Requieren o no de la ejecución del software, o lo simulan
– Caja blanca vs. Caja negra● Necesitan o no de conocimiento sobre la
estructura interno del software
– Positivas vs. Negativas● Buscan o no ejercitar el software en
condiciones normales de uso y funcionamiento
¿Qué sabemos de las pruebas software?
● Técnicas de prueba:– Funcionales
● Se ocupan de lo que el software debe hacer● Suelen ser técnicas dinámicas de caja negra
– Estructurales● Se ocupan de lo que el software debe hacer● Suelen ser técnicas de caja blanca
– No funcionales● Se ocupan de cómo el software debe hacerlo● Suelen ser técnicas dinámicas de caja negra
Técnicas de prueba
● Pruebas funcionales de caja negra– Particiones equivalentes
● Se examina el conjunto de posibles entradas para una unidad y se divide en rangos que, de acuerdo con la especificación, deban recibir el mismo tratamiento
● Para cada rango, se elige un elemento representante, bajo la premisa de que cualquier valor dentro de cada rango es tan bueno para encontrar errorescomo el resto
Técnicas de prueba
● Pruebas funcionales de caja negra– Valores-frontera
● Complementa la técnica de particiones equivalentes seleccionando valores de entrada (y de salida) pertenecientes a las fronteras entre rangos
● Las fronteras no siempre son obvias (especialmente a la salida):
– primero/último, inicio/fin, vacío/lleno, lento/rápido, grande/pequeño, cercano/lejano, mínimo/máximo, encima/debajo, corto/largo, pronto/tarde, alto/bajo... (+/-1)
Técnicas de prueba
● Pruebas funcionales de caja negra– Mapas de transiciones
● Para unidades con estado/memoria● Fronteras en los mapas de transiciones
suelen rebelar problemas de temporización, race conditions,...
Técnicas de prueba
● Pruebas funcionales de caja negra– Árboles causa-efecto + tablas de
decisión– Selección de datos aleatoria
● En realidad, que siga la gramática especificada para la unidad
● Generará datos que ni probadores ni desarrolladores se plantearían normalmente
Técnicas de prueba
● Pruebas funcionales de caja negra– Basadas en modelos y propiedades
● Aserciones, enunciados● Máquinas de estados finitos
Técnicas de prueba
● Pruebas funcionales de caja blanca– Cobertura de instrucciones
● Seleccionar casos de prueba para que se ejecute cada sentencia en el código al menos una vez
– Cobertura de decisiones (ramas)● En el caso de las sentencias de decisión, la
cobertura de instrucción puede hacer que se ejecute la toma de la decisión, pero no todas sus posibles ramas
Técnicas de prueba
● Pruebas funcionales de caja blanca– Cobertura de condiciones
● Seleccionar casos de prueba para que la toma de una decisión sea ejercitada explorando todas las posibilidades de la(s) condición(es) asociada(s)
– Análisis de flujo de datos● Búsqueda de variables sin utilizar,
referenciadas sin inicializar, sin dereferenciar...
– Análisis de flujo de control
Técnicas de prueba
● Pruebas funcionales de caja blanca:– Mutación de código– Inserción de fallos
● Pruebas estructurales de caja blanca:– Revisión de código
Técnicas de prueba
● Pruebas no funcionales de caja blanca– Análisis del tiempo de ejecución
y el uso de recursos● Explora la presencia de bugs
monitorizando estos dos parámetros● Muy valioso para optimización
Técnicas de prueba
● Pruebas no funcionales de caja negra– Configuración (instalación)– Estrés (seguridad, fiabilidad)
● Qué carga aguanta el software sin fallar● Qué avisos da antes de fallar● Qué pasa cuando soporta alta carga largo
rato● Cuánto tarda en recuperarse● Qué asistencia es necesaria para la
recuperación
– Usabilidad
Métricas de prueba
● Métricas de proceso– Bugs en desarrollo vs. en producción (fault
slip-through), edad media de bugs/bugs abiertos, tiempo de respuesta a 30 días, densidad de bugs...
● Métricas de robustez– Tiempo medio de fallo
● Métricas de usabilidad– Facilidad de uso (tiempo experto/tiempo
usuario), ratio de trabajo/productividad,...
III.¿Cómo hago pruebas al software?
¿Cómo hago pruebas al software?
● Las pruebas deben derivarse de una línea base (especificación)
– Determina qué es un error● No necesita ser completa, pero debe
contener suficiente información útil● Debe ser estable pero flexible, sus
cambios deben controlarse
– Debe interpretarse unívocamente– Ser visible y legible para los
stakeholders
Tipos de errores
● Cambios y correcciones son la primera causa de los bugs
– Porque se actualiza el código y no las especificaciones
● Inconsistencias● Falta de trazabilidad● Efectos secundarios imprevistos
– Porque no se revisa o prueba suficiente
Tipos de errores
● Hay 3 principales motivos para cambiar el software:
– Corregir bugs– Añadir funcionalidades– Adaptarse a cambios en el entorno
Tipos de errores
● Errores de especificación● Errores funcionales
– Previstos pero no suficientemente controlados
– Que deberían haberse previsto– Que no podrían haberse previsto
● Errores no funcionales
¿Por dónde empiezo a hacer pruebas?
● Monitorización del progreso de prueba:– ¿Cuánta cobertura necesito?– ¿Cuántos casos de prueba necesito para
alcanzarla?– ¿Cuántos casos de prueba tengo?– ¿Cuántos casos de prueba he ejecutado?– ¿Cuántos bugs he encontrado?– ¿He encontrado tantos bugs como
esperaba?
¿Cuándo paro de hacer pruebas?
● Las funcionalidades son estables– Ha caído el ratio de detección de errores– Ya no aparecen bugs de cierta gravedad– Code turmoil es satisfactorio
● Se han ejecutado todas las pruebas– Se ha ejercitado todo el
código/funcionalidades/escenarios– El número y severidad de los bugs
encontrados está en un nivelsatisfatorio
Calidad de las pruebas
● Métricas e indicios internos:– Bugs detectados en pruebas vs.
detectados en producción– Bugs vs. cambios– Bugs por iteración, bugs por parche,
parches por release● ¿Se reducen los de mayor
gravedad/prioridad respecto al total?
– Bugs abiertos vs. cerrados– Pruebas ejecutadas/abandonadas
Calidad de las pruebas
● Métricas e indicios externos:– Nuevos proyectos no avanzan porque
hay que dedicar personal a mantenimiento
– Evolución de los retrasos en entrega– Evolución de horas extras próximas a las
fechas de entrega– Evolución de LOC/bug en cada release,
en cada producto
Gestión de las pruebas
● Para cada proyecto software, debe definirse una estrategia de prueba
– Visión global de la tarea– Dirección, prioridades– Documento de estrategia:
● Situación hoy + top 10 problemas + posibles soluciones, cómo abordarlos
– Revión cada 6 meses o cuando haya cambios significativos en el proyecto o el entorno
Gestión de las pruebas
● Para cada release, debe redactarse y ejecutarse un plan de pruebas
– Centrado en los posibles problemas de cada release
● Nuevas features, interacción con features ya existentes (backwards-compatibility)...
– Documento de plan de pruebas● Actividades necesarias para llevar a cabo
unas pruebas eficaces + herramientas y entorno de pruebas + planificación
Gestión de las pruebas
● Para cada unidad, debe mantenerse un documento de monitorización de pruebas:
– Casos de prueba esperados y reales– Cobertura de funcionalidades– Prioridad de funcionalidades– Bugs esperados y encontrados– Bugs por funcionalidad
Gestión de las pruebas
● Especificación de diseño de pruebas– Qué se prueba, técnica, entorno, criterios
de aceptación/rechazo.
● Especificación de casos de prueba– Objetivo, especificación, entradas/salidas,
dependencias, nº de bugs esperados
● Especificación del proceso de prueba– Release/configuración, pasos para
ejecución/medición, procedimiento en caso de error, criterios de inicio/parada
Gestión de las pruebas
● Especificación de diseño de pruebas– Qué se prueba, técnica, entorno, criterios
de aceptación/rechazo.
● Especificación de casos de prueba– Objetivo, especificación, entradas/salidas,
dependencias, nº de bugs esperados
● Especificación del proceso de prueba– Release/configuración, pasos para
ejecución/medición, procedimiento en caso de error, criterios de inicio/parada
Plan de Calidad
“Software exhibits weak-link behaviour: failures in even unimportant parts of the code can have important repercussions
elsewhere”
“Bugs remain in software after testing because testers and developers have the same view of the way the software will be
used by users”
Sputnik, 1957
“There are things you can specify and things you can test for, and there are
things you'd never ever think of guarding against”.
“If you can't plan or model it, what makes you think you can do it?”
Taller de pruebas software
El espectro de las pruebas
Pruebas individualesEjemplos concretos
Propiedades generalesEspecificación completa
Casos de prueba congeneración de datos
Generación desecuencias de prueba
