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
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 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 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)
Top Related