UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS

FACULTAD DE INGENIERA
DIVISIN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS
CARRERA DE INGENIERA DE SISTEMAS

AUTOMATIZACIN DE PRUEBAS DE REGRESIN PARA INTERFACES

GRFICAS DE USUARIO USANDO PLANIFICACIN DE INTELIGENCIA
ARTIFICIAL

TRABAJO FINAL

INTEGRANTE:
ZEGARRA PREZ, CARLOS

PROFESOR:
BRUNO VARGAS TAMANI

Lima, Octubre de 2013

NDICE
1

INTRODUCCIN.......................................................................................................................................3

OBJETIVOS................................................................................................................................................3

JUSTIFICACIN........................................................................................................................................4

IDENTIFICACIN DEL PROBLEMA......................................................................................................5

PROCEDIMIENTOS O METODOLOGIA A DESARROLLAR.............................................................7

DESCRIPCIN GENERAL.......................................................................................................................8

GENERACIN DEL PLAN.....................................................................................................................17

REPRESENTACIN DE LOS CASOS DE PRUEBA DE GUI..........................................................18

REPRESENTACIN DE LOS EVENTOS DE GUI COMO OPERADORES..................................19

10

DISEO DETALLADO DEL PROBADOR DE REGRESIN............................................................20

11

GLOSARIO DE TRMINOS...................................................................................................................20

12

SIGLARIO..................................................................................................................................................21

13

BIBLIOGRAFA.........................................................................................................................................21

Pgina 2

INTRODUCCIN

El uso de un software con interfaz grfica de usuario (GUI) puede aumentar

significativamente el costo de pruebas de regresin, tanto porque la GUI del
software ha sido modificada y se ha vuelto a probar con frecuencia como por las
caractersticas especiales de dichas interfaces, tales como las entradas manejadas
por eventos y los resultados grficos, que impiden la aplicacin de las pruebas de
regresin automatizadas.
En el presente trabajo se demuestra que un conjunto de pruebas originalmente
utilizado para probar una GUI tiene dos divisiones para la interfaz modificada: los
casos de prueba afectados que ahora no pueden ejecutarse sobre ella y los casos
de prueba no afectados que no necesitan ser ejecutados nuevamente.
Se presenta una nueva tcnica para las pruebas de regresin automatizadas de GUI
utilizando la planificacin de la Inteligencia Artificial. En primer lugar, se representan
los casos de prueba de GUI con un alto nivel de abstraccin utilizando tareas (pares
de estados iniciales y finales). Luego, se aplica la planificacin para regenerar los
casos de prueba afectados a partir de estas tareas de modo que puedan ser usados
para volver a probar. Asimismo, la representacin tradicional de los casos de prueba
de GUI como secuencias de eventos y estados esperados ya contiene el
mecanismo necesario para asociar una tarea con cada caso de prueba. Finalmente,
la tcnica de planificacin tambin se combina naturalmente con el generador de
casos de prueba que emplea la planificacin jerrquica para crearlos.
2

OBJETIVOS
Investigar la aplicacin de las tcnicas y conceptos de la Inteligencia Artificial en
un problema concreto del mbito de mi desempeo profesional: el desarrollo de
software y las pruebas de regresin.

Conocer y comprender las capacidades de esta rama de la computacin con

fines prcticos y en situaciones reales de aplicacin.

Pgina 3

JUSTIFICACIN

El mantenimiento en el proceso de desarrollo del software es una parte cada vez

ms importante pero al mismo tiempo costosa. Sus actividades conforman hasta
dos tercios del costo total de produccin de software [34, 29, 37]. Las pruebas de
regresin, una actividad de mantenimiento necesaria, se lleva a cabo en el software
modificado para proporcionar la seguridad de que (1) el software se comporta
correctamente, y (2) las modificaciones no han afectado negativamente a la calidad
del software. Las pruebas de regresin pueden explicar tanto como la mitad de los
gastos de mantenimiento de software [3].
El

uso

de

software

con

interfaz

grfica

de

usuario

puede

aumentar

significativamente el costo de pruebas de regresin, ya que constituye tanto como la

mitad del cdigo del software [19, 26].

Las GUIs requieren, frecuentemente, la

repeticin de pruebas debido a que ellas estn diseadas tpicamente usando

prototipado rpido [26], y se modifican y prueban continuamente. Asimismo,
caractersticas especiales de dichas interfaces, tales como las entradas manejadas
por eventos y los resultados grficos, presentan un nuevo conjunto de desafos para
el problema de las pruebas de regresin, lo que requiere el desarrollo de nuevas
soluciones.

Pgina 4

IDENTIFICACIN DEL PROBLEMA

