Mtodo de pruebas de sistema basado e en modelos navegacionales en un contexto MDWE

Arturo Henry Torres Zenteno, NIE: X08100347-T arturoh.torres.exts@juntadeandalucia.es

Supervisado por la Profa. Dra. Mar Jos Escalona Cuaresma y a e el Prof. Dr. Manuel Mej Risoto as

Memoria de investigacin presentada al Departamento de Lenguajes o y Sistemas Informticos de la Universidad de Sevilla, en cumplimiento a parcial de los requisitos para obtener el Diploma Avanzado de Estudios. (Proyecto de Tesis)

 Indice general
Indice general Indice de guras Indice de tablas 1 Introduccin o 1.1 Importancia de la navegacin y los modelos navegacionales o 1.2 Importancia de las pruebas de software . . . . . . . . . . . . 1.3 Las pruebas de software basadas en modelos . . . . . . . . . 1.3.1 El proceso de desarrollo de software . . . . . . . . . 1.3.1.1 Pruebas de sistema . . . . . . . . . . . . . . . . . . 1.3.2 Desarrollo de pruebas basadas en modelos . . . . . . 1.3.2.1 Mtodos de prueba de caja negra . . . . . . . . . . e 1.3.2.2 Mtodos de prueba de caja blanca . . . . . . . . . . e 1.4 Model-Driven Web Engineering (MDWE) . . . . . . . . . . 1.4.1 Transformacin de modelos . . . . . . . . . . . . . . o 1.4.2 Aplicando MDA para modelar pruebas . . . . . . . . 2 Estudio de la situacin actual o 2.1 Las pruebas de software: actuales desaf . . . . . os 2.1.1 ROADMAP . . . . . . . . . . . . . . . . . . 2.1.2 Desaf 1: Orculos de pruebas . . . . . . . o a 2.1.3 Desaf 2: Pruebas 100 % automticas . . . o a 2.1.4 Desaf 3: Pruebas basadas en modelos . . . o 2.2 Trabajos Relacionados sin enfoque MDA . . . . . . 2.2.1 Pruebas basadas en modelos . . . . . . . . 2.2.2 Pruebas basadas en modelos navegacionales 2.3 Trabajos Relacionados con enfoque MDA . . . . . 2.3.1 Visin general terica . . . . . . . . . . . . o o 2.3.1.1 Transformaciones . . . . . . . . . . . . . . 2.3.1.2 UML 2.0 Testing Prole (U2TP) . . . . . . 2.3.1.3 TTCN-3 y su Meta-modelo . . . . . . . . . 2.3.2 Propuestas empresariales . . . . . . . . . . i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I III V

3 5 6 7 7 10 11 11 12 13 15 16 19 20 21 22 24 25 27 27 28 28 29 29 30 32 33

ii

INDICE GENERAL 2.3.2.1 Objecteering Software . . . . . . . . . . . . . . . . . . 2.3.2.2 Test Designer v3.3 . . . . . . . . . . . . . . . . . . . . 2.3.2.3 Telelogic TAU Generation . . . . . . . . . . . . . . . 2.3.3 Propuestas acadmicas . . . . . . . . . . . . . . . . . . e 2.3.3.1 Model-Driven Testing with UML 2.0 . . . . . . . . . 2.3.3.2 From U2TP Models to executable tests with TTCN-3 2.3.3.3 Pruebas dirigidas por modelos usando U2TP . . . . . Discusin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 33 38 38 39 42 44 47 51 51 52 53 53 53 53 54 56 56 57 58 59 61 69 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 71 71 71 72 73

2.4

3 Proyecto de investigacin o 3.1 Hiptesis y objetivos . . o 3.1.1 Objetivo 1 . . . . 3.1.2 Objetivo 2 . . . . 3.1.3 Objetivo 3 . . . . 3.1.4 Objetivo 4 . . . . 3.1.5 Objetivo 5 . . . . 3.2 Metodolog de trabajo. a 3.3 Plan de trabajo . . . . 3.3.1 Journals . . . . . 3.3.2 Congresos . . . . 3.3.3 Workshops . . . 4 Conclusiones Bibliograf a A Glosario

B Curriculum vitae B.1 Formacin acadmica . . . . o e B.2 Experiencia profesional . . . B.3 Proyectos de investigacin . o B.4 Otras actividades relevantes C Trabajos publicados

 Indice de guras
1.1 1.2 1.3 1.4 1.5 1.6 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 3.1 3.2 3.3 3.4 Modelo V - Fases de prueba en un proceso de desarrollo. El modelo W. . . . . . . . . . . . . . . . . . . . . . . . . Estructura MDA para Ingenier Web [41]. . . . . . . . a Capas M2 y M3 de la Arquitectura 4 capas. . . . . . . . Modelado de sistemas basados en MDA. . . . . . . . . . Modelado de pruebas basados en MDA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10 14 16 16 17 23 30 36 37 37 38 40 41 42 44 46 46 52 54 55 56

Roadmap de las pruebas de software [9]. . . . . . . . . . . . . . . Modelos de Diseo del Sistema vs. Modelos de Diseo de Pruebas. n n Arquitectura en Objecteering Software [79]. . . . . . . . . . . . . Pantalla de modelado en Objecteering Software [79]. . . . . . . . Fases de prueba de Test Designer [90]. . . . . . . . . . . . . . . . Pantalla de modelado en Test Designer [90]. . . . . . . . . . . . . Transformacin basada en meta-modelos [20]. . . . . . . . . . . . o Transformacin de componentes de prueba. . . . . . . . . . . . . o Transformacin de U2TP a TTCN-3 [94]. . . . . . . . . . . . . . o Transformacin PIT/PST en U2TP para pruebas en TTCN-3 [94]. o Extensin al meta-modelo de UML para las pruebas [63]. . . . . o Informacin para el orculo segn el nivel de prueba [63]. . . . . o a u Propuesta de investigacin. . . . . . . . . . . . . . . . . . o Mtodos de investigacin: (A) de ingenier (B) emp e o a; rico. Metodolog de investigacin aplicada en la propuesta. . . a o Planicacin del proyecto de investigacin. . . . . . . . . . o o . . . . . . . . . . . . . . . .

iii

iv

INDICE DE FIGURAS

 Indice de tablas
1.1 2.1 2.2 2.3 2.4 Fases de prueba en el proceso de desarrollo de software. . . . . . Conceptos U2TP. . . . . . . . . . . . . . . . . . . . . . . . . . . . Relacin entre U2TP y los elementos del meta-modelo TTCN-3. o Tabla comparativa de herramientas orientadas a modelos. . . . . Cuadro de oportunidades. . . . . . . . . . . . . . . . . . . . . . . 9 32 34 35 48

vi

INDICE DE TABLAS

Agradecimientos
A Dios, que siempre ha colocado a las personas idneas en mi camino. o A mi amada familia, Cecilia y Sebastin, por todo el apoyo, motivacin y a o comprensin que siempre recibo de parte de ellos. o A mis queridos padres, Ricardo y Juana, por todo su empeo y esfuerzo n infatigable para darme la educacin que siempre anhelaron. o Deseo dar un agradecimiento especial a Mar Jos Escalona, quien me a e abri la senda para continuar mis estudios de posgrado en la Universidad de o Sevilla. Y ella junto a Manuel Mej han sido un apoyo constante y valioso en as la redaccin de esta memoria de investigacin. o o Tambin agradezco a la familia everis por abrirme las puertas y permitir ame pliar mi experiencia en el mundo laboral. Y especialmente, a Gustavo Aragn, o Javier Mar y Rafael Ordoez, quienes adems de darme capacitacin profen n a o sional, siempre me han dado la compresin y facilidad necesarias para poder o congeniar el trabajo con los estudios de doctorado.

vii

viii

INDICE DE TABLAS

Resumen
Las aplicaciones Web emplean una serie de nuevos lenguajes, tecnolog y as, modelos de programacin, que se utilizan para implementar aplicaciones altao mente interactivas que presentan un alto nivel de calidad exigido. Analizar, modelar y probar estas aplicaciones presenta nuevos desaf para os desarrolladores e investigadores de software. Con el n de incrementar la seguridad y la abilidad de una aplicacin Web, o las pruebas son uno de los mtodos ms ecaces. Sin embargo, investigadores y e a profesionales todav estn tratando de encontrar formas efectivas para modelar a a y probar aplicaciones Web. Basado en el estudio de la situacin actual, este proyecto de investigacin o o propone una tcnica de pruebas de nivel de sistema a partir de modelos navee gacionales. El aspecto ms novedoso es la propuesta de generar casos de prueba a de sistema a partir de modelos navegacionales mediante el paradigma MDWE (Model-Driven Web Engineering). De esta manera, las pruebas sern generadas a antes de la implementacin del software, y los problemas podrn ser eliminao a dos tempranamente, ahorrando tiempo, recursos, y sobretodo aumentando la abilidad del software. Adems, se propone la construccin de una herramienta que sirva para la a o automatizacin de todo el proceso. o

INDICE DE TABLAS

Cap tulo 1

Introduccin o
La creciente complejidad de las aplicaciones Web ha causado que el campo de la Ingenier Web, denida como la aplicacin sistemtica, disciplinada y a o a cuanticable de aproximaciones para el desarrollo y evolucin eciente de aplio caciones de alta calidad en la World Wide Web [33] se haya desarrollado de manera muy acelerada. Desafortunadamente, dicha complejidad no parece estar acompaada de los n mecanismos adecuados que garanticen la calidad de unos sistemas de los que cada d existe mayor dependencia a nivel social, funcional y econmico. a o Esta carencia de calidad ha venido generando una preocupacin creciente o entre la comunidad cient ca y empresarial involucrada en el desarrollo Web. As pues, en los ultimos aos surgen varias iniciativas con el objetivo de denir n marcos de referencia adecuados a estas nuevas tendencias de creacin de softo ware. La Ingenier Web surge, debido a este crecimiento desenfrenado que a est teniendo la Web, con el objetivo de otorgar los medios necesarios para a mejorar el desarrollo de este tipo de aplicaciones. Es en el mbito de la Ingenier Web donde se ha evaluado la necesidad de a a estudiar de manera concreta una caracter stica del software, que, en los ultimos aos, est denindose como cr n a e tica dentro del proceso de desarrollo: la naveo tico, complejo y que gacin [18]. La navegacin se plantea como un aspecto cr o hay que tratar con especial inters dentro del mundo de los sistemas navegae cionales. La navegacin es la caracter o stica del software que permite estructurar cmo o se desea mostrar la informacin al usuario y poner a su disposicin la funcionalio o dad de una manera adecuada a sus necesidades, ofreciendo, adems, un sistema a oportuno y sencillo para acceder a todo ello mediante estructuras navegacionales complejas y avanzadas. La necesidad del tratamiento adecuado de la navegacin en la Ingenier o a Web, ha sido una de las caracter sticas que ha llevado a diversos grupos de investigacin a proponer nuevos modelos y tcnicas adecuadas para su tratamiento. o e Consciente de tales benecios, se ha comenzado a invertir esfuerzos en la inclusin de medidas que gu la construccin de los diferentes modelos hipermeo en o 3

CAP ITULO 1. INTRODUCCION

diales que componen las distintas propuestas. En ellas, el modelo navegacional juega un papel preponderante, ya que la navegabilidad de una aplicacin Web o est relacionada con caracter a sticas de calidad como la usabilidad, la mantenibilidad, etc. [1][58][59][56], y por lo tanto contribuye al xito de implantacin de e o la aplicacin [58]. o El contexto de este trabajo se centra en asegurar el xito de estas implantae ciones. Para asegurar la calidad del software, la tcnica de pruebas es uno de los e mtodos ms ecaces. Entres los niveles de prueba existentes, las pruebas de sise a tema son de nuestro inters porque permiten probar y vericar el cumplimiento e de los requisitos de negocio de la aplicacin. Es as que, nuestra propuesta se o enfoca en las pruebas de sistema de las aplicaciones Web basadas en los modelos navegacionales, por la importancia expuesta de este tipo de aplicaciones. Por otro lado, existen diversas propuestas metodolgicas para el desarrollo de o aplicaciones Web, en donde el modelado de la navegacin suele ser dependiente o de la metodolog utilizada. La propuesta de nuestro trabajo pretende ser genria e ca; es decir, realizar las pruebas de sistema basados en modelos navegacionales independientemente de la metodolog escogida. Para conseguir tal objetivo, nos a enfocamos en el paradigma guiado por modelos (MDWE), en donde los modelos reemplazan el cdigo como artefactos primarios en el proceso de desarrollo del o software, y adems es posible la denicin de metamodelos, los cuales permiten a o generalizar modelos. Las siguientes subsecciones introductorias ampl y presentan la importanan cia de los conceptos relevantes para nuestra propuesta. Primero, en la subseccin o 1.1 se presenta la importancia de la navegacin y los modelos navegacionales. o De igual forma, en la subseccin 1.2 se presenta la importancia de las pruebas o de software en el desarrollo de software. Esto sirve como prembulo para que a en la subseccin 1.3 se presente la forma en que se desarrollan las pruebas de o software basadas en modelos. Finalmente la seccin 1.4 se presenta el paradigma o MDWE y cmo son realizadas las pruebas mediante este paradigma. o Terminado este cap tulo introductorio, el cap tulo 2 presenta un estudio del estado del arte de las pruebas del software, identicando las propuestas existentes y las ms importantes relacionadas con las pruebas de software para a aplicaciones Web. Las propuestas ms relevantes, relacionadas con el proyecto a de investigacin, se presentan en tres categor las pruebas Web basadas en o as: modelos, las pruebas Web basadas, espec camente, en modelos navegacionales y las pruebas basadas en el paradigma de transformacin de modelos. El cap o tulo termina con un anlisis de las propuestas, identicando las oportunidades a de investigacin que son la base para nuestra propuesta. Seguidamente, en el o cap tulo 3 se describe nuestra hiptesis de partida con los objetivos trazados o para el desarrollo del proyecto de tesis. Tambin se describe, de manera genee ral, la metodolog de trabajo y la planicacin del proyecto. Finalmente, la a o memoria de investigacin termina presentando las conclusiones. o

 1.1. IMPORTANCIA DE LA NAVEGACION Y LOS MODELOS NAVEGACIONALES5

1.1.

Importancia de la navegacin y los modelos o navegacionales

La navegacin implica mostrar una determinada visin de la informacin o o o almacenada en el sistema. Los sistemas manejan y gestionan una informacin o que es presentada de manera adecuada durante la navegacin del usuario por el o sistema. La navegacin implica tambin la idea de movimiento. En este sentido, cuano e do se presenta una determinada informacin al usuario, tambin se le ofrece una o e serie de destinos posibles donde se puede dirigir o navegar a partir del punto en el que se encuentra. Esta idea de movimiento unida a la idea de visin de la o informacin, es lo que se dene como hiperespacio: un rea que marca el mbito o a a de la aplicacin estructurada mediante zonas estticas que se pueden navegar o a para conseguir la informacin necesaria. o Pero la navegacin implica otros elementos ms. Por un lado la adaptabio a lidad al entorno. En un sistema navegacional es necesario adaptar el entorno de navegacin a la situacin concreta. As si el usuario se encuentra en un o o , punto determinado, se pueden abrir diferentes posibilidades de navegacin deo pendiendo desde dnde se haya venido y del tipo de usuario que est conectado: o e un sistema navegacional puede cambiar dependiendo del usuario que en cada momento interacte con el sistema [86]. u La navegacin tambin est relacionada con el concepto de la funcionalio e a dad. Las posibilidades funcionales del sistema deben ofrecerse al usuario en el momento preciso y adecuado a lo largo de su visita por el sistema. Aunque no existe una denicin estndar de navegacin, nos podemos quedar o a o o sticon la denicin de Escalona [27], ella indica que la navegacin es la caracter o ca del software que permite estructurar cmo se desea mostrar la informacin al o o usuario y poner a su disposicin la funcionalidad de una manera adecuada a sus o necesidades, ofreciendo, adems, un sistema oportuno y sencillo para acceder a a todo ello mediante estructuras navegacionales complejas y avanzadas. La necesidad del tratamiento adecuado de la navegacin en la Ingenier o a Web, ha sido una de las caracter sticas que ha llevado a diversos grupos de investigacin a proponer nuevos modelos y tcnicas adecuadas para su tratamiento o e [1] [18] [45]. Consciente de tales benecios, se ha comenzado a invertir esfuerzos en la inclusin de medidas que gu la construccin de los diferentes modeo en o los hipermediales que componen las distintas propuestas. En ellas, el modelo navegacional juega un papel preponderante. Las metodolog de desarrollo Web proponen estructurar el proceso de deas sarrollo en una serie de fases. Diferentes mtodos incluyen distintas etapas, pero e un anlisis de todos ellos muestra que siempre estn presentes, con uno u otro a a nombre los siguientes: modelado conceptual, modelo navegacional, modelo de la presentacin. o El modelado conceptual tiene como objetivo obtener un modelo del dominio del problema; en algunos mtodos (como OOHDM [70], UWE [40] y NDT [27]) e el modelo es orientado a objetos, y en otros (HDM [29], RMM [35] y WebML

CAP ITULO 1. INTRODUCCION

[19]) el modelo es relacional. En el diseo navegacional se obtiene un moden lo navegacional a partir del modelo conceptual usando heur sticas. El modelo navegacional es comnmente denido como una vista del modelo conceptual que u reeja la informacin accesible a un usuario, y los caminos y estructuras de aco ceso para llegar a ella [76]. El modelo de la presentacin trata de la construccin o o de la interfaz que muestran los elementos navegacionales al usuario, y se efecta u mediante interfaces abstractas de usuario. El modelo navegacional es el que marca la diferencia ms importante entre a las metodolog de desarrollo de software convencional y las metodolog de as as desarrollo Web. El modelo de navegacin representa principalmente tres aspectos imporo tantes: 1. Cmo se va a poder navegar a travs de la informacin conceptual, por o e o lo que realmente el modelo navegacional va a ser una vista del modelo conceptual. 2. Qu elementos (informacin, funcionalidad, posibilidades de navegacin, e o o etc.) van a aparecer en esa navegacin y cmo se van a adaptar al usuario o o que interacta con el sistema. u 3. Las relaciones que aparecen entre dichos elementos de la navegacin. o El modelo navegacional juega un papel preponderante, ya que la navegabilidad de una aplicacin Web est relacionada con caracter o a sticas de calidad como la usabilidad, la mantenibilidad, etc. [1][58][59][56], y por lo tanto contribuye al xito de implantacin de la aplicacin Web [58]. e o o El contexto de esta propuesta se centra en asegurar el xito de estas ime plantaciones. Para ello, la tcnica de pruebas de software es uno de los mtodos e e ms ecaces. a

1.2.

Importancia de las pruebas de software

El desarrollo de sistemas de software implica una serie de actividades de produccin en las que las posibilidades de que aparezca el fallo humano son o enormes. Los errores pueden empezar a darse desde el primer momento del proceso, en el que los objetivos pueden estar especicados de forma errnea o o imperfecta, as como en posteriores pasos de diseo y desarrollo. Debido a la n imposibilidad humana de trabajar y comunicarse de forma perfecta, el desarrollo de software ha de ir acompaado de una actividad que garantice la calidad [24]. n Las pruebas del software son un elemento cr tico para la garant de calidad a del software y representa una revisin nal de las especicaciones, del diseo y o n de la codicacin. La creciente percepcin del software como un elemento del o o sistema y la importancia de los costes asociados a un fallo del propio sistema, estn motivando la creacin de pruebas minuciosas y bien planicadas. a o No es raro que una organizacin de desarrollo de software emplee entre el o 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas [62]. En

1.3. LAS PRUEBAS DE SOFTWARE BASADAS EN MODELOS

