View
218
Download
1
Category
Preview:
Citation preview
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Fundación para el Desarrollo de Nuevas Tecnologías
Dr. Hermann Steffen26 y 27 de Abril 2010
Fundación para el Desarrollo de Nuevas Tecnologías
Dr. Hermann Steffen26 y 27 de Abril 2010
El equipo de Software Testing: organización,
metodología, técnicas y herramientas
El equipo de Software Testing: organización,
metodología, técnicas y herramientas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Introducción generalIntroducción general
Capítulo 1Capítulo 1
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 3
Motivaciones
• Desarrollar software sigue siendo una actividad de alto riesgo
55 %Desarrollo con grandes dificultades ysolo alcanzando resultadosparciales
29 %Desarrollo exitoso
16 %Proyectoscancelados
Standish Group 2007
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 4
• Una de principales causas de fracaso en los proyectos es el bajo nivel de pruebas
• Esta dificultad es tanto más grave cuando el proyecto es grandeo La complejidad crece exponencialmente al tamaño del proyecto
o La parte de las pruebas es proporcionalmente mayor en proyectos complejos
Motivaciones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 5
Costo relativo de las actividades
Documentación
Gestión
Desarrollo
Pruebas
100 K 1 M
• Costo relativo cambia según el tamaño del software
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 6
• Las pruebas, en sentido amplio, deben formar parte del Proceso de Desarrolloo Condición indispensable al éxito
• Acciones multidisciplinarias, multidimensionaleso Mejorar los procesos de desarrollo de software
• Mejores prácticas, mejora continua, normalización
o Mejorar los procesos de Prueba de Software • Todo se juega durante el proceso de desarrollo
• Es muy difícil agregar calidad a posteriori
• Difundir las buenas prácticas e impulsar la certificación de profesionales
Tendencias en Pruebas de Software
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 7
• Por naturaleza, las pruebas nunca son completas y definitivaso Imposibilidad práctica (y generalmente también teórica) de ejercer
todos los casos de prueba posibles.
• Las pruebas llegan generalmente demasiado tardeo Al final del proyecto, con poco tiempo y pocos recursos
o Sin capacidad de intervenir en decisiones ya tomadas
• Probar es generalmente considerado como una acción que no tiene un alto valor agregado
Enfrentar algunas dificultades…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 8
• El área de Pruebas de Software está ocupando un lugar crecienteo Como lo ha sido el área de Procesos, con ISO 9000 y CMM-I
o Como lo ha sido el área de Gestión de Proyectos, con PMI
• Una de las claves es ver las pruebas en su contexto global, como aporte a la mejora de los procesos de desarrollo y a la calidad de los productos
• Certificaciones del ISTQB
Tendencias…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 9
Historia del ISTQB
ISEB (Information Systems Examinations Board, perteneciente al British ComputerSociety) desarrolla el programa de estudios de Certified Tester. El primer Certified Testerdata de 1998.
2001 Es fundado el German Testing Board. Desarrolla en alemán el programa de estudios de Certified Tester de acuerdo con la propuesta del ISEB y toma como referencia el estándar alemán DIN.
2002 La primera certificación “ASQF® - Certified-Tester (AD V1.0)“ (Arbeitskreis Software) Qualität und -Fortbildung e.V.= Working Group for Software Quality and Training) tiene lugar en países de habla alemana.
2002 Se fundan el ISTQB® (International Software Testing Qualifications Board), the Swiss Testing Board, the Austrian Testing Board and the German Testing Board
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 10
Historia del ISTQB
2003 El programa de estudios para el “Advanced Level“ se completa.
2004 Primer examen de “ISTQB® Certified-Tester Advanced Level”.El número de comités nacionales llega a 14.
2005 Se funda el Comité Español de Testing
2006 El número de comités nacionales aumenta hasta un total de 28 (Octubre 2006)Se empieza a trabajar en el programa de estudios del Nivel Experto (“Expert Level“).
Actualmente existen más de 30 comités nacionales con más de 80.000 certificaciones en todo el mundo.
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 11
ISTQB en el mundo
American Testing Qualifications Board Australian/New Zealand Testing Board Austrian Testing Board Belgium/Netherlands Testing Board Bangladesh Testing Board Brazil Testing Board Canadian Testing Board Chinese Software Testing Qualifications Board Czech and Slovak Testing Board Danish Testing Board Finnish Software Testing Board French Testing Board German Testing Board Indian Testing Board Irland Testting Board Israeli Testing Certification Board Italian Testing Board Japanese Testing Board
Kingdom of Saudi Arabia Testing Board Korean Testing Board Latin American Testing Board Latvia Testing Board Malaysian Testing Board Nigerian Testing Board Norwegian Testing Board Polish Testing Board Portuguese Testing Board Russian Testing Qualifications Board South East European Testing Board Spanish Testing Board Swedish Software Testing Board Swiss Testing Board Turkish Testing Board UK Testing Board Ukraine Testing Board
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 12
• Estándares mundialmente reconocidos para la enseñanza y entrenamiento de probadores software.
• Programas de Estudios de múltiples niveles.
• Exámenes tomados por entidad independiente.
• Certificaciones reconocidas internacionalmente.
• Fomento de la profesión de “Probador de Software” (software Tester)
Certificación del ISTQB
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 13
Certificaciones en el mundo
ISTQB ® Certified TesterReino Unido 41.840India 10.236Alemania 9.115Bélgica 5.827USA 3.755Suiza 2.294Australia 1.498Israel 1.031Austria 908Japón 904
CrecimientoMayo 2006 33.218Septiembre 2006 40.776Diciembre 2006 41.772Abril 2007 56.032Julio 2007 60.727Octubre 2007 67.822Marzo 2008 81.855 Pronóstico de crecimiento
Diciembre 2009 > 100.000
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 14
• Conferencias sobre el temao Conference of the Associations for Software Testing (CAST) (Canada)
o Test2008 India (Dehli)
o EuroSTAR (Software Testing Analysis and Review) (La Haya)
o Software Testing and Validation (Paris)
o BZ Media Software Test and Performance Conference (Boston)
o Future Test (New York)
o ICSTEST-E Conference of Software Testing (Bilbao)
o QA & Test (Bilbao)
o QAI Canada Internation Quality Conference
o QUEST – Quality Engineered Software and Testing Conference
o STANZ Conference (Software Testing in Australia & New Zeland)
o Software Testing Managers Workshop
o The Workshop on Performance and Reliability
Tendencias…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 15
• Presentar los principios fundamentales de las Pruebas de Softwareo Incluye apoyo a la preparación a la certificación ISTQB.
• Identificar el papel y lugar de un Equipo de Pruebas como parte del proyecto de desarrollo
• Definir y redactar el Plan de Pruebas, adaptado al proyecto
• Construir los entornos y herramientas de pruebas adecuadas para cada nivel de pruebas
• Contribuir a alcanzar los objetivos de calidad del software
• Contribuir a la mejora continua de los procesos de desarrollo de software, a corto y largo plazo
Objetivos del seminario
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 16
• Prueba (Test) de softwareo Proceso de ejercer un software para verificar que satisface los
requisitos especificados y detectar errores.
o Conjunto de uno o más casos de prueba.
• Caso de pruebao Conjunto de valores de entrada, precondiciones de ejecución,
resultados esperados y postcondiciones de ejecución, desarrollado con un objetivo particular o condición de prueba, tales como probar un determinado camino de ejecución o para verificar el cumplimiento de un requisito determinado. (IEEE 610)
Terminología
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 17
• Bug = Defecto = Faltao Características que pueden causar que un componente o sistema
no realice las funciones requeridas
• Error = Desperfectoo Acción humana que produce un resultado incorrecto
• Falla (fallo)o Desviación de un componente o sistema con relación al resultado
esperado
• Calidado Grado con el que un componente, sistema o proceso alcanza los
requerimientos especificados o las expectativas de los usuarios
Terminología
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
7 Principios Básicos7 Principios Básicos
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 19
• Principio 1: las pruebas ponen en evidencia defectoso Reduce la probabilidad de defectos no detectados
o No se puede demostrar que todos los defectos han sido identificados
o “No encontramos defectos” no es una prueba que no haya
• Principio 2: las pruebas exhaustivas son imposibleso Probar “todo” no es factible, salvo en casos muy triviales
o Evaluar los casos más interesantes que reduzcan el riesgo y que aumenten la confianza
Siete principios básicos de las pruebas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 20
• Principio 3: Probar en fases tempranaso Comenzar al inicio del desarrollo del software
o Realizar test estático de los requerimientos, diseño y código
o La corrección de defectos en los requerimientos pueden costar más de 100 veces si son detectados en la implantación
• Principio 4: Agrupamiento de los defectoso La mayoría de las fallas están originadas en unos pocos módulos
o Realizar un análisis del origen de las fallas a partir de test en fases tempranas
o Repetir esas pruebas hacia el final del proceso
Principios básicos…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 21
• Principio 5: Paradoja “del pesticida”o Repetir el mismo tipo de prueba puede perder eficacia
o Revisar periódicamente para evitar este fenómeno
• Principio 6: Las pruebas son dependiente del contextoo Sistemas similares (en apariencia) pueden tener objetivos muy
diferentes y requisitos muy diferentes
o Definir los objetivos de las pruebas según el contexto
o Adecuar esos objetivos según el nivel de riesgo aceptable
• Principio 7: Falacia de la ausencia de erroreso El objetivo es que el software sea conforme a las especificaciones y
no contenga errores
o No se puede demostrar que así sea, pero igual hay que usar el software de todas formas
Principios básicos…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
El Equipo de Test en el Ciclo de Desarrollo
El Equipo de Test en el Ciclo de Desarrollo
Capítulo 2Capítulo 2
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 23
Modelo de Desarrollo
Noción de Independencia del Testing
Lugar de las pruebas según el modelo de desarrollo
Roles y perfiles del Equipo de Test
Conclusiones
Las Pruebas en el Ciclo de Desarrollo
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 24
• Años 70’ : Modelo en Cascada• 1970- W.Royce – “Managing the Development of Large-Scale Software:
Concepts and Techniques”
• Años 80’ : Modelo en “V” y modelo Incremental• 1975- V. Basill – “Iterative Enhancement: A Practical Techniqeus for Software
Developement”
• Años 90’ : Modelo en Espiral, RAD e iterativos• 1985 – Barry Boehm- “A Spiral Model of Software Development and
Enhancement”
• 1992- Ph. Kruchten – “Un Processus de Dévelopment de Logiciel Intératif et Centré sur l’Architecture”
• Años 2000’ : Modelo en Componentes, SOA, Agiles
Evolución de modelos…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 25
• Enfoque a procesos formales y normalizadoso Fuerte importancia en el proceso a ser seguido
• Definición, seguimiento, evaluación, mejora continua
• Permite reproducir mejores prácticas de un proyecto a otro
o ISO 9001:2000
o CMM-I
o SPICE
• Enfoque a procesos Agiles (manifiesto 2002)o Individuos antes que procesos
o Software antes que su documentación
o Colaboración continua con cliente en lugar de contratos rígidos
o Reactividad y cambios en lugar de seguir un plan pre-establecid
o XP, Scrum, RUP, Crystal Clear, …
Formalismo del proceso desarrollo
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 26
• Fuerte orientación al proceso y la satisfacción del clienteo Estructura formal, documentación, seguimiento, trazabilidad
o Distribución de roles y responsabilidades
o Gestión de cambios formal y manejo de versiones
o Procesos internos bien definidos y estables
o Mejora continua
• Auditoría externa y certificación
• Pruebaso Mecanismo de revisión y validación sistemática
o Orientado a resultados: ¿Cómo hace Ud. para verificar la conformidad de sus productos?
ISO 9000:2000
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 27
• Orientado al oficio de desarrollo de softwareo Identificación de áreas y actividades clavesoModelización en 5 “niveles de madurez”o Buena herramienta para la mejora por etapaso Buen compromiso entre eficiencia y costo
• Aplica bien para empresas con muchos proyectos diferentes, con equipos diferentes
• Pruebaso Existen, pero no ocupan un lugar central explícito
o Se derivan de las actividades de revisión y validación orientadas a garantizar la adecuación del producto
CMM-I del SEI
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 28
• Procesos flexibles en contexto flexibleo Existen procesos y áreas, pero es posible cambiar en pleno
proyecto.
• Enfoque Ascendente (“Botton-up”)o Construcción a partir de elementos de base
• Programación por pareso Dos programadores y un solo teclado (driver/observer)
o Algunos estudios comparativos (15% lentos, 15% menos error)
• Propuesta de “Test-first”
• Testathono Evento colectivo para la redacción de los casos de prueba
• Poca formalidad y anticipación en pruebas
eXtreme Programming
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 29
• MSFo Enfoque derivado de procesos iterativos y espiral
• Organización del equipo de proyectoo Jefe de Proyecto, Desarrollo, Pruebas, Implantación, Gerencia del
Producto, Experiencia Usuario
• Proceso iterativoo Cada iteración aborda un entregable
o Esfuerzo medio por cada entregable (ej. 2 meses)
o 5 fases de cada iteración• Visión y Alcance
• Planificación
• Desarrollo
• Estabilización (i.e. Pruebas y correcciones…)
• Implantación/difusión
Microsoft Solutions Framework
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 30
Modelo de Desarrollo
Noción de Independencia del Testing
Lugar de las pruebas según el modelo de desarrollo
Roles y perfiles del Equipo de Test
Conclusiones
Las Pruebas en el Ciclo de Desarrollo
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 31
• Los desarrolladores sienten que son los más idóneos para encontrar defectos en su propio programao Aunque generalmente no poseen la objetividad y la independencia
necesaria
o Es preferible utilizar a personas independientes y objetivas
o Fomentar la colaboración entre esos dos grupos, en lugar de la competencia o la oposición
• Independencia de las pruebaso Separación de las responsabilidades entre las personas (o grupos)
encargados de otras partes del desarrollo y las encargadas de las pruebas, de forma de fomentar la dedicación y concentración en torno a los objetivos de las pruebas.
Factores que influencian el éxito de pruebas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 32
• 0) Pruebas concebidas por el desarrollador
• 1) Pruebas concebidas por otro desarrollador
• 2) Pruebas concebidas por probadores del mismo proyecto
• 3) Pruebas concebidas por terceras partes (externas al proyecto, de la misma empresa)
• 4) Pruebas concebidas por una empresa externa
Niveles de independencia del testing
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 33
Modelo de Desarrollo
Noción de Independencia del Testing
Lugar de las pruebas según el modelo de desarrollo
Roles y perfiles del Equipo de Test
Conclusiones
Las Pruebas en el Ciclo de Desarrollo
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 34
El lugar de las Pruebas…
Desa-rrollo
Debug
Pruebascliente
A
Equ
ipo
de D
esar
rollo
clie
nte
Desa-rrollo
TestSistema
Pruebascliente
B
Debug
TestDesa-rrollo
TestSistema
Pruebascliente
C
Debug
Desa-rrollo
TestSistema
Pruebascliente
D
Test
Debug
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 35
Lugar del Equipo de Testing
1
Jefe de Proyecto
Desarrollo
2Jefe de
Proyecto
Desarrollo, Pruebas, AQ
3
Jefe de Proyecto
Desarrollo Testing
AQ
4
Jefe de Proyecto
Desarrollo Testing
AQJefe de Proyecto
DesarrolloPPAQ AQ
Departamento Desarrollo
Externos
5
Jefe de Proyecto
DesarrolloTesting
AQ
Jefe de Proyecto
DesarrolloPPAQ AQ
Departamento Desarrollo
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 36
Lugar del Equipo de Pruebas
1
Jefe de Proyecto
Desarrollo
2Jefe de
Proyecto
Desarrollo, Pruebas, AQ
3
Jefe de Proyecto
Desarrollo Testing
AQ
4
Jefe de Proyecto
Desarrollo Testing
AQJefe de Proyecto
DesarrolloPPAQ AQ
Departamento Desarrollo
Externos
5
Jefe de Proyecto
DesarrolloTesting
AQ
Jefe de Proyecto
DesarrolloPPAQ AQ
Departamento Desarrollo
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 37
Modelo de Desarrollo
Noción de Independencia del Testing
Lugar de las pruebas según el modelo de desarrollo
Roles y perfiles del Equipo de Test
Conclusiones
Las Pruebas en el Ciclo de Desarrollo
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 38
• El Equipo de Test está integrado por profesionales de varios perfileso Manager o responsable del Equipo
o Analista de Testing
o Diseñador de Testing
o Tester
o Informático de apoyo técnico
Roles y Perfiles del Equipo de Test
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 39
• Manager de test• Gestión de proyectos
• Vínculo con el cliente
• Comprensión y seguimiento de los objetivos
• Planificación
• Herramientas y criterios para toma de decisiones sobre Criterios de Fin del test
Roles y Perfiles del Equipo de Test
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 40
• Analista de test• Experto en el dominio aplicativo
• Identificación de objetivos del producto en su contexto
• Experiencia y riesgos
• Identificar cómo obtener los datos de entrada
Roles y Perfiles del Equipo de Test
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 41
• Conceptor de test• Experto en técnicas de test (Estático, Estructural, Funcional, No-
funcional).
• Realización de especificaciones de casos de prueba
Roles y Perfiles del Equipo de Test
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 42
• Tester• Ejecución de los casos de prueba
• Fabricar o recolectar los datos de entrada
• Seguimiento de los planes y escenarios
• Reejecutar casos con error
Roles y Perfiles del Equipo de Test
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 43
Modelo de Desarrollo
Noción de Independencia del Testing
Lugar de las pruebas según el modelo de desarrollo
Roles y perfiles del Equipo de Test
Conclusiones
Las Pruebas en el Ciclo de Desarrollo
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 44
• El modelo de desarrollo es un elemento centralo Debe ser adaptado al tipo de software y de cliente
o Debe incluir mecanismos de seguimiento y de evaluación
o La tecnología permite un desarrollo por componentes fuertemente autónomos
• Detección temprana de erroreso Pruebas por niveles: componentes, integración, sistema, aceptación
• Combinar diferentes tipos de pruebao Estáticas: Revisiones, Inspecciones, Análisis Estático de código
o Dinámicas: Funcionales, No-Funcionales, Estructurales
• Establecer el lugar adecuado de las pruebas en el proceso de desarrollo
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Procesos Fundamentales de
Testing
Procesos Fundamentales de
Testing
Capítulo 3Capítulo 3
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 46
• 1) Planificación y controlo Verificar la misión de las pruebas
o Tener en cuenta las lecciones aprendidas
o Definir los objetivos de las pruebas
o Comparar el avance real con el planificado
o Reportar el estatus y las desviaciones con lo planeado
o Evaluación del nivel de riesgo alcanzado
Cinco procesos fundamentales de pruebas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 47
• 2) Análisis y diseñoo Transformación de los objetivos de pruebas en condiciones de
pruebas y casos de pruebas concretos
o Determinar qué pruebas pueden automatizarse y cuáles no
• 3) Implementación y ejecucióno Concepción detallada de los casos de prueba
o Programación de los procedimientos o guiones, combinando y construyendo las series de prueba necesarias
o Preparación del entorno necesario para realizar las pruebas
o Ejecución de las pruebas
Procesos fundamentales …
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 48
• 4) Evaluación de criterios de salida y reporteso Evaluar los resultados de los casos de prueba con relación a los
resultados esperados
o Evaluar si los criterios de salida han sido alcanzados para cada nivel de prueba
o Preparar los reportes de síntesis de las pruebas realizadas
• 5) Cierre de las actividades de pruebaso Recolectar la información de las pruebas realizadas
o Consolidar y sintetizar la información obtenida, sacar conclusiones y resguardar los entornos de prueba, resultados y cifras
o Analizar los resultados y deducir lecciones aprendidas para ser aplicadas en futuros proyectos. Documentar conclusiones.
Procesos fundamentales…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 49
Análisis, Concepción e implementación de tests
Implementaciónde test
Análisis de test
Concepciónde test
Documentaciónde base del testAnálisis (qué cosas testear)Condiciones (contexto)del testTrazabilidadAnálisis de impactoCobertura de los requerimientos
Especificaciónde la concepción del testEntradasCondiciones de ejecuciónResultados esperados Datos de las pruebasCreación manual Datos reutilizablesCreación automática
Especificaciónde los casos de pruebaImplementarPriorizarOrganizarEspecificación deescenarios de testsManualesAutomatizados Calendario deejecución de las pruebas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Principales Niveles de test
Principales Niveles de test
Capítulo 4Capítulo 4
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 51
• ¿En qué momento es más conveniente probar?o El menor esfuerzo de prueba parecería ser probar solo el sistema
completo y terminado
o Pero … su eficacia y eficiencia son muy bajas
o La mayoría de los errores que podrían haberse detectado (y corregido) mucho antes
• Principio de la detección temprana de erroreso Aprovechar de la metodología de construcción por componentes.
o Es posible probar, corregir y validar los componentes de base, para construir software sobre bases sólidas
Momento para realizar las pruebas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 52
• No todos los errores pueden ser detectados en cualquier nivel
• Errores en los componentes de base (Unitarios)o Adecuación con la especificación, problemas algorítmicos,
robustez, performance
• Errores de la integración de los componenteso Interacciones o interfaces inconsistentes, semántica incoherente
entre componentes que interactúan, mala gestión de excepciones
• Errores a nivel del sistemao Adecuación con la especificación, mala usabilidad, bajo
rendimiento, mala seguridad, inadecuación al problema del cliente
• Es mucho más eficiente detectar y corregir errores tempranamente
Tipo de errores por nivel
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 53
• Utilizar la secuencia usual de construcción de softwareo Componentes, Integración de componentes, Sistema, Aceptación
• Concepción descendiente, pruebas ascendientes
• Nivel de Pruebas de Componentes (unitarias)o Entorno para probar separadamente cada componente terminado
• Nivel de Pruebas de Integración (de componentes)o Estrategias de integración progresiva y pruebas para cada macro-
unidad integrada
• Nivel de Pruebas de Sistema (todo integrado)o Pruebas que simulen entorno del cliente, adoptando su punto de
vista de alto nivel
• Nivel de Pruebas de Aceptación (por el cliente)
Niveles de pruebas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 54
Niveles de prueba
Visión general del sistema
Especificación del sistema
Diseño y Arquitectura
Diseño detallado de componentes
Código
Pruebas UnitariasComponentes
Pruebas de Integración
Pruebas del Sistema
Pruebas de Aceptación
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Aspectos técnicos del testing y diseño de casos de prueba
Aspectos técnicos del testing y diseño de casos de prueba
Capítulo 5Capítulo 5
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 56
• Estática• Inspección de código
• Análisis estático
• Dinámicao Funcional
o No funcional
o Estructural
Tipos de prueba
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 57
• No se utiliza código ejecutándose
• Revisión de diferentes tipos de documentoso Uso de técnicas de Revisión, Inspección, Auditoría, Análisis técnico
• Análisis estático de códigoo Verificación de conformidad con especificaciones y normas
o Uso manual a través de lecturas
o Uso automático utilizando herramientas de Análisis Estático
• Permiten detección temprana de erroreso También permiten eliminación de causas de error potencial
o … y la mejora global de la calidad del software
• Permiten anticipar y mejorar el Plan de Pruebaso Conocer la complejidad, los riesgos, los objetivos, la arquitectura …
Pruebas estáticas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 58
• Pruebas basadas en “qué hace” el sistema
• Deduce los casos y condiciones de prueba a partir de la especificacióno Documento de especificación de requisitos del sistema
o Casos de uso
o Especificaciones funcionales
• Orientado a validar las características externaso Caja negra
o Punto de vista del usuario
• Aplicables a todos los niveles de pruebas
Pruebas Funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 59
• Pruebas basadas en “cómo” funciona el sistema
• Medidas de las características del software utilizando escalas cuantificables
• Orientado a las propiedades del software:o Fiabilidad, disponibilidad, mantenibilidad, ….
• Incluye pruebas de rendimientoo Tiempos de respuesta, carga, volumen, stress
• Pueden ser realizadas en varios niveles de prueba
Pruebas No-Funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 60
• Basadas en la estructura interna del softwareo Conocer la arquitectura y el código de los componentes
• Probar el software recorriendo su códigoo Diferentes recorridos son posibles para la misma funcionalidad de
interface
• Noción de Cobertura estructuralo Porcentaje de pruebas realizadas con relación a la totalidad de los
casos posibles
o Diferentes tipos de cobertura estructural• De Sentencias, de Rama, de Condiciones, de Caminos,
• Se aspira a cubrir el 100% de cobertura estructural (no siempre posible)
• Pueden realizarse en todos los niveles de pruebao Especialmente en pruebas unitarias y de integración
Pruebas Estructurales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 61
Noción de Pruebas Estáticas
Análisis de código
Herramientas
Conclusión
Pruebas estáticas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 62
• Pruebas sobre artefactos del software sin realizar su ejecucióno Aplica para documentos de requisitos, de diseño, código
o Uso de Revisiones o Análisis Estático de Código
• Revisioneso Realizadas sobre documentos o código, previamente a las pruebas
dinámicas.
• Análisis Estáticoo Identificar potenciales defectos en tiempo de compilación
o Verificación de conformidad con las normas a ser respetadas
o Medidas de complejidad del código
Noción de Pruebas Estáticas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 63
Momento de las Pruebas Estáticas
Visión general del sistema
Especificación del sistema
Diseño y Arquitectura
Diseño detallado de componentes
Código
Pruebas UnitariasComponentes
Pruebas de Integración
Pruebas del Sistema
Pruebas de Aceptación
Negocio
Técnico
1 – Revisión alcance
2 – Plan de Aceptación
3 – Revisión especificaciones
4 – Plan de Pruebas Sistema
5 – Revisión diseño
6 – Plan Pruebas de Integración
7 – Revisión Componentes
8 – Revisión Componentes
9 – Plan PruebasComponentes
10 – Ejecución pruebas
11 – Ejecución pruebas
12 – Ejecución pruebas
13 – Ejecución pruebas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 64
• Se detectan defectos en lugar de fallos
• Detección temprana de defectoso Permite la corrección a bajo costo
• Utiliza y enriquece las lecciones apredidaso Contribuye a la mejora de la construcción del software
• Reducción de costos o Evitar costosas correcciones
o Mayor respeto de plazos debido a menores incidencias
• Detecta defectos, inconsistencias en las especificacioneso Los errores más difíciles de corregir
• Aumenta la fiabilidad del software
Ventajas de las Pruebas Estáticas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 65
Noción de Pruebas Estáticas
Análisis de código
Herramientas
Conclusión
Pruebas estáticas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 66
• Análisis de características del códigoo Previo a la ejecución de pruebas dinámicas
o Lenguajes C, C++, C#, ADA y Java
• Permite detección de problemas potencialeso Gestión de la memoria
o Alta complejidad
o Código muerto
o Variables no utilizadas
o Variables no inicializadas
o No respecto de estándares
o Problemas de seguridad
Análisis estático de código
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 67
Noción de Pruebas Estáticas
Análisis de código
Herramientas
Conclusión
Pruebas estáticas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 68
• PR:QA
• QAC
• PC Lint
• LDRA Tool Suite
• Logiscope
Herramientas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 69
• Las Pruebas Estáticas son un complemento indispensable
• Involucramiento del Equipo de Pruebas en fases tempranas
• Muy alta eficiencia y valor agregadoo Detección temprana de errores importantes
• Análisis de código utilizando herramientaso Cálculo de complejidad
o Detección de errores potenciales
o Respeto de normas
Conclusión
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Pruebas EstructuralesPruebas Estructurales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 71
• Presentar la noción de Prueba Estructural
• Calcular la complejidad estructural de un programa
• Presentar los diferentes tipos de cobertura estructural
• Generar los casos de prueba estructural
• Discutir del alcance y las limitaciones de las pruebas estructurales
Objetivos
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 72
Noción de Pruebas Estructurales
Estructura de los programas
Cobertura estructural
Casos de Prueba Estructural
Herramientas
Conclusión
Pruebas Estructurales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 73
• Basadas en la estructura interna del softwareo Conocer la arquitectura y el código de los componentes
• Probar el software recorriendo su códigoo Diferentes recorridos son posibles para la misma funcionalidad de
interface
• Noción de Cobertura estructuralo Porcentaje de pruebas realizadas con relación a la totalidad de los
casos posibles
o Diferentes tipos de cobertura estructural• De Sentencias, de Decisiones (Rama), de Condiciones
• Se aspira a cubrir el 100% de cobertura estructural (no siempre posible)
• Pueden realizarse en todos los niveles de pruebao Especialmente en pruebas unitarias y de integración
Pruebas Estructurales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 74
Noción de Pruebas Estructurales
Estructura de los programas
Cobertura estructural
Casos de Prueba Estructural
Herramientas
Conclusión
Pruebas Estructurales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 75
• Programas modelados como grafos orientadosCredito (Cliente, Monto, Decision, Razon)
Decision = FALSE If (lista_negra(Cliente) <> TRUE)
if (Ingresos(Cliente) <= (Monto/10) if (Monto < TOPE)
Decision = TRUE; Razon = Bajo_Montoelse
Razon = Monto_relativo_elevado else Decision = TRUE; Razon = Buenos_ingresos
elseRazon = Cliente_lista_negra
end
Estructura de los programas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 76
• Nodos y Arcos orientadosCredito (Cliente, Monto, Decision, Razon)
Decision = FALSE If (lista_negra(Cliente) <> TRUE)
if (Ingresos(Cliente) <= (Monto/10) if (Monto < TOPE)
Decision = TRUE; Razon = Bajo_Montoelse
Razon = Monto_relativo_elevado else Decision = TRUE; Razon = Buenos_ingresos
elseRazon = Cliente_lista_negra
end
o
Complejidad estructural
1
45
6
7
8
9
3
2
1
2
3
4
5 6 7
89
10
11
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 77
• Cálculo de caminos independienteso Arcos = 11
o Nodos = 9
o V (G) = 11 – 9 + 2 = 4o Camino A: 1,3,11o Camino B: 1,2,5,10o Camino C: 1,2,4,6,8o Camino D: 1,2,4,7,9
o En caso de existir loops, se cuentan de la misma forma (habrá un arco de retorno a la condición del loop)
Complejidad estructural
1
45
6
7
8
9
3
2
1
2
3
4
5 6 7
89
10
11
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 78
Noción de Pruebas Estructurales
Estructura de los programas
Cobertura estructural
Casos de Prueba Estructural
Herramientas
Conclusión
Pruebas Estructurales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 79
• Noción de Cobertura estructuralo Porcentaje de pruebas realizadas con relación a la totalidad de los
casos posibles
o Diferentes tipos de cobertura estructural• De Sentencias, de Decisiones (Ramas), de Condiciones,
• Se aspira a cubrir el 100% de cobertura estructural (no siempre posible)
Cobertura estructural
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 80
• Códigoo 1: if ((v > w) OR (x > y))
o 2: z = z +1
• 100% cobertura de sentenciaso Cuando (v>w) or (x>y)
• Casos posibles (1 alcanza)o 1a) v = 6 AND w = 3
o 1b) x = 3 AND y = 2
Cobertura de sentencias
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 81
• Códigoo 1: if ((v > w) OR (x > y))
o 2: z = z +1
• Dos casos son necesarios para 100% cobertura de decisioneso Caso de decisión TRUE: (v>w) OR (x>y)
o Caso de decisión FALSE: (v<=w) AND (x<=y)
• Casos de prueba posibleso Caso 1: (v = 9) AND (w = 8)
o Caso 2: (v = 3) AND (w = 7) AND (x = 4) AND ( y = 4)
Cobertura de decisiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 82
• Códigoo 1: if ((v > w) OR (x > y))
o 2: z = z +1
• 4 casos son necesarios para el 100% de cobertura de condiciones:
Cobertura de condiciones
v > w x > y Se ejecuta sentencia “2”?
TRUE TRUE SI
TRUE FALSE SI
FALSE TRUE SI
FALSE FALSE NO
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 83
Noción de Pruebas Estructurales
Estructura de los programas
Cobertura estructural
Casos de Prueba Estructural
Herramientas
Conclusión
Pruebas Estructurales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 84
• Identificar casos para los tipos de cobertura deseadoso Cobertura de Condiciones >= Cobertura de Decisiones >=
Cobertura de Sentencias
• Cobertura de Sentenciaso Generalmente es una condición demasiado débil
• Cobertura de Decisioneso Suficiente en la gran mayoría de los casos
o Exigida al 100% en algunas normas de productos
o Hay herramientas automáticas de apoyo
• Cobertura de Condicioneso Interesante si existen condiciones complejas con riesgo de
defectos
o Superconjunto de “decisiones”: se puede partir de los caminos independientes y expandirlos a las condiciones
Casos de prueba estructurales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 85
• Utilización de la complejidad estructuralo Cálculo de número Ciclomático
• Método para identificación de los casos de prueba1) Construir el grafo del programa
2) Calcular número Ciclomático
3) Hacer matriz con (al menos) una línea por camino independiente
4) Identificar cada camino independiente
5) Deducir los datos de entrada necesarios para cada camino
6) Identificar los datos de salida esperados
Casos de Prueba: cobertura de decisión
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 86
Noción de Pruebas Estructurales
Estructura de los programas
Cobertura estructural
Casos de Prueba Estructural
Herramientas
Conclusión
Pruebas Estructurales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 87
• Cálculo de complejidad estructuralo McCabe, Logiscope, LDRA
• Generación de casos de pruebao PEX – Visual Studio Team System (Microsoft)
• Coberturao Profiling (Unix), Logiscope, Profiling, y Test Coverage (VSTS-
Microsoft)
• Ambiente de ejecucióno Ejecución paso a paso, trazas
Herramientas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 88
• Generación de casos de prueba estructuralesValidar_tarjeta (Tarjeta, estatus_tarjeta, estatus_pw)Begincant_intentos = 0; estatus_pw = FALSE; estatus_tarjeta= FALSE
if (estatus(Tarjeta) == ROBADA) tragar (Tarjeta)
else estatus_tarjeta = TRUE while ((cant_intentos < MAX) AND (estatus_pw == FALSE))
ingresar_password(pw)if (eval_password(pw) == TRUE)
estatus_pw = TRUEcant_intentos = cant_intentos+1
endw if (estatus_pw == FALSE)
tragar (Tarjeta)End
Ejercicio : cobertura de decisiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 89
• Generación de casos de prueba estructuralesValidar_tarjeta (Tarjeta, estatus_tarjeta, estatus_pw)Begincant_intentos = 0; estatus_pw = FALSE; estatus_tarjeta= FALSE
if (estatus(Tarjeta) == ROBADA) tragar (Tarjeta)
else estatus_tarjeta = TRUE while ((cant_intentos < MAX) AND (estatus_pw == FALSE))
ingresar_password(pw)if (eval_password(pw) == TRUE)
estatus_pw = TRUEcant_intentos = cant_intentos+1
endw if (estatus_pw == FALSE)
tragar (Tarjeta)End
Ejercicio : cobertura de decisiones
1
23
4
5
6
78
9
1011
1213
1
32
4
5
6
789
1112
10
1413
16 15
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Complejidad:o Nodos = 13
o Arcos = 16
o V(G) = 16-13+2= 5o A:1,3,4,o B:1,2,5,6,7,8,10,11, 12,13,16o C:1,2,5,(6,9,10,11)n,12,14,15,16o D:1,2,5,6,7,8,10,11, 12,14,15,16o E:1,2,5,(6,9,10,11)n, 12,13,16o F:1,2,5, 12,14,15,16oG:1,2,5, 12,13,16
Análisis de caminos…
90
1
23
4
5
6
78
9
1011
1213
1
32
45
6
789
1112
10
1413
16 15
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Situación hallada:
Análisis de caminos…
91
Camino Representa… Decisión
A:1,3,4 Tarjeta robada Probar
B:1,2,5,6,7,8,10,11, 12,13,16 Tarjeta OK y PIN OK Probar
C:1,2,5,(6,9,10,11)n,12,14,15,16 Tarjeta OK y PIN KO (MAX=3, n=3) Probar
D:1,2,5,6,7,8,10,11, 12,14,15,16 Camino imposible excluido
E:1,2,5,(6,9,10,11)n, 12,13,16 Camino imposible excluido
F:1,2,5, 12,14,15,16 Tarjeta OK y sin PIN (MAX = 0) Probar
G:1,2,5, 12,13,16 Camino imposible excluido
B2:1,2,5,6,9,10,11,6,7,8,10,11, 12,13,16
Variante de B. PIN KO primera vez Probar
B3:1,2,5, 6,9,10,11, 6,9,10,11,6,7,8,10,11, 12,13,16
Variante de B. PIN KO dos primeras veces
Probar
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Casos de Prueba
92
Caso Contexto de ENTRADA Estado Esperado en SALIDA
Tarjeta PIN Lista Negra MAX Estatus Tarjeta
Estatus PIN
Tarjeta
A 9876 ---- 9876, 4567 3 FALSE FALSE TRAGAR
B B1 9876 OK 6565, 4567 3 TRUE TRUE Devolver
B B2 9876 KO;OK 6565, 4567 3 TRUE TRUE Devolver
B B3 9876 KO;KO;OK 6565, 4567 3 TRUE TRUE Devolver
C 9876 KO;KO;KO 6565, 4567 3 TRUE FALSE TRAGAR
F 9876 ---- 6565, 4567 0 TRUE FALSE TRAGAR
…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 93
Noción de Pruebas Estructurales
Estructura de los programas
Cobertura estructural
Casos de Prueba Estructural
Herramientas
Conclusión
Pruebas Estructurales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 94
• Las pruebas estructurales son un importante complementoo Verificación de buen funcionamiento de los diferentes caminos
internos
• Es conveniente utilizar herramientaso Para el cálculo de complejidad
o Para la generación de casos de prueba
o Si la complejidad es baja, es posible manejarlos manualmente
• Se aconseja…o Cumplir 100% de cobertura de decisiones
Conclusión
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Pruebas FuncionalesPruebas Funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 96
Noción de Pruebas Funcionales
Particiones en Clases de Equivalencia
Análisis de Valores de Borde
Tablas de Decisión
Transición de Estados
Casos de Uso
Pruebas Funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 97
• Pruebas basadas en “qué hace” el sistema
• Deduce los casos y condiciones de prueba a partir de la especificacióno Documento de especificación de requisitos del sistema
o Casos de uso
o Especificaciones funcionales
• Orientado a validar las características externaso Caja negra
o Punto de vista del usuario
• Aplicables en todos los niveles de pruebas
Pruebas Funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 98
• Técnica aleatoriao El probador elige juego de datos al azar
Generar casos de prueba…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 99
• Selectiva a partir del análisis de especificacioneso Deducir manualmente los casos más interesantes y representativos
o Deducir automáticamente a partir de un modelo y herramientas de generación. Posible en forma parcial, en particular utilizando UML
• Principales técnicas aplicableso Particiones en Clases de Equivalencia
o Análisis de valores de borde
o Tablas de decisión
o Transición de Estados
o Casos de Uso
o Otras…
Alternativas para generar casos…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 100
Noción de Pruebas Funcionales
Particiones en Clases de Equivalencia
Análisis de Valores de Borde
Tablas de Decisión
Transición de Estados
Casos de Uso
Pruebas Funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 101
• Partición de Equivalenciao Una porción del dominio de la entrada o la salida para la cual se
asume que el comportamiento es el mismo para un componente o sistema, basándose en la especificación.
• Generación de casos de prueba1) Análisis de las especificaciones
2) Identificación de comportamientos de la función a ser probada, considerando la relación entre entradas y salidas
3) Identificar las variables de entrada pertinentes
4) Para cada variable, analizar los subconjuntos de valores que deben tener el mismo comportamiento de la función : clase de equivalencia
5) Generar la combinación de las clases de equivalencia de las variables pertinentes de entrada
6) Simplificar si es posible
Partición de Equivalencia
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 102
o El seguro de automóvil no es aceptado para menores de 18 años ni mayores de 90. Para las personas de hasta 21 años solo se les permite asegurar autos de categoría Turismo, con una tasa de 30%. Los mayores de 75 años serán asegurados solo para autos de categoría Turismo y Sedan, con una tasa de 20%. Para los conductores de 21 años a 65, la tasa será de 0% para autos de Turismo, 5% para Sedan y 25% Deportivos.
Ejemplo partición de equivalencia
0 ..17 18..21 22..65 65..75 76..90 >90
Turismo A: B: C: D: E: F:
Sedan G: H: I: J: K: L:
Deportivo M: N: O: P: Q: R:
Error Cat. S: T: U: V: W: X:
NO 30% 0%
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 103
• Aspectos positivos de la Partición de Equivalenciao Es sistemático con relación a las especificaciones
o Permite un estudio sistemático de los casos
o Minimiza los casos a ser probados
o Permite detectar inconsistencias o incompletitud en las especificaciones
• Aspectos negativoso No tiene en cuenta las posibles interacciones entre condiciones de
las pruebas
o No resuelve problemas de estabilidad del software (e.g. repetición de la misma función, series que combinan funciones de cierta forma…)
Alcance de esta técnica de prueba
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 104
Noción de Pruebas Funcionales
Particiones en Clases de Equivalencia
Análisis de Valores de Borde
Tablas de Decisión
Transición de Estados
Casos de Uso
Pruebas Funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 105
• Propone generar casos de prueba para los valores de borde de las particiones de equivalenciao La probabilidad de defectos se sitúen en la programación de los
valores de borde
o Es un buen complemento a las Particiones de Equivalencia
• Ejemplo para el caso de “tasa de seguro”o Generar adicionalmente para cada clase de equivalencia
• Clase “A”: Edad = 15 años, Categoría = Turismo
• Clase “A2”: Edad = 17 años, Categoría = Turismo
• Clase “B”: Edad = 20 años, Categoría = Turismo
• Clase “B2”: Edad = 18 años, Categoría = Turismo
Técnica Análisis de Valores de Borde
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
o Función: Autentificación.• El usuario ingresa su tarjeta bancaria y espera para ingresar su código. El lector
de tarjetas extrae el número de tarjeta. La función solo aceptará tarjetas que no se encuentren en la “lista negra”. Si la tarjeta se encuentra en la “lista negra” será tragada por el cajero automático. El usuario dispone de hasta una cantidad MAX de intentos de ingreso de su número de identificación. En caso de superarse esa cantidad MAX la autorización será denegada y la tarjeta será tragada. Si la tarjeta no está en la “lista negra” y si el usuario ingresa correctamente su número de identificación la función autorizará al usuario. Se utilizarán las variables de salida “estatus_tarjeta”, “estatus_número_identificacion”, “autorizacion”, y “número de tarjeta”.
o Aplicar una Revisión de tipo “Inspección” para evaluar la especificación
• Corregir si fuese necesario…
o Aplicar técnica de generación de casos de prueba utilizando Partición de Equivalencias
• Solo considerar el caso del funcionamiento normal, sin fallas del entorno.
Ejercicio Inspección y Caso de Prueba
106
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 107
Noción de Pruebas Funcionales
Particiones en Clases de Equivalencia
Análisis de Valores de Borde
Tablas de Decisión
Transición de Estados
Casos de Uso
Conclusiones
Pruebas Funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 108
• Tablas de decisión• Presentación sintética y matricial de condiciones, acciones y reglas
asociadas
• Utilizadas para el análisis de reglas complejas
Técnica de Tablas de Decisión
Regla 1 Regla 2 Regla 3
Entradas y condiciones de ejecución
Var. A Valor a Valor a Valor b
Var. B Expres. n Expres. K Expres. p
Resultados esperados
Res. X 45 50 60
Res. Y SI NO NO
Estado Abierto Abierto Cerrado
Condiciones
Acciones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 109
• Utilizar una matriz, orientada a probar las Reglas• Al menos un línea o caso de prueba por cada Regla
• Leer la tabla de decisión en forma ordenada• De izquierda a derecha, de arriba abajo
• Las Condiciones representan los valores de entrada y condiciones de ejecución de las pruebas
• Las Acciones representan los resultados esperados
• Incluir los números de regla en los casos• Para llevar trazabilidad de las reglas y asociar los casos a las
reglas
• Verificar la completitud• Al menos una línea o caso de prueba por regla
Casos de Prueba para T. de Decisión
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 110
Ejemplo de Tablas de Decisión
Regla 1 Regla 2 Regla 3 Regla 4 Regla 5 Regla 6 Regla 7
Entradas y condiciones de ejecución
Edad conductor
<18 >=90 18..20 18..20 21..75 21..75 >75
Categoría auto
nd nd Turismo Sedan | Deport.
Turismo Sedan Deport
Resultados esperados
Aceptado NO NO SI NO SI SI NO
Monto básico
nd nd 1.000 $ nd 1.000 $ 1.000 $ nd
Tasa incremental
nd nd 30% nd 0% 5% nd
• Seguros de autos (incompleto, faltan reglas…)
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 111
Noción de Pruebas Funcionales
Particiones en Clases de Equivalencia
Análisis de Valores de Borde
Tablas de Decisión
Transición de Estados
Casos de Uso
Pruebas Funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 112
• DTE: Modelo de diseño de sistemas• Sistemas que mantienen un estado o sistemas con memoria
• Autómatas, Diagramas de Estado de UML, Workflows, BPM Notation, …
• Estados y Eventos• Estados : situación estable de un sistema, hasta que un evento
pueda modificarlo
• Eventos: situaciones exteriores que pueden ocurrir cuando el sistema está en cierto Estado
• DTE: presenta la síntesis de los estados, eventos y transiciones posibles entre estados.
• Muchos sistemas pueden ser modelados de esa forma• Sistemas integrados, máquinas y dispositivos hardware/software
• Interfaces usuario complejas
Técnica Diagramas de Transición de Estado
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 113
• Pruebas de Transición de Estado• Técnica de diseño de pruebas de caja negra en cual los casos de
prueba son diseñados para ejecutar transiciones de estado válidas e inválidas.
• Orientadas a ejercer todas las transiciones de estado, verificando su buen funcionamiento.
• También se pueden incluir transiciones no válidas, no previstas o “imposibles”, a los efectos de verificar el comportamiento del sistema en esos casos
Pruebas basadas en DTE
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Partir del DTE terminado y completo
• Crear una Matriz de Transición de Estadoso Matriz cuadrada, columnas y líneas son los Estados
o Para cada Estado en las líneas, identificar todas las transiciones posibles y los eventos que las disparan
o Colocar identificadores en las casillas de transiciones inválidas
• Crear una tabla de casos de pruebao A partir de la Matriz, cada casilla es un caso de prueba.
o Comenzar con las “pruebas positivas” (transiciones válidas)
o Prever casos de transiciones inválidas, para verificar la gestión de errores de transición
• Completar y simplificaro Algunas transiciones son irrealistas, otras merecen más de una
prueba
Casos de Prueba para DTE
114
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Casos de Prueba para DTE
115
Vacio
Contenido
Lleno
Crear Destruir
Agregar
Quitar &
Cant =
1
Agregar & Cant < Max-1Quitar & Cant > 1Leer
Agregar & Cant = Max-1
Quitar
AgregarLeer
Para: 1<Max
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Arbol de Transiciones: incluir los aspectos dinámicoso 1<Max<10
Pruebas de DTE dinámicas
116
Vacio
inicio
Cont. Destruido
VacioCont. Cont.
Lleno Cont.
Lleno
Lleno
Crear
Agreg
ar
Agregar
Agregar
Leer
Destruir
Quitar
Qui
tar
Leer
Agregar
Cont.
Quitar
Vacio
Quitar
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 117
Noción de Pruebas Funcionales
Particiones en Clases de Equivalencia
Análisis de Valores de Borde
Tablas de Decisión
Transición de Estados
Casos de Uso
Pruebas Funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 118
• Modelo de representación de interacción entre usuarios y el sistema• Un “actor primario” interactúa con el “sistema”
• El sistema responde, aportando soluciones al actor
• No solo aplica para software, sino que es un modelo de diálogo
• Puede representarse en modo texto o gráfico
• Forma parte de UML• Una de sus representaciones gráficas
• Se aspira a generar automáticamente casos de prueba a partir de los casos de uso formalmente definidos en una herramienta
Casos de Uso
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 119
• Los casos de uso permiten definir casos de prueba de alto nivel• Normalmente a nivel de pruebas de Aceptación
• Un caso de prueba de alto nivel puede subdividirse en varios casos de menor nivel
• Comenzar con los casos del escenario principal de éxito • Probar el funcionamiento del sistema en situación normal
• Es posible generar casos de prueba previos a la definición completa de los casos de uso
• Diseñar un caso de prueba por cada extensión• Prever casos de prueba para diferentes juegos de datos
• Ejecutar varias configuraciones
Probar Casos de Uso
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Pruebasno-funcionales
Pruebasno-funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 121
Atributos no funcionales del software
Usabilidad
Robustez
Rendimiento
Otros
Conclusiones
Pruebas no-funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 122
• Lista de los principales atributoso Usabilidad
o Integridad
o Robustez
o Disponibilidad
o Rendimiento
o Eficiencia
o Seguridad
o Flexibilidad y Evolución
o Portabilidad
o Simplicidad de Mantenimiento
Atributos no-funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 123
Atributos no funcionales del software
Usabilidad
Robustez
Rendimiento
Otros
Conclusiones
Pruebas no-funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 124
• Noción de usabilidado La capacidad del software para ser entendido, aprendido, usado y
atractivo al usuario cuando es usado bajo las condiciones especificadas. [ISO 9126]
• Usabilidad dirigida al usuarioo Identificar tipos de usuarios
• Usuario esporádico
• Usuario habitual
• Usuario gerencial
• Administradores
o Identificar perfil de usuario• Conjunto de tareas y responsabilidades de un conjunto de usuarios
• Determina menús, métodos de acceso, derechos de intervención.
Usabilidad
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 125
• Usabilidad en el marco del proceso de trabajoo Conocer y modelar actividades y procesos de trabajo para cada
tipo de usuario y cada perfil de usuario
o Utilizar BPMN u otros modelos
o Incluir diálogos y tiempos de reflexión
Modelar procesos de uso
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 126
• Pruebas de usabilidado Con relación a la especificación de requisitos
o Objetivo de validación
• Análisis o evaluación de usabilidado Con relación a reglas generales, a normas internas generales y a
un comportamiento esperado.
o No se basan en la especificación, que generalmente no existe o es muy pobre en este plano.
o Objetivo de anticipación de problemas, evidenciar problemas potenciales y hacer proposiciones de mejora
Análisis y pruebas de Usabilidad
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 127
• Adecuación al tipo de usuarioo Tipo usuario esporádico : altamente intuitivo. Buscar la simplicidad
antes que la performance.
o Tipo usuario habitual: permitir automatizar gestos, que sean naturales en el contexto y adaptados al flujo de trabajo
• Adecuación al flujo de trabajoo Estudio de la ergonomía del sistema en el marco real de trabajo
o Continuidad en las tareas
o Disponer de la información pertinente y solo de ella
o Acceso a la información con el mínimo esfuerzo
o No preguntar o ingresar información ya disponible
Reglas generales de Usabilidad
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 128
• Feedbacko Informar al usuario de lo que está pasando y de la comprensión de
sus órdenes.
o Mostrar los cambios de estado en pantalla (efecto “congelado”).
o Presentar mensajes asociados al contexto o al problema (evitar que el mensaje tape al problema)
• No ambigüedad, precisióno Evitar la información implícita (medidas, monedas…)
o Pantallas de ingreso/consulta específicas al caso (evitar campos no pertinentes)
Más reglas….
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 129
• Jerarquizar lo pertinenteo Evitar inundar la pantalla con datos, todos al mismo nivel, sino
presentar datos pertinentes, claramente visibles.
• Uniformizar/normalizaro Norma de uso de colores, nombres, textos, posiciones en pantalla,
uso de teclas, formato de datos, números y fechas.
o Norma en el uso de mensajes e instrucciones
• Permisividad e indulgenciao Evitar temor a “romper algo”.
o Robustez y paciencia cuando el usuario comete errores.
o Evitar desconexiones automáticas fuera de contexto
más reglas…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 130
• Asistencia al usuarioo Presentación en pantalla de los pasos a seguir
o Guía visual intuitiva
o Validación de campos en tiempo real
• Presentación de opciones y menúso Ver todo lo necesario sin tener que hacer scroll
o Mantener el estado de las operaciones
Mas reglas…
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 131
• Establecer medidas, asociadas al casoo Inventario de medidas de usabilidad
o Adecuado al tipo de usuario
o Su evaluación es realizada por usuarios reales• Definir criterios y realizar encuestas a usuarios
Medidas de usabilidad
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 132
Atributos no funcionales del software
Usabilidad
Robustez
Rendimiento
Otros
Conclusiones
Pruebas no-funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 133
• Robustezo Capacidad del software para resistir a errores de uso y errores de
entorno– Grado en el que un componente o sistema puede funcionar correctamente
en presencia de entradas no válidas o condiciones de entorno de estrés. [IEEE 610] Véase también tolerancia al error, tolerancia a faltas.
o Resistir : mantener el mejor comportamiento y continuidad posible, en esas circunstancias
• Ser robustoo Generalmente, resistir a eventos que están fuera de la
especificación de requisitos funcionales normales
o Generalmente no están especificados
o Importante capacidad del software para reducir el impacto negativo de problemas del entorno
Robustez
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 134
• Estimación de riesgos de la no robustezo Evaluar los eventos que podrían ocurrir, la probabilidad de que
ocurran y las consecuencias
• No existen normas genéricas
• Normas asociadas a productoso Seguridad de funcionamiento de productos o dispositivos
industriales
Alcance de la robustez
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 135
• Resistencia a errores de ingreso de datos
• Resistencia a errores de secuencia o procedimiento
• Resistencia a problemas de acceso a componentes/servicios externos
• Resistencia a errores del propio aplicativo
• Resistencia a errores en los datos
Reglas generales de robustez
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 136
• Requieren típicamente de un “banco de pruebas”o Pruebas eventualmente destructivas
o Pruebas que pueden requerir un acceso a componentes internos
o Pruebas de simulación de desperfectos del entorno
• Pueden ser costosaso En especial en la preparación del ambiente y en la ejecución de los
diferentes casos de desperfecto
Pruebas de robustez
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 137
Atributos no funcionales del software
Usabilidad
Robustez
Rendimiento
Otros
Conclusiones
Pruebas no-funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 138
• Rendimientoo Grado con que un sistema o componente logra la funcionalidad
señalada dentro de las restricciones dadas con respecto a tiempo de proceso.
• Pruebas de rendimientoo Validación, a partir de especificaciones de requisitos existentes
• Generalmente insuficientemente detalladas
• Muy difícil especificar condiciones de contextos complejos
o Objetivo: validar el cumplimiento de requisitos de rendimiento.
• Evaluación y análisis de rendimientoo Evaluación de rendimiento en base a criterios generales.
o Objetivo: conocer y anticipar problemas potenciales de rendimiento.
Rendimiento
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 139
• Alcance de las pruebas de rendimientoo El rendimiento es dependiente del contexto
• Características y configuración del entorno (hardware, redes, SO, DBMS)
• Cantidad de usuarios (conectados, simultáneos)
• Tipo de operaciones/transacciones
• Volumen de datos (en la BD, resultado de la consulta…)
o Pruebas en entorno variable• Caso más favorable
• Caso nominal
• Peor caso previsto
• Situación de bloqueo
Pruebas de rendimiento
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 140
• Pruebas de cargao Orientado a la cantidad de usuarios
o El volumen de datos se mantiene constante
o ¿Cómo reacciona el sistema ante al aumento de usuarios simultáneos o de transacciones en paralelo?
• Pruebas de volumeno Orientado al volumen de datos utilizados
o La cantidad de usuarios/transacciones se mantiene constante
• Pruebas de estréso Orientado a evaluar el sistema más allá de los límites especificados
o Ejecución de pruebas de carga y/o volumen, independientes o simultáneas
o ¿Cómo reacciona el sistema en situación de estrés?
Ejemplo : Prueba de rendimiento
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 141
• Determinar la cantidad promedio de usuarioso Combinar las transacciones típicas que ejecutan los usuarios
• Mantener el volumen de datos constante e ir aumentando la cantidad de usuarioso Comenzar con un único usuario
o Incrementar por paquetes (por ej. de 10) hasta llegar a la cantidad de usuarios prevista en promedio
o Continuar hasta la cantidad máxima prevista
o Sobrepasar la cantidad máxima prevista
• Monitorear los tiempos de respuesta para cada caso
o Incluir medidas de todas las transacciones ejecutadas, no solo del tiempo promedio
Ejemplo para prueba de carga
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 142
• Determinar la cantidad promedio de usuarios
• Mantener constante la cantidad usuarios e incrementar progresivamente el volumen de datoso Comenzar con un volumen mínimo (un registro…)
o Aumentar el volumen de datos y ejecutar una serie de transacciones típicas
o Identificar transacciones que manipulan grandes volúmenes de datos, agregaciones, selecciones, joins
o Hacer pruebas llegando al máximo de datos
Ejemplo para pruebas de volumen
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 143
• Es necesario disponer de herramientas de medición y monitoreo
• Simulación de cantidad variable de usuarios
• Mediciones interesanteso Tiempos de respuesta totales al usuario
o Tiempos de respuesta parciales al usuario (por operación elemental)
o Tiempos de respuesta internos de los principales componentes
o Consumo de recursos : memoria, procesador, red.
o Distribución de los tiempos de respuesta (no solo promedios o percentiles)
o Evolución de recursos para pruebas repetitivas al infinito
Ambiente para pruebas de rendimiento
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 144
• Analizar la forma en que se consumen los recursoso Componentes del consumo de tiempo
o Pruebas de “profiling”• Utilización de herramientas para medir el tiempo pasado en casa componente y
la cantidad de invocaciones de procesos.
o Identificar los componentes críticos y los cuellos de botella
o Base de información para planear mejoras y optimizar el software.
Análisis de rendimiento
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 145
• Utilizar un modelo “grafo de actividad” para representar el flujo de ejecución de una operacióno Permite un análisis de alto nivel
o Permite asignar los tiempos obtenidos con el “profiling”
o Permite descubrir los “agujeros negros” dónde se pierde el tiempo.
Modelado de flujos para rendimiento
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 146
• Rendimiento de operaciones y del sistema globalo Medidas de rendimiento de cada operación, tomada
separadamente.
o Medidas globales de combinaciones particulares de operaciones, en el marco del uso “realista” del sistema
• Modelar los patrones de uso del sistema globalo Cantidad de usuarios
o Volumen de datos
o Operaciones por perfil de usuario
o Periodicidad y grado de uso diario, semanal, mensual, anual.
o Incluir la actividad de recursos compartidos (BD, red, procesador, otros sistemas externos).
Visión global del rendimiento
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 147
• Construir los dos o tres principales patrones de usoo Deben representar el uso integrado y global
• Identificar contextos de cada modeloo Cada patrón de uso puede tener variantes de carga y volumen
o Estudio de los casos de “combinaciones indeseables”: coincidencia entre operaciones opuestas o conflictivas
• Consultas masivas frente a actualizaciones prolongadas en la BD.
Patrones de uso del sistema
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 148
Atributos no funcionales del software
Usabilidad
Robustez
Rendimiento
Otros atributos
Conclusiones
Pruebas no-funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 149
• Seguridad
• Eficiencia
• Integridad
• Disponibilidad
• Facilidad de Mantenimiento
• Facilidad de Evolución
• Portabilidad
Otros atributos no-funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 150
Atributos no funcionales del software
Usabilidad
Robustez
Rendimiento
Otros atributos
Conclusiones
Pruebas no-funcionales
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 151
• Las pruebas no-funcionales son indispensables
• Gran parte de la percepción de calidad del software se determina en estos atributoso Una vez resuelto los aspectos funcionalmente básicos, importa la
forma en que los mismos son resueltos
• Generalmente no se dispone de especificaciones o Actitud proactiva: contribuir a definir el alcance de las
características no-funcionales al comienzo del proyecto
o Actitud reactiva: disponer de criterios generales de observación y prueba para evaluar software, y generar observaciones y consejos a posteriori
• Aspectos generalmente ignorados en las pruebas
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Redacción del Plan Maestro de TestingRedacción del Plan Maestro de Testing
Capítulo 6Capítulo 6
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 153
• Plan de Pruebas y documentacióno Introducir una metodología estructurada de pruebas desde el
comienzo del proyecto
o Emplear un enfoque descendiente para la planificación de las pruebas y de la documentación
o Definir varios niveles de prueba con papeles y responsabilidades definidas
o Integrar la revisión a lo largo del proceso de pruebas
Enfoque general de las pruebas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 154
• Ejecución de pruebaso Ejecución de pruebas en forma ascendente (comenzar por las
unidades más pequeñas)
o Construir el entorno adecuado y los datos de pruebas
o Producir diarios de pruebas, de incidentes y reportes
o Obtener aceptaciones o alcanzar los criterios de salida antes de pasar al próximo nivel de pruebas
Enfoque general de las pruebas …
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 155
• Grandes objetivos de pruebas1. Conformidad funcional básica
2. Estabilidad
3. Robustez
4. Disponibilidad
5. Rendimiento
• No son los únicoso Pero permiten construir una estrategia lógica y ordenada para el
plan de pruebas• Incluir Usabilidad en fases tempranas de las pruebas
Estrategia sistemática para las pruebas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 156
• Primer etapa de pruebaso Validar funcionalidades básicas más importantes y críticas
o Método de “prueba de humo” al comienzo
o Cobertura funcional de casos normales de las especificaciones• Técnicas de pruebas estáticas (revisiones) sobre aspectos críticos
• Técnica de Particiones de Equivalencia, Tablas de Decisión, Diagramas de Estado, Casos de Uso…
• Técnicas de pruebas estructurales
o Modelar el uso típico y normal del sistema y realizar casos de prueba para ese contexto
o Corregir si los errores son medianamente importantes• Solo seguir el plan de pruebas si los defectos encontrados son de muy baja
importancia y no impactan el resultado de las demás pruebas
Objetivo 1: conformidad funcional básica
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 157
• Comprobar que el software mantiene su comportamiento frente a cambios de contexto:o Estabilidad frente al contexto hardware/drivers/sistema operativo
• Toda la serie de navegadores, versiones del SO, de drivers, de protocolos de red, varios tamaños de memoria RAM disponibles, …
o Estabilidad frente a cambio en parámetros o configuración normales
• Cambiar parámetros por otros valores válidos/autorizados
o Estabilidad frente a cambios en la forma de ejecución, al orden y a la duración del funcionamiento continuo
• Operación en continuo para detectar tendencias o puntos de crisis
• Cambio en el orden de ejecución y combinación de operaciones normales
• Probar dentro del alcance de las especificaciones
Objetivo 2: Estabilidad
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 158
• Observar el comportamiento frente a un contexto hostilo Resistencia a errores de datos de entrada
o Invocación incorrecta o fuera de contexto (no inicializado…)
o No respuesta de las invocaciones externas
o Recepción de códigos de error no previstos
o Recepción de resultados erróneos
o Loop infinito en el convocado
o Errores cometidos pero no declarados de los invocados• Disco lleno, BD no graba los cambios, transacción abortada, formatos erróneos
o Interrupción de transacciones
o Caída del software aplicativo
o Caída del SO
o Corte de energía
o Rotura hardware
Objetivo 3: Robustez
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 159
• Disponibilidado El grado hasta cual un componente o sistema es operativo y
accesible cuando se requiere su uso. A menudo es expresado como un porcentaje. [IEEE 610]
• Solo se puede evaluar en contexto realo Contexto hardware/software/redes/otros software, reales
o Usuarios reales
o Administradores reales
• En fase de pruebas de Sistema o Aceptacióno Simular contexto como para anticipar problemas graves
Objetivo 4: Disponibilidad
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 160
• Rendimiento es generalmente última etapao El rendimiento es muy sensible a los cambios realizados para
mejorar/corregir otros defectos
o Es preferible optimizar un software correcto pero lento, que corregir un software incorrecto pero rápido
Objetivo 5: Rendimiento
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 161
Principales ejes de trabajo
Estáticas
Funcionales
No funcionales
Estructurales
Técnicasde Prueba
Unitario
Integración
Sistema
AceptaciónNiveles de Prueba
Básica
Estabilidad
Robustez
Disponibilidad
Rendimiento
Objetivosde Prueba
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 162
• Elaborar estrategia de pruebas en las tres dimensiones1. Niveles de Prueba
• Unitario/Componentes, Integración, Sistema, Aceptación
2. Técnicas de Prueba• Estáticas, Funcionales, No-funcionales, Estructurales
3. Objetivos de Prueba• Nominales, Estabilidad, Robustez, …, Performance
• La definición de los Objetivos de Prueba es un factor central del diseño de las pruebaso Determina el alcance y la secuencia de pruebas
• Incluir estrategia en el Plan de Pruebaso En cada Nivel de Pruebas, identificar o definir los objetivos y las
técnicas a ser utilizadas
Estrategia a incluir en el Plan Maestro
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• IEEE 829 es una buena referencia : parte planificación
Redactar el Plan de Pruebas
163
Plan Maestrode Pruebas
Plan Pruebas Unitarias
Plan Pruebas
Integración
Plan Pruebas de
Sistema
Plan Pruebas de Aceptación
Especificación Concepción de
Pruebas
Especificación Concepción de
Pruebas
Especificación Concepción de
Pruebas
Especificación Casos de Prueba
Especificación Procedimientos
de Prueba
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Parte ejecución de pruebas…
Redactar el Plan de Pruebas
164
Informe de resumen de
Pruebas
Diario de Pruebas
Informe de Incidentes de
Prueba
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Test Management Processes
Fundamental Test Processes
• Organización en tres niveles
Nueva norma ISO Software Testing 29119
165
Test Desing & Implementation
Organizational Test Process
Test Planning
Test Environment
Set-UpTest Execution Test Incident
Reporting
Test Monitoring & Control Test Completion
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• El Plan y los documentos anexos debe incluir respuesta a los siguientes principales temas:o Alcance del Plan de Pruebas
o Enfoque general o combinación del enfoque
o Organización, responsabilidades
o Definición de las principales actividades
o Cronograma de alto nivel, asociado a cronograma del proyecto
o Identificación de los principales objetos/productos a ser probados
o Asignación de recursos
o Identificar los riesgos
Principales capítulos del Plan
166
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Gestión y Plan de Pruebas
Gestión y Plan de Pruebas
Capítulo 7Capítulo 7
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 168
Gestión y Plan de Pruebas
Noción de Gestión de Pruebas
Organización
Seguimiento
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Pruebas como proyecto dentro del proyecto de desarrolloo Necesita una estructura organizativa propia
o Necesita realizar una gestión completa
• Gestión de pruebaso Definir responsabilidades
o Establecer la organización, los recursos y los vínculos con el desarrollo (formales o informales)
o Identificar los objetivos a alcanzar
o Proponer las etapas a seguir
o Documentar el plan de trabajo
o Asignar tareas y verificar su cumplimiento
o Evaluar el estado de avance, tanto del plan como de los objetivos
o Tomar decisiones de salida de pruebas
Noción de Gestión de Pruebas
169
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 170
Gestión y Plan de Pruebas
Noción de Gestión de Pruebas
Organización
Seguimiento
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Buscar el grado de independencia adecuadoo Muchas personas pueden ser útiles para las pruebas:
• Los desarrolladores conocen bien el software y pueden ayudar a identificar zonas de riesgo y zonas de fragilidad. Se basan en lo que ha sido construido.
• Los probadores independientes aportan un punto de vista exterior, guiado por las especificaciones, por su experiencia, sin estar influenciados por el producto construido (al que conocen mal desde el ángulo de la construcción)
• Los usuarios finales aportan su evaluación acerca de la pertinencia del producto como herramienta para ayudarlos efectivamente en su trabajo. No les preocupa la construcción ni la adecuación con las especificaciones, sino la pertinencia del resultado final.
• Los expertos del área de negocio aportan una visión estratégica y de alto nivel.
o Buscar la combinación de puntos de vista y de grados de independencia más adecuados
• Pueden variar mucho dependiendo de los objetivos y del nivel de pruebas
• Construir un equipo de pruebas (o varios equipos) integrando a los diferentes actores a cada nivel de pruebas
¿Cómo organizarse para las pruebas?
171
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Equipo independienteo Se recomienda disponer de un grado mínimo de independencia
o Existencia de un Responsable de Pruebas del Proyecto
o Existencia de probadores dedicados, en cantidad suficiente para asumir las diferentes tareas previstas. Puede incluir personas de perfil muy diferente
o Existencia de un entorno dedicado a la actividad de pruebas, incluyendo hardware, software de base y herramientas
o Establecer claramente la misión y la relación entre el equipo de Pruebas y el resto del equipo del proyecto
o Establecer claramente los objetivos a corto y mediano plazo del Equipo de Pruebas
Nivel de independencia
172
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Se debe incluir la estimación del esfuerzo antes del comienzo del proyectoo Partir del alcance estimado para el desarrollo y del alcance
funcional y no funcional del producto final
• El esfuerzo de pruebas es función de múltiples factoreso Grado de confianza inicial
o Grado de confianza requerido sobre el producto entregado
• Reglas de estimacióno Regla simple: 1 probador cada 3 desarrolladores es un buen
promedio, para situaciones promedio.
o Microsoft preconiza 1 probador por cada desarrollador.
o Hay proyectos de alta fiabilidad donde hay más probadores que desarrolladores.
Estimación del esfuerzo de pruebas
173
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 174
Gestión y Plan de Pruebas
Noción de Gestión de Pruebas
Organización
Seguimiento
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• El responsable de Pruebas debe realizar un seguimiento sistemáticoo Del avance del plan de trabajo (de pruebas)
o Del estatus de los resultados obtenidos
• Definición de métricaso Cumplimiento del plan de trabajo
• Comparar el avance con relación a lo planeado
• Comparar el consumo de recursos de pruebas con relación a lo planeado
• Porcentaje de pruebas preparadas pero no realizadas (casos de prueba)
• Porcentaje pruebas realizadas
o Medidas de defectos• Identificar cada defecto encontrado y su estatus
• Clasificación de defectos y resumen.
• Medidas de previsión y estimación, medidas correctivas y mejoras.
Plan y Seguimiento de Pruebas
175
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Responsable debe re-evaluar constantemente su plano Los resultados obtenidos pueden poner en evidencia problemas
sistemáticos mayores
o ¿El plan de pruebas imaginado está siendo pertinente?• Caso de gran cantidad de defectos encontrados (¿en qué nivel de pruebas?)
• Caso de muy pocos defectos encontrados en desarrollo, pero riesgo de tasa de defectos residuales importantes una vez puesto en producción.
Utilización de los informes
176
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Es indispensable el uso de herramientas de apoyo a la gestión y seguimientoo Herramientas de planificación y asignación de tareas de alto nivel
• Ej. MS-Project
o Herramientas de Definición y/o Especificación de Casos de Prueba• Ej. CaseMaker
o Herramientas de registro diario de resultados de pruebas• Ej. CaseMaker, o integradas al ambiente de pruebas : VSTS, Rational…
o Herramientas de seguimiento de incidentes• Ej. Mantis, y varias otras más o menos integradas al ambiente
o Herramientas de análisis de resultados y avance a partir de lo ejecutado realmente
• Ej. VSTS con funciones de análisis de cobertura
• Reportes y síntesis de errores
Herramientas de seguimiento
177
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 178
Gestión y Plan de Pruebas
Noción de Gestión de Pruebas
Organización
Seguimiento
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Las pruebas representan un proyecto dentro del proyectoo Responsabilidades, organización, recursos, objetivos, plan de
trabajo, seguimiento, evaluación de resultados, mejora continua
• Estimar los recursos de acuerdo con el entornoo Niveles de confianza inicial y objetivo final
o Grado de experiencia del equipo de pruebas
• Documentar plan según IEEE 829
• Realizar seguimiento sistemáticoo Realizado versus lo planeado
o Identificación de defectos y su estatus en todo momento
o Disponer de algunas métricas pertinentes
Conclusiones
179
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Estrategias de mejora de la actividad de
Pruebas de Software
Estrategias de mejora de la actividad de
Pruebas de Software
Capítulo 8Capítulo 8
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 181
Estrategias de mejora
TMMi
TPI
Estrategia de mejoras
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 182
• TMMi inspirado de enfoque de CMMio Propuesto por el IIT (Illinois Institute of Technology)
o Modelo de 5 niveles de madurez en Pruebas de Software
• Marco referencial para la mejora continua de proceso de Pruebas de Software
• Mecanismo de evaluación• www.tmmifoundation.org
TMMi - Testing Maturity Model Integration
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 183
• Cinco fases de Boris Beizer:
Madurez de la actividad de pruebas
Fase 0 No existe diferencia entre Pruebas y Debug
Fase 1 La actividad de pruebas está dirigida a mostrar que el software funciona bien
Fase 2 La actividad de prueba está dirigida a poner en evidencia los defectos del software
Fase 3 Las pruebas son una actividad que reduce el riesgo de mal funcionamiento del software, hasta alcanzar un nivel aceptable
Fase 4 Las pruebas no son una actividad en si misma, sino una disciplina mental inmersa en el conjunto del equipo de desarrollo, permitiendo la construcción de software de alta calidad
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 184
TMMi
5 Optimización, Prevención
Optimización del proceso de pruebasControl de calidadUtilización de los datos para hacer previsiones de defectos
4 Métricas y Gestión
Evaluación de la calidad del softwarePrograma de métricas asociado a las pruebasPlan de Revisión sistemática a nivel de la empresa
3 Integración Control y seguimiento del proceso de pruebasIntegración de Pruebas en el proceso de desarrolloAplicar plan de formación técnica específicaEstablecer un Equipo de Pruebas de Software
2 Fase de Definición
Formalizar las técnicas y métodos de baseIniciar un proceso de Planificación de las PruebasEstablecer Objetivos de las pruebas
1 Inicial No existe función específica de pruebasEnsayos informales e incompletos realizados por el equipo de desarrollo
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 185
Estrategias de mejora
TMMi
TPI
Estrategia de mejoras
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Marco de referencia para la mejora progresiva de la actividad de Pruebas de Softwareo Propuesto a fines de lo años 90 por Sogeti.
• Identifica 20 áreas principales en la actividad de Pruebaso Para cada área define niveles de madurez (A-D)
o Propone un modelo de mejora continua, sin niveles globales
• Plan de mejora paso a pasoo Utilizan una matriz de madurez, mostrando las 20 áreas, los niveles
de madurez y su lugar relativo en el proceso de mejora
o Integrarse a un proceso CMM-I nivel 3
TPI – Test Process Improvement
186
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 187
Estrategias de mejora
TMMi
TPI
Estrategia de mejoras
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 188
Mejoras en varios planos…
1. Procesos de Desarrollo de Software
2. Gestión de los Proyectos
3. Calidad de los Productos
Procesos de Pruebas de Software
Gestión de la actividad de Pruebas
Identificación de objetivos y plan de pruebas adaptado
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Estrategia por niveles del TMMi
• Estrategia por contenidos del TPI
• Estrategia propia, específica a la empresa
Enfoques posibles
189
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Evaluación del nivel actual en el que estamos
• Pasar al nivel superioro Proyecto de más de un año en promedio
• Identificar y priorizar mejoras sobre nuestros puntos débileso Dependiendo del tipo de producto
o Dependiendo de los problemas que hemos encontrado en el pasado
o Dependiendo de nuestra capacidad de acción en los próximos meses
Estrategia TMMi + adaptación
190
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• ¿Cómo determinar en qué nivel estamos hoy?o Guía de autoevaluación
o Identificación de las consecuencias (y su gravedad)
o Identificación de las prioridades en los resultados buscados
Evaluación…
191
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Es el caso más frecuente
• ¿Qué resultados debemos exhibir en el nivel 2?o Asignación de un Responsable de Pruebas para el proyecto
o Documento simple del Plan de Pruebas
o Identificar los objetivos de las pruebas• Focalizado en sistematizar y hacer más completas las pruebas funcionales y
nominales
• Puede incluir algo de performances
o Formalizar técnica de pruebas• Focalizado en “caja negra”, usando Particiones de Equivalencia
o Normalizar forma de especificación de Casos de Prueba• Usar documento simple
o Hacer seguimiento del plan de pruebas
Pasar del nivel 1 al 2
192
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Mejora muy importante
• ¿Qué resultados debemos exhibir en el nivel 3?o Equipo de Pruebas estable
o Actividades de prueba en todo el proceso de desarrollo• Introducir revisiones e inspecciones
• Noción de pruebas estáticas
o Procedimiento de seguimiento sistemático• Qué ha sido probado y su resultado
• Trazabilidad de los casos con error
• Gestión de incidencias
o Aplicar niveles de prueba• Nivel de Componentes y de Integración
o Sistematizar lecciones aprendidas
Pasar del nivel 2 al 3
193
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Alta calidad del proceso y del equipo de pruebas
• ¿Qué resultados debemos exhibir en el nivel 4?o Evaluación de la calidad a través de métricas
o Utilización avanzada de técnicas de prueba• Casos de prueba guiados por el riesgo
• Casos de prueba para aspectos no funcionales
Pasar del nivel 3 al 4
194
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 195
Estrategias de mejora
TMMi
TPI
Estrategia de mejoras
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 196
Conclusiones 1
• Es indispensable mejorar la metodología de desarrolloo Mayores exigencias del mercado
o Mayor complejidad de la tecnología
o Mayor competencia internacional
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 197
Conclusiones 2
• El modelo de desarrollo depende del tipo de proyectoo No existe modelo universal
o Existe un modelo adecuado a vuestro caso
o Incluir tríptico: proyecto, procesos, producto
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 198
Conclusiones 3
• Avanzar en mejoras progresivaso Apuntar a mejoras a mediano plazo
o Introducir y consolidar mejoras parciales
o Combinar motivación y voluntad política
o Utilizar modelo “por escalones” del SEI
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 199
Conclusión 4
• La actividad de Pruebas en el corazón del desarrolloo Referencial del modelo TMMi
o Establecer Equipo de Pruebas con grado de independencia de las pruebas dentro del proyecto
o Utilizar Plan de Pruebas y definir actividades en cada nivel del desarrollo
o Disponer de herramientas de gestión y de seguimiento
o Herramientas de gestión de incidentes y estatus de los defectos
o Introducir plan sistemático de mejora continua
o Prever de incluir la formación y la certificación de profesionales de pruebas
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• www.funtec.org.ar a partir del jueves 29 de abril
• Contacto con Hermann Steffen :
• hermann.steffen@active.com.uy
Material disponible en ….
200
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 201
• ISTQB
o Syllabus Foundation Level 2007
o Syllabus Advanced Level 2007
o Glossary 2007
o Glosario Inglés-Español v0.911– SSTQB – (Comité Español de Testing - “Spanish Software Testing Qualifications Board”)
Para preparar el examen de ISTQB (niveles Foundation y Advanced):
• Software Testing Foundations, Andreas Spillner – 2007 (ISTQB)
• Software Testing Practice: Test Management, Andreas Spillner – 2007 (ISTQB)
• Advanced Software Testing vol 1 (Advanced Test Analyst). Rex Black, 2008
• Advanced Software Testing vol 2 (Advanced Test Manager). Rex Black, 2008
• Pragmatic Unit Testing (in C# with Nunit), Andrew Hunt – 2007 (2nd edition)
• Unit Test Frameworks, Paul Hamill – 2005
• Software Testing and Analisys, Mauro Pezzè, 2008
• Practical Model-Based Testing, Mark Utting, 2007
• Test Process Improvement, Tim Koomen, 2001
• Managing the Testing Process, Rex Black, 2002
• Le test des logiciels, Spyros Xandthakis, 2000
• Test Logiciel en Pratique, John Watkins, 2002
Bibliografía
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 202
• www.istqb.org
• www.sstqb.es
• www.gasq.org
• www.testingexperience.com
• www.tmmifoundation.org
•
Otras referencias
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Fin
203
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Terminología y Ejercicios
Terminología y Ejercicios
Anexo 1Anexo 1
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 205
• Prueba de Confirmacióno Volver a probar una nueva versión del software para un caso de
prueba que ha mostrado error, con el fin de verificar si ha sido corregido.
• Criterio de salidao Conjunto de condiciones generales y específicas, aceptadas por el
cliente, tal que permiten que el proceso sea oficialmente terminado.
o Evitar ambigüedad y malos entendidos respecto al momento de dar por terminada una prueba
• Incidenciao Un evento ocurrido que requiere investigación
Terminologia
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 206
• Prueba de regresióno Prueba de un software previamente probado en una versión
anterior, para verificar que en la nueva versión no se han introducido errores.
• Base de pruebas (baseline)o La documentación en la que se basan los casos de prueba. Es el
conjunto de documentos de donde los requisitos de un componente o sistema se pueden inferir. (caso de base de pruebas congelada)
• Condición de pruebao Un ítem o evento de un componente o sistema que debería ser
verificado por uno o más casos de prueba, p.ej. una función, transacción, rasgo, atributo de calidad o elemento estructural.
Terminología
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 207
• Cobertura de las pruebaso Porcentaje en el cual se ha realizado pruebas a un elemento, con
relación a una serie potencial de pruebas
• Datos de pruebao Datos que existen previos a la ejecución de la prueba y que afectan
o son afectados por el sistema bajo prueba.
• Ejecución de pruebao Proceso de utilización de un componente o sistema, produciendo
resultados reales.
• Política de pruebaso Documento de alto nivel describiendo principios, enfoques y los
objetivos principales con relación a las pruebas de software
Terminología
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 208
• Estrategia de pruebaso Descripción general que indica qué niveles de prueba deben ser
realizados y los tipos de prueba en cada nivel.
• Serie de pruebaso Conjunto de casos de prueba para un componente, donde la post
condición de uno es usualmente la pre-condición del siguiente caso de prueba.
• Elementos (utensilios) de pruebaso Artefactos producidos durante el proceso de pruebas, necesarios
para planificar, concebir y ejecutar las pruebas, tales como documentos, guiones, datos de entrada y de salida, procedimientos de ejecución, archivos, entornos y otros software o herramientas utilizadas para las pruebas.
Terminología
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 209
• Generación de casos de prueba estructuralesValidar_tarjeta (Tarjeta, estatus_tarjeta, estatus_pw)Begincant_intentos = 0; estatus_pw = FALSE; estatus_tarjeta= FALSE
if (estatus(Tarjeta) == ROBADA) tragar (Tarjeta)
else estatus_tarjeta = TRUE while ((cant_intentos < MAX) AND (estatus_pw == FALSE))
ingresar_password(pw)if (eval_password(pw) == TRUE)
estatus_pw = TRUEcant_intentos = cant_intentos+1
endw if (estatus_pw == FALSE)
tragar (Tarjeta)End
Ejercicio : cobertura de decisiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
o Función: Autentificación.• El usuario ingresa su tarjeta bancaria y espera para ingresar su código. El lector
de tarjetas extrae el número de tarjeta. La función solo aceptará tarjetas que no se encuentren en la “lista negra”. Si la tarjeta se encuentra en la “lista negra” será tragada por el cajero automático. El usuario dispone de hasta una cantidad MAX de intentos de ingreso de su número de identificación. En caso de superarse esa cantidad MAX la autorización será denegada y la tarjeta será tragada. Si la tarjeta no está en la “lista negra” y si el usuario ingresa correctamente su número de identificación la función autorizará al usuario. Se utilizarán las variables de salida “estatus_tarjeta”, “estatus_número_identificacion”, “autorizacion”, y “número de tarjeta”.
o Aplicar una Revisión de tipo “Inspección” para evaluar la especificación
• Corregir si fuese necesario…
o Aplicar técnica de generación de casos de prueba utilizando Partición de Equivalencias
• Solo considerar el caso del funcionamiento normal, sin fallas del entorno.
Ejercicio Inspección y Caso de Prueba
210
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Variables pertinentes:
V1: Validez_de_tarjeta (Tarjeta, Lista_Negra)• Particiones :
– Tarjeta_OK, Tarjeta_Robada, Tarjeta_ilegible, Tarjeta_no_responde
Particiones de equivalencia
211
V2: Número_Personal_OK (Tarjeta, Número_ingresado, cant_intentos, MAX)
• Particiones :– PIN_OK, PIN_KO, Error_lectura, PIN_no_responde
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Análisis de Particiones…
212
TarjetaOK
TarjetaRobada
TarjetaIlegible
TarjetaNo responde
PIN_OK A B C D
PIN_KO E F G H
PIN_ errorLectura I J K L
PIN no responde M N O P
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Casos de Prueba
213
CasoNro
PE/Variables
Tarjeta PIN EstatusTarjeta
EstatusPIN
Tarjeta
1 A OK OK TRUE TRUE Devuelta
2 E OK KO TRUE FALSE TRAGADA
3 I OK Error lectura
TRUE FALSE Devuelta
4 M OK No responde
TRUE FALSE TRAGADA
5 B KO ----- FALSE FALSE TRAGADA
6 C Errorlectura
----- FALSE FALSE TRAGADA
7 D No responde
------ FALSE FALSE TRAGADA
CódigoError
CE_00
CE_01
CE_02
CE_03
CE_04
CE_05
CE_06
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Sistema Relojes BasketballEl sistema de relojes debe llevar el control de dos relojes: Tiempo Restante de Juego (TRJ) y 24 segundos (R24). TRJ tiene tres botones: Inicio_de_cuarto, Marcha, Stop. Inicio_de_quarto, posiciona el reloj en 10:00 (minutos) y R24 se pone en Espera24. Al accionarse el botón de Marcha comienza la cuenta regresiva y se habilita el botón de Reanudar de R24. Para que comience la cuenta regresiva del R24 debe apretarse su propio botón de Reanudar.
o Si se aprieta Stop el TRJ se detiene y también el R24.
o R24 tiene un botón Reanudar, que continúa la cuenta regresiva a partir de donde está, un botón Espera24 que detiene el reloj y lo posiciona en 24 segundos y un boton Nuevo24 que posiciona el reloj en 24 e inmediatamente reanuda la cuenta regresiva.
o Si R24 llega a cero, esto detiene ambos relojes, y pone a R24 en posición inicial, detenido.
Ejercicio DTE
214
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Estados posibleso D: Detenido
o M: En Marcha
o D0 : Detenido en Cero
• Eventos posibles del TRJo Inicio de Cuarto (10:00)
o Marcha (botón de marcha)
o Stop (botón de Stop)
o Llega a cero (evento)
Relojes Basket: TRJ…
215
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Estados posibleso D24: Detenido en posición de 24 segundos
o DR: Detenido en medio de una posesión
o M: En Marcha
o D0: Detenido en Cero
• Eventos posibleso Posicionar en 24 (botón o evento)
o Reanudar (botón)
o Pausa (botón o evento)
o Nuevo 24 (botón)
o Llega a cero (evento)
Relojes Basket: R24…
216
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Matriz de estados
217
DR Detenido para Reanudar
D24Detenido con valor 24
MEn marcha
D0Detenido en cero
D: Detenido D/DR D/D24 D/M D/D0
M: Marcha M/DR M/D24 M/M M/D0
D0: Detenido en Cero
D0/DR D0/D24 D0/M D0/D0
X
XXX
XX
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Diagrama de Transición : Reloj
218
D/D24
M/D24
M/M
D0/D0
M/DR
Nuevo24
MarchaStop
Stop
Posicionar24
Rea
nuda
r
Cer
o24
Lleg
aCer
o
Inic
ioC
uart
oInicioCuarto
Marcha
D/DR
Reanudar
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
DTE del Reloj
219
D/D24 D/DR D0/D0 M/D24 M/DR M/M
D/D24 NO NO NO Marcha NO NO
D/DR Posic24 NO NO NO Marcha NO
D0/D0 Inicialcuarto
NO NO NO NO NO
M/D24 NO Stop NO NO NO Reanudar
M/DR NO NO NO NO NO Reanudar
M/M NO Stop llegacero Cero24 NO Nuevo24
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Casos de Prueba DTE Reloj
220
NroCaso
Estado de partida
Estado de llegada
Evento a ser generado
Contexto en el que se debería producir el caso
1 D/D24 M/D24 Marcha Inicio del cuarto
2 D/DR D/D24 Posicion24 Pelota muerta y no hay posesión
3 D/DR M/DR Marcha Pelota viva de nuevo
4 D0/D0 D/D24 Iniciocuarto Preparar relojes para iniciar el cuarto
5 M/D24 D/DR Stop Interrupción del juego, pelota muerta
6 M/D24 M/M Reanudar Equipo toma posesión
7 M/DR M/M Reanudar Equipo continúa con la posesión
8 M/M D0/D0 Llegacero Tiempo cumplido del TRJ
9 M/M M/M Nuevo24 Pelota sigue viva, cambio de posesión
10 M/M D/DR Stop Interrupción del juego, pelota muerta
11 M/M M/D24 Cero24 Fin de posesión, pelota sigue viva
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Arbol de Transición : Reloj
221
D/D24
M/D24
M/M
M/DR
Marcha
Stop
Reanudar
Cero24
InicioCuarto
Marcha
D/DR
ReanudarM/M
M/D24
D0/D0
LlegaCero M/M
Nuevo24
M/D24
Cero24
D/D24
Posicionar24
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Casos de Prueba: DTE dinámica
222
NroSerie
Descripción Casos a ejecutar
1 Desarrollo desde inicio cuarto, juego, posesión, pelota fuera y retome de posesión hasta agotar los 24 s.
1, 6, 10,3, 7, 11
2
3
4
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Normas y Certificaciones
Normas y Certificaciones
Anexo 2Anexo 2
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 224
Normas de Documentación
Normas de Procesos
Normas de Productos
Evaluación y modelo de madurez
ISTQB y Certificaciones personales
Normas, Institutos y Certificaciones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 225
• IEEE posee larga tradición en normalización de documentoso Norma 830 para Especificación de Requisitos
o Norma 1016 para Especificación de la Concepción/Diseño
o Norma 1061 para Medidas del Software
o Norma 730 para Aseguramiento de la Calidad
o Norma 610 Glosario de términos en Ingeniería de Software
o Norma 1044 Clasificación de Anomalías de Software
• IEEE 829 ( mayo 2008) – Software Testingo Conjunto de normas para la redacción del conjunto de la
documentación asociada a las Pruebas de Software.
• Nueva norma ISO 29119 (para 2011)
IEEE para Pruebas de Software
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 226
Normas de Documentación
Normas de Procesos
Normas de Productos
Evaluación y modelo de madurez
ISTQB y Certificaciones personales
Normas, Institutos y Certificaciones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 227
• Orientado a la definición de los procesos
• Definir el proceso de pruebas de softwareo En el marco de ISO 9001
o No es específico para el software, pero se adapta bien
o Permite la definición de aspectos organizacionales, responsabilidades, herramientas, y procesos de prueba de software
ISO para las Pruebas de Software
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 228
Normas de Documentación
Normas de Procesos
Normas de Productos
Evaluación y modelo de madurez
ISTQB y Certificaciones personales
Normas, Institutos y Certificaciones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 229
• Especifican requisitos del producto integrado• El software es uno de los componentes en un sistema embebido
• Automovilistica• MISRA-C 2004 (Motor Industry Software Reliability Association).
Reglas de escritura para lenguaje C y C++.
• Electromecánicos• Seguridad de funcionamiento y operación.
• Aeronáuticos
• Energía atómica
• Bancarios
Normas relativas al producto
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 230
Normas de Documentación
Normas de Procesos
Normas de Productos
Evaluación y modelo de madurez
ISTQB y Certificaciones personales
Normas, Institutos y Certificaciones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 231
• TMM inspirado de enfoque de CMMio Propuesto por el IIT (Illinois Institute of Technology)
o Modelo de 5 niveles de madurez en Pruebas de Software
• Marco referencial para la mejora continua de proceso de Pruebas de Software
• Mecanismo de evaluación• www.tmmifoundation.org
TMMi - Testing Maturity Model Integrating
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Marco de referencia para la mejora progresiva de la actividad de Pruebas de Softwareo Propuesto a fines de lo años 90 por Sogeti.
• Identifica 20 áreas principales en la actividad de Pruebaso Para cada área define niveles de madurez (A-D)
o Propone un modelo de mejora continua, sin niveles globales
• Plan de mejora paso a pasoo Utilizan una matriz de madurez, mostrando las 20 áreas, los niveles
de madurez y su lugar relativo en el proceso de mejora
o Integrarse a un proceso CMM-I nivel 3
TPI – Test Process Improvement
232
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 233
Normas de Documentación
Normas de Procesos
Normas de Productos
Evaluación y modelo de madurez
ISTQB y Certificaciones personales
Normas, Institutos y Certificaciones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Modelos de previsión y estimación de fiabilidad
del software
Modelos de previsión y estimación de fiabilidad
del software
Anexo 3Anexo 3
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 235
Modelos de previsión y estimación
Fiabilidad del software
Modelos de fiabilidad
Modelos de predicción
Modelos de estimación
Modelos de evaluación
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Fiabilidado Habilidad de un producto software para realizar las funciones
requeridas condiciones establecidas para un periodo de tiempo específico, o para un número específico de operaciones. [ISO 9126]
o Estrictamente no es posible de conocer la fiabilidad sino en el marco de su utilización real, durante el período de uso considerado (normalmente un período largo).
Fiabilidad
236
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Evaluación de fiabilidado Para anticipar el conocimiento de la fiabilidad, sin tener que medirla
a posteriori, se han concebido modelos de evaluación de la fiabilidad
o Utilizar para modelar la información relativa a las características del software (código fuente) y de los defectos encontrados durante la fase de pruebas.
• Varios modeloso Fuertemente inspirados de la experiencia con el hardware y
componentes electrónicos
o Modelos estadísticos, basados en la observación del hardware en funcionamiento
o Modelos de previsión, basados en la estructura del hardware, que tienen componentes de base conocidos (cuya fiabilidad es conocida y disponible en bases de datos MIL HDBK 217, NASA…)
Modelar para poder evaluar
237
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 238
Modelos de previsión y estimación
Fiabilidad del software
Modelos de fiabilidad
Modelos de predicción
Modelos de estimación
Modelos de evaluación
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Modelos de prediccióno Proponen anticipar la fiabilidad del software a partir del estudio de
su complejidad o de características de su estructura interna
• Modelos de estimacióno Proponen calcular la fiabilidad utilizando los resultados de las
pruebas realizadas, observando la detección de defectos introducidos a propósito o usando un referencial de muestreo de datos
• Modelos de evaluacióno Proponen calcular la fiabilidad a partir de los resultados de pruebas
realizados sobre el software real, en condiciones lo más realistas posibles (pruebas de sistema y pre-producción)
Modelos de cálculo
239
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 240
Modelos de previsión y estimación
Fiabilidad del software
Modelos de fiabilidad
Modelos de predicción
Modelos de estimación
Modelos de evaluación
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Información de baseo Realizar cálculos a partir del código fuente (estático)
• Modelo de Halsteado Propone una estimación de la cantidad de defectos a partir de
ciertos parámetros del software: cantidad de operadores y de operandos diferentes, frecuencia de utilización de los mismos.
• Modelo de McCabeo Cálculo de la complejidad a partir del Número Ciclomático
o No propone deducir directamente la fiabilidad a partir de esta complejidad
• Modelo de Cheungo Utiliza la base de McCabe, pero agrega el análisis de
funcionamiento dinámico (invocaciones) entre módulos, partiendo de conocer la fiabilidad de cada componente (pruebas unitarias)
Modelos de predicción
241
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 242
Modelos de previsión y estimación
Fiabilidad del software
Modelos de fiabilidad
Modelos de predicción
Modelos de estimación
Modelos de evaluación
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Modelo de inyección de defectoso Introducir artificialmente defectos, generar secuencias de pruebas y
contar la cantidad de defectos “nativos” frente a los defectos inyectados. Extrapolar a partir de esa proporción para estimar los defectos resultantes.
• Modelo de pruebas independienteso Realizar pruebas por parte de dos equipos de prueba separados y
no conectados, usando casos y juegos de datos independientes. Estimar a partir del análisis de los resultados obtenidos.
Principales estrategias de estimación
243
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Modelo de muestreo de datoso Realizar pruebas usando juegos de datos aleatorios, midiendo la
cantidad de datos que han generado defectos. Extrapolar en función del tamaño de la muestra.
• Modelos estadísticoso Basados en el análisis de defectos de proyectos terminados y en
producción, del cuál se pueda hacer la hipótesis que la casi totalidad de los defectos ya ha sido puesta en evidencia.
o Para esos proyectos conocer la cantidad de defectos encontrados durante las fases de prueba y la cantidad total de defectos.
o Extrapolar ponderadamente esta información hacia otros proyectos en construcción (ponderar según el lenguaje utilizado, el contexto de desarrollo, etc).
Principales estrategias de estimación
244
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Inyectar defectos en un software antes de ser probadoo Se parte de la hipótesis simplista de que los defectos inyectados
serán de la misma naturaleza que los defectos nativos, y de que la probabilidad de detección es la misma para ambos tipos
• D: cantidad de defectos nativos, lo que se desea estimar
• I: cantidad de defectos inyectados
• D: cantidad de defectos nativos detectados
• i: cantidad de defectos inyectados detectados
• Tendremos entonces : i = d , D = d x I I D i
• Alcance del modelo• Gran dificultad para generar defectos inyectados que sean “equivalentes” a los
nativos
• Algunos defectos inyectados van a esconder defectos nativos
• La pertinencia del diseño de casos de prueba que sean equivalentes para los diferentes tipos de defecto.
Modelo de inyección de Mills
245
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 246
Modelos de previsión y estimación
Fiabilidad del software
Modelos de fiabilidad
Modelos de predicción
Modelos de estimación
Modelos de evaluación
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Observación de los defectos en situación real• Se parte de la hipótesis del aumento de la fiabilidad con el tiempo,
debido a la corrección de defectos que provocaron fallas.
• Se asume que las correcciones no generan nuevos defectos
• Modelos estocásticos organizados en torno a una variable:• La variable aleatoria es el tiempo entre dos fallas (se asume las fallas siguen
una distribución exponencial). No indica la cantidad de errores calculados sino el tiempo hasta la próxima falla (MTTF). Modelo Littlewood-Verral.
• La variable aleatoria es la cantidad de ocurrencias de fallas (se asume que cada defecto provoca una falla según una distribución de Poisson).
– Modelos determinísticos, donde cada defecto tiene la misma probabilidad de aparición. (Jelinski-Moranda).
– Modelos no homogéneos, donde la probabilidad de aparición sigue una distribución de Poisson no homogénea. (Musa).
Modelos de evaluación de fiabilidad
247
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Existen varios productos que permiten realizar los cálculos
Software de cálculo de fiabilidad
248
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 249
Modelos de previsión y estimación
Fiabilidad del software
Modelos de fiabilidad
Modelos de predicción
Modelos de estimación
Modelos de evaluación
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Modelos útiles para complementar las mediciones de resultados de pruebas• Algunas veces el valor calculado por un modelo es utilizado
complementariamente como un criterio de salida de las pruebas
• No debe ser utilizado como criterio de validez de un software.
• No se consideran modelos válidos para calcular una fiabilidad alta• Errores inferiores a 1/1000.
• Es necesario ponderar los resultados utilizando un historial propio
• Usualmente se introducen en el nivel 4 CMM-I o En tanto planes cuantitativos de la fiabilidad y planes de
mediciones sistemáticas con fines estadísticos
Alcance de los modelos
250
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Herramientas de Pruebas
Herramientas de Pruebas
Anexo 4Anexo 4
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010 252
Herramientas de Pruebas
Clasificación de Herramientas
Organización
Plan de Pruebas
Seguimiento
Conclusiones
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Apoyo al Equipo de Pruebas en varias etapas y actividadeso Gestión, automatización, seguimiento, generación de casos, arnés
• Clasificadas según su función
• Algunas son intrusivaso Incrustan instrucciones en el código aplicativo
o Pueden alterar el comportamiento tanto funcional como sobre todo el rendimiento
o Se debe realizar pruebas finales sin las instrucciones agregadas
• Algunas están en la frontera desarrollo/pruebaso Análisis dinámico de rendimiento, perfil de ejecución, modelado y
análisis de ejecución de base de datos, cobertura
Herramientas de pruebas
253
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
o Gestión de pruebas• Gestión de pruebas, Gestión de Requisitos (RM), Gestión de Incidentes, Gestión
de Configuración
o Pruebas estáticas• Revisión, Análisis Estático, Modelado de Software, Medidas Complejidad
o Especificación de pruebas• Especificación de casos de prueba, Generación de datos
o Ejecución y registro de pruebas• Robots de ejecución, Arnés de ejecución, Comparadores, Medida de Cobertura
o Rendimiento y supervisión• Medidas de rendimiento, Análisis dinámico y perfil de ejecución, supervisión de
ejecución y recursos consumidos
o Especializadas• Orientadas a Web, especializadas en plataformas, orientadas a estándares
industriales o productos, orientadas a seguridad
o Otras• Cálculos de previsión y estimación, debugging
Clasificación de herramientas
254
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Herramientas que permiten automatizar pruebas funcionaleso Existen desde hace 2 décadas
o Propietarias, integradas, open source.
o Requieren un gran esfuerzo de especificación y preparación de los casos de prueba, para cada caso de prueba.
• Son rentables para casos de muchas ejecuciones para la misma prueba
• Son muy costosas en tiempo de preparación para pruebas de 1 o pocas veces para cada caso de prueba. Pueden ser una inversión para la ejecución de pruebas de no regresión…
Robots de Ejecución
255
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
Niveles de automatización
256
Software bajo Pruebas
(SUT)
Generador de Casos a partir de especificaciones
Caso 1
Resultado 1
2
13
4
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• Las herramientas no son simples de introducir en el proceso de pruebaso Las herramientas permiten automatizar o sistematizar
procedimientos ya consolidados y precisos.• Si no hay procedimientos, hay primero que consolidarlos.
• Una herramienta inadecuada o inoportuna puede ser un freno al proceso de mejoras de las pruebas.
o Las herramientas deben estar integradas o interoperar con el entorno de desarrollo
• De lo contrario se manejan modelos diferentes que no permiten o dificultan muchísimo la relación entre pruebas y desarrollo
o La curva de aprendizaje es generalmente prolongada
o Los herramientas están aun en una segunda generación• Su grado de inteligencia y flexibilidad es bastante limitado
• No tienen la flexibilidad de una persona para entender lo que hay que hacer e improvisar para resolver las dudas o incompletitudes de las especificaciones de pruebas
Utilización de herramientas
257
Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires , Abril 2010
• La actividad de Pruebas requiere el apoyo de herramientaso Existe una amplia variedad y calidad de herramientas
• Las herramientas deben ser coherentes e integradas con el ambienteo Usar el mismo modelo y lenguaje de referencia
• Las herramientas deben ser el paso posterior a la formalización de procedimientos internoso No se puede automatizar lo que no se ha formalizado antes
• Establecer proceso progresivo de incorporación de herramientaso De acuerdo con el proceso interno del área Pruebas y del área
Desarrollo en general.
Conclusión
258
Recommended