Expertos en el problema
Atif M. Memon
Departamento de Ciencias de la Computacin y Centro de Ingeniera de Software
Experimental - Fraunhofer, Universidad de Maryland, EE.UU.
E-mail: atif@cs.umd.edu
Caractersticas importantes del problema: tipo y alcance
Aunque las pruebas de regresin de software convencional han recibido mucha
atencin [6, 32, 34, 35], casi no ha habido investigacin reportada sobre las pruebas
de regresin a GUI. La excepcin es White [40] que propone un mtodo Latin
square para reducir el tamao del conjunto de pruebas de regresin.
Varias estrategias para las pruebas de regresin de software convencional se han
propuesto [2, 9, 30, 17]. Una estrategia de pruebas de regresin propone volver a
ejecutar todos los casos de prueba que no han quedado obsoletos. Dado que esta
estrategia de probar todo es intensiva en recursos, se han hecho numerosos
esfuerzos para reducir su costo.

Tcnicas selectivas de reprueba [1, 4, 11]

intentaron reducir el costo de las pruebas de regresin probando slo partes

seleccionadas del software. Estas tcnicas se han centrado tradicionalmente en
dos problemas: (1) el problema de seleccin de pruebas de regresin, es decir, la
seleccin de un subconjunto de los casos de prueba existentes [34], e (2)
identificacin de problemas de cobertura, es decir, la identificacin de partes del
software que requieren pruebas adicionales.

Las soluciones al problema de la

seleccin de pruebas de regresin compara tradicionalmente las representaciones

estructurales (por ejemplo, grficos de control de flujo [34], los grficos de control de
la dependencia [33]) del software original y el modificado. Los casos de prueba que
provocan la ejecucin de diferentes caminos en estas estructuras son susceptibles
de ser seleccionados para una nueva prueba. Entre las estrategias de reprueba
selectivas, los enfoques seguros requieren la seleccin de cada caso de prueba
existente que involucra cualquier elemento del programa que podra verse afectado
por un cambio dado. Aunque computacionalmente menos costoso que la estrategia
Pgina 5

de volver a probar todo, los enfoques seguros siguen haciendo grandes demandas
de recursos. En el otro extremo del espectro de estrategias de reprueba selectivas,
estn enfoques que tratan de seleccionar el conjunto ms pequeo de casos de
prueba necesarios para probar los elementos del programa afectados al menos una
vez [36]. Estas tcnicas intentan asegurar que al menos un criterio de cobertura
estructural se cumpla en los casos de prueba que se han seleccionado. Las
estrategias prcticas caen entre las estrategias seguras y las de minimizacin. El
diseador de pruebas podra estar satisfecho con el uso de conjuntos casi mnimos
de casos de prueba [31].
Las tcnicas de reprueba selectivas para el software tradicional tratan de reducir el
costo de las pruebas de regresin mediante la identificacin de las partes del
software modificado que deben ser probadas nuevamente. El conjunto de pruebas
original se divide en (1) los casos de prueba que no hay que volver a ejecutar en el
software modificado, porque la modificacin no fue transversal, (2) los casos de
prueba que tienen que volver a ejecutarse porque la modificacin fue transversal, y
(3) los casos de prueba obsoletos que ya no son necesarios para probar el software
[34, 33]. Nuevos casos de prueba tambin pueden ser generados para probar las
partes del software modificado no probado en (2). La divisin descrita de los casos
de prueba originales no se puede aplicar a interfaces grficas de usuario debido a
que la estructura de un caso de prueba de GUI, mostrada a continuacin, slo
permite los casos (1) y (3) de arriba, es decir, ningn caso de prueba del conjunto de
pruebas original podra o debera volver a ejecutarse.
Un caso de prueba de GUI consta de 3 partes: (a) un estado inicial de la GUI S 0 en
el que se ejecuta el caso de prueba, (b) una secuencia de eventos e 1; e2; ...; en que
son las entradas de la prueba para la GUI, y (c) una secuencia de estados S 1, S2, ...,
Sn, donde Si; es el estado esperado de la GUI despus de que el evento e i; es
ejecutado [21].

El estado inicial se utiliza para inicializar la GUI a un estado

deseado antes de que los eventos se ejecuten en ella y la secuencia de estados

esperados se utiliza por los orculos de prueba [23] para determinar si la GUI se
ejecut correctamente durante la prueba. Los orculos son necesarios cuando se
prueban GUIs debido a que un comportamiento incorrecto en cualquier estado
puede impedir la ejecucin del resto del caso de prueba. Un cambio en la GUI
Pgina 6

