Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires,...

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


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


• 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


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


• 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


• 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…


• 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…


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


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.


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


• 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


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


• 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…


• 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


• 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


• 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


7 Principios Básicos7 Principios Básicos


• 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


• 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…


• 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…


El Equipo de Test en el Ciclo de Desarrollo

El Equipo de Test en el Ciclo de Desarrollo



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


• 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…


• 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


• 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


• 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


• 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


• 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






Conclusiones



• 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


• 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






Conclusiones



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


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



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


Externos

5

Jefe de Proyecto

DesarrolloTesting

AQ

Jefe de Proyecto

DesarrolloPPAQ AQ







Conclusiones



• 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


• 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



• 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



• Conceptor de test• Experto en técnicas de test (Estático, Estructural, Funcional, No-

funcional).

• Realización de especificaciones de casos de prueba



• 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







Conclusiones



• 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


Procesos Fundamentales de

Testing

Procesos Fundamentales de

Testing



• 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


• 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 …


• 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…


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


Principales Niveles de test

Principales Niveles de test



• ¿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


• 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


• 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


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


Aspectos técnicos del testing y diseño de casos de prueba

Aspectos técnicos del testing y diseño de casos de prueba



• Estática• Inspección de código

• Análisis estático

• Dinámicao Funcional

o No funcional

o Estructural

Tipos de prueba


• 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


• 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


• 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


• 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


Noción de Pruebas Estáticas

Análisis de código

Herramientas

Conclusión

Pruebas estáticas


• 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



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





• 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




Herramientas

Conclusión

Pruebas estáticas


• 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




Herramientas

Conclusión

Pruebas estáticas


• PR:QA

• QAC

• PC Lint

• LDRA Tool Suite

• Logiscope

Herramientas


• 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


Pruebas EstructuralesPruebas Estructurales


• 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


Noción de Pruebas Estructurales

Estructura de los programas

Cobertura estructural

Casos de Prueba Estructural

Herramientas

Conclusión



• 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


casos posibles

o Diferentes tipos de cobertura estructural• De Sentencias, de Decisiones (Rama), de Condiciones


• Pueden realizarse en todos los niveles de pruebao Especialmente en pruebas unitarias y de integración







Herramientas

Conclusión



• 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



• 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


• 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






Herramientas

Conclusión




casos posibles

o Diferentes tipos de cobertura estructural• De Sentencias, de Decisiones (Ramas), de Condiciones,




• 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



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



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






Herramientas

Conclusión



• 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


• 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






Herramientas

Conclusión



• 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


• 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








tragar (Tarjeta)End


1

23

4

5

6

78

9

1011

1213

1

32

4

5

6

789

1112

10

1413

16 15


• 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


• 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


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

…






Herramientas

Conclusión



• 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


Pruebas FuncionalesPruebas Funcionales


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


• 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


• Técnica aleatoriao El probador elige juego de datos al azar

Generar casos de prueba…


• 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…





Tablas de Decisión


Casos de Uso

Pruebas Funcionales


• 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


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%


• 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





Tablas de Decisión


Casos de Uso

Pruebas Funcionales


• 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


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





Tablas de Decisión


Casos de Uso

Conclusiones

Pruebas Funcionales


• 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


• 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


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…)





Tablas de Decisión


Casos de Uso

Pruebas Funcionales


• 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


• 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


• 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


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


• 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





Tablas de Decisión


Casos de Uso

Pruebas Funcionales


• 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


• 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


Pruebasno-funcionales

Pruebasno-funcionales


Atributos no funcionales del software

Usabilidad

Robustez

Rendimiento

Otros

Conclusiones

Pruebas no-funcionales


• 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



Usabilidad

Robustez

Rendimiento

Otros

Conclusiones



• 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


• 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


• 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


• 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


• 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….


• 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…


• 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…


• 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



Usabilidad

Robustez

Rendimiento

Otros

Conclusiones



• 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


• 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


• 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


• 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



