Líneas de Producto de

Software – Pruebas de

componentesRubby Casallas

Departamento de Sistemas y Computación

Universidad de los Andes, Bogotá

Referencias

� [Pohl 2010] Pohl K., Böckle G., van der Linden F.,

Requirements Engineering - Fundamentals, Principles, and

Techniques. Berlin. Springer, 2010

Agenda

� Domain testing vs Application testing

� Estrategias

� Plan de pruebas

Generalidades� Diferentes tipos de pruebas: unitarias.,

integración y sistema

� Cada una debe seguir un proceso básico de:

� análisis:

� De acuerdo con el artefacto que se va aprobar, se debe definir cuál será la estrategia de prueba. Se produce un Plan de pruebas

� construcción:

� Construir los artefactos de la prueba: escenarios, software que implementa la prueba.

� Ejecución y evaluación:

� Ejecutar las pruebas y analizar los resultados

Características del proceso de pruebas

� Objetivo

� Guiado por la satisfacción de requerimeintos

� Sistemático y repetible

� Prepararse para pruebas de regresión

� Minucioso

� Tratando de expandir el cubrimiento

� Integrado al proceso de desarrollo

� Preparar plan de pruebas

Artefactos de pruebas

� test cases:

� Se diseñan con un objetivo preciso y logrando un

cierto nivel de cubrimiento

� test documents:

� Plan de pruebas y reporte de defectos

� test software:

� Ej: construido utilizando junit

Plan de pruebas

� Contenido

� Objetivos

� Estrategia (Rationale)

� Casos de prueba organizados pro artefactos

Objetivo

� Establecer un proceso eficiente de pruebas

de los artefactos reutilizables

� Reto: tener en cuenta la variabilidad

� Pruebas de sistema (de domino) se basan en

los requerimientos de dominio comunes

� Pruebas de integración se basan en la

arquitectura de referencia para validar la

interacción entre componentes

� Pruebas unitarias se basan en la definición

de cada interface de los componentes

Domain testing vs Application testing

� Pruebas de dominio se concentran en probar

aisladamente los componentes

� Pruebas de Aplicación en probar

aplicaciones completas

� Las pruebas unitarias se deben realizar por

cada variante de manera independiente

� No es posible (o por lo menos muy difícil)

probar todas las interacciones entre los

componentes variantes

Criterios para seleccionar estrategias

de pruebas en SPLs1. Esfuerzo para crear los artefactos de

prueba:

� Qué tan bien la estrategia soporta la reutilización

de los artefactos de pruebas

� Qué tanto se acelera el desarrollo de los

artefactos

2. Variantes ausentes:

� Que tan bien la estrategia maneja el problema de

las variantes ausentes

Criterios para seleccionar estrategias

de pruebas en SPLs3. Validación temprana:

� Tiempo entre la construcción del artefacto y su

validación.

� El tiempo debe ser corto para asegurar una

detección temprana de defectos

4. Esfuerzo de aprendizaje:

3. Tiempo de aprender a utilizar la estrategia

escogida

5. Overhead:

� Eficiencia de la estrategia

Estrategias

1. Fuerza bruta

2. Pruebas de aplicación

3. Pruebas de aplicación sobre una muestra

4. Pruebas de artefactos comunes

Estrategia Fuerza bruta

� Pruebas exhaustivas (sistema, integración y

unitarias) por cada producto posible

� No puede haber variantes ausentes

� El número de posibles configuración puede

ser demasiado grande

� Ejemplo: 10 puntos de variación cada uno

con tres variantes

� 3^10 = 59,049 aplicaciones posibles

� Si las variantes son opcionales

� 8^10 = 1,073,741,824

Estrategia Fuerza bruta

Estrategia Pruebas de aplicación

� No hacer pruebas de dominio y solo realizar

pruebas de aplicación

� No crear artefactos reutilizables para pruebas

� Alto overhead – los artefactos de prueba se

desarrollan cada vez por aplicación

Estrategia Pruebas de aplicación sobre

una muestra� Pocas aplicaciones son ensambladas y

probadas

� Asegura una calidad razonable para los

artefactos de dominio

� Primero se configura una aplicación

representativa y se prueba

� Luego se cambian variantes y se prueban

unas cuantas configuraciones

� Se prueba también configurabilidad

Estrategia Pruebas de aplicación sobre

una muestra

Estrategia Pruebas de artefactos

comunes� Focaliza en probar los componentes

comunes y preparar artefactos de pruebas

para los variables

� Los artefactos de pruebas deben contener

variabilidad en sí mismos

Referencia

� Testing a Software Product Line. John

McGregor. Technical Report. CMU/SEI-2001-

TR-022. December 2001

� “The number of variation points and possible

values for each variation make the testing of

all possible products that can be built from

the product line impossible. This makes it

imperative that products be composed of

high-quality components.” [Ardis 00].

Los casos de prueba se crean a nivel de la línea (domain engineering) y se

especializan a nivel del producto (application engineering)