puede hacer que algunos de los casos de prueba sean intiles, ya sea porque
especifican un estado inicial inalcanzable, una secuencia incorrecta de eventos o
estados esperados incorrectos para la GUI modificada. Tales casos de prueba se
denominan afectados y no se pueden ejecutar en la GUI modificada. Los casos de
pruebas restantes (no afectados) ejecutan exactamente la misma secuencia de
eventos, sin cambios, en la GUI modificada como lo hicieron en la GUI original y
especifican el estado esperado correctamente. Es improbable que estos casos de
prueba revelen fallos en la GUI modificada debido a que ya han sido probados para
esas secuencias.
Dado que los casos de prueba afectados no se pueden ejecutar en la GUI y los
casos de prueba no afectados no necesitan volver a ejecutarse, ninguno de los
casos de pruebas originales puede ser reutilizado durante las pruebas de regresin.
En consecuencia, nuevos casos de prueba tienen que ser generados desde cero
para volver a probar la GUI. Dado que el propsito de las pruebas de regresin es
volver a probar las partes pre-probadas del software, el diseador de pruebas debe
llevar un registro de todas ellas y volver a generar casos de prueba cuando sea
necesario. Dado que el anlisis necesario para la regeneracin selectiva es caro, en
la prctica no se realiza ninguna prueba de regresin de interfaces grficas de
usuario.
5

PROCEDIMIENTOS O METODOLOGIA A DESARROLLAR

En este trabajo se presenta una nueva tcnica para realizar pruebas de regresin a
GUI. Se representan casos de prueba de GUI con un alto nivel de abstraccin
utilizando tareas (pares de estados iniciales y finales). Y, aunque los cambios en la
GUI produzcan casos de prueba inservibles, dichas tareas continan siendo vlidas
a travs de las sucesivas versiones de la GUI. Se emplea la planificacin para
regenerar los casos de pruebas afectados a partir de estas tareas y, luego, se
utilizan para volver a probar. El uso de tareas est en lnea con la filosofa de las
pruebas de regresin, ya que su propsito es asegurar que cualquier funcionalidad
de un software no se haya estropeado, sin querer, a lo largo de su ciclo de vida. Las
tareas proporcionan una manera simple e intuitiva de representar la funcionalidad de
una GUI.

La representacin tradicional de casos de prueba de GUI, como

Pgina 7

secuencias de eventos y estados esperados, ya contiene el mecanismo necesario

para asociar una tarea con cada caso de prueba. La tcnica de planificacin
tambin se adapta de forma natural con el generador de casos de prueba que
emplea la planificacin jerrquica para generar casos de prueba [22, 24]. Dado que
el objetivo principal es la automatizacin, se utiliza un modelo de GUI para detectar
automticamente las modificaciones a la GUI e identificar casos de prueba que
deben volverse a ejecutar. Tambin se utilizan los casos de prueba originales como
cach para reusar sus partes tiles.
Se implementaron estas tcnicas para desarrollar un probador de regresin
automatizado. En el camino, se enfrentaron varios desafos. En primer lugar, se
tuvo que identificar, automticamente, las partes de la GUI que cambiaron de modo
que pudieran ser usadas para identificar los casos de prueba a ser ejecutados
nuevamente. En segundo lugar, haba que representar los casos de prueba a fin de
que no queden inutilizables cuando se realicen cambios en la GUI. Finalmente, se
tuvo que desarrollar un mecanismo para dar al diseador de pruebas una forma de
representar la nueva funcionalidad de la GUI despus de los cambios.
6

DESCRIPCIN GENERAL

Antes de presentar los detalles del modelo de interfaz grfica de usuario y los
algoritmos de pruebas de regresin, en esta seccin presentamos en primer lugar
una descripcin general e intuitiva del proceso de pruebas de regresin mediante un
ejemplo.

La figura 1 muestra una descripcin de alto nivel del probador de

regresin. Las entradas son el conjunto de pruebas original, generado para probar
la interfaz grfica original, y las representaciones de la GUI original y la modificada.
Las salidas son los casos de prueba que necesitan volver a ejecutarse, los casos de
prueba no afectados que no necesitan ser ejecutados nuevamente, y los casos de
prueba desechados.

Pgina 8

Figura 1 Descripcin de alto nivel del Probador de Regresin

Los componentes clave del probador de regresin son:

El selector de casos de prueba que divide el conjunto de pruebas original en

(1) los casos de prueba no afectados, (2) los casos de prueba para las tareas
obsoletas, por ejemplo, los que contienen un estado inicial inalcanzable, (3) los
casos de prueba que se ven afectados porque especifican una secuencia de
eventos ilegal para la GUI modificada, y (4) los casos de prueba que se ven
afectados porque especifican un estado esperado incorrecto para la GUI
modificada.

El regenerador de casos de prueba basado en planificacin que utiliza la

