ArticlePDF Available

Aplicación de Open HMI Tester como framework open-source para herramientas de pruebas de software

Authors:

Abstract and Figures

Software testing is a very important phase in the software development process. These tests are performed to ensure the quality, reliability, and robustness of software within the execution context it is expected to be used. Some of these tests are focused on ensuring that the graphical user interfaces (GUIs) are working properly. GUI Testing represents a critical step before the software is deployed and accepted by the end user. This paper describes the main results obtained from our research work in the software testing and GUI testing areas. It also describes the design and implementation of an open source architecture used as a framework for developing automated GUI testing tools.
Content may be subject to copyright.
Disponible en: http://redalyc.uaemex.mx/src/inicio/ArtPdfRed.jsp?iCve=92217159003
Redalyc
Sistema de Información Científica
Red de Revistas Científicas de América Latina, el Caribe, España y Portugal
Mateo Navarro, Pedro Luis; Martínez Pérez, Gregorio; Sevilla Ruiz, Diego
Aplicación de Open HMI Tester como framework open-source para herramientas de
pruebas de software
REICIS Revista Española de Innovación, Calidad e Ingeniería del Software, vol. 5,
núm. 4, diciembre-enero, 2009, pp. 6-18
Asociación de Técnicos de Informática
Madrid, España
¿Cómo citar? Número completo Más información del artículo Página de la revista
REICIS Revista Española de Innovación, Calidad
e Ingeniería del Software
ISSN (Versión electrónica): 1885-4486
reicis@ati.es
Asociación de Técnicos de Informática
España
www.redalyc.org
Proyecto académico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 6
Aplicación de Open HMI Tester como framework
open-source para herramientas de pruebas de software
Pedro Luis Mateo Navarro1,2, Gregorio Martínez Pérez1, Diego Sevilla Ruiz2
1Departamento de Ingeniería de la Información y las Comunicaciones
2Departamento de Ingeniería y Tecnología de Computadores
Universidad de Murcia, 30.071 Murcia, España
{pedromateo,gregorio,dsevilla}@um.es
Resumen
Las pruebas de software comprenden una fase muy importante del proceso de desarrollo.
Este tipo de pruebas tienen como principal objetivo asegurar la calidad, fiabilidad y
robustez de un software, dentro de un contexto o escenario donde está previsto que éste sea
utilizado. Un subconjunto de estas pruebas corresponde con las que tienen como principal
objetivo asegurar el correcto funcionamiento de las interfaces de usuario (o GUIs –
Graphical User Interfaces–). Este tipo de pruebas de GUI representan un paso crítico antes
de que un software sea puesto en funcionamiento y aceptado por el usuario final. Este
artículo describe los principales resultados obtenidos como fruto de una serie de
investigaciones relacionadas con las pruebas de software y de GUIs, entre los que se
encuentra el diseño e implementación de una arquitectura código-abierto utilizada como
entorno para el desarrollo de herramientas automáticas de pruebas sobre GUIs.
Palabras clave: Framework para herramientas de test, tests sobre GUIs, generación
automática de casos de prueba en GUIs, tests de usabilidad software.
Application of the Open HMI Tester as an Open-source
Framework for Software Testing Tools
Abstract
Software testing is a very important phase in the software development process. These tests
are performed to ensure the quality, reliability, and robustness of software within the
execution context it is expected to be used. Some of these tests are focused on ensuring that
the graphical user interfaces (GUIs) are working properly. GUI Testing represents a critical
step before the software is deployed and accepted by the end user. This paper describes the
main results obtained from our research work in the software testing and GUI testing areas.
It also describes the design and implementation of an open source architecture used as a
framework for developing automated GUI testing tools.
Key words: Framework for testing tools, GUI testing, GUI test case auto-generation,
software usability testing.
Mateo, P.J., Martínez, G., Sevilla, D.,”Aplicación de Open HMI Tester como framework open-source para herramientas de pruebas de
software”, REICIS, vol. 5, no.4, 2009, pp.6-18. Recibido: 23-7-2009; revisado: 28-10-2009; aceptado: 19-11-2009
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 7
1. Introducción
Las interfaces gráficas de usuario (GUIs) representan un elemento fundamental y crítico de
las aplicaciones de hoy en día, llegando a acaparar incluso hasta el 60% del código que se
produce en un proyecto software. Por lo tanto, probar la funcionalidad de las GUIs se
presenta como una tarea imprescindible para asegurar la calidad, fiabilidad, robustez y
usabilidad del sistema completo.
Pese a que está demostrado que la utilización de herramientas avanzadas para las
pruebas de GUI permite mejorar los resultados y ahorrar tiempo y recursos a las empresas
de desarrollo, la integración de éstas en los desarrollos actuales no es tan frecuente como se
podría esperar. El principal motivo es que la naturaleza propia de este tipo de herramientas
no facilita su integración en el proceso de desarrollo, ya que suelen poseer características
muy específicas del entorno de pruebas para el que inicialmente fueron desarrolladas. Una
limitación adicional relacionada directamente con las interfaces gráficas de usuario es que,
hoy en día, existe una gran cantidad de sistemas de ventanas que pueden ser empleados en
los desarrollos software, por lo que es fundamental el diseño de herramientas adaptables o
de propósito general. Todas estas limitaciones, junto con otras tantas, son las que
convierten la investigación, el diseño y el desarrollo de herramientas de pruebas abiertas y
multiplataforma en un desafío muy interesante.
Este trabajo incluye una breve descripción de la arquitectura Open HMI Tester
(OHT) (sección 2) y de algunas aplicaciones reales de ésta en el área de pruebas del
software. En la sección 3 se describe una herramienta de captura y reproducción automática
de pruebas de software desarrollada sobre la arquitectura mencionada anteriormente. En la
sección 4 se explica un sistema de generación automática de casos de prueba para interfaces
de usuario. Adicionalmente, en la sección 5 se describen algunas aplicaciones de esta
arquitectura en el ámbito de las pruebas de usabilidad. Finalmente, se incluye una sección
de conclusiones sobre el trabajo expuesto y algunas referencias sobre el trabajo futuro.
2. Arquitectura Open HMI Tester
La arquitectura Open-HMI Tester (OHT) [1] se trata de una arquitectura abierta (no está
ligada a ningún sistema operativo ni sistema de ventanas concretos) para pruebas de
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 8
interfaz gráfica. Esta arquitectura (figura 1) está compuesta por una serie de módulos que
implementan la funcionalidad genérica, y que por lo tanto nunca cambian (representados en
la figura por las cajas no coloreadas), y un conjunto de módulos que deben ser adaptados
(representados en la figura por las cajas coloreadas) con el fin de dotar a la arquitectura de
la funcionalidad necesaria para poder operar sobre un entorno de pruebas (sistema
operativo, sistema de ventanas, etc.) concreto.
Figura 1: Arquitectura del HMI Tester y del Preload Module.
La arquitectura OHT se divide en dos módulos principales: el primero de ellos es el
módulo HMI Tester, el cual se encarga principalmente del control de los procesos; el
segundo de ellos corresponde con el módulo Preload, el cual es inyectado en la aplicación
testada (en tiempo de ejecución) con el fin de ofrecer servicios de extracción y ejecución de
eventos. Ambos módulos tienen la capacidad de comunicarse entre sí, lo que permite a la
parte controladora llevar a cabo un proceso de introspección sobre la aplicación testada con
dos fines principales: por una parte extraer la información correspondiente a los eventos
generados a causa de las acciones que realiza el operador sobre la aplicación a probar; por
otra, poder enviar nuevos eventos al núcleo de la aplicación objetivo con el fin de simular,
de la manera más realista posible, las acciones del operador sobre la interfaz gráfica de la
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 9
aplicación testada. El hecho de que el proceso de introspección se realice mediante la
inyección de una librería dinámica en la aplicación testada [2] evita la necesidad de ejecutar
ningún tipo de código o de llamada en ésta, lo que permite que las herramientas
desarrolladas bajo esta arquitectura puedan ser usadas tanto en aplicaciones en fase de
desarrollo como en aplicaciones ya desarrolladas.
El módulo HMI Tester tiene como principal cometido el controlar los procesos de
grabación (captura de eventos) y de reproducción (ejecución de eventos), así como la
gestión completa de la creación y el mantenimiento de los archivos de pruebas (test suites).
Como podemos observar en la figura 1, el módulo HMI Tester contiene una serie de
submódulos que deben ser adaptados:
Data Model Manager and Adapter submodules: estos submódulos permiten
integrar en la arquitectura Open HMI Tester la implementación de cualquier
representación del modelo de datos. Por lo tanto, deberán ser adaptados
dependiendo del modelo de datos seleccionado para representar el conjunto de
pruebas (test suite).
Preloading Action module: el principal objetivo de este submódulo es llevar a
cabo el proceso de precarga, permitiendo la inyección del módulo Preload al
lanzar la aplicación a testar. Ya que el proceso de lanzamiento y control de
aplicaciones puede incluir acciones concretas del sistema operativo, este módulo
deberá ser adaptado dependiendo de las características del entorno de pruebas.
El resto de submódulos incluyen la funcionalidad genérica, y que por lo tanto se
reutilizará independientemente de las características del entorno de pruebas en el que
estemos trabajando; esta funcionalidad se encarga principalmente de manejar la interfaz de
usuario (la correspondiente a la herramienta de pruebas) y las decisiones que se toman en
ella, el sistema de comunicaciones hacia el módulo Preload, y el control de los procesos de
grabación y reproducción de casos de prueba.
El módulo Preload será inyectado en la aplicación testada como una librería
dinámica [2], con el fin de añadir la funcionalidad necesaria para llevar a cabo los procesos
de extracción y ejecución de eventos. Su principal cometido será la captura de datos y
eventos GUI, y también la ejecución de los eventos y órdenes recibidas desde el módulo
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 10
HMI Tester. Como podemos observar en la figura 1, este módulo también contiene una
serie de submódulos que deben ser adaptados dependiendo de las características del entorno
de pruebas:
Preloading Control module: este submódulo será el encargado de desplegar
todos los servicios necesarios para incorporar toda la funcionalidad del módulo
Preload a la aplicación testada. Su funcionalidad deberá ser adaptada con el fin de
asegurar que el conjunto de servicios necesarios para la introspección
(comunicaciones, extracción de datos y ejecución de eventos y acciones) sean
desplegados durante el proceso de inicialización de la aplicación testada.
Event Consumer module: este submódulo se encarga de capturar y filtrar los
eventos que se generan por las acciones del operador en la aplicación testada,
gestionar los datos que éstos contienen y enviarlos hacia el HMI Tester para que
sean tratados y almacenados. La adaptación de este submódulo dependerá del
sistema de ventanas utilizado y de la jerarquía de eventos que utilice.
Event Executor module: este submódulo ejecutará en la aplicación testada los
eventos recibidos desde el módulo HMI Tester. La ejecución de estos eventos
permitirá llevar a cabo una reproducción fiel de las acciones del operador que
previamente fueron almacenadas, junto con cualquier acción adicional que pueda
resultar necesaria para llevar a cabo el control del proceso de ejecución y/o
validación. Los nuevos eventos recibidos serán notificados a través de un método
de la interfaz. La implementación de este submódulo también dependerá del
sistema de ventanas.
El resto de submódulos incluyen la funcionalidad genérica correspondiente a la lógica
que gestiona los procesos en la aplicación testada, y la correspondiente al sistema de
comunicaciones hacia el módulo HMI Tester.
Como también podemos apreciar en la figura 1, el proceso completo requiere la
comunicación entre los dos módulos principales: HMI Tester y Preload. Esta comunicación
se llevará a cabo mediante el establecimiento de un canal de datos (por ejemplo, sockets
TCP) y el intercambio de elementos de información. Por otra parte, el módulo Preload
también deberá establecer una comunicación con la aplicación testada a través de la captura
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 11
y envío de eventos, la cual puede ser completada con la ejecución de acciones mediante
código.
3. Herramientas de captura y reproducción para GUI
Una de las principales aplicaciones de la arquitectura Open HMI Tester es la creación de
herramientas de captura y reproducción para pruebas de interfaces gráficas de usuario. Este
tipo de herramientas se centran en capturar la interacción de un operador con la aplicación
(normalmente se almacena la secuencia de acciones que el operador ha realizado sobre la
GUI), y volcarla a un fichero o soporte similar. Posteriormente, las secuencias de acciones
pueden ser recuperadas y reproducidas sobre el software real tantas veces como sea
necesario.
Actualmente existen herramientas parecidas que permiten grabar una secuencia de
eventos y luego volver a reproducirla. Muchas de estas herramientas tienen la principal
desventaja de que no capturan la interacción real del operador, sino que sólo son capaces de
acceder a los eventos más externos de la GUI (es decir, clics de ratón y pulsaciones de
teclado) y no al resto de los eventos que también forman parte de la ejecución de las
acciones. Esta merma en la precisión de las acciones almacenadas puede provocar, por
ejemplo, que un mínimo cambio en el entorno de pruebas (por ejemplo, mover la ventana
principal de la aplicación 10 píxeles hacia un lado) convierta en inservible todo el esfuerzo
realizado en un proceso anterior de grabación de casos de prueba. La baja tolerancia a
modificaciones que presentan algunas de estas herramientas provoca que la fiabilidad y
robustez de estos sistemas de pruebas quede en entredicho. En el lado opuesto tenemos las
herramientas que al igual que ocurre en la arquitectura Open HMI Tester, pueden acceder al
núcleo de la aplicación testada gracias a la introspección no intrusiva en código (mediante
la inyección de librerías DLL) y por tanto tienen acceso sin problemas a toda la
información correspondiente a cualquier evento generado en ella. Esta característica
permite llevar a cabo una reproducción de secuencias de eventos en la que realmente se
simula la interacción del operador sobre la aplicación, siendo ésta tolerante a ciertas
modificaciones no críticas, como por ejemplo, un cambio en la localización de la ventana,
la inclusión de nuevos elementos en la GUI, modificaciones en la localización de estos
elementos, etc.
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 12
Este tipo de herramientas permite llevar a cabo un proceso de pruebas de interfaz
gráfica donde el operador es el que decide qué partes de la GUI deben probarse, evitando
así la creación de pesados modelos y de enormes baterías de casos de prueba. Esto nos
permite solucionar el conocido problema del coverage criteria [3] (o problema del criterio
de cobertura en su traducción al español), ya que la responsabilidad de decidir qué partes
son testadas y cuáles no recaen completamente sobre el operador. Así, los casos de prueba
generados se centrarán en los elementos relevantes y la funcionalidad para la que la GUI
fue desarrollada, evitando secuencias de eventos y combinaciones de acciones sin sentido
práctico.
Este tipo de herramientas también pueden incluir procesos adicionales
(normalmente con el apoyo de herramientas de edición externas o incorporadas en la propia
aplicación), como por ejemplo la validación automática mediante la incorporación de
eventos especiales, la creación de guías del operador interactivas, o la generación de
documentación asociada a las pruebas. Esto permite complementar el proceso de pruebas
en base a las necesidades de cada proyecto.
En la figura 2 podemos apreciar una captura de pantalla correspondiente a un
prototipo de herramienta de captura y reproducción desarrollado sobre la arquitectura Open
HMI Tester. Esta herramienta, que puede ser descargada desde la plataforma Sourceforge
en la dirección http://sourceforge.net/projects/openhmitester/, fue implementada con el
objetivo de mostrar la funcionalidad y el enfoque aportado por la arquitectura Open HMI
Tester. Este prototipo adapta la arquitectura OHT a un entorno de pruebas con las
siguientes características:
Sistema operativo Linux.
Sistema de ventanas Trolltech Qt4 bajo X-Window.
Representación del fichero de pruebas con XML.
Este prototipo, desarrollado en lenguaje C++, incluye la funcionalidad básica
necesaria para llevar a cabo los procesos de captura y reproducción de eventos sobre
aplicaciones desarrolladas bajo las características especificadas más arriba.
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 13
Figura 2: Pantalla de una Herramienta de Captura/reproducción desarrollada sobre la arquitectura OHT
4. Generación automática de casos de prueba y procesos de validación
sobre GUI
Otra de las áreas en las que se está trabajando es la de la generación automática de pruebas
para interfaces de usuario. La solución propuesta en [4] describe un enfoque intermedio
entre las pruebas de software basadas en modelos y las que no utilizan ningún tipo de
modelado, ya que la solución propuesta se centra principalmente en la creación de un
modelo ligero a partir de un conjunto de anotaciones sobre los elementos representativos de
la GUI.
El proceso correspondiente a este nuevo enfoque se basa principalmente en dos
elementos: el primero de ellos es un conjunto inicial de casos de uso, que será utilizado
para describir el comportamiento de la GUI; el otro elemento será un conjunto de
anotaciones que describirán las posibles variaciones que pueden afectar a los diferentes
elementos que componen la GUI (variaciones sobre los valores contenidos por esos
elementos), y adicionalmente una serie de reglas de validación que comprobarán ciertas
propiedades de esos elementos.
Como podemos apreciar en la figura 3, una vez hayamos definido un conjunto inicial
de casos de uso que describa el funcionamiento de la GUI, el proceso continúa con las
siguientes fases:
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 14
1. Anotación de la GUI: durante este proceso se van anotando los elementos más
representativos de la GUI, es decir, los elementos a tener en cuenta en el conjunto
de pruebas. Estos elementos pueden ser anotados de dos formas totalmente
complementarias: la primera de ellas consiste en indicar un conjunto o rango de
posibles valores que un elemento puede tener (cada nuevo valor da lugar a un
nuevo caso de prueba); la segunda consiste en comprobar cierto valor de alguna
propiedad que deba ser validada (se introducirán nuevas reglas de validación para
estos elementos). A la hora de anotar un elemento, el operador podrá escoger
cualquiera de las dos alternativas, o las dos en el caso de que sea necesario.
Figura 3: Proceso completo de auto-generación de casos de prueba basado en anotaciones
2. Generación automática de casos de prueba: durante esta fase se generará un
nuevo caso de prueba para cada posible combinación de valores, es decir, se
generarán todos los casos de prueba necesarios para cubrir todo el espectro de
valores incluidos en las anotaciones y todas sus combinaciones. También se
añadirán nuevos puntos de validación para satisfacer las reglas especificadas en la
fase anotación. La figura 4 muestra un ejemplo muy sencillo en el que en la parte
izquierda se muestran una serie de anotaciones sobre dos elementos de la GUI, y
en la parte derecha se incluye el conjunto equivalente de casos de uso generados.
Como podemos apreciar, se han generado cuatro casos de uso para cubrir todas
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 15
las posibles combinaciones de los 2x2 valores definidos. Además, se ha añadido
un punto de validación para el segundo elemento anotado para poder comprobar
las reglas definidas en las anotaciones.
3. Ejecución y validación: en este proceso los casos de prueba generados en el paso
anterior son ejecutados uno a uno; al mismo tiempo se llevará a cabo el proceso
de validación mediante el uso de test oracles [5]). Finalmente el proceso devuelve
un informe completo en el que se incluirá el resultado, satisfactorio o no, de la
ejecución de cada uno de los casos de prueba, y en el que también se incluirá el
resultado de cada una de las validaciones.
Figura 4: Ejemplo de generación automática de pruebas a partir de anotaciones
Como se ha comentado antes, en la tercera fase se llevará a cabo un proceso de
validación basado en test oracles, u oráculos de pruebas en su traducción al español. Estos
elementos se encargarán de, a partir de la información ofrecida por terceras partes (por
ejemplo, una serie de adaptadores para los elementos de la GUI), llevar a cabo el proceso
de validación para el que han sido diseñados. Más concretamente, se contempla la
posibilidad de incorporar tres tipos diferentes de oráculos: de estado (validan que el estado
actual de un elemento sea el mismo que uno previamente almacenado), de validación
(validan un conjunto de reglas especificada previamente por el operador), y de crash o
caída de la aplicación (comprueban si la aplicación ha caído por completo durante la
ejecución del caso de prueba).
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 16
Esta solución al completo evita el proceso costoso de tener que crear un modelo
complejo de la GUI y gran parte de las acciones inherentes a su creación, tales como la
verificación, corrección y mantenimiento del modelo, que en la mayoría de los casos
implican la intervención manual de las personas que componen el equipo de pruebas.
También destacar la solución propuesta al problema del criterio de cobertura, ya que en este
caso se evita la inclusión en los casos de prueba de los elementos y propiedades no
relevantes mediante la anotación de los elementos más representativos de la GUI. En este
caso se puede decir que el criterio de cobertura está dirigido por el usuario u operador. En
el lado opuesto también es necesario recordar que ya que el criterio de cobertura queda en
manos del operador, y con el objetivo de asegurar un proceso de pruebas completo, éste
tiene la obligación de realizar las anotaciones necesarias y suficientes para cubrir todo el
funcionamiento y espectro de posibles datos de entrada de la GUI.
Este método nos permite llevar a cabo un proceso de pruebas más ágil, con una
mayor escalabilidad y mejor tolerancia a modificaciones respecto a los enfoques centrados
en crear un modelo completo; esto se traduce en desarrollos más rápidos, ya que la
productividad de los activos aumenta. Este enfoque también permite llevar a cabo un
proceso de pruebas iterativo, sobre todo gracias a la posibilidad de reutilizar los casos de
uso y las anotaciones. El tamaño del fichero de pruebas puede ir creciendo a la vez que el
desarrollo avanza y las pruebas necesitan de un mayor refinamiento.
5. Evaluación de la Usabilidad en GUIs
Recientemente, los esfuerzos sobre la arquitectura Open HMI Tester están siendo
trasladados hacia otro tipo de pruebas software, más enfocadas hacia la evaluación de la
usabilidad de las interfaces gráficas de usuario. De acuerdo a la norma ISO 9241 [6], la
usabilidad puede ser vista como “la medida con la que un producto puede ser utilizado por
ciertos usuarios con el fin de conseguir sus objetivos con efectividad, eficiencia y
satisfacción, en un contexto de uso específico”. Una de las principales motivaciones es que,
hasta hace unos años, las investigaciones sobre la evaluación de la usabilidad en el software
han estado algo abandonadas, abarcando casi todo el protagonismo la evaluación de la
usabilidad en sitios web.
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 17
La idea principal es utilizar todo el potencial de la arquitectura Open HMI Tester
(principalmente la introspección no intrusiva en código) para poder implementar
herramientas que permitan automatizar los diferentes procesos de evaluación de la
usabilidad. Sin embargo, se cree necesario dotar a la arquitectura de una mayor genericidad
con el objetivo de no restringir el funcionamiento general a un proceso de grabación de
eventos y a otro de reproducción. Este cambio permitiría al desarrollador añadir su propia
lógica de operación, convirtiendo así a la arquitectura Open HMI Tester en una arquitectura
con un propósito más general, y facilitando así la integración de este tipo de herramientas
en el proceso de desarrollo [7].
El hecho de que la lógica de aplicación pueda ser adaptada permite encapsular el
conocimiento de los expertos en usabilidad en la propia herramienta de pruebas, facilitando
así la automatización completa de los procesos de evaluación. Al mismo tiempo, esta
característica facilita la integración de los usuarios finales en el proceso de desarrollo, ya
que evita la coincidencia de éstos y los expertos durante la fase de análisis y evaluación.
6. Conclusiones y trabajos futuros
En este trabajo se han presentado algunas de las principales líneas de investigación y
desarrollo existentes en la actualidad en relación con los sistemas de pruebas para interfaces
gráficas. Se ha presentado la arquitectura Open HMI Tester, sobre la que se han diseñado y
desarrollado algunas herramientas destinadas a la realización de pruebas automáticas sobre
GUIs. Algunos de los ejemplos propuestos son las herramientas de captura y reproducción
y la generación automática de casos de prueba basada en anotaciones de los elementos de la
GUI. También se ha descrito un nuevo enfoque para generalizar la arquitectura con el
objetivo de aumentar el número de submódulos adaptables del OHT, donde destaca la
posibilidad de adaptar la propia lógica de la herramienta. Con este nuevo enfoque más
general se pretende ampliar el abanico de utilidades que pueden desarrollarse sobre esta
arquitectura, como por ejemplo herramientas para la evaluación de la usabilidad de un
software.
Actualmente se está diseñando una nueva arquitectura más general que permita
implementar sobre ella un número mayor de herramientas para las pruebas de software.
También se está trabajando para poder hacer realidad algunas de las cuestiones que se
Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 4, 2009
ISSN: 1885-4486 © ATI, 2009 18
presentan en este trabajo, y que hasta ahora son simples ideas en proceso de maduración,
como por ejemplo el desarrollo de una serie de prototipos de herramientas para la
evaluación de la usabilidad en las aplicaciones software. Por último, también se está
trabajando en otros usos paralelos de la arquitectura, como por ejemplo la posibilidad de
extender las pruebas de GUI hacia la lógica de aplicación, o utilizar la arquitectura OHT
como un elemento independiente para la validación de propiedades y datos de entrada,
siguiendo así la filosofía de la programación orientada a aspectos.
Agradecimientos
Este trabajo ha sido parcialmente financiado por la Cátedra SAES de la Universidad de
Murcia. Este acuerdo engloba un esfuerzo conjunto entre la empresa SAES (Sociedad
Anónima de Electrónica Submarina, http://www.electronica-submarina.com/) y la
Universidad de Murcia, para trabajar en software de código abierto y en sistemas de tiempo
real y aplicaciones críticas.
Referencias
[1] Mateo Navarro, P., Martínez Pérez, G., Sevilla Ruiz, D., “OpenHMI-Tester: An Open
and Cross-Platform Architecture for GUI Testing and Certification”, International
Journal of Computer Systems Science and Engineering (IJCSSE), Special Issue on
Open Source Certification, in press.
[2] Nasika, R., Dasgupta, P., “Transparent Migration of Distributed Communicating
Processes”, 13th ISCA International Conference on Parallel and Distributed
Computing Systems (PDCS), Las Vegas (Nevada, USA), November 2000.
[3] Memon, A., Soffa, M., Pollack, M., “Coverage Criteria for GUI Testing”, ESEC/FSE-
9: Proceedings of the 8th European software engineering conference held jointly with
9th ACM SIGSOFT international symposium on Foundations of software engineering,
pp. 256-267, New York (USA), 2001.
[4] Mateo Navarro, P., Sevilla Ruiz, D., Martínez Pérez, G., “Automated GUI Testing
Validation guided by Annotated Use Cases”, Informatik 2009: Model-based Testing
(MoTes09) - 4th Workshop in conjunction with the annual national conference of
German Assoc. for Informatics (GI), Lübeck (Germany), September 2009.
[5] Xie, Q., Memon, A.M., “Designing and Comparing Automated Test Oracles for GUI-
Based Software Applications”, ACM Transactions on Software Engineering and
Methodology, 16, 1, Article 4, 2007.
[6] International Organization for Standardization, “ISO 9241-11 – Guidance on
usability”, 1998.
[7] Ferré, X., Juristo, N., “How to Integrate Usability into the Software Development
Process”, ACM: 28th International Conference on Software Engineering (ICSE 2006),
Shanghai, China, May 2006.
Thesis
Full-text available
1 Introduction 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Human-Computer Interaction . . . . . . . . . . . . . . . . . . . . 2 1.1.2 Software Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.3 Data Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.4 Software Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1.5 Quality of Experience . . . . . . . . . . . . . . . . . . . . . . . . . 10 Enhancing Software Quality . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.1 Block 1: Achieving Quality in Interaction Components Separately . 12 1.2.2 Block 2: Achieving Quality of User-System Interaction as a Whole . 14 1.3 Goals of this PhD Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.4 Publications Related to this PhD Thesis . . . . . . . . . . . . . . . . . . . . 19 1.5 Software Contributions of this PhD Thesis . . . . . . . . . . . . . . . . . . 22 1.5.1 OHT: Open HMI Tester . . . . . . . . . . . . . . . . . . . . . . . . 23 1.5.2 S-DAVER: Script-based Data Verification . . . . . . . . . . . . . . 24 1.5.3 PALADIN: Practice-oriented Analysis and Description of Multi-modal Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 CARIM: Context-Aware and Ratings Interaction Metamodel . . . . 25 1.6 Summary of Research Goals, Publications, and Software Contributions . . 25 1.7 Context of this PhD Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.8 Structure of this PhD Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2 Related Work 2.1 Group 1: Approaches Assuring Quality of a Particular Interaction Component 30 2.2 Validation of Software Output . . . . . . . . . . . . . . . . . . . . 30 2.1.1.1 Methods Using a Complete Model of the GUI . . . . . . 31 2.1.1.2 Methods Using a Partial Model of the GUI . . . . . . . . 32 2.1.1.3 Methods Based on GUI Interaction . . . . . . . . . . . . 32 Validation of User Input . . . . . . . . . . . . . . . . . . . . . . . . 33 2.1.2.1 Data Verification Using Formal Logic . . . . . . . . . . . 34 2.1.2.2 Data Verification Using Formal Property Monitors . . . . 35 2.1.2.3 Data Verification in GUIs and in the Web . . . . . . . . . 36 Group 2: Approaches Describing and Analyzing User-System Interaction as a Whole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.2.1 Analysis of User-System Interaction . . . . . . . . . . . . . . . . . 37 2.2.1.1 Analysis for the Development of Multimodal Systems . . 37 2.2.1.2 Evaluation of Multimodal Interaction . . . . . . . . . . . 41 2.2.1.3 Evaluation of User Experiences . . . . . . . . . . . . . . 44 Analysis of Subjective Data of Users . . . . . . . . . . . . . . . . . 45 2.2.2.1 User Ratings Collection . . . . . . . . . . . . . . . . . . 45 2.2.2.2 Users Mood and Attitude Measurement . . . . . . . . . . 47 Analysis of Interaction Context . . . . . . . . . . . . . . . . . . . . 49 2.2.3.1 Interaction Context Factors Analysis . . . . . . . . . . . 49 2.2.3.2 Interaction Context Modeling . . . . . . . . . . . . . . . 50 3 Evaluating Quality of System Output 3.1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2 GUI Testing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.3 Preliminary Considerations for the Design of a GUI Testing Architecture . 57 3.3.1 Architecture Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.3.2 Organization of the Test Cases . . . . . . . . . . . . . . . . . . . . 57 3.3.3 Interaction and Control Events . . . . . . . . . . . . . . . . . . . . 58 The OHT Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.4.1 The HMI Tester Module Architecture . . . . . . . . . . . . . . . . 60 3.4.2 The Preload Module Architecture . . . . . . . . . . . . . . . . . . . 61 3.4.3 The Event Capture Process . . . . . . . . . . . . . . . . . . . . . . 63 3.4.4 The Event Playback Process . . . . . . . . . . . . . . . . . . . . . . 64 The OHT Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.5.1 Implementation of Generic and Final Functionality . . . . . . . . . 66 3.5.1.1 Generic Data Model . . . . . . . . . . . . . . . . . . . . 66 3.5.1.2 Generic Recording and Playback Processes . . . . . . . . 66 Implementation of Specific and Adaptable Functionality . . . . . . 67 3.5.2.1 Using the DataModelAdapter . . . . . . . . . . . . . . . 68 3.5.2.2 The Preloading Process . . . . . . . . . . . . . . . . . . . 68 3.5.2.3 Adapting the GUI Event Recording and Playback Processes 69 3.7 Technical Details About the OHT Implementation . . . . . . . . . 70 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.6.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.6.2 The Test Case Generation Process . . . . . . . . . . . . . . . . . . 73 3.6.3 Validation of Software Response . . . . . . . . . . . . . . . . . . . 74 3.6.4 Tolerance to Modifications, Robustness, and Scalability . . . . . . . 75 3.6.5 Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 76 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4 Evaluating Quality of Users Input 4.1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.2 Practical Analysis of Common GUI Data Verification Approaches . . . . . 82 4.3 Monitoring GUI Data at Runtime . . . . . . . . . . . . . . . . . . . . . . . 83 4.4 Verification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.4.1 Rule Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.4.2 Using the Rules to Apply Correction . . . . . . . . . . . . . . . . . 87 4.4.3 Rule Arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.4.4 Rule Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.4.4.1 88 Loading the Rules . . . . . . . . . . . . . . . . . . . . . xviiContents 4.4.4.2 Evolution of the Rules and the GUI . . . . . . . . . . . . 89 Correctness and Consistency of the Rules . . . . . . . . . . . . . . 90 4.5 The Verification Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.6 S-DAVER Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.6.1 Architecture Details . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.6.2 Architecture Adaptation . . . . . . . . . . . . . . . . . . . . . . . . 94 4.7 S-DAVER Implementation and Integration Considerations . . . . . . . . . 95 4.8 Practical Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.8.1 Integration, Configuration, and Deployment of S-DAVER . . . . . 99 4.8.2 Defining the Rules in Qt Bitcoin Trader . . . . . . . . . . . . . . . 100 4.8.3 Defining the Rules in Transmission . . . . . . . . . . . . . . . . . . 103 4.8.4 Development and Verification Experience with S-DAVER . . . . . 106 4.9 Performance Analysis of S-DAVER . . . . . . . . . . . . . . . . . . . . . . 106 4.10 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.10.1 A Lightweight Data Verification Approach . . . . . . . . . . . . . 108 4.10.2 The S-DAVER Open-Source Implementation . . . . . . . . . . . . . 110 4.10.3 S-DAVER Compared with Other Verification Approaches . . . . . . 111 4.11 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5 Modeling and Evaluating Quality of Multimodal User-System Interaction 115 5.1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.2 A Model-based Framework to Evaluate Multimodal Interaction . . . . . . . 118 5.2.1 Classification of Dialog Models by Level of Abstraction . . . . . . 119 5.2.2 The Dialog Structure . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.2.3 Using Parameters to Describe Multimodal Interaction . . . . . . . 121 5.2.3.1 Adaptation of Base Parameters . . . . . . . . . . . . . . 121 5.2.3.2 Defining new Modality and Meta-communication Param- eters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.2.3.3 Defining new Parameters for GUI and Gesture Interaction 123 5.2.3.4 Classification of the Multimodal Interaction Parameters . 124 5.3 Design of PALADIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.4 Implementation, Integration, and Usage of PALADIN . . . . . . . . . . . . 129 5.5 Application Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 5.6 Assessment of PALADIN as an Evaluation Tool . . . . . . . . . . . 132 5.5.1.1 Participants and Material . . . . . . . . . . . . . . . . . 134 5.5.1.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.5.1.3 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . 137 Usage of PALADIN in a User Study . . . . . . . . . . . . . . . . . 140 5.5.2.1 Participants and Material . . . . . . . . . . . . . . . . . 140 5.5.2.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 144 5.5.2.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 5.6.1 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 146 5.6.2 Practical Application of PALADIN . . . . . . . . . . . . . . . . . . 147 5.6.3 Completeness of PALADIN According to Evaluation Guidelines . . 148 5.6.4 Limitations in Automatic Logging of Interactions Parameters . . . 151 5.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 5.8 Parameters Used in PALADIN . . . . . . . . . . . . . . . . . . . . . . . . . 152 6 Modeling and Evaluating Mobile Quality of Experience 163 6.1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 164 6.2 Context- and QoE-aware Interaction Analysis . . . . . . . . . . . . . . . . 166 6.2.1 Incorporating Context Information and User Ratings into Interaction Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 6.2.2 Arranging the Parameters for the Analysis of Mobile Experiences . 168 6.2.3 Using CARIM for QoE Assessment . . . . . . . . . . . . . . . . . . 169 Context Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 6.3.1 Quantifying the Surrounding Context . . . . . . . . . . . . . . . . 170 6.3.2 Arranging Context Parameters into CARIM . . . . . . . . . . . . . 173 User Perceived Quality Parameters . . . . . . . . . . . . . . . . . . . . . . 173 6.4.1 Measuring the Attractiveness of Interaction . . . . . . . . . . . . . 173 6.4.2 Measuring Users Emotional State and Attitude toward Technology Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 6.5 Arranging User Parameters into CARIM . . . . . . . . . . . . . . . 177 CARIM Model Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 6.5.1 The Base Design: PALADIN . . . . . . . . . . . . . . . . . . . . . 177 6.5.2 The New Proposed Design: CARIM . . . . . . . . . . . . . . . . . 178 6.6 CARIM Model Implementation . . . . . . . . . . . . . . . . . . . . . . . . 181 6.7 Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 6.7.1 Participants and Material . . . . . . . . . . . . . . . . . . . . . . . 183 6.7.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 6.7.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 6.9 Comparing the Two Interaction Designs for UMU Lander 185 Validating the User Behavior Hypotheses . . . . . . . . . 186 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 6.8.1 Modeling Mobile Interaction and QoE . . . . . . . . . . . . . . . . 188 6.8.3 CARIM Implementation and Experimental Validation . . . . . . . 190 CARIM Compared with Other Representative Approaches . . . . . 191 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 7 Conclusions and Further Work 7.2 Conclusions of this PhD Thesis . . . . . . . . . . . . . . . . . . . . . . . . 196 7.1.2 Driving Forces of this PhD Thesis . . . . . . . . . . . . . . . . . . 196 Work and Research in User-System Interaction Assessment . . . . 197 7.1.3 Goals Achieved in this PhD Thesis . . . . . . . . . . . . . . . . . . 200 Future Lines of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Bibliography 205 A List of Acronyms 231
Article
Full-text available
A Man-Machine Interface with the software Panel Builder 32, that interacts with Panel View 1000, to perform the control of the Pneumatics Station PN-2800 is presented. This station provides raw material to an Integrated Manufacturing Center. Visual programming was used and the dimensions of the cylindrical bars, acrylic parts and the gap of the gripers of the manipulators, as well as their angles and spaces of work to consider new raw material. For the configuration of the communication protocol Dates Highway Plus and the compatibility with the protocol Modbus Plus a converter DL-3500 was used. The work presented in this article shows the integration of new materials for the process of maquilado and the handling of different protocols that are found in different industries.
Conference Paper
This paper is a position paper of my PhD thesis: https://www.researchgate.net/publication/264194567_Enhancing_Software_Quality_and_Quality_of_Experience_through_User_Interfaces With this work we expect to provide the community and the industry with a solid basis for the development, integration, and deployment of software testing tools. As a solid basis we mean, on one hand, a set of guidelines, recommendations, and clues to better comprehend, analyze, and perform software testing processes, and on the other hand, a set of robust software frameworks that serve as a starting point for the development of future testing tools.
Article
Full-text available
Software testing is usually used to report and/or assure about the quality, reliability and robustness of a software in the given context or scenario where it is intended to work. This is specially true in the case of user interfaces, where the testing phase is critical before the software can be accepted by the final user and put in execution mode. This paper presents the design, and the later implementation as a contribution to the open-source community, of a Human-Machine Interface (HMI) testing architecture, named OpenHMI-Tester. The current design is aimed to support major event-based and open-source windowing systems, thus providing generality, besides some other features such as scalability and tolerance to modifications in the HMI design process. The proposed architecture has been also integrated as part of a complex industrial scenario, which helped to identify a set of realistic requirements of the testing architecture, as well as to test it with real HMI developers.
Conference Paper
Usability is increasingly recognized as a quality attribute that one has to explicitly deal with during development. Nevertheless, usability techniques, when applied, are decoupled from the software development process. The host of techniques offered by the HCI (Human-Computer Interaction) field make the task of selecting the most appropriate ones for a given project and organization a difficult task. Project managers and developers aiming to integrate usability practices into their software process have to face important challenges, as the techniques are not described in the frame of a software process as it is understood in SE (Software Engineering). Even when HCI experts (either in-house or from an external organization) are involved in the integration process, it is also a tough endeavour due to the strong differences in terminology and overall approach to software development between HCI and SE. In this tutorial we will present, from a SE viewpoint, which usability techniques can be most valuable to development teams with little or no previous usability experience, how a particular set of techniques can be selected according to the specific characteristics of the organization and project, and how usability techniques match with the activity groups in the development process.
Article
Test designers widely believe that the overall effectiveness and cost of software testing depends largely on the type and number of test cases executed on the software. This article shows that the test oracle, a mechanism that determines whether a software is executed correctly for a test case, also significantly impacts the fault detection effectiveness and cost of a test case. Graphical user interfaces (GUIs), which have become ubiquitous for interacting with today's software, have created new challenges for test oracle development. Test designers manually “assert” the expected values of specific properties of certain GUI widgets in each test case; during test execution, these assertions are used as test oracles to determine whether the GUI executed correctly. Since a test case for a GUI is a sequence of events, a test designer must decide: (1) what to assert; and (2) how frequently to check an assertion, for example, after each event in the test case or after the entire test case has completed execution. Variations of these two factors significantly impact the fault-detection ability and cost of a GUI test case. A technique to declaratively specify different types of automated GUI test oracles is described. Six instances of test oracles are developed and compared in an experiment on four software systems. The results show that test oracles do affect the fault detection ability of test cases in different and interesting ways: (1) Test cases significantly lose their fault detection ability when using “weak” test oracles; (2) in many cases, invoking a “thorough” oracle at the end of test case execution yields the best cost-benefit ratio; (3) certain test cases detect faults only if the oracle is invoked during a small “window of opportunity” during test execution; and (4) using thorough and frequently-executing test oracles can compensate for not having long test cases.
Article
The widespread recognition of the usefulness of graphical user interfaces (GUIs) has established their importance as critical components of today's software. GUIs have characteristics different from traditional software, and conventional testing techniques do not apply directly to GUI software. This paper's focus is on coverage criteria for GUIs, an important tool in testing. We present new coverage criteria that may be employed to help determine whether a GUI has been adequately tested. These coverage criteria use events and event sequences to specify a measure of test adequacy. Since the total number of permutations of event sequences in any non-trivial GUI is extremely large, the GUI's hierarchical structure is exploited to identify the important event sequences to be tested. The GUI's hierarchy is decomposed into GUI components each of which is used as a basic unit of testing. A new representation of a GUI component, called an event-flow graph, identifies the interaction of events within a component and intra-component criteria are used to evaluate the adequacy of tests on these events. The hierarchical relationship among components is represented by an integration tree and inter-component coverage criteria are used to evaluate the adequacy of test sequences that cross components. Algorithms are described to construct event-flow graphs and an integration tree for a given GUI, and to evaluate the coverage of a given test suite with respect to the new coverage criteria. A case study illustrates an important correlation between event-based coverage of a GUI and statement coverage of the software's underlying code. Partially supported by the Andrew Mellon Pre-doctoral Fellowship. Effective Aug 1, 2001: Department of Computer Science, University of Maryland. atif@cs.um...
Article
A Computing Community is a group of cooperating machines that behave like a single system and runs all general-purpose applications---without any modifications to the shrink-wrapped binary applications or the operating system. In order to realize such a system, we inject a wrapper DLL into an application at runtime that manages the execution of the application and endows it with features such as virtualization and mobility. This paper describes the concept of virtualization, and the mechanism of injection and the implementation of a wrapper DLL. We focus on one kind of applications, those that use sockets to communicate with other processes. We show how these processes can migrate between machines without disrupting the socket communications. We have implemented the software that needs to be injected into the application to enable this feature. Handling more application types is part of the continued research in the Computing Communities project. 1. Introduction The ...
ISO 9241-11 – Guidance on usability
International Organization for Standardization, " ISO 9241-11 – Guidance on usability ", 1998.
Transparent Migration of Distributed Communicating Processes
  • R Nasika
  • P Dasgupta
Nasika, R., Dasgupta, P., "Transparent Migration of Distributed Communicating Processes", 13th ISCA International Conference on Parallel and Distributed Computing Systems (PDCS), Las Vegas (Nevada, USA), November 2000.