ANÁLISIS DINÁMICO DEL SO SSOFTWARE: PRUEBAS

ANÁLISIS DINÁMICO DEL SO SSOFTWARE: PRUEBAS

SSira VegasEvaluación de Sistemas de Información

Facultad de Informática - UPMCurso 08/09Curso 08/09

CONTENIDOS

Conceptos generales de evaluaciónóIntroducción a las pruebas de software

Organización de las pruebas de softwareOrganización de las pruebas de softwareTécnicas de pruebas de software

Conceptos Generales de l ióEvaluación

Análisis dinámico del software:Análisis dinámico del software: pruebas

Contenidos

IntroducciónIntroducciónNecesidad de la evaluaciónPapel de las pruebas de softwareE o falta falloError, falta y fallo

Introducción

Objetivos de la Ingeniería del Software. Construcción de:

Sistemas de calidadSistemas de calidadDentro de presupuestoA tiA tiempo

No consecución de objetivos => CRISIS jDEL SOFTWARE

Necesidad de la evaluaciónCoste de reparación del software

ETAPA COSTE RELATIVO R i it 0 1 0 2Requisitos 0,1--0,2Diseño 0,5 Codificación 1 Pruebas unitarias 2Pruebas unitarias 2Pruebas de aceptación 5 M i i 20Mantenimiento 20

Papel de las pruebas de swActividades de control y garantía de

calidad del software

Preventivas Correctivas (E l ió d )(Evaluación de sw)

Análisis estático Análisis dinámicoBuenos hábitos Análisis estático Análisis dinámico (pruebas)

