ANÁLISIS DINÁMICO DEL SOFTWARE: PRUEBAS

Sira Vegas

Facultad de Informática - UPM

CONTENIDOS

n  Conceptos generales de evaluación n  Introducción a las pruebas de software n  Organización de las pruebas de software n  Técnicas de pruebas de software

Conceptos Generales de Evaluación

Análisis dinámico del software: pruebas

Contenidos

n  Introducción n  Necesidad de la evaluación n  Papel de las pruebas de software n  Error, falta y fallo

Introducción

n  Objetivos de la Ingeniería del Software. Construcción de: n  Sistemas de calidad n  Dentro de presupuesto n  A tiempo

n  No consecución de objetivos => CRISIS DEL SOFTWARE

Necesidad de la evaluación

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

Coste de reparación del software

Papel de las pruebas de sw Actividades de control y garantía de

calidad del software

Preventivas Correctivas (Evaluación de sw)

Análisis estático Análisis dinámico (pruebas)

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

- Examen en reposo - Aspectos estáticos - Cualquier producto sw

- Examen resultado funcionamiento del sw - Aspectos dinámicos - Solamente código

Error, falta y fallo

n  Distinción error/falta/fallo según IEEE n  Error. Los humanos comenten errores con

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

modo deseado

n  Término genérico defecto n  Problema: Relación no directa entre error/

falta/fallo

Introducción a las Pruebas de Software

Análisis dinámico del software: pruebas

Contenidos

n  Niveles de madurez n  Definición de prueba n  Principios de las pruebas n  El proceso de pruebas

Niveles de madurez

n  Nivel 0:Prueba es igual a depuración n  Nivel 1: Demostrar que el software funciona n  Nivel 2: Demostrar que el software no

funciona n  Nivel 3: Reducir el riesgo de que el software

no funcione n  Nivel 4: La prueba es una disciplina mental

que conduce a software de bajo riesgo

Definición de prueba

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

n  Cualquier actividad dirigida a evaluar un atributo o capacidad de un programa o sistema y determinar que alcanza los resultados requeridos

n  Actividad necesaria de reunir información que nos permita evaluar nuestro trabajo de forma eficiente

Principios de las pruebas (1/3) n  Las pruebas son el proceso de ejecutar un programa/

sistema con la intención de descubrir defectos en el software

n  Un buen caso de prueba es aquel que tiene una alta probabilidad de descubrir un defecto no encontrado

n  Se deben definir las salidas o resultados esperados de los casos de prueba

n  Se debe realizar una inspección minuciosa de cada caso de prueba

n  Los caos de prueba se escriben para condiciones de entrada válidas/no válidas y esperadas/inesperadas

Principios de las pruebas (2/3) n  La prueba del software se hace tanto para ver

si no hace lo que se supone que debe hacer, como para ver si hace lo que se supone que no debe hacer

n  Un programador debe evitar probar su propio programa

n  Un equipo no debe probar sus propios programas

n  Se debe evitar tirar/perder los casos de prueba n  No se debe planificar el esfuerzo de la prueba

bajo la creencia de que no se encontrarán defectos

Principios de las pruebas (3/3) n  La probabilidad de la existencia de más defectos en

una parte del software es proporcional al número de defectos ya encontrados en dicha parte

n  La prueba completa (exhaustiva) no es posible n  Una razón para la prueba es prevenir deficiencias

antes de que ocurran n  La prueba está basada en el riesgo n  La prueba es una actividad extremadamente creativa,

intelectual y difícil

El proceso de pruebas

n  Generación y especificación de los casos de prueba

n  Ejecución de los casos de prueba n  Comparación de los resultados

obtenidos con los esperados n  Identificación de fallos en el sistema n  Identificación y corrección de las faltas

que causaban los fallos

Organización de las Pruebas de Software

Análisis dinámico del software: pruebas

Contenidos

n  Problemática n  Pruebas unitarias n  Pruebas de integración n  Pruebas de sistema n  Pruebas de aceptación n  Tipos de organizaciones

Problemática

n  La depuración se complica a medida que aumenta el tamaño del software

n  Necesidad de abordar la etapa de pruebas en fases para facilitar dicha tarea

n  Se comenzará a nivel de módulo y se progresará hacia el sistema completo

Pruebas unitarias n  Objetivo: Comprobar los productos resultantes de la

codificación n  Cada módulo se prueba por separado y por la

persona que lo creó n  Módulo: Pieza de código que cumple:

n  Bloque básico de programa n  Implementa función independiente simple n  Puede probarse por separado n  Normalmente menor de 500 líneas de código

n  En OO se suele hablar de prueba de clase o método n  Se ha de comprobar que el módulo está

correctamente codificado

Pruebas de integración n  Objetivo: Comprobar los productos del diseño n  Se ha de comprobar:

n  Integridad de la interfaz n  Rendimiento

n  Tipos de integración n  Incremental

n  Ascendente n  Descendente

n  En profundidad n  En anchura

n  No incremental

