Gestión de pruebas en desarrollo software
Upcoming SlideShare
Loading in...5
×
 

Gestión de pruebas en desarrollo software

on

  • 4,622 views

 

Statistics

Views

Total Views
4,622
Views on SlideShare
4,608
Embed Views
14

Actions

Likes
1
Downloads
98
Comments
0

2 Embeds 14

http://www.linkedin.com 8
http://sistemadegestionydeprueba.alianzasuperior.com 6

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Gestión de pruebas en desarrollo software Gestión de pruebas en desarrollo software Presentation Transcript

  • 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