casos extremos, las pruebas del software para actividades cr ticas; por ejemplo, control de trco areo y el control de reactores nucleares, puede costar de tres a e a cinco veces ms que el resto de los pasos de la ingenier del software juntos. a a La prueba es un elemento cr tico para la calidad del software. La importancia de los costes asociados a los errores, promueve la denicin y aplicacin de un o o proceso de pruebas minuciosas y bien planicadas. Las pruebas permiten validar y vericar el software, entendiendo como validacin del software el proceso que o determina si el software satisface los requisitos, y vericacin como el proceso o que determina si los productos de una fase satisfacen las condiciones de dicha fase. Las estrategias de pruebas permiten enfocar el plan de pruebas; ste come prende la visin global del proceso de pruebas, y la denicin de actividades y o o los roles involucrado en cada una de ellas.

1.3.

Las pruebas de software basadas en modelos

Las pruebas basadas en modelos son denidas como las pruebas de software donde los casos de pruebas son derivados en todo o en parte de un modelo que describe algunos, si no todo, aspectos del sistema bajo prueba. El sistema bajo prueba puede ser algo tan simple como un mtodo o una clase, o tan complejo e como un sistema completo o una solucin compuesta de mltiples sistemas. o u Para este tipo de pruebas, un modelo proporciona una descripcin del como portamiento del sistema bajo prueba (SUT). Esta descripcin puede ser proceo sada para obtener un conjunto de casos de prueba, los cuales se pueden utilizar para determinar si el sistema bajo prueba se ajusta a una propiedad que est rea presentada en el modelo. En esta seccin, se identica las fases en el proceso de o desarrollo de software donde los modelos diseados y se describen los principios n del desarrollo de las pruebas basadas en modelos.

1.3.1.

El proceso de desarrollo de software

La literatura distingue diferentes procesos de desarrollo de software. Como ejemplos de algunos procesos segn el ciclo de vida tenemos, el modelo de casu cada, el modelo de espiral [91], el proceso unicado [2], el modelo V [77], y el modelo W [37]. En todos estos procesos, el software es desarrollado en fases. La mayor de los procesos tienen fases similares y dieren principalmente en las a condiciones y posibilidades para avanzar hacia la prxima fase o volver a visitar o la fase anterior. Una caracter stica de los modelos V y W es que presentan una visin integrada de la construccin y de las fases correspondientes de pruebas. o o En este caso, se usarn los modelos V y W para explicar las pruebas basadas a en modelos y el rol que cumple UML Testing Prole (UTP) en el proceso de desarrollo de software. La estructura del modelo V es mostrado en la Figura 1.1. El modelo V distingue las fases de construccin (el lado izquierdo de la gura) y las fases de o

CAP ITULO 1. INTRODUCCION

Figura 1.1: Modelo V - Fases de prueba en un proceso de desarrollo. pruebas (lado derecho de la gura). El desarrollo del sistema comienza con la captura y denicin de los requisio tos. Los requisitos son capturados del cliente y de los futuros usuarios. Ellos son usados en la siguiente fase para desarrollar los modelos funcionales del sistema. Los modelos funcionales deben ser independientes de la futura implementacin o del sistema, para evitar decisiones tempranas de diseo. n La arquitectura del software es modelada en la fase de Diseo y Arquitectura n (vea Figura 1.1). Esta fase dene la estructura del sistema en componentes, y, a la vez, dene las interfaces correspondientes. Seguidamente, el comportamiento detallado de los componentes es denido en la fase de Diseo Detallado. Finaln mente, las fases de construccin del modelo V terminan con la implementacin o o de los componentes. La implementacin de los componentes es la base para las fases de pruebas. o En el nivel de pruebas unitarias, las implementaciones de los componentes son probados en base a sus especicaciones. En el siguiente nivel, las pruebas de nivel de integracin son usadas para probar la integracin de los componentes o o nalizados. La fase de pruebas de integracin termina cuando todos los compoo nentes son integrados. Las pruebas de sistema es la primera prueba cuando el sistema completo est disponible y la funcionalidad completa es probada. La base para las pruebas a de nivel de sistema es el diseo de la funcionalidad del sistema. Las pruebas de n nivel de aceptacin son similares a las pruebas de nivel de sistema, pero estn o a puramente basadas en las perspectiva del cliente y de los futuros usuarios. Por ultimo, las pruebas de regresin son realizadas cuando el sistema est im o a

1.3. LAS PRUEBAS DE SOFTWARE BASADAS EN MODELOS Prueba Pruebas unitarias Pruebas de integracin o Descripcin o Prueban el diseo y el comportamiento de can da componente del sistema una vez construido Prueban la correcta relacin entre los compoo nentes del sistema a travs de sus interfaces y e si ellas cumplen con la funcionalidad establecida Prueban el sistema comprobando su funcionalidad y atributos de calidad. El sistema es probando en un ambiente lo ms parecido a posible al ambiente operacional Evalan que el sistema cumple con todos los u requisitos indicados y permite que los usuarios del sistema provean su aceptacin o El objetivo es comprobar que los cambios sobre un componente del sistema no generan errores adicionales en otros componentes no modicados

Pruebas de sistema

Pruebas de aceptacin o

Pruebas de regresin o

Tabla 1.1: Fases de prueba en el proceso de desarrollo de software. plantado, y al realizarse un mantenimiento debe de probarse que no existan efectos colaterales con las modicaciones realizadas. o En [16] se presenta una recopilacin de los niveles de prueba, y lo podemos resumir en la Tabla 1.1. A pesar de que el modelo V sugiere un procedimiento donde las fases de pruebas son ejecutadas despus de las fases de construccin, es conocido que e o la preparacin de cada fase de prueba deber comenzar tan pronto como sea o a posible, es decir, en paralelo con la correspondiente fase de construccin. Esto o permite un feedback temprano respecto a la fase de pruebas. El modelo W, ilustrado en la Figura 1.2, es un renamiento del modelo V. En el lado izquierdo del modelo W, las fases de construccin estn estruco a turadas en dos conjuntos de tareas: las tareas relacionadas con las fases de construccin y las tareas de preparacin (plan de pruebas) para cada fase coo o rrespondiente. Las echas presentes entre la ejecucin de la prueba (en cada fase de prueo ba), el debugging, y la implementacin (codicacin) describen la correccin o o o iterativa de errores. Es decir, si una prueba detecta un fallo, el debugging es utilizado para localizarlo. Una vez localizado el fallo se procede a su correccin, o lo que signica un cambio en la implementacin del software. Al ser cambiada o la implementacin, la prueba tiene que ser ejecutada nuevamente. o Un aspecto fundamental del proceso de prueba es evaluar el sistema completo y la satisfaccin de la especicacin funcional o requisitos por parte del o o sistema construido, es decir, las pruebas de nivel de sistema. Debido a esta im-

10

CAP ITULO 1. INTRODUCCION

Figura 1.2: El modelo W. portancia, nuestro inters se centra en este nivel de prueba y adems porque e a es necesario vericar la correcta y completa implantacin de los requisitos en o las fases tempranas del desarrollo [32]. En el prximo apartado se presentan o las caracter sticas e importancia de este nivel de prueba en el contexto de esta propuesta, las aplicaciones Web. 1.3.1.1 Pruebas de sistema La Web est ocasionando un impacto en la sociedad y el nuevo manejo que a se le est dando a la informacin en las diferentes reas en que se presenta, ha a o a hecho que las personas tiendan a realizar todas sus actividades por esta v a. El incremento de la complejidad de este tipo de sistemas incrementa a su vez la necesidad de asegurar su calidad. La fase de pruebas del sistema ayuda a asegurar la calidad del software. Las pruebas del sistema tienen como objetivo vericar la funcionalidad del sistema a travs de sus interfaces externas, comprobando que dicha funcionalie dad sea la esperada en funcin de los requisitos del sistema [32]. o La mayor de las pruebas en la industria se desarrolla a nivel del sistema. a Sin embargo, muchas tcnicas de prueba del sistema estn descritas slo de e a o manera informal. Adems, la fase de prueba del sistema suele realizarse al nal a del proceso de desarrollo, por lo que estas pruebas suelen realizarse de manera supercial e incompleta. Al utilizarse una forma informal para la realizacin de las pruebas, no se o puede asegurar que el software est libre de errores. De hecho, uno de los proe blemas ms dif a ciles con este tipo de pruebas, es saber cundo parar de probar. a Si para un determinado sistema, se asigna un equipo de probadores, y ellos

1.3. LAS PRUEBAS DE SOFTWARE BASADAS EN MODELOS

11

invierten cuatro semanas en el producto terminado, ellos podr encontrar an muchos errores la primera semana, algunos la segunda, pocos la tercera, y quizs a ninguno en la cuarta. Pero slo porque ellos no encontraron ningn error en la o u cuarta semana no signica que no haya ninguno. En muchas empresas, actualmente no hay una forma prctica para probar a que cualquier pieza de software del mundo real est exenta de errores, incluso una e bien probada pieza de software. Adems, la funcionalidad no llega a probarse a bien, debido a que los probadores son raramente usuarios expertos. Ante todos los inconvenientes enunciados, se han invertido esfuerzos en mejorar la calidad del proceso de pruebas del sistema. Uno de ellos se basa en el mtodo de pruebas de sistema basados en modelos. e

1.3.2.

Desarrollo de pruebas basadas en modelos

Las pruebas basadas en modelos requieren la derivacin sistemtica y posio a blemente automtica de las pruebas a partir de modelos. Los mtodos de derivacin a e o de pruebas conocidos de las pruebas de software convencionales, pueden ser aplicados a los modelos UML. Las dos tcnicas bsicas en las pruebas de software e a son las pruebas de caja negra y las pruebas de caja blanca. Los principios de las pruebas de caja negra y caja blanca est bien detallados, por ejemplo, en los a libros de Beizer [8] y Myers [53]. Adems de estas tcnicas, existen algunos mtodos para la generacin aua e e o e tomtica de casos de prueba a partir de descripciones formales [54]. Estos mtoa dos pueden ser aplicados en modelos UML si los modelos son ejecutables y si existe una semntica formal para el subconjunto UML usado. La generacin aua o tomtica de pruebas a partir de modelos UML se tratar en la seccin de Estado a a o de la Situacin Actual, porque todav es un tema actual de investigacin. o a o 1.3.2.1 Mtodos de prueba de caja negra e Las pruebas de caja negra, muchas veces son llamadas pruebas funcionales, tratan el sistema bajo prueba como una caja negra. Las pruebas son desarrolladas sin ningn tipo de suposicin acerca de la estructura interna del sistema bajo u o prueba. Ellos evalan el comportamiento puro de entrada y salida del sistema u bajo prueba. T picamente, un conjunto de casos de prueba es denido para cada funcin del sistema bajo prueba, enfocndose sobre las diferentes salidas que la o a funcin debe producir. o Los mtodos ms conocidos para el desarrollo sistemtico de pruebas de caja e a a a negra son la particiones de clases de equivalencia [32] y el anlisis de valores l mite [62]. Para las particiones de clases de equivalencia, el dominio de cada parmetro a de entrada de una funcin es estructurada en clases de equivalencia. Para los o valores en una clase de equivalencia, es asumido que la funcin los trata de la o misma manera, y por lo tanto, solo un representante de cada clase de equivalencia necesita ser probado.

12

CAP ITULO 1. INTRODUCCION

El anlisis de valores de frontera es muchas veces usado en combinacin a o con la particin de clases de equivalencia. En este mtodo, los casos de prueba o e desarrollados por las particiones de clases de equivalencia son complementadas por los casos de prueba que prueban la frontera de las clases de equivalencia, porque los errores de programacin t o pico, como por ejemplo, la terminacin o equivocada de bucles, estn muchas veces relacionados a estas fronteras. a En UML, las funciones son especicadas sobre diferentes niveles de abstraccin. Los casos de uso describen la funcionalidad principal de todo el sistema, es o decir, sobre el nivel de sistema, y los mtodos de las clases especican funciones e sobre el subsistema. Los diferentes niveles de abstraccin corresponden a las o diferentes fases de construccin y pruebas descritas en el modelo V (ver Figura o 1.1). En otras palabras, los casos de uso y los mtodos identican los conjuntos de e casos de pruebas que deben ser desarrollados para lograr la cobertura funcional del sistema. Para ayudar a la identicacin de las clases de equivalencia, pueden o ser usadas las especicaciones de los casos de uso y los mtodos de, por ejemplo, e los diagramas de secuencia o diagrama de actividades. El ujo especicado de control est muchas veces relacionado a las clases de equivalencia. a

1.3.2.2 Mtodos de prueba de caja blanca e Las pruebas de caja blanca hacen uso de la estructura interna del sistema bajo prueba, es decir, tratan el sistema bajo prueba como una caja de cristal. Los casos de prueba son desarrollados usando criterios de cobertura para el cdigo del programa. o Los criterios t picos de cobertura son sentencias, ramas, y rutas de cobertura. Los dems criterios de cobertura se relacionan al uso de las variables en el ujo a del programa y las condiciones que determina las ramas y la terminacin de o bucles. Los criterios de cobertura tambin son usados para derivar los casos de e prueba a partir de modelos UML. Por ejemplo, los criterios de cobertura de estado y transicin, pueden ser usados para denir un conjunto satisfactorio de o casos de pruebas para las mquinas de estados, describiendo el comportamiento a de una clase. Los criterios de cobertura pueden tambin ser usados para denir e los casos de prueba para diagramas de secuencia, diagramas de actividad, y diagramas de interaccin. o Hasta este punto hemos abordado cmo son tratadas las pruebas de softo ware convencional. De aqu en adelante nos centraremos en las aplicaciones Web, donde la navegabilidad es su caracter stica por naturaleza (ver seccin o 1.1). Si bien es cierto, el desarrollo de aplicaciones Web tiene varias propuestas metodolgicas que tienen una robustez reconocida, la Ingenier Web ha o a puesto atencin en el desarrollo de aplicaciones Web basada en modelos. En o el siguiente apartado, presentaremos sus caracter sticas principales, nalizando con el tratamiento de las pruebas de software aplicando este nuevo paradigma.

1.4. MODEL-DRIVEN WEB ENGINEERING (MDWE)

13

1.4.

Model-Driven Web Engineering (MDWE)

En la actualidad, la Ingenier dirigida por Modelos (MDE) [11] ha recibido a una atencin considerable y est en camino de volverse en un paradigma proo a metedor en la Ingenier del Software. Es as que el Desarrollo Dirigido por a , Modelos (MDD) est siendo ampliamente aceptado en los diferentes dominios a de la Ingenier del Software. La idea bsica de MDD es separar el modelado a a independiente de la plataforma con el modelado espec co, y a la vez, separar el modelado espec co de la plataforma con la implementacin, tardando o tanto como sea posible la construccin de modelos relacionados a tecnolog o as espec cas. El paradigma MDD [57] tiene dos ejes principales: Primero, hace nfasis en la separacin entre la especicacin de la fune o o cionalidad esencial del sistema y la implementacin de dicha funcionalidad o usando plataformas tecnolgicas espec o cas. Para ello, el MDD identica dos tipos principales de modelos: modelos con alto nivel de abstraccin e o independientes de cualquier tecnolog de implementacin, llamados PIM a o (Platform Independent Model) y modelos que especican el sistema en trminos de construcciones de implementacin disponibles en alguna tece o nolog espec a ca, conocidos como PSM (Platform Specic Model); Segundo, los modelos son considerados los conductores primarios en todos los aspectos del desarrollo de software. Un PIM es transformado en uno o ms PSMs, es decir que para cada plataforma tecnolgica espec a o ca se genera un PSM espec co. La transformacin entre modelos constituye o el motor del MDD y de esta manera los modelos pasan de ser entidades meramente contemplativas a ser entidades productivas. La iniciativa MDD cubre un amplio espectro de reas de investigacin: a o lenguajes para la descripcin de modelos, denicin de lenguajes de transforo o macin entre modelos, construccin de herramientas de soporte a las distintas o o tareas involucradas, aplicacin de los conceptos en mtodos de desarrollo y en o e dominios espec cos, etc. Otra de las reas de investigacin cubiertas por MDD se orienta hacia la a o Web. El nmero creciente de metodolog orientadas a la Web ha causado un u as nmero intensivo de estudios comparativos que valoran sus ventajas y desvenu tajas [39][67]. La comunidad investigadora ha detectado en estos estudios que hay un nmero alto de tcnicas, modelos o procesos orientados con el mismo u e grupo de conceptos. Este hecho ha introducido una nueva tendencia de la investigacin dentro de la Ingenier Web conocido como Ingenier Web Dirigido o a a por Modelos (MDWE). Adems, la Arquitectura Dirigida por Modelos (MDA, [57]) de OMG ofrece a los principios necesarios para denir mtodos dirigidos por modelos usando noe taciones estndares. En la Figura 1.3 [41], se muestra la estructura MDA para a el desarrollo Web.

14

CAP ITULO 1. INTRODUCCION

Figura 1.3: Estructura MDA para Ingenier Web [41]. a En esta rea, los conceptos son lo ms importante, independientemente de a a la manera de cmo son representados. MDWE propone representar conceptos o usando metamodelos. El proceso de desarrollo se apoya en un conjunto de transformaciones y relaciones entre conceptos que permitan hacer ms gil el desaa a rrollo y aseguran la consistencia entre modelos. Los metamodelos son un requisito previo para la Ingenier Dirigida por a Modelos (MDE) en general y por consiguiente para la Ingenier Web dirigida a por Modelos. Sin embargo, varios lenguajes de modelado en el campo de la Ingenier a Web no estn basados en metamodelos y estndares. Adems, existen diversas a a a propuestas metodolgicas para el desarrollo de aplicaciones Web, en donde el o modelado de la navegacin suele ser dependiente de la metodolog utilizada. Es o a as que la propuesta de nuestro trabajo pretende ser genrica; es decir, realizar , e las pruebas de sistema basados en modelos navegacionales independientemente de la metodolog escogida. Para conseguir tal objetivo, nos basamos en este a paradigma guiado por modelos (MDWE). De esta manera, aprovecharemos el uso de los conceptos de metamodelos. Cabe resaltar, que el poder de MDWE est provocando que mtodos clsicos a e a estn evolucionando a este nuevo paradigma. As en [52][74]los metamodelos e , para WebML [19] son presentados o en [5] un metamodelo para W2000 [6] es ofrecido. Incluso, algunas metodolog dirigidas por modelos, como UWE [40], as estn evolucionando a la norma denida por OMG con el uso de QVT para a e denir las transformaciones [42]. Tambin, los modelos de NDT (Navigational Development Techniques) [27], metodolog denida para las fases de requisitos a

1.4. MODEL-DRIVEN WEB ENGINEERING (MDWE)

15

y anlisis del desarrollo Web, estn basados en metamodelos MOF lenguajes a a o de transformacin estndar. o a

1.4.1.

Transformacin de modelos o