planificacin para regenerar los casos de prueba afectados que tienen una
secuencia de eventos ilegal. Si tiene xito, entonces el caso de prueba
regenerado se utiliza para las pruebas de regresin; de lo contrario, si el
planificador no puede encontrar un plan, entonces la tarea es declarada obsoleta
y el caso de prueba se descarta.

Pgina 9

El regenerador de estados esperados que regenera los estados esperados

para los casos de prueba. En caso de que no sea capaz de hacerlo, entonces la
tarea es declarada obsoleta y el caso de prueba se descarta.

Para hacer una descripcin general del probador de regresin y su funcionamiento

se tomar como ejemplo el popular software Xfig disponible en la mayora de
plataformas Unix. Se utilizan las versiones Xfig 3.2 patchlevel 0-beta4 (Protocolo
3.2) y Xfig 3.2 patchlevel 3c (Protocolo 3.2), a las que nos referiremos como el
software original y el modificado, respectivamente. El software original se muestra
en la Figura 2. Tenga en cuenta que las cajas sombreadas no son parte de la GUI.
Representan las etiquetas que se han utilizado para representar sus eventos. Las
lneas punteadas muestran las relaciones entre estos nombres y los eventos
correspondientes. Por ejemplo, la caja sombreada TypelnTextField representa un
evento utilizado para introducir texto en un campo. Las flechas de lnea continua
muestran las relaciones entre las ventanas y los eventos utilizados para abrirlas. Por
ejemplo, el evento File invoca la ventana titulada "Xfig: File Menu".
(Contine en la pgina siguiente)

Pgina 10

Figura 2. El software original (Xfig 3.2 patchlevel 0-beta4 (protocolo 3.2))

Considere el caso de prueba generado para el software original que se muestra en

la Figura 3. El caso de prueba utiliza un nuevo evento ClickOnObject(OBJETO),
que se traduce en hacer clic con el botn izquierdo del ratn sobre un objeto. Tenga
en cuenta que se han representado eventos usando la notacin de funcin con
parmetros. El caso de prueba ejecuta primero Xfig, carga un archivo llamado
original.fig, corta un objeto crculo, guarda el dibujo resultante con el nombre de
archivo new.fig, y sale de la aplicacin.

Pgina 11

Figura 3. Un caso de prueba para el software original

Un ejemplo de ejecucin de este caso de prueba utilizando una instancia especfica

del archivo original.fig se muestra en la Figura 4.
(Contine en la pgina siguiente)

Pgina 12

Figura 4. Ejecucin del caso de prueba en una instancia especfica de original.fig

Consideremos ahora el software modificado mostrado en la Figura 5. El software

modificado contiene la mayora de la funcionalidad del software original.
Concretamente, el usuario es capaz de cargar / guardar archivos y eliminar objetos.
Un diseador de la prueba realizando pruebas de regresin sobre la modificacin
del software tendra que comprobar si la funcionalidad probada que estaba
disponible en el software original funciona correctamente en el software modificado.

Pgina 13

Figura 5. El software modificado (Xfig 3.2 patchlevel 3c (protocolo 3.2))

Pgina 14

Sin embargo, examinando el caso de prueba de la figura 3 muestra que ni siquiera

puede ser ejecutado en el software modificado. Al hacer clic sobre File se abre un
men desplegable, (no la ventana como se hizo originalmente) impidiendo que el
evento TypelnTextField se ejecute. Por lo tanto, las modificaciones al software
hicieron que el caso de prueba de la figura 3 quede inservible debido a que la
secuencia de eventos se convirti en ilegal. El selector de casos de prueba marca
este caso de prueba como afectado para que el regenerador de casos de prueba
basado en planificacin lo tome en cuenta y lo procese. Sin embargo, a partir de la
experiencia previa de haber utilizado Xfig, sabemos que el software modificado
puede ser utilizado para llevar a cabo la tarea de la Figura 4. Si tuviramos que
realizar la tarea manualmente, tendramos que adaptar la secuencia de eventos
para esta nueva versin. El caso de prueba modificado necesario para lograr la
misma tarea se muestra en la Figura 6. El probador de regresin utiliza la
planificacin para generar el caso de prueba modificado automticamente. Este
caso de prueba puede ser utilizado para las pruebas de regresin.

Figura 6. Un caso de prueba para el software modificado

En principio, el enfoque descrito anteriormente puede ser utilizado para las pruebas
de regresin de interfaces grficas de usuario si las tareas se mantienen con cada
caso de prueba. Sin embargo, la regeneracin de los casos de prueba desde cero
es innecesaria, ya que algunas partes del caso de prueba original siguen siendo
vlidas y pueden ser reutilizadas. Para lograr este fin, se representa a la GUI como
una jerarqua de componentes y se emplea una forma de planificacin jerrquica
con almacenamiento en cach.