Buenos hábitos de construcción del software (metodologías Examen en(metodologías, etc.)

- Examen en reposo- Aspectos

táti

- Examen resultado funcionamientoestáticos

- Cualquier producto sw

funcionamiento del sw- Aspectos d á

Error, falta y fallo

Distinción error/falta/fallo según IEEEError. Los humanos comenten errores con razonamientos no correctos

úFalta. Error escrito en algún producto softwareFallo. El sistema software no se comporta del

d d dmodo deseado

Término genérico defectoProblema: Relación no directa entre error/falta/fallo

Introducción a las Pruebas de S fSoftware


Contenidos

Niveles de madurez Definición de pruebaPrincipios de las pruebasPrincipios de las pruebasEl proceso de pruebasp p

Niveles de madurez

Nivel 0:Prueba es igual a depuraciónNivel 1: Demostrar que el software funcionaNivel 2: Demostrar que el software noNivel 2: Demostrar que el software no funcionaNivel 3: Reducir el riesgo de que el softwareNivel 3: Reducir el riesgo de que el software no funcioneNivel 4: La prueba es una disciplina mentalNivel 4: La prueba es una disciplina mental que conduce a software de bajo riesgo

Definición de prueba

Proceso de ejecutar un programa o sistema ó fcon la intención de encontrar defectos

Cualquier actividad dirigida a evaluar un atributo o capacidad de un programa o sistema y determinar que alcanza los resultados requeridosActividad necesaria de reunir información queActividad necesaria de reunir información que nos permita evaluar nuestro trabajo de forma eficienteeficiente

Principios de las pruebas (1/3)Las pruebas son el proceso de ejecutar un programa/sistema con la intención de descubrirprograma/sistema con la intención de descubrir defectos en el softwareUn buen caso de prueba es aquel que tiene una alta p q qprobabilidad de descubrir un defecto no encontradoSe deben definir las salidas o resultados esperados de los casos de pruebade los casos de pruebaSe debe realizar una inspección minuciosa de cada caso de pruebacaso de pruebaLos caos de prueba se escriben para condiciones de entrada válidas/no válidas y esperadas/inesperadas

Principios de las pruebas (2/3)La prueba del software se hace tanto para ver si no hace lo que se supone que debe hacersi no hace lo que se supone que debe hacer, como para ver si hace lo que se supone que no debe hacerUn programador debe evitar probar su propio programa

d b bUn equipo no debe probar sus propios programasSe debe evitar tirar/perder los casos de pruebaSe debe evitar tirar/perder los casos de pruebaNo se debe planificar el esfuerzo de la prueba bajo la creencia de que no se encontraránbajo la creencia de que no se encontrarán defectos

Principios de las pruebas (3/3)La probabilidad de la existencia de más defectos en una parte del software es proporcional al número deuna parte del software es proporcional al número de defectos ya encontrados en dicha parteLa prueba completa (exhaustiva) no es posiblep p ( ) pUna razón para la prueba es prevenir deficiencias antes de que ocurran

áLa prueba está basada en el riesgoLa prueba es una actividad extremadamente creativa, intelectual y difícilintelectual y difícil

El proceso de pruebas

Generación y especificación de los casos d bde pruebaEjecución de los casos de pruebaj pComparación de los resultados obtenidos con los esperadosobtenidos con los esperadosIdentificación de fallos en el sistemad f ó ó d l f lIdentificación y corrección de las faltas

que causaban los fallos

Organización de las Pruebas d S fde Software


Contenidos

ProblemáticaPruebas unitariasPruebas de integraciónPruebas de integraciónPruebas de sistemaPruebas de aceptaciónTi d i iTipos de organizaciones

Problemática

La depuración se complica a medida que aumenta el tamaño del softwareNecesidad de abordar la etapa deNecesidad de abordar la etapa de pruebas en fases para facilitar dicha ttareaSe comenzará a nivel de módulo y se yprogresará hacia el sistema completo

Pruebas unitariasObjetivo: Comprobar los productos resultantes de la codificacióncodificaciónCada módulo se prueba por separado y por la persona que lo creóMód l Pi d ódi lMódulo: Pieza de código que cumple:

Bloque básico de programaImplementa función independiente simplePuede probarse por separadoNormalmente menor de 500 líneas de código

En OO se suele hablar de prueba de clase o métodoEn OO se suele hablar de prueba de clase o métodoSe ha de comprobar que el módulo está correctamente codificado

Pruebas de integraciónObjetivo: Comprobar los productos del diseñoSe ha de comprobar:

Integridad de la interfazdRendimiento

Tipos de integraciónIncremental

AscendenteDescendenteDescendente

En profundidadEn anchura

N i t lNo incremental

Pruebas de integración: TiposIncremental Ascendente: Se combinan los módulos de más bajo nivel utilizando driversmódulos de más bajo nivel, utilizando drivers para los de más alto nivel.Incremental Descendente: Se comienzaIncremental Descendente: Se comienza en el módulo de mayor nivel y se incorporan los módulos subordinados bien en profundidad o anchuraprofundidad o anchura.No Incremental: Se utiliza un driver y uno o más stubs para simular el resto de loso más stubs para simular el resto de los módulos. Cada módulo se prueba por separado., y luego se juntan todos.

Pruebas de sistemaObjetivo: Comprobar que el sistema integrado de hardware y software cumple con los requisitoshardware y software cumple con los requisitos especificadosSe ha de comprobarp

Se cumplen los requisitos funcionales establecidos durante el análisis.El funcionamiento y rendimiento en las interfaces hardwareEl funcionamiento y rendimiento en las interfaces hardware, software de usuario y de operador.La adecuación de la documentación de usuario.R di i t t di i lí it dRendimiento y respuesta en condiciones límite y de sobrecarga

Se realizan en la plataforma de desarrollop

Pruebas de aceptaciónObjetivo: Comprobar que el sistema cubre las necesidades de los usuarios finalesnecesidades de los usuarios finalesParticipación activa del usuario, que deberá ejecutar casos de prueba ayudado porejecutar casos de prueba ayudado por miembros del equipo de pruebasEstán enfocadas para probar los requisitos de usuarioSe realizan en la plataforma de explotaciónC d l f f l d l dCorresponden a la fase final del proceso de desarrollo software

Resumen

Pruebas de regresiónRegresión: Repetición selectiva de pruebas para detectar fallos introducidos durante lapara detectar fallos introducidos durante la modificación de un sistema o componente.En ellas habrá que:En ellas habrá que:

Probar los módulos cambiadosDecidir las pruebas a efectuar en los módulos no

bi dcambiados.Deberán efectuarse:

Cuando existe riesgo de que los cambios afecten aCuando existe riesgo de que los cambios afecten a otras áreas no modificadas directamente.Durante el desarrollo, después de ciertos cambios.Durante el mantenimiento.

Tipos de organizaciones

La organización de las pruebas depende del ciclo de vida utilizadoCiclo de vida en cascada => AplicaciónCiclo de vida en cascada => Aplicación trivialOtros ciclos de vida interesantes:

IncrementalIterativo

Técnicas de Pruebas de S fSoftware


Contenidos

ProblemáticaClasificación de familias de técnicasTécnicas aleatoriasTécnicas aleatoriasTécnicas funcionalesTécnicas de flujo de controlTé i d fl j d d tTécnicas de flujo de datosTécnicas de mutación

ProblemáticaLa prueba exhaustiva no es viable

fNecesidad de predecir de forma precisa la calidad del sistema software

l b l d d lSeleccionar sobre el universo de entradas al sistema aquellas que ayuden a predecir la calidad del software con mayor exactitudcalidad del software con mayor exactitudProblema estadístico del muestreo

d d d é d lNecesidad de técnicas que ayuden a la selección de casos de prueba

Clasificación de familias (1/2)

Conocimiento de l i l t ió

- Caja BlancaC j Nla implementación - Caja Negra

Criterios de adecuación

Enfoque- Estructurales - Basados en faltasEnfoque Basados en faltas - Basados en errores

Clasificación de familias (2/2)

ImplementaciónEnfoque

Caja Blanca Caja Negra Enfoque

Estructurales Flujo de control Flujo de datos

Flujo de datos

Basadas en faltas Mutación Funcionales

Basadas en errores FuncionalesAleatorias

Técnicas aleatorias

El programa se ve como una caja negraIntentan ejecutar casos de prueba relativos a posibles faltas en el programaVariantes:

Puramente aleatorias. Seleccionan casos al azarPuramente aleatorias. Seleccionan casos al azarAtendiendo a la intuiciónAtendiendo a algún perfil de operaciónAtendiendo a algún perfil de operación

Técnicas funcionalesEl programa se ve como una caja negraIntentan ejecutar casos de prueba relativos aIntentan ejecutar casos de prueba relativos a posibles faltas en el programaDivisión del dominio de entrada en clases válidas yDivisión del dominio de entrada en clases válidas y no válidasPasos

Identificar las clases de equivalencia.Identificar los casos de prueba.

Variantes:Variantes:Partición en clases de equivalencia. Todos los elementos de la clase son equiprobables.Análisis de valores límite. Se seleccionan casos del borde de la clase

Técnicas funcionales: Clases de equivalencia

Se examina cada condición de entrada y se divide en dos o más grupos, identificando dos tipos de clases:g p , p

Clases de equivalencia válidasClases de equivalencia no válidas

S l t di t t blSe suelen representar mediante tablas.Proceso heurístico.

Rango de valores: Una clase válida y dos no válidasRango de valores: Una clase válida y dos no válidas.Número de valores: Una clase válida y dos no válidasConjunto de valores de entrada: Tantas clases válidas como

l álidvalores y una no válida.Situación que debe ocurrir: Una clase válida y dos no válidas.Se cree que no todos los elementos de la case se tratan igual: Dividir en subclases.

Técnicas funcionales:Técnicas funcionales: Identificación de casos de prueba

Para la técnica de partición en clases de equivalencia:Asignar un número único a cada clase de equivalenciaAsignar un número único a cada clase de equivalencia.Escribir un caso que cubra tantas clases válidas no incorporadas como sea posible hasta que se cubran todas las clases de equivalencia válidas.qEscribir un caso que cubra una sola clase no válida no incorporada hasta que se cubran todas las clases de equivalencia no válidas

Para el análisis de valores límite:Condiciones límite: Aquellas que se hallan en los márgenes de las clases de equivalencia tanto de entrada g qcomo de salida.Se seleccionan uno o más elementos tal que los márgenes de la clase se sometan a prueba.

á éSe considerará también el dominio de salida

Técnicas de flujo de controlEl programa se ve como una caja blancaSe generan casos atendiendo a la estructura de control del programaVariantes:

Cobertura de sentenciasb d d óCobertura de decisión

Cobertura de condiciónC b t d d i ió / di ióCobertura de decisión/condiciónCobertura de condición múltiple

Técnicas de flujo de control:Técnicas de flujo de control: Prueba del camino básico (1/4)

Camino: Secuencia de sentencias encadenadas desde la entrada del programa hasta su salida.desde la entrada del programa hasta su salida.Diseña casos para caminos independientes:

Todas las sentencias se ejecutan al menos una vez.L di i b d l d dLas condiciones son probadas para valores verdadero y falso.

Se basa en la medida de complejidad ciclomática de M C bMc Cabe.Pasos:

Representación del programa como grafo de flujo.Representación del programa como grafo de flujo.Cálculo de la complejidad ciclomática.Determinación de un conjunto básico de caminos linealmente independientes.ea e te depe d e tesDerivación de los casos de prueba.


Elementos para representar el programa f fcomo grafo de flujo

Nodos. Representan cero, una o varias sentencias.Aristas: Unen dos nodos.

ÁRegiones: Áreas delimitadas por aristas y nodos. Para contarlas, se incluirá la externa.N d P di d S l d lNodos Predicado: Surgen al descomponer las sentencias compuestas en simples.


Cálculo de la complejidad ciclomática:Métrica software para averiguar la complejidad lógica de un programa

í úAquí define el número de caminos independientesPone límite superior al número de caminos a recorrerRepresentando como V(G) la complejidad:

V(G) Nú d iV(G) = Número de regionesV(G) = Aristas - Nodos + 2V(G) = Número de nodos predicado + 1V(G) Número de nodos predicado + 1


Determinación de un conjunto básico de caminos linealmente independientes:linealmente independientes:

Elegir un camino inicial.Alterar la primera decisión y conservar el resto.Colocar primera decisión en su lugar y alterar la segunda, intentando conservar el resto.Continuar el proceso hasta haber tratado todas las Co t ua e p oceso asta abe t atado todas asdecisiones, intentando conservar el resto

Derivación de los casos de prueba: Cada caso de prueba se diseñará de tal modo que corresponda aprueba se diseñará de tal modo, que corresponda a cada uno de los caminos elegidos.PROBLEMA: El número ciclomático no da idea acercaPROBLEMA: El número ciclomático no da idea acerca de la complejidad de los datos

Técnicas de flujo de datosEl programa se ve como una caja blancaBasadas en:Basadas en:

Forma en que se asignan valores a variablesCómo pueden afectar asignaciones a ejecuciónCómo pueden afectar asignaciones a ejecución

Se generan casos atendiendo al flujo de los datos por el programadatos por el programaOcurrencia de variable:

Definición (def ) => Asociada a nodoDefinición (def.) => Asociada a nodoUso:

Uso en computación (uso-c) => Asociada a nodoUso en computación (uso c) > Asociada a nodoUso en predicado (uso-p) => Asociada a arista

Técnicas de flujo de datos: jDefiniciones

Camino simple: Todos los nodos excepto posiblemente el primero y el último sonposiblemente el primero y el último son distintosCamino libre de bucles: Todos los nodosCamino libre de bucles: Todos los nodos son distintosCamino completo: El nodo inicial es el de

d l d f l l d l dentrada y el nodo final el de salida.Camino libre de definiciones (i,j): (i, n1,

n j) m≥ 0 tal que no hay definiciones..., nm, j), m≥ 0, tal que no hay definiciones en n1, ..., nm

