Gestión de pruebas en desarrollo software

GESTIÓN DE PRUEBAS EN DESARROLLO SOFTWARE25 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 010 € 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 010 € 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 tiene fallos● Las pruebas no pueden demostrar que el software se ajusta a su especificación

¿Para qué valen las pruebas?● Las pruebas pueden mostrar la presencia 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 programa por 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é vale la 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é vale la 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 Validación¿Desarrollamos el ¿Desarrollamos el software software correcto? correctamente?

¿Qué sabemos de las pruebas software? Verificación Validación¿Desarrollamos el ¿Desarrollamos el software software correcto? correctamente?(de acuerdo a su (de acuerdo a laespecificación) 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 errores como 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 nivel satisfatorio

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 d criterios Especificación de diseño de pruebas● a id Qué se prueba, técnica, entorno, – l a de prueba de aceptación/rechazo. Especificación de C casos e● – d nº de bugs esperados Objetivo, especificación, entradas/salidas, n la dependencias,● P Especificación del proceso de prueba – Release/configuración, pasos para ejecución/medición, procedimiento en caso de error, criterios de inicio/parada

“Software exhibits weak-link behaviour: failures in even unimportant parts of the code can have important repercussions elsewhere” “Bugs remain in software after testingbecause 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 arethings youd never ever think of guarding against”.“If you cant plan or model it, what makes you think you can do it?”

Taller de pruebas software

El espectro de las pruebas Casos de prueba con Generación de generación de datos secuencias de pruebaPruebas individuales Propiedades generalesEjemplos concretos Especificación completa

Gestión de pruebas en desarrollo software

by Laura M. Castro

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Gestión de pruebas en desarrollo software Presentation Transcript