Pgina 15

El proceso de pruebas completo puede dividirse en tres fases principales. En la

primera fase de Configuracin el sistema automatizado crea un modelo de GUI
que consta de operadores para la planificacin, los grficos de flujo de eventos, y un
rbol de integracin [25] que se utiliza durante todo el proceso de pruebas. A
continuacin, el diseador de pruebas:

Define las precondiciones y los efectos de cada operador.

Comienza la fase de Generacin de Casos de Prueba identificando las tareas.

Estas tareas son utilizadas por un generador de casos de prueba para
generarlos automticamente.

Modifica la GUI como el primer paso de la fase de Pruebas de Regresin. El

sistema actualiza automticamente el modelo de la GUI, identifica los casos de
prueba que deben volver a ejecutarse y genera el conjunto de pruebas de
regresin. Este proceso se resume en la siguiente tabla:

Fase

Pas
o

Diseador de
Pruebas

1
Configuraci
n
2
Generacin
de Casos de
Prueba

Pruebas de
Regresin

Definir las
Precondiciones y
Efectos de los
Operadores
Identificar Tareas

4
5

Sistema basado en
planificacin
Derivar los Operadores
Jerrquicos de GUI,
Grficos de Flujo de
Eventos, Arboles de
Integracin

Generar Casos de Prueba

Modificar el diseo de la
GUI

Detectar cambios al
modelo de la GUI

Identificar casos de prueba

afectados que necesitan
volver a ejecutarse

Generar el conjunto de
pruebas de regresin
Tabla 1. Funciones del diseador de pruebas y el sistema automtico durante las pruebas
8

de regresin.

Pgina 16

GENERACIN DEL PLAN

En este acpite se ofrece informacin general sobre generacin de planes. La

generacin automatizada de planes ha sido ampliamente investigada y utilizada
dentro del campo de la inteligencia artificial. Dado un estado inicial, un estado final,
un conjunto de operadores, y un conjunto de objetos, un planificador devuelve un
conjunto de pasos (operadores instanciados) para lograr el objetivo. Distintos
algoritmos para la generacin de un plan se han propuesto y desarrollado. Para
profundizar en el asunto se puede consultar [24] para ver ejemplos de trabajos
recientes en este campo.
En este trabajo se emple una tecnologa de planificacin desarrollada
recientemente que aumenta la eficiencia de la generacin del plan. Concretamente,
se generan planes de un solo nivel a travs del Planificador de Progresin por
Interferencia (IPP) [9], un sistema que extiende las ideas del sistema Graphplan [5]
para la generacin de un plan. Graphplan introdujo la idea de llevar a cabo la
generacin del plan mediante la conversin de la representacin de un problema de
planificacin en una codificacin proposicional.
IPP forma planes en un solo nivel de abstraccin. En el presente trabajo se extendi
esto a la planificacin jerrquica, la cual es valiosa para la generacin de casos de
prueba para GUIs por varias razones. En primer lugar, puesto que las GUIs tienden
a ser grandes, el uso de una jerarqua nos permite descomponerla en partes con
diferentes niveles de abstraccin, lo que resulta en una mayor eficiencia. En
segundo lugar, esta descomposicin de la GUI trae como resultado que se generen
planes para cada nivel individualmente. Los cambios a un componente de la GUI no
invalidan todos los casos de prueba. De hecho, la mayora de los casos de prueba
pueden ser conservados. Los cambios slo deben ser realizados a los casos de
prueba asociados al componente modificado, lo que contribuye con las pruebas de
regresin.
Un ltimo punto se refiere a la generacin de planes alternativos. Como se seal
anteriormente, una de las principales ventajas de la utilizacin del planificador en

Pgina 17

esta aplicacin es la generacin automtica de planes alternativos para la misma

meta o estado objetivo.
8

REPRESENTACIN DE LOS CASOS DE PRUEBA DE GUI

Una GUI se modela como un conjunto de objetos O = {o1, o2,..., om} (por
ejemplo, label, form, button, text) y un conjunto de las propiedades P
= {p1, p2,..., Pl} de esos objetos (por ejemplo, background-color,
font, caption). Cada GUI usar ciertos tipos de objetos con sus propiedades
asociadas; en cualquier punto especfico en el tiempo, el estado de la GUI puede
ser descrito en trminos de todos los objetos que contiene, y los valores de todas
sus propiedades. Formalmente se define el estado de una GUI como sigue:
Definicin: El estado de una GUI en el momento t es el conjunto P de todas las
propiedades de todos los objetos O que la GUI contiene en el tiempo t.
Con cada GUI se asocia un conjunto diferenciado de estados llamado su
conjunto inicial de estados vlidos:
Definicin: Un conjunto de estados SI se denomina conjunto inicial de estados
vlidos para una determinada GUI s y slo s la GUI puede estar en cualquier
estado Si SI cuando se invoca por primera vez.
El estado de una GUI no es esttico; los eventos realizados en la GUI cambian su
estado. Estos estados son llamados estados alcanzables de la GUI. Los eventos se
modelan como transductores de estados. La notacin de la funcin Sj = e(Si) se
utiliza para denotar que Sj es el estado resultante de la ejecucin del evento e en el
estado Si. Los eventos pueden ser agrupados en secuencias. De importancia para
los probadores son secuencias que se permiten por la estructura de la GUI. Se
restringen las pruebas a las secuencias de eventos vlidas, definidas de la siguiente
manera:
Definicin: Una secuencia de eventos legal de una GUI es e1; e2; e3;;en
donde ei+1 puede ser realizado despus de ei.