El metamodelado es un mecanismo que permite especicar formalmente lenguajes de modelado, como lo son el UML y el RDBMS. La Arquitectura 4 capas de modelado es la propuesta de OMG orientada a estandarizar conceptos relacionados al modelado, desde los modelos ms abstractos a los modelos ms a a concretos. Los niveles denidos en esta arquitectura se denominan comnmente: u M3, M2, M1, M0: El nivel M3 (el meta-metamodelo) es el nivel ms abstracto, donde se a encuentra el MOF [50], que permite denir metamodelos concretos (como el del lenguaje UML) El nivel M2 (el metamodelo), sus elementos son lenguajes de modelado, por ejemplo UML. Los conceptos a este nivel podr ser Clase, Atributo, an Asociacin. o El nivel M1 (el modelo del sistema), sus elementos son modelos de datos, por ejemplo entidades como Persona, Auto, atributos como nombre, relaciones entre estas entidades. El nivel M0 (instancias) modela al sistema real. Sus elementos son datos, por ejemplo Juan Lpez, que vive en Av. Mar Luisa 345 o a En este contexto, la denicin de lenguajes para transformacin de modelos o o puede pensarse en la capa M3 de la Arquitectura de modelado 4 capas, ya que una instancia espec ca de transformacin se ubica en la capa M2 para o poder relacionar instancias genricas de metamodelos concretos (que se ubican e en M2) como el de UML y el de RDBMS, entre cuyas instancias se produce la transformacin (por ejemplo una Class de UML y una Table de RDBMS). Es o decir, los modelos que concretamente estn involucrados en la transformacin a o (capa M1) son parmetros para el lenguaje de transformacin. a o Es lgico pensar que el metamodelo para transformaciones y su instanciacin o o no pueden convivir en la misma capa, ya que representan distintos niveles de abstraccin. o Ahora bien, en la capa M3 se ubica MOF, que representa un Meta-metamodelo cerrado sobre el que se instancian metamodelos (instancias de MOF). En consecuencia, el metamodelo para Transformaciones deber ubicarse en la capa M2, a junto con el resto de los metamodelos (por ejemplo el de UML, de OCL, etc.) como puede verse en la Figura 1.4. Otra de las especicaciones, estrechamente vinculadas a MOF, y que dene OMG es la Infraestructura [50]. La Infraestructura es la especicacin ms simplicada que dene los constructores bsicos o a a y conceptos comunes para lenguajes de modelado. Podemos decir que es independiente al lenguaje UML en s El metamodelo de UML se complementa con .

16

CAP ITULO 1. INTRODUCCION

Figura 1.4: Capas M2 y M3 de la Arquitectura 4 capas.

Figura 1.5: Modelado de sistemas basados en MDA. la especicacin de la Superestructura [50], que dene los constructores a nivel o usuario de UML 2.0. El caso de la Infraestructura es interesante por su denicin recursiva respeco to a MOF: por un lado, puede verse denida como instancia de MOF (en la capa M2 como muestra la Figura 1.4); por otro lado el MOF mismo se basa, o bien usa elementos del paquete Core de la Infraestructura para su denicin, situacin o o que nos permite identicar a la Infraestructura como un meta-metamodelo.

1.4.2.

Aplicando MDA para modelar pruebas

Segn el enfoque de MDA, el desarrollo del software se inicia con la esu pecicacin de un modelo independiente de la plataforma (PIM) del sistema a o ser desarrollado. Este modelo especica el correcto funcionamiento del sistema independientemente de los detalles espec cos de la plataforma. (PSM). El PIM debe ser renado en varios pasos iterativos. Una vez que el PIM es nalizado, uno o ms modelos espec a cos de la plataforma (PSMs) pueden ser derivados por transformadores apropiados. Esto se muestra en la Figura 1.5. Para cada PSM, el paso de transformacin apropiado adapta la estructura y la o

1.4. MODEL-DRIVEN WEB ENGINEERING (MDWE)

17

Figura 1.6: Modelado de pruebas basados en MDA. funcionalidad del PIM hacia una plataforma espec ca. Subsecuentemente, el cdigo del sistema para la plataforma destino puede ser generado de cada PSM o por transformadores apropiados. Todos los pasos de transformacin entre PIM y PSM, y entre PSM y el cdigo o o del sistema pueden ser realizados de forma automtica o semi-automtica. En a a este ultimo caso, los PSM necesitan ser completados antes de que se pueda iniciar el siguiente paso de transformacin. o Dependiendo de la conformidad de las transformaciones PSM to Code, el cdigo del sistema generado est listo para su ejecucin an necesita ser como a o o u pletado manualmente. El mayor benecio de MDA es que el sistema puede ser desarrollado para una o ms de una plataforma espec a ca. Sin embargo, incluso si slo hay una o sola plataforma destino en la planicacin del sistema desarrollado, MDA pero mite la exibilidad y el soporte necesario para implantarlo ms tarde en nuevas a plataformas. Para el modelado de pruebas, la misma abstraccin en trminos de modelado o e de plataforma independiente y espec ca, puede ser aplicado segn [57]. Como u se muestra en la Figura 1.6, de un modelo de pruebas independiente de la plataforma (PIT), varios modelos de pruebas espec cos de la plataforma pueden ser derivados por transformadores apropiados. De cada PST, el cdigo de la o prueba puede ser generado para la plataforma destino dedicada del sistema con el objetivo de ser probados en la plataforma de ejecucin de la prueba. o Es importante mencionar que no siempre es necesario tener un PST separado para cada plataforma destino del sistema bajo prueba. Si un lenguaje abstracto de pruebas es usado, tal como TTCN-3 [87], y las plataformas destino son similares con respecto a su carcter global, la adaptacin nal para la plataforma de a o destino concreta puede ser hecho en el nivel de cdigo usando los adaptadores o de pruebas apropiados. Hasta aqu hemos visto la importancia que tiene la navegacin y lo im, o

18

CAP ITULO 1. INTRODUCCION

portante que es desarrollar una fase de pruebas en el desarrollo de software, permitiendo asegurar la calidad de las aplicaciones construidas. Adems, se ha a presentado la aplicabilidad del paradigma de transformacin de modelos para o el proceso de pruebas en aplicaciones convencionales. Una vez introducidos estos conceptos relevantes, necesarios para nuestra propuesta, el siguiente cap tulo presenta las propuestas existentes de mtodos e de pruebas, analizando las ventajas y desventajas de cada una de ellas. Este anlisis servir para identicar las oportunidades de investigacin, y ser la a a o a base para formular nuestra propuesta de investigacin. o

Cap tulo 2

Estudio de la situacin o actual

Las pruebas de software son un trmino bastante amplio y abarcan una e extensa gama de actividades muy diferentes, desde las pruebas realizadas por el desarrollador de una pequea pieza de cdigo (pruebas unitarias), hasta la n o validacin del cliente de un gran sistema de informacin (pruebas de aceptacin). o o o Las diferentes fases y niveles de pruebas pueden consultarse en la seccin 1.3.1. o En todas estas fases, los casos de prueba pueden ser concebidos con objetivos muy variados, tales como validar si existen desviaciones en los requisitos del usuario, evaluar la conformidad de una especicacin estndar, evaluar la o a robustez de las condiciones de carga, o de entradas maliciosas, medir atributos como el desempeo o usabilidad, estimar la conanza operacional, etc. Adems, n a la actividad de las pruebas podr ser llevadas a cabo por diversos procedimienan tos formales, tales como la planicacin y documentacin rigurosa, o como las o o informales y ad hoc (pruebas de exploracin). o Como consecuencia de esta variedad de objetivos y mbitos, se plantean una a multiplicidad de trminos para las pruebas de software, lo cual ha generado e confusin y muchos problemas en la investigacin sobre pruebas de software. o o Creemos que es necesario claricar este panorama multidisciplinar de las pruebas de software, y a partir de ello, poder concretar nuestra propuesta. Es as que este cap , tulo se inicia presentando los actuales desaf de las pruebas os de software en sus diferentes mbitos y fases (sub-seccin 2.1). Una vez claricaa o dos todos los desaf en el desarrollo de las pruebas de software, nos centramos os en aquellos que consideramos necesarios para formalizar nuestra propuesta. La sub-seccin 2.2 presenta las propuestas ms relevantes con relacin al enfoque de o a o las pruebas basadas en modelos, pero aquellas que no estn dentro del contexto a de transformacin de modelos. En cambio, seguidamente, en la sub-seccin 2.3, o o se presentan los trabajos relacionados que usan el paradigma de transformacin o de modelos. Dicha sub-seccin se inicia con una visin general de los principales o o conceptos en los cuales se basan las propuestas. En esta sub-seccin se presentan o 19

20

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

los trabajos relacionados divididos en dos grandes grupos: las propuestas empresariales y las propuestas acadmicas. Finalmente, este cap e tulo termina con una discusin sobre los trabajos relacionados, en donde se destaca sus ventajas o y desventajas; y sobretodo se orienta hacia las oportunidades de investigacin o que servirn como base para nuestra propuesta. a

2.1.

Las pruebas de software: actuales desaf os

Como se mencion en el prembulo de este cap o a tulo, existe una amplia variedad de objetivos y mbitos con relacin a las pruebas de software. Para aclararlo a o y organizarlo en una vista unicada, presentamos la propuesta de Bertolino [9] acerca de clasicacin de los problemas comunes y de los muchos signicados o de las pruebas de software. El primer concepto a capturar es el encontrar el denominador comn, si existe, entre todas las posibles facetas de las pruebas. u Bertolino propone que el denominador comn puede ser una vista muy absu tracta. Dada una pieza de software (cualquiera que sea en tipolog tamao y a, n dominio) las pruebas siempre consisten en observar una muestra de las ejecuciones de las pruebas, y dar un veredicto sobre ellos. A partir de esta visin general, se pueden concretar diferentes casos, distino guiendo los aspectos espec cos que pueden caracterizar la muestra observada: WHY: Por qu realizamos las observaciones? Esta interrogante concierne al e objetivo de la prueba, por ejemplo, es necesario decidir si el producto puede ser liberado? o ms bien es necesario evaluar la usabilidad de la interfaz de a usuario? HOW: Qu muestra debemos observar? y cmo la escogemos? Este es el e o problema de la seleccin de la prueba, el cual puede ser hecho de manera ad o hoc, de manera aleatoria, o de una forma sistemtica, aplicando algn algorita u mo o tcnica estad e stica. Esto ha inspirada muchas investigaciones, lo cual es comprensible, no slo porque es intelectualmente atractiva, sino tambin por o e la forma en cmo los casos de prueba seleccionados (test criterion) inuyen o grandemente en la ecacia de la prueba. HOW MUCH: Cun grande es la muestra? Aqu hay una doble cuestin, a o de cmo elegimos las pruebas a observar (seleccin de prueba), y de cuntos o o a de ellos son tenidos en cuenta (prueba de adecuacin, o regla de parada). El o anlisis de cobertura o las medidas de abilidad constituyen los dos mtodos a e clsicos para responder a esta interrogante. a WHAT: Qu es lo que ejecutamos? Dado el sistema bajo prueba (SUT), e podemos observar su ejecucin tomndolo como un todo, o enfocndonos slo o a a o en una parte, que pueden ser ms o menos grandes (pruebas de unidad, pruebas a de componentes, pruebas de subsistemas, pruebas de integracin), o ms o menos o a

2.1. LAS PRUEBAS DE SOFTWARE: ACTUALES DESAF IOS

21

denidos: este aspecto da lugar a los distintos niveles de pruebas, y el andamiaje necesario para permitir la ejecucin de las pruebas. o WHERE: Dnde ejecutamos la observacin? Est estrictamente relacionado o o a a qu es lo que ejecutamos, la interrogante es si ello se realiza en casa, en un e entorno simulado o en el contexto del destino nal. Esta cuestin tiene mayor o relevancia cuando se trata de pruebas de sistemas embebidos. WHEN: Cundo, durante el ciclo de vida del producto, ejecutamos las oba servaciones? El argumento convencional es lo ms temprano posible. Es el ms a a conveniente, dado que el costo de eliminar la falla aumenta a medida que el ciclo de vida avanza. Sin embargo, algunas observaciones, en particular los que dependen del contexto de su entorno, no siempre pueden ser anticipados, y no podemos realizar ninguna observacin hasta que el sistema est desplegado y en o e funcionamiento. Una vez distinguidos los aspectos espec cos que pueden caracterizar a la muestra observada, es necesario tener unas orientaciones acerca de cul es el a estado actual de las propuestas relacionadas con las pruebas de software y hacia dnde se deber de dirigir; es decir, precisamos de un roadmap. o an

2.1.1.

ROADMAP

Un plan de trabajo proporciona la orientacin para llegar al destino deseado, o a partir del punto t ests aqu El roadmap de la investigacin de las pruebas u a . o de software est organizado de la siguiente forma: a El punto t ests aqu consiste de los ultimos logros de la investigacin u a o (tomando en cuenta que algunos de estos esfuerzos estn todav en curso). a a El destino deseado se representa en la forma de un conjunto de sueos: se n usa este trmino, para indicar que son metas asintticas. Son, por denie o cin, inalcanzables y su valor se mantiene exactamente como polos de o atraccin para las futuras investigaciones. o 3. En el medio estn los desaf de las actuales y futuras investigaciones a os de pruebas de software. Estos desaf constituyen las orientaciones a ser os seguidas, en el camino hacia los sueos, y como tales, es la parte ms n a importante del roadmap. El roadmap est ilustrado en la Figura 2.1. Dentro de l, en el centro se sitan a e u las investigaciones en curso y las investigaciones emergentes, con muchos tpicos o maduros (los logros) sobre la izquierda, y sobre la derecha las ultimas metas (los sueos). Cuatro tiras horizontales representan las rutas de investigacin n o identicadas hacia los sueos: n 1. Teor de pruebas universal. a

22

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL 2. Pruebas basadas en modelos. 3. Pruebas 100 % automticas. a 4. Ingenier de pruebas con ecacia maximizada. a

Los desaf horizontales corresponden a las interrogantes WHY, HOW, os HOW MUCH, WHAT, WHERE, y WHEN sin un orden espec co. Los desaf de la investigacin en pruebas de software encuentran su lugar en os o este plan, verticalmente dependiendo si es un largo sueo, y hacia la que tienden n principalmente, y horizontalmente de acuerdo a las cuestiones introducidas. En base al Roadmap detallado por Bertolino, y segn la naturaleza de nuestra u propuesta, consideramos oportuno centrarnos en alcanzar dos de los sueos n mencionados: modelado basado en pruebas y las pruebas 100 % automticas. a Los siguientes apartados abordan estos conceptos, pero partiendo desde los desaf existentes en cada sueo y poder alcanzarlos. Es as que abordaremos os n tres desaf los cuales pretendemos seguir con nuestra propuesta: los referentes os, a las pruebas basadas en modelos, a los orculos de prueba y a las pruebas 100 % a automticas. a

2.1.2.

Desaf 1: Orculos de pruebas o a

La cuestin referente a decidir si el resultado de una prueba es aceptable o o no, est relacionado estrictamente con la planicacin de las pruebas, y espec a o camente al problema de cmo derivar los casos de prueba. Esto corresponde a o lo que es denominado orculo, idealmente es un mtodo que provee las saa e lidas esperadas de cada caso de prueba dado; de manera ms realista, es una a heur stica que puede emitir un veredicto de pasa/fallo sobre las salidas de prueba observadas. Aunque es evidente que una prueba de ejecucin para la cual no somos o capaces de discriminar entre el xito y el fracaso, es una prueba intil, y aunque e u la importancia de este problema se ha planteado muy temprano en la literatura [?], al problema del orculo le ha prestado poca atencin en la investigacin y a o o en la prctica existen pocas soluciones alternativas. a Con el incremento de la complejidad y criticidad de las aplicaciones de software, est destinado a convertirse en un obstculo que bloquee la abilidad de a a la automatizacin de las pruebas. o Es ms, la precisin y la eciencia de los orculos afectan al coste y a la a o a ecacia de las pruebas. No se desea que las pruebas fallidas pasen desapercibidas, pero por otro lado, no queremos noticar muchos falsos positivos, los cuales echan a perder los recursos. Se necesita encontrar mtodos ecientes para la realizacin y automatizacin e o o de las pruebas. Baresi y Young [7] proporcionan un estudio cr tico de las soluciones de orculos, concluyendo en las siguientes caracter a sticas:

2.1. LAS PRUEBAS DE SOFTWARE: ACTUALES DESAF IOS

23

Figura 2.1: Roadmap de las pruebas de software [9].

24

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

Comportamiento y estado abstracto vs. concreto: las pruebas basadas en modelos prometen aliviar el problema de los orculos, ya que el mismo modelo a puede actuar como orculo; sin embargo, para los orculos basados en las desa a cripciones abstractas del comportamiento del cdigo, el problema sigue siendo o el salvar las distancias entre las entidades concretas observadas y las entidades abstractas especicadas. Parcialidad: convincentemente los orculos parciales son la unica solucin a o viable para la automatizacin del orculo. El reto es encontrar la mejor como a pensacin entre precisin y costo. o o Cuanticacin: Para los orculos de prueba implementados por lenguajes de o a especicacin ejecutables, se trata de encontrar un compromiso entre la expreo sividad y la eciencia. Hasta el momento no hay un claro equilibrio ptimo, ni o algn mtodo completamente satisfactorio para adaptar los cuanticadores. u e Seleccin de casos de prueba y orculos: Idealmente, los orculos deben o a a ser ortogonales a la seleccin de los casos de prueba; sin embargo, en las pruebas o basadas por modelos, los modelos disponibles son muchas veces usados para derivar clases de pruebas y orculos de prueba de clases espec a cas.

2.1.3.

Desaf 2: Pruebas 100 % automticas o a

La automatizacin es una de las formas de mantener la calidad del anlisis o a y de las pruebas, en l nea con la actual complejidad del software. La investigacin en ingenier del software pone gran nfasis en la automatizacin de la o a e o produccin del software, con una mayor parte en las herramientas de desarrollo, o generando cada vez ms grandes y complejas cantidades de cdigo con menos a o esfuerzo. La otra cara de la moneda es el gran peligro que tienen los mtodos para e evaluar calidad del software producido, en particular, los mtodos de prueba e que no pueden mantener el ritmo de los mtodos de construccin de software. e o Una gran parte de la investigacin actual sobre las pruebas tiene por objeto o mejorar el grado de automatizacin, ya sea mediante el desarrollo de tcnicas o e avanzadas para la generacin de entradas de pruebas, o para encontrar proceo dimientos de soporte para la automatizacin del proceso de prueba. o El sueo vendr a ser un potente ambiente integrado de pruebas, que por n a s solo, pueda, automticamente, hacerse cargo de la generacin y recuperacin a o o del cdigo necesario (drivers, stubs, simuladores), generando los casos de prueba o ms adecuados, ejecutndolos y nalmente expidiendo un informe de la prueba. a a Esta idea ha atra muchos seguidores, por ejemplo, el mtodo de pruebas do e continuas de Sa [72], precisamente intentan ejecutar pruebas en background sobre la mquina de los desarrolladores mientras ellos programan. a Se han realizado muchos pasos prometedores para las pruebas unitarias, que es ampliamente reconocida como la fase esencial que asegura la calidad del soft-

2.1. LAS PRUEBAS DE SOFTWARE: ACTUALES DESAF IOS

25

ware, porque examinar unidades individuales de forma aislada puede permitir detectar tempranamente aquellos fallos sutiles que dif cilmente se encuentran en el nivel de las pruebas de sistema. Desafortunadamente, las pruebas unitarias son muchas veces mal realizadas o dejadas de lado por completo, al considerarse una actividad cara. Es as que se , necesita enfoques para hacerlo ms factible dentro de los procesos de desarrollo a de la industria del software. Uno de los principales componentes que intervienen en el alto costo de las pruebas unitarias es la enorme cantidad de codicacin extra, necesaria para o simular el ambiente donde la unidad debe ejecutarse y en donde se ejecuta el chequeo funcional necesario para las salidas de la unidad. Para aliviar tales tareas, los frameworks de la familia XUnit tienen un gran xito entre los dee sarrolladores. Entre ellas la ms satisfactoria es JUnit [38], la cual permite la a automatizacin del cdigo de los casos de prueba Java. o o Otro ejemplo es el proporcionado por la nocin de agitacin de software o o [15], una tcnica de pruebas unitarias automticas soportadas por la herramienta e a comercial Agitator, la cual combina diferentes anlisis, tales como la ejecucin a o simblica, resolucin de restricciones, y la generacin aleatoria de entradas para o o o la generacin de los datos de entrada. o Tambin existe otro mtodo de pruebas unitarias, las parametrizables (PUT) e e [84]; es decir, las pruebas unitarias codicadas que no son jas, sino que dependen de algunos parmetros de entrada. PUT puede describir el comportamiento a abstracto en una forma concisa. Usando tcnicas de ejecucin simblica y ree o o solviendo restricciones, puede encontrar entradas para los PUTs para alcanzar un alto cdigo de cobertura. o Los tres ejemplos citados no son ciertamente exhaustivos. La tendencia comn que surge es el esfuerzo por combinar de manera eciente los diveru sos tipos de anlisis, y esto, junto con el aumento exponencial de los recursos a computacionales disponibles, podr ser realmente la direccin hacia el sueo de a o n la automatizacin 100 % de las pruebas. o