Técnicas de flujo de datos: jConjuntos definición uso

Para cada nodo del grafo se crea:Def(i): Conjunto de variables para las que el nodo iDef(i): Conjunto de variables para las que el nodo i contiene una definición global.Uso-c(i): Conjunto de variables para las que el nodo i contiene un uso-c globalg

Para cada arista se crea:Uso-p (i,j): Conjunto de variables para las que la arista (i,j) contiene un uso-pcontiene un uso p

Sea un nodo i y una variable x t.q. x Є def(i)dcu(x,i): Conjunto de todos aquellos nodos j tales que x Єuso-c(j) y para los que hay un camino libre de definicionesuso-c(j) y para los que hay un camino libre de definiciones para x de i a jdpu(x,i): Conjunto de todas aquellas aristas (j,k) tales que x Є uso-p(j,k) y para las que hay un camino libre dex Є uso p(j,k) y para las que hay un camino libre de definiciones para x de i a j

Técnicas de flujo de datos: jComponentes

Todas-defs: ∀ nodo i, ∀ x Є def(i), P incluye un camino libre de definiciones para x de i a todos loscamino libre de definiciones para x de i a todos los elementos de dcu(x,i)Todos-usos-p: ∀ nodo i, ∀ x Є def(i), P incluye un p , ( ), ycamino libre de definiciones para x de i a todos los elementos de dpu(x,i)Todos usos p/algunos usos c: ∀ nodo i ∀ x ЄTodos-usos-p/algunos-usos-c: ∀ nodo i, ∀ x Єdef(i), P incluye un camino libre de definiciones para x de i a todos los elementos de dcu(x,i); si éste es ( , );vacío, entonces debe incluir un camino libre de definiciones para x de i a algún elemento de dpu(x,i)