Pgina 18

Finalmente se define un Caso de Prueba de GUI como:

Definicin: Un Caso de Prueba de GUI T es un triple < S0, e1; e2; e3;;en,
Sn > compuesto por un estado alcanzable S0 llamado el estado inicial para T, una
secuencia de eventos legal e1; e2; e3;;en y Sn, el estado final de la GUI
despus de que el caso de prueba es ejecutado.
Ntese que S0 y Sn son una parte del caso de prueba y representan la tarea
asociada con el caso de prueba.
9

REPRESENTACIN DE LOS EVENTOS DE GUI COMO OPERADORES

Formalmente, cada evento est representado por un operador. Estos operadores

son utilizados por los planificadores de inteligencia artificial para generar planes. A
continuacin, se presenta una descripcin general de los operadores mediante la
presentacin de un ejemplo.

Intuitivamente, un operador especifica las

precondiciones y los efectos del evento que representa. Las precondiciones

representan las condiciones que deben cumplirse antes de que el evento pueda
ejecutarse en la GUI. Los efectos representan las modificaciones hechas a la GUI
despus de la ejecucin del evento. Por ejemplo, el siguiente operador representa
una evento llamado set-background-color que se utiliza para cambiar el color
de fondo de una ventana de GUI:
Nombre: set-background-color (WX: window, Col: color)
Precondiciones: is-open (WX)
Efectos: background-color (WX, Col)
La definicin del operador muestra que el evento set-background-color (WX,
Col) toma dos parmetros: una ventana WX y el color Col; WX y Col pueden tomar
valores especficos en el contexto de la ejecucin de una determinada GUI. Las
condiciones previas requieren que el evento set-background-color (WX,
Col) slo se pueda ejecutar en un estado en el que la ventana WX est abierta,
siendo el efecto que el color de fondo de WX cambie a Col.

Pgina 19

10 DISEO DETALLADO DEL PROBADOR DE REGRESIN

Como se mostr anteriormente en la Figura 1, el probador de regresin consiste de
dos componentes principales: el Selector de Casos de Prueba y el Regenerador de
Casos de Prueba. Esta seccin proporciona informacin sobre el diseo de estos
componentes.
El Selector de Casos de Prueba: la funcin primaria de este componente es la de
identificar los casos de prueba afectados. Adems, realiza la identificacin preliminar
de casos de prueba descartados. Por ejemplo, descarta todos los casos de prueba
asociados con tareas obsoletas.
El Regenerador de Casos de Prueba: el diseo de este componente es
esencialmente el mismo que el de PATHS [24] excepto que se introdujo un cach
para reutilizar partes del caso de prueba original afectado. No se han incluido los
detalles de los algoritmos de planificacin, debido a razones de espacio. La idea
clave es explotar el algoritmo de planificacin jerrquica y, en lugar de invocar el
planificador para cada sub-plan, primero se comprueba si una parte vlida del caso
de prueba ya existe. Si existe, entonces esta parte es reutilizada.
11 GLOSARIO DE TRMINOS
Orculo de pruebas:

Es un mecanismo usado por probadores e ingenieros de

software para determinar si una prueba pas o fall. Es
usado para comparar la salida del sistema que se prueba,
para un caso de prueba que se da como entrada, con la
salida que el orculo determina se debera obtener.

Pruebas de regresin:

Es cualquier tipo de pruebas de software que busca

descubrir nuevas fallas (bugs) o regresiones, en los
requerimientos funcionales o no funcionales, despus de
que algunos cambios (mejoras, correcciones o cambios
en la configuracin) se introdujeran en sus componentes.

Regresin de software:

Es una falla (bug) que hace que una funcionalidad deje

de funcionar correctamente despus de un evento dado
Pgina 20

(por ejemplo, una actualizacin o correcciones). Puede

