Universidad Tcnica Federico Santa Mara

Departamento de Informtica
Testing de Software
Testing de Regresin
Profesor : Marcello Visconti
Asignatura : Testing de Software
Alumnos : Claudio Bustamante
Jan Arneric
Fecha : 21/Noviembre/2002
2
INDICE
1. Introduccin .......................................................................................................................... 04
2. Estado del Arte...................................................................................................................... 06
3. Estado de la Prctica............................................................................................................. 07
3.1. Experiencia Tcnica Firewall ........................................................................................... 07
3.1.1. Descripcin de la Tcnica.................................................................................... 07
3.1.2. Experiencia Computacional .................................................................................. 08
3.2. Comparacin experimental de las tcnicas Slicing, Incremental, Firewall y Gentica.......... 10
3.2.1. Algoritmo Slicing.................................................................................................. 10
3.2.2. Algoritmo Incremental .......................................................................................... 10
3.2.3. Algoritmo Firewall ................................................................................................ 10
3.2.4. Algoritmo Gentico.............................................................................................. 11
3.2.5. Criterios de Comparacin..................................................................................... 11
3.2.5.1. Criterios cuantitativos..................................................................................... 11
3.2.5.2. Criterios cualitativos....................................................................................... 12
3.2.6. Resultados .......................................................................................................... 13
3.2.6.1. Resultados criterios cuantitativos .................................................................... 13
3.2.6.2. Resultados criterios cualitativos ...................................................................... 14
3.2.7. Pautas de seleccin de algoritmos........................................................................ 15
3.3. Integracin tcnicas caja blanca y negra en el testing de regresin en OO......................... 16
3.3.1. Integracin de las tcnicas ................................................................................... 16
3.3.1.1. Construccin de Bloques............................................................................... 16
3.3.1.1.1. Tcnica Rothermel............................................................................. 16
3.3.1.1.2. Tcnica de caja negra de Hong .......................................................... 16
3.3.2. Ejemplo............................................................................................................... 17
3.3.3. Implementacin grfica de la especificacin de la clase......................................... 18
3.3.3.1. Construccin de prototipo por cada tipo de evento........................................... 18
3.3.3.2. Generando e insertando grafos de flujo de control dentro del marco CCFG....... 19
3.3.3.3. Agregando arcos de flujo de datos para el testing de caja-negra....................... 20
3.3.4. Usando el CSIG para el testing de regresin......................................................... 21
4. Efectividad y disponibilidad de tcnicas y herramientas............................................................ 23
4.1. Notacin........................................................................................................................ 23
4.2. Clasificacin de las tcnicas ........................................................................................... 23
4.3. El Retest selectivo.......................................................................................................... 23
4.4. Clases de Test para medir la efectividad de las tcnicas................................................... 24
3
4.5. Mtricas para medir la efectividad de las tcnicas ............................................................ 27
4.5.1. Inclusividad......................................................................................................... 27
4.5.2. Precisin............................................................................................................. 29
4.5.3. Eficiencia ............................................................................................................ 30
4.5.4. Generalidad ........................................................................................................ 32
4.6. Anlisis de Tcnicas de Seleccin de Test de Regresin.................................................. 33
4.6.1. Tcnicas de Ecuacin Lineal (Linear Equation)...................................................... 35
4.6.2. Tcnica de Ejecucin Simblica (Symbolic Execution) ........................................... 37
4.6.3. Tcnica de Anlisis de Camino (Path Analisys) ..................................................... 39
4.6.4. Tcnicas Flujo de Datos (Dataflow)....................................................................... 40
4.6.5. Tcnicas Grafo Dependencias Programa (Program Dependece Graph PDG).......... 41
4.6.6. Tcnicas de Grafo de Dependencia del Sistema (System Dependence Graph)........ 42
4.6.7. Tcnica Basada en la Modificacin (Modification Based)........................................ 43
4.6.8. Tcnica Cortafuego (Firewall)............................................................................... 44
4.6.9. Tcnica de Identificacin del Cluster (Cluster Identification).................................... 45
4.6.10. Tcnicas de Corte (Slicing)................................................................................... 47
4.6.11. Tcnicas de Recorrido del Grafo (Graph Walk)...................................................... 49
4.6.12. Tcnica de Entidad Modificada (Modified Entity).................................................... 51
4.7. Algunas Herramientas .................................................................................................... 52
4.7.1. Mercury Interactive y Segue Software................................................................... 52
4.7.2. Capbax/x, Capbax/Unix de TestWorks Software.................................................... 52
4.7.3. Herramientas Capture-Playback ........................................................................... 52
5. Conclusiones......................................................................................................................... 53
6. Referencias........................................................................................................................... 54
4
1. Introduccin
Los diseadores toman en cuenta muchos criterios cuando escriben software. En estos tiempos en que
el cambio es tan comn, uno de los ms importantes es la capacidad de mantencin, que se relaciona
fuertemente con otros criterios deseables. Este mantenimiento del software implica modificarlo como
resultado de errores, o de alteraciones en los requerimientos del usuario. Durante tales modificaciones,
nuevos errores se pueden introducir, causando efectos secundarios adversos en el software.
Entre las mantenciones ms comunes se encuentra la mantencin perfectiva que es aquella que mejora
la funcionalidad del software, y la mantencin correctiva que es aquella que detecta y corrige defectos.
Ya sea en la mantencin perfectiva o correctiva, se debe asegurar que los cambios no afectan
inadvertidamente las funcionalidades no modificadas. Cuando esto ocurre, se dice que hay un error de
regresin.
Las estimaciones determinan que dichas actividades corresponden a casi los dos tercios del costo de
produccin del mismo. Una de las tareas necesarias, pero caras, es el test de regresin, efectuado sobre
un programa modificado para confirmar que los cambios son correctos y no han afectado de forma
adversa a las porciones no alteradas del programa.
Una diferencia importante entre el test de regresin y el test de desarrollo es que durante el primero un
conjunto establecido de tests puede estar disponible para ser reutilizado. Una de las estrategias del test
de regresin, el modelo retest all, vuelve a ejecutar todos los test de ese tipo, pero esta estrategia
puede consumir tiempo y recursos de modo excesivo. Las tcnicas de seleccin del test de regresin,
por el contrario, intentan reducir el tiempo requerido para volver a probar un programa modificado,
seleccionando algn conjunto del total de los test existentes.
Por lo tanto, el testing de regresin tiene como objetivo principal proporcionar la suficiente confianza en
que las modificaciones efectuadas estn correctas y no han afectado otras partes del software. El testing
de regresin puede ser progresivo o correctivo. Lo anterior implica cambios importantes que reexaminan
la especificacin del software. Para el testing de regresin, sera costoso repetir el conjunto de casos de
prueba usados en el desarrollo inicial del software y no sera ptimo elegir un subconjunto al azar de
estos casos de prueba. Por lo tanto, es importante seleccionar un subconjunto conveniente de los casos
de prueba que logran los objetivos del testing de regresin.
La seleccin de los casos convenientes se puede hacer de diversas maneras, y se han propuesto un
nmero de acercamientos y de algoritmos de testing de regresin. Una estrategia basada en el
particionamiento de entrada y grafos de causa-efecto de la especificacin del software en sido descritos.
Leung y White han sugerido clasificar los casos iniciales de prueba como reutilizables, retesteables,
obsoletos, y aaden casos de prueba para nueva estructura y nueva especificacin y, luego, seleccionar
casos de prueba para alguna o todas las clases. Tambin se han propuesto mtodos para limitar la
integracin del testing de regresin en un conjunto pequeo de mdulos.
El testing de regresin tiene una importancia crucial a niveles de prueba de unidad, integracin y sistema.
Los equipos de desarrollo generalmente tienen responsabilidad en el testing de unidad e integracin,
stos generalmente aplican consistentemente pruebas de regresin a estos niveles cuando hacen
cambios y, con frecuencia no almacenan datos de prueba.
5
Figura 1. Enfoque para pruebas de regresin a nivel de unidad.
La figura 1 ilustra un enfoque para pruebas de regresin a nivel de unidad, de modo que un subconjunto
de casos de prueba puede detectar un error de regresin de unidad.
El anlisis esttico detecta los llamados tests reusables, es decir, aquellos casos que no sern afectados
por los cambios del software.
El analizador dinmico ejecuta los tests restantes e identifica tests obsoletos que ya no logran la funcin
esperada puesto que el programa ha cambiado. Los casos testeables restantes revelan errores de
regresin. Se necesitan nuevos tests para actualizar los tests funcionales si ha cambiado la
especificacin del mdulo, o para obtener tests estructurales que alcancen un nivel especfico de
cobertura.
6
2. Estado del Arte
Siendo el Objetivo ltimo de la Ingeniera de Software el producir software de calidad, el Testing de
Regresin apunta en este sentido por medio de:
Definicin de las Clases de Casos de Prueba (Regression-Test suite) como un Conjunto representativo
que ejercita todas las funciones,
Pruebas adicionales que se focalizan en funciones probablemente afectadas, y
Pruebas que se focalizan en componentes que han cambiado.
Para la ejecucin, se emplean Herramientas Manuales y Automatizadas, las que se denominan capture -
Playback tools.
El estado del arte ha evolucionado desde que se ampli la definicin de sus objetivos, incluyendo e
integrando a reas que no eran consideradas como parte integral del desarrollo, o en su defecto, a lo
menos compatibles. Esta integracin se puede resumir de la siguiente manera:
Creacin y promocin de sinergia entre las reas funcionales y de sistemas de informacin donde el
mantenimiento y ejecucin del testing de regresin forman parte del normal desarrollo de las
actividades de la empresa.
Implementacin de ciclos de vida en las labores de testing.
Establecimiento de testing framework que puedan ser usadas como monitoreo del testing de
regresin, por las reas funcionales y de sistemas de informacin de la empresa.
Creacin de Comits y Equipos de trabajo conjuntos entre usuarios y testeadores.
Potenciado empleo de la documentacin, requerimientos, especificaciones funcionales y procesos de
negocios, determinando claramente qu necesita el testeador.
Formalizacin de los test y de la documentacin empleada en testing de regresin, profesionalizando
al personal abocado a las tareas inherentes.
Orientar el nfasis en que en un proceso de reporte de defectos de documentacin y reporte de
problemas software, los detectores sean individualizados y se lleve un detallado informe de las
circunstancias en que fueron hallados.
Creacin de herramientas administrativas para documentar, organizar e informar los test y sus
defectos.
Desarrollar planes de entrenamiento a testeadores y desarrolladores en el uso de herramientas
administrativas de test.
Orientar importantes esfuerzos al desarrollo de herramientas automatizadas para realizar los test que
hasta la fecha se realizan en forma manual.
Exigencia de monitoreos formales continuos durante todo el proceso de testeo de regresin.
Por otra parte, las entidades que se han enfocado en estas tareas y realizan los esfuerzos para mejorar
las tcnicas de testing de regresin principalmente son:
Universidades, que buscan por medio de estudios avanzados el mejorar la formalidad y optimizar
procesos de desarrollo y control.
Empresas Areas, Comerciales y de Servicios, que persiguen por razones comerciales, dar cumplimiento
a las normas dispuestas por las instituciones rectoras, acuerdos o comunidades comerciales, incluyendo
seguridad, barreras arancelarias y para-arancelarias.
Instituciones Gubernamentales y Defensa, que se orientan a la seguridad en la minimizacin de fallas en
sus operaciones, procesos y procedimientos.
7
NASA, orientada a la seguridad de sus operaciones involucrando a todo el proceso de nuevos diseos,
desde la identificacin hasta la puesta en marcha.
3. Estado de la Prctica
3.1. Experiencia Tcnica Firewall
3.1.1. Descripcin de la Tcnica
Esta tcnica se encuentra basada en el grafo de control de flujo y la idea principal es establecer un corta
fuego que rodea los mdulos que se deben retestear, es decir, dados los mdulos modificados,
cuntos mdulos se deben retestear? en otras palabras, dnde se debe establecer un firewall que
rodee esos mdulos que se deben retestear? Cuando se detectan errores, se deberan efectuar los
cambios que eviten extender al firewall.
Los casos bsicos que describen dependencias para un mdulo a son:
No hay cambio en a, NoCh(a),
Slo cambio de cdigo en a, CodeCh(a), y
Cambio en la especificacin de a, SpecCh(a).
Si el mdulo a llama al mdulo b, se pueden ignorar todos los casos en los que ni a ni b cambian.
Los cuatro casos lmites crticos se presentan a la derecha. Dos
corresponden a un mdulo no cambiado que llama a un mdulo
modificado, y los otros dos corresponden a un mdulo
modificado que llama a uno no modificado. El caso 6 es inusual
en cuanto a que no se esperara que un mdulo no cambiado
llame a un mdulo en el que ha cambiado la especificacin.
Esta situacin inusual crea dos consecuencias:
Ejecutar los tests de integracin entre los dos mdulos en
cada caso. No volver a ejecutar los tests de unidad en el
mdulo que no ha cambiado.
Si cualquiera de los tests detecta un error, corregir el error
cambiando slo el mdulo modificado. No se debera
cambiar el mdulo no modificado. Si se sigue esta
conducta, el firewall no se expande.
8
La figura 2 muestra un grafo de control de flujo
con cuatro mdulos modificados: C1 a C4, el
firewall se ha dibujado con una lnea roja.
En este ejemplo, el firewall indica que:
Se deben volver a ejecutar los tests de
integracin U2-C1, U2-C3, C2-U4, C3-U7, C3-
U8, C4-U5 y C4-U6.
No es necesario aplicar los tests de unidad a
los mdulos no cambiados.
Figura 2. Firewall
3.1.2. Experiencia Computacional
La experiencia se basa en un programa de base de datos con 20 mdulos diferentes, siete caractersticas
de software (con funciones de software principal en las especificaciones), y ms de 550 lneas
ejecutables de cdigo Pascal. Se proporcionaron 4 modificaciones reales que se evaluaron con pruebas
de regresin, usando tests reducidos.
La tabla 1 muestra el resultado de
este estudio. Las modificaciones 1,
2 y 4 muestran reducciones
considerables en el nmero de tests
requeridos, pero la modificacin 3
muestra una pequea reduccin.
Las cuatro lneas superiores de la
tabla 1 muestran la razn de esto.
La modificacin 3 tiene un nmero
levemente ms alto de mdulos
afectados o de interacciones de
mdulos que las otras
modificaciones. La diferencia ms
grande se encuentra en el nmero
de caractersticas afectadas. Como
la modificacin 3 afecta a todas las
caractersticas, el nmero de tests
de sistema no disminuye.
Tabla 1. Resultados experiencia computacional
9
Para establecer la efectividad de los subconjuntos de test y encontrar qu tests detectan errores, se
introdujeron 13 errores lgicos. De stos, los tests detectaron 12, siendo los subconjuntos tan efectivos
en detectar estos errores como los conjuntos de tests completos. Aparte de los 12 errores detectados:
el testing de unidad detect ocho errores,
el testing de integracin detect once errores, y
el testing de sistema detect doce errores.
Se podran evitar problemas con las pruebas de unidad o de integracin y llevar a cabo solamente
pruebas de sistema, pero esto sera muy caro y consumidor de tiempo. Los valores tanto del testing de
unidad como del de integracin estn claros. El testing de integracin detecta diferentes errores a los
que detecta el testing de unidad. Los desarrolladores no deberan slo realizar ambos tipos de prueba,
sino tambin almacenar los datos para efectuar pruebas de regresin a estos dos niveles.
10
3.2. Comparacin experimental de las tcnicas Slicing, Incremental, Firewall y
Gentica
La comparacin se basa en nueve criterios cuantitativos y cualitativos: tiempo de ejecucin, nmero de
retest seleccionados, precisin, inclusividad, parmetros de usuario, manipulacin de variables globales,
tipo de mantencin, nivel de testing y del tipo de acercamiento.
3.2.1. Algoritmo Slicing
Es un algoritmo basado en el flujo de datos. Este usa la separacin para detectar explcitamente los
pares definicin-uso que son afectados directa o indirectamente por la modificacin del programa. Un
trozo de programa consiste en un bloque de sentencias, incluyendo las condiciones, que pudieran afectar
los valores de variables en que se encuentran en el bloque modificado. La ventaja de este acercamiento
es que no se requieren flujos de datos histricos. Los recorridos del algoritmo encaminan los
procedimientos para determinar el trozo de software asociado al bloque modificado. Los casos de prueba
seleccionados sern todos los que atraviesa un trozo.
3.2.2. Algoritmo Incremental
El algoritmo incremental selecciona casos de prueba cuyas salidas pudieran haber sido afectadas por las
modificaciones realizadas al software. El acercamiento incremental sigue las siguientes observaciones:
No todas las sentencias en el software se ejecutan bajo todos los casos de prueba,
Si una sentencia no se ejecuta bajo un caso de prueba, sta no puede afectar la salida del software
para ese caso de prueba,
Si una sentencia se ejecuta bajo un caso de prueba, sta no afecta necesariamente la salida del
software para el caso de prueba, y
Cada sentencia no afecta necesariamente a cada parte de la salida del programa.
Estas observaciones se pueden utilizar para determinar los trozos de ejecucin dinmicos, y entonces
relevantes para los casos de prueba.
3.2.3. Algoritmo Firewall
Leung y White han propuesto el concepto de "firewall" para asistir al testeador en el testing de regresin
en el proceso de integracin. En vez de emplear el firewall se ha usado el concepto de "tirewall a nivel
del segmento (contra el mdulo). Leung y White sugieren construir "tirewalls" para confinar el testing de
regresin en la integracin a un conjunto pequeo de mdulos ms bien que permitir muchos mdulos.
Un "firewall" involucra los mdulos que fueron modificados y sus antecesores y sucesores directos. El
firewall adaptado se basa en el grafo de flujo de control. Un "firewall" se construye alrededor de los
segmentos modificados y de los segmentos relacionados. Solamente esos segmentos necesitan test de
regresin cuyos casos son seleccionados del conjunto original de pruebas. La construccin del "firewall"
se realiza en los lmites de los segmentos que interactan con los segmentos modificados o afectados en
una de las siguientes maneras:
siendo antecesores directos de las definiciones que afectan la modificacin del programa, o
siendo descendientes directos donde los usos son afectados por la modificacin.
11
3.2.4. Algoritmo Gentico
El algoritmo gentico se basa en una poblacin de individuos. Un individuo se codifica como un vector de
N elementos [ X1, X2. . . Xn ] que corresponde a una solucin candidata para el problema del testing de
regresin. Un elemento o gen Xj = 1 (o 0) indica la inclusin (o la exclusin) del caso de prueba tj
perteneciente al conjunto original de pruebas.
La aptitud de un individuo es maximizada por el algoritmo gentico de acuerdo a 1/Z, donde Z=X1+X2
+.*.+Xn y las restricciones del individuo vienen dadas por la sumatoria desde j=1 hasta N de aijXj >=bi
con i = 1...M; aij es un elemento de la tabla de cobertura del test-segmento; el bi indica si el segmento i
es accesible desde el segmento modificado y, si necesita ser cubierto por el subconjunto de retest.
La poblacin inicial de individuos es generada aleatoriamente y luego evoluciona sobre un nmero de
generaciones, hasta convergir. Una nueva generacin es creada asignando ensayos de reproduccin a
los individuos segn su aptitud, y despus aleatoriamente seleccionando a pares de individuos que
sobreviven y aplicando operadores genticos a cada par para crear a su descendiente. Al final de la
evolucin, un subconjunto ptimo de retest correspondera a la aptitud mxima de individuos factibles.
3.2.5. Criterios de Comparacin
3.2.5.1. Criterios cuantitativos:
1. Tiempo de ejecucin del algoritmo.
2. Nmero de casos seleccionados por el algoritmo a partir del conjunto original, que deben ser
retesteados.
3. Precisin, que se define en trminos de las pruebas de modificacin relevantes y las modificaciones
cruzadas. Las pruebas de modificacin relevantes son las que producen diversas salidas para el
programa modificado. Las pruebas de modificacin cruzada son aquellas que ejecutan cdigo
modificado. Obviamente, no todas las pruebas de modificacin cruzada son pruebas de modificacin
relevante. La precisin mide la capacidad de un algoritmo para omitir las pruebas que no son de
modificacin relevante que, por lo tanto, no harn que el software modificado produzca salidas
diferentes. Si el conjunto inicial de pruebas contiene n1 pruebas de modificacin no relevantes y el
algoritmo de regresin selecciona (n1-m1) de estos test, entonces la precisin del algoritmo viene
dada por (m1 /n1).
4. Inclusividad, mide el grado con el cual el algoritmo de regresin elige las pruebas de modificacin
relevantes que harn que el software modificado produzca salidas diferentes. Si el conjunto de
pruebas original contiene n2 pruebas de modificacin relevantes y el algoritmo de regresin
selecciona m2 de stas, entonces la inclusividad del algoritmo viene dada por (m2/n2).
12
3.2.5.2. Criterios cualitativos:
5. Fijacin de parmetros por parte del usuario, esto se refiere a que si el algoritmo de regresin
requiere la intervencin del usuario para fijar algunos de sus parmetros.
6. Prueba de variables globales: Se consideran las variables globales puesto que crean dependencias
de flujos de datos entre los mdulos
7. Tipo de mantencin: la mantencin del sofware puede ser:
correctiva, debido a los informes de errores
perfectiva, para realzar la funcionalidad del software
adaptativa, debido a los cambios en el ambiente externo, o
preventiva, para facilitar la mantencin futura.
Los algoritmos de regresin se clasifican segn su uso para el tipo correctivo y/o perfectivo
8. Nivel de prueba, esto se refiere a si el algoritmo es conveniente para las pruebas de integracin o
solamente a nivel de mdulo.
9. Tipo de acercamiento: los acercamientos de testing de regresin se pueden clasificar como
cobertura, minimizacin, o seguro.
Los algoritmos que seleccionan solamente pruebas de modificacin cruzada son algoritmos de
cobertura.
Los algoritmos que apuntan a reducir al mnimo el nmero de retest y, as, del tiempo de
prueba son algoritmos de minimizacin.
Los algoritmos que seleccionan siempre todas las pruebas de modificacin relevantes son
algoritmos seguros.
13
3.2.6. Resultados
Para realizar la comparacin la experimentacin utiliz 20 mdulos diferentes de programa (m1 a m20) ,
para los cuales los cdigos fueron escritos y los grafos fueron generados manualmente junto con los
casos de prueba. Estos mdulos son de diferentes tamaos: los pequeos (m1 a m14) y los medianos
(m15 a m20). Cada mdulo tiene asociado: un nmero de segmentos, un nmero de segmentos
modificados, una tabla de casos de prueba y la informacin de cobertura del segmento.
3.2.6.1. Resultados criterios cuantitativos
Tiempos de ejecucin y nmero de retest seleccionados
Para los mdulos de tamao pequeo, slicing y firewall exhiben un comportamiento similar. Para algunos
mdulos, seleccionan un nmero de retest cercano a la estrategia de reprobar todo. El algoritmo
incremental tiene un nmero mejor de retest para tiempos de ejecucin similares. El gentico selecciona
menos nmeros de retest.
Para los mdulos de tamao mediano, firewall toma ms tiempo con un nmero de retest cercano al del
slicing. Incremental da un nmero mejor de retest, en un tiempo de ejecucin cercano al del slicing. El
mejor nmero de retest, es ofrecido constantemente por gentico con un tiempo de ejecucin menor. El
nmero de retest seleccionados por el algoritmo incremental est cercano al del gentico.
Precisin e Inclusividad
Los algoritmos incremental y gentico dan una precisin del 100%, es decir, las pruebas que no harn
que el software modificado produzca salidas diferentes, se evitan completamente. Slicing y firewall tienen
una precisin ms baja. Esto se debe al hecho de que estos algoritmos definen todos los pares
definicin-uso que pueden ser afectados por la modificacin, esto da lugar a seleccionar casos de
pruebas adicionales para probar modificaciones no relevantes.
La inclusividad para slicing y firewall son altas. Estos algoritmos seleccionan solamente pruebas de
modificacin cruzada seleccionando de esta manera pruebas que ejercitan los pares definicin-uso. Sin
embargo, pueden fallar en:
La identificacin de tests que ejecutan sentencias modificadas que no contienen ningn uso de
variables, aunque estas sentencias pueden hacer que el software produzca salidas diferentes.
Pueden no detectar los test que incluyen sentencias suprimidas del software modificado. As,
dependiendo de la modificacin, su inclusividad vara para diversos mdulos.
La inclusividad de incremental vara para diversos mdulos, pero son generalmente ms bajas que sciling
y firewall. Incremental ayuda a seleccionar los casos de prueba en los cuales el nuevo y viejo software
pueden producir salidas diferentes.
Sin embargo, no todos estos casos de prueba son incluidos; si varias pruebas ejercitan una sentencia
particular afectada, slo algunas de ellas se seleccionan de acuerdo a la dependencia de control entre las
sentencias. Gentico exhibe inclusividad ms bajas que los otros algoritmos; si varias pruebas ejercitan
una sentencia particular afectada, ayuda a seleccionar solamente una de esas prueba.
14
3.2.6.2. Resultados criterios cualitativos
Fijacin de parmetros por parte del usuario
Gentico requiere que el usuario fije parmetros, estos son el tamao de la poblacin, el rango de
probabilidades para la reproduccin, el umbral de convergencia, y la razn de mutacin.
Prueba de variables globales
Leung y White han demostrado que las variables globales se pueden tratar como parmetros adicionales
y que pueden ser testeadas por el algoritmo de firewall. Sin embargo, los 4 algoritmos pueden utilizar la
matriz de set/use de una variable para identificar solamente variables globales dentro de los mdulos.
Tipo de mantencin
Los 4 algoritmos son de regresin correctiva. Sin embargo, el concepto del firewall en el nivel de la
integracin apoya ambos, correctiva y perfectiva. Tambin, el algoritmo incremental apoya la mantencin
correctiva y perfectiva. Los otros algoritmos requieren adaptacin adicional para hacerlos convenientes
para la mantencin perfectiva.
Nivel de prueba
Los 4 algoritmos se aplicaron a nivel del mdulo, a excepcin del algoritmo firewall que es inicialmente un
algoritmo a nivel de la integracin. La prueba de integracin no se puede aplica usando el algoritmo
sciling debido a que se basa en identificar los pares definicin-uso a nivel del mdulo.
En el testing de regresin incremental, el computo de los trozos de ejecucin pueden ser hechos a nivel
del mdulo o de la integracin. A nivel de la integracin, un caso de prueba ser seleccionado solamente
si invoca una funcin o un mdulo modificado. Para el gentico, los segmentos pueden ser substituidos
por los mdulos lo que permite a los algoritmos trabajar a nivel del programa.
Tipo de acercamiento
Los algoritmos sciling y firewall, son de cobertura debido a que seleccionan las pruebas que cubren los
pares definicin-uso afectados; a nivel de la integracin el algoritmo firewall selecciona los test que
cubren los mdulos afectados.
El algoritmo incremental es un algoritmo seguro, puesto que tiene como objetivo seleccionar los test que
harn que el software modificado produzca salidas diferentes que el software original.
El algoritmo gentico es de minimizacin; si varias pruebas ejercitan un segmento particular modificado,
slo se selecciona una prueba.
15
3.2.7. Pautas de seleccin de algoritmos
La experiencia indica que:
Para probar todos los pares definicin-uso afectados, sin considerar el tiempo de ejecucin, los
algoritmos que se deberan elegir seran el sciling y el firewall.
Si se desea elegir un nmero mnimo de casos de prueba y, por lo tanto, realizar la prueba de una
manera ms rpida, se debera seleccionar el algoritmo gentico, aunque es lento.
El algoritmo incremental sera la mejor opcin para seleccionar un nmero de casos de prueba para ver
las salidas que pudieron ser afectadas, es el ms rpido entre los 4.
Sin embargo, basado en los nueve criterios, la tendencia indica que el algoritmo incremental tiene
caractersticas ms favorables que los otros cuatro algoritmos.
Algoritmo Slicing Incremental Firewall Gentico
Tiempo de Ejecucin para
mdulos pequeos
Rpido Rpido Rpido Aceptable
Tiempo de Ejecucin para
mdulos medianos
Aceptable Rpido Lento Aceptable
Nmero de test
seleccionados
Aceptable Bueno Aceptable Muy Bueno
Precisin Alta Muy Alta Alta Muy Alta
Inclusividad Alta Media Alta Baja
Fijacin de parmetros de
usuario
No requiere No requiere No requiere Requiere
Prueba de Variables
Globales
Puede
identificar
Puede
identificar
Puede
identificar
Puede
identificar
Correctiva Si Si Si Si Tipo de
Mantencin Perfectiva Si Si, posible Si Si, posible
Unidad Si Si Si Si Nivel de
Prueba Integracin No Con modificacin Si Con modificacin
Tipo de acercamiento Cobertura Seguro Cobertura Minimizacin
Tabla 2. Resumen de Resultados
16
3.3. Integracin tcnicas caja blanca y negra en el testing de regresin en la
orientacin a objeto.
Varias tcnicas se han propuesto para el testing regresin. La mayora de stas se centran en la caja
negra y caja blanca, aunque un acercamiento integrado puede tener varias ventajas. Tareas similares
deben ser realizadas para las pruebas de caja blanca y caja negra, un acercamiento integrado mejora la
eficiencia y el disminuir los costos.
Generalmente, una prueba suficiente de software requiere tcnicas de caja negra y blanca. Aunque
ambas tareas son similares, es decir, tiene los mismos objetivos, el cual es la deteccin critica de errores
dentro de un software, a menudo se aplican por separado usando diversas herramientas.
La razn es una carencia de tcnicas que integran ambas estrategias. Pocos acercamientos han
investigado la integracin de ambas tcnicas para la orientacin a objeto. A menudo, el software se
prueba independientemente contra el cdigo de la especificacin y cdigo fuente usando diversas
herramientas especializadas.
Usar diversas tcnicas y herramientas conduce a menudo a procesos ineficaces. El testeador debe
trabajar con diversas herramientas que podran requerir diversas habilidades y separar as el
entrenamiento. Tambin debe estar familiarizado no solamente con las diversas herramientas, sino que
tambin con sus diversos conceptos subyacentes.
Adems, usar varias herramientas requiere un esfuerzo ms alto del mantenimiento. Por lo tanto, al
integrar las tcnicas de caja negra y blanca se puede mejorar substancialmente el proceso de prueba con
respecto a costos y a tiempo.
3.3.1. Integracin de las tcnicas
3.3.1.1. Construccin de Bloques
3.3.1.1.1. Tcnica Rothermel
La idea principal es comparar dos versiones de una clase para detectar y analizar cambios. De acuerdo
con este anlisis, los casos de prueba que cubren sentencias cambiantes se seleccionan de un conjunto
dado de pruebas anteriores.
La comparacin de las dos versiones de la clase se realiza usando las representaciones de los grafos de
control de flujo de la clase (CCFGs). Un CCFG es una representacin grfica de una clase que visualiza
sus mtodos encajados en un conductor abstracto de prueba. La comparacin se realizada
simultneamente atravesando ambos CCFGs y comparando los nodos correspondientes de los grafos.
3.3.1.1.2. Tcnica de caja negra de Hong
La idea principal de esta tcnica es identificar definiciones y usos de cada atributo y asociarlas de
acuerdo a criterios de flujo de datos. Despus de asociar definiciones y usos a cada uno, los casos de
prueba cubren los pares definicin-uso que se generan.
Para facilitar la generacin del caso de prueba, Hong sugiere una representacin grfica de la clase,
grafo de flujo de la clase (CFG), generado en base a un autmata finito especial llamado la mquina de
estado de la clase (CSM).
17
3.3.2. Ejemplo
El ejemplo consiste en una clase, llamada
account, que simula una cuenta bancaria.
Proporciona los mtodos para hacer
depsitos (deposit()), retiros (withdraw()),
pagar el inters (payInterest()) e imprimir
(printBankStatement()).
Account puede estar en uno de los
siguientes estados: inCredit, overdraw y
blocked.
La figura 3 muestra la especificacin de la
clase account en forma CSM. Cada
estado es representado por un crculo,
mientras que cada transicin lo es a travs
de una flecha que conduce de su estado
fuente a su estado destino.
Figura 3. Especificacin CSM de account.
Una transicin consiste de:
Estado fuente y destino
Un evento que causa la transicin
Un protector del predicado que tenga que ser satisfecho antes de que la transicin pueda ocurrir, y
La accin que define las operaciones en los atributos durante la transicin.
Tambin hay dos crculos especiales etiquetados inicial y final. Estos dos crculos representan el estado
del objeto antes de su creacin y despus de su destruccin, respectivamente. As, representan los
estados en los cuales los atributos y sus valores no se definen, significando que estos dos estados no
son ningn estado concreto del objeto.
Las transiciones son:
t1 = (initial; inCredit; account(); true;balance=0.0;);
t2 = (inCredit; inCredit; deposit(amount); true; balance+=amount;);
t3 = (inCredit; inCredit; withdraw(amount); balance - amount >=0; balance -=amount;);
t4 = (inCredit; inCredit; payInterest(); true; balance=ic*balance;);
t5 = (inCredit; inCredit; printBankStatement(); true; print);
t6 = (inCredit; overdrawn; withdraw(amount); limit < balance - amount < 0; balance -=amount;);
t7 = (overdrawn; inCredit; deposit(amount); balance + amount >= 0; balance+=amount;);
t8 = (overdrawn; overdrawn; deposit(amount); balance + amount < 0; balance+=amount;);
t9 = (overdrawn; overdrawn; withdraw(amount); limit <= balance - amount < 0; balance -=amount;);
t10 = (overdrawn; overdrawn; payInterest(); balance + id1balance>= limit; balance+=id1*balance;);
t11 = (overdrawn; overdrawn; printBankStatement(); true; print);
t12 = (overdrawn; blocked; withdraw(amount); balance - amount < limit; balance -=amount;);
t13 = (overdrawn; blocked; payInterest(); balance + id1balance < limit; balance+=id1*balance;);
t14 = (blocked; overdrawn; deposit(amount); limit <= balance + amount < 0; balance+=amount;);
t15 = (blocked; blocked; deposit(amount); balance + amount < limit; balance+=amount;);
t16 = (blocked; blocked; payInterest(); true; balance+=id2*balance;);
t17 = (blocked; blocked; printBankStatement(); true; print);
t18 = (inCredit; blocked; withdraw(amount); balance - amount < limit; balance -=amount;);
t19 = (blocked; inCredit; deposit(amount); balance + amount < 0; balance+=amount;);
18
t20 = (inCredit; final; finalize(); true; );
t21 = (overdrawn; final; finalize(); true; );
t22 = (blocked; final; finalize(); true;):
El fuente de la clase account es el siguiente:
3.3.3. Implementacin grfica de la especificacin de la clase
El mtodo para integrar las pruebas de caja negra y blanca opera en la representacin grfica de la clase
llamada Implementacin grfica de la especificacin de la clase (CSIG), su construccin consiste en 3
pasos
1. Construir un prototipo para cada tipo de evento que ocurre dentro de las transiciones del CSM.
2. Luego, generar los grafos de control de flujo para cada prototipo y cada mtodo. Se construye un
marco de CCFG y dos grafos de control de flujo de cada mtodo para insertarlos en este marco.
3. Determinar los pares uso-definido para la caja negra base al CSM y visualizado por los arcos de flujo
de datos.
3.3.3.1. Construccin de prototipo por cada tipo de evento
La construccin de un prototipo en primer lugar consiste en el generar de un prototipo para cada
transicin t = (fuente; destino; evento; protector; accin) en forma de una construccin if-then-else
jerarquizada segn:
19
en donde predicate(source) indica el predicado del estado fuente aplicado a los atributos que definen la
ocurrencia del estado fuente. Por ejemplo, el predicate(inCredit) es ' balance > = 0.0'. Despus de
generar estos prototipos, aquellos que tiene el mismo tipo de evento son combinados.
Por ejemplo, las transiciones t2, t7, t8, t14,t15 y t19 comparten el tipo de evento deposit(). Sus prototipos
se pueden combinar al prototipo representado aqu:
Teniendo la representacin de cada mtodo de esta forma, la identificacin de definiciones y los usos de
los atributos es fcil debido a la estructura simple y predefinida de un prototipo. Despus de la
identificacin, los casos de prueba generados cubren los pares definido-usado. Aunque los casos de
prueba se identifican en base de prototipos, hay intentos (caja negra) para probar la correspondiente
clase de mtodo.
3.3.3.2. Generando e insertando grafos de flujo de control dentro del marco CCFG
Este paso consiste en la generacin de los grafos de flujo de control de los mtodos y de los prototipos,
un marco CCFG, y finalmente enlazarlos a un CSIG.
Un CSIG es un grafo dirigido a visualizar tanto el flujo de control como de datos dentro de una clase.
Cada mtodo es representado por dos tipos de grafos de flujo de control. Uno de ellos es un grafo de
flujo de control del prototipo generado en base a la especificacin, mientras que el otro es un grafo de
flujo de control construido usando el cdigo fuente del mtodo. Los grafos de flujo de control son
interenlazados uno con el otro por los arcos de flujo de control y datos.
Se pueden distinguir tres tipos bordes de flujo de control y de datos:
Mtodo-Intra de arcos de flujos control y datos
Este tipo de arco visualiza dependencias del control y de los datos dentro de un solo grafo de flujo de
control. Por ejemplo, los datos se conectan a un nodo que representa una definicin de atributos con otro
que representa el uso en el mismo mtodo.
20
Mtodo-Inter de arcos de flujos de control y datos
Una invocacin de un mtodo dentro de otro es modelada por un arco de flujo de control de inter-mtodo
que conduce del nodo que representa la declaracin de invocacin en el primer mtodo al nodo que
representa la declaracin de entrada del segundo mtodo. Similarmente, los modelos del inter-mtodo
de control de un arco de flujo tambin gatillan un evento dentro de la parte de la accin de una transicin
para causar una segunda transicin. Los arcos de flujo de control del Inter-mtodo conectan ambos
grafos de flujo de control de mtodos con cada otro y grafos de flujo de control de prototipos con cada
otro. Los arcos de flujo de datos del inter-mtodo conectan solamente nodos dentro del grafo de flujo de
control de los prototipos. Como el objetivo de los prototipos es facilitar la identificacin y la asociacin de
definiciones y de usos de atributos, de esta forma los arcos de flujo de datos del inter-mtodo no se
requieren para los grafos de flujo de control del mtodo.
Arcos de especificacin-implementacin
Este tipo de arco visualiza la conexin entre la especificacin y el cdigo fuente conectando los dos
grafos de flujo de control de un mtodo. As, la especificacin-implementacin de un arco se dirige desde
el nodo que representa la accin dentro de un prototipo al nodo que representa la entrada del mtodo
correspondiente.
3.3.3.3. Agregando los arcos de flujo de datos para el testing de caja-negra
Las definiciones y los usos de los atributos se determinan usando el CSM de la clase segn las ideas de
Hong.
En el ejemplo, las siguientes acciones de transiciones contienen una asignacin al atributo balance: a1,
a2, a3, a4, a6, a7, a8, a9, a10, a12, a13, a14, a15, a16, a18 y a19.
Los usos de este atributo estn situados en la parte de la accin: a2, a3, a4, a6, a7, a8, a9, a10, a12,
a13, a14, a15, a16, a18 y a19.
Adems, los usos tambin se contienen en los protectores siguientes: g3, g6, g7, g8, g9, g10, g12, g13,
g14, g15, g18 y g19. Con el uso del atributo balance se puede tambin encontrar los predicados que
definen los estados: inCredit, overdraw y blocked.
Despus de la identificacin, estas definiciones y usos son asociados de acuerdo al criterio del flujo de
datos. Luego, un caso de prueba consiste en una secuencia de llamadas del mtodo, incluyendo los
mtodos que definen y utilizan el atributo.
Generalmente, los mtodos no se pueden invocar en un orden arbitrario, esto significa asociar
definiciones y usos considerando las secuencias posibles del mtodo. Despus de identificar una
definicin en el mtodo A, el uso correspondiente tiene que estar dentro de un mtodo B que se pueda
invocar inmediatamente despus de la invocacin del mtodo A.
Significa inmediatamente que el segundo mtodo tiene que ser invocado antes de que el atributo sea
redefinido por una definicin en otro mtodo. Las secuencias posibles del mtodo son modeladas por el
CSM de la clase. Por ejemplo, todas las definiciones de criterio, que requiere probar cada definicin de
un atributo por lo menos una vez por un uso, se podra satisfacer por los casos de prueba que cubren los
siguientes pares definicin-uso: (a1; g3), (a2; g 3), (a3; a6), (a4; s 5), (a6; g 12), (a7; a3), (a8; a8),
(a9; a9), (a10; s 9), (a12; a15), (a13; a16), (a14; s 4), (a15; a15), (a16; a16), (a18; a14) y (a19; s3).
Por ejemplo, la definicin en la accin 6 no se puede asociar a un uso en la accin 18, puesto que la
transicin t6 cambia el estado del objeto account estado overdraw, mientras que la transicin t18 requiere
el estado inCredit.
21
3.3.4. Usando el CSIG para el testing de regresin
El CSIG de una clase se puede utilizar de varias maneras para el testing. Generalmente, un CSIG se
puede utilizar para generar los casos de prueba que satisfacen algunos criterios de cobertura incluyendo
la identificacin de pares definicin-uso. Despus de las ideas de Rothermel, CSIGs se puede utilizar
tambin para verificar cambios entre dos versiones de una clase. Un algoritmo que pone esta estrategia
en ejecucin es el siguiente:
El algoritmo toma como entrada los nodos raz de los CSIGs de las dos versiones de la clase y un
conjunto de casos de prueba que se ha utilizado para probar la primera versin de la clase, despus de
quitar los casos de pruebas obsoletos. Basada en esta entrada, selecciona los casos de prueba para una
prueba segura de regresin para la ltima versin. Los casos de pruebas seleccionados se pueden
dividir en dos grupos:
el primero contiene los casos para la prueba de caja blanca. Cada uno de stos consiste en una
entrada para el constructor de la clase, si se requiere una, y una entrada para el mtodo cambiante.
el segundo contiene los casos de prueba requeridos para la caja negra. Estos casos de prueba
consisten en una entrada para el constructor, una entrada para el mtodo en el cual el valor de un
atributo se fija, y una entrada para el mtodo en el cual el valor de este atributo se utiliza.
Para facilitar la notacin, los casos de prueba para la caja blanca son representados por una sola
entrada, mientras que los casos de prueba la caja negra son representados por un par de entradas,
asumiendo que el constructor no requiere ninguna entrada.
En lo que sigue en el algoritmo, los nodos en un CSIG son referidos por las letras maysculas, los nodos
de la ltima versin son marcados por una prima. Comenzando con dos nodos G y G, el algoritmo
22
marca en primer lugar G como G, visitado para evitar pasar mltiples veces por los mismos nodos (lnea
17).
Despus, compara ambos nodos, una modificacin de la declaracin representada por G se maneja
segn el tipo de declaracin representado por este nodo (lnea 12). Una modificacin en una asignacin
simple es manejada agregando todos los casos de prueba que cubren esta asignacin simple y
sucesores dato-dependientes a T (lneas 13-14). Una modificacin de una declaracin que no sea una
asignacin simple es manejada agregando todos los casos de prueba que cubren esta declaracin a T
(lnea 16). Hasta ahora, solamente los casos de prueba para la caja blanca han sido seleccionados.
Los casos de prueba para la caja negra se seleccionan en las cinco lneas siguientes del algoritmo, que
es realizado probando datos del flujo inter-mtodo. Los arcos correspondientes conectan una definicin
en un mtodo A con un uso en otro mtodo B. En algunos casos, A y B son el mismo mtodo, pero
invocado dos veces, primero para definir el valor del atributo y despus para utilizar este valor.
En lneas 18-22, los casos de prueba son determinados considerando los primeros datos precursores
dependientes del inter-mtodo y luego los datos sucesores dependientes del inter-mtodo. Despus de
determinar los casos de prueba para el nodo G, se consideran sus sucesores(lnea 23). Sus sucesores
se asocian a los del nodo G (lnea 24) y son diferenciados entre los que no se pueden emparejar a los
sucesores de G (lneas 25-26) y los que tienen contrapartes correspondientes en la versin primera de la
clase (lnea 27-28).
23
4. Efectividad y disponibilidad de tcnicas y herramientas
4.1. Notacin
A continuacin se definir una notacin que ser utilizada ms adelante.
P un programa,
P una versin modificada de P, y
S y S las especificaciones para P y P respectivamente
P(i) se refiere a la salida de P con una entrada i,
P(i) corresponde a la salida de P con una entrada i,
S(i) a la salida especificada por P con entrada i, y
S(i) a la salida especificada por P con entrada i
T un conjunto de tests creado para testear a P
Un test es una 3-tupla (identificador, entrada, salida), en la que identificador corresponde al test, entrada
es la entrada para esa ejecucin del programa y salida es la salida especificada, S(entrada), para esta
entrada. Para simplificarlo, se refiere a un test (t,i,S(i)) por su identificador t, y a las salidas P(i) y S(i) del
test t para la entrada i como P(t) y S(t), respectivamente.
4.2. Clasificacin de las tcnicas
Algunas tcnicas de seleccin de tests de regresin seleccionan tests basadas en informacin
recolectada de especificaciones del programa, la mayora lo hace basada en informacin acerca del
cdigo del programa y de la versin modificada. Estas tcnicas basadas en el cdigo persiguen tres
metas diferentes:
1. Las tcnicas de cobertura localizan componentes del programa que han sido modificadas o
afectadas por modificaciones, y seleccionan tests del conjunto original de test que ejercitan esas
componentes.
2. Las tcnicas de minimizacin trabajan como las de cobertura, pero seleccionan conjuntos mnimos
de tests a travs de componentes del programa modificadas o afectadas.
3. Las tcnicas seguras seleccionan cada test en el conjunto original de test que puede exponer una o
ms fallas en el programa modificado.
4.3. El Retest selectivo
La mayora de las investigaciones recientes se refieren a las tcnicas de retest selectivo. Estas reducen
el costo de testear un programa modificado reutilizando tests existentes e identificando las porciones de
un programa modificado o sus especificaciones que deberan ser testeadas. Las tcnicas de retest
selectivo difieren de las de la tcnica retest-all que vuelve a ejecutar todos los tests en el conjunto de
tests existentes. Leung y White muestran que una tcnica de retest selectivo es ms econmica que la
tcnica retest-all si el costo de seleccionar un subconjunto reducido de test para ejecutar es menor que el
costo de ejecutar los tests que la tcnica de retest selectivo nos permite omitir.
Una tcnica tpica de retest selectivo procede de la siguiente manera:
1. Selecciona T, un subconjunto de test de T para ejecutar sobre P.
2. Testea P con T, para establecer la correccin de P respecto a T.
3. Si es necesario, crea T, un conjunto nuevo de tests funcionales o estructurales para P.
4. Testea P con T, para establecer la correccin de P respecto a T.
5. Crea T, a nuevo conjunto de tests y testea la historia para P, desde T, T y T.
24
Al realizar estos pasos, una tcnica de retest selectivo se enfrenta con cuatro problemas:
Paso 1 : el problema de seleccionar un subconjunto T de T con el cual testear P.
Paso 3 : el problema de identificar porciones de P y S que requieren testeo adicional.
Pasos 2 y 4 : el problema de ejecutar eficientemente los tests y revisar los resultados para su
correccin.
Paso 5 : el problema de actualizar y almacenar la informacin del test.
Todas las tcnicas de seleccin de tests de regresin intentan seleccionar un subconjunto T de T que
sea til en establecer la confianza de que P fue modificado correctamente y que la funcionalidad de P se
ha mantenido donde se requiera. En este sentido, todas las tcnicas de seleccin de test basados en el
cdigo estn afectadas., entre otras cosas, con ubicar tests en T que expongan las fallas en P. De este
modo, es apropiado evaluar las habilidades relativas de las tcnicas para elegir tests desde T que
detecten fallas.
4.4. Clases de Test para medir la efectividad de las tcnicas
Un test t detecta una falla en P si ocasiona que P falle: en ese caso se dice que es revelador de fallas
para P. Un programa P falla para t si, cuando P es testeado con t, P produce una salida que es
incorrecta de acuerdo a S. No hay un procedimiento efectivo mediante el cual se encuentre los tests en T
que son reveladores de fallas para P. Sin embargo, bajo ciertas condiciones, una tcnica de seleccin
de test de regresin puede seleccionar un superconjunto de tests de los tests en T que son reveladores
de fallas para P. Bajo esas condiciones, una tcnica semejante no omite tests en T que puedan revelar
fallas en P.
Un segundo subconjunto de los tests en son los tests reveladores de modificaciones. Un test es
revelador de modificaciones para P y P si y slo si ocasiona que las salidas de P y P difieran. Dadas
dos suposiciones, se pueden encontrar los tests en T que son reveladores de fallas para P, encontrando
los tests que son reveladores de modificaciones para P y P. Las suposiciones son las siguientes:
Suposicin P-Correcto-para-T. Para cada test t en T, cuando P fue testeado con t, P mantuvo y produjo
la salida correcta.
Suposicin Identificacin-Test-Obsoleto. Existe un procedimiento efectivo para determinar, para cada
test en t, si t es obsoleto para P. El test t es obsoleto para el programa P si, y solo si t, tanto especifica
una salida para P que, de acuerdo a S, es invlida para P, como si t especifica una relacin entrada-
salida invlida para P.
Para encontrar tests en T que sean reveladores de fallas para P, se ejecuta un procedimiento para
identificar tests obsoletos en T, y se remueven de T. Se sabe que todo test que queda en T determina y
produce salida correcta para P, y se supone que produce la misma salida para P. De esta forma, los
nicos tests dejados en T que pueden ser reveladores de fallas para P son aquellos que son reveladores
de modificaciones para P y P, y se pueden encontrar esos tests reveladores de fallas simplemente
encontrando los tests reveladores de modificaciones. Adems, algunos tests identificados como
obsoletos pueden an implicar salidas legales para P que, si se usan para testear a P, revelan fallas en
P. Sin embargo, se pueden encontrar estos tests simplemente ejecutando P con esas entradas, y
fijando un tiempo lmite b tal que, si cualquier test excede ese lmite, asumimos que es revelador de fallas
para P.
Desafortunadamente, incluso cuando la suposicin P-Correcto-para-T y la suposicin Identificacin-Test-
Obsoleto permanecen, no hay un procedimiento efectivo para identificar en forma precisa los tests no
obsoletos en T que son reveladores de modificaciones para P y P. As, se considera un tercer
25
subconjunto de T, los tests atravesadores de modificaciones. Un test t perteneciente a T es
atravesador de modificaciones para P y P si, y slo si
(a) ejecuta cdigo nuevo o modificado en P, o
(b) cdigo ejecutado anteriormente que ha sido borrado ya desde P.
Los tests atravesadores de modificaciones son tiles de considerar porque, con una suposicin adicional,
un test t no obsoleto en T puede slo ser reveladores de modificaciones para P y P si es atravesadores
de modificaciones para P y P. La suposicin adicional es la siguiente:
Suposicin Testing de Regresin Controlada. Cuando P es testeado con t, se mantiene todos los
factores que podran influir en la salida de P, excepto el cdigo en P, constante en relacin a sus
estados cuando se testea P con t.
Cuando la Suposicin del Testing de Regresin Controlada se mantiene (con las primeras dos
suposiciones), se puede identificar los tests en T que son reveladores de fallas para P y P, identificando
los tests no obsoletos en T que son atravesadores de modificaciones para P y P, y luego determinar, de
entre los tests obsoletos para T, aquellos tests que son reveladores de fallas para P y P. Cuando se
cumplen las tres suposiciones, este proceso localiza los tests en T que son reveladores de fallas para P.
La figura 4 muestra la relacin que se establece entre los
conjuntos de tests obsoletos, reveladores de fallas,
reveladores de modificaciones y atravesadores de
modificaciones en T cuando se cumplen las suposiciones.
Existen pocos algoritmos eficientes para identificar los test
atravesadores de modificacin para P y P. Sin embargo,
incluso aunque el problema de identificar con precisin los
tests en T que son atravesadores de modificaciones para P
y P no es posible de tratar, en general, hay algoritmos que
pueden identificar conservadoramente esos tests. Al hacer
as, para los casos en que se cumplen las tres
suposiciones, estos algoritmos seleccionan todos los tests
no obsoletos en T que son reveladores de fallas para P.
Figura 4. Relacin entre clases de test
La suposicin Testing de Regresin Controlada no es siempre prctica. Por ejemplo, si se lleva P a otro
sistema, creando P, no se puede usar el testing de regresin controlada para testear P en el nuevo
sistema: el testing de regresin controlada pide que se mantengan todos los factores adems de la
constante del cdigo, incluyendo el sistema. Cuando no se emplea el testing de regresin controlada, la
seleccin de los tests atravesadores de modificaciones pueden omitir los tests reveladores de
modificaciones.
Por ejemplo, P (de la situacin anterior) puede fallar en los tests que no son atravesadores de
modificaciones para P y P si el nuevo sistema tiene menos memoria disponible para localizaciones
dinmicas que el antiguo sistema. Hay tambin otros factores que afectan la viabilidad de la suposicin
en la prctica: el no determinismo en los programas, dependencias de tiempo, e interacciones con el
ambiente externo pueden ser todos difciles (aunque no necesariamente imposible) de incorporar en el
proceso de testing en la forma que permita el testing de regresin controlada. Sin embargo, an cuando
no se puede emplear el testing de regresin controlada, los tests de atravesamiento de modificaciones
pueden constituir un conjunto til de tests. Se supone que cuando se limita un conjunto de testing, y se
debe elegir un subconjunto de T, los tests que ejecutan cdigo cambiado son mejores candidatos para la
reutilizacin que los tests que no son atravesadores de modificaciones.
Las tres clases de tests pueden contribuir a la especificacin de la estructura para evaluar y comparar las
tcnicas de seleccin de test de regresin, por varias razones:
26
Primero, los profesionales del testing son reacios a descartar tests que pueden exponer fallas. A
pesar de que muchas tcnicas de seleccin de tests de regresin tienden a seleccionar tests para
satisfacer alguna medida de adecuacin del test, es razonable e importante evaluar esos mtodos en
trmino de sus habilidades para detectar fallas.
Segundo, incluso para los casos en que la suposicin del Testing de Regresin Controlada no puede
ser satisfecha, las tres clases pueden todava sirven para distinguir las tcnicas de seleccin de tests
de regresin existentes. La mayora de las tcnicas de seleccin de tests de regresin basadas en el
cdigo tratan de identificar tests que ejecuten componentes cambiadas de P. Muchas tcnicas
intentan ser ms precisas, eliminando, de aquellos tests que ejecutan componentes cambiados,
algunos tests que claramente no pueden hacer que P y P produzcan una salida diferente. As, es til
comparar las tcnicas de seleccin de tests en trminos de sus habilidades para identificar estas
clases de tests.
Tercero, en la prctica, para sistemas de software extensos, los conjuntos de tests son funcionales, y
la meta de testing no es cubrir los componentes de cdigo, sino el testing de conductas funcionales.
Cuando los conjuntos de tests se construyen primariamente para proporcionar cubrimiento al cdigo,
puede tener poco sentido seleccionar todos los tests que pasan a travs de una componente, ya que
slo un test semejante proporcionar ese cubrimiento. Pero cuando los conjuntos de tests son
funcionales parece particularmente importante no omitir tests de T que puedan revelar fallas en P,
an cuando puedan ejercitar componentes de cdigo ya ejercitadas por otros tests.
27
4.5. Mtricas para medir la efectividad de las tcnicas
Dada esta abundancia de tcnicas de seleccin del test de regresin, si se quiere escoger una tcnica
para una aplicacin prctica, se necesita una forma de comparar y evaluar las tcnicas.
Las mtricas para comparar y evaluar las tcnicas de seleccin del test de regresin son:
1. Inclusividad, mide la amplitud con que una tcnica elige tests que causarn que el programa
modificado produzca diferentes salidas a las del programa original, y por lo tanto expone las fallas
causadas por las modificaciones.
2. Precisin, mide la habilidad de una tcnica en evitar la eleccin de tests que no causarn el que el
programa modificado produzca una salida diferente a la del programa original.
3. Eficiencia, mide el costo computacional, y as, prcticamente, el de la tcnica.
4. Generalidad, mide la habilidad de una tcnica en manejar construcciones de lenguaje realistas y
diversas, modificaciones de cdigo arbitrariamente complejo, y aplicaciones de testing realista.
Estas mtricas forman una estructura para la evaluacin y comparacin de las tcnicas de seleccin del
test de regresin. Al comparar y evaluar las diferentes mtricas de las tcnicas ayuda a elegir tcnicas
apropias para aplicaciones particulares. Por ejemplo, si se necesita un cdigo muy confiable, se puede
insistir en una tcnica de retest selectivo segura, a pensar del costo. Por otra parte, si se debe reducir el
tiempo de testeo se puede elegir una tcnica de minimizacin, incluso aunque al hacerlo se puede fallar
en elegir algunos test que exponen los errores en el programa modificado. La evaluacin y comparacin
de tcnicas existentes tambin proporcionan vistas interiores de las fortalezas y debilidades de las
tcnicas actuales, y guan en la eleccin de reas sobre las que futuros trabajos sobre seleccin de tests
de regresin deberan enfocarse.
4.5.1. Inclusividad
Sea M una tcnica de seleccin de test de regresin. La Inclusividad mide la amplitud con que M escoge
tests reveladores de modificaciones de T para inclusin en T. Se define la inclusividad relativa a un
programa particular, a un programa modificado, y a un conjunto de tests, como:
Definicin1: Supngase que T contiene n tests que son reveladores de modificaciones para P y P, y
supngase que M selecciona m de estos tests. La inclusividad de M relativa a P, P y T es
(1) el porcentaje dado por la expresin (100(m/n)) si n 0
(2) 100% si n = 0.
Por ejemplo, si t contiene 50 tests de los cuales 8 son reveladores de modificaciones para P y P, y M
selecciona 2 de estos 8 tests, entonces M es 25% inclusiva con relacin a P, P y T. Si T contiene tests
no reveladores de modificaciones, entonces cada tcnica de seleccin de test es 100% inclusiva con
relacin a P, P y T. Si M selecciona siempre todos los tests reveladores de modificaciones decimos que
M es segura, como sigue:
Definicin 2: Si para todo P, P y T, M es 100% inclusiva con relacin a P, P y T, M es segura.
Para una eleccin arbitraria de M, P, P y T, no hay algoritmo que determine la inclusividad de M con
relacin a P, P y T; sin embargo, todava se pueden disear conclusiones tiles sobre la inclusividad:
Primero, se puede probar que M es segura, mostrando que M selecciona un super conjunto conocido
de tests reveladores de modificaciones. Por ejemplo, si M selecciona todos los tests atravesadores
de modificaciones, entonces para el testing de regresin controlada M es segura.
28
Segundo, se puede probar que M no es segura, encontrando un caso para el cual M omite un test
revelador de modificaciones.
Tercero, se pueden comparar las tcnicas de seleccin de tests M1 y M2 con cada una de las otras
en trminos de inclusividad mostrando que las tcnicas seleccionan subconjuntos Q y R de tests
reveladores de modificaciones, y mostrando que Q es un subconjunto o un superconjunto de R.
Finalmente, se comparan estos tests con los tests reveladores de modificaciones en T.
La inclusividad y la seguridad son medidas significativas. Si M es segura entonces M selecciona cada
test no obsoleto en T que es revelador de fallas para P, mientras que si M no es segura, puede omitir
tests que exponen fallas. Adems, sosteniendo la hiptesis de que si M1 y M2 son tcnicas de seleccin
de test de regresin, y M1 es ms inclusiva que M2, entonces M1 tiene una mayor habilidad para exponer
fallas que M2.
Todas las tcnicas de seleccin de test de regresin basadas en el cdigo consideran los efectos del
cdigo modificado; sin embargo, para evaluar la inclusividad de una tcnica se debe considerar tambin
los efectos del cdigo nuevo y del cdigo borrado. Cuando P se crea agregando nuevo cdigo a P, T
puede contener ya tests que son reveladores de modificaciones debido a ese cdigo.
Por ejemplo, considerando los fragmentos de cdigo F1 y F1
Cualquier test que ejecute la declaracin S2 en el fragmento F1, necesariamente ejecuta la declaracin
S2a en el fragmento F1 y puede ser revelador de modificaciones dependiendo de las sentencias que
encuentre subsecuentemente.
De modo similar, cuando P se crea borrando cdigo de P, T puede cont ener tests que son reveladores
de modificaciones debido a este cdigo borrado.
Por ejemplo, considerando los fragmentos de cdigo F2, F2, F3 y F3
la sentencia S1 en el fragmento F2 se borra, dejando el fragmento F2. En ausencia de otras
modificaciones, cualquier test que ejecute S1 en F2 puede producir una salida diferente en F2.
En el caso de F3 y F3, dos sentencias se borran del fragmento F3, dejando el fragmento F3. En
ausencia de otras modificaciones, cualquier test en que tanto P como Q sean verdaderas, puede producir
una salida diferente en F3.
Si M no cuenta para los efectos de un cdigo nuevo y borrado, se pueden encontrar ejemplos de
adiciones o borrados de cdigo que prueben que M no es seguro.
29
4.5.2. Precisin
Sea M una tcnica de seleccin de test de regresin. La precisin mide la extensin con la que M omite
tests que son no reveladores de modificaciones. Se define la precisin relativa a un programa particular,
programa modificado y conjunto de test, como:
Definicin 3: Supngase que T contiene n tests que son no reveladores de modificaciones para P y P y
que M omite m de estos tests. La precisin de M en relacin a P, P y T es
(1) el porcentaje dado por la expresin (100(m/n)) si n 0,
(2) 100% si n = 0.
Por ejemplo, si T contiene 50 tests de los cuales 44 son no reveladores de modificaciones para P y P, y
M omite 33 de estos 44 tests, entonces M es 75% precisa con relacin a P, P y T. Si t no contiene tests
no reveladores de modificaciones, entonces cada tcnica de seleccin de test es 100% precisa en
relacin a P, P y T.
De igual forma que con la inclusividad, no existe un algoritmo para determinar, para un conjunto arbitrario
de M, p, P y T, la precisin de M relativa a P, P y T; sin embargo, se pueden disear conclusi ones tiles
acerca de la precisin:
Primero, se pueden comparar las tcnicas de seleccin de test M1 y M2 con cualquier otra en
trminos de precisin, mostrando que las tcnicas seleccionan subconjuntos Q y R de tests no
reveladores de modificaciones, y mostrando que Q es un subconjunto o un superconjunto de R.
Segundo, se puede probar que M no es precisa al encontrar un caso en el cual M selecciona un test
que es no revelador de modificaciones.
Tercero, se puede utilizar la experimentacin para comparar precisiones relativas.
Finalmente, se podra probar que M es precisa si se pudiera mostrar que M omite un superconjunto
de tests no reveladores de modificaciones.
La precisin es til porque mide la extensin con la que M evita seleccionar tests que no pueden producir
una salida de programa diferente. En general, se pueden comparar tcnicas de seleccin de test en
trminos de precisin, se pueden identificar las tcnicas que promueven el menor testing innecesario. En
particular, cuando se pueden comparar tcnicas de seleccin de tests seguros en trminos de precisin,
se puede identificar tcnicas que estn muy cerca de la meta de seleccionar exactamente los tests
reveladores de modificaciones.
Cuando se evala la precisin de una tcnica de seleccin de test, es til considerar el procedimiento
structchange y la versin modificada del mismo. Los cambios en structchange crean una versin
modificada, sintcticamente diferente, pero semnticamente equivalente: los cambios no afectan la salida
del programa en ninguna salida. Si M selecciona cualquier test para este par de procedimientos, es
imprecisa.
30
Otro procedimiento: pathological, y una versin modificada: pathological, que pueden ser tiles cuando
se evala la precisin de una tcnica de seleccin de test. Cada constructor while en las dos versiones
incrementa primero el valor de x, y luego testea el valor incrementado para determinar si entra o sale de
su ciclo. Para un test con valor de entrada 0, ambas versiones tienen como valor de salida 1, por lo
que para un test con valor de entrada -2, la salida de pathological es 1 y la de pathological es 3. Si
M selecciona el test con valor de salida 0, es imprecisa.
4.5.3. Eficiencia
La eficiencia de las tcnicas de seleccin de test de regresin se mide en trminos de sus requerimientos
de espacio y tiempo. En lo referente al tiempo, una tcnica de seleccin de tests es ms econmica que
la tcnica retest-all si el costo de seleccionar T es menor que el costo de ejecutar los test en T-T. La
eficiencia de espacio depende primariamente de la historia del test y de la informacin del anlisis del
programa que debe almacenar una tcnica. De esta manera, la eficiencia, tanto del espacio como el
tiempo, depende del tamao del conjunto de tests que selecciona una tcnica, y del costo computacional
de esa tcnica.
El primer factor por considerar cuando se evala la eficiencia de una tcnica de seleccin de test es la
fase del ciclo de vida en la que la tcnica realiza sus actividades. Se distinguen dos fases en el ciclo de
vida del testing de regresin tpico: una fase preliminar y una fase crtica.
31
La fase preliminar del testing de regresin comienza despus de la liberacin de alguna versin del
software. Durante esta fase preliminar, los programadores optimizan y corrigen el software. Cuando las
correcciones estn completas, comienza la fase crtica del ciclo de vida del testing de regresin.
En esta fase crtica, el testing de regresin es la actividad dominante; su tiempo es limitado, a veces en
forma severa, por la muerte de la versin del producto. En esta fase crtica es cuando la minimizacin del
costo es ms importante para el testing de regresin.
Las tcnicas de seleccin del test de regresin pueden aprovechar las fases del ciclo de vida del testing
de regresin. Por ejemplo, una tcnica que requiere historia del test e informacin del anlisis del
programa durante la fase crtica puede alcanzar un costo menor de la fase crtica reuniendo algo de esa
informacin durante la fase preliminar. Cuando se evalan las tcnicas de seleccin por su eficiencia, se
diferencia entre costos en los que se incurre durante la fase preliminar del testing de regresin y costos
en los que se incurre durante la fase crtica.
Un segundo factor por considerar cuando se evala la eficiencia de una tcnica de seleccin de test es
su automatizacin. El esfuerzo humano es caro; las tcnicas que requieren interaccin humana excesiva
no son prcticas. Los costos relativos del esfuerzo humano versus el tiempo de mquina pueden crear
situaciones en las que, an cuando la seleccin de test requiera ms tiempo que el mtodo retest-all, es
preferible la seleccin de test.
Por ejemplo, supngase que se necesitan dos horas de anlisis para determinar que se puede grabar
una hora de testing. Si el anlisis es completamente automatizado, el testing requiere interaccin
humana intensiva, y nos conviene el tiempo de anlisis, entonces la seleccin de test es preferible.
Finalmente, an cuando un mtodo de seleccin de test sea eficiente en la fase crtica, puede ser
impracticable, si requiere excesiva interaccin humana durante la fase preliminar.
Un tercer factor que impacta en la eficiencia de una tcnica de seleccin de test es la extensin en la que
la tcnica debe calcular informacin sobre modificaciones del programa. Una tcnica que debe
determinar cada componente del programa que ha sido modificado en, borrado de o agregado a P, o
calcular una correspondencia entre P y P, puede ser ms caro que una tcnica que calcula informacin
modificada a medida que se necesita. Una tcnica que calcula informacin a medida que se necesita
puede encontrar que slo se necesita una correspondencia parcial, ahorrando trabajo en comparacin
con una tcnica que primero calcula una correspondencia completa.
Las tcnicas de seleccin de test de regresin que requieren informacin de la modificacin la obtienen
mediante uno de los siguientes sistemas:
El primero consiste en utilizar un editor incremental que rastrea las modificaciones a medida que los
programadores de mantencin las realizan. En este caso, el costo de obtener la informacin ocurre
durante la fase preliminar del testing de regresin y no durante la fase crtica.
Un segundo sistema para obtener informacin de la modificacin emplea un algoritmo diferenciador
que calcula una correspondencia entre P y P, que muestra qu componentes en P son nuevos, qu
componentes en P han sido borrados, qu componentes en P corresponden a cules componentes
en P, y cules de estas componentes correspondientes han sido modificadas.
Un factor final que afecta la eficiencia de las tcnicas de seleccin de tests se relaciona con la
habilidad de las tcnicas para manejar casos en los que P se crea mediante mltiples modificaciones
de P. Una que depende de anlisis de programas y procesa una modificacin a la vez, puede ser
forzada a reanalizar o actualizar incrementalmente anlisis o informacin histrica de tests despus
de considerar cada modificacin. Tales reanlisis pueden ser onerosos e impactar significativamente
en el costo de una tcnica. Un enfoque de este tipo puede bastar en el contexto de un proceso de
testing de regresin incremental; sin embargo, en un proceso big bang, este gasto puede ser
prohibitivo.
32
4.5.4. Generalidad
La generalidad de una tcnica de seleccin de tests es su habilidad para funcionar en un rango amplio y
prctico de situaciones. Los factores que deben ser considerados al evaluar la generalidad de una
tcnica son los siguientes:
Primero, una tcnica de seleccin debera funcionar para una clase identificable y prctica de
programas. Por ejemplo, una tcnica que se define slo para procedimientos construidos con if,
while y constructores de sentencias de asignacin, no es prctica, de acuerdo a lo definido.
En segundo lugar, una tcnica de seleccin de tests debera manejar modificaciones de programa
realistas. Por ejemplo, una tcnica que no maneja modificaciones que alteran el flujo de control en
los programas no es prctica, en general.
Tercero, una tcnica que para su xito depende de suposiciones relacionadas con el testing o los
ambientes de mantencin es menos general que una tcnica que no requiere semejantes
suposiciones. Por ejemplo, una tcnica que requiere que el testing inicial sea realizado utilizando
criterios de testing de flujo de datos es menos general que una tcnica que no implica requerimientos
en el testing inicial. De modo semejante, una tcnica que requiere un editor incremental para seguirle
la pista a las modificaciones del cdigo es menos general que una tcnica que no tiene tal
requerimiento.
Cuarto, una tcnica que depende de la disponibilidad de herramientas de anlisis para un programa
particular es menos general que una tcnica que no depende de tales herramientas. Por ejemplo,
una tcnica que requiere una coleccin de informacin de test de seguimiento es menos general que
una tcnica que no requiere esta informacin, debido a que los instrumentos requeridos para
recolectar estas pistas pueden ser excesivamente intrusivos para ciertas aplicaciones de testing. Por
razones similares, un mtodo que requiere seales en una base por funcin, es ms general que una
tcnica que necesita seales en una base por declaracin.
Finalmente, una tcnica puede soportar seleccin de tests intra o interprocedimental. En la prctica,
el test de regresin es a menudo realizado a nivel interprocedimental en subsistemas o programas.
Ms an, la evidencia emprica sugiere que la seleccin de tests a nivel intraprocedimental no
pueden ofrecer ahorros suficientes como para justificar su costo.
Las tcnicas de seleccin de tests enfrentan otros asuntos en que se manifiestan los criterios anteriores.
Primero, entre las tcnicas seguras, el incremento en la precisin se obtiene generalmente mediante
incrementos en el anlisis. As, el incremento de la precisin puede disminuir la eficiencia. Entra las
tcnicas que no son seguras el incremento, tanto de la precisin como de la inclusividad, puede disminuir
la eficiencia. Cuando la eficiencia disminuida lleva el costo del anlisis ms all de un cierto ni vel, puede
hacer que el costo del testing de regresin selectiva sea mayor que el costo de la tcnica del retest-all.
Segundo, la mayora de los factores que afectan a la generalidad, tambin tienen implicaciones sobre la
inclusividad, la eficiencia y la precisin. Por ejemplo, las tcnicas basadas en flujo de datos que no
calculan la informacin de alias, pueden hacer suposiciones conservadoras para manejar programas que
contienen alias.
El intento por aumentar la generalidad de estos mtodos amplindolos para manejar alias, disminuye su
eficiencia. De modo similar, las tcnicas que manejan mltiples modificaciones, cada una a su tiempo,
incurren en castigos en la eficiencia si deben volver a analizar programas despus de considerar cada
modificacin; si tcnicas de este tipo no realizan reanlisis, sin embargo, pueden incurrir en castigos en la
precisin.
33
4.6. Anlisis de Tcnicas de Seleccin de Test de Regresin
A continuacin se presentan algunas de las tcnicas existentes en la seleccin de tests de regresin y se
describen las mtricas antes mencionada por cada una de ellas. Para ilustrar la inclusividad y la
precisin, se utilizan diagramas como el que se muestra en la figura 5:
Figura 5. Diagrama base para inclusidad y precisin
en donde la caja externa delimita el conjunto de todos los tests no obsoletos en T. Los tres crculos
etiquetados como M, N y D, representan conjuntos de tests que ejecutan cdigo modificado en P,
nuevo cdigo en P o cdigo en P que ha sido eliminado de P, respectivamente.
Los tres crculos se intersectan debido a que algunos tests ejecutan dos o tres tipos de cambios de
cdigo. Todos los tests en los conjuntos representados por los crculos son atravesadores de
modificaciones; aquellos que no se encuentran en esos conjuntos no son atravesadores de
modificaciones.
El rea achurada de la figura representa el conjunto de tests reveladores de modificaciones. Debido a
que cada categora de tests atravesadores de modificaciones contiene algunos tests que son reveladores
de modificaciones y algunos que no lo son, el rea achurada contiene y omite porciones de cada rea
formada por las intersecciones de los crculos.
Para representar la inclusividad y la precisin de una tcnica particular de retest selectivo, existen
porciones sombreadas de estos diagramas. El rea sombreada muestra los conjuntos de tests
atravesadores de modificaciones y reveladores de modificaciones que una tcnica admite u omite.
34
La Figura 6 representa en A la inclusividad y la precisin de la tcnica retest-all y en B una tcnica
ptima. Debido a que la tcnica retest-all selecciona todos los tests, esta sombreado todo el diagrama de
la izquierda. Una tcnica ptima, por otro lado, selecciona exactamente los tests reveladores de
modificaciones; por esto, en el diagrama de la derecha se encuentra sombreado slo el rea que delimita
tests reveladores de modificaciones.
Figura 6. Inclusividad y precisin para tcnicas retest-all y una tcnica ptima
En unos pocos casos se emplean reas sombreadas mayores para indicar que algunas tcnicas
particulares son ms o menos inclusivas que otras tcnicas para categoras particulares de tests. En
cada uno de estos casos, sin embargo, se seala esta relacin en el texto cuando se describe el
diagrama. Con excepcin de unos pocos casos en los que importa el tamao relativo de las reas
sombreadas, no se debera asignar importancia al tamao de las regiones o reas sombreadas en los
grafos.
Para evaluar la eficiencia de tiempo se utiliza el anlisis de tiempo del peor caso. En muchos casos en
los que no esta disponible este anlisis, se realiza por experimentacin.
35
4.6.1. Tcnicas de Ecuacin Lineal (Linear Equation)
Las tcnicas de ecuacin lineal utilizan sistemas de ecuaciones lineales para expresar relaciones entre
tests y segmentos de programa. Las tcnicas obtienen sistemas de ecuaciones de matrices que rastrean
segmentos de programa alcanzados por casos de tests, segmentos alcanzables por otros segmentos y
(opcionalmente) informacin definicin-uso relacionada con los segmentos. Las tcnicas
intraprocedimentales utilizan un algoritmo de programacin entera 0-1 para identificar un subconjunto T
de T que, si P no contiene modificaciones que afecten el flujo de control, asegura que todo segmento
que es estadsticamente alcanzable desde un segmento modificado (y opcionalmente todo segmento que
puede estadsticamente alcanzar), es ejecutado por al menos un test en T que tambin ejecuta el
segmento modificado. Una variante interproc edimental de las tcnicas trata subrutinas como segmentos;
este enfoque monitorea ms bien cubrimiento de subrutinas que cubrimiento de sentencias, y soporta
seleccin de test para programas en los que las modificaciones han afectado al flujo de control. Las
tcnicas intra e interprocedimentales pueden utilizar definicin de variable y emplear informacin en vez
de o en conjunto con informacin de flujo de control.
Inclusividad. Las tcnicas de minimizacin omiten los tests reveladores de modificaciones. Si varios
tests ejecutan un segmento modificado particular y todos estos tests alcanzan a un segmento de cdigo
particular afectado, las tcnicas de minimizacin seleccionan solamente uno de tales test a menos que
seleccionen los otros para cubrimiento extra. Por ejemplo, los fragmentos de cdigo y los casos de tests
mostrados a continuacin, donde el fragmento F4 representa una versin modificada del fragmento F4
en el que la declaracin S5 est modificada en forma errnea. Los tests t3 y t4 ejecutan las sentencias
S5 y S5. El test t3 produce una excepcin de divisin por cero en S5, mientras que el test t4 no lo hace.
Las tcnicas de minimizacin seleccionan slo uno de estos tests y omiten el otro; si seleccionaran t4
perderan una oportunidad de presentar la falla que expone t3. Debido a que las tcnicas de
minimizacin pueden omitir este test revelador de modificaciones, no son seguras.
Las tcnicas de ecuacin lineal no necesitan competir por minimizacin. En este caso, las tcnicas
seleccionan conjuntos de tests seguros. En su variante intraprocedimental, en donde las tcnicas slo
manejan situaciones en que las modificaciones de cdigo no alteran el flujo de control, las tcnicas de
minimizacin pueden revertirse para seleccionar todos los tests mediante procedimientos en que tales
modificaciones han ocurrido. Las variantes interprocedimentales de las tcnicas no tienen problema con
las alteraciones en el flujo de control, porque identifican justamente los procedimientos o funciones sin
consideracin al tipo de modificacin.
Precisin. Aplicadas a procedimientos modificados para los que el flujo de control no es afectado, las
tcnicas de ecuacin lineal intraprocedimental omiten los tests no atravesadores de modificaciones,
ignorando los tests que no ejecutan segmentos cambiados. Sin embargo, cuando el flujo de control es
afectado, las tcnicas de ecuacin lineal no son definidas a nivel intraprocedimental. El uso de
informacin de flujo de datos puede aumentar fuertemente la precisin de las tcnicas. A nivel
interprocedimental, las tcnicas de ecuacin lineal pueden seleccionar tests que atraviesan
procedimientos modificados, pero no atraviesan ningn cdigo modificado en esos procedimientos. Tales
tests no son atravesadores de modificaciones, de modo que al seleccionarlos se pierde precisin.
36
La figura 7 describe la inclusividad y la precisin de las tcnicas de ecuacin lineal, representadas en el
Diagrama A como tcnicas de minimizacin, y en el Diagrama B como tcnicas interprocedimentales de
no minimizacin.
Figura 7. Inclusividad y precisin para tcnicas de ecuacin lineal
El Diagrama A ilustra la falta de seguridad de la minimizacin, dejando reas no sombreadas dentro de
todas las categoras de tests. Por fuera de los crculos, el rea sombreada describe los tests no
atravesadores de modificaciones seleccionados por las tcnicas, suponiendo que, cuando los
procedimientos contienen flujo de control modificado, deben seleccionar todos los tests mediante los
procedimientos. El Diagrama B muestra la inclusividad y la precisin de las tcnicas de ecuacin lineal
cuando no intentan minimizar el conjunto de tests seleccionados. En este caso, las reas circulares
sombreadas significan la seleccin de tcnicas de todos los tests atravesadores de modi ficaciones,
mientras que las reas sombreadas por fuera de los crculos corresponden a la seleccin de tcnicas de
tests que no son atravesadores de modificaciones.
Eficiencia. Las tcnicas de ecuacin lineal son automatizables. Cuando las tcnicas operan como
tcnicas de minimizacin, devuelven pequeos conjuntos de tests y as reducen el tiempo requerido para
ejecutar los tests seleccionados. Sin embargo, debido a los clculos requeridos para resolver sistemas
de ecuaciones lineales, las tcnicas pueden ser intensivas en datos y clculos en programas extensos.
De hecho, el problema subyacente es intenso en NP, y todos los algoritmos de programacin entera 0-1
conocidos pueden ocupar tiempo exponencial. A pesar de este comportamiento como peor caso, existen
algoritmos de programacin entera 0-1 que pueden obtener soluciones, en la prctica, en tiempos que
pueden ser aceptables.
Tanto las tcnicas intraprocedimentales como las interprocedimentales requieren el clculo de una
correspondencia entre segmentos en P con segmentos en P, y de qu segmentos han sido modificados,
despus que el testing ha entrado en su fase crtica.
Generalidad. Las tcnicas de ecuacin lineal pueden implementarse para cualquier lenguaje
procedimental. Tanto las versiones intraprocedimentales como las interprocedimentales de la tcnica
estn definidas. La tcnica intraprocedimental est definida slo para modificaciones que afectan el flujo
de control. La tcnica interprocedimental maneja todo tipo de modificaciones de programa. Las tcnicas
son independientes de los criterios de cubrimiento subyacentes, pero se prefieren, en general, para
utilizarlas con criterios de flujo de control o flujo de datos. Las tcnicas requieren herramientas para
resolver problemas de programacin entera 0-1, y para recolectar informacin de seguimiento de tests, ya
sea a nivel de funcin o en algn nivel de segmento intraprocedimental.
37
4.6.2. Tcnica de Ejecucin Simblica (Symbolic Execution)
Esta tcnica utiliza particiones de entrada y ejecucin simblica orientada a los datos para seleccionar y
ejecutar tests de regresin. Inicialmente, la tcnica analiza el cdigo y las especificaciones para derivar
la particin de entrada para un programa modificado. Luego, la tcnica elimina los tests obsoletos, y
genera nuevos tests para asegurar que cada clase de particin de entrada sea ejecutada por al menos un
test. Dada la informacin sobre el lugar en donde el cdigo ha sido modificado, la tcnica determina
arcos en el grafo de flujo de control para el nuevo programa desde el cual el cdigo modificado es
alcanzable. La tcnica realiza entonces una ejecucin simblica orientada a los datos, utilizando el rbol
de ejecucin simblica para ejecutar simblicamente todos los tests. Cuando se descubren tests que
alcanzan arcos desde los cuales no se alcanzan modificaciones, ellos no necesitan ser ejecutados ms
all. Los tests que alcanzan modificaciones son ejecutados simblicamente para la terminacin. La
tcnica selecciona todos los tests que alcanzan cdigo nuevo o modificado. Sin embargo, la tcnica
tambin ejecuta simblicamente estos tests seleccionados, obviando la necesidad de su ejecucin
posterior.
Inclusividad. La tcnica de ejecucin simblica selecciona todos los tests que ejecutan cdigo nuevo o
modificado en el programa modificado. La tcnica selecciona tambin tests que alcanzan bloques en el
programa original en el que se han eliminado sentencias. Sin embargo, si se han borrado bloques
enteros de cdigo, removiendo sentencias de control, la tcnica de ejecucin simblica no detecta tests
afectados por tales borrados, debido a que selecciona slo tests que alcanzan cdigo modificado o nuevo
actualmente presente en el programa modificado. Debido a que tales tests pueden ser reveladores de
modificaciones, la tcnica de ejecucin simblica no es segura.
Precisin. La tcnica de ejecucin simblica selecciona slo tests que alcanzan bloque nuevos o
cambiados de cdigo. En la mayora de los casos, este enfoque omite los tests no atravesadores de
modificaciones; sin embargo, la presencia de un nuevo bloque de cdigo no suministra necesariamente
tests mediante ese bloque atravesador de modificaciones.
Figura 8. Inclusividad y precisin para tcnica de ejecucin simblica
La figura 8 describe la inclusividad y la precisin de la tcnica de ejecucin simblica. El rea sombreada
indica la tcnica de seleccin de todos los tests que ejecutan cdigo modificado o nuevo. El rea
correspondiente a los tests que ejecutan slo sentencias borradas est parcialmente no sombreada,
indicado con esto la omisin de la tcnica de algunos de estos tests. Debido a que la tcnica admite
algunos tests no atravesadores de modificaciones, algunas reas por fuera de los crculos se encuentran
sombreados.
38
Eficiencia. Esta tcnica es computacionalmente cara y puede producir grandes cantidades inmanejables
de datos. Las expresiones simblicas construidas durante la ejecucin pueden ser ms complejas que el
programa del cual derivan.
De hecho, el rbol de ejecucin simblica construido por la tcnica puede tener un tamao (y requerir un
tiempo para construirlo) que es exponencial en relacin al tamao del programa modificado; esto puede
dar como resultado expresiones simblicas que son exponenciales en relacin al tamao del programa
modificado. Finalmente, es posible que para ciertas modificaciones el algoritmo no termine. Esto puede
ocurrir, por ejemplo, si el predicado del ciclo es modificado de tal manera que la modificacin ocasione
que el programa entre en un ciclo sin fin en una de sus entradas de prueba.
Generalidad. La tcnica de ejecucin simblica maneja modificaciones que afectan el flujo de control,
pero no manejan borrados de cdigo. La tcnica se aplica a procedimientos y programas modificados.
Aunque la tcnica se presenta como parte de un enfoque de testing que hace uso de testing de particin
de entrada, el algoritmo de seleccin de test no depende en s del uso de ningn criterio de testing
especfico.
No obstante, la tcnica tiene una generalidad limitada debido a su costo: los autores concluyen que,
debido al gasto computacional de la ejecucin simblica, su tcnica es factible slo para programas
numricos que no son extraordinariamente complejos. La tcnica no requiere rastreo del test.
39
4.6.3. Tcnica de Anlisis de Camino (Path Analisys)
Esta tcnica toma como entrada el conjunto de caminos del programa en P expresado en forma
algebraica, y maneja esa expresin para obtener un conjunto de caminos ejemplares libres de ciclo:
caminos acclicos desde la entrada del programa hasta la salida. La tcnica compara luego los caminos
ejemplares desde P a caminos ejemplares desde P, y los clasifica como nuevos, modificados,
cancelados o inmodificados. Luego, la tcnica analiza los tests para ver qu recorridos ejemplares
atraviesan en P. La tcnica selecciona todos los tests que atraviesan recorridos ejemplares modificados.
Inclusividad. La tcnica omite tests que atraviesan caminos cancelados y tests que atraviesan nuevos
caminos (caminos que contienen nuevos bloques de cdigo). En cada caso, los tests omitidos pueden
ser reveladores de modificaciones.
Precisin. La tcnica slo selecciona tests que ejecutan caminos ejemplares modificados; tales tests
son necesariamente atravesadores de modificaciones. Por lo tanto, la tcnica omite tests no
atravesadores de modificaciones. Sin embargo, la tcnica no omite ningn test no revelador de
modificaciones que ejecuta recorridos ejemplares modificados.
La figura 9 describe la inclusividad y precisin de la
tcnica de anlisis de recorrido. El rea sombreada
indica la seleccin que hace la tcnica de todos los tests
que atraviesan recorridos que contienen slo
modificaciones. Las reas correspondientes a otros
tests no estn sombreadas, indicando con esto la
omisin que hace la tcnica de tales tests.
Figura 9. Inclusividad y precisin tcnica anlisis de camino
Eficiencia. La tcnica no necesita calcular una correspondencia entre un programa y su versin
modificada; al menos, no en el mismo sentido en que otras tcnicas calculan una correspondencia. En
vez de esto, compara caminos ejemplares para localizar modificaciones. La tcnica tambin maneja
modificaciones mltiples en una sola aplicacin del algoritmo. Sin embargo, la tcnica de anlisis de
camino es computacionalmente cara. La tcnica calcula y almacena caminos ejemplares para P, P y
para cada test en T.
Generalidad. La tcnica supone el uso de un ambiente de programacin en el que se describen diseos
de programa de bajo nivel mediante representaciones algebraicas independientes del lenguaje. Tal
ambiente facilita la construccin de expresiones algebraicas que pueden ser manipuladas para producir
un conjunto de caminos ejemplares. La tcnica no maneja seleccin de tests mediante agregados o
eliminacin de cdigo. La tcnica no soporta testing de regresin interprocedimental ms all del
enfoque de analizar todos los procedimientos en un programa. La tcnica no requiere el uso de ningn
criterio particular de cubrimiento o tcnica de generacin de tests, pero requiere una herramienta para
recolectar huellas a nivel de declaracin.
40
4.6.4. Tcnicas Flujo de Datos (Dataflow)
Estas tcnicas identifican pares definicin-uso que son nuevos en, o modificados para P, y seleccionan
tests que ejecutan estos pares. Algunas tcnicas identifican tambin y seleccionan tests para pares
definicin-uso que han sido borrados de P.
Las tcnicas incrementales procesan un solo cambio, seleccionan tests para ese cambio, actualizan
incrementalmente la informacin del flujo de datos y de seguimiento del test, y luego repiten el proceso
para el cambio siguiente.
Las tcnicas no incrementales procesan un programa con mltiples cambios considerando todas las
modificaciones simultneamente.
Inclusividad. Estas tcnicas consideran los tests slo en asociacin con pares definicin-uso. Como
resultado, pueden omitir tests reveladores de modificaciones de varias formas. Por ejemplo, para borrado
de cdigo no seleccionan ningn test. De modo similar, si un test ejecuta una declaracin de salida
nueva o modificada que no contiene usos de variable, estas tcnicas podran no seleccionar este test,
incluso aunque la declaracin pudiera ser reveladora de modificaciones para las nuevas y antiguas
versiones del programa. Tanto las tcnicas incrementales como las no incrementales pueden omitir tests
de esta forma. Por lo tanto, las tcnicas de flujo de datos no son seguras.
Precisin. Al seleccionar slo tests que ejecutan pares definicin-uso nuevos, modificados o borrados,
las tcnicas de flujo de datos omiten normalmente los tests no atravesadores de modificaciones. Sin
embargo, la presencia de una definicin o un uso en un nuevo bloque de cdigo no transforma siempre a
los tests mediante ese atravesamiento de modificaciones del bloque. Por otra parte, al requerir tests
seleccionados para ejecutar pares definicin-uso
nuevos o modificados, las tcnicas de flujo de datos
omiten tests, tales como aquellos que alcanzan una
definicin modificada, pero no alcanzan al uso de la
variable definida, que son atravesadores de
modificaciones, pero no reveladores de
modificaciones.
La figura 10 ilustra la inclusividad y la precisin de las
tcnicas de flujo de datos. Debido a que las tcnicas
alcanzan un aumento en la precisin seleccionando
slo tests que ejecutan pares definicin-uso, la parte
del rea del diagrama que corresponde a tests
atravesadores de modificaciones que no son
reveladores de modificaciones no est sombreada.
Sin embargo, debido a que las tcnicas pierden
algunos tests reveladores de modificaciones, las
reas que estn dentro del rea del test revelador de
modificaciones tambin estn sin sombrear, y debido Figura 10. Inclusividad y precisin tcnicas de
que las tcnicas pueden seleccionar algunos tests no flujo de datos
atravesadores de modificaciones, alguna parte del rea por fuera de los crculos, est sombreada.
Eficiencia. Estas tcnicas requieren clculo inicial y almacenamiento de informacin de flujo de datos.
Las tcnicas incrementales de seleccin de tests de flujo de datos deben realizar anlisis incremental de
flujo de datos y actualizar la informacin del flujo de datos.
Generalidad. Requieren slo grafos de flujo de control e historiales de ejecucin del test, y as pueden
ser aplicadas generalmente a programas procedimentales. Las tcnicas funcionan para todo tipo de
cambios de programa, excepto para aquellos que no alteran las asociaciones definicin-uso. Suponen el
uso inicial de criterios de seleccin de test de flujo de datos, y requieren herramientas para el anlisis
esttico de flujo de datos y para recolectar huellas del test a nivel bsico del bloque. El enfoque
incremental requiere tambin herramientas incrementales de anlisis de flujo de datos.
41
4.6.5. Tcnicas de Grafo de Dependencias del Programa (Program Dependece Graph PDG)
Las tcnicas PDG utilizan cortes para agrupar los componentes del PDG (nodos o bordes del flujo) de P y
de P en clases de ejecucin, tales que un test que ejecuta cualquier componente en una clase de
ejecucin, ejecuta todos los componentes en esa clase. Luego, las tcnicas identifican componentes que
pueden mostrar conducta diferente en P que en P (componentes afectados), comparando cortes de
componentes correspondientes en P y P. Por ltimo, las tcnicas seleccionan todos los tests que
ejercitan componentes que estn en la misma clase de ejecucin que un componente afectado.
Inclusividad. Estas tcnicas identifican todos los tests que ejecutan cdigo nuevo o modificado. En
presencia de mltiples cambios, las tcnicas pueden fallar en reconocer que algn test t alcance un
componente particular c en P, debido a la presencia de alguna otra declaracin en el corte desde c. En
ese caso, sin embargo, ellos seleccionan t como necesario en relacin a algn otro componente. No
obstante, las tcnicas PDG pueden omitir tests que ejecutan sentencias que estn borradas de P.
Precisin. La tcnica de seleccin de tests mediante nodos afectados ocasiona que la cobertura todos
los nodos-PDG seleccione tests no atravesadores de modificaciones. Este problema no ocurre con la
cobertura de la todos los arcos del grafo-PDG.
La figura 11 describe la inclusividad y la precisin de las
tcnicas PDG. Debido a que ambas tcnicas admiten
tests no atravesadores de modificaciones, algunas
reas por fuera de los crculos estn sombreadas. Y
como ambas tcnicas pierden algunos tests a travs de
sentencias borradas, las reas de tests reveladores de
modificaciones permanecen no sombreadas.
Figura 11. Inclusividad y precisin tcnicas PDG
Eficiencia. Estas tcnicas calculan cortes del flujo de control para todo nodo o arco ujo en el PDG para
P y todo nodo o arco en el PDG para P. Luego calculan cortes hacia atrs en cada nodo o arco en P que
tiene un nodo correspondiente o arco en P, y cada nodo o arco en P que tiene un nodo o arco
correspondiente en P.
Generalidad. Las tcnicas PDG se presentan slo para un conjunto restringido de constructores de
lenguaje. Las tcnicas se enfocan a todo tipo de modificaciones de cdigo, excepto a las de borrado de
cdigo. Las tcnicas no soportan testing interprocedimental de regresin ms all del enfoque de
analizar todos los procedimientos de un programa. Las tcnicas suponen el uso de criterios adecuados a
tests basados en PDG, y requieren herramientas para construir PDGs (lo que a su vez requiere
herramientas para efectuar dependencias de control y anlisis de flujo de datos), herramientas para
efectuar cortes de programa, y herramientas para recolectar huellas de test a nivel de declaracin.
42
4.6.6. Tcnicas de Grafo de Dependencia del Sistema (System Dependence Graph)
Dado el programa P y la versin modificada P, las tcnicas SDG utilizan el llamado corte de contexto
(una tcnica de corte para calcular cortes interprocedimentales precisos) en SDGs para P y P, identificar
componentes (vrtices o arcos de flujo) en P y P que tienen modelos de ejecucin comunes. Las
tcnicas identifican componentes nuevas, mantenidas, borradas y afectadas en P, donde las
componentes afectadas son componentes en P que difieren de sus correspondientes componentes en P,
o para las que el llamado corte de contexto contiene componentes que no estn en P. Las tcnicas
seleccionan tests que ejecutan componentes en P que tienen modelos de ejecucin comunes respecto a
componentes nuevas o afectadas en P.
Inclusividad. Las tcnicas SDG, al igual que las tcnicas PDG, identifican todos los tests que ejecutan
cdigo nuevo o modificado. Sin embargo, igual que las tcnicas PDG, las tcnicas SDG pueden omitir
tests que ejecutan componentes borradas de P. Por lo tanto, las tcnicas SDG no son seguras.
Precisin. La cobertura de todos los arcos-SDG es ms precisa que la cobertura de todos los vrtices-
PDG, debido a que evita seleccionar tests que ejecutan slo componentes afectadas (tests que no son
atravesadores de modificaciones).
La figura 12 describe la inclusividad y la precisin de
las tcnicas SDG. Debido a que las tcnicas pueden
admitir tests no atravesadores de modificaciones, las
reas por fuera de los crculos estn sombreadas. Al
igual que las tcnicas PDG, sin embargo, ambas
tcnicas pierden algunos tests reveladores de
modificaciones a travs de sentencias borradas, de
modo que un rea correspondiente a tales tests no est
sombreada.
Figura 12. Inclusividad y precisin tcnicas SDG
Eficiencia. El clculo del corte de SDG y las comparaciones de corte se ejecutan respecto a las
sentencias en P, de modo que se incurre en los costos de estas operaciones en P despus que las
modificaciones estn completas, cuando el testing ha entrado en la fase crtica. Las tcnicas SDG
manejan modificaciones mltiples con una aplicacin individual de su algoritmo. Las tcnicas requieren
que se proporcione una correspondencia completa entre las sentencias en P y sus versiones modificadas
en P, provistas ya sea por un algoritmo de mapeo o por un editor incremental. Esta correspondencia
debe ser calculada despus que el testing ha entrado en la fase crtica.
Generalidad. Las tcnicas SDG se aplican generalmente a lenguajes procedimentales. Las tcnicas se
enfocan a todo tipo de modificaciones de programa, excepto a borrados de cdigo. Las tcnicas se
dedican especficamente al problema de la seleccin interprocedimental de tests, pero deberan funcionar
para la seleccin intraprocedimental de tests. Las tcnicas requieren herramientas para la construccin
de SDGs (lo que a su vez necesita herramientas para ejecutar dependencia de control y anlisis de flujo
de datos), y para recolectar huellas de tests a nivel de declaracin. Las tcnicas suponen el uso de
criterios de adecuacin de tests basados en PDG.
43
4.6.7. Tcnica Basada en la Modificacin (Modification Based)
Esta tcnica utiliza anlisis esttico de dependencia para determinar las componentes del programa que
son dependientes de los datos o del control en cdigo modificado, y puedan as ser afectadas por una
modificacin. Para cada uno de los diversos tipos de modificaciones de un programa, la tcnica
especifica un conjunto de componentes del programa que puede ser influenciado por esa modificacin.
La tcnica utiliza el programa modificado y requiere un testeador para ejecutar tests desde T sobre la
fuente utilizada. A medida que se ejecuta cada test, la tcnica realiza anlisis dinmico de dependencia
sobre las huellas de ejecucin del test, para determinar si el test ejecut el cdigo modificado y, si es as,
qu componentes influenciadas alcanz. El testing est completo para la modificacin cuando cada
componente influenciada ha sido alcanzada por algn test que ejecut la modificacin.
La tcnica basada en la modificacin difiere de las otras en que no automatiza el proceso de seleccionar
T a partir de T. En vez de eso, identifica requerimientos de cubrimiento; el proceso de seleccionar a T
que ayuda a satisfacer estos requerimientos de cubrimiento se deja al testeador.
Inclusividad. Es una tcnica de minimizacin. Como tal, omite tests reveladores de modificaciones
debido a que intenta seleccionar, para componentes de cdigo modificado, solo un test que alcance cada
componente afectada por esa modificacin. Puede omitir otros tests que ejecutan el mismo par de
componentes de cdigo modificadas y afectadas, y por lo tanto omiten tests que exponen fallas. No est
definida para todo tipo de modificaciones, afectando la inclusividad de la tcnica.
Precisin. No requiere testeadores para seleccionar tests no atravesadores de modificaciones debido a
que slo cuentan tests que ejecutan actualmente cdi go modificado. Ms an, al usar anlisis de
dependencia, la tcnica evita requerir algunos tests que, aunque atravesadores de modificaciones, no
son reveladores de modificaciones. Sin embargo, depende de una persona para localizar tests que
cubran los requerimientos de testing, en la prctica, el conjunto de tests T que esa persona selecciona
para tratar de coincidir con los criterios, incluir tests no atravesadores de modificaciones.
La figura 13 describe la inclusividad y la precisin de la tcnica
basada en la modificacin. La tcnica puede dejar sin ejecutar
tests en todas las categoras y, por lo tanto, hay reas en
todas las categoras que permanecen sin sombrear. Al usar la
tcnica, los tests no atravesadores de modificaciones pueden
ser ejecutados inadvertidamente; debido a esto, estn
sombreadas algunas reas por fuera de los crculos.
Eficiencia. Como tcnica de minimizacin, puede ser
satisfecha por la seleccin de pequeos conjuntos de tests;
esto puede reducir el tiempo de testing. Sin embargo, la
tcnica no automatiza actualmente el proceso de seleccin de
test; una persona debe seleccionar y ejecutar tests hasta que
se han encontrado los requerimientos de testing para una
modificacin. La tcnica supone el conocimiento de todas las
Figura 13. Inclusividad y precisin modificaciones del cdigo. Despus que la tcnica analiza
tcnica basada en la modificacin una modificacin part icular o una modificacin lgica, y se han
encontrado tests que cubren esa modificacin, se deben volver a hacer o a actualizar incrementalmente
su anlisis esttico (datos estticos y anlisis de dependencia de control) antes de que pueda considerar
la modificacin siguiente. Despus de ejecutar cada test, la tcnica requiere anlisis dinmico de la
huella para ese test.
Generalidad. La tcnica basada en la modificacin se aplica en general a los lenguajes
procedimentales. Esta definida para muchos tipos de modificaciones de un programa, pero no para
todos. Puede aplicarse inter o intraprocedimentalmente. No depende de ningn criterio de testing en
particular, pero requiere una herramienta para recolectar huellas de test a nivel de declaracin, y
herramientas para efectuar control esttico y dinmico y anlisis de dependencia de datos.
44
4.6.8. Tcnica Cortafuego (Firewall)
Esta tcnica esta dirigida especficamente al testing de regresin interprocedimental que maneja los
cambios, tanto del cdigo como de las especificaciones. La tcnica determina dnde colocar un
cortafuego alrededor de los mdulos de cdigo modificados. Donde corresponde la seleccin del test
desde T, la tcnica selecciona tests unitarios para mdulos modificados que permanecen dentro del
cortafuego, y tests de integracin para grupos de mdulos interactivos que se encuentran dentro del
cortafuego.
Inclusividad. Cuando los tests unitarios y de integracin utilizados inicialmente para probar
componentes del sistema son confiables, de tal modo que la correccin de los mdulos ejecutados por
aquellos tests para las entradas testeadas implique correccin de aquellos mdulos para todas las
entradas, la tcnica cortafuegos selecciona todos los tests reveladores de modificaciones, y es segura.
Sin embargo, en la prctica, los conjuntos de tests no son confiables de modo caracterstico. Cuando los
conjuntos de tests no son confiables, la tcnica cortafuegos puede omitir tests reveladores de
modificaciones. En la prctica, la tcnica cortafuegos no es segura
Precisin. La tcnica selecciona todos los tests unitarios y de integracin de mdulos que permanecen
dentro del cortafuegos. Debido a que no todos estos tests ejecutan necesariamente cdigo modificado,
no se seleccionan tests atravesadores de modificaciones.
La figura 14 describe la inclusividad y la precisin de
la tcnica cortafuegos. Debido a que la tcnica
omite tests reveladores de modificaciones en todas
las categoras, el diagrama contiene reas no
sombreadas en todas las categoras. Debido a que
la tcnica admite algunos tests no atravesadores de
modi ficaciones, algunas reas por fuera de los
crculos estn sombreadas.
Eficiencia. El tiempo de construccin de un
cortafuegos es proporcional al tamao del grafo de
llamadas del programa, y el tiempo de seleccin de
test para el cortafuegos es proporcional al producto
del tamao del conjunto de tests y del tamao del
grafo de llamadas. Maneja modificaciones mltiples
en una aplicacin individual. La tcnica tambin
requiere clculo del conjunto de procedimientos
modificados durante la fase crtica del testing
Figura 14. Inclusividad y precisin tcnica Firewall
La tcnica cortafuegos ha sido implementada y se ha informado de mediciones iniciales de sus costos.
La Implementacin requiere una base de datos que puede ser costosa de implementar; sin embargo, esta
implementacin puede realizarse durante la fase inicial del testing de regresin. Los resultados empricos
preliminares sugieren que una vez que est completa la implementacin, las fases de anlisis y de
seleccin de tests de la tcnica, son eficientes para grandes cantidades de datos.
Generalidad. La tcnica cortafuegos es aplicable a programas en lenguajes procedimentales, en
general. La tcnica maneja todo tipo de modificaciones de cdigo, especficamente la seleccin
interprocedimental de tests, aunque no lo hace con la seleccin intraprocedimental de tests. La tcnica
no requiere el empleo de ninguna tcnica de testing subyacente ni de ningn criterio particular de
cubrimiento. Requiere herramientas para recolectar huellas de tests a nivel de funcin.
45
4.6.9. Tcnica de Identificacin del Cluster (Cluster Identification)
Esta tcnica identifica subgrafos de entradas simples y salidas simples de un grafo de flujo de control,
llamados clusters, que han sido modificados entre una versin de un programa y la siguiente. Calcula
informacin de dependencia de control para un procedimiento y su versin modificada, y luego calcula la
visin de control de cada declaracin de decisin en el procedimiento, tomando el cierre transitivo de la
relacin de dependencia de control. La tcnica utiliza esta informacin para identificar clusters y
establecer una correspondencia entre los CFGs de P y de P. Al establecer esta correspondencia, la
tcnica selecciona tests que ejecutan clusters nuevos, borrados y modificados.
Inclusividad. Es una tcnica segura. Maneja cambios estructurales y no estructurales, y cdigo nuevo y
borrado, identificando clusters en los que se han aadido, modificado o borrado estructuras o cdigo, y
seleccionando todos los tests que ejecutan los correspondientes clusters en P. Este procedimiento
identifica un superconjunto de los tests atravesadores de modificaciones.
Precisin. La tcnica puede identificar
clusters de forma que permite seleccin
de tests no atravesadores de
modificaciones. Por ejemplo, dado el
procedimiento avg y el conjunto de tests
para avg, la tcnica identifica un cluster
consistente en las sentencias S3 hasta
S10, pero no identifica clusters ms
pequeos dentro de ese cluster. Si se
aade la declaracin S5.
print(Improper input.), justo antes de
la declaracin S5, se seleccionan los
tests t1, t2 y t3, debido a que estos tres
ejecutan el cluster modificado que
encierra la nueva lnea.
Sin embargo, slo el test t2 ejecuta
actualmente la nueva declaracin; los tests t1 y t3 no son atravesadores de modificaciones.
La tcnica revisa dentro de los procedimientos modificados, y puede omitir tests no atravesadores de
modificaciones que cruzan esos procedimientos al reconocer que esos tests no ejecutan cluster
modificados. Por este motivo, son ms precisas que las tcnicas interprocedimentales de ecuacin lineal,
que seleccionan todos los tests mediante procedimientos modificados.
La figura 15 describe la inclusividad y la precisin de
la tcnica de identificacin de cluster. Debido a que la
tcnica es segura, los crculos del diagrama estn
sombreados por completo. Como la tcnica puede
admitir tests no atravesadores de modificaciones,
algunas reas por fuera de los crculos estn
sombreadas. Sin embargo, ya que la tcnica es ms
precisa que las tcnicas interprocedimentales de
ecuacin lineal, esa rea sombreada es ms pequea
en este diagrama que en el diagrama B de la Figura 9.
Figura 15. Inclusividad y precisin tcnica
identificacin de cluster
46
Eficiencia. El tiempo de ejecucin de la tcnica de identificacin de cluster est limitado por el tiempo
requerido para calcular la extensin del control de las sentencias de decisin, que es O(n
3
) para
procedimientos de n sentencias. La tcnica maneja modificaciones mltiples en una aplicacin individual
del algoritmo. Sin embargo, la tcnica calcula una correspondencia para el procedimiento completo y la
versin modificada, y realiza este clculo despus de que las modificaciones estn completas, cuando el
testing est en la fase crtica.
Generalidad. Debido a que la tcnica de identificacin de cluster trabaja en CFGs, se aplica a
programas procedimentales, en general. Sin embargo, la tcnica maneja todo tipo de modificaciones de
programa. La tcnica no soporta testing interprocedimental de regresin ms all de analizar todos los
procedimientos de un programa. La tcnica no hace supuestos sobre el desarrollo, el ambiente o el
diseo inicial de conjuntos de tests. La tcnica requiere herramientas para calcular dependencia de
control y para recolectar informacin sobre huellas de tests a nivel de declaracin.
47
4.6.10. Tcnicas de Corte (Slicing)
Para esta tcnica se definen 4 tipos diferentes de cortes: corte de ejecucin, corte dinmico, corte
relevante y corte aproximadamente relevante.
Un corte de ejecucin para t contiene las sentencias en P que fueron ejecutadas por t.
Un corte dinmico para t contiene todas las sentencias en el corte de ejecucin para t que tienen
influencia en una declaracin de salida en el corte de ejecucin.
Un corte relevante para t es como el corte dinmico para t, excepto que contiene tambin sentencias
de predicado en t que, si se modifican, pueden ocasionar que P produzca una salida diferente, y
tambin las sentencias en t sobre las que estos predicados son dependientes de datos.
Por ltimo, un corte aproximadamente relevante para t es como el corte dinmico para t, excepto que
contiene tambin todas las sentencias de predicado en el corte de ejecucin para t.
Dado el corte sl para el test t, construido por una de las cuatro tcnicas de corte, si sl contiene una
declaracin modificada, la tcnica selecciona t.
Inclusividad. La tcnica del corte dinmico puede omitir tests reveladores de modificaciones cuando P
contiene sentencias modificadas de predicado, de modo que la tcnica no es segura.
Cuando las modificaciones del cdigo no alteran los arcos del grafo de flujo de control o los conjuntos de
definiciones para P, las otras tcnicas de corte son seguras. Sin embargo, los agregados de sentencias
de predicado o de asignacin a P impactan adversamente sobre la inclusividad de las tcnicas de corte.
Por ejemplo, supngase que se agrega una nueva declaracin de asi gnacin s a P.
Debido a que los cortes construidos con las tcnicas de corte contienen slo sentencias que aparecen en
P antes de sus modificaciones, ningn corte contiene a s. Ningn test que ejecute el bloque de cdigo en
P en el que s est inserta, sin embargo, puede ser revelador de modificaciones. Ya que las tcnicas de
corte no seleccionan tests semejantes, no son seguras. La inclusividad se ve afectada en forma adversa
cuando los programas contienen modificaciones mltiples. En este caso, las tcnicas de corte trabajan
incrementalmente, considerando los cambios de a uno.
Precisin. En los casos en que las modificaciones no son estructurales y no implican adiciones de
nuevo cdigo, las tcnicas de corte seleccionan slo tests atravesadores de modificaciones. Al restringir
los tests seleccionados a aquellos que influyen en la salida, los cortes potencialmente relevantes, los
relevantes y los dinmicos excluyen, en diferente grado, los tests que son atravesadores de
modificaciones, pero no reveladores de modificaciones.
Cuando los programas contienen cambios estructurales, sin embargo, las extensiones hechas para
aumentar la inclusividad de las tcnicas puede ocasionar que se seleccionen tests no atravesadores de
modificaciones.
En la figura 16 se describen la inclusividad y la precisin de las tcnicas de corte. Los diagramas ilustran
la carencia de seguridad de todas las tcnicas, dejando sin sombrear porciones de las reas
correspondientes a tests reveladores de modificaciones.
Adems, para todas las tcnicas, los diagramas sombrean al gunas reas correspondientes a tests
atravesadores de modificaciones que no son reveladores de modi ficaciones, dando a entender la
inclusin de tales tests.
48
Figura 16. Inclusividad y precisin para tcnicas de corte
Eficiencia. Cuando las modificaciones del programa no agregan sentencias de asignacin ni afectan el
flujo de control, las tcnicas de corte pueden efectuar la mayor parte del trabajo en la fase prelimi nar del
testing de regresin. En presencia de modificaciones arbitrarias las tcnicas de corte son menos
eficiente. Por otra parte, dadas mltiples modificaciones, para evitar la prdida de precisin y seguridad,
el anlisis del cdigo puede necesitar ser repetido o actualizado incrementalmente, recolectarse de nuevo
huellas del tests, despus de considerar cada modificacin. Sin semejante reclculo, la tcnicas no
pueden explicar los efectos acumulativos de las modificaciones sobre los recorridos y cortes del test. Al
menos, el reclculo de las huellas puede necesitar ejecutar todos los tests en T, destruyendo el propsito
del retest selectivo.
Generalidad. Las tcnicas funcionan para lenguajes procedimentales debido a que slo dependen de la
habilidad para seguir la pista de la ejecucin del programa y calcular la informacin de dependencia. Sin
embargo, la efectividad y eficiencia decrecen en los casos en que los programas contienen
modificaciones mltiples o modificacin en la estructura de control. Las tcnicas no soportan el testing
interprocedimental de regresin, ms all de analizar todos los procedimientos de un programa. Las
tcnicas no requieren el diseo particular de un conjunto de tests o el uso de requerimientos de
cubrimiento. Requieren la recoleccin de informacin de las huellas del test a nivel de declaracin o de
procedimiento; algunas de las tcnicas tambin requieren herramientas para el anlisis de dependencia
esttica y dinmica.
49
4.6.11. Tcnicas de Recorrido del Grafo (Graph Walk)
Esta es una tcnica introprocedimental de seleccin de test de regresin que construye grafos de flujo de
control (CFGs) para P y P, que recolecta huellas para tests en T que asocian los tests con los arcos
CFG, y realiza cruzamientos sincrnicos de primer nivel, comparando los nodos (o en estos momentos,
las sentencias del programa asociados con esos nodos) que son alcanzados a lo largo de prefijos de
huellas de ejecucin. Cuando se descubren un par de nodos N y N en los grafos para P y P,
respectivamente, de tal modo que las sentencias asociadas con N y N no son lxicamente iguales, la
tcnica selecciona todos los tests desde T que, en P, alcanzan a N. Este enfoque identifica los tests que
alcanzan cdigo que es nuevo en o modificado para P, y revisa ese cdigo alcanzado inicialmente que
ha sido borrado de P. La tcnica selecciona todos los tests en T que son atravesadores de
modificaciones para P y P.
Inclusividad. Las tcnicas de recorrido del grafo seleccionan todos los tests atravesadores de
modificaciones. Por este motivo, para el testing controlado de regresin, son seguras.
Precisin. Las tcnicas de recorrido del grafo no son 100% precisas para programas arbitrarios.
Rothermel define una propiedad de los CFGs llamada la propiedad del nodo visitado en forma mltiple.
Rothermel prueba que cuando P y P no exhiben la propiedad del nodo visitado en forma mltiple, las
tcnicas de recorrido del grafo seleccionan exactamente los tests en T que son atravesadores de
modificaciones para P y P.
Sin embargo, cuando G y G exhiben la propiedad del nodo visitado en forma mltiple, las tcnicas de
recorrido del grafo pueden seleccionar tests que no son atravesadores de modificaciones para P y P.
Las tcnicas que emplean informacin sobre dependencia de datos aumentan ms la precisin de la
seleccin de tests, omitiendo algunos tests atravesadores de modificaciones que no son reveladores de
modificaciones.
Figura 17. Inclusividad y precisin tcnicas de recorrido del grafo
Los Diagramas A y B muestran la seguridad y la precisin de las tcnicas de recorrido del grafo para
casos en los que la propiedad del nodo visitado en forma mltiple existe y no existe, respectivamente.
El Diagrama C muestra la seguridad y la precisin de las versiones mejoradas de las tcnicas de
recorrido del grafo que utilizan informacin sobre dependencia de datos.
50
La seguridad de las tcnicas se describe mediante la presencia de sombreado en todas las reas
correspondientes a tests reveladores de modificaciones.
La imprecisin de las tcnicas se ilustra mediante el sombreado de reas no correspondientes a tests
reveladores de modificaciones. El hecho de que las tcnicas pueden seleccionar tests no atravesadores
de modificaciones cuando se da la propiedad del nodo visitado en forma mltiple se ilustra sombreando la
zona externa de los crculos en los Diagramas A y C; este sombreado se omite en el Diagrama B, que
describe la precisin supuesta de las tcnicas en la prctica.
Sin embargo, el rea sombreada del rea de los tests no atravesadores de modificaciones es ms
pequea que el rea correspondiente en el Diagrama B de la Figura 9, reflejando la mayor precisin de
las tcnicas de recorrido del grafo. El diagrama de la derecha ilustra las ganancias en precisin
obtenidas por las versiones mejoradas de las tcnicas; estas tcnicas omiten algunos tests que son
atravesadores de modificaciones, pero no reveladores de modificaciones.
Generalidad. Las tcnicas de recorrido del grafo se aplican generalmente a lenguajes procedimentales
debido a que los grafos de flujo de control e informacin de flujo de control pueden ser calculados para
todos los lenguajes semejantes. Manejan todo tipo de modificaciones de programa y soportan seleccin
intraprocedimental e interprocedimental de tests.
No hacen supuestos en relacin al diseo inicial del conjunto de tests o al uso de criterios de cubrimiento.
Requieren informacin sobre huellas del test a nivel del bloque bsico, y herramientas para construir
grafos de flujo de control; las versiones avanzadas de las tcnicas requieren tambin herramientas para
anlisis de flujo de datos.
51
4.6.12. Tcnica de Entidad Modificada (Modified Entity)
Esta tcnica detecta entidades de cdigo modificadas. Las entidades de cdigo se definen como
porciones ejecutables de cdigo (funciones), o como componentes no ejecutables (localizaciones de
almacenamiento). La tcnica selecciona todos los tests asociados con entidades modificadas. La
tcnica ha sido implementada como una herramienta de software, llamada TestTube, que realiza
seleccin de test de regresin para programas en C. Las entidades se almacenan en una base de datos
que, entre otras cosas, facilita la comparacin de esas entidades para determinar dnde han ocurrido las
modificaciones.
Inclusividad. Al identificar todos los tests a travs de las entidades de cdigo modificado, la tcnica
identifica todos los tests atravesadores de modificaciones. De esta forma, es segura para el testing de
regresin.
Precisin. Dada una funcin modificada F en el programa P, la tcnica selecciona todos los tests que
ejecutan F. Debido a que algunos tests pueden ejecutar F sin ejecutar ningn cdigo modificado en F, se
seleccionan tests no atravesadores de modi ficaciones. Adems, debido a que la tcnica de la entidad
modificada puede seleccionar tambin tests que no ejecutan clusters modificados o huellas de ejecucin
modificadas, la tcnica es menos precisa que las tcnicas de identificacin de cluster o de recorrido del
CFG. El conjunto de tests no atravesadores de modificaciones seleccionado por el mtodo es
equivalente al conjunto de tests no atravesadores de modificaciones seleccionado por la tcnica
interprocedimental de la ecuacin lineal.
La figura 18 describe la inclusividad y la precisin de la
tcnica de la entidad modificada. Ya que la tcnica es
segura, los tres crculos estn completamente
sombreados. Como la tcnica selecciona tests no
atravesadores de modificaciones, las reas por fuera de
los crculos tambin estn sombreadas. Esa rea
sombreada es comparable en tamao del rea
sombreada empleada con las tnicas
interprocedimentales de ecuacin lineal en el Diagrama
B.
Figura 18. Inclusividad y precisin tcnica de la entidad
modificada.
Eficiencia. Es la tcnica segura ms eficiente. La tcnica es completamente automatizable y se ejecuta
en un tiempo en donde el peor caso es proporcional al tamao del conjunto de test, multiplicado por el
nmero de entidades cambiadas en P, el cual es al menos equivalente al tamao de P (aunque en la
prctica se espera que sea mucho menor).
Generalidad. Aunque implementada para C, la tcnica se puede aplicar en general a lenguajes
procedimentales. Maneja todos los tipos de modificaciones de cdigo. La tcnica est especficamente
diseada para manejar testing de regresin interprocedimental ms que intraprocedimental. Requiere el
uso de una base de datos que contiene informacin sobre el cdigo, pero esta base de datos sirve para
otros propsitos tiles. La tcnica no hace suposiciones respecto al diseo inicial del conjunto de tests o
al uso de criterios de cubrimiento. Finalmente, la tcnica es prometedora en su aplicacin a programas
no determinsticos.
52
4.7. Algunas Herramientas
4.7.1. Mercury Interactive y Segue Software:
Estas herramientas proveen funcionamiento automatizado (generacin de usuarios) y testeo de
performance para ambientes Java, CORBA, WWW, WAP, client/server, UNIX y Windows.
Evaluacin de copias (Por diferenciacin de clientes/usuarios)
Metodologas y procesos de testing (Por tipo de software, probable mas indicado) Identificacin de
ambientes de testeo (aquellos componentes hardware y software identificados en la definicin del plan
global situndolos en condiciones de soportar el testing de las aplicaciones)
4.7.2. Capbax/x, Capbax/Unix de TestWorks Software
Posee capture/replay con modos completos de la sincronizacin del aparato de lectura. Operacin
cambiable de TrueTime, de ObjectMode, y de CharacterMode(OCR).
Ventajas: Tiempo reducido de la creacin de la prueba, notificacin temprana de los cambios del GUI,
programacin flexible.
Caractersticas Dominantes: TrueTime, ObjectMode y operacin de CharacterMode(OCR), sincronizacin
automtica incorporada de la salida, expedientes en subconjunto de C y extraccin automtica del objeto.
Usos: prueba del GUI de todas las clases: Local, Cliente/Server, TELA, prueba el motor del aparato de
lectura de la habitacin, capacidad realista de la generacin de la carga construida adentro.
4.7.3. Herramientas Capture-Playback
Empleo en programas que trabajan con interfaz (GUI) grfica. Para apoyar pruebas de uso, proporcionan
la capacidad de operaciones de usuario en captura (golpes de teclado, actividad del ratn, aceleradores)
despus de que el cdigo se ha modificado.
En muchos casos de prueba la operacin del GUI no puede ser duplicada porque es muy difcil que el
testeador recuerde todos los pasos anteriores. Las herramientas de Capture/playback se desarrollan
para solucionar estos problemas.
Categoras de las herramientas de capture/playback
Primer Tipo: Permiten que los usuarios utilicen un lenguaje simular (cdigo) del GUI. Esta clase de
herramientas de capture/playback son tiles para software de uso en diferentes plataformas.
Segundo Tipo: Poseen la capacidad de ejecutar automticamente las operaciones manuales de los
usuarios, sin codificar. Esta clase de herramientas es ms fcil de utilizar por testeadores con menor
experiencia en multi-plataformas.
53
5. Conclusiones
La etapa de mantencin en todo proceso de desarrollo de software es una fase que ocupa la mayor
parte del proceso y es la etapa en donde el software puede sufrir muchos cambios debido a nuevos
requerimientos, cambios de plataformas y dispositivos empleados, por defectos encontrados, etc.
Por lo tanto, es crucial poseer un mecanismo de prueba para validar que todos los cambios
introducidos al software no hayan perjudicado las funcionalidades existentes, de all que el testing
de regresin sea una actividad tan importante en la etapa de la mantencin.
El testing de regresin posee una base que lo diferencia de los dems tipos de testing, ste tiene
como fundamento la existencia de un conjunto original de casos de prueba correspondientes al
software no modificado. Los otros tipos de testing deben generar sus propios casos de pruebas, en
cambio, el de regresin ya cuenta con esa informacin y su misin principal es seleccionar casos
de pruebas, a partir del conjunto original de test, que muestren que el software original y el
modificado generan salidas diferentes y de esa manera encontrar los llamados errores de
regresin.
El testing de regresin es una tarea cara pero necesaria. La mayora de las veces no se realiza por
problemas de falta de recursos y tiempo.
El testing de regresin permite mantener la calidad de las aplicaciones.
La gran cantidad de tcnicas disponibles en la actualidad deben ser evaluadas por los testeadores
para que stos decidan el tipo de retest que sean obtener. Dichas decisiones se basan tpicamente
en la obtencin de un subconjunto de restest mnimo, de una alta cobertura y que proporcione la
seguridad suficiente para indicar que las modificaciones introducidas no han incorporado nuevos
defectos y que las funcionalidades existentes se mantienen. Sin embargo, no existe una tcnica
optima que permita obtener dicho conjunto de retest, es por ello que los testeadores deben priorizar
entre seguridad y cantidad de casos que desean retestear.
La tcnica ms segura para encontrar defectos de regresin es el mtodo de retestear todo, es
decir, testear la aplicacin modificada con el conjunto original de casos de prueba. Esta es una
tcnica segura y muy cara, adems es ineficiente debido a que en una modificacin no todo el
cdigo cambia, slo una parte de l y por lo tanto slo habra que probar dicho sector.
La experiencia emprica indica que las tcnicas desarrolladas se comportan de una manera
bastante adecuada al objetivo del testing de regresin, dando as esperanzas que en el futuro se
puedan conseguir subconjuntos ptimos de retest, lo cual provocar que la etapa de mantencin
sea ms corta de lo que es actualmente.
En la actualidad se estn desarrollando tcnicas que permitan integrar varios tipos de pruebas (caja
negra y blanca) para de esta manera tener un enfoque general que produzca procesos ms
eficientes al permitirle al testeador trabajar con menos herramientas que podran requerir diversas
habilidades, conceptos subyacentes y separar as el entrenamiento. Por lo tanto, la integracin
permite mejorar substancialmente el proceso de prueba con respecto a costos y a tiempo.
Las mtricas ms empleadas para medir la efectividad de las tcnicas del testing de regresin son
la inclusividad, precisin, eficiencia y generalidad. Estas mtricas permiten comparar de un modo
satisfactorio las diferencias entre las tcnicas proporcionando de esta manera un camino evaluarlas
y as permitirle al testeador tomar la mejor decisin al momento de elegir una tcnica para un
determinado algoritmo.
54
6. Referencias
Empirical Studies of a Safe Regression Test Selection Technique, Greg Rothermel, Mary Jean Harrol.
Analysing Regression Test Selection Techniques, Greg Rothermel, Mary Jean Harrold.
Managing Object-Oriented Integration and Regression Testing, Mario Winter.
Methods and Metrics for Selective Regression Testing, Rami Bahsoon.
Integrating White and Black Box Techniques for Class-Level Regression Testing, Sami Beydeda.
Reducing the Cost of Regression Testing by Semantics Guided Test Case Selection, David Binkey.
A Comparative Study of Five Regression Testing Algorithms, Ghinwa Baradhi, Nashat Mansor.
Natural Optimization Algorithms for Optimal Regression Testing, Nashat Mansor, Khaled El-Fakih.
A Study of Effective Regression Testing in Practice, W. Eric Wong, J.R. Horgan, Saul London, Hira
Agrawal.
Compacting Regression-Suites On-The-Fly, Erez Buchnik, Dr. Shmuel Ur.
Regression Testability, Carl Warren.
Modular Regression Testing : Connections to Component-Based Software, Bruce W. Weide.