Pruebas de integración: Tipos n  Incremental Ascendente: Se combinan los

módulos de más bajo nivel, utilizando drivers para los de más alto nivel.

n  Incremental Descendente: Se comienza en el módulo de mayor nivel y se incorporan los módulos subordinados bien en profundidad o anchura.

n  No Incremental: Se utiliza un driver y uno o 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 sistema n  Objetivo: Comprobar que el sistema integrado de

hardware y software cumple con los requisitos especificados

n  Se ha de comprobar n  Se cumplen los requisitos funcionales establecidos durante el

análisis. n  El funcionamiento y rendimiento en las interfaces hardware,

software de usuario y de operador. n  La adecuación de la documentación de usuario. n  Rendimiento y respuesta en condiciones límite y de

sobrecarga n  Se realizan en la plataforma de desarrollo

Pruebas de aceptación n  Objetivo: Comprobar que el sistema cubre las

necesidades de los usuarios finales n  Participación activa del usuario, que deberá

ejecutar casos de prueba ayudado por miembros del equipo de pruebas

n  Están enfocadas para probar los requisitos de usuario

n  Se realizan en la plataforma de explotación n  Corresponden a la fase final del proceso de

desarrollo software

Resumen

Pruebas de regresión n  Regresión: Repetición selectiva de pruebas

para detectar fallos introducidos durante la modificación de un sistema o componente.

n  En ellas habrá que: n  Probar los módulos cambiados n  Decidir las pruebas a efectuar en los módulos no

cambiados. n  Deberán efectuarse:

n  Cuando existe riesgo de que los cambios afecten a otras áreas no modificadas directamente.

n  Durante el desarrollo, después de ciertos cambios. n  Durante el mantenimiento.

Tipos de organizaciones

n  La organización de las pruebas depende del ciclo de vida utilizado

n  Ciclo de vida en cascada => Aplicación trivial

n  Otros ciclos de vida interesantes: n  Incremental n  Iterativo

Técnicas de Pruebas de Software

Análisis dinámico del software: pruebas

Contenidos

n  Problemática n  Clasificación de familias de técnicas n  Técnicas aleatorias n  Técnicas funcionales n  Técnicas de flujo de control n  Técnicas de flujo de datos n  Técnicas de mutación

Problemática n  La prueba exhaustiva no es viable n  Necesidad de predecir de forma precisa la

calidad del sistema software n  Seleccionar sobre el universo de entradas al

sistema aquellas que ayuden a predecir la calidad del software con mayor exactitud

n  Problema estadístico del muestreo n  Necesidad de técnicas que ayuden a la

selección de casos de prueba

Clasificación de familias (1/2)

Conocimiento de la implementación

- Caja Blanca - Caja Negra

Criterios de adecuación

Enfoque - Estructurales - Basados en faltas - Basados en errores

Clasificación de familias (2/2)

Implementación Enfoque

Caja Blanca Caja Negra

Estructurales Flujo de control Flujo de datos

Basadas en faltas Mutación

Basadas en errores Funcionales

Aleatorias

Técnicas aleatorias

n  El programa se ve como una caja negra n  Intentan ejecutar casos de prueba relativos a

posibles faltas en el programa n  Variantes:

n  Puramente aleatorias. Seleccionan casos al azar n  Atendiendo a la intuición n  Atendiendo a algún perfil de operación

Técnicas funcionales n  El programa se ve como una caja negra n  Intentan ejecutar casos de prueba relativos a

posibles faltas en el programa n  División del dominio de entrada en clases válidas y

no válidas n  Pasos

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

n  Variantes: n  Partición en clases de equivalencia. Todos los elementos de

la clase son equiprobables. n  Análisis de valores límite. Se seleccionan casos del borde de

la clase

Técnicas funcionales: Clases de equivalencia n  Se examina cada condición de entrada y se divide en

dos o más grupos, identificando dos tipos de clases: n  Clases de equivalencia válidas n  Clases de equivalencia no válidas

n  Se suelen representar mediante tablas. n  Proceso heurístico.

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

valores y una no válida. n  Situación que debe ocurrir: Una clase válida y dos no

válidas. n  Se cree que no todos los elementos de la case se tratan

igual: Dividir en subclases.

Técnicas funcionales: Identificación de casos de prueba n  Para la técnica de partición en clases de equivalencia:

n  Asignar un número único a cada clase de equivalencia. n  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.

n  Escribir un caso que cubra una sola clase no válida no incorporada hasta que se cubran todas las clases de equivalencia no válidas

n  Para el análisis de valores límite: n  Condiciones límite: Aquellas que se hallan en los

márgenes de las clases de equivalencia tanto de entrada como de salida.

n  Se seleccionan uno o más elementos tal que los márgenes de la clase se sometan a prueba.

n  Se considerará también el dominio de salida

Técnicas de flujo de control n  El programa se ve como una caja blanca n  Se generan casos atendiendo a la estructura

de control del programa n  Variantes:

n  Cobertura de sentencias n  Cobertura de decisión n  Cobertura de condición n  Cobertura de decisión/condición n  Cobertura de condición múltiple

Técnicas de flujo de control: Prueba del camino básico (1/4) n  Camino: Secuencia de sentencias encadenadas

desde la entrada del programa hasta su salida. n  Diseña casos para caminos independientes:

n  Todas las sentencias se ejecutan al menos una vez. n  Las condiciones son probadas para valores verdadero y

falso. n  Se basa en la medida de complejidad ciclomática de

Mc Cabe. n  Pasos:

n  Representación del programa como grafo de flujo. n  Cálculo de la complejidad ciclomática. n  Determinación de un conjunto básico de caminos

linealmente independientes. n  Derivación de los casos de prueba.

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

n  Elementos para representar el programa como grafo de flujo n  Nodos. Representan cero, una o varias

sentencias. n  Aristas: Unen dos nodos. n  Regiones: Áreas delimitadas por aristas y nodos.

Para contarlas, se incluirá la externa. n  Nodos Predicado: Surgen al descomponer las

sentencias compuestas en simples.

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

n  Cálculo de la complejidad ciclomática: n  Métrica software para averiguar la complejidad

lógica de un programa n  Aquí define el número de caminos independientes n  Pone límite superior al número de caminos a

recorrer n  Representando como V(G) la complejidad:

n  V(G) = Número de regiones n  V(G) = Aristas - Nodos + 2 n  V(G) = Número de nodos predicado + 1

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

n  Determinación de un conjunto básico de caminos linealmente independientes: n  Elegir un camino inicial. n  Alterar la primera decisión y conservar el resto. n  Colocar primera decisión en su lugar y alterar la segunda,

intentando conservar el resto. n  Continuar el proceso hasta haber tratado todas las

decisiones, intentando conservar el resto n  Derivación de los casos de prueba: Cada caso de

prueba se diseñará de tal modo, que corresponda a cada uno de los caminos elegidos.

n  PROBLEMA: El número ciclomático no da idea acerca de la complejidad de los datos

Técnicas de flujo de datos n  El programa se ve como una caja blanca n  Basadas en:

n  Forma en que se asignan valores a variables n  Cómo pueden afectar asignaciones a ejecución

n  Se generan casos atendiendo al flujo de los datos por el programa

n  Ocurrencia de variable: n  Definición (def.) => Asociada a nodo n  Uso:

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

Técnicas de flujo de datos: Definiciones n  Camino simple: Todos los nodos excepto

posiblemente el primero y el último son distintos

n  Camino libre de bucles: Todos los nodos son distintos

n  Camino completo: El nodo inicial es el de entrada y el nodo final el de salida.

n  Camino libre de definiciones (i,j): (i, n1, ..., nm, j), m≥ 0, tal que no hay definiciones en n1, ..., nm

Técnicas de flujo de datos: Conjuntos definición uso n  Para cada nodo del grafo se crea:

n  Def(i): Conjunto de variables para las que el nodo i contiene una definición global.

n  Uso-c(i): Conjunto de variables para las que el nodo i contiene un uso-c global

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

contiene un uso-p n  Sea un nodo i y una variable x t.q. x Є def(i)

n  dcu(x,i): Conjunto de todos aquellos nodos j tales que x Є uso-c(j) y para los que hay un camino libre de definiciones para x de i a j

n  dpu(x,i): Conjunto de todas aquellas aristas (j,k) tales que x Є 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: Componentes n  Todas-defs: ∀ ∀ nodo i, ∀ ∀ x Є def(i), P incluye un

camino libre de definiciones para x de i a todos los elementos de dcu(x,i)

n  Todos-usos-p: ∀ ∀ nodo i, ∀ ∀ x Є def(i), P incluye un camino libre de definiciones para x de i a todos los elementos de dpu(x,i)

n  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: Componentes n  Todos-usos-c/algunos-usos-p: ∀ ∀ nodo i, ∀ ∀ x Є def(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 definiciones para x de i a algún elemento de dcu(x,i)

n  Todos-usos: ∀ ∀ nodo i, ∀ ∀ x Є def(i), P incluye un camino libre de definiciones para x de i a todos los elementos de dcu(x,i) y de dpu(x,i)

n  Todos-caminos-du: ∀ ∀ nodo i, ∀ ∀ x Є def(i), P incluye cada camino du con respecto a x

Técnicas de mutación n  El programa se ve como una caja blanca n  Se generan mutantes atendiendo a las posibles faltas

existentes en el programa n  Se utiliza el conjunto de operadores de mutación

asociado al lenguaje de programación utilizado n  Generación de casos de prueba a partir de los

mutantes obtenidos n  Se generan tantos casos de prueba como mutantes

se quieran “matar” n  Técnicas

n  Mutación fuerte. Se utilizan todos los operadores de mutación y se busca 100% de cobertura

n  Mutación débil. Se relaja la condición de cobertura. n  Mutación selectiva. Se utilizan solamente algunos de los

operadores de mutación