ser de 3 tipos:
Local un cambio introduce una falla en el mdulo o
componente modificado.
Remoto un cambio en una parte del software quiebra la
funcionalidad de otro mdulo o componente.
Escondido un cambio descubre una falla que no haba
sido advertida antes del cambio.
12 SIGLARIO
GUI:

Graphical User Interface o Interfaz Grfica de Usuario

IPP

Interference Progression Planner

13 BIBLIOGRAFA
Last, Mark (Editor); Kandel, A. (Editor). Artificial Intelligence Methods in Software
Testing.
River Edge, NJ, USA: World Scientific, 2004
http://site.ebrary.com/lib/upc/Doc?id=10256002
[1] Agrawal, H., Horgan, J. R., Krauser, E. W., and London, S. A. "Incremental regression
testing". In Proceedings of the Conference on Software Maintenance (Washington, Sep.
1993), pp. 348 - 357.
[2] Ball, T. "On the limit of control flow analysis for regression test selection". In Proceedings
of the ACM SIGSOFTInternational Symposium on Software Testing and Analysis (ISSTA-98)
(New York, Mar.2 - 5 1998), vol. 23, 2 of ACM Software Engineering Notes, pp. 134 - 142.
[3] Beizer, B. Software Testing Techniques, 2nd ed. Van Nostrand Reinhold, New York, 1990.
[4] Benedusi, P., Cimitile, A., and DeCarlini, U. "Post-maintenance testing based on path
change analysis". In Proceedings of the IEEE Conference on Software Maintenance (1988),
pp. 352 - 368.
[5] Binkley, D. "Reducing the cost of regression testing by semantics guided test case
selection". In Proceedings of the International Conference on Software Maintenance
(Washington, Oct. 17-2 0 1995), G.Caldiera and K.Bennett, Eds., IEEE Computer Society
Press, pp. 251 - 263.
[6] Binkley, D. "Semantics guided regression test cost reduction". IEEE Transactions on
Software Engineering, 23, 8 (Aug. 1997), 498 - 516.
[7] Frank, M., de, J. J. G., Gieskens, D., and Foley, J. D. "Building user interfaces
interactively using re-and postconditions". In Proceedings of CHI '92 (1992).

Pgina 21

[8] Green, M. The Design of Graphical User Interfaces. Ph.d. thesis, Department of
Computer Science, University of Toronto, 1985.
[9] Harrold, M. J., Gupta, R., and Soffa, M. L. "A methodology for controlling the size of a test
suite". ACM Transactions of Software Engineering and Methodology 2, 3 (July 1993), 270285 .
[10] Harrold, M. J., McGregor, J. D., and Fitzpatrick, K. J. "Incremental testing of objectoriented class structures". In Proceedings: 14th International Conference on Software
Engineering (1992), pp. 68 - 80.
[11] Harrold, M. J., and Soffa, M. L. "Interprocedual data flow testing". In Proceedings
oftheACMSIGSOFT '89 Third Symposium on Testing, Analysis, and Verification (TAV3)
(1989),pp. 158-167 .
[12] Jonsson, A. K., and Ginsberg, M. L. "Procedural reasoning in constraint satisfaction". In
Proceedings of the Fifth International Conference on Principles of Knowledge
Representation and Reasoning (San Francisco, Nov. 58 1996), L. C. Aiello, J. Doyle, and S.
Shapiro, Eds., Morgan Kaufmann, pp. 160 - 173.
[13] Kambhampati, S. "Can we bridge refinement-based and SAT-based planning
techniques?" In Proceedings of the 15th International Joint Conference on Artificial
Intelligence (IJCAI-97) (1997), M. Pollack, Ed., Morgan Kaufmann, pp. 44 -49.
[14] Kasik, D. J., and George, H. G. "Toward automatic generation of novice user test
scripts". In Proceedings of the Conference on Human Factors in Computing Systems:
Common Ground (New York, 13-18 Apr. 1996), ACM Press, pp. 244 - 251.
[15] Koehler, J., Nebel, B., Hoffman, J., and Dimopoulos, Y. Extending planning to an ADL
subset. Lecture Notes in Computer Science 1348 (1997), 273.
[16] Koehler, J., Nebel, B., Hoffman, J., and Dimopoulos, Y. "Extending planning graphs to
an ADL subset". In Proceedings of the 4th European Conference on Planning (ECP-97):
Recent Advances in AI Planning (Berlin, Sept. 24 -26 1997), S. Steel and R. Alami, Eds., vol.
1348 of LNAI, Springer, pp. 273-285.
[17] Kung, D. C, Gao, J., Hsia, P., Toyoshima, Y., and Chen, C. "On regression testing of
object-oriented programs". The Journal of Systems and Software 32, 1 (Jan. 1996), 21-31.
[18] Lifschitz, V. "On the semantics of STRIPS. "In Reasoning about Actions and Plans:"
Proceedings of the 1986 Workshop (Timberline, Oregon, June-July 1986), M. P. George and
A. L. Lansky, Eds., Morgan Kaufmann, pp.1 - 9.
[19] Mahajan, R., and Shneiderman, B. "Visual & textual consistency checking tools for
graphical user interfaces". Technical Report CS-TR-3639, University of Maryland, College
Park, May 1996.
[20] McCarthy, J. Situations, actions, and causal laws. Memo 2, Stanford University Artificial
Intelligence Project, Stanford, California, 1963.
[21] Memon, A. M. A Comprehensive Framework for Testing Graphical User Interfaces.
Ph.D. thesis, Department of Computer Science, University of Pittsburgh, July 2001.