2.1.4.

Desaf 3: Pruebas basadas en modelos o

Una gran parte de la investigacin, hoy en d est enfocada en las pruebas o a, a basadas en modelos. La idea es usar los modelos denidos en la construccin del o software para conducir el proceso de pruebas. En particular, generar automticaa mente los casos de prueba. El enfoque pragmtico que toma la investigacin en a o pruebas es la tendencia en el modelado: la notacin que se utiliza, por ejemplo, o UML o Z, y se intenta adaptar una tcnica de pruebas que sea la ms efectiva e a posible. A partir del punto de vista del probador, la situacin ideal ser invertir este o a enfoque con respecto a qu es lo primero y qu viene despus; es decir, en lugar e e e de tomar un modelo y ver cmo podemos aprovecharlo de la mejor manera para o las pruebas, permitir considerar que idealmente se podr construir un modelo a de modo que el software pueda ser probado de manera efectiva.

26

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

Anteriormente, se ha mencionado que la tendencia del aumento de la complejidad del software requiere la necesidad de una alta calidad y estn impulsando a a que el costo de las pruebas sea ms alto, hasta el punto que en las prcticas a a de pruebas tradicionales, las pruebas no resulten econmicas. Pero afortunadao mente en el otro extremo, el uso creciente de modelos de desarrollo de software est eliminando la principal barrera de la adopcin de las pruebas basadas en a o modelos. La idea de las pruebas basadas en modelos ha estado alrededor de dcadas. e o o o Moore [51] inici la investigacin con la generacin de pruebas basadas en FSM (mquinas de estados nitos en el ao 1956. Pero, en los ultimos aos se ha visto a n n un gran inters en su aplicacin para aplicaciones reales. Para una mayor introe o duccin sobre los mtodos y herramientas basadas en modelos, puede consultar o e el libro [89] No obstante, la adopcin industrial de las pruebas basadas en modelos an o u sigue siendo baja y las seales de investigacin son dbiles. Por lo tanto, ms n o e a all de los desaf tericos, actualmente los investigadores se estn enfocando a os o a en cmo vencer las barreras para ampliar la adopcin. o o Estn pendientes cuestiones tcnicas importantes relativas al proceso. Una a e cuestin ampliamente reconocida es el cmo se pueden combinar diferentes estio o los de modelado, tales como los basados en transiciones, basados en pre y post condiciones y los basados en escenarios. Por ejemplo, se necesita encontrar la forma efectiva para componer mtodos basados en estados y mtodos basados e e en escenarios [10] [30]. En Microsoft, donde las pruebas basadas en modelos han sido defendidas por varios aos, se ha propuesto un mtodo multi-paradigmatico [30] con la n e nalidad de ampliar esta adopcin. La idea es que los modelos derivados de o diferentes paradigmas y que estn expresados en cualquier notacin, puedan ser e o perfectamente utilizados dentro de un entorno integrado. La leccin aprendida es que no funciona el hecho de obligar a los usuarios o a usar una nueva notacin. El mtodo de pruebas basado en modelos debe ser o e agnstico y dejar a los desarrolladores usar las notaciones de programacin y o o ambientes existentes [30]. Tambin es necesario tener maneras para combinar el criterio basado en e modelos con otros mtodos; por ejemplo, una idea prometedora es usar pruebas e sobre simulaciones [71] para optimizar el juego de pruebas y para impulsar y estimular las pruebas. Las cuestiones relacionadas con el proceso se preocupan por integrar las prcticas de pruebas basadas en modelos dentro de los procesos de software a actuales. Tal vez, por un lado son cruciales, la necesidad relacionada con la administracin de las pruebas para realizar modelos de prueba tan abstractos como o sea posible, al tiempo que se sigue manteniendo la capacidad para generar pruebas ejecutables. Y por otro lado, de mantener la trazabilidad de los requisitos para las pruebas a lo largo de todo el proceso de desarrollo. Finalmente, tambin se necesitan herramientas industriales robustas para el e modelado interactivo, que puede ayudar a reducir la educacin inadecuada de o los actuales probadores.

2.2. TRABAJOS RELACIONADOS SIN ENFOQUE MDA

27

Un caso especial de pruebas basadas en modelos son las pruebas de conformidad, es decir, comprobar si el sistema cumple con la especicacin del sistema o bajo prueba, bajo alguna relacin de denicin. En este aspecto, Broy et al. o o [47] presentan un amplio panorama de los desaf en las pruebas basadas en os modelos para sistema reactivos. o Tambin, Berlinfante et al. [47] presentan una buena visin general de las e herramientas para las pruebas de conformidad basadas en modelos, que ponen de maniesto la necesidad de mejorar y facilitar la aplicacin de la teor o a. Los resultados logrados hasta la fecha son impresionantes sobre razones terio cas, pero muchos de los mtodos propuestos no son aplicables a sistemas reales, e aunque varias herramientas han sido desarrolladas y algunas de stas se aplican e en mbitos especializados. a Adems de las propuestas de investigacin mencionadas que tienen en cuenta a o el desaf de las pruebas basadas en modelos, existen varias propuestas que o tambin lo han abordado, pero que tienen una mayor relacin con nuestra proe o puesta. En el siguiente apartado se presenta estas propuestas.

2.2.

Trabajos Relacionados sin enfoque MDA

En esta seccin se presentan aquellas propuestas que no estn en el contexto o a MDA, pero que se centran en el desarrollo de pruebas basados en modelos y que estn relacionadas con nuestra propuesta. Bsicamente, se dividen en a a dos sub-secciones: las propuestas basadas en modelos destinadas al mbito de a las aplicaciones Web, y las propuestas basadas, espec camente, en modelos navegacionales, stas tambin, dentro del contexto de la Ingenier Web. Esta e e a sub-seccin no pretende ser muy rigurosa, sino fundamentalmente informativa, o pues el grado de relacin con nuestra propuesta es menor, con referencia a las o propuestas de trabajos relacionados que son presentados en la sub seccin 2.3, los o cules utilizan la especicacin de meta-modelos y el enfoque de transformacin a o o de modelos.

2.2.1.

Pruebas basadas en modelos

En las pruebas basadas en modelos se construye un modelo abstracto de la aplicacin bajo prueba, y las secuencias de pruebas son generadas a partir de o dicho modelo para satisfacer algunos objetivos de cobertura. Las tcnicas de pruebas existentes basadas en modelos para aplicaciones e Web, se extienden de las tcnicas tradicionales de pruebas, por ejemplo, los e basados en ujos de control y/o ujos de datos [46] [65] [25] [3] [69] o En particular, Lucca et al. [25] propuso la aplicacin de varios criterios de cobertura presentados por Binder [13] para probar las interacciones con el navegador. Nuestra propuesta para pruebas de sistema est tambin basada en moa e delos, espec camente en los modelos navegacionales. El siguiente apartado presenta las propuestas que toman en cuenta dichos modelos para su proceso de pruebas.

28

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

2.2.2.

Pruebas basadas en modelos navegacionales

Existe una serie de tcnicas y modelos de pruebas para aplicaciones Web, e cada una de las cuales tiene diferentes or genes y persigue diferentes objetivos para hacer frente a una de las caracter sticas singulares de las aplicaciones Web, la navegacin. Los modelos de navegacin propuestos en [73] [45] [23] usan noo o taciones de modelos de estados para modelar la navegacin y las interacciones o con el usuario. Sin embargo, la generacin de pruebas no es cubierta. o En cambio, Rico y Tonella [69] proponen un modelo de pruebas para aplicaciones Web basada en modelos navegacionales. Los criterios de cobertura son denidos con referencia al modelo navegacional; es decir, un modelo que contenga pginas Web, links y formularios. Esta propuesta es esttica y no cubre a a el comportamiento dinmico de la navegacin. Otra de las propuestas basadas a o en modelos navegacionales fue hecha por Andrews et al. [3] En este caso, el modelo navegacional es una mquina de estados con la restriccin que, los casos a o de prueba son recuperados a mano por los ingenieros de pruebas directamente de la aplicacin. Es decir, se carece de un proceso automatizado. o Kung et al. [43] desarrollaron un mtodo de generacin de pruebas basado e o sobre mltiples modelos de la aplicacin bajo prueba. Los modelos incluyen diau o gramas entidad-relacin, diagramas de estados, diagramas de clster y modelos o u navegacionales. No obstante, este mtodo asume que se tiene disponibilidad del e cdigo fuente, mientras que nuestra propuesta se basa en las pruebas de caja o negra.

2.3.

Trabajos Relacionados con enfoque MDA

Los niveles de abstraccin de MDA pueden tambin aplicarse al modelado o e de pruebas [31]. Debido a la creciente complejidad de los sistemas de software, la temprana integracin de las pruebas en el proceso de desarrollo es cada vez o ms importante. a Al hacerlo, los errores de diseo y fallas de implementacin pueden ser detecn o tados en una fase temprana del proceso de desarrollo. Esto permite la reduccin o de tiempo y costos. Adicionalmente, las pruebas desarrolladas pueden ser ejecutadas en el sistema que ha sido entregado al cliente con el n de comprobar su correcto comportamiento en el ambiente del cliente. Esta sub-seccin presenta los trabajos relacionados con los modelos de prueo bas de software que utilizan el enfoque MDA. Debido a que dichos trabajos relacionados comparten una base terica comn, iniciamos este apartado mostrando o u una visin general terica. Bsicamente, se trata el concepto de transformao o a ciones, UML 2.0 Test Prole (U2TP [64]) y Testing and Test Control Notation version 3 (TTCN-3 [87]). Seguidamente, en la sub-seccin 2.3.2 se presenta los o trabajos relacionados del mbito comercial. Finalmente, se muestran las proa puestas relacionadas con el mbito acadmico. a e

2.3. TRABAJOS RELACIONADOS CON ENFOQUE MDA

29

2.3.1.

Visin general terica o o

El lenguaje de modelado unicado (UML) es un lenguaje visual que soporta el diseo y desarrollo de sistemas complejos orientados a objetos. Con el incren mento de la complejidad de los sistemas, se incrementa la necesidad de unas pruebas slidas. Pero UML por s mismo, an con la nueva versin 2.0 [44], o u o no proporciona los medios para describir modelos de prueba. Es as que, se ha denido el prole de UML 2.0 para las pruebas, llamado UML 2.0 Testing Proa le (U2TP) [64], y se ha convertido en el estndar ocial de OMG desde marzo de 2004. U2TP llena el vac entre diseadores y probadores proporcionando los o n medios para usar UML en el modelado del sistema y especicacin de las prueo bas. Esto permite un reuso de los documentos de diseo UML para las pruebas n y permite el desarrollo de las pruebas en una fase temprana del desarrollo del sistema. El objetivo de esa sub-seccin es presentar los conceptos tericos en los cuales o o se basan los actuales trabajos de investigacin relacionados con las pruebas de o software basados en modelos en un contexto MDA. En la seccin 2.3.1.1, se o presenta el concepto general de transformaciones relacionados con las pruebas de software. Seguidamente, en la seccin 2.3.1.2 se presenta las caracter o sticas del prole de UML (U2TP). Finalmente, la seccin 2.3.1.3 brinda un panorama o general de TTCN-3 y su relacin con U2TP. o 2.3.1.1 Transformaciones De acuerdo a la losof de MDA, el mismo mecanismo de modelado puede a ser reutilizado para mltiples objetivos [78]. Antes de generar los cdigos de u o sistema ejecutables, debe hacerse una distincin estricta entre los modelos ino dependientes de la plataforma y los modelos espec cos de la plataforma. Similarmente, los modelos de pruebas pueden ser especicados, tanto independientemente de la plataforma, as como de forma espec ca de la plataforma, antes de la generacin de cdigos de prueba ejecutables. o o La losof de MDA puede ser aplicada tanto al modelado del sistema como al a modelado de pruebas. Como es mostrado en la Figura 2.2, los modelos de diseo n del sistema independientes de la plataforma (PIM) pueden ser transformados en modelos de diseo del sistema espec n cos de la plataforma (PSM). En otro paso de la transformacin, el cdigo del sistema puede ser derivado de los PSM. o o Ciertamente, la completitud del cdigo depende de la completitud del modelo o de diseo del sistema. n Los investigadores han realizado transformaciones entre los diferentes niveles de abstraccin del sistema o los diferentes niveles de abstraccin de las pruebas o o (echas verticales en la Figura 2.2) [14] [12]. Pero slo unos pocos investigadores o han realizado la transformacin entre los modelos del sistema y los modelos de o pruebas (echas horizontales de la Figura 2.2). Adems, los modelos de diseo de pruebas pueden ser transformados directaa n mente a partir de los modelos de diseo del sistema. Esto permite la integracin n o

30

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

Figura 2.2: Modelos de Diseo del Sistema vs. Modelos de Diseo de Pruebas. n n temprana del desarrollo de pruebas dentro del proceso de desarrollo global. Una vez que est denido el modelo de diseo del sistema en el nivel PIM, se puede a n derivar el modelo de diseo de prueba independiente de la plataforma (PIT). n Este modelo puede ser transformado directamente a cdigo de prueba a un o o modelo de diseo de prueba espec n co de una plataforma (PST) [75]. La misma tecnolog de transformacin puede ser usada para derivar los PSTs a partir a o de los PSM. Despus de cada paso de transformacin, el modelo de diseo de e o n pruebas puede ser renado y enriquecido con las propiedades espec cas de la prueba. A pesar que el modelo de diseo de prueba transformado ya puede n contener aspectos estticos y dinmicos, el comportamiento tiene que ser coma a pletado a n de cubrir todo el comportamiento esperado del sistema. Adems, a cuestiones de pruebas como por ejemplo, el control de pruebas y la informacin o de despliegue, tienen que ser adicionadas manualmente al modelo del diseo n de pruebas. Por ultimo, el modelo de diseo de pruebas puede ser nalmente n transformado en cdigo de pruebas ejecutables, tanto a partir de PST como de o PIT. 2.3.1.2 UML 2.0 Testing Prole (U2TP) U2TP proporciona conceptos para desarrollar especicaciones de pruebas y modelos de pruebas para pruebas de caja negra [8]. El prole introduce cuatro grupos de conceptos lgicos que cubren los siguientes aspectos [64]: arquitectura o de las pruebas, comportamiento de la prueba, datos de prueba y tiempo. Juntos, estos conceptos denen un lenguaje de modelado para visualizar, especicar, analizar, construir y documentar un sistema de pruebas. A continuacin, se o introducen los conceptos U2TP (Tabla 2.1).

2.3. TRABAJOS RELACIONADOS CON ENFOQUE MDA

31

CONCEPTOS DE ARQUITECTURA DE LA PRUEBA. Uno o ms a objetos pueden ser denidos como el sistema bajo prueba (SUT). Los componentes son objetos dentro de un sistema de prueba, los cuales se pueden comunicar con el SUT con otros componentes para realizar el comportamiento de o la prueba. El contexto de la prueba permite a los usuarios agrupar los casos de prueba para describir una conguracin de prueba correspondiente; es decir, la o conexin entre los componentes de prueba y el SUT, y para denir el control de o prueba, es decir, el orden de ejecucin de los casos de prueba. o El arbitraje es un medio para evaluar un veredicto global para el contexto de la prueba. Un probador puede usar el arbitraje por defecto o denir su propio esquema de arbitraje usando un rbitro. El planicador controla la ejecucin de a o las pruebas y los componentes de pruebas. Es responsable por la creacin de los o componentes de prueba, un inicio sincronizado de los diferentes componentes de prueba y la deteccin de la terminacin de los casos de prueba. o o CONCEPTOS DE COMPORTAMIENTO DE PRUEBA. Un objetivo de prueba dene la meta de una prueba. Por tanto, los diagramas de interaccin de UML, tales como la mquina de estados y los diagramas de actividad, o a pueden ser usados para denir el est mulo de la prueba, las observaciones, las invocaciones y control de pruebas, coordinacin y acciones. o El comportamiento de prueba normativo es especicado en un caso de prueba, el cual es una operacin del contexto de la prueba especicando el cmo o o un conjunto de componentes interacta con el SUT para realizar los objetivos u de prueba. Cuando el comportamiento de la prueba normativa es denido, se tendr en cuenta la denicin de comportamientos no esperados que se logra a a o travs de la especicacin de defaults. e o Una accin de validacin es ejecutada por un componente de prueba local o o para informar al rbitro acerca de su veredicto de la prueba local. Un veredicto a de prueba muestra el resultado de la prueba ejecutada. Los posibles veredictos son pass, inconclusive, fail, y error. CONCEPTOS DE DATOS DE PRUEBA. En U2TP, los wildcards (comodines) son usados para manejar los eventos inesperados, eventos que cono tengan muchos valores diferentes. El prole introduce wildcards siguiendo la especicacin de: (1) cualquier valor y (2) cualquier valor o valores omitidos. o Los pools de datos son asociados con el contexto de prueba e incluyen datos de prueba concretos. Los selectores de datos son operaciones para recuperar datos de prueba del pool de datos de las particiones de datos. La nocin de o o reglas de codicacin permite al probador denir el encoding y decoding de los o datos de prueba cuando se comunican con el SUT. CONCEPTOS DE TIEMPO. El grupo de conceptos de tiempo dene los conceptos para restringir y controlar el comportamiento de la prueba con respecto al tiempo. Los timers son necesarios para manipular y controlar el comportamiento de la prueba, as como asegurar la terminacin de los casos de o

32 Arquitectura SUT Componentes Concepto Conguracin o Arbitro Programador

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL Comportamiento Objetivos Caso de prueba Defaults Veredictos Control Datos Wildcards Pools de datos Particiones Selectores Reglas de codicacin o Tiempo Timer Zona horaria

Tabla 2.1: Conceptos U2TP. prueba. Los timezones son usados para agrupar componentes dentro de un sistema distribuido, permitiendo la comparacin de eventos de tiempo dentro de la miso ma zona horaria. 2.3.1.3 TTCN-3 y su Meta-modelo Testing and Test Control Notation version 3 (TTCN-3 [87]) ha sido desarrollado por el Instituto Europeo de Estandarizacin de Telecomunicaciones o (ETSI) y tambin ha sido estandarizado en la Unin Internacional de Telecomue o nicaciones (ITU-T). TTCN-3 es un lenguaje de especicacin e implementacin o o para denir procedimientos de pruebas de caja negra en sistemas distribuidos. La tabla 2.2 presenta la relacin entre U2TP y los elementos de meta-modelo o TTCN-3. Permite la ejecucin de pruebas, si las herramientas apropiadas y el SUT o estn disponibles. En [14] se proporciona un meta-modelo para TTCN-3, el cual a representa el espacio de concepto de TTCN-3 y permite el uso de TTCN-3 en el contexto de meta-modelado, repositorios y transformaciones de modelos. Los principales objetivos para el desarrollo del meta-modelo TTCN-3 fueron: La separacin de conceptos, separando el concepto y la semntica de o a TTCN-3 de los aspectos sintcticos de TTCN-3. a La capacidad para denir la semntica sobre el nivel de espacio del cona cepto, sin afectar las consideraciones sintcticas, por ejemplo, en caso de a cambios de sintaxis. Para facilitar el intercambio de las especicaciones TTCN-3 de cualquier formato de presentacin y no solamente de las especicaciones textuales o TTCN-3. Para facilitar la denicin del mapeo de un lenguaje externo para TTCN-3, o tales como las deniciones que pueden re-usar partes de mapeos conceptuales de otros lenguajes.

2.3. TRABAJOS RELACIONADOS CON ENFOQUE MDA

33

Para integrar herramientas TTCN-3 dentro de los procesos e infraestructuras basadas en MDA [57]. El meta-modelo de prueba TTCN-3 dene el concepto de espacio de TTCN3 con soporte adicional para formatos de diferentes presentaciones. No reeja directamente la estructura de los mdulos TTCN-3, sino ms bien, la estructura o a de la semntica de la denicin del lenguaje TTCN-3. Ello dene un paquete a o simple con estructuras de conceptos para tipos y expresiones, mdulos y mbitos, o a declaraciones, e instrucciones y operaciones. El meta-modelo TTCN-3 es el objetivo usado en su transformacin y la base o para la denicin de las reglas de mapeo. Cada meta-clase del meta-modelo o objetivo se nombra aplicando la misma convencin: el nombre lgico para el o o concepto TTCN-3 representado por la meta-clase, siendo prejado con TT para hacer que las meta-clases sean fcilmente identicables como meta-clases a de TTCN-3. Una vez introducidos los conceptos necesarios para presentar las diferentes propuestas relacionadas con la generacin de pruebas ejecutables a partir de o modelos, en el prximo apartado comenzamos describiendo las propuestas emo presariales.

2.3.2.

Propuestas empresariales

En este apartado se presentan los trabajos de la industria relacionados con la generacin de pruebas ejecutables a partir de modelos UML, de acuerdo a los o conceptos MDA. En la Tabla 2.3, se presenta el estado del arte de las herramientas que toman, como artefacto principal para el desarrollo, los modelos en lugar que el cdigo (paradigma MDD). Conviene indicar que la mayor de herramieno a tas presentan un modelo de validacin, lo cual signica que es posible probar la o implementacin a partir de la especicacin de requisitos (pruebas de sistema). o o Pero en este conjunto, solamente identicamos tres, que en su proceso de pruebas, se basan en la arquitectura MDA. En los prximos apartados se presenta o una descripcin de las caracter o sticas importantes de estas herramientas. 2.3.2.1 Objecteering Software Por otro lado, Objecteering Software [79] proporciona la oportunidad de trabajar con herramientas de codicacin y de diseo pragmtico, el cual combina o n a modelado UML, produccin de cdigo, debugging y pruebas de aplicaciones o o Java en un ambiente simple. Es una herramienta orientada a modelos, soportando la tecnolog MDA. La Figura 2.3 presenta la arquitectura general de la a herramienta. La herramienta Objecteering/UML est integrada dentro de la plataforma a Eclipse. Esta integracin permite al desarrollador Java tomar ventaja de una o herramienta fuertemente orientada al modelo, el cual, cuando es integrado con el ambiente dedicado Java, se asocia el soporte del modelado UML con el soporte del desarrollo Java. La Figura 2.4 muestra el ambiente grco de modelado de a la herramienta.

34 U2TP Element SUT

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

TTCN-3 Meta-model Element system association of TTTestcase TTVariable TestComponent TTComponentType TestCase TTTestcase TestContext TTModule TTComponentType for the MTC type TestConguration TTFunction TTPortLinkKind TTCreateTC TTStartTC TestObjective TTComment Arbiter TTComponentType TTExternalFunction or TTFunction Verdict TTVerdict ValidationAction TTExternalFunction or TTFunction Default TTDefaultType TTAltstep DefaultApplication TTDefaultKind Stimuli TTOutputKind Observation TTInputKind Coordination TTOutputKind TTInputKind LogAction TTLog InteractionOperator(alt,determAlt) TTAlternative InteractionOperator(loop) TTLoopKind DataSelector TTExternalFunction or TTFunction DataPartition TTExternalFunction or TTFunction TTTemplate CodingRule TTWithKind LiteralAny matching/expression Timer TTTimer TTTimerType StartTimerAction TTTimerStatementKind StopTimerAction TTTimerStatementKind ReadTimerAction TTTimerOp TimerRunningAction TimeOutAction TimeOut TTTimerOp TimeOutMessage Duration TTFloatType Port TTPort , TTPortKind, TTPortType Parameters TTModuleParameter Tabla 2.2: Relacin entre U2TP y los elementos del meta-modelo TTCN-3. o

2.3. TRABAJOS RELACIONADOS CON ENFOQUE MDA

35

Herramienta

Validacin o del modelo

Mtricas e

Antipatrones Navegacin o

Visualizacin Pruebas con o del modelo MDA

All Fusion Component Modeler [49]

ArcStyler [4]

iUML [36]

NetBeans [55]

N/A

N/A

N/A

N/A

N/A

Objecteering Software [79]

Poseidon [61]

Rhapsody [68]

SD Metrics [48]

Tau Generation 2 [82]

Together [85]

WayPointer [92]

N/A

N/A

N/A

XDE [93]

Test Designer [90]

Tabla 2.3: Tabla comparativa de herramientas orientadas a modelos.

36

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

Figura 2.3: Arquitectura en Objecteering Software [79]. 2.3.2.2 Test Designer v3.3 La herramienta Test Designer v3.3 [90] automatiza el diseo de pruebas, n incluyendo diversas fases. Test Designer genera todos los casos de prueba a partir de la especicacin de un modelo funcional, por ejemplo, UML. La Figura 2.5, o muestra las fases que comprende en su desarrollo. Test Designer permite: Implementar la estrategia de pruebas a travs de modelado. e Generar los casos de prueba a partir de varios criterios. Adaptar el scripts de pruebas dentro del ambiente de pruebas para la ejecucin automtica. o a Administrar fcilmente la evolucin de la especicacin. Al actualizar el a o o modelo, Test Designer permite generar los nuevos casos de prueba. La herramienta Test Designer v3.3 implementa el concepto de Smart Testing. Smart Testing son pruebas que, basndose en la teor o en la experiencia, a a tienen una alta probabilidad de detectar clases espec cas de errores; son pruebas dirigidas a t pos espec cos de errores. Adems, Test Designer v3.3 soporta a las pruebas basadas en modelos. Es un mtodo en el cual uno dene el compore tamiento del sistema en trminos de acciones, que cambian el estado del sistema e

2.3. TRABAJOS RELACIONADOS CON ENFOQUE MDA

37

Figura 2.4: Pantalla de modelado en Objecteering Software [79].

Figura 2.5: Fases de prueba de Test Designer [90].

38

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

Figura 2.6: Pantalla de modelado en Test Designer [90]. (mquina de estados). Los modelos UML 2.0 son usados para la generacin aua o tomtica de las secuencias de pruebas. Esta tecnolog implementa heur a a sticas smart para ejecutar los casos de prueba. La Figura 2.6 muestra el ambiente grco de modelado de la herramienta. a 2.3.2.3 Telelogic TAU Generation2 Finalmente, Telelogic TAU Generation2 [82] representa la generacin avano zada de desarrollo y herramientas de pruebas, soportando los estndares de la a industria para sistema visuales y desarrollo de software (UML 2.0 Testing Prole) e integracin de pruebas (TTCN-3). El equipo de Telelogic proporciona un o mtodo que automatiza las actividades de pruebas cubriendo la especicacin, e o desarrollo y ejecucin de las pruebas. U2TP es seleccionado como lenguaje de o modelado para la especicacin de casos de prueba. Los modelos son entonces o transformados al lenguaje TTCN-3, el cul es usado para describir los casos de a uso ejecutables.

2.3.3.

Propuestas acadmicas e

Este apartado presenta las propuestas acadmicas relacionadas con las pruee bas de software, basadas en modelos y en un contexto MDA. Existen varias propuestas, por ejemplo [17][21][60], que utilizan este enfoque; sin embargo, para los propsitos de este apartado, hemos escogido tres propuestas que identio

2.3. TRABAJOS RELACIONADOS CON ENFOQUE MDA

39

can los conceptos comunes existentes. Las propuestas tienen un denominador comn en el desarrollo de sus propuestas. Ellos utilizan los conceptos presenu tados en la sub-seccin 2.3.1: la obtencin de modelos de pruebas a travs de o o e transformaciones, U2TP y TTCN-3. Los meta-modelos U2TP y TTCN-3 son denidos por los modelos Meta Object Facility (MOF) [50]. Las reglas de transformacin denen relaciones o entre las meta-clases origen y destino de estos meta-modelos. 2.3.3.1 Model-Driven Testing with UML 2.0 Dai [20] introduce una metodolog acerca de cmo usar el prole U2TP a o a n de transformar un modelo de diseo de sistema UML en modelos de n pruebas. Para la formalizacin de la propuesta metodolgica, son consideradas o o las reglas de transformacin Query/View/Transformation (QVT) denidas por o CBOP/IBM/DSTC [66]. Se introduce una metodolog para usar de forma efectiva el U2TP, una vez a obtenido el modelo de diseo detallado del sistema a probar [22]. Seguidamente, n se determina el modelo de diseo del sistema modelado con UML 2.0 y el modelo n de diseo de prueba a ser modelado con UML 2.0 usando los conceptos de U2TP. n Teniendo el modelo de diseo del sistema, un probador puede obtener una n prueba espec ca del sistema. Esto puede ser hecho extendiendo el modelo del sistema con los conceptos de U2TP. Los siguientes aspectos son tomados en cuente cuando se da la transformacin del modelo de diseo del sistema en el o n modelo de diseo de prueba. n Lo primero es denir un nuevo paquete UML como el paquete de pruebas del sistema. Luego, importar las clases e interface del paquete del diseo del sistema n a n de obtener acceso a los mensajes y tipos de datos en la especicacin de o la prueba. Seguidamente, se inicia con la especicacin de la arquitectura de la o prueba y se contina con las especicaciones del comportamiento de la prueba. u Los datos y tiempos de prueba estn en su mayor incluidos en las especia a caciones de la arquitectura (por ejemplo zona horaria o pool de datos) o en las especicaciones del comportamiento de la prueba (por ejemplo, timer o particin o de datos). A continuacin, son listadas las cuestiones relacionadas con las especicao ciones de la arquitectura y comportamiento de la prueba. Estn sub-divididos a en dos categor Obligatorias, con las cuestiones que son esenciales para el moas: delo de diseo de la prueba con U2TP. La cuestin obligatoria ms importante n o a es, por ejemplo, el SUT y los componentes de prueba. Las cuestiones opcionales son espec cas para los requisitos de prueba y no son siempre necesarios para la especicacin del modelo de diseo de la prueba. Las cuestiones opcionales son, o n por ejemplo, el control de pruebas y los timers. Adicionalmente, hay conceptos tanto obligatorios como opcionales, los cuales pueden ser derivados directamente de los diagramas existentes del diseo del sistema. n Seguidamente, son listados las cuestiones obligatorias, opcionales y las posibles derivaciones esbozadas. Un modelo de diseo de prueba basado sobre U2TP n puede usar todos los tipos de diagramas UML para la especicacin de la prueo

40

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

Figura 2.7: Transformacin basada en meta-modelos [20]. o ba. Dependiendo de los tipos de diagramas de diseo, pueden ser transferin dos los diferentes tipos de diagramas de diseo de prueba. Por lo tanto, en la n metodolog tambin se seala los tipos de diagramas viables para las derivaa, e n ciones. Estas derivaciones son usadas para la transformacin del modelo de o diseo de prueba. n Transformacin del modelo de dise o de prueba o n La Figura 2.7 muestra la transformacin basada en meta-modelos para la o transformacin del modelo de diseo de prueba. Aqu el meta-modelo fuente o n , es un meta-modelo UML y el meta-modelo objetivo es el meta-modelo U2TP. En la metodolog las clases y objetos son agrupados a n de denir los coma, ponentes de pruebas o el SUT. Tales mecanismos no pueden ser ejecutados por transformaciones. As para el mtodo propuesto de transformacin, se tienen denidos esos , e o mecanismos con el objetivo de proporcionar al probador un medio para agrupar o eliminar elementos, referenciar fragmentos del comportamiento de la prueba, etc. Estos mecanismos son llamados directivas de la prueba y su meta-modelo es el Test Directive Meta-Model. Las reglas de transformacin son aplicadas sobre o el meta-modelo UML y el Test Directive Meta-Model para crear una instancia del meta-modelo U2TP. Los tres meta-modelos son basados sobre MOF. La transformacin del modelo UML para el modelo U2TP es especicado o por un conjunto de reglas denido en la transformacin de meta-modelos [26] o de acuerdo a la especicacin QVT de CBOP/IBM/DSTC [66]. El lenguaje o

2.3. TRABAJOS RELACIONADOS CON ENFOQUE MDA

41

Figura 2.8: Transformacin de componentes de prueba. o de transformacin introducido es orientado a aspectos, lenguajes declarativos y o basados en patrones. Ello muestra los conceptos para la especicacin de reglas, o relaciones de patrones y de rastreo. La transformacin de reglas es usada para o describir la correspondencia entre los patrones de elementos en el modelo fuente y los elementos creados en el modelo objetivo. Los patrones son deniciones reusables. Cuando se usa en la fuente de una regla, el patrn es una consulta. o Cuando es usado en el objetivo, ello acta como una plantilla para los elementos u del modelo. Las relaciones de rastreo asocian los elementos del modelo fuente con los elementos del modelo objetivo. Seguidamente, se muestra un ejemplo de transformacin de diseo de la o n prueba: asumimos que se tiene un Diagrama de Objetos existente del modelo de diseo del sistema y que se desea ejecutar la prueba del sistema sobre el modelo. n Para la transformacin de los componentes de prueba, la metodolog dice: se o a agrupan los objetos (exceptos el SUT) para los objetos de los componentes de prueba. As adems del Diagrama de Objetos, es necesario un mecanismo de agru, a pacin, el cual debe ser proporcionado por el Test Directives Meta-Model. Es o aplicado un mecanismo de agrupacin a un m o nimo de dos objetos en el diagrama. La Figura 2.8 muestra cmo la transformacin puede ser ejecutada en el o o nivel de instancia. En la esquina superior izquierda, se muestra un paquete con tres objetos. En la esquina inferior izquierda, es especicada la relacin entre o los objetos los cuales deben ser agrupados para el componente de prueba en un modelo de directivas de prueba. La notacin de agrupacin es una asociacin o o o entre los objetos con el estereotipo ((group)). En este ejemplo, slo el objeto 1 y el objeto 3 deben de ser agrupados en o un slo componente de prueba. Por lo tanto, despus de la transformacin en o e o

42

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

Figura 2.9: Transformacin de U2TP a TTCN-3 [94]. o este ejemplo, el modelo de prueba de salida consiste de un componente de prueba y una instancia de SUT. Por supuesto, los dos componentes de prueba podr tambin ser especicados, dependiendo de la eleccin de la regla an e o de transformacin. Los estereotipos ((TestComponent)) y ((SUT )) son notaciones o U2TP. Mediante la ejecucin de las reglas de transformacin adecuadas sobre o o los diferentes diagramas del sistema, pueden ser especicadas la arquitectura y el comportamiento de la prueba para el modelo de diseo de prueba. n 2.3.3.2 From U2TP Models to executable tests with TTCN-3 En este trabajo, Zander et al. [94] presentan un mtodo para derivar aue tomticamente las pruebas ejecutables a partir de diagramas UML, usando el a prole UML 2.0 Testing Prole. Se presenta una transformacin entre las especicaciones de UML 2.0 Testing o Prole (U2TP [64]) usadas para representar PITs y Testing and Test Control Notation (TTCN-3 [87]). Las transformaciones son especicadas como reglas de transformacin entre el meta-modelo U2TP [64] y el meta-modelo TTCN-3 o [87]. Posteriormente, la salida generada es completada y compilada en cdigo o de pruebas ejecutables en Java [34]. Los meta-modelos U2TP y TTCN-3 son denidos por los modelos Meta Obo ject Facility (MOF) [50]. Las reglas de transformacin proporcionadas en este trabajo, denen relaciones entre las meta-clases origen y destino de estos metamodelos. Mientras las transformaciones son ejecutadas en el nivel de modelo (instancia), es decir, derivando partes de mdulos TTCN-3 de partes de especio caciones U2TP. Este procedimiento es mostrado en la Figura 2.9.

2.3. TRABAJOS RELACIONADOS CON ENFOQUE MDA

43

El objetivo es obtener automticamente pruebas ejecutables a partir de moa delos U2TP. Sin embargo, en general la generacin slo ser semi-automtica, o o a a pues las especicaciones U2TP pueden ser muy abstractas, de modo que se necesitar ms detalle para hacer las pruebas ejecutables. Ejemplos de esta situacin a a o son la adicin de datos concretos, timing comportamientos por defecto. o o El ambiente, que fue usado para demostrar la viabilidad de este trabajo es Eclipse con el plug-in UML 2.0 [88]. U2TP es realizado con una extensin del o plug-in UML 2.0 mediante la API de Java. Las reglas de transformacin son o tambin realizadas en Java. Las transformaciones generan objetos dentro de la e instancia del meta-modelo TTCN-3, el cual permite la compilacin y ejecucin o o de la pruebas, diseadas previamente en U2TP. n La transformacin entre U2TP y TTCN-3 es obtenida usando el framework o de Eclipse para el meta-modelado, la generacin del repositorio y el acceso a leco tura/escritura para los datos del modelo en repositorio. Se guarda la informacin o a a del modelo en el framework de meta-modelado (EMF [28]), es cul est basado en repositorios. Las reglas de transformacin son denidas entre los metao modelos fuentes y destinos, aplicados a una instancia concreta de meta-modelo; es decir, los modelos fuente y destino en U2TP y TTCN-3 respectivamente. Esta propuesta tambin desarroll especicaciones en U2TP y se ejecutaron e o las transformaciones en el nivel de modelo, a n de obtener las instancias del modelo de prueba TTCN-3. U2TP es el meta-modelo origen para la transformacin y la base para denir o las reglas de mapeo, as como para desarrollar los modelos fuente de pruebas a ser transformados. Aunque Eclipse proporciona EMF, el plug-in UML 2.0 para Eclipse [88] y el mecanismo de proling de este plug-in, se requiere que el meta-modelo U2TP sea escrito en Java desde cero. El plug-in UML2 est basado sobre el meta-modelo a UML 2.0 [80] pero proporciona una realizacin espec o ca de ste en el contexto e de EMF. Esto permite desarrollar un plug-in U2TP para Eclipse e integrarlo con el plug-in TTCN-3 de Eclipse [34]. Mtodo de transformacin e o Esta propuesta dene una transformacin de modelos de U2TP a modelos o TTCN-3. A partir de TTCN-3 se proporciona una generacin de pruebas ejeo cutables, tambin se proporciona una traduccin directa hasta obtener el cdie o o go de prueba. Basados en las especicaciones de un U2TP concreto, el usuario est habilitado para generar cdigo TTCN-3. La idea es proporcionar las rea o glas de transformacin que permitan mapear los conceptos en el nivel de metao modelo. Sin embargo, las transformaciones por s mismas son ejecutadas en el nivel de modelo. En general, es posible un mapeo de TTCN-3 a U2TP, pero no al revs. e Para el mapeo de U2TP a TTCN-3, las restricciones en el nivel U2TP son necesarias para restringir las deniciones de U2TP para modelos ejecutables. Seguidamente, se asume que los modelos U2TP pueden ser mapeados a TTCN3. El mtodo principal referente al mapeo a TTCN-3, consiste de dos pasos e

44

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

Figura 2.10: Transformacin PIT/PST en U2TP para pruebas en TTCN-3 [94]. o principales. Los estereotipos y las asociaciones U2TP son seleccionados y asignados a conceptos TTCN-3. Posteriormente, son denidos los procedimientos para recopilar informacin requerida para los mdulos generados TTCN-3 [87]. o o En la Figura 2.10, la aplicacin espec o ca de la transformacin U2TP para o TTCN-3 es considerada en el framework general de pruebas basadas en MDA a [75], donde las pruebas independientes de la plataforma (PIT) estn relacionadas con los modelos de sistemas independientes de la plataforma (PIM) y las pruebas espec cas de la plataforma (PST) estn relacionadas con los modelos espec a cos de la plataforma. Se provee un mapeo del diseo de pruebas abstracto en U2TP n a un nivel tcnico detallado en TTCN-3. e Posteriormente, el cdigo de prueba generado es completado en TTCN-3 y o cambiado en cdigo de pruebas ejecutable. La traduccin de PITs a PSTs para o o una plataforma objetivo espec ca, no es considerado en la propuesta. La forma de obtener el cdigo de prueba del repositorio TTCN-3 es ejecuo e tado usando un compilador TTCN-3 (por ejemplo TTthree [34]). Despus de la provisin de un adaptador de prueba, pueden ser ejecutadas las pruebas, o originalmente diseadas en U2TP. n El mapeo de reglas dene la conexin entre los nodos apropiados del metao modelo fuente y destino. Estos nodos son estereotipos (y extensiones de metaclases UML), tipos primitivos o interfaces en el caso de U2TP y meta-clases en el caso del meta-modelo TTCN-3. 2.3.3.3 Pruebas dirigidas por modelos usando U2TP En este art culo, Prez et al. [63] presentan una propuesta para pruebas en e el contexto de la ingenier dirigida por modelos. A partir de los modelos de a diseo del sistema en UML, se propone realizar transformaciones a modelos de n prueba basados en el perl de pruebas de UML. Para que la generacin de los casos de prueba sea automtica, se dene o a

2.3. TRABAJOS RELACIONADOS CON ENFOQUE MDA

45

una extensin del meta-modelo de UML, de forma que se puedan anotar los o diagramas de secuencia con informacin que, luego, pueda ser utilizada para o generar el orculo de pruebas. Esta informacin es anotada en OCL como pre a o y post-condiciones en el diagrama. Se presenta una propuesta para la generacin automtica de casos de prueo a ba en el contexto de MDA, basada en el meta-modelo de UML 2 y el perl de pruebas de UML, realizando transformaciones desde los modelos UML al modelo de pruebas, utilizando como modelo de descripcin de comportamieno to del sistema el diagrama de secuencia de UML. Dentro de la propuesta se aborda la generacin automtica de los orculos de las pruebas ya que stos o a a e son dependientes del dominio de la aplicacin. Este hecho hace necesario anotar o los modelos con informacin adicional durante el diseo para poder generar los o n orculos. Dado que la propuesta de este art a culo est basada en MDA, se prea senta una extensin al meta-modelo del diagrama de secuencia de UML para o representar la informacin dependiente del dominio como pre y post-condiciones o anotadas usando OCL que servir posteriormente para generar los orculos de a a las pruebas. Los diagramas de secuencia extendidos con pre y post-condiciones son transformados posteriormente en modelos de prueba que son instancias del UMLTP. En las pruebas dirigidas por modelos resulta imprescindible poder generar casos de prueba completos en forma automtica. Esto incluye representar la a informacin dependiente del dominio para las pruebas en los modelos UML y o poder transformarla luego en el orculo de pruebas en los distintos modelos de a prueba. Adems, la propuesta aade una pequea extensin al meta-modelo de UML a n n o para agregar la informacin requerida para el orculo de las pruebas en los o a diagramas de secuencia: puesto que un diagrama de secuencia se corresponde con un escenario relevante que debe ser probado, el diagrama se anota de forma que incluya informacin sobre el resultado esperado y el estado inicial del mismo. o En la Figura 2.11 se muestra la extensin del meta-modelo de UML denida, o donde en la clase InteractionFragment se le agrega una Constraint de OCL, y dos relaciones, una que representa la precondicin del diagrama de secuencia o y otra que representa sus post-condiciones. Se agrega tambin una restriccin e o que indica que dichas pre y post-condiciones no se aplican especializaciones InteractionFragment de tipo StateInvariant. Un InteractionFragment es un fragmento de interaccin, por lo que la semntio a ca de la extensin propuesta es que cualquier segmento de una interaccin puede o o tener una pre y post-condicin a ser utilizada como orculo para las pruebas. o a Esto permite poder derivar casos de prueba a distintos niveles (dado que los segmentos se anidan): unitario, de integracin funcionales. o o En la Figura 2.12 (a) se pueden observar los distintos puntos donde se pueden poner pre y post-condiciones. Por ejemplo, la pareja pre1 y pos 1, tienen la informacin necesaria para construir el orculo para todo el diagrama, lo que se o a conoce como una prueba funcional. La pareja pre2 y pos2 dan la informacin o necesaria para construir el orculo para probar la interaccin entre B y C, a o mientras que la pareja pre3 y pos3 permite realizar pruebas unitarias de C. La

46

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

Figura 2.11: Extensin al meta-modelo de UML para las pruebas [63]. o

Figura 2.12: Informacin para el orculo segn el nivel de prueba [63]. o a u

Figura 3 (b) muestra cmo, empleando transformaciones QVT sobre el diagrama o de secuencia extendido se pueden generar modelos de pruebas unitarias, de integracin y funcionales. Siguiendo un enfoque MDA, primero se obtiene el o modelo de pruebas en el nivel deseado y luego dicho modelo es renado segn u la plataforma, en caso de que el lenguaje sea Java, podr amos derivar casos de prueba en JUnit. Las transformaciones son realizadas utilizando QVT [66]. A partir del diagrama de clases (que representa la arquitectura del sistema) y de los diagramas de secuencia extendidos con pre y post-condiciones (que representan el comportamiento), se realizan las transformaciones para llegar al modelo de pruebas. Primero se construye la arquitectura del modelo de pruebas a partir de la arquitectura del sistema y de los modelos que representan el comportamiento (en este caso, diagramas de secuencia). Una vez construida la arquitectura de sistema de pruebas se genera el comportamiento asociado a cada uno de los casos de prueba mediante un diagrama de secuencia.

 2.4. DISCUSION

47

2.4.

Discusin o

El objetivo de este apartado es identicar las oportunidades de investigacin o a partir de los trabajos relacionados expuestos. Esta identicacin se realiza o teniendo en cuenta las ventajas y desventajas de cada propuesta. En primer lugar, la propuesta de Dai descrita en la sub-seccin 2.3.3.1 introo duce una metodolog acerca de cmo usar el prole U2TP a n de transformar a o un modelo de diseo de sistema UML en modelos de pruebas. Presenta la denin cin de las reglas de transformacin, pero el inconveniente es que an no estn o o u a totalmente completadas. Por lo tanto, es un frente abierto para futuros trabajos. Tambin debido a la falta de herramientas de soporte para UML 2.0 y U2TP, e no estn en condiciones para probar las reglas de transformacin. Dai expresa a o que en sus trabajos futuros, investigarn en herramientas que soporten los cona ceptos U2TP y la derivacin automatizada de modelos de diseo de prueba a o n partir de modelos de diseo del sistema. Por tanto, no se contempla el desarrollo n de una herramienta de automatizacin del proceso. o Por otro lado, la propuesta de Zander et al. [94]; la cual est descrita en la a sub-seccin 2.3.3.2, presenta un mtodo para derivar automticamente las prueo e a bas ejecutables a partir de diagramas UML, usando el prole UML 2.0 Testing Prole. En la propuesta se presenta una transformacin entre las especicao ciones de UML 2.0 Testing Prole (U2TP [64]) usadas para representar PITs y Testing and Test Control Notation (TTCN-3 [87]). La principal ventaja de esta propuesta es que proporciona las reglas de transformacin entre el meta-modelo o U2TP [64] y el meta-modelo TTCN-3. Otra de las ventajas de este mtodo es que presenta un ambiente de ejecucin e o automtico, Eclipse fue usado para demostrar la viabilidad de este trabajo junto a al plug-in UML 2.0 [88] y otro desarrollado para soportar U2TP. Tambin usan e un plug-in para soportar TTCN-3. Los modelos con conceptos U2TP la integran con la plataforma Eclipse, como lo hace el equipo de Objecteering (vase la sub-seccin 2.3.2.1). Tambin se e o e desarrolla transformacin de modelos de U2TP para TTCN-3 como los ofrecidos o por Telelogic, pero en este trabajo se dene las reglas en el nivel de meta-modelo usando los mtodos disponibles en Eclipse para implementarlos. e Finalmente, la propuesta de Prez et al., presentan una propuesta para pruee bas en el contexto de la ingenier dirigida por modelos. A partir de los modelos a de diseo del sistema en UML, se propone realizar transformaciones a modelos n de prueba basados en el perl de pruebas de UML. Esta propuesta tiene como ventaja principal el tratamiento de los orculos de prueba, del cual se puedan a derivar los datos de prueba en forma automtica. Para esto han denido una exa tensin del meta-modelo de UML donde se expresan las pre y post-condiciones o de cada diagrama de secuencia mediante el lenguaje OCL. Esta propuesta no cuenta con una herramienta de automatizacin que permita ayudar a validar la o propuesta. A continuacin, en la tabla 2.4 se presenta todas las propuestas estudiadas, o tanto las propuestas empresariales, as como tambin las propuestas acadmicas. e e La tabla muestra las caracter sticas necesarias que cubren los tres desaf de os

48 CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

Tabla 2.4: Cuadro de oportunidades.

Dai [20] Desaf 1 o Desaf 2 o Desaf 3 o Orculos de prueba a Automatizacin del o proceso Enfoque MDA Reglas de transformacin o Enfoque MDWE Basados en navegacin o

Propuestas acadmicas e Zander at al. [94] Prez et al. [63] e

Objecteering Software [79]

Propuestas empresariales Test Designer [90] Telelogic TAU [82]

Incompletas Semi-automticas a Desconocidos

 2.4. DISCUSION pruebas de software que vamos a abordar en nuestra propuesta:

49

Desaf 1: Para conseguir este desaf es necesario obtener un mtodo que o o, e provea las salidas esperadas de cada caso de prueba dado; es decir, obtener un orculos de pruebas eciente. Para ms detalle acerca de este desaf a a o, vase la sub-seccin 2.1.2. e o Desaf 2: Para conseguir el desaf de las pruebas 100 % automticas, o o a es necesario que los procesos de pruebas propuestos sean automatizados. Para ms detalle sobre este desaf vase la sub-seccin 2.1.3. a o, e o Desaf 3: Para conseguir el desaf de las pruebas basadas en modelos, o o se considera que el proceso propuesto debe de tener las siguientes caracter sticas: el enfoque MDA o enfoque MDWE, proporcionar las reglas de transformacin necesarias, y en el caso de aplicaciones Web, estar basados o en modelos navegacionales. Para ms detalle acerca de este desaf vase a o, e sub-seccin 2.1.4. o Con el s mbolo se seala las propuestas que s cumplen con la caracter n stica especicada. Por el contrario, el s mbolo seala que no las cumplen. El n s mbolo indica que aunque la propuesta cumple la caracter stica, no la cubre completamente; es decir, est incompleta. El s a mbolo indica que la automatizacin es semi-automtica. Finalmente, el s o a mbolo seala que aunque la n caracter stica es abordada, son desconocidos los detalles que cubren la caracter stica. De esta manera, con la ayuda de este cuadro comparativo identicamos las oportunidades de investigacin, y a partir de stas, en el siguiente cap o e tulo planteamos nuestros objetivos de la propuesta de investigacin. Por lo tanto, o destacamos las siguientes oportunidades esenciales: La primera oportunidad es referente al tratamiento de los orculos de prueba, a segn Bertolino, este es el principal obstculo para conseguir una automatizacin u a o 100 % del proceso de pruebas. Los orculos de pruebas en un contexto MDA, son a abordados solamente por Prez et al., pero slo con los artefactos de diagramas e o de secuencia. Entonces, un importante desaf es el conseguir los mecanismos o ecientes para obtener un orculo de pruebas robusto, ya que an se carece de a u mtodos que nos lo proporcionen. e El cuadro tambin reeja que todas las propuestas enunciadas estn basadas e a en el enfoque MDA, pero no todas proporcionan las reglas de transformacin o necesarias para este enfoque. Si bien es cierto, las propuestas empresariales cubren esta caracter stica, se desconoce el detalle y naturaleza de stas. Existen, e algunas propuestas acadmicas que presentan reglas de transformacin, pero e o estn incompletas. a La ultima oportunidad y la ms importante para nuestra investigacin es a o que las propuestas, ya sean acadmicas o empresariales, no estn orientadas al e a desarrollo de aplicaciones Web. Por lo tanto, no utilizan el enfoque MDWE y no estn basados en los modelos navegacionales. a

50

CAP ITULO 2. ESTUDIO DE LA SITUACION ACTUAL

El siguiente cap tulo presenta nuestra propuesta de investigacin, en base a o las oportunidades planteadas, tomando los puntos fuertes de los trabajos relacionados e intentando rellenar los vac metodolgicos de dichas propuestas. os o

Cap tulo 3

Proyecto de investigacin o
La seccin anterior present los actuales desaf en las pruebas de software, y o o os a partir de stos, se identicaron las oportunidades de investigacin relacionadas e o con el desarrollo del proceso de pruebas en un contexto de transformacin de o modelos. Es as que, en esta seccin, se presenta de manera detallada nuestra propues o ta, la cual, aprovechando las oportunidades identicadas en el anlisis de esta a investigacin, pretende cubrir los grandes desaf de las pruebas de software: o os los orculos de pruebas, las pruebas 100 % automticas y las pruebas basadas a a en modelos. Todos ellos destinados a conseguir un desarrollo seguro y eciente de las aplicaciones Web. El aspecto ms novedoso de la propuesta es proporcionar un mtodo de a e pruebas de sistema a partir de modelos navegacionales mediante el paradigma MDWE. Nos basamos en dichos modelos, debido a su gran importancia (ver seccin 1.1) en el desarrollo de aplicaciones Web. o Las siguientes sub-secciones detallan la propuesta del proyecto de investigacin. La seccin 3.1 presenta la hiptesis y los objetivos trazados a n de o o o cumplir la hiptesis planteada. Seguidamente, en la seccin 3.2 se presenta la o o metodolog de trabajo. Finalmente, la seccin 3.3 muestra el plan de trabajo a o tentativo durante la investigacin. o

3.1.

Hiptesis y objetivos o

El objetivo principal de este proyecto de investigacin es mejorar las tcnio e cas de garant de calidad en el desarrollo de aplicaciones Web. Para ello, nos a centraremos en el desarrollo de una tcnica de pruebas de nivel de sistema a e partir de modelos navegacionales. Por consiguiente, nuestra hiptesis es que el mtodo de pruebas de sistema o e para la navegacin a partir de modelos navegacionales, mediante el paradigma o MDWE, puede ser usado para mejorar las pruebas de las aplicaciones Web, y por consiguiente, mejorar su seguridad y abilidad. 51

52

CAP ITULO 3. PROYECTO DE INVESTIGACION

Figura 3.1: Propuesta de investigacin. o En la Figura 3.1 se presenta de manera esquemtica nuestra propuesta. Los a modelos de requisitos mostrados en la gura, pertenecen a la metodolog NDT a [27]. Los siguientes objetivos forman parte de la investigacin: o

3.1.1.

Objetivo 1

Obtener el modelo de pruebas de sistema basado en transformacin o PIM to PIM. Se crearn los algoritmos necesarios para la obtencin del a o modelo de pruebas navegacionales de sistema a partir de los modelos navegacionales, esta transformacin est enmarcada dentro de los modelos de diseo o a n independientes de la plataforma (PIM), y debido a que tanto el modelo ori-

 3.1. HIPOTESIS Y OBJETIVOS

53

gen, as como tambin el modelo destino son PIM, ser necesario realizar una e a transformacin PIM to PIM. En la Fig. 3.1 se muestra la ubicacin de esta o o transformacin marcado con la letra A. o

3.1.2.

Objetivo 2

Obtener el modelo de pruebas de sistema espec co basado en transformacin PIM to PSM. En el nivel PIM, el modelo conceptual, el modelo o navegacional y el modelo de interfaz abstracta son integrados y transformados en un modelo que representa una visin global del sistema (Big Picture). Es o as que, una vez obtenido el modelo de pruebas navegacionales del sistema en el nivel PIM, con ayuda de la especicacin denotada en Big Picture, ser neceo a sario obtener un modelo de prueba de sistema espec co de la plataforma en estudio; por ejemplo, modelos de pruebas para J2EE, .NET, etc. Para conseguir este modelo, se utilizar una transformacin PIM to PSM (letra B en la Figura a o 3.1). Se dotar de las reglas y algoritmos necesarios para cumplir el objetivo en a cuestin. o

3.1.3.

Objetivo 3

Obtener los casos de prueba navegacionales basados en transformacin PSM to Code. Una vez obtenido el modelo de pruebas de sistema eso pec co para una plataforma, podremos generar los casos de prueba. Para ello, se utilizar una transformacin PSM to Code (letra C en la Figura 3.1), donde a o tambin ser necesario denir la sintaxis y semntica de los casos de prueba a e a a obtener.

3.1.4.

Objetivo 4

Desarrollar una herramienta de automatizacin del proceso. Un objeo tivo del trabajo es proveer una herramienta que capte los algoritmos realizados y que sea util para la automatizacin de todo el proceso. Esta herramienta o formar parte de NDT Suite [81]. a

3.1.5.

Objetivo 5

Evaluacin de la propuesta. Evaluar el resultado del proceso con la metoo dolog NDT [27]. La metodolog de estudio ser NDT, pues sus modelos se a a a obtienen por transformacin de modelos, y adems por tener reconocida aplio a cabilidad en diversos proyectos acadmicos y empresariales. NDT surgi como e o resultado de un trabajo de investigacin dentro del grupo [27], y nuestra propueso ta lo abordar para continuar con la labor del grupo. Para evaluar la hiptesis, a o se van a desarrollar tcnicas de generacin de pruebas de sistema basados en e o meta-modelos y se comparar la eciencia con otras tcnicas que no utilizan a e este tipo de enfoque.

54

CAP ITULO 3. PROYECTO DE INVESTIGACION

Figura 3.2: Mtodos de investigacin: (A) de ingenier (B) emp e o a; rico.

3.2.

Metodolog de trabajo. a

as o En [83], Richards identica cuatro metodolog de investigacin en la Ingenier del Software. El mtodo cient a e co: observa el mundo, propone un modelo o teor de comportamiento, mide y analiza, valida la hiptesis del modelo o a o teor y lo repite si fuera posible; el mtodo de ingenier (paradigma evoa, e a lutivo): observa soluciones existentes, propone mejores soluciones, construye o desarrolla, mide y analiza, y lo repite hasta que no fuera posibles nuevas mejoras; el mtodo emp e rico (paradigma revolucionario): propone un modelo, desarrolla estad sticas u otros mtodos, lo aplica a casos de estudio, valida el modelo y lo e repite; el mtodo anal e tico: propone una teor formal o conjunto de axiomas, a desarrolla una teor deriva resultados y si fuera posible los compara con otras a, observaciones emp ricas. En base al conjunto de metodolog presentado, nuestro proyecto de inas vestigacin se basar principalmente en dos de estos mtodos: el mtodo de o a e e ingenier y el mtodo emp a e rico. La Figura 3.2 muestra ambos mtodos de una e manera esquemtica con la ayuda de los diagramas de actividades de UML. a Espec camente, utilizaremos el mtodo de ingenier para obtener la mejor e a solucin en cuanto a transformacin de modelos se reere. Es decir, cuando se o o intente conseguir los tres primeros objetivos de la investigacin enunciados en o la sub-seccin anterior y que se muestran de manera grca en la Figura 3.3. En o a nuestra propuesta, en los puntos A, B y C ser utilizado el mtodo de ingenier a e a o mtodo evolutivo. En tanto, el mtodo emp e e rico ser utilizado para cumplir a el objetivo de validacin y evaluacin de la propuesta. o o

3.2. METODOLOG DE TRABAJO. IA

55

Figura 3.3: Metodolog de investigacin aplicada en la propuesta. a o

56

CAP ITULO 3. PROYECTO DE INVESTIGACION

Figura 3.4: Planicacin del proyecto de investigacin. o o

3.3.

Plan de trabajo

Este apartado presenta el plan de trabajo del proyecto de investigacin, el o cual tiene una duracin total aproximada de tres aos. De manera general, o n la subdivisin de tareas durante este per o odo se ha realizado a nivel de los objetivos del proyecto. La Figura 3.4 muestra de manera ms detallada los a tiempos establecidos para cumplir cada objetivo. Adems, se tiene en cuenta a que durante este per odo se incluye la redaccin de la tesis hasta llegar a la o versin denitiva. o Adems, durante el per a odo de elaboracin del proyecto, se prev realizar o e publicaciones a medida que se obtengan resultados. En las siguientes sub-secciones se muestran algunos foros importantes en el contexto de esta investigacin. o

3.3.1.

Journals

The Journal of Software Testing, Verication and Reliability: Esta publicacin est orientada al mbito acadmico. Est editada por o a a e a John Wiley & Sons, Inc. http://www3.interscience.wiley.com/journal/13635/home The Journal of International Institute for Software Testing: Esta es una publicacin del Instituto Internacional para Pruebas de Software o

3.3. PLAN DE TRABAJO

57

(IIST). Est dirigida tanto a organizaciones educativas como organizaa ciones empresariales. http://www.testinginstitute.com/journal.php

3.3.2.

Congresos

International Symposium on Software Testing and Analysis (ISSTA): ISSTA es un simposio que se celebra cada dos aos y es conferencia n l der en el campo de la prueba y anlisis del software. a http://www.cse.msu.edu/issta09/#Welcome ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems: Conferencia internacional UML para Ingenier dirigida por modelos. a http://www.modelsconference.org/ ICWE 2009 - International Conference on Web Engineering 2009: ICWE es una conferencia internacional de gran renombre en el rea de la a Ingenier Web. a http://icwe2009.webengineering.org/ ECMDA 2009 - Fifth European Conference on Model Driven Architecture R Foundations and Applications http://ecmda2009.utwente.nl/ CAiSE09 - The 21st International Conference on Advanced Information Systems Engineering http://caise09.thenetworkinstitute.eu/ ISD 2009 - The 18th International Conference on Information Systems Development http://sit.jxufe.cn/isd2009/ ICEIS 2009 - 11th International Conference on Enterprise Information Systems http://www.iceis.org/ JISBD 2009 - XIV Jornadas de Ingenier del Software y Bases a de Datos http://www.mondragon.edu/jisbd2009/

58

CAP ITULO 3. PROYECTO DE INVESTIGACION

3.3.3.

Workshops

5th Model-Based Testing Workshop http://react.cs.uni-sb.de/mbt2009/ 5th Model-Driven Web Engineering Workshop http://mdwe2009.pst.ifi.lmu.de/

Cap tulo 4

Conclusiones
El desarrollo de esta investigacin ha resaltado una serie de aspectos imporo tantes con relacin a las aplicaciones Web. Debido a la creciente complejidad de o estas aplicaciones, el campo de la Ingenier Web se ha desarrollado de manea ra muy acelerada. Pero desafortunadamente, dicha complejidad no est acoma paada de los mecanismos adecuados que garanticen la calidad de este tipo de n aplicaciones. Es en el mbito de la Ingenier Web donde se ha evaluado la necesidad de a a estudiar de manera concreta una caracter stica del software, que, en los ulti mos aos, est denindose como cr n a e tico dentro del proceso de desarrollo: la navegacin. o Se present (ver seccin 1.1) la necesidad del tratamiento adecuado de la o o navegacin en la Ingenier Web, la cual es una de las caracter o a sticas que est llea vando a diversos grupos de investigacin a proponer nuevos modelos y tcnicas o e adecuadas para su tratamiento. Entre los estudios de grupos de investigacin, se concluye que el modelo o navegacional juega un papel preponderante, ya que la navegabilidad de una aplicacin Web est relacionada con las caracter o a sticas de calidad de este tipo de aplicaciones. El contexto de esta investigacin se centra en asegurar el xito de la imo e plantacin de aplicaciones Web. Para asegurar la calidad de este software, se o mostr que la tcnica de pruebas es uno de los mtodos ms ecaces (ver seco e e a cin 1.2). Entre los niveles de prueba existentes, las pruebas de sistema son de o nuestro inters porque se permiten probar y vericar el cumplimiento de los e requisitos de negocio de la aplicacin. Es as que, nuestra investigacin se eno o foca en las pruebas de sistema de las aplicaciones Web basadas en los modelos navegacionales, por la importancia expuesta de este tipo de aplicaciones. Por otro lado, existen diversas propuestas metodolgicas para el desarrollo o de aplicaciones Web, en donde el modelado de la navegacin suele ser dependieno te de la metodolog utilizada. La propuesta de nuestra investigacin pretende a o ser genrica; es decir, realizar las pruebas de sistema basados en modelos navee gacionales independientemente de la metodolog escogida. Para conseguir tal a 59

60

CAP ITULO 4. CONCLUSIONES

objetivo, nos enfocamos en el paradigma guiado por modelos (MDWE). Pues, los niveles de abstraccin de MDA pueden tambin aplicarse al modelado de o e pruebas. Perao para las cuestiones de validacin de la propuesta y para cono tinuar con la labor de nuestro grupo de investigacin, usaremos los modelos de o NDT. Debido a la creciente complejidad de los sistemas de software, acoplar tempranamente las pruebas dentro del proceso de desarrollo es cada vez ms impora tante. Al hacerlo, los errores de diseo y fallas de implementacin pueden ser n o detectados en una fase temprana del proceso de diseo. Esto permite la reducn cin de tiempo y costos. Adicionalmente, las pruebas desarrolladas pueden ser o ejecutadas en el sistema que ha sido entregado al cliente con el n de comprobar su correcto comportamiento en el ambiente del cliente. Tambin, uno de los aspectos importantes mostrados, son los relacionados e con los actuales desaf en las pruebas de software, y a partir de stos, se os e identicaron las oportunidades de investigacin relacionadas con el desarrollo o del proceso de pruebas en un contexto de transformacin de modelos. o En base a todos los aspectos mencionados, se present de manera detallada la o propuesta de investigacin, la cual aprovechando las oportunidades identicadas o en el anlisis de esta investigacin, pretende cubrir los grandes desaf de las a o os pruebas de software destinados a conseguir un desarrollo seguro y eciente de las aplicaciones Web.

Bibliograf a
[1] S. Abrahao, N. Condori-Fernndez, L. Olsina, and O. Pastor. Dening a and validating metrics for navigational models. Software Metrics, IEEE International Symposium on, 0:200210, 2003. [2] F. Ahmed and L.F. Capretz. Best practices of rup line development. pages 13631366, May 2008.
R

in software product

[3] A.A. Andrews, J. Outt, and R. T. Alexander. Testing web applications by modeling with fsms. In Software and Systems Modeling, volume 4, pages 326245. Springer, 2005. [4] ArcStyler. http://www.arcstyler.com/. [5] L. Baresi, S. Colazzo, L. Mainetti, and S. Morasca. W2000: A modelling notation for complex web applications. In Web Engineering, pages 335364, 2006. [6] L. Baresi, F. Garzotto, L. Mainetti, and P. Paolini. Meta-modeling techniques meet web application design tools. In Fundamental Approaches to Software Engineering, pages 182206, 2002. [7] L. Baresi and M. Youngh. Test oracles. Technical report, Dept. of Comp. and Information Science, Univ. of Oregon, 2001. [8] B. Beizer. Black-Box Testing: Techniques for Functional Testing of Software and Systems. John Wiley & Sons, Inc., 1995. [9] A. Bertolino. Software testing research: Achievements, challenges, dreams. In FOSE 07: 2007 Future of Software Engineering, pages 85103, Washington, DC, USA, 2007. IEEE Computer Society. [10] A. Bertolino, E. Marchetti, and H. Muccini. Introducing a reasonably complete and coherent approach for model-based testing. Electronic Notes in Theoretical Computer Science, 116:8597, jan 2005. [11] J. Bzivin. On the unication power of models. In Software and System e Modeling. 61

62 [12] J. Bzivin. From e mda. In TOOLS and Exhibition on (TOOLS39), page ciety.

BIBLIOGRAF IA object composition to model transformation with the 01: Proceedings of the 39th International Conference Technology of Object-Oriented Languages and Systems 350, Washington, DC, USA, 2001. IEEE Computer So-

[13] R. Binder. Testing Object-Oriented Systems. Addison Wesley, 2000. [14] M. Born, I. Schieferdecker, H.-G. Gross, and P. Santos. Model-driven development and testing - a case study. 2004. [15] M. Boshernitsan, R. Doong, and A. Savoia. From daikon to agitator: lessons and challenges in building a commercial tool for developer testing. In ISSTA 06: Proceedings of the 2006 international symposium on Software testing and analysis, pages 169180, New York, NY, USA, 2006. ACM Press. [16] P. Bourque and R. Dupuis. Guide to the software engineering body of knowledge 2004 version. Guide to the Software Engineering Body of Knowledge, 2004. SWEBOK, 2004. [17] M. Busch, R. Chaparadza, Z.R. Dai1, A. Homann, L. Lacmene, T. Ngwangwen, G.C. Ndem, H. Ogawa, D. Serbanescu, I. Schieferdecker, and J. Zander-Nowicka. Model transformers for test generation from system models. Technical report, Fraunhofer FOKUS, Germany and Hitachi Central Research Laboratory Ltd., Japan, 2006. [18] C. Cachero and N. Koch. Conceptual navigation analysis: a device and platform independent navigation specication. 2nd International Workshop on Web-oriented Software Technology (IWWOST02), Jun 2002. [19] S. Ceri, P. Fraternali, and A. Bongio. Web modeling language (webml): a modeling language for designing web sites. Comput. Netw., 33(1-6):137 157, 2000. [20] Z. R. Dai. Model-driven testing with uml 2.0. In Proceedings of the Second European Workshop on Model Driven Architecture, pages 179187, Canterbury, UK, 2004. Computing Laboratory, University of Kent. [21] Z. R. Dai, P. H. Deussen, L. P. Lacmene M. Busch, T. Ngwangwen, J. Herrmann, and M. Schmidt. Automatic test data generation for ttcn-3 using cte. In ICSSEA 2005: 18th International Conference Software & Systems Engineering and their Applications, Paris, 11 2005. [22] Zhen Ru Dai, Jens Grabowski, Helmut Neukirchen, and Holger Pals. From design to test with uml - applied to a roaming algorithm for bluetooth devices. In In TestCom2004, 2004. [23] Maria Cristina Ferreira de Oliveira, Marcelo Augusto Santos Turine, and Paulo Cesar Masiero. A statechart-based model for hypermedia applications. ACM Trans. Inf. Syst., 19(1):2852, 2001.

BIBLIOGRAF IA

63

[24] M.S. Deutsch. Tutorial series 7 software project verication and validation. Computer, 14(4):5470, 1981. [25] G.A. Di Lucca and M. Di Penta. Considering browser interaction in web application testing. pages 7481, Sept. 2003. [26] K. Duddy, A. Gerber, M. Lawley, K. Raymond, and J. Steel. Model transformation: A declarative, reusable patterns approach. In EDOC, pages 174185. IEEE Computer Society, 2003. [27] M.J. Escalona. Modelos y tcnicas para la especicacin y el anlisis de la e o a Navegacin en Sistemas Software. PhD thesis, University of Seville, Seville, o Spain, 2004. [28] Eclipse Modelling Framework. http://www.eclipse.org/emf/. [29] F. Garzotto, P. Paolini, and D. Schwabe. Hdma model-based approach to hypertext application design. ACM Trans. Inf. Syst., 11(1):126, 1993. [30] W. Grieskamp. Multiparadigmatic modelbased testing. In Formal Approaches to Software Testing and Runtime Verication, volume 4262/2006, page 119, Berlin, 11 2006. Springer. [31] H. Gross. Testing and the uml a perfect t. Technical report, Fraunhofer IESE Report 110.03E, 2003. [32] J.J. Gutierrez, M.J. Escalona, M. Mejias, J. Torres, and A.H. Torres. A case study for generating test cases from use cases. In Research Challenges in Information Science, 2008. RCIS 2008. Second International Conference on, pages 209214. IEEE Computer Society, June 2008. [33] L. Heuser. The real world or web engineering? In Proceedings of the 4th International Conference on Web Engineering, volume 3140, page 15, Berlin, 06 2004. Springer. [34] Testing Technologies: TTworkbench http://www.testingtech.de. TTCN-3 IDE in Eclipse.

[35] T. Isakowitz, E.A. Stohr, and P. Balasubramanian. Rmm: a methodology for structured hypermedia design. Commun. ACM, 38(8):3444, 1995. [36] iUML. http://www.kc.com/products/iuml.php. [37] L. Jin-hua, L. Qiong, and L. Jing. The w-model for testing software product lines. Computer Science and Computational Technology, International Symposium on, 1:690693, 2008. [38] JUnit.org. http://www.junit.org/index.htm. [39] N. Koch. A comparative study of methods for hypermedia development. Technical report, Ludwig-Maximilians-Universitt Mnchen, Novema u ber 1999.

64

BIBLIOGRAF IA

[40] N. Koch. Software Engineering for Adaptative Hypermedia Applications. PhD thesis, FAST Reihe Softwaretechnik, Munich, Germany, 2001. [41] N. Koch, G. Zhang, and M.J. Escalona. Model transformations from requirements to web system design. In ICWE 06: Proceedings of the 6th international conference on Web engineering, pages 281288, New York, NY, USA, 2006. ACM. [42] Nora Koch. Transformation techniques in the model-driven development process of uwe. In ICWE 06: Workshop proceedings of the sixth international conference on Web engineering, page 3, New York, NY, USA, 2006. ACM. [43] D.C. Kung, Chien-Hung Liu, and Pei Hsia. An object-oriented web test model for testing web applications. pages 111120, 2000. [44] Unied Modeling Language. http://www.uml.org/. [45] K.R.P.H. Leung, L.C.K. Hui, S.M. Yiu, and R.W.M. Tang. Modeling web navigation by statechart. pages 4147, 2000. [46] C.H. Liu, D. C. Kung, P. Hsia, and C.T. Hsu. Structural testing of web applications. In ISSRE 00: Proceedings of the 11th International Symposium on Software Reliability Engineering, page 84, Washington, DC, USA, 2000. IEEE Computer Society. [47] J.-P. Katoen M. Leucker M. Broy, B. Jonsson and editors. A. Pretschner. Model-based testing of reactive systems. In Advanced Lectures, volume 3472. Springer, 11 2005. [48] SD Metrics. http://www.sdmetrics.com/. [49] AllFusion Component Modeler. http://www.astrom.se/allfusion/. [50] MOF. http://www.omg.org/technology/documents/formal/mof.htm. [51] E.F. Moore. Gedanken experiments on sequential machines. In Automata Studies, pages 129153. Princeton U., 1956. [52] N. Moreno and P.and Vallecillo A. Fraternalli. A uml 2.0 prole for webml modeling. In ICWE 06: Workshop proceedings of the sixth international conference on Web engineering, page 4, New York, NY, USA, 2006. ACM. [53] G. Myers. The Art of Software Testing. John Wiley & Sons, Inc., 2004. [54] C. Nebut, F. Fleurey, Y.L. Traon, and J.M. Jezequel. Automatic test generation: A use case driven approach. IEEE Transactions on Software Engineering, 32(3):140155, 2006. [55] NetBeans. http://www.netbeans.org/.

BIBLIOGRAF IA [56] J. Nielsen. Designing Web Usability. New Riders, 2000. [57] Model Driven Architecture OMG. http://www.omg.org/mda/.

65

[58] J. Palmer. Designing for web site usability. Computer, 35(7):102103, Jul 2002. [59] J.W. Palmer. Web Site Usability, Design, and Performance Metrics. INFORMATION SYSTEMS RESEARCH, 13(2):151167, 2002. [60] S. Pietsch and B. Stanca-Kaposta. Model-based testing with utp and ttcn-3 and its application to hl7. Technical report, Conquest Potsdam, Germany, september 2008. [61] Poseidon. http://www.gentleware.com/. [62] R. S. Pressman. Ingenier del Software. Un enfoque prctico. MacGrawa a Hill, 5a edition, 2001. [63] B. Prez, P. Reales, I. Garc and M. Polo. Propuesta para pruebas die a, rigidas por modelos usando el perl de pruebas de uml 2.0. Actas de los Talleres de las Jornadas de Ingenier del Software y Bases de Datos, 2008. a [64] UML Testing Prole. http://utp.omg.org/. [65] Y. Qi, D. Kung, and E. Wong. An agent-based testing approach for web applications. In COMPSAC 05: Proceedings of the 29th Annual International Computer Software and Applications Conference, pages 4550, Washington, DC, USA, 2005. IEEE Computer Society. [66] QVT. http://tefkat.sourceforge.net/publications/ad-04-01-06.pdf. [67] W. Retschitzegger and W. Schwinger. Towards modeling of dataweb applications - a requirements perspective, 2000. [68] Rhapsody. http://www.telelogic.com/products/rhapsody/index.cfm. [69] Filippo Ricca and Paolo Tonella. Analysis and testing of web applications. In ICSE 01: Proceedings of the 23rd International Conference on Software Engineering, pages 2534, Washington, DC, USA, 2001. IEEE Computer Society. [70] G. Rossi. An Object Oriented Method for Designing Hipermedia Applications. PhD thesis, PUC-Rio, RJ, Brazil, 1996. [71] Matthew J. Rutherford, Antonio Carzaniga, and Alexander L. Wolf. Simulation-based test adequacy criteria for distributed systems. In SIGSOFT 06/FSE-14: Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering, pages 231241, New York, NY, USA, 2006. ACM.

66

BIBLIOGRAF IA

[72] David Sa and Michael D. Ernst. An experimental evaluation of continuous testing during development. In ISSTA 04: Proceedings of the 2004 ACM SIGSOFT international symposium on Software testing and analysis, pages 7685, New York, NY, USA, 2004. ACM. [73] Marcelo Augusto Santos Turine, Maria Cristina Ferreira de Oliveira, and Paul Ceasr Masiero. A navigation-oriented hypertext model based on statecharts. In HYPERTEXT 97: Proceedings of the eighth ACM conference on Hypertext, pages 102111, New York, NY, USA, 1997. ACM. [74] A. Schauerhuber, M. Wimmer, and E. Kapsammer. Bridging existing web modeling languages to model-driven engineering: a metamodel for webml. In ICWE 06: Workshop proceedings of the sixth international conference on Web engineering, page 5, New York, NY, USA, 2006. ACM. [75] I. Schieferdecker and G. Din. A meta-model for ttcn-3. In Applying Formal Methods: Testing, Performance, and M/E-Commerce, volume 4, pages 326 245. Springer, 2005. [76] H.A. Schmid and G. Rossi. Modeling and designing processes in e-commerce applications. Internet Computing, IEEE, 8(1):1927, Jan-Feb 2004. [77] L. Shuping and P. Ling. The research of v model in testing embedded software. pages 463466, 29 2008-Sept. 2 2008. [78] J. Siegel. Developing in omgs model-driven architecture. OMG white paper, 2001. [79] Objecteering Software. http://www.objecteering.com/. [80] OMG: UML 2.0 Superstructure Final www.omg.org/cgibin/doc?ptc/2003-08-02. [81] NDT Suite. http://www.iwt2.org/ndt.php. [82] Telelogic Tau. http://www.telelogic.com/products/tau/index.cfm. [83] W.F. Tichy, N. Habermann, and L. Prechelt. Summary of the dagstuhl workshop on future directions in software engineering: February 1721, 1992, schlodagstuhl. SIGSOFT Softw. Eng. Notes, 18(1):3548, 1993. [84] N. Tillmann and W. Schulte. Unit tests reloaded: parameterized unit testing with symbolic execution. Software, IEEE, 23(4):3847, July-Aug. 2006. [85] Together. http://www.borland.com/us/products/together/index.html. [86] O. De Troyer, P. Plessers, and S. Casteleyn. Conceptual view integration for audience driven web design. In WWW (Posters), 2003. [87] TTCN-3. http://www.ttcn-3.org/. Adopted Specication.

BIBLIOGRAF IA [88] Eclipse UML2. http://www.eclipse.org/uml2/.

67

[89] M. Utting and B. Legeard. Practical Model-Based Testing: A Tools Approach. Morgan-Kaufmann, 2006. [90] Test Designer v3.3. http://www.smartesting.com/cms/en/explore/products. [91] C. Viravan. Lessons learned from applying the spiral model in the software requirements analysis phase. Jan 1997. [92] WayPointer. http://www.jaczone.com/product/overview/. [93] Rational XDE. http://www.ibm.com/developerworks/rational/products/xde/. [94] J. Zander, Z.R. Dai, I. Schieferdecker, and G. Din. From u2tp models to executable tests with ttcn-3 - an approach to model driven testing. In Testing of Communicating Systems, volume 3502/2005, page 289303, Berlin, 05 2005. Springer.

68

BIBLIOGRAF IA

Apndice A e

Glosario
CBOP: CIM: DSTC: FSM: HDM: J2EE: MDA: MDD: MDE: Consortium for Business Object Promotion. Computation Independent Model. Distributed Systems Technology Centre. Finite State Machine. Hypermedia Design Methodology. Java 2 Enterprise Edition. Model-Driven Architecture. Model-Driven Development. Model-Driven Engineering. Model-Driven Web Engineering.

MDWE: MOF: NDT:

Meta Object Facility. Navigational Development Techniques.

OCL: Object Constraint Language. OOHDM: OMG: Object-Oriented Hypermedia Design Methodology.

Object Management Group. 69

70 PIM: PIT: PSM: Platform Independent Model. Platform Independent Test. Platform Specic Model.

APENDICE A. GLOSARIO

PST: Platform Specic Test. PUT: QVT: Parameterized Unit Tests. Query/View/Transform.

RDBMS: Relational Database Management System. RMM: Relationship Management Method. SUT: Software Under Test. Testing and Test Control Notation version 3.

TTCN-3:

UML: Unied Modeling Language. UTP: UML Testing Prole.

UWE: UML-Based Web Engineering. U2TP: UML 2.0 Testing Prole.

WebML: Web Modeling Language. .NET: Microsoft XML Web Services platform.

Apndice B e

Curriculum vitae
B.1. Formacin acadmica o e

2006 Actualidad: Doctorado en Tecnolog e Ingenier del Software. a a Universidad de Sevilla, Sevilla, Espaa. n 2003 2005: Mag ster en Ingenier de Computacin. Universidade Esa o tadual de Campinas, So Paulo, Brazil. a T tulo original de la tesis (en portugus): Processo de desenvolvimento e e testes para aplicaes SIG Web. co T tulo de la tesis (en espaol ): Proceso de desarrollo y pruebas para aplin caciones SIG Web. 1996 2001: Bachiller en Ingenier de Sistemas. Universidad Nacional a de San Agust Arequipa, Per. n, u

B.2.

Experiencia profesional

06/2007 Actualidad: Consultor Analista de Aplicaciones, Everis Spain S. L. 11/2006 05/2007: Becario (Fundacin Fidetia), Everis Spain S. L. o 04/2005 10/2005: Ingeniero de Software, Unicamp Brazil 04/2002 02/2003: Programador Web, INFOUNSA Per u 04/2002 06/2002: Profesor de Informtica, CESCA Per a u

B.3.

Proyectos de investigacin o

2008 Actualidad: Ingenier Web y Testing Temprano (IWT2), a 71

72 http://www.iwt2.org/

APENDICE B. CURRICULUM VITAE

. Investigador Principal: Maria Jos Escalona Cuaresma, e http://www.lsi.us.es/~escalona/ 2004 2006: Sistema baseado na Web para Monitoramento Agr cola e Previso de Safras (WEBMAPS), a http://www.lis.ic.unicamp.br/projects/webmaps/ . Investigador Principal: Cludia Bazer Medeiros, a u http://www.ic.unicamp.br/~cmbm/

B.4.

Otras actividades relevantes

2008: Miembro del Comit de programa de las VII Jornadas Peruanas de e Computacin. JPC2008 o 2008: Miembro del Comit de programa de ANDESCON IEEE Per, e u 2008. 2007: Miembro del Comit de programa de las VI Jornadas Peruanas de e Computacin. JPC2007 o 2006: Revisor invitado en las V Jornadas de Computacin. Congreso Ino ternacional de Iniciacin Cient o ca en Computacin 2006 o 2003: Miembro del comit auxiliar de la Sociedad peruana de computacin. e o I Congreso Internacional de Cient cos Peruanos. Lima Per, 2 al 5 de u enero 2003. 2002 2003: Integrante de la direccin de publicaciones de la Sociedad o Peruana de Computacin. o

Apndice C e

Trabajos publicados
A continuacin se presenta la lista de trabajos publicados que tienen relacin o o con nuestra propuesta de investigacin, los cuales se presentan de manera cronolgio o ca.

Teste De Desempenho em Aplicaoes SIG Web c

Autores: A.H. Torres, E. Martins, R.S. Torres, M.J. Escalona

Congreso: 9o Workshop Iberoamericano de Ingenier de Requisitos y Ama bientes de Software (IDEAS 2006) Tipo de Participacin: o Ponencia. ISSN/ISBN: 950-34-0360-X La Plata, Argentina, 24/04/2006 26/04/2006

Lugar y fecha de celebracin: o

Aportaciones a la l nea de investigacin: Este art o culo inicia la l nea de investigacin con la propuesta de un mtodo que trata los tipo de pruebas de o e sistema relacionados con los requisitos de calidad, o ,los comnmente denominau dos, requisitos no funcionales. Espec camente, la propuesta estudia y propone un mtodo para realizar las pruebas de desempeo. Aunque el art e n culo fue validado con una aplicacin SIG Web, es totalmente vlida para cualquier tipo de o a sistemas Web. Resumen: Este art culo propone un modelo de proceso de pruebas de desempeo para aplicaciones SIG Web. El modelo considera los casos de uso ms n a cr ticos o de mayor riesgo en cuanto al desempeo de un sistema para la creacin n o de los casos de prueba. Adems, se provee la utilizacin de herramientas libres a o para la automatizacin de las etapas del proceso de evaluacin. El modelo fue o o aplicado al proyecto WebMaps, que es una aplicacin SIG Web, cuya nalidad o 73

74

APENDICE C. TRABAJOS PUBLICADOS

es auxiliar a sus usuarios en el planeamiento agr cola a partes de las regiones de inters. Los resultados preliminares obtenidos indican que las pruebas fueron e utiles en la identicacin de problemas de la arquitectura preliminar del sistema. o

Hacia una propuesta de Pruebas Tempranas del Sistema

Autores: Congreso: J.J. Gutierrez, M.J. Escalona, A.H. Torres, M. Mejias, J.Torres Taller sobre Pruebas en Ingenier del Software (PRIS 2006) a Ponencia. Sitges, Barcelona, Espaa, 03/10/2006 n

Tipo de Participacin: o

Lugar y fecha de celebracin: o 04/10/2006

Aportaciones a la l nea de investigacin: Esta publicacin es la primera o o propuesta referente a pruebas de sistema relacionada con los requisitos funcionales. Esta propuesta expone la importancia del tratamiento de las pruebas funcionales desde etapas tempranas del desarrollo del software. Es un aporte importante para la l nea de investigacin, porque adems estudia la elaboracin o a o de casos de pruebas de manera sistemtica. a Resumen: Una tarea vital en el desarrollo de software es probar la correcta implementacin de los requisitos funcionales. Sin embargo, muchas veces la o fase de prueba del sistema es demasiado corta para disear un buen conjunto n de pruebas, ejecutarlas y analizar sus resultados. Una solucin es la estrategia o de pruebas tempranas, la cual consiste en obtener de manera sistemtica casos a de prueba en etapas tempranas del desarrollo. Este trabajo describe los puntos clave de una nueva propuesta de pruebas tempranas del sistema, la cual resuelve algunas carencias detectadas en trabajos anteriores.

Generacin e implementacin de pruebas del o o sistema a partir de casos de uso

Autores: J.J. Gutierrez, M.J. Escalona, M. Mej A.H. Torres, J. Torres as,

Revista: Revista Espaola de Innovacin. Calidad e Ingenier del Software n o a Volumen: 3 N3. ISSN/ISBN: 1885-4486 Espaa, 2007 n

Pa de publicacin: s o

75 Indicios de calidad: Este art culo fue seleccionado como uno de los mejores del Workshop de pruebas en las Jornadas de Ingenier del Software y Bases de a Datos y ha sido revisado para la publicacin en esta revista. o Aportaciones a la l nea de investigacin: El principal aporte de esta o publicacin es profundizar la investigacin anterior, Hacia una propuesta de o o Pruebas Tempranas del Sistema. En este trabajo se muestran experimentos de realizacin de pruebas en cdigos de pruebas automticas. o o a Resumen: En la actualidad, existe una amplia cantidad de trabajos y cap tulos de libros que proponen cmo obtener pruebas a partir de requisitos funo cionales denidos como casos de uso. Sin embargo, existe una carencia de referencias que muestren cmo implementar dichas pruebas en cdigo de prueo o bas automticas. Este trabajo presenta una arquitectura basada en el perl de a pruebas de UML, y un conjunto de pasos para la implementacin de cdigo o o ejecutable de pruebas de casos de uso denidas mediante escenarios y variables operacionales.

Practical Experiences In Web Engineering

Autores: M.J. Escalona, J.J. Gutierrez, D. Villadiego, A. Leon, A.H.Torres

Libro: Advances in Information Systems Development. New Methods and Practise for the networked society. Volumen: Pginas: a 2. ISSN/ISBN: 978-0-387-70801-0 Desde: 421 Hasta: 434. Editorial: Springer Verlag Estados Unidos, 2007

Pa de publicacin: s o

Indicios de calidad: Texto fruto de la investigacin con gran aplicabilidad o en el Mundo real. Este libro surge como Proceedings Specials de la conferencia ISD (Information System Development). Esta conferencia est incluida en el Tier Conference Ranking con valor A a Aportaciones a la l nea de investigacin: Esta publicacin es un imporo o tante aporte a la l nea de investigacin, debido que muestra diversas aplicaciones o de la metodolog NDT en aplicaciones prcticas. De esta forma se valida los a a diferentes modelos presentes en las fases de Ingenier de Requisitos y de Anlia a sis. Esta es una de las razones por la cual, en nuestra propuesta de investigacin,la tomamos en cuenta a NDT para alcanzar nuestro quinto objetivo, o Evaluciacin de la propuesta (vase sub-seccin 3.1.5). o e o

76

APENDICE C. TRABAJOS PUBLICADOS

Resumen: La Ingenier Web se dene como una nueva rea que propone a a modelos, tcnicas, procesos, arquitecturas, etc. para tratar con las caracter e sticas especiales de los desarrollos en entornos Web. Sin embargo, no hay muchas aplicaciones prcticas. Este art a culo presenta una visin general de NDT (Navio gational Development Techniques) centrndose en el estudio de sus aplicaciones a prcticas. a

Generacin automtica de objetivos de prueba o a a partir de casos de uso mediante particin de o categor y variables operacionales as
Autores: Congreso: 2007) J.J. Gutierrez, M.J. Escalona, M. Mej A.H. Torres as, XII Jornadas de Ingenier del Software y Bases de Datos (JISBD a

Tipo de Participacin: o

Ponencia. ISSN/ISBN: 978-84-9732-595-0 Zaragoza, Espaa, 11/09/2007 14/09/2007 n

Lugar y fecha de celebracin: o

Aportaciones a la l nea de investigacin: El aporte de esta publicacin o o radica en presentar una serie de algoritmos que permiten automatizar el proceso de generacin de pruebas a partir de los casos de uso. De esta forma, se aborda o uno de los desaf de las pruebas de software, pruebas 100 % automticas (vase os a e sub-seccin 2.1.3). o Resumen: Este trabajo describe una propuesta para la generacin de pruebas o a partir de casos de uso presentando un proceso que, de manera sistemtica y a automtica, permite generar objetivos de prueba a partir de casos de uso especia cados en un lenguaje no formal. Este proceso aplica el mtodo de categor e aparticin y el patrn Use Case Test Pattern, el cual usa variables operacionales. o o Adems se presenta los algoritmos necesarios para la automatizacin del proceso a o propuesto, acompaados de un ejemplo aplicativo. n

Implementacin de Pruebas de Sistema o

Autores: Congreso: J.J. Gutierrez, M.J. Escalona, M. Mej A.H. Torres, J. Torres as, II Taller sobre Pruebas de Sistema Ponencia. ISSN/ISBN: 1988-3455

Tipo de Participacin: o

77 Lugar y fecha de celebracin: o Zaragoza, Espaa, 12/09/2007 12/09/2007 n

Aportaciones a la l nea de investigacin: El aporte de esta publicacin o o radica en presentar e implementar objetivos en pruebas automticas. Este traa bajo complementa la publicacin anterior, Generacin automtica de objetivos o o a de prueba a partir de casos de uso mediante particin de categor y variables o as operacionales Resumen: Las pruebas funcionales del sistema permiten vericar que el sistema en desarrollo satisface sus requisitos funcionales. Existen una amplia cantidad de trabajos y cap tulos de libros que proponen cmo obtener objetivos de o prueba a partir de requisitos funcionales expresados como casos de uso. Sin embargo, existe una carencia de trabajos que muestren cmo implementar dichos o objetivos en pruebas automticas. Este trabajo presenta un ejemplo, basado en a el perl de pruebas de UML, para la implementacin en cdigo ejecutable de o o objetivos de prueba denidos mediante escenarios y variables operacionales.

Using use cases scenarios and operational variables for generating test objectives
Autores: Congreso: J.J. Gutierrez, M.J. Escalona, M. Mejias, A.H. Torres 5th Workshop on System Testing and Validation (STV 2007) Ponencia. ISSN/ISBN: 978-3-8167-7475-4 Paris, Francia, 05/12/2007 06/12/2007

Tipo de Participacin: o

Lugar y fecha de celebracin: o

Aportaciones a la l nea de investigacin: Al igual que la publicacin o o anterior, se presenta una serie de algoritmos que permiten automatizar el proceso de generacin de pruebas a partir de los casos de uso, y adicionalmente se o muestra otras herramientas de soporte en la automatizacin. o Resumen: La aplicacin de los casos de uso en las etapas tempranas del ciclo o de vida es una tcnica ampliamente aceptada. Sin embargo, hay una importante e necesidad en desarrollar propuestas que deriven objetivos de prueba a partir de la denicin de casos de uso. Este art o culo presenta un conjunto de procesos que permiten obtener objetivos de pruebas desde escenarios de casos de uso y variables operacionales. Adems, se muestra la posibilidad de automatizacin a o con dos herramientas de soporte.

78

APENDICE C. TRABAJOS PUBLICADOS

A Development Process for Web Geographic Information System A case of study

Autores: M.J. Escalona, A.H. Torres, J.J. Gutierrez, E. Martins, R.S. Torres, M. C. Baranauskas Coleccin: o 2008) Volumen: Pginas: a International Conference on Enterprise Information System (ICEIS

HCI. ISSN/ISBN: 978-989-8111-40-1 Desde: 112 Hasta: 117. Editorial: INSTICC, Portugal Espaa, 2008 n

Pa de publicacin: s o

Indicios de calidad: Incluido en el ranking Citiseer (95,49 %) Incluido en Tier Conference Ranking (B) Incluido en el indicador de calidad ISI Proceedings. Articulo incluido en DBLP. Aportaciones a la l nea de investigacin: Con esta publicacin se demueso o tra que NDT puede adaptarse, no slo con otras metodolog o tcnicas (p.e. o as e Semitica Organizacional), sino que tambin es capaz de adaptarse a otros tipo o e de aplicaciones Web, las aplicaciones SIG (Sistemas de Informacin Geogrca) o a Web. Es as que se contina conrmando la eciencia de los modelos presentes , u en NDT y de su gran aplicabilidad prctica. a Resumen: Este art culo introduce un Proceso de desarrollo de aplicaciones SIG (Sistemas de Informacin Geogrca) Web. Este proceso integra la metodolog o a a NDT (Navigational Development Techniques) con algunos modelos de la Semitica Organizacional. El uso del proceso de desarrollo propuesto est ilustrao a do en una aplicacin real: la construccin de un sistema WebMaps. WebMaps o o es un sistema SIG Web cuyo objetivo principal es el soporte de planeamiento agr cola en Brasil.

A Case Study for generating test cases from use cases

Autores: J.J. Gutierrez, M.J. Escalona, M. Mej J. Torres, A.H. Torres as,

Congreso: IEEE International Conference on Research Challenges in Information Sciences

79 Tipo de Participacin: o Ponencia. Pginas: Desde: 223 Hasta: 228 a Marrakech, Marruecos, 03/06/2008 06/06/2008

Lugar y fecha de celebracin: o

Aportaciones a la l nea de investigacin: El principal aporte de esta puo blicacin es presentar resultados concluyentes sobre el aumento de la eciencia o del software, al utilizar mtodos automticos en la generacin de casos de pruee a o ba. Resumen: La vericacin de la correcta implementacin de casos de usos es o o una tarea vital en el desarrollo de software y en el aseguramiento de la calidad. Aunque hay muchos trabajos que describen como generar casos de prueba desde casos de uso, hay pocos resultados publicados de estudios emp ricos. Este art culo muestra un primer caso de estudio que testea la correcta implementacin de o casos de uso en un sistema Web y un sistema de l nea de comandos, analizar los resultados y concluye con un porcentaje de xito de ms del 80 %. e a

Hacia el dise o de Aplicaciones Web Reusables n

Autores: Congreso: A.H. Torres, M.J. Escalona, J.J. Gutierrez XII International Conference on Project Engineering Ponencia. ISSN/ISBN: 978-84-936430-3-4 Zaragoza, Espaa, 06/07/2008 11/07/2008 n

Tipo de Participacin: o

Lugar y fecha de celebracin: o

Aportaciones a la l nea de investigacin: El objetivo de nuestras inveso tigaciones, en general, va encaminado hacia el mejoramiento de la calidad en el proceso de desarrollo de aplicaciones Web. El aporte de esta publicacin es o que se basa en la fase de diseo, que no es contemplada en NDT, para extender n el alcance de nuestra investigacin. Es decir, aquellos modelos presentes dentro o del nivel PIM, comentado en la sub-seccin 2.3.1.1. o Resumen: Este art culo presenta una propuesta de un proceso de refactorizacin de software que permite aumentar el grado de reusabilidad de una aplicacin o o Web. El proceso incluye el uso de patrones de diseo JEE, el uso de mtodos n e de evaluacin cuantitativa de refactorizaciones de software y de mtricas de o e reuso. Se muestra como caso de estudio una propuesta de mdulo de gestin de o o proyectos para NDT.