Técnicas de flujo de datos: jComponentes

Todos-usos-c/algunos-usos-p: ∀ nodo i, ∀ x Єdef(i) P incluye un camino libre de definiciones paradef(i), P incluye un camino libre de definiciones para x de i a todos los elementos de dpu(x,i); si éste es vacío, entonces debe incluir un camino libre de d fi i i d i l ú l d d ( i)definiciones para x de i a algún elemento de dcu(x,i)Todos-usos: ∀ nodo i, ∀ x Є def(i), P incluye un camino libre de definiciones para x de i a todos loscamino libre de definiciones para x de i a todos los elementos de dcu(x,i) y de dpu(x,i) Todos-caminos-du: ∀ nodo i, ∀ x Є def(i), P , ( ),incluye cada camino du con respecto a x

Técnicas de mutaciónEl programa se ve como una caja blancaSe generan mutantes atendiendo a las posibles faltas

i t t lexistentes en el programaSe utiliza el conjunto de operadores de mutación asociado al lenguaje de programación utilizadoasociado al lenguaje de programación utilizadoGeneración de casos de prueba a partir de los mutantes obtenidosS t t d b t tSe generan tantos casos de prueba como mutantes se quieran “matar”Técnicas

Mutación fuerte. Se utilizan todos los operadores de mutación y se busca 100% de coberturaMutación débil. Se relaja la condición de cobertura.jMutación selectiva. Se utilizan solamente algunos de los operadores de mutación

Documents

ANÁLISIS DINÁMICO DEL SO SSOFTWARE: PRUEBAS