Pgina 22

[22] Memon, A. M., Pollack, M. E., and Soffa, M. L. "Using a goal-driven approach to
generate test cases for GUIs". In Proceedings of the 21st International Conference on
Software Engineering (May 1999), ACM Press, pp. 257 - 266.
[23] Memon, A. M., Pollack, M. E., and Soffa, M. L. "Automated test oracles for GUIs". In
Proceedings of the ACM SIGSOFT 8th International Symposium on the Foundations of
Software Engineering (FSE-8) (NY, Nov. 8-1 0 2000), pp. 30 - 39.
[24] Memon, A. M., Pollack, M. E., and Soffa, M. L. "Hierarchical GUI test case generation
using automated planning ". IEEE Transactions on Software Engineering 27, 2(Feb. 2001),
144-155.
[25] Memon, A. M., Soffa, M. L., and Pollack, M. E. "Coverage criteria for GUI testing". In
Proceedings of the 8th European Software Engineering Conference (ESEC) and 9th ACM
SIGSOFT International Symposium on the Foundations of Software Engineering (FSE-9)
(Sept. 2001), pp. 256 - 267.
[26] Myers, B. A. "User interface software tools". ACM Transactions on ComputerHuman
Interaction 2, 1 (1995), 64-103.
[27] Pednault, E.P.D. "ADL: Exploring the middle ground between STRIPS and the situation
calculus". In Proceedings ofKR '89 (Toronto, Canada, pp. 324 - 331, May 1989).
[28] Pollock, L., and Soffa, M. L. "Incremental global reoptimization of programs". ACM
Transactions on Programming Languages and Systems 14, 2 (Apr. 1992), 173 -200.
[29] Pressman, R. S. Software Engineering: A Practitioner's Approach. 1994.
[30] Rosenblum, D., and Rothermel, G. "A comparative study of regression test selection
techniques". In Proceedings of the IEEE Computer Society 2nd International Workshop on
Empirical Studies of Software maintenance (Oct. 1997), pp.89 - 94.
[31] Rosenblum, D. S., and Weyuker, E. J. "Predicting the cost-effectiveness of regression
testing strategies". In Proceedings of the Fourth ACM SIGSOFT Symposium on the
Foundations of Software Engineering (New York, Oct. 16 -18 1996), vol.21 ofACM Software
Engineering Notes, ACM Press, pp. 118 -126.
[32] Rosenblum, D. S., and Weyuker, E. J. "Using coverage information to predict the costeffectiveness of regression testing strategies". IEEE Transactions on Software Engineering
23, 3 (Mar. 1997), 146 - 156.
[33] Rothermel, G., and Harrold, M. J. "A safe, efficient algorithm for regression test
selection". In Proceedings of the Conference on Software Maintenance (1993), pp. 358 369.
[34] Rothermel, G., and Harrold, M. J. "A safe, efficient regression test selection technique".
ACM Transactions on Software Engineering and Methodology, 2 (Apr. 1997), 173-210.
[35] Rothermel, G., and Harrold, M. J. "Empirical studies of a safe regression test selection
technique". IEEE Transactions on Software Engineering 24, 6 (June 1998), 401-419.
[36] Rothermel, G., Harrold, M. J., Ostrin, J., and Hong, C. "An empirical study of the effects
of minimization on the fault detection capabilities of test suites". In Proceedings; International
Conference on Software Maintenance (1998), pp. 34 - 43.

Pgina 23

[37] Schach, S. R Software Engineering, Richard D. Irwin/Aksen Associates, 1993.

[38] Weld, D. S. "An introduction to least commitment planning". AI Magazine, 15, 4 (1994),
27-61.
[39] Weld, D. S. "Recent advances in AI planning". AI Magazine 20, 1 (Spring 1999), 55-64.
[40] White, L. "Regression testing of GUI event interactions". In Proceedings of the
International Conference on Software Maintenance (Washington, Nov. 48 1996), pp. 350-35.

Pgina 24