Usabilidad

Robustez

Rendimiento

Otros

Conclusiones



• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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



Usabilidad

Robustez

Rendimiento

Otros atributos

Conclusiones



• Seguridad

• Eficiencia

• Integridad

• Disponibilidad

• Facilidad de Mantenimiento

• Facilidad de Evolución

• Portabilidad

Otros atributos no-funcionales



Usabilidad

Robustez

Rendimiento

Otros atributos

Conclusiones



• 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


Redacción del Plan Maestro de TestingRedacción del Plan Maestro de Testing



• 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


• 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 …


• 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


• 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


• 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


• 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


• 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


• 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


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


• 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


• 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


Pruebas


Pruebas

Especificación Casos de Prueba

Especificación Procedimientos

de Prueba


• Parte ejecución de pruebas…

Redactar el Plan de Pruebas

164

Informe de resumen de

Pruebas

Diario de Pruebas

Informe de Incidentes de

Prueba


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


• 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


Gestión y Plan de Pruebas





Noción de Gestión de Pruebas

Organización

Seguimiento

Conclusiones


• 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


169




Organización

Seguimiento

Conclusiones


• 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


• 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


• 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




Organización

Seguimiento

Conclusiones


• 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


• 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


• 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




Organización

Seguimiento

Conclusiones


• 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


Estrategias de mejora de la actividad de

Pruebas de Software

Estrategias de mejora de la actividad de

Pruebas de Software



Estrategias de mejora

TMMi

TPI

Estrategia de mejoras

Conclusiones


• 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

http://www.tmmifoundation.org/


• 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


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



TMMi

TPI


Conclusiones


• 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



TMMi

TPI


Conclusiones


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


• Estrategia por niveles del TMMi

• Estrategia por contenidos del TPI

• Estrategia propia, específica a la empresa

Enfoques posibles

189


• 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


• ¿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


• 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


• 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


193


• 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


194



TMMi

TPI


Conclusiones


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


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


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


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


• www.funtec.org.ar a partir del jueves 29 de abril

• Contacto con Hermann Steffen :

• [email protected]

Material disponible en ….

200

http://www.funtec.org.ar/

mailto:[email protected]


• 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


• www.istqb.org

• www.sstqb.es

• www.gasq.org

• www.testingexperience.com

• www.tmmifoundation.org

•

Otras referencias

http://www.testingexperience.com/






Fin

203


Terminología y Ejercicios

Terminología y Ejercicios

Anexo 1Anexo 1


• 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


• 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


• 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


• 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








tragar (Tarjeta)End



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


• 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


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


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


• 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


• 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


• 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


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


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


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


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


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


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


Normas y Certificaciones

Normas y Certificaciones

Anexo 2Anexo 2


Normas de Documentación

Normas de Procesos

Normas de Productos

Evaluación y modelo de madurez

ISTQB y Certificaciones personales

Normas, Institutos y Certificaciones


• 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



Normas de Procesos

Normas de Productos





• 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



Normas de Procesos

Normas de Productos





• 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



Normas de Procesos

Normas de Productos





• 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



• 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



Normas de Procesos

Normas de Productos





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


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


• 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


• 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








Conclusiones


• 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








Conclusiones


• 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)


241








Conclusiones


• 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


• 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


• 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








Conclusiones


• 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


• Existen varios productos que permiten realizar los cálculos

Software de cálculo de fiabilidad

248








Conclusiones


• 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


Herramientas de Pruebas


Anexo 4Anexo 4



Clasificación de Herramientas

Organización

Plan de Pruebas

Seguimiento

Conclusiones


• 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


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


• 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


Niveles de automatización

256

Software bajo Pruebas

(SUT)

Generador de Casos a partir de especificaciones

Caso 1

Resultado 1

2

13

4


• 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


• 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

Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires,...

Documents

Transcript of Dr. Hermann Steffen | Las Pruebas en el Desarrollo de Software | Seminario FUNTEC – Buenos Aires,...