trabajo fin de estudios - biblioteca.unirioja.es · diseño y automatización de pruebas software...

TRABAJO FIN DE ESTUDIOS

Diseño y automatización de pruebas software enentornos gráficos

Carlos Daniel Serres Martínez

PROYECTO FIN DE CARRERA

Tutor: Juan José Olarte Larrea

Curso 2011-2012

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2012

publicaciones.unirioja.esE-mail: [email protected]

Diseño y automatización de pruebas software en entornos gráficos, trabajo finde estudios

de Carlos Daniel Serres Martínez, dirigido por Juan José Olarte Larrea (publicado por laUniversidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

UNIVERSIDAD DE LA RIOJA

Facultad de Ciencias, Estudios Agroalimentarios e Informática


Ingeniería Técnica en Informática de Gestión

Diseño y automatización de pruebas software en entornos gráficos.

Alumno: Carlos Daniel Serres Martínez

Director: Juan José Olarte

Codirector: Carlos Marín (Digi International)

Logroño, junio 2012

Resumen:

El presente documento contiene la memoria del proyecto “Diseño y automatización de pruebas software en entornos gráficos”, en la que se detalla el proceso seguido hasta la finalización del mismo.

Este proyecto aborda la creación de un sistema que permita realizar pruebas sobre las interfaces gráficas de las aplicaciones que la empresa Digi International desarrolla. En concreto este proyecto está enfocado únicamente en la implementación de este sistema para una de las aplicaciones, un entorno basado en Eclipse para el desarrollo de modulos electrónicos que Digi fabrica, pero se definirá el diseño y estructura básicos para futuras adaptaciones de otras aplicaciones.

Este sistema estará formado y deberá hacer funcionar todas las siguientes partes:

• La herramienta para las pruebas software, Squish.

• Los test que interpretará dicha herramienta.

• Los ficheros de configuración para los test.

• Los ejecutables para lanzar los test.

• Los ejecutables para lanzar un sistema de virtualización, VMWare.

• La generación de los resultados.

Para la realización del proyecto se utilizará el lenguaje Python, así como UML como metodología de ingeniería.

Índices

ÍNDICE DE CONTENIDO

1: Introducción.................................................................................................11.1 Tema tratado................................................................................................................11.2: Motivo de la elección..................................................................................................1

2: Documento de objetivos del proyecto...........................................................22.1: Objetivos.....................................................................................................................22.2: Alcance........................................................................................................................2

2.2.1: Requisitos.............................................................................................................32.2.2: Especificaciones adicionales................................................................................3

2.3: Participantes del proyecto...........................................................................................42.4: Comunicación.............................................................................................................42.5: Metodología................................................................................................................42.6: Tecnologías..................................................................................................................52.7: Identificación de Riesgos y planes de acción..............................................................6

2.7.1: Posibles riesgos....................................................................................................62.7.2: Planes de acción..................................................................................................7

2.8: Entregables.................................................................................................................72.9: Descomposición de tareas...........................................................................................8

Tarea 1: Seguimiento del proyecto.................................................................................8Tarea 2: Gestión del proyecto........................................................................................9Tarea 3: Estudio previo................................................................................................10Tarea 4: Especificación de requisitos............................................................................10Tarea 5: Formación y aprendizaje................................................................................10Tarea 6: Ciclo 1 Base del sistema y test para XBee project........................................11Tarea 7: Ciclo 2 Test para XBee sample.....................................................................12Tarea 8: Ciclo 3 Virtualización del sistema................................................................13Tarea 9: Documentación..............................................................................................13

2.10: Estimación temporal..............................................................................................172.10.1: Calendario de trabajo......................................................................................172.10.2: Estimación del tiempo de las tareas.................................................................172.10.3: Diagrama de Gantt..........................................................................................21

3: Gestión del proyecto...................................................................................243.1: Replanificación..........................................................................................................24

I

Índices

3.1.1: Introducción......................................................................................................243.1.2: Factores de retraso.............................................................................................243.1.3: Replanificación..................................................................................................25

3.2: Comparación de estimaciones con resultados...........................................................253.2.1: Comparación por fechas de entrega..................................................................253.2.2: Comparación por duración de las tareas...........................................................26

4: Estudio previo............................................................................................274.1: Introducción..............................................................................................................274.2: DIGI International.....................................................................................................274.3: Aplicación bajo prueba..............................................................................................27

4.3.1: Módulo XBee.....................................................................................................274.3.2. Codewarrior + plugin XBee SKD.......................................................................284.3.3. Conociendo el entorno.......................................................................................28

Creación de proyectos..........................................................................................................28Compilación del proyecto....................................................................................................30Volcado del proyecto............................................................................................................31

4.4: Comparativa de herramientas de automatización.....................................................32

5: Especificación de los requisitos...................................................................345.1: Introducción..............................................................................................................34

5.1.1: Propósito............................................................................................................345.1.2: Ámbito del sistema............................................................................................345.1.3: Definiciones, siglas y abreviaturas.....................................................................345.1.4: Referencias.........................................................................................................345.1.5: Visión general del documento............................................................................35

5.2: Descripción General..................................................................................................355.2.1: Perspectiva del producto....................................................................................355.2.2: Funciones del producto......................................................................................355.2.3: Características de los usuarios...........................................................................36

5.3 Requisitos específicos.................................................................................................365.3.1: Interfaces externas.............................................................................................365.3.2: Funciones...........................................................................................................365.3.3: Requisitos de rendimiento.................................................................................375.3.4: Restricciones de diseño......................................................................................375.3.5: Atributos del sistema.........................................................................................375.3.6: Otros requisitos..................................................................................................38

6: Formación y aprendizaje.............................................................................39

II

Índices

6.1: Resumen general.......................................................................................................396.2: Documentación sobre Squish....................................................................................39

6.2.1: Introducción......................................................................................................396.2.2: Aproximación a Squish......................................................................................40

6.2.2.1: Conclusión...............................................................................................................446.2.3: Modo de ejecución.............................................................................................44

6.2.3.1: Problema encontrado...............................................................................................45

7: Ciclo 1: Análisis..........................................................................................487.1: Análisis de requisitos.................................................................................................48

7.1.1: Introducción......................................................................................................487.1.2: Usuarios del sistema..........................................................................................487.1.3: Casos de uso......................................................................................................48

7.1.3.1: Lanzar servidor........................................................................................................497.1.3.2: Lanzar test...............................................................................................................507.1.3.3: Descargar actualización AUT..................................................................................527.1.3.4: Definir configuración de test...................................................................................537.1.3.5: Comprobar resultados.............................................................................................54

7.1.4: Especificación de requisitos...............................................................................547.2: Clases de análisis.......................................................................................................55

7.2.1: Lógica de negocio..............................................................................................557.2.2: Persistencia........................................................................................................55

8: Ciclo 1: Diseño...........................................................................................568.1: Estructura del sistema...............................................................................................56

8.1.1: Estructura lógica................................................................................................568.1.1.1: Introducción............................................................................................................568.1.1.2: Descomposición en capas........................................................................................56

8.1.2: Estructura física.................................................................................................57Directorio SquishScripts.......................................................................................................58

8.2: Diseño de clases........................................................................................................598.3: Representación de web de los resultados..................................................................618.4: Especificación de la pruebas.....................................................................................63

8.4.1: Clases de equivalencia.......................................................................................638.4.1.1: SquishServerLauncher............................................................................................638.4.1.2: SquishTestLauncher................................................................................................638.4.1.3: SourceCodeDownloader..........................................................................................64

8.4.2: Identificación de los casos de prueba................................................................648.4.2.1: SquishServerLauncher............................................................................................648.4.2.2: SquishTestLauncher................................................................................................658.4.2.3: SourceCodeDownloader..........................................................................................66

III

Índices

9: Ciclo 1: Construcción..................................................................................679.1: Tecnología empleada.................................................................................................679.2: Descripción Squish IDE.............................................................................................67

9.2.1: Introducción......................................................................................................679.2.2: Resumen de lo ya conocido...............................................................................679.2.3: Squish y Java.....................................................................................................68

9.3: Interfaces definitivas.................................................................................................689.4: Código relevante.......................................................................................................71

9.4.1: SquishTestLauncher.py.......................................................................................719.4.2: Seleccionar componentes para proyectos XBee.................................................739.4.3: Recogida de los problemas de compilación.......................................................789.4.4: Funciones auxiliares para la fiabilidad del test..................................................80

9.4.4.1: handleShell()...........................................................................................................819.4.4.2: clickMenuOptionWithRetry().................................................................................819.4.4.3: clickContextualMenuOptionWithRetry()................................................................82

9.5: Resultado de las pruebas...........................................................................................83

10: Ciclo2: Análisis.........................................................................................8410.1 Análisis de requisitos................................................................................................84

10.1.1: Introducción....................................................................................................8410.1.2: Casos de uso....................................................................................................8410.1.3: Especificación de requisitos.............................................................................85

10.2: Clases de análisis.....................................................................................................8610.2.1: Lógica de negocio............................................................................................8610.2.2: Persistencia......................................................................................................86

11: Ciclo 2: Diseño.........................................................................................8711.1: Estructura del sistema.............................................................................................8711.2: Diseño de clases......................................................................................................8711.3: Especificación de pruebas.......................................................................................88

12: Ciclo 2: Construcción................................................................................8912.1 Tecnología empleada................................................................................................8912.2: Interfaces definitivas...............................................................................................8912.3: Código relevante.....................................................................................................89

12.3.1: Clase XBeeProjectTerminal..............................................................................8912.3.1.1: Introducción..........................................................................................................8912.3.1.2: Codificación..........................................................................................................90

12.4: Resultados de los pruebas.......................................................................................92

IV

Índices

13: Ciclo 3: Análisis........................................................................................9313.1: Análisis de requisitos...............................................................................................93

13.1.1: Introducción....................................................................................................9313.1.2: Casos de uso....................................................................................................93

13.1.2.1: Lanzar máquina virtual..........................................................................................9413.1.3: Especificación de requisitos.............................................................................95

14: Ciclo 3: Diseño.........................................................................................9614.1: Estructura del sistema.............................................................................................96

14.1.1: Estructura lógica..............................................................................................9614.1.2: Estructura física...............................................................................................96

14.2: Especificación de las pruebas..................................................................................9714.2.1: Clases de equivalencia.....................................................................................9714.2.2: Identificación de los casos de prueba..............................................................98

15: Ciclo 3: Construcción..............................................................................10015.1: Tecnología empleada.............................................................................................10015.2: Descripción de VMWare........................................................................................100

15.2.1 Binding de la librería vix.dll............................................................................10015.4 Código relevante....................................................................................................10115.3: Resultado de las pruebas.......................................................................................101

16: Pruebas del sistema y aceptación............................................................102

17: Conclusiones..........................................................................................10317.1: Comparación entre objetivos y resultados obtenidos............................................10317.2 Visión personal.......................................................................................................104

19: Glosario de términos.............................................................................105

20: Bibliografía.............................................................................................106

ÍNDICE DE ILUSTRACIONES

Ilustración 1: Diagrama de descomposición de tareas general........................14

Ilustración 2: Diagrama de descomposición de tareas Ciclo 1......................15



V

Índices

Ilustración 5: Diagrama de Gantt Visión General..........................................21

Ilustración 6: Diagrama de Gantt Tareas de gestión del proyecto.................21

Ilustración 7: Diagrama de Gantt Ciclo 1.....................................................22

Ilustración 8: Diagrama de Gantt Ciclo 2......................................................22

Ilustración 9: Diagrama de Gantt Ciclo 3 y documentación..........................23

Ilustración 10: Diagrama de Gantt Replanificación......................................25

Ilustración 11: Un módulo XBee.....................................................................27

Ilustración 12: Selección de tipo de proyecto XBee project.............................29

Ilustración 13: Asistente de creación de proyectos XBee.................................30

Ilustración 14: Barra de progreso de compilación de un proyecto..................31

Ilustración 15: Pantalla de configuración del run...........................................32

Ilustración 16: Diagrama de relaciones Perspectiva del producto.................35

Ilustración 17: Interfaz de Squish IDE............................................................40

Ilustración 18: Interfaz de Squish IDE – Test suite creado..............................41

Ilustración 19: Interfaz de Squish IDE Test case creado................................42

Ilustración 20: Interfaz de Squish IDE Código autogenerado.......................43

Ilustración 21: Esquema de ejecución de Squish IDE......................................44

Ilustración 22: Esquema de ejecución de Squish.............................................45

Ilustración 23: Esquema del problema con Squish..........................................46

Ilustración 24: Diagrama de casos de uso ciclo 1 General............................49

Ilustración 25: Diagrama de casos de uso ciclo 1 Lanzar servidor.................50

Ilustración 26: Diagrama de casos de uso ciclo 1 Lanzar test.......................50

Ilustración 27: Diagrama de actividad lanzador de test..................................51

Ilustración 28: Diagrama de secuencia de test XBee project...........................52

Ilustración 29: Diagrama de casos de uso ciclo 1 – Descarga AUT..................53

VI

Índices

Ilustración 30: Diagrama de casos de uso ciclo 1 Definir configuración test.53

Ilustración 31: Diagrama de descomposición de capas lógicas.......................56

Ilustración 32: Árbol de directorios del sistema..............................................57

Ilustración 33: Diagrama de clases ciclo 1......................................................60

Ilustración 34: Esquema interfaz web de resultados.......................................61

Ilustración 35: Esquema interfaz web compilación.........................................62

Ilustración 36: Interfaz web de los resultados del test....................................69

Ilustración 37: Interfaz web de los resultados de la compilación....................70

Ilustración 38: Código SquishTestLauncher.py Función getConfig().............72

Ilustración 39: Código SquishTestLauncher.py Funciónes autList() y testList().........................................................................................................73

Ilustración 40: Añadir componente Componente único................................74

Ilustración 41: Añadir componente Pines insuficientes.................................75

Ilustración 42: Añadir componente Reasignar pines.....................................76

Ilustración 43: Código clase XBeeDefinedProjectCreator Método clickAddButton...............................................................................................77

Ilustración 44: Problemas de compilación......................................................78

Ilustración 45: Código de la clase XBeeProjectBuilder getProblems.............79

Ilustración 46: Ventana de Package Manager..................................................80

Ilustración 47: Código de handleShell............................................................81

Ilustración 48: Código de clickMenuOptionWithRetry....................................82

Ilustración 49: Código de clickContextualMenuOptionWithRetry...................82

Ilustración 50: Diagrama de secuencia del text XBee Samples........................85

Ilustración 51: Diagrama de clases del ciclo 2................................................87

Ilustración 52: Debugger................................................................................88

Ilustración 53: Ventana de Terminal Settings..................................................90

VII

Índices

Ilustración 54: Código de la clase XBeeProjectTerminal..................................91


Ilustración 56: Diagrama de casos de uso ciclo 3 Lanzar máquina virtual....94

Ilustración 57: Estructura física de los directorios Paquete final...................96

VIII

1:Introducción

1: INTRODUCCIÓN

1.1 TEMA TRATADO

Este proyecto surge como solución a la necesidad de la empresa Digi International de una herramienta de testeo para el desarrollo de sus aplicaciones. La solución a este problema es un sistema que permita ejecutar pruebas sobre las aplicaciones de forma automática y sin interacción por tarde del usuario, pudiendo configurar dichas pruebas, y que una vez terminadas se genere un registro de resultados.

Este sistema no solo pretende mejorar algo tan arduo y poco eficiente como hacer las pruebas manualmente, sino que además ayudará en la detección y la localización de errores, útiles en estrategias de pruebas como la integración continua y las pruebas de regresión, para las que principalmente está enfocado este sistema.

Adicionalmente, el sistema deberá ser integrado dentro de un sistema de virtualización que también funcione de forma automática.

1.2: MOTIVO DE LA ELECCIÓN

A finales de febrero del año 2011 comencé un periodo de practicas en la empresa Digi International en su oficina de Logroño. Como por entonces no tenía elegido ningún tema para mi proyecto fin de carrera, me ofrecieron la posibilidad de realizar el presente proyecto durante mis prácticas.

El proyecto me resultó interesante ya que podría conocer en un entorno real cómo se aborda el tema de las pruebas en el desarrollo de aplicaciones. Durante este tiempo la mayor parte de los conocimientos que he ido adquiriendo han sido sobre todo en campo del diseño y la implementación de software, y es por eso que me gustó la idea de conocer algo mejor el campo de las pruebas.

También me comentaron que lo más probable es que tendría que escribir mi código en Python, ya que es el lenguaje más utilizado por el departamento de pruebas. Python es un lenguaje del que había oído hablar mucho pero que no conocía y me llamaba la atención, así que con el proyecto tenía la escusa perfecta para poder aprenderlo.

Finalmente me comprometí a realizar el proyecto, presenté la propuesta en el departamento de la facultad y fue aceptada asignándome como director a Juan José Olarte.

1

2:Documento de objetivos del proyecto

2: DOCUMENTO DE OBJETIVOS DEL PROYECTO

2.1: OBJETIVOS

El objetivo del proyecto es la elaboración de un sistema formado por varias herramientas que permita realizar pruebas software sobre las aplicaciones creadas por Digi International. Aún estado centrado este proyecto en una aplicación concreta se asentarán las bases del diseño del sistema para ofrecer robustez al mismo y ayudar a la futura implantación de otras aplicaciones.

Sobre la aplicación bajo prueba hace falta decir que deberá conocerse su funcionamiento a nivel de usuario, para poder ser capaz de saber cuales son sus particularidades y poder así diseñar los test a partir de ellas.

Una vez realizados los estudios previos sobre el manejo de la aplicación bajo prueba y sobre las tecnologías a utilizar, se diseñarán los test acorde a las partes de la aplicación que quieran ser probadas. Concretamente, para la aplicación en la que se centra este proyecto, CodeWarrior + plugin XBee SDK (explicada más adelante en el punto 4.3) , se diseñarán dos tipos de test:

• XBee Project: Destinado a las pruebas para los proyectos creados en la aplicación.

• XBee Sample: Destinado a las pruebas para las muestras se incluyen en la aplicación.

Ambos test poseerán parámetros configurables por medios de ficheros de configuración con los que se podrá dotar a los test de mayor flexibilidad y reutilización que si fuera diseñado un test para cada caso concreto.

Para cada test que sea realizado se recogerá información y con ella se generará un registro de resultados. De esta forma será posible utilizar conceptos como la integración continua mediante la automatización de pruebas diarias y también las pruebas de regresión a través de los resultados de los test.

Adicionalmente se ofrecerá la opción de poder lanzar de forma automática todo el sistema dentro de una maquina virtual, para así poder realizar pruebas diferentes en la misma maquina y en el futuro poder gestionar las máquinas virtuales por medio de una aplicación web.

2.2: ALCANCE

La finalidad de proyecto es crear el sistema de automatización para las pruebas de las aplicaciones. Sin embargo, el número de aplicaciones desarrolladas es lo suficientemente grande como para generar un proyecto mucho mas extenso. Por ese motivo el proyecto

2


estará únicamente enfocado en la aplicación CodeWarrior + XBee SDK.

Teniendo definido el contexto sobre el que se va a trabajar, el sistema deberá cumplir una serie de requisitos para considerar que el proyecto ha sido llevado correctamente a buen puerto.

2.2.1: REQUISITOS

A continuación se muestran los puntos mínimos fijados para la realización final del proyecto:

• Diseñar la estructura básica del sistema: Una vez se conozcan cual o cuales son las herramientas a utilizar, se determinará su jerarquía en el árbol de directorios.

• Crear los ejecutables: Se trata de los ficheros utilizados para lanzar los test de forma sencilla para los usuarios. Soportarán parámetros en su invocación.

• Diseñar e implementar los test: En este caso se trata de dos test para dos casos distintos.

• Recolectar y presentar resultados: Cuando termine cada test se guardará y dará formato legible a los resultados de todos los puntos sensibles de la ejecución del test.

• Crear el ejecutable para el uso de la maquina virtual: Para el caso de usar el sistema bajo una maquina virtual.

2.2.2: ESPECIFICACIONES ADICIONALES

Debido a la limitación de tiempo y extensión, o bien por desviarse en mayor o menor medida del tema del proyecto, se han descartado las siguientes ampliaciones:

• Diseñar e implementar para otras aplicaciones.

• Ampliar para más samples las pruebas de la salida del terminal: En el test de los samples se realiza una conexión por medio del puerto COM con un dispositivo el cual devuelve datos en una consola.

• Ampliar la web de la empresa con una aplicación web para lanzar los test: La idea es disponer de imágenes de máquina virtual en red y mediante la aplicación web poder seleccionar una libre y realizar los test sobre ella. Posteriormente los resultados del test serían almacenados en una base de datos.

3


2.3: PARTICIPANTES DEL PROYECTO

Al ser realizado el proyecto dentro del marco empresarial, existen varias las personas que participan en él. Debido a esto, y por mantener un orden, se puede dividir a los participantes en dos entornos diferentes: el entorno académico y el entorno de la empresa.

En el caso académico, por parte de la Universidad de la Rioja, se hallan:

• Carlos Daniel Serres Martínez, alumno y desarrollador del proyecto.

• Juan José Olarte, profesor del departamento de Matemáticas y Computación, con función de director de proyecto.

En el entorno de la empresa, por parte de Digi Internacional, se hallan:

• Pedro Pérez, Jefe de proyectos de la oficina de Digi en Logroño.

• Carlos Marín, Ingeniero del departamento de pruebas y director del proyecto dentro de la empresa.

Durante la realización del proyecto el alumno adoptará el rol de un trabajador dentro de la empresa, pero al estar el proyecto destinado a la creación de una herramienta de uso privado para los desarrollos de la empresa, se puede enfocar al relación en una relación desarrollador-cliente.

2.4: COMUNICACIÓN

La principal vía de comunicación será el correo electrónico, pero también se organizarán reuniones personales, ambas tanto entre el entorno académico, como con el entorno empresarial.

Sin embargo conviene reseñar, que el puesto de trabajo asignado para el alumno dentro de la empresa se encuentra junto al director del proyecto, de forma que la comunicación será fluida y constante durante el proceso de desarrollo. Además de tener reuniones semanales sobre el seguimiento del desarrollo.

2.5: METODOLOGÍA

La metodología elegida en este proyecto será la denominada Proceso Unificado, definida por Jacobson, Booch y Rumbaugh. Esta metodología se caracteriza por estar dirigida por casos de uso, centrada en la arquitectura y por ser iterativa e incremental. El uso que se dará a esta metodología no será el de un seguimiento estricto, sino que se utilizarán y adaptarán características de la misma según las necesidades del proyecto.

4


Principalmente, se utilizará un ciclo de vida iterativo e incremental para el desarrollo del proyecto, de forma que pueda obtenerse en la primera fase un producto funcional que se vaya ampliando en las sucesivas fases con el resto de especificaciones.

Otras de las razones de la elección de esta metodología es que utiliza UML, como lenguaje de modelado de sistemas software, el cual es casi considerado un estándar y es interesante su uso en este proyecto por disponer un amplio abanico de diagramas útiles para su organización.

Gracias al uso esta metodología se pretende dotar a este proyecto de la robustez necesaria y así minimizar los riesgos.

2.6: TECNOLOGÍAS

En el caso de este proyecto, la elección de las tecnologías no es decidida hasta no haber sido terminado el estudio previo sobre las herramientas disponibles en el mercado. Aun así, a modo de anticipo, se resumirán en esta sección cuales son las tecnologías utilizadas.

Esta es la lista de los lenguajes utilizados:

• Python: Es el lenguaje de programación utilizado para la implementación de este proyecto. Se puede decir a modo de introducción que su filosofía hace hincapié en una sintaxis muy limpia y que favorezca un código legible, soporta orientación a objetos y programación imperativa, y es un lenguaje interpretado con tipado dinámico, fuertemente tipado y multiplataforma. En la empresa Digi International es el lenguaje utilizado por el departamento de pruebas.

• HTML: Es el lenguaje utilizado a la hora de presentar los resultados de los test de forma legible. Su nombre significa HyperText Markup Language y es el lenguaje utilizado para representar el contenido en la web. Se utiliza concretamente en este proyecto para transformar los archivos xml en formato web. De forma anecdótica dentro de HTML también se llega a utilizar Javascript, pero no lo añadiré como tecnología por su uso puntual.

• XML: Al igual que HTML es otro lenguaje de marcado ya que provienen los dos de SGML. Su nombre significa eXtensible Markup Language y es utilizado principalmente en el intercambio de información. Para este proyecto se utiliza en la lectura o parseo de documentos xml.

A continuación ésta es la lista de las herramientas y otras tecnologías utilizadas:

• Squish: Ésta es la herramienta principal encargada de la automatización de las pruebas software. Es un producto desarrollado por la empresa Froglogic y concretamente se utiliza para el proyecto su versión v4.1 para entornos en Java. Soporta varios lenguajes para escribir su código, pero en este caso se utiliza Python. Más adelante, en el estudio previo se describe la estructura y el uso de

5


esta herramienta.

• Interprete de Python: Es el interprete del código de Python, la versión utilizada es v2.7.1.

• Interprete de Java: El interprete de Java utilizado por la herramienta a probar. Lo añado en esta sección ya que es necesario indicarlo en el proceso de instalación de Squish. La versión utilizada es el JRE7.

• Cliente GIT: Cliente para uso del servidor de gestión de versiones GIT. GIT es el sistema de gestión de versiones utilizado en Digi y en el proyecto es necesario para descargar el software que se va a probar, pudiendo seleccionar la versión deseada. Su versión es la v1.7.4.

• VMWare Workstation 7: Herramienta para la gestión de máquinas virtuales. Se utiliza para lanzar las pruebas software mediante virtualización. Para conseguir un comportamiento automático de dicha aplicación se utiliza la librería VIX, la cual permite arrancar las maquinas virtuales y trasladarles comandos de consola una vez arrancadas.

2.7: IDENTIFICACIÓN DE RIESGOS Y PLANES DE ACCIÓN

Para evitar que el tiempo de desarrollo del proyecto se resienta por imprevistos, se tratará de identificar los posibles problemas que puedan surgir durante el mismo. Además de los riesgos se propondrá también planes de acción para estos casos.

2.7.1: POSIBLES RIESGOS

Esta es la lista de los riesgos identificados que pueden ocurrir durante el desarrollo del proyecto:

1. En el caso de este proyecto está claro que existe riesgo por el desconocimiento previo de alguna herramienta, puesto que ya se sabe de antemano que una herramienta para la automatización de pruebas deberá ser elegida sin tener experiencia en su manejo. Esto podría desencadenar una detección tardía de la inviabilidad del proyecto.

2. Los Factores de índole personal de todos los participantes de proyecto, pero principalmente en el caso del alumno, que tiene el peso del desarrollo. Pueden ser enfermedades u otros impedimentos imprevisibles.

3. Error en la estimación de fechas tienen una alta probabilidad de ocurrir debido a la falta de experiencia del alumno, ya sea por exceso o por defecto del tiempo asignado para las tareas.

4. Al tener que usar un ordenador, el desarrollo puede verse afectado por problemas

6


de hardware y software.

5. Una vez terminado el desarrollo puede ocurrir que el producto final no sea del agrado alguno de los participantes, especialmente en el caso del cliente.

2.7.2: PLANES DE ACCIÓN

Estos son los planes de actuación en el caso de los anteriores riesgos:

1. Para evitar la detección tardía de la inviabilidad del proyecto, se efectuará un estudio previo en el que uno de sus puntos de estudio deberá centrarse en el conocimiento de las aplicaciones utilizadas. De esta forma, se conseguirá conocer las limitaciones de las aplicaciones, su forma de manejarlas y si fuera necesario encontrar alguna solución pertinente. Así se evitaría tener que aprender sobre la marcha o llegar a una situación en la que continuar sea imposible .

2. En el caso de los factores de índole personal dependiendo de su naturaleza y gravedad se verá afectado irremediablemente en mayor o menor medida. Seguirá con la planificación del proyecto en el momento que sea posible haciendo constar en la documentación el motivo del retraso y se replanificarán las tareas si fuera necesario.

3. Si se produjera un error en la estimación de tiempos, se documentará el error y se replanificarán las tareas como sea conveniente.

4. Durante el desarrollo de este proyecto el alumno dispondrá un equipo en el puesto de trabajo dentro de la empresa y también de su ordenador portátil para el trabajo que pueda ser realizado desde casa. Para evitar que problemas de hardware y software puedan desencadenar la pérdida de todo el trabajo se guardarán copias del mismo. Las copias se guardarán en una memoria USB, en un equipo de red dentro de la empresa destinado a este propósito y también mediante la cuenta de Dropbox del alumno.

5. La comunicación entre el alumno y su director de proyecto en la empresa será continua, ya que sus puestos de trabajo se encuentran juntos. De esta forma es posible llevar un seguimiento muy actualizado del estado del proyecto y por consiguiente se evitará que no sea del agrado del cliente.

2.8: ENTREGABLES

Tras la finalización del proyecto deberá haberse generado como resultado un paquete que contenga una serie de elementos. El nombre elegido por el cliente para este paquete será “GuiAutomation” y su contenido el siguiente:

• Directorio “Documents”: En el se incluirá la documentación necesaria sobre el manejo y la instalación del sistema.

7


• Directorio “extras”: Contendrá los instaladores de las herramientas necesarias.

• Directorio “squish-4.1”: Paquete de la herramienta Squish, herramienta usada para la automatización.

• Directorio “SquishScripts”: Contendrá todo el código creado para ser ejecutado por Squish, tanto los test como las clases creadas. El interior de este directorio estará diseñado y organizado con la idea de añadir nuevos scripts para otras aplicaciones.

• Directorio “VIX”: Directorio necesario para el manejo automático de la herramienta de maquinas virtuales VMWare Workstation. Contendrá la librería capaz de hacer esto además de su ejecutable.

• Fichero “SourceCodeDownloader”: Script Python para bajar la versión de la aplicación bajo prueba desde el servidor del administrador de versiones GIT. Dispondrá de parámetros configurables en su ejecución.

• Fichero “SquishServerLauncher”: Script Python para iniciar el servidor de Squish y que permanezca a la escucha de petición de tests. Dispondrá de parámetros configurables en su ejecución.

• Fichero “SquishTestLauncher”: Script Python para enviar al servidor de Squish la orden de iniciar el test. Dispondrá de parámetros configurables en su ejecución.

• Fichero “xml2result2html”: Script Python con la finalidad de transformar los resúmenes de los test de formato xml a formato html.

Además, así como con el paquete anterior, el presente documento también formará parte de los entregables de este proyecto.

2.9: DESCOMPOSICIÓN DE TAREAS

El proyecto se ha dividido en una serie de tareas que nos ayudarán en la organización y en la estimación del tiempo del mismo.

A continuación se muestran las tareas con una breve descripción y sus subtareas.

TAREA 1: SEGUIMIENTO DEL PROYECTO

Esta tarea abarcará toda la duración total de la vida del proyecto, en la que se efectuarán controles en diversos momentos del ciclo de vida.

1.1. Reuniones: Contempla en tiempo consumido en las reuniones realizadas sobre el proyecto.

8


1.2. Revisiones: Son las comprobaciones periódicas para asegurar que el proyecto va por buen camino y cumple los objetivos de la planificación, y en caso de necesitarse hacer las rectificaciones adecuadas.

TAREA 2: GESTIÓN DEL PROYECTO

Esta tarea abarca las labores de documentación y las específicas que afectan al proyecto fin de carrera como asignatura y no como proyecto de sistema de información.

2.1. Generación del DOP: Creación del presente documento de los objetivos de proyecto.

2.1.1. Estudio previo: Obtener información sobre dirección de proyectos.

2.1.2. Descomposición de tareas: Descomponer el proyecto en tareas. Generar el diagrama de descomposición de tareas.

2.1.3. Asignar tiempo a tareas: Estimar el tiempo que se dedicará a cada duna de las tareas.

2.1.4. Diagrama Grantt: Crear el diagrama de Gantt.

2.1.5. Documentación: Documentar textualmente las tareas identificadas.

2.1.6. Revisión: Revisar la documentación generada en esta tarea.

2.2. Generación de la memoria.

2.2.1. Estudio previo: Estudiar documentación de proyectos de años anteriores y otra información proporcionada por el departamento sobre proyectos fin de carrera.

2.2.2. Creación de la memoria: Creación del documento de la memoria del proyecto. La duración de esta tarea se extiende durante toda la vida del proyecto, puesto que la memoria se irá actualizando tras la finalización de tareas.

2.2.3. Revisión del documento: Revisar la documentación generada en esta tarea

2.3. Defensa del Proyecto.

2.3.1. Preparación: Preparación de la presentación del proyecto ante el tribunal.

2.3.2. Defensa: Defensa del proyecto ante el tribunal.

9


TAREA 3: ESTUDIO PREVIO

Mediante esta tarea se conocerá el escenario en el que se desarrollara el proyecto y sus antecedentes, además se presentarán las aplicaciones y herramientas que serán utilizadas. En el caso de la herramienta para la automatización se realizara un estudio entre varias alternativas, en el que se realizara una comparativa y una posterior elección.

3.1. Estudio del escenario.

3.1.1. Estudio de la empresa: Se estudiará la empresa Digi International en la que se realizará el proyecto para conocer información sobre ella y sus antecedentes al proyecto.

3.1.2. Estudio de las herramientas: Se estudiarán las aplicaciones y herramientas implicadas en el proyecto creadas y utilizadas por las empresa.

3.1.3. Estudio de alternativas en automatización de pruebas: Se buscarán y compararán herramientas para la automatización de pruebas.

3.2. Establecer los límites del sistema a desarrollar junto con el personal de la empresa.

3.3. Estudiar la viabilidad del proyecto junto con el personal de la empresa.

TAREA 4: ESPECIFICACIÓN DE REQUISITOS

Consiste en el proceso en el cual tras el análisis previo se extraen los requisitos fundamentales que debe poseer el sistema.

4.1. Crear documento de especificación de requisitos: Antes de comenzar con las iteraciones definiremos los requisitos que debe cumplir la plataforma globalmente. Se numerarán y describirán adecuadamente para poder ir identificándolos a medida que se vayan satisfaciendo a lo largo de cada una de las iteraciones.

TAREA 5: FORMACIÓN Y APRENDIZAJE

En esta tarea se buscarán por parte del alumno los conocimientos necesarios para la elaboración del proyecto.

5.1. Aprendizaje en la aplicación bajo prueba: Conocer la aplicación Codewarrior + plugin XBee SDK, para posteriormente crear los test que correrán sobre ella.

5.2. Aprendizaje en la aplicación de automatización de pruebas: Conocer el funcionamiento del entorno de desarrollo para Squish.

10


5.2.1. Documentar funcionamiento y estructura de Squish.

5.3. Aprendizaje en lenguaje de programación Python: Aprender este lenguaje de programación será necesario para la codificación de los ejecutables y los test.

TAREA 6: CICLO 1 - BASE DEL SISTEMA Y TEST PARA XBEE PROJECT

Esta tarea corresponde con la primera iteración del proyecto. Una vez haya sido finalizada habrá sido creada toda la estructura básica del sistema y el test XBee proyect el cual podrá ser utilizado partir de este momento.

6.1. Análisis.

6.1.1. Casos de uso.

6.1.1.1. Identificar actores.

6.1.1.2. Crear casos de uso.

6.1.1.3. Crear diagrama de actividad.

6.1.1.4. Crear diagrama de flujo.

6.1.1.5. Revisión.

6.1.2. Clases de análisis.

6.1.2.1. Identificar clases.

6.1.2.2. Diagrama de clases.

6.2. Diseño.

6.2.1. Diseño de la estructura del sistema.

6.2.2. Diseño de las clases.

6.2.3. Diseño de la representación web de los resultados.

6.3. Construcción.

6.3.1. Crear los scripts para usar Squish y Git.

6.3.2. Implementar el código para Squish.

6.3.2.1. Crear el principal del test.

6.3.2.2. Implementar las clases.

11


6.3.2.3. Crear los ficheros de configuración.

6.3.2.4. Crear librería de funciones adicionales.

6.3.3. Crear el script para transformar a formato web los resultados.

6.3.4. Documentar código.

6.4. Pruebas.

6.4.1. Pruebas unitarias de el sistema.

6.4.2. Pruebas de integración periódicas.

TAREA 7: CICLO 2 - TEST PARA XBEE SAMPLE

En esta tarea se ampliará el sistema añadiéndole el test XBee sample. Esta tarea se apoyará en la estructura creada anteriormente.

7.1. Análisis.




7.1.1.3. Crear diagrama de actividad


7.1.1.5. Revisión.




7.2. Diseño.

7.2.1. Diseño de clases.

7.3. Construcción.

7.3.1. Implementar código para Squish.



12


7.4. Pruebas.



TAREA 8: CICLO 3 - VIRTUALIZACIÓN DEL SISTEMA

La finalidad de esta tarea será la de incluir todo el sistema dentro de una máquina virtual, de forma que pueda ser luego lanzado mediante algún comando y que realice los test que se le pida de forma automática. Para el caso de esta tarea los límites de sus fases son bastante difusos y es por eso que se seguirá una estructura diferente a las tareas anteriores, siendo la de este caso mucho mas simple.

8.1. Análisis.






8.1.1.5. Revisión.

8.2. Construcción.

8.2.1. Implementación del script lanzador de VMWare.

8.2.2. Implementación del binding de Python para la librería vix.dll.

8.3. Pruebas.

8.3.1. Pruebas unitarias del sistema.


TAREA 9: DOCUMENTACIÓN

Esta tarea se centrará en la elaboración de la documentación para el manejo del sistema, además de la pertinente documentación dentro del código generado.

9.1. Manual de instalación y uso del sistema.

13


14

Ilustración 1: Diagrama de descomposición de tareas general.


15

Ilustración 2: Diagrama de descomposición de tareas - Ciclo 1


16




2.10: ESTIMACIÓN TEMPORAL

2.10.1: CALENDARIO DE TRABAJO

Ya que este proyecto se desarrolla durante el periodo de prácticas en la empresa Digi, se dispone de mucho tipo entre semana para el desarrollo del mismo. Por otro lado, al ser utilizadas herramientas y recursos que solo son accesibles desde la empresa, será imposible aprovechar los fines de semana.

2.10.2: ESTIMACIÓN DEL TIEMPO DE LAS TAREAS

En la siguiente tabla se muestra la estimación de horas para cada una de las tareas:

Nombre Duración en horas

Seguimiento del proyecto 14

Reuniones 6

Revisiones 8

Gestión del proyecto 66

Generación del DOP 25

Estudio previo 4

Descomposición de tareas 4

Asignar tiempo a tareas 4

Diagrama Grantt 2

Documentación 10

Revisión 1

Generación de la memoria 72

Estudio previo 8

Creación de la memoria 60

Revisión 4

Defensa del proyecto 13

Preparación 12

Defensa 1

Estudio previo 43

Estudio del escenario 37

Estudio de la empresa 8

17


Estudio de las herramientas 17

Estudio de las alternativas 12

Establecer los límites 3

Estudiar viabilidad 3

Especificación de requisitos 8

Creación del documento 8

Formación y aprendizaje 197

Aplicación bajo prueba 43

Aplicación de automatización 68

Documentación 4

Python 62

Ciclo 1 155

Análisis 7

Casos de uso 5

Identificación de actores 1

Crear casos de uso 2

Crear diagrama de actividad 2

Crear diagrama de flujo 2

Revisión 1

Clases de análisis 2

Identificar clases 1

Diagrama de clases 1

Diseño 8

Estructura del sistema 4

Clases 3

Interfaz de representación de resultados 1

Construcción 15

Crear script para Squish 27

Implementar código para Squish 85

Crear el principal del test 6

Implementar clases 72

Crear ficheros de configuración 2

Crear librería de funciones adicionales 5

18


Crear el script de los resultados web 2

Pruebas 26

Pruebas unitarias de el sistema 4

Pruebas de integración periódicas 22

Ciclo 2 100

Análisis 8

Casos de uso 6





Revisión 2




Diseño 4

Clases 4

Construcción 62





Pruebas 26



Ciclo 3 42

Análisis 5

Casos de uso 5





Revisión 1

19


Diseño 2


Construcción 9

Crear lanzador de VMWare 6

Modificar bindeo de vix.dll para Python 3

Pruebas 26



Documentación 5

Manual de instalación y uso 5

Total de hora del proyecto 626

20


2.10.3: DIAGRAMA DE GANTT

A continuación: se muestra las diferentes partes del diagrama de Gantt de las tareas del proyecto.

21

Ilustración 5: Diagrama de Gantt - Visión General.

Ilustración 6: Diagrama de Gantt - Tareas de gestión del proyecto.


22

Ilustración 7: Diagrama de Gantt - Ciclo 1.



23

Ilustración 9: Diagrama de Gantt - Ciclo 3 y documentación.

3:Gestión del proyecto

3: GESTIÓN DEL PROYECTO

3.1: REPLANIFICACIÓN

3.1.1: INTRODUCCIÓN

Durante el desarrollo del proyecto, han surgido una serie de imprevistos que han afectado a la planificación. Esto ha afectado para cumplir con los plazos que fueron asignados para algunas de las tareas.

A raíz de esto, se efectúa una replanificación de las tareas el día 15 de agosto.

3.1.2: FACTORES DE RETRASO

Los factores por los que se ve obligado el proyecto a una replanificación son los siguiente:

• Se libera una nueva versión del la aplicación bajo prueba. En esta versión cambia algunos aspectos de la interfaz gráfica son cambiados considerablemente. Esto ocasiona tener que actualizar el código de los test, además de aumentar la complejidad de los mismos.

• Se libera una nueva versión de Squish. Se decide utilizar esta nueva versión desde ese momento en adelante, pero posteriormente se descubre un error que no sucedía con la versión anterior. Tras esto, se le comunica a la atención al cliente de de Squish la existencia de este fallo. Después de algunos correos el error es localizado y posteriormente solucionado.

• Problemas en el desarrollo por la falta de experiencia en las herramientas.

También se puede considerar, no como factor de retraso, que la planificación de las tareas era bastante optimista. Ya que, a pesar de los problemas anteriores, se podía intuir a mitad del desarrollo que sería complicado cumplir con las fechas.

24


3.1.3: REPLANIFICACIÓN

Este es el nuevo diagrama de Gantt después de replanificar.

3.2: COMPARACIÓN DE ESTIMACIONES CON RESULTADOS

3.2.1: COMPARACIÓN POR FECHAS DE ENTREGA

En la siguiente tabla se muestra se comparan las fechas de entrega.

Tarea Fecha estimada Fecha replanificación Fecha final

Seguimiento 14/09/11 1/03/12 28/02/12

Gestión 22/09/11 14/03/12 29/05/2012

Estudio previo 22/04/11 22/04/11 22/04/11

Especificación de requisitos 26/04/11 26/04/11 26/04/11

Formación 14/09/11 18/08/11 18/08/11

Ciclo 1 29/06/11 30/09/11 14/10/11

Ciclo 2 25/07/11 11/01/12 14/01/12

Ciclo 3 5/09/11 28/02/12 20/02/12

Documentación 7/09/11 1/03/12 22/03/12

Tras la replanificación se puede ver que en algunos aspectos las fechas quedaron cortas y en otros se pasaron bastante de la fecha.

25

Ilustración 10: Diagrama de Gantt - Replanificación.


3.2.2: COMPARACIÓN POR DURACIÓN DE LAS TAREAS

La siguiente es la tabla de la comparativa de la duración de tareas.

Tarea Horas estimada Horas reales

Seguimiento 14 20

Gestión 66 134

Estudio previo 43 43

Especificación de requisitos 8 8

Formación 197 229

Ciclo 1 155 289

Ciclo 2 100 167

Ciclo 3 42 128

Documentación 5 3

Total 626 1021

A partir de estos tiempos, se mostrará una gráfico para comprarlos.

Se puede apreciar, que para las partes de estudio el tiempo se ha respetado, pero no es así para las partes en las que se requería implementación, ya que es donde se ha tenido que invertir más tiempo. Tampoco se ha cumplido en el caso de gestión debido principalmente a la documentación del proyecto.

26

SeguimientoGestión

Estudio previoEspecificación requisitos

Formación y aprendizajeCiclo 1

Ciclo 2Ciclo 3

Documentación

Estimación Tiempo real

4:Estudio previo

4: ESTUDIO PREVIO

4.1: INTRODUCCIÓN

En esta sección se mostrarán algunos elementos del marco de trabajo en el que se va a realizar el proyecto.

Inicialmente se presentará la empresa en la que se desarrolla y después información relacionada sobre la herramienta que se quiere probar.

Para finalizar, se seleccionará la herramienta para hacer las pruebas, tras haber hecho una comparativa entre varias.

4.2: DIGI INTERNATIONAL

Digi International fue fundada 1985 como DigiBoard y pertenece a la industria de dispositivos de red. Digi International es líder en dispositivos de red de tipo comercial, y en innovación de la tecnología inalámbrica de máquina a máquina (M2M). Actualmente está centrada en redes embebidas y externas tanto por cable como inalámbricas.

Digi International ha ido adquiriendo numerosas compañías desde su creación .Una de estas oficinas es la que se encuentra en Logroño y es el lugar en el que se desarrolla este proyecto.

4.3: APLICACIÓN BAJO PRUEBA

4.3.1: MÓDULO XBEE

Sin entrar en detalles técnicos, que no conciernen a este proyecto, se puede decir que los módulos XBee son dispositivos de radio frecuencia principalmente utilizados en automatización de casas, sistemas de seguridad, monitoreo de sistemas remotos, alarmas y un largo etcétera.

27

Ilustración 11: Un módulo XBee.

4:Estudio previo

Estos dispositivos son desarrollados por muchos fabricantes, de los cuales existen versiones programables. Uno de estos dispositivos es el XBee desarrollado por Digi.

Para facilitar la tarea de programación de estos módulos, se desarrolló una aplicación con una API para este propósito.

4.3.2. CODEWARRIOR + PLUGIN XBEE SKD

Existe una herramienta llamada Codewarrior y desarrollada por la empresa Freescale. Esta herramienta es usada por la empresa para la programación de sus micros. No hace mucho, en esta herramienta fue cambiada su implementación para pasar a ser implementada sobre el entorno Eclipse

Es sobre esta herramienta donde fue desarrollada la aplicación para la programación de los módulos XBee, mediante un plugin.

Actualmente, el desarrollo de esta aplicación continúa, añadiendo nuevas funcionalidad y actualizaciones. Este es el motivo, por el cual se desea construir un sistema para realizar las pruebas a esta aplicación, principalmente pruebas de integración continua y de regresión.

4.3.3. CONOCIENDO EL ENTORNO.

A continuación, se mostrarán una serie de capturas del entrono de Codewarrior + plugin de XBee con le propósito de presentarlo y mostrar también las distintas partes que se probar en la automatización de pruebas.

Esta parte no pretende mostrar todas y cada unas de las opciones configurables de la aplicación, pero si ofrecer una visión general de ella para facilitar la comprensión de futuras secciones de este proyecto.

Creación de proyectos

En primer lugar se desea probar el proceso de creación de los distintos tipos de proyecto. Para crear un proyecto se deberá acceder al menú archivo y seleccionar el tipo, como se muestra en la siguiente imagen.

En el caso de los dos tipos de projecto, project y sampe, el proceso es idéntico a excepción de la opción elegida que dependerá de cada caso.

28

4:Estudio previo

Después de ser seleccionada la opción aparecerá, un asistente o wizard para guiar el proceso de configuración del proyecto. En la siguiente imagen se muestra uno de los pasos del asistente de creación para en el caso de XBee project.

29

Ilustración 12: Selección de tipo de proyecto XBee project.

4:Estudio previo

Tras finalizar el asistente el proyecto será creado y opcionalmente se le podrán añadir nuevos componentes.

Compilación del proyecto

Una vez que se tiene creado un proyecto es posible compilarlo, haciendo clic derecho en el proyecto y seleccionando la opción build project.

Tras esto aparecerá por pantalla una ventana con una barra de progreso del proceso de compilación, tal y como se muestra en la siguiente captura.

30

Ilustración 13: Asistente de creación de proyectos XBee.

4:Estudio previo

Una vez terminada la compilación aparecerán los todo posibles problemas que hayan podido ocurrir durante la compilación. Concretamente en la zona en la que se encuentra situado el puntero en la imagen anterior.

Volcado del proyecto

Tras una compilación exitosa en la que no existan errores, el proyecto las instrucciones compiladas del proyecto pueden ser volcadas al módulo XBee. Este proceso, de forma análoga a la compilación, es realizado clic derecho en el proyecto y seleccionando la opción run.

La ventada surgida, fruto de ésta selección, presentará el aspecto de la siguiente captura.

31

Ilustración 14: Barra de progreso de compilación de un proyecto.

4:Estudio previo

Mediante ésta pantalla se configura la ejecución del run. Básicamente, se debe seleccionar el fichero generado en la compilación en la casilla Application.

4.4: COMPARATIVA DE HERRAMIENTAS DE AUTOMATIZACIÓN

Para la realización del comentado sistema es necesario buscar una herramienta para la realización de pruebas software sobre interfaces gráficas.

Entre la posible información que se encontró en internet sobre el tema de la automatización, principalmente aparecían dos tipos distintos de aplicaciones.

Unas simplemente eran aplicaciones que reproducían acciones sobre una interfaz gráfica, con la intención de simular el comportamiento de un usuario humano. Esto no era lo que se buscaba.

En cambio el otro tipo de aplicaciones si se trataba de software para la automatización de pruebas.

32

Ilustración 15: Pantalla de configuración del run.

4:Estudio previo

Entre las aplicaciones de automatización que se encontraron destacaron TestComplete y Squish.

Respecto a TestComplete se puede decir, que era capaz de reproducir pruebas interactuando con distintos elementos a la vez. Es decir, que no manejaba únicamente una aplicación, sino que podría utilizar varias e incluso los elementos del sistema operativo. Tenía una integración total.

Por contra, solo esta disponible para sistemas Windows y además utilizaba un lenguaje para los test propietario que podía llegar a ser algo farragoso.

Squish en cambio, está enfocado a realizar pruebas sobre una sola aplicación basa en Java (existen más paquetes para otros entornos), pero es multiplataforma y usa el lengua de programación Python (también soporta otros) permitiendo incluso utilizar sus librerías.

Además de eso Squish permite la ejecución de los test entre máquinas distintas a través de red.

Ya que la herramienta que se quiere probar está basada en Eclipse (Java), y que se busca una herramienta que sea multiplataforma, finalmente se opto por utilizar la herramienta Squish para crear el sistema.

33

5:Especificación de los requisitos

5: ESPECIFICACIÓN DE LOS REQUISITOS

5.1: INTRODUCCIÓN

5.1.1: PROPÓSITO

El propósito es la elaboración de un sistema que permita realizar pruebas software sobre la aplicación Codewarrior + XBee SDK de Digi International. El encargado de realizar los test podrá ejecutar el test y verificar los resultados al final del mismo.

5.1.2: ÁMBITO DEL SISTEMA

El sistema una vez finalizado deberá ofrecerá la posibilidad de seleccionar el test que se quiera efectuar permitiendo además seleccionar sus parámetros de configuración. Deberá ser posible recoger los resultados de los test y por otro lado también disponer de la opción de poder lanzar los test en una maquina virtual de forma automática.

5.1.3: DEFINICIONES, SIGLAS Y ABREVIATURAS

Test XBee_Project: Test que se correrá sobre la aplicación Codewarrior + XBee SDK y el cual estará enfocado en realizar las pruebas de dicha aplicación referentes a los proyectos creados en ella.

Test Xbee_Sample: Test que se correrá sobre la aplicación Codewarrior + XBee SDK y el cual estará enfocado en realizar las pruebas de dicha aplicación en lo referente a las muestras o samples que contiene la misma.

Tester o probador: Será el usuario de los test, la persona encargada de lanzarlos y configurarlos.

Ficheros de configuración: Ficheros que serán leídos por los test para obtener los valores de los parámetros configurables.

5.1.4: REFERENCIAS

Para la elaboración de la especificación de los requisitos se seguirá la norma IEEE STD 830 1998 .

34


5.1.5: VISIÓN GENERAL DEL DOCUMENTO

En este apartado de la memoria se presentarán los requisitos que debe de satisfacer el sistema una vez terminado el mismo.

Este proyecto esta dividido en varios ciclos y en consecuencia puede ser sensible a que se produzcan cambios. Por esa razón los requisitos se definirán de forma general en este punto para posteriormente, si es necesario, ser refinados en sus correspondientes secciones.

5.2: DESCRIPCIÓN GENERAL

5.2.1: PERSPECTIVA DEL PRODUCTO

Ya que la finalidad el propio sistema es la ejecución de pruebas en el entorno gráfico de una aplicación, evidentemente existirá interacción con esa aplicación. Por otro lado, también está la parte de la virtualización por lo que adicionalmente también existe la relación entre la maquina virtual y el sistema.

Mediante el siguiente diagrama se representa las relaciones existentes entre las aplicaciones. La fecha que sale de cada aplicación apunta a la aplicación con la que interactúa.

5.2.2: FUNCIONES DEL PRODUCTO

El sistema estará ideado para ser usado por medio de comandos de consola con parámetros configurables. Mediante estos comandos el usuario de las pruebas podrá lanzar los test sobre la aplicación bajo prueba. Concretamente podrán ser seleccionados y configurados dos tipos de test mediante ficheros de configuración.

El usuario podrá también usar el sistema en una maquina virtual mediante comandos de consola como en el caso anterior. De esta forma, se evitará el tener que disponer de otras máquinas físicas y poder utilizar la infraestructura de máquinas virtuales de Digi.

35

Ilustración 16: Diagrama de relaciones - Perspectiva del producto.


5.2.3: CARACTERÍSTICAS DE LOS USUARIOS

Los usuarios que utilizarán el sistema son trabajadores del departamento de pruebas de la empresa Digi International, personal que posee experiencia trabajando con herramientas similares en otro tipo de pruebas.

5.3 REQUISITOS ESPECÍFICOS

5.3.1: INTERFACES EXTERNAS

El usuario únicamente interactuará con el sistema a través de comandos de consola, ya que la finalidad de este es la de lanzarlo y que funcione de forma autónoma sin necesidad de una interacción continua, por lo que en este caso no es necesario desarrollar una interfaz gráfica para su manejo.

A pesar de esto los comandos de consola deberán cumplir una serie de requisitos:

• RIE1: A través del comando de ejecución de los test se deberá poder seleccionar el tipo de test que se quiera realizar.

• RIE2: Los comandos y sus parámetros deberán ser claros y proporcionar la ayuda necesaria para su utilización.

• RIE3: Los comandos deberán soportar parámetros para cambiar aspectos de su configuración, tanto de los test como del propio comando.

• RIE4: El comando de ejecución de los test deberá lanzar la aplicación Squish.

5.3.2: FUNCIONES

Para la organización de los requisitos de las funciones de sistema se ha optado por utilizar la jerarquía funcional. El motivo principal de esta elección es que ninguna de las otras formas de organización (por tipos de usuario, por objetos, por objetivos y por estímulos) se amoldan bien para este sistema.

• RF1: El test deberá lanzar la aplicación bajo prueba y esperar a que ésta esté lista para ser usada.

• RF2: El test deberá recoger los valores de configuración de los ficheros de configuración.

• RF3: El test deberá realizar todos los pasos en los que esta dividido. Este requisito se desarrollará con más detalle dentro de cada ciclo.

• RF4: El test registrará todos los hitos de la ejecución en un registro de resultados.

36


5.3.3: REQUISITOS DE RENDIMIENTO

Dado que el sistema está formado por varias aplicaciones y que éstas pueden llegar a hacer un gran consumo de los recursos del equipo, es importante buscar la forma mas eficiente de codificación.

• RR1: El código del sistema deberá ser de la máxima eficiencia posible.

5.3.4: RESTRICCIONES DE DISEÑO

Tal como esta diseñado Squish, presenta una dificultad a la hora utilizar ficheros y la comunicación entre cliente y servidor en distintas máquinas. Este problema se explica con mayor detalle en las secciones 6.2.3 y 6.2.3.1. Como solución a esto se ha optado por adaptar la herramienta de virtualización utilizada en el sistema.

• RD1: El sistema dispondrá de una funcionalidad que solucione le problema de los ficheros locales y la comunicación cliente-servidor de Squish mediante máquinas virtuales. Este requisito en tratado en la parte del ciclo 3 del proyecto y en él se desarrollará con más detalle.

• RD2: Los test que se van a diseñar deberán utilizar un fichero de configuración. De normal Squish no ofrece esta funcionalidad.

5.3.5: ATRIBUTOS DEL SISTEMA

Para garantizar la calidad del sistema se tendrán en cuenta los siguientes requisitos.

• RAS1: Fiabilidad; el sistema deberá ser lo suficientemente robusto para garantizar que su ejecución finalizara correctamente. Para esto se dispondrá de mecanismos para evitar problemas en su ejecución o recuperarse de los mismos.

• RAS2: Mantenibilidad; la codificación se estructurara de forma clara para para facilitar la comprensión de la misma. De esta forma será mucho más sencilla la tarea de encontrar errores o hacer modificaciones.

• RAS3: Portabilidad; a pesar de que el sistema estará enfocado para ser utilizado en Windows se adaptará para ser usado en plataformas Linux. También se diseñará en forma de un único paquete para facilitar la instalación.

Al no existir diferentes grupos de usuarios con distintos roles y permisos, en este proyecto la seguridad no será considerada como un atributo para la calidad del sistema. Además, el acceso a este sistema será para uso interno y únicamente se emplea en la intranet de la empresa, sin posibilidad que se acceda del exterior. Tampoco contiene información crítica sobre usuarios u otra información sensible.

37


5.3.6: OTROS REQUISITOS

Sobre otros requisitos existen los referidos a cerca de la documentación.

• RD1: La codificación del sistema deberá estar debidamente documentada.

• RD2: El sistema dispondrá de un manual de usuario para su instalación y manejo.

38

6:Formación y aprendizaje

6: FORMACIÓN Y APRENDIZAJE

6.1: RESUMEN GENERAL

Como ya se ha ido comentando en apartados anteriores, para la realización de este proyecto será obligatorio familiarizarse con una serie de aplicaciones en las que no se tiene ningún tipo de experiencia previa.

Durante la tarea de formación y aprendizaje se estudiarán dichas aplicaciones, entre las que se encuentran principalmente la aplicación bajo prueba, Codewarrior + XBee SDK; y la aplicación de pruebas Squish. Además de estas dos aplicaciones existen también otras como el cliente de gestión de versiones GIT y el gestor de máquinas de virtuales VMWare Workstation, las cuales tendrán un menor peso dentro de esta tarea sobre todo por tener una complejidad bastante inferior.

También se incluye el aprendizaje del lenguaje de programación Python, el cual es utilizado en toda la codificación del proyecto. Se estudiará a través de tutoriales y de pruebas realizadas con la aplicación Squish, de esta forma se espera conseguir los conocimientos necesarios para la utilización de dicha aplicación.

Respecto a la aplicación bajo prueba se espera conocer su forma de funcionar y su comportamiento. De esta forma será posible identificar los puntos claves para los test y la forma de diseñarlos.

En el caso de la aplicación Squish es necesario conocer su estructura y su forma de funcionar para poder usarla. Por este motivo en esta sección se incluye documentación sobre esta herramienta, con el objetivo de presentar una serie de conceptos necesarios para la comprensión de este documento.

6.2: DOCUMENTACIÓN SOBRE SQUISH


Como ya se comento en el estudio previo, la herramienta elegida para la automatización de pruebas es Squish, aplicación desarrollada por la empresa Frologic. Estas son algunas de sus características:

• No es libre. Hace falta licencia para que pueda ser utilizarla.

• Es multiplataforma: Windows, Linux, Unix, Mac, ...

• Soporta varios entornos gráficos: Java, Qt, entornos web, iPhone ,…

39


• Soporta varios lenguajes de programación. Python, JavaScript, Ruby; Perl, …

• GUI Object Map. Mapeo de la interfaz gráfica para hacer referencia sus elementos.

• Soporta pruebas de aplicaciones múltiples. A través de conexiones de red cliente-servidor.

• Test recording: Permite autogenerar código de los script grabando sobre la aplicación.

• Test logging: Permite registrar los resultados de los test.

En este proyecto se utilizará un paquete para sistemas Windows en entornos de Java. La versión utilizada será la v4.1.

6.2.2: APROXIMACIÓN A SQUISH.

A continuación se documentará el Squish IDE, mostrando el proceso de creación de un test. La finalidad de esto no es crear un manual de usuario, sino mas bien será el medio para ir presentado y explicando conceptos.

La herramienta Squish IDE está basada en Eclipse, por lo que resultará familiar a usuarios que ya hayan trabajado con ese entorno.

40

Ilustración 17: Interfaz de Squish IDE.


El panel de la izquierda será donde se vayan agrupando los test creados, y la parte de la derecha donde aparecerá y desarrollara el código de los test. La parte de bajo de la derecha será donde se muestren los los resultados del test después de haber terminado.

Lo primero que debe hacerse es crear un test suite, el proceso es similar a la creación de un nuevo proyecto en Eclipse. Una vez creado la interfaz mostrará un aspecto similar a el siguiente:

Ahora a la izquierda aparece un test suite al que se le ha llamado “suite_py”.

Para definir lo que es un test suite basta con decir que, a efectos prácticos, no es mas que un directorio dentro de cual se irán añadiendo test. El concepto es similar a los paquetes de Java en los que se van agrupando ficheros .java.

De esta forma todos los test que se encuentren dentro de este mismo test suite, compartirán cierta información, como por ejemplo su configuración y el object map. Además, una vez ejecutado el test suite, todos los test de si interior del serán ejecutados de forma secuencial.

A cada uno de estos test se les conoce como test case o caso de prueba y son los ficheros donde realmente se encuentra el código del test a ejecutar.

41

Ilustración 18: Interfaz de Squish IDE – Test suite creado.


A través del icono con forma de hoja de papel puede ser añadido un nuevo test case al test suite. En la siguiente ilustración se muestra el estado de la interfaz anterior con un test case creado:

En este caso se le ha asignado el nombre de “tst_general”.

Como puede verse a la derecha, ahora ya es posible comenzar a escribir código, pero para poder implementar algo que funcione hay que hacer un par de cosas primero.

Lo primero que debe hacerse es registrar la aplicación en la lista de AUTs (Application under test) de manera que Squish conozca cual es el ejecutable de la aplicación que se quiere probar para que pueda arrancarla. Esto puede hacerse a través del menú Squish y también por medio de comandos, como se explicará en el ciclo 1 con el script lanzador.

El siguiente paso es tener mapeada la interfaz gráfica de la aplicación bajo prueba. Con esto se consigue tener una referencia de cada elemento de la interfaz gráfica para poder interactuar con ellos. Esto se consigue mediante el object map, un fichero de texto común a todos los test case de un mismo test suite, que contiene las referencias de los widgets (o elementos de la interfaz) ordenados jerárquicamente.

Elaborar un object map de forma manual es una tarea tediosa, pero afortunadamente

42

Ilustración 19: Interfaz de Squish IDE - Test case creado.


existe la funcionalidad de grabar test. Al grabar un test todas acciones efectuadas en la aplicación que se esta grabando, tanto acciones de teclado como de ratón, serán traducidas a código en el test case y además todas los elementos que no tengan referencia serán añadidos al object map.

Para ponerse hacer una grabación simplemente habrá que usar el botón de record representado con un circulo rojo al lado del test case. A continuación se selecionará la aplicación de la lista de AUTs y será arrancada.

Mientras la aplicación que se graba esta ejecutándose aparecerá una pequeña barra de control con la que se podrá finalizar la grabación.

Una vez que la grabación haya sido terminada se habrá generado el código y añadido las entradas correspondientes en el object map.

Después por medio del botón play, representado de color verde con triangulo blanco apuntando a la derecha, podrá probarse el código generado.

43

Ilustración 20: Interfaz de Squish IDE - Código autogenerado.


6.2.2.1: Conclusión

Con este ejemplo de como usar Squish IDE se ha mostrado una pequeña parte del desarrollo de los test. Aunque la grabación de código es una herramienta potente a la hora de generar los object map y el código autogenerado, no resulta suficientemente para crear código elaborado y más eficiente. Con los resultados de la grabación únicamente se obtiene código secuencial sin ningún tipo de estructura de control de flujo, ni tampoco mecanismos de captura y prevención de errores. Todo esto ya forma parte del trabajo del programador, aunque el código autogenerado es una gran ayuda como punto de partida sobre el que ir moldeando.

6.2.3: MODO DE EJECUCIÓN

En el punto anterior se ha mostrado como es el entorno de desarrollo Squish IDE, pero para tener una mejor visión de como funciona Squish y como será utilizado de forma normal es importante conocer su esquema de ejecución.

En el caso del ejemplo anterior su esquema de ejecución es el siguiente:

Como se muestra en el esquema, para poder lanzar un test script, Squish IDE tiene que arrancar el Squish Runner y el Squish Server.

• Squish Runner es el programa cliente que se conecta a Squish Server. Su función es la de enviar a Squish Server el código del test Script que se va a ejecutar.

• Squish Server es el programa servidor y el que realmente ejecuta las instrucciones que ha recibido del Squish Runner. Una de las primeras instrucciones que tienen los test script es la instrucción de lanzar la aplicación bajo prueba. Cuando esta aplicación arranca Squish Server se encarga de hacer el enlace (Squish Hook) para poder interacturar con la aplicación.

44

Ilustración 21: Esquema de ejecución de Squish IDE.


La anterior es la forma en que Squish IDE ejecuta los test, pero no es la manera habitual de usar Squish, una vez que se han creado los test, sino que sigue este esquema:

El esquema es similar al anterior, tiene los mismos elementos, pero en este caso cada uno de ellos se coloca en el lado del cliente o del servidor de una comunicación de red. De esta forma es posible disponer de varios equipos con el Squish Server a la espera de recibir los test y por otro lado un equipo con todos los test y el Squish Runner que será el encargado de mandarlos a los otros equipos.

También es posible establecer una conexión remota al utilizar Squish IDE en lugar de hacer una conexión local.

6.2.3.1: Problema encontrado

Como se ha explicado en el punto anterior, la arquitectura de cliente servidor entre diferentes máquinas es una muy buena funcionalidad que aporta la capacidad de hacer test simultáneos. Pero desgraciadamente para desarrollo de este proyecto se detectó la inviabilidad de poder utilizarla.

A la hora de recoger los datos de los resultados de los test, surgió la necesidad de buscar el fichero de resultados de la consola de la aplicación bajo prueba. Ese documento se encuentra en los directorios de los proyectos, dentro del workspace, y es creado cada vez que se compilan los proyectos. Es un fichero de texto plano y en el aparece información del proceso de compilación, información que se desea guardar en el registro de resultados de los test.

45

Ilustración 22: Esquema de ejecución de Squish.


La forma de obtener este fichero fue añadiendo dentro de los test instrucciones Python para trabajar con ficheros y acceder a él, para posteriormente copiarlo e incrustarlo en el registro de resultados. En un primer momento esta solución funcionó correctamente.

El problema apareció en el momento en que el test fue lanzado de forma no local, es decir, entre dos equipos diferentes. Los resultados del registro mostraban que no era posible encontrar el fichero de los resultados de consola. Investigando el asunto se descubrió que todas las lecturas (u otras acciones realizadas sobre ficheros y directorios) solo eran posibles en el lado del cliente de Squish. Esto quiere decir que los resultados de la consola, al ser creados en la parte de servidor, nunca podrían ser accedidos. Por esa razón, al ser ejecutados los dos programas en la misma máquina no ocurría este problema.

Para facilitar la comprensión de este problema, se muestra este esquema dividido en dos partes, la parte izquierda del cliente y la derecha de servidor. La parte del cliente ejecuta el test y manda las instrucciones al servidor. Mientras el test se está realizando en la parte del servidor, una serie de directorios son creados por la aplicación bajo prueba, es ahí donde se encuentra el directorio que se quiere copiar. La forma de acceder a él es por medio del código que se encuentra en el script del test, el cual lo busca y hace una copia. Es en este punto donde se produce el problema, ya que se intenta leer de forma local desde un lado de la comunicación, un fichero que se encuentra en el otro.

46

Ilustración 23: Esquema del problema con Squish.


Como solución se decidió utilizar siempre el sistema localmente, pero también se decidió adaptar la herramienta de virtualización para que soportase un funcionamiento similar al ofrecido por la funcionalidad perdida. Esta parte corresponde al ciclo 3 de la vida de este proyecto.

47

7:Ciclo 1: Análisis

7: CICLO 1: ANÁLISIS

7.1: ANÁLISIS DE REQUISITOS


Este es el primer ciclo del sistema y como su nombre indica, “sistema base y test XBee project”, su finalidad es la de desarrollar toda la estructura básica del sistema así como el tipo de test XBee proyect. Una vez que este terminado el ciclo deberá ser posible realizar dichos test sobre la aplicación bajo prueba.

7.1.2: USUARIOS DEL SISTEMA

Este sistema se caracteriza por ser una herramienta con una finalidad muy concreta; la prueba de interfaces gráficas. Esto hace que en el sistema no exista un variado número de roles, ya que simplemente se trabaja a un único nivel de usuario.

A este único usuario del sistema se le asignará el nombre de probador o tester.

7.1.3: CASOS DE USO

Al ser el tester el único usuario del sistema todos los posibles casos de uso recaerán sobre él. Una característica importante del sistema es que debe ser fácil de usar, ya que de él se espera que una vez arrancado el test todo el proceso sea autónomo. Por esta razón el usuario no tendrá un papel muy activo en el uso de este sistema más que en el momento de lanzar el test.

Principalmente y sin entrar en detalles, pueden ser identificados cinco posibles casos de usos que el tester le dará al sistema. Éstos son los siguientes:

• Lanzar servidor.

• Lanzar test.

• Descargar actualización AUT.

• Definir configuración de test.

• Comprobar resultados.

48


Estos cinco casos de uso serán las cinco posibles formas que tendrá el usuario de interactuar con el sistema. A continuación se detallara cada uno de ellos.

7.1.3.1: Lanzar servidor

Mediante este caso de uso, el usuario del sistema podrá arrancar el servidor de Squish para que así se mantenga a la espera de recibir los test que se quieran ejecutar. Su utilización será vía comando de consola y soportará opcionalmente un parámetro para definir el puerto de escucha de la conexión.

49

Ilustración 24: Diagrama de casos de uso ciclo 1 - General.


7.1.3.2: Lanzar test

Este caso de uso se corresponde con el principal cometido de este sistema, ya que en él se engloba todo el proceso de las pruebas. El usuario del sistema, al igual que con el lanzador del servidor, lanzará el test por medio de un comando de consola. El comando dispondrá de varios parámetros configurables que le dotarán de versatilidad.

50

Ilustración 25: Diagrama de casos de uso ciclo 1 - Lanzar servidor.

Ilustración 26: Diagrama de casos de uso ciclo 1 - Lanzar test.


Existirán dos parámetros obligatorios en los se seleccionará la aplicación bajo prueba y también el fichero de configuración del test que correrá sobre ella. Opcionalmente se podrá fijar una ruta para guardar los resultados y un puerto de conexión distintos a los valores por defecto.

Una vez ejecutado comando del lanzador se desencadenará todo el proceso de la prueba. A partir de este punto el sistema funcionará de forma autónoma, ya que todos los parámetros variables ya han sido definidos. El proceso de las pruebas se ceñirá al siguiente diagrama de actividad.

La actividad “Realizar test” cambiará dependiendo del test seleccionado, pero inicialmente siempre en todos los test se lanzará la aplicación bajo prueba y se recogerán los valores del fichero de configuración.

Como en este ciclo también será desarrollado el test XBee project se mostrará a continuación el diagrama de secuencia de dicho test. Lo mostrado en el diagrama se producirá dentro de la actividad realizar test, después de que la aplicación bajo prueba haya sido arrancada y obtenidos los valores de la configuración.

51

Ilustración 27: Diagrama de actividad lanzador de test.


Este diagrama corresponde a la realización de un solo test para un proyecto de XBee, pero en realidad se repetirá tantas veces como conste en el fichero de configuración del test.

A partir de este diagrama se pueden identificar cuatro tipos de objeto que intervendrán en el test: el creador, el compilador, el generador de resultados y el eliminador.

7.1.3.3: Descargar actualización AUT

Mediante este caso de uso, el usuario del sistema podrá descargar del servidor del administrador de versiones, una versión distinta del XBee SDK instalado en la AUT. Gracias a esto será posible probar versiones que un están en desarrollo, pudiendo descargarlas desde este servidor.

El siguiente es el diagrama de casos de uso para la descarga de la actualización de la aplicación bajo prueba.

52

Ilustración 28: Diagrama de secuencia de test XBee project.


Como se muestra en el diagrama, el usuario utilizará un comando de consola el cual pedirá el número de la versión a descargar y de formaba opcional la dirección de un servidor alternativo al utilizado por defecto.

7.1.3.4: Definir configuración de test

El sistema dispondrá de una serie de ficheros de configuración en los que estará definidos una serie de parámetros variables para incrementar la versatilidad de los test.

Estos ficheros serán creados y modificados por el propio usuario tester a partir de unas plantillas.

53

Ilustración 29: Diagrama de casos de uso ciclo 1 – Descarga AUT.

Ilustración 30: Diagrama de casos de uso ciclo 1 - Definir configuración test.


7.1.3.5: Comprobar resultados

Este caso de uso únicamente se refiere a comprobar los resultados de los test efectuados. Mediante este uso el usuario tester podrá comprobar si el test a tenido éxito, o en el caso contrario poder localizar el error que se haya producido.

Para este caso de uso no existen subcasos, por lo que el diagrama de casos de uso general no presentará cambios en este aspecto.

7.1.4: ESPECIFICACIÓN DE REQUISITOS

Como en la sección de especificación de requisitos de este proyecto ya han sido descritos los requisitos de carácter general para todo el sistema, simplemente aquí serán detallados aquellos requisitos propios de este ciclo de iteración. Obviamente el resto de los requisitos también serán tenidos en cuenta, aunque no estén reflejados a continuación.

Para este ciclo únicamente será actualizado el requisito RF3 el cual fue definido de la siente forma:

RF3: El test deberá realizar todos los pasos en los que esta dividido. Este requisito se desarrollará con más detalle dentro de cada ciclo.

Concretamente este requisito deberá ser dividido entre todas las partes que forman el test XBee project. Tal y como se mostró antes en el diagrama de secuencia del test XBee project, se pueden distinguir claramente cuales son esas partes que forman dicho test.

La manera de enumerar estos nuevos requisitos seguirá el siguiente formato RF3.c.s. Donde c referirá al numero de ciclo y s al numero de subrequisito. De esta forma los nuevos requisitos añadidos en esta iteración serán los siguientes:

• RF3.1.1: El test para XBee project deberá ser capaz de probar el proceso de creación de proyectos XBee en la aplicación bajo prueba.

• RF3.1.2: Una vez creado un proyecto deberá probarse la adicción de componentes para ese proyecto.

• RF3.1.3: El test deberá probar el proceso de compilación del proyecto.

• RF3.1.4: Una vez terminado el proceso de compilación deberá guardarse un resumen en formato web de dicho proceso, en el que estén reflejados los resultados de la compilación y la configuración del proyecto.

• RF3.1.5: Una vez completados los requisitos anteriores el proyecto deberá ser eliminado.

• RF3.1.6: El test deberá repetir el proceso tantas veces como su fichero de configuración indique.

54


7.2: CLASES DE ANÁLISIS

En este apartado se presentarán los diagramas de clases que serán utilizadas en este sistema. Aquí únicamente serán mostradas las clases principales sin entrar en detalles sobre sus métodos y atributos. Principalmente estarán divididas en dos capas, la de lógica de negocio y la de persistencia.

7.2.1: LÓGICA DE NEGOCIO

Durante la ejecución del test una serie de objetos serán los encargados de realizar cada una de las partes por las que está formado el test. Estos objetos funcionarán de forma independiente entre ellos, la idea es que cada objeto realice su función deje el test en un estado correcto para que el siguiente objeto tome el testigo de la ejecución.

A continuación se enumeran los objetos y son descritos brevemente.

• Creator: Objeto encargado realizar todo el proceso de creación de los proyectos de XBee.

• Builder: Objeto destinado a realizar la compilación de los proyectos que hayan sido creados.

• Deleter: Objeto que eliminara los proyectos creados anteriormente antes de que el test termine.

7.2.2: PERSISTENCIA

Squish proporciona instrucciones para la creación de un registro de resultados de los test. Por desgracia para realizar un registro con los resultados de la compilación, estas instrucciones se quedan bastante cortas. Por esta razón Se ha decido crear una clase encargada de esta tarea.

• WebLog: Objeto que se encargara de crear un registro de los resultados de la compilación en formato web. Esta clase será utilizada por la clase Builder.

55

8:Ciclo 1: Diseño

8: CICLO 1: DISEÑO

8.1: ESTRUCTURA DEL SISTEMA

8.1.1: ESTRUCTURA LÓGICA

8.1.1.1: Introducción

En este apartado se definirá la estructura lógica que se utilizará para el diseño del sistema. En este caso se ha elegido la habitual arquitectura de tres capa, aunque cabe destacar que por la naturaleza del sistema la frontera entre estas capas puede llegar a ser algo difusa llegando al punto de mezclarse en determinados momentos.

8.1.1.2: Descomposición en capas

El siguiente diagrama muestra la separación en capas del sistema y más adelante una descripción de cada una de ellas.

• Capa de presentación: En esta capa se encuentran los elementos destinados a la interacción con el usuario. Por ese motivo dentro de ella se encontrarán el lanzador de los test y los resultados de los test.

• Capa de lógica de negocio: Esta capa contiene todo el peso operacional del sistema. Es la encargada de realizar los test y también de servir de nexo entre las capas de presentación y persistencia.

• Capa de persistencia: En esta capa se encontrarán todos los resultados obtenidos de los test que hayan sido ejecutados. El formato utilizado para ser guardados será el de documentos xml.

56

Ilustración 31: Diagrama de descomposición de capas lógicas.

8:Ciclo 1: Diseño

En el diagrama son representadas cinco relaciones entre los distintos elementos. A continuación se explicará cada una de ellas.

1. Cuando el usuario utiliza el comando lanzador hace que el sistema se prepare para efectuar el test.

2. Durante el test esta siendo ejecutado se irán generando entradas en el registro por cada uno de los puntos de verificación que hayan sido incluidos en el test. Estos resultados se guardan en formato xml.

3. Cuando se tiene el fichero xml es leído por el script transformador a html.

4. Solo cuando la ejecución del test a terminado el script transformador será lanzado.

5. El script transformador a partir del fichero xml creará el fichero html para una mayor legibilidad para el usuario.

8.1.2: ESTRUCTURA FÍSICA

En esta sección se muestra una representación de la estructura física del paquete en el que estará incluido todo el sistema.

57

Ilustración 32: Árbol de directorios del sistema.

8:Ciclo 1: Diseño

Este paquete estará formado por un directorio raíz llamado GuiAutomation el cual contendrá los directorios del resto de las partes que forman el sistema.

Tal como es mostrado en el árbol de directorios anterior, GuiAutomation está formado por cuatro subdirectorios y cuatro scrips de Python. Seguidamente se describirá cada uno de ellos:

• Directorio Documents: Este directorio contendrá la documentación relativa al sistema, como los manuales de usuario.

• Directorio extras: En si interior se encuentran instaladores de aplicaciones necesarias para el sistema, como pueden ser el JDK, el interprete de Python y el cliente de GIT.

• Directorio squish: Este directorio se corresponde con el paquete de Squish que es utilizado por el sistema.

• Directorio SquishScripts: En este directorio se encuentra la mayor parte del código del proyecto, puesto que es aquí donde se guardan los scripts de los test. Posteriormente se explicarán cada uno de sus elementos con más detalle en esta misma sección.

• Fichero SourceCodeDownloader.py: Es el script del comando para bajar las versiones de XBee SDK del servidor GIT.

• Fichero SquishServerLauncher.py: Es el script del comando para arrancar el servidor de Squish.

• Fichero SquishTestLauncher.py: Es el script del comando para ejecutar los test con Squish.

• Fichero xml2result2html.py: Es el script utilizado para transformar los registros de resultados de xml a html.

Directorio SquishScripts

Dentro del directorio SquishScripts se encontrará un directorio llamado common. Dicho directorio contendrá elementos necesarios para la apariencia web de los registros de resultados, tales como algunas imágenes y su hoja de estilos.

A parte de el directorio common, SquishScripts poseerá en su interior un directorio por cada una de las herramientas para las que existan test. En el caso de este proyecto, al estar solo enfocado en la herramienta Codewarrior + plugin XBee SDK, únicamente existirá un directorio correspondiente a esa aplicación.

El contenido de cada uno de esos directorio deberá estar formado de los siguientes elementos:

58

8:Ciclo 1: Diseño

• Directorio configurations: Lugar en el que se guardarán las configuraciones de los test.

• Directorio shared: En el que se guardarán elementos compartidos por los test. Este es el directorio en el que estarán guardadas las clases.

• Directorio del suite: En este caso se muestra el suite de XBee project. En el diseño de los test se ha optado por usar suites con un único test case, el cual tendrá el mismo nombre que el suite. Dentro del test case se encontrará el script con el código del test. Dentro del directorio del suite también se encuentran su fichero de configuración y su directorio shared que son generados siempre por Squish.

• Fichero AppPath.txt: Contiene la ruta de donde se encuentra la aplicación bajo test, en este caso el codewarrior. Su finalidad es que sea leído por el script lanzador para que pueda registra la aplicación en la tabla de AUTs de Squish de forma que el usuario se ahorre tener que hacerlo a mano.

• Fichero ConfigPath.txt: Contiene la ruta del fichero de configuración que será utilizado. La necesidad de este fichero surge de querer pasar a Squish un parámetro para la configuración a utilizar, pero Squish no permite poder hacer eso. Así que la solución a este problema es la de usar un fichero que contenga la ruta del fichero del configuración y que cada vez que es lanzado el SquishTestLauncher modifique ese fichero con la ruta nueva para que luego sea leída por el dentro del test.

• Fichero cwide.map: Es el fichero del mapeo de la interfaz gráfica que se genera dentro de todos los suites para poder hacer referencia a los widgets. La finalidad de que se encuentre aquí es la de poder compartirlo con todos los suites y que así puedan utilizar los mismo nombres de referencia para los elementos.

8.2: DISEÑO DE CLASES

Tal como se comento en la fase de análisis del ciclo 1, son cuatro las clases que serán implementadas es el caso de test XBee project. Tres de estas clases corresponden con la parte de lógica de negocio y la restante a la de persistencia de datos.

En un primer momento, a estas clases se las nombró como creator, builder, deleter y webLog, pero a partir de ahora recibirán otros nombres más acordes para el test. A parte de este cambio de nombres también serán incluidas otras clases adicionales.

En la siguiente ilustración se muestra el nuevo diagrama de clases para el test XBee project, el cual hace posible su actualización para próximos tests.

59

8:Ciclo 1: Diseño

Como se muestra en la ilustración, existen cuatro clases de distinto tipo: XBeeProjectCreator, XBeeProyectBuider, XBeeProjectDeleter y WebLog. Cada una de estas clases se encargará de una parte concreta dentro del test.

XBeeProjectCreator será la clase encargada de crear los proyectos de XBee para posteriormente poder ser utilizados por el resto de fases del test. Esta clase contendrá el código correspondiente a la creación de un proyecto genérico, es decir, que se encargará de las partes comunes de todos los proyectos de XBee y también las pulsaciones de botones de la interfaz.

Para el caso del test XBee project se utilizará la clase XBeeDefinedProjectCreator que hereda de la anterior sobrescribiéndola y completándola. Como muestra el esquema, le dispone de dos métodos nuevos para añadir componentes al proyecto.

XBeeProjectBuilder se encargará de hacer el build o compilación del proyecto una vez haya sido creado y configurado. En esta caso el proceso de compilación será identico para todos los proyectos de XBee, por lo que no será necesario hacer ninguna especialización.

XbeeProjectDeleter eliminará todos los proyectos XBee existente. Éste es el último paso de los test.

WebLog es una clase que será utilizada para generar los registros de resultados de los builds de los proyectos. Esta es una clase de carácter general ya que estará diseñada para adaptarse a distintos test.

Para el caso del test XBee project, existirá la clase XbeeWebLog que heredará de la anterior reescribiendo solo uno de sus métodos. Esta clase será utilizada por la clase XbeeProjectBuilder para generar.

60

Ilustración 33: Diagrama de clases ciclo 1.

8:Ciclo 1: Diseño

8.3: REPRESENTACIÓN DE WEB DE LOS RESULTADOS

A la hora de crear un registro de resultados con Squish se dispone de unas instrucciones de código para tal propósito, de forma que es posible registrar distintos tipos de mensajes que se quiera guardar, como pueden ser errores, mensajes informativos o mensajes satisfactorios. Cuando es terminado el test a partir de estos mensajes es creado un fichero xml en el que se almacena esta información.

El fichero xml internamente esta formado por una parte con la información del test así como un resumen del mismo, y otro parte que contiene todos los mensajes creados durante el test.

A la hora de representar esta información en web se buscará obtener una estructura similar la siguiente.

Sin embargo este diseño para se queda corto para representar la información de la compilación de los proyectos XBee. Por este motivo para dicha información se utilizará adicionalmente el diseño mostrada más abajo. La idea es ofrecer como presentación inicial el diseño de arriba y esta tenga los enlaces a los resúmenes de los build en las lineas de resultados que proceda.

61

Ilustración 34: Esquema interfaz web de resultados.

8:Ciclo 1: Diseño

Como se puede comprobar en la imagen, la interfaz estará dividida en cuatro zonas.

En la zona de configuración del proyecto estará la información referente a los componentes que contenga dicho proyecto.

En la zona de información del build se mostrará si la compilación ha tenido éxito o no y también su tiempo de inicio y final.

En la zona de información de consola se incrustará el fichero de los resultados de consola del proyecto.

Y en la zona de problemas build aparecerá, o no, una lista con los errores que se hayan producido durante la compilación.

62

Ilustración 35: Esquema interfaz web compilación

8:Ciclo 1: Diseño

8.4: ESPECIFICACIÓN DE LA PRUEBAS

En este apartado se especificarán las pruebas unitarias que deben ser realizadas en cada una de las partes que componen ciclo del sistema.

Se enfocarán en la parte de interacción con el usuario, es decir la parte de lo comandos de consola.

El resto del código del sistema, lo que viene a ser la parte de los test, se probará mediante test periódicos diarios con distintos tipos de configuración efectuados como usuarios del sistema. De esta forma se comprobará la eficacia de los test y se detectarán posibles errores.

8.4.1: CLASES DE EQUIVALENCIA

8.4.1.1: SquishServerLauncher

Condición Clases válidas Clases no válidas

Puerto

Tipo Es entero SSL1 No es entero SSL2

Nº caracteres No vacío SSL3 Vacío SSL4

8.4.1.2: SquishTestLauncher


Aplicación

Unicidad Existe STL1 No existe STL2

Nº caracteres No vacío STL3 Vacío STL4

Test



Puerto

Tipo Es entero STL9 No es entero STL10


Ruta de resultados



63

8:Ciclo 1: Diseño

8.4.1.3: SourceCodeDownloader


Servidor

Unicidad Existe SCD1 No existe SCD2

Nº caracteres No vacío SCD3 Vacío SCD4

Versión



8.4.2: IDENTIFICACIÓN DE LOS CASOS DE PRUEBA

A continuación se mostrarán los casos de prueba mínimos que deberán probarse una vez terminada la implementación.

Se dividirán para cada uno de los script que se va a probar.


Casos de prueba válidos:

Prueba unitaria 1

Descripción Inicialización correcta del servidor.

Entradas Puerto: 4322

Clases de equivalencia SSL1, SSL3

Resultado esperado Correcto

Prueba unitaria 2

Descripción Inicialización correcta del servidor con valor por defecto.

Entradas Puerto:

Clases de equivalencia SSL3


64

8:Ciclo 1: Diseño

Casos de prueba no válidos:

Prueba unitaria 3

Descripción Inicialización del servidor fallida

Entradas Puerto:hola


Resultado esperado Error. Muestra la ayuda.



Prueba unitaria 4

Descripción Inicialización correcta de los test.

Entradas Aplicación: cwideTest: XBeeProject1.txtPuerto:Resultados:

Clases de equivalencia STL1, STL3, STL5, STL7, STL12, STL16


Prueba unitaria 5

Descripción Iniciación vacía para ver ayuda.

Entradas Aplicación:Test:Puerto:Resultados:

Clases de equivalencia STL4, STL8, STL12, STL16

Resultado esperado Correcto. No arranca y muestra la lista de aplicaciones.

65

8:Ciclo 1: Diseño

Casos no válidos:

Prueba unitaria 6

Descripción Completar solo el test.

Entradas Aplicación:Test: XBeeProject1.txtPuerto:Resultados:

Clases de equivalencia STL4, STL5, STL7, STL12, STL16

Resultado esperado Se produce un error por elegir un test sin haber elegido la aplicación.


Casos válidos:

Prueba unitaria 7

Descripción Descargar versión en servidor por defecto.

Entradas Servidor:Versión: 1.1.1

Clases de equivalencia SCD4, SCD5, SCD7


Casos no válidos:

Prueba unitaria 8

Descripción Descargar versión incorrecta en servidor por defecto.




66

9:Ciclo 1: Construcción

9: CICLO 1: CONSTRUCCIÓN

9.1: TECNOLOGÍA EMPLEADA

Para la elaboración de la mayor parte de este proyecto se ha utilizado la herramienta Squish IDE y para su codificación el lenguaje Python. Mediante este entorno de desarrollo han sido creados los guiones de los test con ayuda de las herramientas que ofrece.

Por otra parte, también existe otra parte de programación que no corresponde directamente a la codificación de los test, sino a los lanzadores para ellos. En este caso se utilizó las herramientas que proporciona Python al ser instalado para la programación.

Otra de las tecnologías utilizadas han sido html y xml para la parte de los registros de resultados.

9.2: DESCRIPCIÓN SQUISH IDE


Squish IDE es el entorno de desarrollo incluido dentro del paquete de Squish, la finalidad es esta aplicación es la de facilitar la creación de los test que Squish ejecutará.

Como una de las primeras fases en este proyecto fue seleccionar una herramienta de automatización de entre las disponibles en el mercado, fue realizada una comparativa entre algunas de ellas. Una vez que fue elegida Squish, se realizó un estudio para familiarizarse con ella y conocer sus limitaciones. A partir de este estudio se redactó una documentación que describe algunos aspectos de Squish IDE, concretamente en el punto 6.2.2. ”Aproximación a Squish” de este documento.

9.2.2: RESUMEN DE LO YA CONOCIDO

A continuación se presentan los siguientes puntos a modo de resumen:

• Cada prueba creada es considerada como un caso de prueba o test case.

• El test suite es un directorio en el que están contenidos varios test case. Además contiene otro tipos de ficheros de uso común.

• Object.map es un fichero en el cual están incluidos los elementos de la interfaz que se va a probar. Almacena los elementos de forma jerárquica y está incluido dentro del test suite.

67


• Es posible grabar una secuencia de ejecución para generar código del script.

9.2.3: SQUISH Y JAVA

La versión utilizada de Squish para este proyecto es la versión para aplicaciones Java. Esto permite poder crear y realizar test sobre cualquier aplicación gráfica creada con Java, pero además proporciona una ventaja adicional.

Para la implementación de los test, como es de esperar, es posible utilizar cualquier tipo de librería de Python incluyendo las que proporciona el API de Squish. Pero además también es posible usar parte del código de Java de la interfaz gráfica.

Para cada elemento de la interfaz gráfica bajo prueba, Squish es capaz de conocer sus métodos y atributos, con lo que se obtiene un potencial enorme para escribir los test.

Para poder acceder a esta información, Squish IDE proporciona una utilidad que lanza la aplicación bajo prueba y una vez arrancada puede ser seleccionado cualquier elemento de la interfaz. Como resultado de esto son mostrados en pantalla los atributos y métodos del objeto en cuestión.

9.3: INTERFACES DEFINITIVAS

En este apartado se mostrará como es el resultado final de la interfaz web de resultados.

El siguiente es un ejemplo de la como es la apariencia del la interfaz para los resultados del test.

68


Como se concretó el diseño esta dividido en dos partes, el resumen y los resultados. En cada resultado se muestra su fecha de realización y una descripción. Las lineas verdes corresponden a puntos de verificación que han sido correctos, los errores serán mostrados en rojo.

En el caso de los resultados de la compilación su apariencia será como la que viene a continuación.

69

Ilustración 36: Interfaz web de los resultados del test.


En la parte de configuración se mostrarán todos los componentes que tenga el proyecto, al ser pulsado cada uno se mostrarán los valores de sus parámetros.

En la parte Build Output se mostrará que tipo de complicación ha sido, satisfactoria, satisfactorio con warnings o erronea. También se incluye el tiempo que ha tardado en compilarse.

El fichero con los resultados de consola es incrustado en la sección Build Console log.

Y finalmente se mostrará una tabla con problemas que hayan ocurrido. Se mostrarán errores en color rojo, warnings en amarillo e infos de color azul. Para cada uno de ellos se mostrará su localización ayudar a solucionarlos.

70

Ilustración 37: Interfaz web de los resultados de la compilación.


9.4: CÓDIGO RELEVANTE

En esta sección se documentan aspectos de la programación que son destacables ya bien por su complejidad o importancia.

9.4.1: SQUISHTESTLAUNCHER.PY

Éste es el script que contiene el código del comando de consola utilizado para lanzar los test. Tanto SquishTestLauncher como SquishServerLauncher y SourceCodeDownloader tienen un estructura similar, ya que los tres pueden dividirse en las siguientes partes:

• Parte de ayuda y documentación del comando. Información mostrada cuando se escribe el parámetro “-h” que sirve para mostrar la ayuda.

• Recogida de parámetros.

• Verificación de parámetros.

• Ejecución del comando.

Sin embargo en el caso de SquishTestLauncher estas partes son más complejas, acorde con la mayor complejidad de este script con respecto a los otros.

En el caso de los otros script se trata simplemente de recoger los parámetros y ejecutar el código de forma secuencial, pero para el caso de SquishTestLauncher será capaz de mostrar mayor información al usuario sobre las opciones de los parámetros.

SquishTestLauncher tiene dos parámetros obligatorios que se corresponde con la aplicación bajo prueba y el fichero de configuración que serán usado para el test. La idea es que si es lanzado SquishTestLauncher sin alguno de los parámetros obligatorios, muestre un aviso con la ayuda y la lista de las posibles aplicaciones y ficheros de configuración que se puedan utilizar.

Todo este proceso es realizado por la función getConfig de SquishTestLauncher. A continuación se muestra su código.

71


Este código es similar al que tienen los otros dos scripts pero es bastante mas extenso. Con este código se recogen los valores de los parámetros del comando y también es generada la ayuda. La parte final de las condiciones se encarga de comprobar la validad de los parámetros, también en esta parte se muestran las listas de aplicaciones y configs mediante las funciones autList() y testList() que se muestran a continuación.

72

Ilustración 38: Código SquishTestLauncher.py - Función getConfig()


9.4.2: SELECCIONAR COMPONENTES PARA PROYECTOS XBEE

Dentro del código de los XBee project una vez que se ha creado un proyecto XBee, son añadidos los componentes de ese proyecto. Este proceso, debido al elevado número de comportamientos posibles, adquiere un nivel de dificultad reseñable.

Cada vez que un nuevo componente es añadido a un proyecto ocurrirá una de las siguientes situaciones:

El componente debe ser único.

Existen componentes que tiene la cualidad de ser únicos, o lo que quiere decir que un proyecto solo puede tener uno de ellos al mismo tiempo. Esto provoca que si alguno de estos componentes es añadido por segunda vez se muestre una ventana de información avisando de este suceso, como se puede ven la imagen siguiente.

73

Ilustración 39: Código SquishTestLauncher.py - Funciónes autList() y testList().


Los pines son insuficientes.

Los XBee físicamente están formados por veinte pines o patillas. Para algunos de sus componentes es necesario que tengan asignado uno o más pines, por consiguiente esto hace que llegue un momento en el que los pines se agoten o no sean suficientes.

Cuando ocurre esto, un mensaje por pantalla aparece indicando que los pines son insuficientes, tal como se muestra en la imagen siguiente.

74

Ilustración 40: Añadir componente - Componente único.


Sin embargo en este caso, a partir de este momento, pueden ocurrir dos cosas. Una de ellas es que no pueda ser posible añadir este elemento y termine, y la otra que la herramienta busque una solución reasignado los pines. Para el segundo caso aparecerá la siguiente ventana.

75

Ilustración 41: Añadir componente - Pines insuficientes.


Una vez que se ha encontrado un solución pide la verificación del usuario para hacer efectivos los cambios.

Componente necesario.

Puede darse el caso de que al añadir un componente, éste necesite otro componente para poder funcionar. En caso de ocurrir esto se mostrará una ventana modificando de este hecho y posteriormente añadirá los dos componentes. Al añadir un componente adicional puede producir uno de los casos anteriores.

76

Ilustración 42: Añadir componente - Reasignar pines.


A continuación se muestra el código del método que gestiona todo el proceso de añadir componentes a un proyecto, que tiene en cuanta los casos anteriores.

77

Ilustración 43: Código clase XBeeDefinedProjectCreator - Método clickAddButton


9.4.3: RECOGIDA DE LOS PROBLEMAS DE COMPILACIÓN

Mientras la compilación de un proyecto es realizada puede darse el caso de que ocurra algún problema, estos son mostrados en la parte inferior izquierda de la aplicación como se puede ver en la siguiente imagen.

Como se muestra en la imagen, existen dos errores en la compilación, los cuales hay que recoger para que puedan ser añadidos al registro de resultados. El problema es que estos elementos de la interfaz gráfica son variables, elementos que no tienen por que ser esperados, por no estarán guardados dentro del object.map. Esto es un problema a la hora de intentar acceder a esos elementos ya que no tienen una referencia directa.

Este problema no aparece únicamente en esta parte del test, pero al ser la primera vez que fue detectado se utilizará para documentar la solución.

Principalmente, la idea para solucionar esto es conseguir la referencia de un elemento que sea fijo y que contenga los elementos variables a los que se quiere acceder. De esta forma a través de ese elemento fijo se pueden obtener sus elementos hijos en tiempo de ejecución.

78

Ilustración 44: Problemas de compilación.


El siguiente código es el correspondiente a la lectura de los errores de la interfaz.

Mediante este método auxiliar se recorre la lista de los problemas de la compilación y se van guardando.

Es interesante reseñar la instrucción problemTree=waitForObject(":Problems_Tree", 600000) , mediante la cual se obtiene un objeto, que es la referencia del elemento que contiene la lista de problemas. Posteriormente, de este objeto se pueden obtener sus hijos mediante esta otra instrucción childrenProblemTree=object.children(problemTree).

Una vez que se tiene el array con los hijos del elemento pueden ser recorridos por medio de una estructura de iteración, generalmente un bucle for.

En este caso los hijos de la lista de problemas solo pueden ser tres, errors, warnings e infos. Estos elementos son los grupos en los que están divididos los problemas, por lo que habrá volver a repetir el proceso anterior para cada uno de los grupos y obtener así sus hijos.

79

Ilustración 45: Código de la clase XBeeProjectBuilder - getProblems.


9.4.4: FUNCIONES AUXILIARES PARA LA FIABILIDAD DEL TEST

Además de las clases que son utilizas por los test, también han sido desarrolladas unas funciones auxiliares de carácter general, para garantizar que durante la ejecución del test no se produzcan impedimentos para su finalización.

La razón de la implementación de estas funciones fue a causa de un comportamiento de la aplicación bajo prueba que podía ocasionar problemas al proceso del test que estaba siendo ejecutado. Esta aplicación tiene una funcionalidad para gestionar sus paquetes, con la cual es posible actualizar la aplicación, y la cual puede ser accedida a través de un botón en la interfaz.

Esto no provocaría ningún problema si no fuera porque cada vez que la aplicación para XBee es iniciada lanza la siguiente ventana que puede verse a continuación.

Es una ventana de asistente para facilitar la utilización de la herramienta de XBee a nuevos usuarios, y su problema no es que aparezca al inicio de la aplicación sino que su aparición es variable en el tiempo. Por poner un ejemplo, una vez puede aparecer en un segundo, pero la siguiente vez tardar diez.

80

Ilustración 46: Ventana de Package Manager.


La aparición descontrolada de esta ventana (y también de otras) ocasionaba problemas en los elementos que quedaban debajo de ella, impidiendo que pudieran ser manejados al no ser visibles.

Otro problema que ocasionaba la aparición espontánea de estas ventanas esta con los menús de la aplicación para XBee. En ocasiones un menú podía ser desplegado y antes de pulsar en la opción deseada aparecía una de estas ventanas haciendo que el menú se cerrará, provocando que la opción no fuera posible de seleccionar.

Para solucionar estos problemas tan molestos para la ejecución del test implementaron las siguientes tres funciones.

9.4.4.1: handleShell()

En la API de Squish existen instrucciones para trabajar con eventos, uno de ellos es “Dialog Opened” el cual detecta cuando una ventana aparece.

Mediante la instrucción installEventHandler("DialogOpened", "handleShell") es posible asignar una función para que sea ejecutada cada vez que se produzca ese evento. La función para este caso es la siguiente.

Básicamente, esta función recibe la ventana abierta como un objeto y comprueba su nombre en una lista de ventanas permitidas que está en el fichero de configuración del test. De esta forma, cada vez que una ventana no permitida aparece es cerrada y se añade una linea en el registro de soluciones para que conste este hecho.

9.4.4.2: clickMenuOptionWithRetry()

Con esta función mediante recursividad se soluciona el problema que ocurría con los menús y las ventanas emergentes. Gracias a ella es posible que se haga un reintento en caso de que un elemento de un menú no sea detectado.

81

Ilustración 47: Código de handleShell.


El siguiente es el código de la función.

Cada vez que se produce un nuevo ciclo recursivo es añadida una linea en el registro de resultados.

9.4.4.3: clickContextualMenuOptionWithRetry()

Esta función es similar a la anterior, con la diferencia de que es para los menús contextuales que salen al pulsar el botón derecho de ratón.

82

Ilustración 48: Código de clickMenuOptionWithRetry.

Ilustración 49: Código de clickContextualMenuOptionWithRetry.


9.5: RESULTADO DE LAS PRUEBAS

Finalizada la parte de implementación de este ciclo del proyecto se procedió a realizar los test definidos en el punto 8.4 de este documento, hasta que todos fueron superados produciendo los resultados esperados.

A partir de este momento y durante el desarrollo de los siguientes ciclos del proyecto, se utilizará diariamente el test XBee project con la finalidad de probar tanto la aplicación para la que fue creado, así como para la detección de posibles errores no detectados o la necesidad de depurar el código.

Actualización:

Gracias a las pruebas periódicas se han podido detectar fallos en la aplicación bajo prueba y también algunas partes del código de test han sido mejoradas.

83

10:Ciclo2: Análisis

10: CICLO2: ANÁLISIS

10.1 ANÁLISIS DE REQUISITOS


Actualmente ha sido terminado el ciclo 1 y con él se ha conseguido la base del sistema y la capacidad de hacer los test para los proyectos de XBee.

En este nuevo ciclo se pretende incluir un nuevo tipo de test en el sistema, el test XBee samples, destinado a efectuar las pruebas sobre las muestras que tiene la aplicación bajo prueba. Estas muestras son proyectos finalizados para XBee que pueden ser utilizados a modo de ejemplo o en algunos casos como pruebas para el propio módulo XBee.

La integración de este nuevo test no supondrá ningún cambio para el sistema base, por lo que muchas partes de éste serán prácticamente iguales. Debido a esto simplemente se documentará lo que sea nuevo para este ciclo.

10.1.2: CASOS DE USO

Para el ciclo actual con respecto a los casos de uso no se produce ningún cambio.. Sin embargo, es importante reseñar un nuevo añadido para la sección 7.1.3.2. de este documento.

En esa sección se muestra el diagrama de actividad para el lanzamiento del test, en el cual se menciona una actividad llamada “realizar test”.

Para esta actividad se creó un diagrama de secuencia para el test XBee project. Ya que este ciclo esta enfocado en el test de XBee samples es necesario crear un nuevo diagrama de secuencia para él.

A continuación se muestra el nuevo diagrama de secuencia para el test XBee samples.

84


Como se puede ver en el diagrama anterior, existen algunas diferencias con respecto a diagrama del test XBee project.

Para empezar, a la hora de crear un sample ya no es necesario añadir componentes puesto que el propio sample esta formado por los que necesita.

El otro cambio es la aparición de dos nuevas partes en el proceso del test. Estas dos nuevas partes se corresponderán a dos nuevas clases que habrá que diseñar.


Como ya se hizo con el ciclo anterior, pasaremos a detallar los requisitos para este ciclo. Concretamente, de nuevo se trata de un refinamiento del requisito RF3.


Se recuerda que la manera de enumerar estos nuevos requisitos sigue el siguiente formato RF3.c.s. Donde c referirá al numero de ciclo y s al numero de subrequisito. De esta forma los nuevos requisitos añadidos en esta iteración serán los siguientes:

• RF3.2.1: El test para XBee samples deberá ser capaz de probar el proceso de creación de los samples de XBee en la aplicación bajo prueba..

85

Ilustración 50: Diagrama de secuencia del text XBee Samples.


• RF3.2.2: El test deberá probar el proceso de compilación del sample.

• RF3.2.3: Una vez terminado el proceso de compilación deberá guardarse un resumen en formato web de dicho proceso, en el que estén reflejados los resultados de la compilación y la configuración del sample.

• RF3.2.4: El test deberá probar el proceso de flasheo y ejecución con los samples compilados.

• RF3.2.5: El test deberá de ser capaz de interactuar con el terminal del módulo XBee.

• RF3.2.6: Una vez completados los requisitos anteriores el sample deberá ser eliminado.




Estas son las clases que forman parte de la lógica de negocio:

• Creator: En esta ocasión se encargara de crear los samples. No hace ninguna operación adicional.

• Builder: No presenta cambios.

• Ejecutor: Se encarga de volcar el código compilado al módulo XBee y hacer que lo ejecute.

• Manejador del terminal: permite realizar una conexión con el dispositivo XBee e interactuar con él.

• Deleter: No presenta cambios.

10.2.2: PERSISTENCIA

Esta es la clase de la parte de persistencia:

WebLog: No presenta cambios.

86

11:Ciclo 2: Diseño

11: CICLO 2: DISEÑO


Al igual que sucedía en la fase de análisis, en esta nueva fase tampoco se producen cambios significativos.

La estructura lógica se mantiene como en el ciclo 1 y para el caso de la estructura física solo cabe mencionar la adición del test XBee samples dentro del directorio SquishScript/cwide.


En cuanto a las clases de los test, se produce un cambio significativo con respecto al test XBee project, ya que para el caso de los samples entran en juego un mayor número de clases.

Muchas de las clases existentes del anterior ciclo serán vueltas a utilizar en este test, el resto serán implementas o heredaran de las anteriores.

Como se puede ver en el diagrama y, representadas en azul para distinguirlas del resto, tres son las nuevas clases necesarias para poder realizar el test XBee samples.

Las clases XBeeProjectBuilder , XBeeProjectDeleter y XBeeWebLog volverán a ser como eran antes. No ocurre lo mismo con la clase XbeeDefinedProjectCreator, ya que

87

Ilustración 51: Diagrama de clases del ciclo 2.

11:Ciclo 2: Diseño

ésta era una especialización de la clase XbeeProjectCreator para los test de los proyectos de XBee. Para este test es necesario crear una nueva clase especialidad para los test de los sample. Esa clase es XBeeSamplesProjectCreator.

La clase XbeeProjectBuilder se encargara de volcar el código compilado del sample en la memoria flash del módulo XBee. Para poder hacer esto el modulo XBee debe estar conectado al PC por medio de un cable USB para su alimentación y tener instalados los drivers correspondientes. Además, también deberá estar otro aparato llamado debugger conectado entre el PC y el módulo XBee, este aparato es el que realmente hace el flasheo al XBee. La clase también genera un fichero con los resultados de la ejecución.

La última clase creada, XbeeProjectTerminal, es una clase diseñada con un patrón singleton. Esta clase tiene la función de conectarse mediante el terminal de la interfaz gráfica para poder interactuar con el módulo XBee. La conexión se realiza a través del cable USB por el que esta conectado XBee.

11.3: ESPECIFICACIÓN DE PRUEBAS

Al no producirse cambios en el sistema, no hay necesidad de realizar pruebas nuevas. Sin embargo para garantizar que la integración del ciclo 2 ha sido satisfactorio, se volverán a repetir los mismas pruebas unitarias del ciclo anterior y se comprobará que no se hayan producido cambios.

Una vez que el ciclo este terminado, al igual que en el anterior, el resto de código generado se probará con la ejecución de test periódico diarios del test XBee samples, sin olvidarse tampoco del test XBee project.

88

Ilustración 52: Debugger



12.1 TECNOLOGÍA EMPLEADA

La tecnología empleada en este ciclo sigue siendo la misma que la que se utilizó en el ciclo anterior. Por lo tanto se sigue utilizando la herramienta Squish IDE para desarrollar los test.


Como ya se ha comentado en la fase de diseño, la clase encargada de generar los resultados web no ha cambiado y lo mismo ocurre para script que transforma de xml a html. Por lo tanto las interfaces siguen siendo las mismas que para el ciclo anterior.


En esta sección se comentarán algunos aspectos de la clase XBeeProjectTerminal, ya que es la que presenta mayores diferencias con el resto.

12.3.1: CLASE XBEEPROJECTTERMINAL


El entorno de desarrollo para XBee contiene una zona en la parte inferior derecha destinada para conectarse con el módulo de XBee. Si estando conectado al módulo de esta forma se vuelca la compilación de un proyecto o sample en el módulo, se observará como la consola del terminal muestra información de que el programa se ha iniciado y si es posible se podrá interactuar con él.

Para poder conectarse a través de este terminal puede usarse el botón de connect. Una vez pulsado aparecerá una ventana en la que se deberán rellenar con los parámetros de la conexión.

En la siguiente imagen se muestra la ventana de los parámetros de la conexión.

89


Como se puede ver en la imagen, la consola es ese recuadro de color amarillo, encima de ella se encuentran los controles para manejarla. Entre esos controles se encuentra el botón connect, el cual esta ya pulsado. La ventana que se encuentra en el centro de la imagen es la de configuración de la conexión del terminal.

Una vez que se han añadido los parámetros para la conexión y haberlos aceptado, se establecerá la conexión con el módulo. Si se pulsa el botón de desconectar la conexión terminará, pero a partir de este momento si vuelve a ser pulsado el botón conectar la conexión volverá a establecerse de forma automática con los parámetros introducidos la primera vez.

Esto quiere decir que únicamente la ventana de Terminal Settings aparece una vez.

Ahora conociendo esta característica del entorno gráfico pasaremos a la codificación.

12.3.1.2: Codificación

Como ya se ha comentado antes, existe una ventana la cual aparecerá solamente la primera vez que es pulsado el botón conectar. Este hecho puede suponer un pequeño

90

Ilustración 53: Ventana de Terminal Settings


problema a la hora de desarrollar el test para los samples, ya que podría ser necesario utilizar dos métodos distintos para hacer la conexión con el terminal; uno para la primera vez y otro para el resto. Pero si se optase por esta solución habría que tener en cuenta cuando se debe usar uno y cuando usar otro.

Para solucionar esto se ha optado por utilizar una idea similar a la que presenta el patrón singlenton, tal y como se muestra en el código.

El código de la imagen se corresponde con dos métodos de la clase XBeeProjectTerminal.

El primero de ellos es el constructor de la clase, el cual inicializa un atributo llamado singleton con valor inicial falso.

Por otro lado está el método connect, el cual dependiendo del valor del atributo singleton hará una cosa u otro. Como en un principio singleton tiene valor falso, realizará la primera parte del código en la que se introducen los parámetros de la conexión y después cambia a verdadero. De esta forma las siguientes veces ejecutará la otra parte del código, donde solo se pulsa el botón.

91

Ilustración 54: Código de la clase XBeeProjectTerminal.


12.4: RESULTADOS DE LOS PRUEBAS

Tras volver a realizar las pruebas unitarias definidas en el punto 8.4, se vuelven a obtener los mismos resultados que en su momento tuvo el ciclo 1. Por esta razón se puede considerar que la integración del ciclo 2 en el sistema ha tenido éxito.

A partir de este momento y durante el desarrollo de la última parte del proyecto, se efectuarán diariamente pruebas de los dos tipos diferentes. Se espera conseguir de esta forma localizar posibles errores no detectados y ayudar a la depuración del código, tal y como se hizo en el ciclo anterior.

92





En este momento los ciclos 1 y 2 se encuentran terminados y a partir de ahora comienza el tercero y último ciclo.

La finalidad de este ciclo es proporcionar al sistema la capacidad de utilizar la infraestructura de máquinas virtuales de Digi, para la realización de pruebas. Adicionalmente en este ciclo se busca cumplir uno de los requisitos generales que fueron definidos al principio. Este requisito es el RD1, y trataba sobre la adaptación de la herramienta de virtualización para solucionar una deficiencia. A grandes rasgos, el problema surgía al no poder leer un fichero desde en la máquina del cliente de Squish. Para una descripción más profunda de este problema consultar la sección 6.2.3.


El usuario del sistema sigue siendo únicamente el tester, pero en esta ocasión se le añadirá un nuevo caso de uso a los que ya posee.

Este nuevo caso de uso se llamará, tal y como se ve en la imagen anterior, lanzar máquina virtual, y mediante él se pretende lanzar la máquina virtual y realizar los test

93



seleccionados sobre ella. A continuación, se amplia el diagrama para este caso de uso concreto.

13.1.2.1: Lanzar máquina virtual

La forma de utilizar este caso de uso por el usuario de sistema, pretende ser por medio de comando de consola. Mediante el diagrama anterior se pueden diferenciar los distintos parámetros por los que está formado el ejecutable.

Principalmente, el comando estará formado por tres parámetros de carácter obligatorio. Estos parámetros estarán destinados a seleccionar la imagen de la máquina virtual, seleccionar una ruta para guardar los resultados y una lista con los test que se quieran ejecutar en la imagen.

Por otro lado, el script de este lanzador deberá tener ciertos valores por defecto que puedan ser cambiados también por medio de parámetros. Estos valores serán el snapshot y el usuario y la contraseña del sistema operativo de la imagen. Sobre el snapshot solo decir que es un estado guardado de una máquina virtual.

94

Ilustración 56: Diagrama de casos de uso ciclo 3 - Lanzar máquina virtual.



En el caso de este ciclo se desarrollará el requisito RD1. Ésta es la descripción que se el dio en su momento:

RD1: El sistema dispondrá de una funcionalidad que solucione le problema de los ficheros locales y la comunicación cliente-servidor de Squish mediante máquinas virtuales.

Siguiendo la nomenclatura definida en los anteriores ciclos para los subrequisto, el requisito RD1 estará formado por los siguientes:

• RD1.1: El script deberá ser capaz lanzar la máquina virtual y cargar el estado inicial en el que podrán ser ejecutados los test.

• RD1.2: El script deberá tener los permisos de usuarios necesarios para lanzar comandos en el sistema operativo de la máquina virtual.

• RD1.3: El script deberá poder funcionar en sistema Windows XP y Windows 7.

• RD1.4: El script deberá ser capaz de mover ficheros y directorios entre el host y la máquina virtual, para por un lado pasarle los test a la máquina virtual y por otro poder recoger los resultados.

• RD1.5: El script deberá ser capaz recibir una lista de test y hacer que los ejecute la máquina virtual.

95

14:Ciclo 3: Diseño




En este nuevo ciclo a pesar de haber sido añadida una nueva aplicación dentro del marco del sistema, se sigue manteniendo la estructura lógica que se definió en el diseño del ciclo 1. Esto es debido a que independientemente de que se utilice una máquina virtual, la estructura de las capas lógicas sigue siendo la misma. Simplemente, ahora hay un paso intermedio entre el lanzamiento del test y su ejecución, el cual puede ser agrupado junto con el lanzamiento del test como una sola parte.


La estructura física del proyecto no ha sufrido ningún tipo de modificación de los elementos que ya contenía. Por otro lado si han sido añadidos nuevos elementos, como se muestra en la siguiente imagen.

96

Ilustración 57: Estructura física de los directorios - Paquete final.

14:Ciclo 3: Diseño

Como se puede apreciar, dentro del paquete de GuiAutomation ha sido añadido un nuevo directorio llamado VIX. Dentro de este nuevo directorio se encuentra la librería vix.dll, la cual es un librería para C con la que es posible manejar el gestor de máquinas virtuales VMWare Workstation.

Mediante esta librería es posible hacer, entre otras cosas, acciones como arrancar una máquina virtual, seleccionar un snapshot o enviar comandos a la máquina virtual para que los ejecute.

Además de esta librería, el directorio VIX contendrá el script ejecutable, VMLauncher.py, para el usuario del sistema y un fichero con el binding de la librería VIX.

El fichero del binding se explicarán en la fase de construcción de este ciclo.

También se puede ver en la imagen, como ahora están los dos tipos de test dentro del directorio SquishScripts/cwide correspondientes a los dos ciclos anteriores.

14.2: ESPECIFICACIÓN DE LAS PRUEBAS

Seguidamente en este apartado, se especificarán las pruebas unitarias de se realizarán sobre el nuevo script lanzador.

Una vez obtenidos los resultado esperados de estas pruebas, se realizarán tests periódicos diarios de todo el sistema para detectar posibles errores ocultos o puntos en los que es necesaria una optimización

Si tras realizar durante un tiempo estos test, el sistema presenta un estado estable, significará que es hora de entregar el sistema al cliente.


A continuación se presentan las clases de equivalencia para el script VMLauncher.


Ruta imagen de la máquina virtual.

Unicidad Existe VML1 No existe VML2

Nº caracteres No vacío VML3 Vacío VML4

Ruta de los resultados.



Lista de los test para ejecutar.


Formato Correcto VML11 Incorrecto VML12

97

14:Ciclo 3: Diseño


Snapshot de la imagen.

Unicidad Existe VML13 No Existe VML14


Usuario del sistema operativo de la imagen.



Contraseña para el usuario.




Las siguientes son las pruebas unitarias mínimas que se deberán de realizar para el script del lanzador VMLauncher.

Casos válidos:

Prueba unitaria 9

Descripción Ejecutar comando normalmente con parámetros por defecto.

Entradas Imagen: Z://vmwareimagens/Windows7.vmxResultados: C://ResultsSquishLista de tests: cwide:Test2.txt;cwide:Test1.txtSnapshot:Usuario:Contraseña:

Clases de equivalencia VML1, VML3, VML5, VML7; VML9, VML11, VML16, VML20, VML24

Resultado esperado Correcto.

98

14:Ciclo 3: Diseño

Prueba unitaria 10

Descripción Ejecutar comando normalmente con parámetros por defecto excepto el Snapshot.

Entradas Imagen: Z://vmwareimagens/Windows7.vmxResultados: C://ResultsSquishLista de tests: cwide:Test2.txt;cwide:Test1.txtSnapshot: XBee SDK 1.0.8Usuario:Contraseña:

Clases de equivalencia VML1, VML3, VML5, VML7; VML9, VML11, VML13, VML15, VML20, VML24


Casos no válidos:

Prueba unitaria 11

Descripción Ejecutar comando con valores por defecto y con ruta de la imagen errónea.

Entradas Imagen: Z://vmwareimagens/Windows7.imgResultados: C://ResultsSquishLista de tests: cwide:Test2.txt;cwide:Test1.txtSnapshot:Usuario:Contraseña:



Prueba unitaria 12

Descripción Ejecutar comando con valores por defecto y el formato de la lista de incorrecto.

Entradas Imagen: Z://vmwareimagens/Windows7.vmxResultados: C://ResultsSquishLista de tests: cwide;Test2;txt;cwide;Test1.txtSnapshot:Usuario:Contraseña:


Resultado esperado Error. Ejecución fallida.

99




En esta ocasión no será necesario utilizar el entorno Squish IDE ni tampoco ningún otro tipo de entorno de desarrollo.

Para tercer ciclo se utilizará la aplicación VMWare Workstation como gestor de imágenes de máquinas virtuales. Mediante esta aplicación es posible crear máquinas virtuales en las que instalar un sistema operativo y hacer que funcione como si se tratase de un ordenador físico.

VMWare también proporciona la capacidad de hacer snapshots de las maquinas virtuales, éstas son como un especie de fotografía que se hacen en la máquina virtual para guardar el estado de la máquina en el momento que se crean. Más tarde con esas snapshot es posible volver al estado en el que fueron creadas.

Por último, existe una librería para C, llamada VIX, que permite manejar la aplicación VMWare por medio funciones. Esta librería se utilizará para crear el script lanzador de VMWare.

15.2: DESCRIPCIÓN DE VMWARE

15.2.1 BINDING DE LA LIBRERÍA VIX.DLL

Como se ha comentado antes, una de las herramientas que se van a utilizar es VMWare. Pero para conseguir un comportamiento automático es necesaria la creación de un script que se encargue de todo su manejo.

Para esto está la librería vix.dll, la cual dispone de funciones capaces de utilizar la herramienta VMWare.

El problema es que es una librería de C y, como ya fijamos al principio de este proyecto, todo el código deberá ser desarrollado en Python, por lo que habrá que buscar una solución a esto.

Si no hubiera existido una solución, no habría más remedio que escribir el script en C. Pero afortunadamente existe una librería de Python, llamada ctypes, que permite hacer un binding entre el código de C y el de Python.

Básicamente un binding es una adaptación de una librería para ser usada en un lenguaje de programación distinto de aquél en el que ha sido escrita.

Para el propósito de este proyecto Digi me proporcionó un paquete de VIX con todas

100


estas partes implementadas, por lo que solamente hizo falta implementar el código del lanzador de VMWare.

A través de este lanzador y gracias al binding, también se enviarán los test desde el host hasta la máquina virtual. Con esto se consigue que los test del host puedan ser ejecutados en la máquina virtual, como si del caso de la especificación perdida descrita en el punto 6.2.3 se tratase.

15.4 CÓDIGO RELEVANTE

La implementación del código para el script lanzador no tuvo mayor complejidad que la de ninguno de los otros scripts creados anteriormente.

Es por este motivo que no existe ningún fragmento de código reseñable para la documentación.


Para terminar este ciclo se realizaron las pruebas unitarias definidas en el apartado 14.2 de la documentación. Fueron realizadas las veces necesarias hasta obtener los resultados esperados.

A partir este momento se utilizará diariamente el sistema completo de las dos formas posibles, local y por virtualización, y para los dos tipos de test que existen. De esta forma se espera poder detectar posibles errores ocultos o necesidades de depuración de código.

A parte de esto, el resultado del proyecto ya puede ser considerado como finalizado, por esa razón se entregará al cliente para pueda utilizarlo.

101

16:Pruebas del sistema y aceptación

16: PRUEBAS DEL SISTEMA Y ACEPTACIÓN

Tras la finalización del las pruebas unitarias del sistema puede considerarse terminado el desarrollo del mismo.

A partir de este momento, se probará que el sistema cumple con todas las especificaciones que fueron definidas en su inicio.

Cabe señalar que en este proyecto el cliente es a la vez la empresa en la que se desarrolla, y la empresa para la que se desarrolla. Esto significa que el proyecto ha tenido por parte de cliente un seguimiento continuo, e incluso ha llegado a probar fases tempranas del sistema mediante pruebas periódicas.

Como consecuencia de esto, el sistema siempre ha estado bien encaminado durante el desarrollo y consecución de requisitos.

Tras todo esto podemos garantizar que el estado actual del sistema es válido y finalizado, por lo que ya puede ser utilizado por el cliente.

102

17:Conclusiones

17: CONCLUSIONES

Esta sección pretende ser el lugar en el que plasmar mis impresiones y reflexiones sobre el periodo de tiempo comprendido entre inicio y final de este proyecto.

17.1: COMPARACIÓN ENTRE OBJETIVOS Y RESULTADOS OBTENIDOS

En el apartado 2.2 Alcance del proyecto, definimos los objetivos que se querían alcanzar a lo largo del desarrollo del proyecto. Eran los siguientes:

Requisitos:






Especificaciones adicionales.




Una vez finalizado el desarrollo del proyecto, se puede afirmar que los requisitos han sido totalmente completados, aunque no ocurre los mismo con las especificaciones adicionales. A pesar de esto el sistema se encuentra preparado para futuras ampliaciones.

103

17:Conclusiones

17.2 VISIÓN PERSONAL

Una vez terminado el proyecto, mi valoración personal del resultado del mismo es satisfactoria, considerando que el objetivo de crear un sistema para la realización de pruebas en entornos gráficos ha sido completado con éxito.

Considero que con la estimación del tiempo no he estado muy acertado, tardado más de lo que en un principio pensaba. La falta de experiencia en este aspecto me hizo ser demasiado optimista, pero también los problemas ajenos a mí, que ocurrieron durante el desarrollo tuvieron su peso. Sin embargo no me quejo de ello, ya que me ha servido para enriquecer más la experiencia vivida y el aprendizaje.

Respecto a la documentación, resulta curioso comprobar como después de pasado un tiempo alcanza un volumen considerable. Al principio, parece imposible creer que serás capaz de generar tal cantidad de información, cuando comparas con otros proyecto, pero finalmente lo consigues. Esto produce mucha satisfacción.

Otro cosa de la que me gustaría hablar, es de los conocimientos que me ha aportado realizar este proyecto; y es que prácticamente todas las herramientas utilizadas eran desconocidas por mí o no tenia experiencia previa. Algunas de ellas son:

• Squish: Tanto el propio Squish como su entorno de desarrollo y todo lo que rodea a las aplicaciones de testeo. Todo esto era desconocido para mí.

• GIT: Conocía los programa de gestión de versiones, pero nunca los había utilizado.

• Lenguaje Python: Tenía intención de aprenderlo pero lo hice hasta llegado este punto.

• Conocer que es un binding en programación.

• VMWare: Ya había utilizado antes aplicaciones similares, pero no ésta.

La obtención de estos conocimientos, y otros que seguramente no recuerde ahora, son un valor que me llevo de esta experiencia. Volviendo la vista atrás, puedo acordarme de como al principio de todo tenía la sensación de estar muy perdido, pero a medida que iba adquiriendo conocimientos esa sensación se iba disipando.

Por último, me gustaría hacer una mención al equipo de DIGI, al que estoy agradecido por brindarme esta oportunidad. He conocido un entorno de trabajo real y además he podido trabajar en algo que será utilizado en el futuro y posiblemente en estos momentos.

En resumidas cuentas, el desarrollo de este proyecto ha sido una experiencia muy positiva, a pesar de haber existido momentos en los que se exigía mucho esfuerzo. Pero eso, al fin y al cabo, hace que sea más gratificante.

104

19: Glosario de términos

19: GLOSARIO DE TÉRMINOS

AUT: Son las siglas de Application under test, o lo que es lo mismo Aplicación bajo test. Es la aplicación que se va someter a las pruebas.

Binding: En programación es una adaptación de una librería para ser usada en un lenguaje de programación distinto de aquél en el que ha sido escrita

Log: Puede traducirse como registro. Suele ser un documento en el que se guardan resultados o en el que se hagan constar eventos que han ocurrido.

Object.map: Es un fichero que normalmente se encuentra dentro de un test suite, y que contiene información sobre los widget. En su interior están las referencias de los widgets ordenadas jerárquicamente.

Test case: Es un script que contiene el código de un test.

Test suite: Es un directorio que agrupa varios test cases. Normalmente contienen información común para todos los cases. Su uso suele ser generalizado en las aplicaciones de pruebas.

Tester o Probador: Es el nombre con el que se conoce al único usuario que usará el sistema. Al ser el único, en ocasiones puede ser nombrado como usuario simplemente.

Widget: Son todos y cada uno de los elementos que forman un interfaz gráfico. Si hay un botón en un interfaz, ese botón es un widget. Si hay un menú desplegable en la interfaz eso es un widget. También pueden ser nombrados en la documentación como elementos de la interfaz.

105

20:Bibliografía

20: BIBLIOGRAFÍA

Para la realización de este proyecto se ha utilizado información obtenida de las siguientes fuentes:

• API de Squish 4.1:

http://doc.froglogic.com/squish/4.1/all/

• Tutorial “Python para todos” de Raúl González Duque.

http://mundogeek.net/tutorial-python/

• Javadoc sobre los Widgets de eclipse(SWT):

http://www.eclipse.org/swt/widgets/

• Documentación de Python:

http://docs.python.org/

106





UNIVERSIDAD DE LA RIOJA

Facultad de Ciencias, Estudios Agroalimentarios e Informática


Ingeniería Técnica en Informática de Gestión

Diseño y automatización de pruebas software en entornos gráficos.

Alumno: Carlos Daniel Serres Martínez

Director: Juan José Olarte

Codirector: Carlos Marín (Digi International)

Logroño, junio 2012

Resumen:

El presente documento contiene la memoria del proyecto “Diseño y automatización de pruebas software en entornos gráficos”, en la que se detalla el proceso seguido hasta la finalización del mismo.

Este proyecto aborda la creación de un sistema que permita realizar pruebas sobre las interfaces gráficas de las aplicaciones que la empresa Digi International desarrolla. En concreto este proyecto está enfocado únicamente en la implementación de este sistema para una de las aplicaciones, un entorno basado en Eclipse para el desarrollo de modulos electrónicos que Digi fabrica, pero se definirá el diseño y estructura básicos para futuras adaptaciones de otras aplicaciones.

Este sistema estará formado y deberá hacer funcionar todas las siguientes partes:

• La herramienta para las pruebas software, Squish.

• Los test que interpretará dicha herramienta.

• Los ficheros de configuración para los test.

• Los ejecutables para lanzar los test.

• Los ejecutables para lanzar un sistema de virtualización, VMWare.

• La generación de los resultados.

Para la realización del proyecto se utilizará el lenguaje Python, así como UML como metodología de ingeniería.

Índices

ÍNDICE DE CONTENIDO

1: Introducción.................................................................................................11.1 Tema tratado................................................................................................................11.2: Motivo de la elección..................................................................................................1

2: Documento de objetivos del proyecto...........................................................22.1: Objetivos.....................................................................................................................22.2: Alcance........................................................................................................................2

2.2.1: Requisitos.............................................................................................................32.2.2: Especificaciones adicionales................................................................................3

2.3: Participantes del proyecto...........................................................................................42.4: Comunicación.............................................................................................................42.5: Metodología................................................................................................................42.6: Tecnologías..................................................................................................................52.7: Identificación de Riesgos y planes de acción..............................................................6

2.7.1: Posibles riesgos....................................................................................................62.7.2: Planes de acción..................................................................................................7

2.8: Entregables.................................................................................................................72.9: Descomposición de tareas...........................................................................................8

Tarea 1: Seguimiento del proyecto.................................................................................8Tarea 2: Gestión del proyecto........................................................................................9Tarea 3: Estudio previo................................................................................................10Tarea 4: Especificación de requisitos............................................................................10Tarea 5: Formación y aprendizaje................................................................................10Tarea 6: Ciclo 1 Base del sistema y test para XBee project........................................11Tarea 7: Ciclo 2 Test para XBee sample.....................................................................12Tarea 8: Ciclo 3 Virtualización del sistema................................................................13Tarea 9: Documentación..............................................................................................13

2.10: Estimación temporal..............................................................................................172.10.1: Calendario de trabajo......................................................................................172.10.2: Estimación del tiempo de las tareas.................................................................172.10.3: Diagrama de Gantt..........................................................................................21

3: Gestión del proyecto...................................................................................243.1: Replanificación..........................................................................................................24

I

Índices

3.1.1: Introducción......................................................................................................243.1.2: Factores de retraso.............................................................................................243.1.3: Replanificación..................................................................................................25

3.2: Comparación de estimaciones con resultados...........................................................253.2.1: Comparación por fechas de entrega..................................................................253.2.2: Comparación por duración de las tareas...........................................................26

4: Estudio previo............................................................................................274.1: Introducción..............................................................................................................274.2: DIGI International.....................................................................................................274.3: Aplicación bajo prueba..............................................................................................27

4.3.1: Módulo XBee.....................................................................................................274.3.2. Codewarrior + plugin XBee SKD.......................................................................284.3.3. Conociendo el entorno.......................................................................................28

Creación de proyectos..........................................................................................................28Compilación del proyecto....................................................................................................30Volcado del proyecto............................................................................................................31

4.4: Comparativa de herramientas de automatización.....................................................32

5: Especificación de los requisitos...................................................................345.1: Introducción..............................................................................................................34

5.1.1: Propósito............................................................................................................345.1.2: Ámbito del sistema............................................................................................345.1.3: Definiciones, siglas y abreviaturas.....................................................................345.1.4: Referencias.........................................................................................................345.1.5: Visión general del documento............................................................................35

5.2: Descripción General..................................................................................................355.2.1: Perspectiva del producto....................................................................................355.2.2: Funciones del producto......................................................................................355.2.3: Características de los usuarios...........................................................................36

5.3 Requisitos específicos.................................................................................................365.3.1: Interfaces externas.............................................................................................365.3.2: Funciones...........................................................................................................365.3.3: Requisitos de rendimiento.................................................................................375.3.4: Restricciones de diseño......................................................................................375.3.5: Atributos del sistema.........................................................................................375.3.6: Otros requisitos..................................................................................................38

6: Formación y aprendizaje.............................................................................39

II

Índices

6.1: Resumen general.......................................................................................................396.2: Documentación sobre Squish....................................................................................39

6.2.1: Introducción......................................................................................................396.2.2: Aproximación a Squish......................................................................................40

6.2.2.1: Conclusión...............................................................................................................446.2.3: Modo de ejecución.............................................................................................44

6.2.3.1: Problema encontrado...............................................................................................45

7: Ciclo 1: Análisis..........................................................................................487.1: Análisis de requisitos.................................................................................................48

7.1.1: Introducción......................................................................................................487.1.2: Usuarios del sistema..........................................................................................487.1.3: Casos de uso......................................................................................................48

7.1.3.1: Lanzar servidor........................................................................................................497.1.3.2: Lanzar test...............................................................................................................507.1.3.3: Descargar actualización AUT..................................................................................527.1.3.4: Definir configuración de test...................................................................................537.1.3.5: Comprobar resultados.............................................................................................54

7.1.4: Especificación de requisitos...............................................................................547.2: Clases de análisis.......................................................................................................55

7.2.1: Lógica de negocio..............................................................................................557.2.2: Persistencia........................................................................................................55

8: Ciclo 1: Diseño...........................................................................................568.1: Estructura del sistema...............................................................................................56

8.1.1: Estructura lógica................................................................................................568.1.1.1: Introducción............................................................................................................568.1.1.2: Descomposición en capas........................................................................................56

8.1.2: Estructura física.................................................................................................57Directorio SquishScripts.......................................................................................................58

8.2: Diseño de clases........................................................................................................598.3: Representación de web de los resultados..................................................................618.4: Especificación de la pruebas.....................................................................................63

8.4.1: Clases de equivalencia.......................................................................................638.4.1.1: SquishServerLauncher............................................................................................638.4.1.2: SquishTestLauncher................................................................................................638.4.1.3: SourceCodeDownloader..........................................................................................64

8.4.2: Identificación de los casos de prueba................................................................648.4.2.1: SquishServerLauncher............................................................................................648.4.2.2: SquishTestLauncher................................................................................................658.4.2.3: SourceCodeDownloader..........................................................................................66

III

Índices

9: Ciclo 1: Construcción..................................................................................679.1: Tecnología empleada.................................................................................................679.2: Descripción Squish IDE.............................................................................................67

9.2.1: Introducción......................................................................................................679.2.2: Resumen de lo ya conocido...............................................................................679.2.3: Squish y Java.....................................................................................................68

9.3: Interfaces definitivas.................................................................................................689.4: Código relevante.......................................................................................................71

9.4.1: SquishTestLauncher.py.......................................................................................719.4.2: Seleccionar componentes para proyectos XBee.................................................739.4.3: Recogida de los problemas de compilación.......................................................789.4.4: Funciones auxiliares para la fiabilidad del test..................................................80

9.4.4.1: handleShell()...........................................................................................................819.4.4.2: clickMenuOptionWithRetry().................................................................................819.4.4.3: clickContextualMenuOptionWithRetry()................................................................82

9.5: Resultado de las pruebas...........................................................................................83

10: Ciclo2: Análisis.........................................................................................8410.1 Análisis de requisitos................................................................................................84

10.1.1: Introducción....................................................................................................8410.1.2: Casos de uso....................................................................................................8410.1.3: Especificación de requisitos.............................................................................85

10.2: Clases de análisis.....................................................................................................8610.2.1: Lógica de negocio............................................................................................8610.2.2: Persistencia......................................................................................................86

11: Ciclo 2: Diseño.........................................................................................8711.1: Estructura del sistema.............................................................................................8711.2: Diseño de clases......................................................................................................8711.3: Especificación de pruebas.......................................................................................88

12: Ciclo 2: Construcción................................................................................8912.1 Tecnología empleada................................................................................................8912.2: Interfaces definitivas...............................................................................................8912.3: Código relevante.....................................................................................................89

12.3.1: Clase XBeeProjectTerminal..............................................................................8912.3.1.1: Introducción..........................................................................................................8912.3.1.2: Codificación..........................................................................................................90

12.4: Resultados de los pruebas.......................................................................................92

IV

Índices

13: Ciclo 3: Análisis........................................................................................9313.1: Análisis de requisitos...............................................................................................93

13.1.1: Introducción....................................................................................................9313.1.2: Casos de uso....................................................................................................93

13.1.2.1: Lanzar máquina virtual..........................................................................................9413.1.3: Especificación de requisitos.............................................................................95

14: Ciclo 3: Diseño.........................................................................................9614.1: Estructura del sistema.............................................................................................96

14.1.1: Estructura lógica..............................................................................................9614.1.2: Estructura física...............................................................................................96

14.2: Especificación de las pruebas..................................................................................9714.2.1: Clases de equivalencia.....................................................................................9714.2.2: Identificación de los casos de prueba..............................................................98

15: Ciclo 3: Construcción..............................................................................10015.1: Tecnología empleada.............................................................................................10015.2: Descripción de VMWare........................................................................................100

15.2.1 Binding de la librería vix.dll............................................................................10015.4 Código relevante....................................................................................................10115.3: Resultado de las pruebas.......................................................................................101

16: Pruebas del sistema y aceptación............................................................102

17: Conclusiones..........................................................................................10317.1: Comparación entre objetivos y resultados obtenidos............................................10317.2 Visión personal.......................................................................................................104

19: Glosario de términos.............................................................................105

20: Bibliografía.............................................................................................106

ÍNDICE DE ILUSTRACIONES

Ilustración 1: Diagrama de descomposición de tareas general........................14




V

Índices

Ilustración 5: Diagrama de Gantt Visión General..........................................21

Ilustración 6: Diagrama de Gantt Tareas de gestión del proyecto.................21

Ilustración 7: Diagrama de Gantt Ciclo 1.....................................................22

Ilustración 8: Diagrama de Gantt Ciclo 2......................................................22

Ilustración 9: Diagrama de Gantt Ciclo 3 y documentación..........................23

Ilustración 10: Diagrama de Gantt Replanificación......................................25

Ilustración 11: Un módulo XBee.....................................................................27

Ilustración 12: Selección de tipo de proyecto XBee project.............................29

Ilustración 13: Asistente de creación de proyectos XBee.................................30

Ilustración 14: Barra de progreso de compilación de un proyecto..................31

Ilustración 15: Pantalla de configuración del run...........................................32

Ilustración 16: Diagrama de relaciones Perspectiva del producto.................35

Ilustración 17: Interfaz de Squish IDE............................................................40

Ilustración 18: Interfaz de Squish IDE – Test suite creado..............................41

Ilustración 19: Interfaz de Squish IDE Test case creado................................42

Ilustración 20: Interfaz de Squish IDE Código autogenerado.......................43

Ilustración 21: Esquema de ejecución de Squish IDE......................................44

Ilustración 22: Esquema de ejecución de Squish.............................................45

Ilustración 23: Esquema del problema con Squish..........................................46


Ilustración 25: Diagrama de casos de uso ciclo 1 Lanzar servidor.................50

Ilustración 26: Diagrama de casos de uso ciclo 1 Lanzar test.......................50

Ilustración 27: Diagrama de actividad lanzador de test..................................51

Ilustración 28: Diagrama de secuencia de test XBee project...........................52

Ilustración 29: Diagrama de casos de uso ciclo 1 – Descarga AUT..................53

VI

Índices

Ilustración 30: Diagrama de casos de uso ciclo 1 Definir configuración test.53

Ilustración 31: Diagrama de descomposición de capas lógicas.......................56

Ilustración 32: Árbol de directorios del sistema..............................................57

Ilustración 33: Diagrama de clases ciclo 1......................................................60

Ilustración 34: Esquema interfaz web de resultados.......................................61

Ilustración 35: Esquema interfaz web compilación.........................................62

Ilustración 36: Interfaz web de los resultados del test....................................69

Ilustración 37: Interfaz web de los resultados de la compilación....................70

Ilustración 38: Código SquishTestLauncher.py Función getConfig().............72

Ilustración 39: Código SquishTestLauncher.py Funciónes autList() y testList().........................................................................................................73

Ilustración 40: Añadir componente Componente único................................74

Ilustración 41: Añadir componente Pines insuficientes.................................75

Ilustración 42: Añadir componente Reasignar pines.....................................76

Ilustración 43: Código clase XBeeDefinedProjectCreator Método clickAddButton...............................................................................................77

Ilustración 44: Problemas de compilación......................................................78

Ilustración 45: Código de la clase XBeeProjectBuilder getProblems.............79

Ilustración 46: Ventana de Package Manager..................................................80

Ilustración 47: Código de handleShell............................................................81

Ilustración 48: Código de clickMenuOptionWithRetry....................................82

Ilustración 49: Código de clickContextualMenuOptionWithRetry...................82

Ilustración 50: Diagrama de secuencia del text XBee Samples........................85

Ilustración 51: Diagrama de clases del ciclo 2................................................87

Ilustración 52: Debugger................................................................................88

Ilustración 53: Ventana de Terminal Settings..................................................90

VII

Índices

Ilustración 54: Código de la clase XBeeProjectTerminal..................................91


Ilustración 56: Diagrama de casos de uso ciclo 3 Lanzar máquina virtual....94

Ilustración 57: Estructura física de los directorios Paquete final...................96

VIII

1:Introducción

1: INTRODUCCIÓN

1.1 TEMA TRATADO

Este proyecto surge como solución a la necesidad de la empresa Digi International de una herramienta de testeo para el desarrollo de sus aplicaciones. La solución a este problema es un sistema que permita ejecutar pruebas sobre las aplicaciones de forma automática y sin interacción por tarde del usuario, pudiendo configurar dichas pruebas, y que una vez terminadas se genere un registro de resultados.

Este sistema no solo pretende mejorar algo tan arduo y poco eficiente como hacer las pruebas manualmente, sino que además ayudará en la detección y la localización de errores, útiles en estrategias de pruebas como la integración continua y las pruebas de regresión, para las que principalmente está enfocado este sistema.

Adicionalmente, el sistema deberá ser integrado dentro de un sistema de virtualización que también funcione de forma automática.

1.2: MOTIVO DE LA ELECCIÓN

A finales de febrero del año 2011 comencé un periodo de practicas en la empresa Digi International en su oficina de Logroño. Como por entonces no tenía elegido ningún tema para mi proyecto fin de carrera, me ofrecieron la posibilidad de realizar el presente proyecto durante mis prácticas.

El proyecto me resultó interesante ya que podría conocer en un entorno real cómo se aborda el tema de las pruebas en el desarrollo de aplicaciones. Durante este tiempo la mayor parte de los conocimientos que he ido adquiriendo han sido sobre todo en campo del diseño y la implementación de software, y es por eso que me gustó la idea de conocer algo mejor el campo de las pruebas.

También me comentaron que lo más probable es que tendría que escribir mi código en Python, ya que es el lenguaje más utilizado por el departamento de pruebas. Python es un lenguaje del que había oído hablar mucho pero que no conocía y me llamaba la atención, así que con el proyecto tenía la escusa perfecta para poder aprenderlo.

Finalmente me comprometí a realizar el proyecto, presenté la propuesta en el departamento de la facultad y fue aceptada asignándome como director a Juan José Olarte.

1


2: DOCUMENTO DE OBJETIVOS DEL PROYECTO

2.1: OBJETIVOS

El objetivo del proyecto es la elaboración de un sistema formado por varias herramientas que permita realizar pruebas software sobre las aplicaciones creadas por Digi International. Aún estado centrado este proyecto en una aplicación concreta se asentarán las bases del diseño del sistema para ofrecer robustez al mismo y ayudar a la futura implantación de otras aplicaciones.

Sobre la aplicación bajo prueba hace falta decir que deberá conocerse su funcionamiento a nivel de usuario, para poder ser capaz de saber cuales son sus particularidades y poder así diseñar los test a partir de ellas.

Una vez realizados los estudios previos sobre el manejo de la aplicación bajo prueba y sobre las tecnologías a utilizar, se diseñarán los test acorde a las partes de la aplicación que quieran ser probadas. Concretamente, para la aplicación en la que se centra este proyecto, CodeWarrior + plugin XBee SDK (explicada más adelante en el punto 4.3) , se diseñarán dos tipos de test:

• XBee Project: Destinado a las pruebas para los proyectos creados en la aplicación.

• XBee Sample: Destinado a las pruebas para las muestras se incluyen en la aplicación.

Ambos test poseerán parámetros configurables por medios de ficheros de configuración con los que se podrá dotar a los test de mayor flexibilidad y reutilización que si fuera diseñado un test para cada caso concreto.

Para cada test que sea realizado se recogerá información y con ella se generará un registro de resultados. De esta forma será posible utilizar conceptos como la integración continua mediante la automatización de pruebas diarias y también las pruebas de regresión a través de los resultados de los test.

Adicionalmente se ofrecerá la opción de poder lanzar de forma automática todo el sistema dentro de una maquina virtual, para así poder realizar pruebas diferentes en la misma maquina y en el futuro poder gestionar las máquinas virtuales por medio de una aplicación web.

2.2: ALCANCE

La finalidad de proyecto es crear el sistema de automatización para las pruebas de las aplicaciones. Sin embargo, el número de aplicaciones desarrolladas es lo suficientemente grande como para generar un proyecto mucho mas extenso. Por ese motivo el proyecto

2


estará únicamente enfocado en la aplicación CodeWarrior + XBee SDK.

Teniendo definido el contexto sobre el que se va a trabajar, el sistema deberá cumplir una serie de requisitos para considerar que el proyecto ha sido llevado correctamente a buen puerto.

2.2.1: REQUISITOS

A continuación se muestran los puntos mínimos fijados para la realización final del proyecto:






2.2.2: ESPECIFICACIONES ADICIONALES

Debido a la limitación de tiempo y extensión, o bien por desviarse en mayor o menor medida del tema del proyecto, se han descartado las siguientes ampliaciones:




3


2.3: PARTICIPANTES DEL PROYECTO

Al ser realizado el proyecto dentro del marco empresarial, existen varias las personas que participan en él. Debido a esto, y por mantener un orden, se puede dividir a los participantes en dos entornos diferentes: el entorno académico y el entorno de la empresa.

En el caso académico, por parte de la Universidad de la Rioja, se hallan:

• Carlos Daniel Serres Martínez, alumno y desarrollador del proyecto.

• Juan José Olarte, profesor del departamento de Matemáticas y Computación, con función de director de proyecto.

En el entorno de la empresa, por parte de Digi Internacional, se hallan:

• Pedro Pérez, Jefe de proyectos de la oficina de Digi en Logroño.

• Carlos Marín, Ingeniero del departamento de pruebas y director del proyecto dentro de la empresa.

Durante la realización del proyecto el alumno adoptará el rol de un trabajador dentro de la empresa, pero al estar el proyecto destinado a la creación de una herramienta de uso privado para los desarrollos de la empresa, se puede enfocar al relación en una relación desarrollador-cliente.

2.4: COMUNICACIÓN

La principal vía de comunicación será el correo electrónico, pero también se organizarán reuniones personales, ambas tanto entre el entorno académico, como con el entorno empresarial.

Sin embargo conviene reseñar, que el puesto de trabajo asignado para el alumno dentro de la empresa se encuentra junto al director del proyecto, de forma que la comunicación será fluida y constante durante el proceso de desarrollo. Además de tener reuniones semanales sobre el seguimiento del desarrollo.

2.5: METODOLOGÍA

La metodología elegida en este proyecto será la denominada Proceso Unificado, definida por Jacobson, Booch y Rumbaugh. Esta metodología se caracteriza por estar dirigida por casos de uso, centrada en la arquitectura y por ser iterativa e incremental. El uso que se dará a esta metodología no será el de un seguimiento estricto, sino que se utilizarán y adaptarán características de la misma según las necesidades del proyecto.

4


Principalmente, se utilizará un ciclo de vida iterativo e incremental para el desarrollo del proyecto, de forma que pueda obtenerse en la primera fase un producto funcional que se vaya ampliando en las sucesivas fases con el resto de especificaciones.

Otras de las razones de la elección de esta metodología es que utiliza UML, como lenguaje de modelado de sistemas software, el cual es casi considerado un estándar y es interesante su uso en este proyecto por disponer un amplio abanico de diagramas útiles para su organización.

Gracias al uso esta metodología se pretende dotar a este proyecto de la robustez necesaria y así minimizar los riesgos.

2.6: TECNOLOGÍAS

En el caso de este proyecto, la elección de las tecnologías no es decidida hasta no haber sido terminado el estudio previo sobre las herramientas disponibles en el mercado. Aun así, a modo de anticipo, se resumirán en esta sección cuales son las tecnologías utilizadas.

Esta es la lista de los lenguajes utilizados:

• Python: Es el lenguaje de programación utilizado para la implementación de este proyecto. Se puede decir a modo de introducción que su filosofía hace hincapié en una sintaxis muy limpia y que favorezca un código legible, soporta orientación a objetos y programación imperativa, y es un lenguaje interpretado con tipado dinámico, fuertemente tipado y multiplataforma. En la empresa Digi International es el lenguaje utilizado por el departamento de pruebas.

• HTML: Es el lenguaje utilizado a la hora de presentar los resultados de los test de forma legible. Su nombre significa HyperText Markup Language y es el lenguaje utilizado para representar el contenido en la web. Se utiliza concretamente en este proyecto para transformar los archivos xml en formato web. De forma anecdótica dentro de HTML también se llega a utilizar Javascript, pero no lo añadiré como tecnología por su uso puntual.

• XML: Al igual que HTML es otro lenguaje de marcado ya que provienen los dos de SGML. Su nombre significa eXtensible Markup Language y es utilizado principalmente en el intercambio de información. Para este proyecto se utiliza en la lectura o parseo de documentos xml.

A continuación ésta es la lista de las herramientas y otras tecnologías utilizadas:

• Squish: Ésta es la herramienta principal encargada de la automatización de las pruebas software. Es un producto desarrollado por la empresa Froglogic y concretamente se utiliza para el proyecto su versión v4.1 para entornos en Java. Soporta varios lenguajes para escribir su código, pero en este caso se utiliza Python. Más adelante, en el estudio previo se describe la estructura y el uso de

5


esta herramienta.

• Interprete de Python: Es el interprete del código de Python, la versión utilizada es v2.7.1.

• Interprete de Java: El interprete de Java utilizado por la herramienta a probar. Lo añado en esta sección ya que es necesario indicarlo en el proceso de instalación de Squish. La versión utilizada es el JRE7.

• Cliente GIT: Cliente para uso del servidor de gestión de versiones GIT. GIT es el sistema de gestión de versiones utilizado en Digi y en el proyecto es necesario para descargar el software que se va a probar, pudiendo seleccionar la versión deseada. Su versión es la v1.7.4.

• VMWare Workstation 7: Herramienta para la gestión de máquinas virtuales. Se utiliza para lanzar las pruebas software mediante virtualización. Para conseguir un comportamiento automático de dicha aplicación se utiliza la librería VIX, la cual permite arrancar las maquinas virtuales y trasladarles comandos de consola una vez arrancadas.

2.7: IDENTIFICACIÓN DE RIESGOS Y PLANES DE ACCIÓN

Para evitar que el tiempo de desarrollo del proyecto se resienta por imprevistos, se tratará de identificar los posibles problemas que puedan surgir durante el mismo. Además de los riesgos se propondrá también planes de acción para estos casos.

2.7.1: POSIBLES RIESGOS

Esta es la lista de los riesgos identificados que pueden ocurrir durante el desarrollo del proyecto:

1. En el caso de este proyecto está claro que existe riesgo por el desconocimiento previo de alguna herramienta, puesto que ya se sabe de antemano que una herramienta para la automatización de pruebas deberá ser elegida sin tener experiencia en su manejo. Esto podría desencadenar una detección tardía de la inviabilidad del proyecto.

2. Los Factores de índole personal de todos los participantes de proyecto, pero principalmente en el caso del alumno, que tiene el peso del desarrollo. Pueden ser enfermedades u otros impedimentos imprevisibles.

3. Error en la estimación de fechas tienen una alta probabilidad de ocurrir debido a la falta de experiencia del alumno, ya sea por exceso o por defecto del tiempo asignado para las tareas.

4. Al tener que usar un ordenador, el desarrollo puede verse afectado por problemas

6


de hardware y software.

5. Una vez terminado el desarrollo puede ocurrir que el producto final no sea del agrado alguno de los participantes, especialmente en el caso del cliente.

2.7.2: PLANES DE ACCIÓN

Estos son los planes de actuación en el caso de los anteriores riesgos:

1. Para evitar la detección tardía de la inviabilidad del proyecto, se efectuará un estudio previo en el que uno de sus puntos de estudio deberá centrarse en el conocimiento de las aplicaciones utilizadas. De esta forma, se conseguirá conocer las limitaciones de las aplicaciones, su forma de manejarlas y si fuera necesario encontrar alguna solución pertinente. Así se evitaría tener que aprender sobre la marcha o llegar a una situación en la que continuar sea imposible .

2. En el caso de los factores de índole personal dependiendo de su naturaleza y gravedad se verá afectado irremediablemente en mayor o menor medida. Seguirá con la planificación del proyecto en el momento que sea posible haciendo constar en la documentación el motivo del retraso y se replanificarán las tareas si fuera necesario.

3. Si se produjera un error en la estimación de tiempos, se documentará el error y se replanificarán las tareas como sea conveniente.

4. Durante el desarrollo de este proyecto el alumno dispondrá un equipo en el puesto de trabajo dentro de la empresa y también de su ordenador portátil para el trabajo que pueda ser realizado desde casa. Para evitar que problemas de hardware y software puedan desencadenar la pérdida de todo el trabajo se guardarán copias del mismo. Las copias se guardarán en una memoria USB, en un equipo de red dentro de la empresa destinado a este propósito y también mediante la cuenta de Dropbox del alumno.

5. La comunicación entre el alumno y su director de proyecto en la empresa será continua, ya que sus puestos de trabajo se encuentran juntos. De esta forma es posible llevar un seguimiento muy actualizado del estado del proyecto y por consiguiente se evitará que no sea del agrado del cliente.

2.8: ENTREGABLES

Tras la finalización del proyecto deberá haberse generado como resultado un paquete que contenga una serie de elementos. El nombre elegido por el cliente para este paquete será “GuiAutomation” y su contenido el siguiente:

• Directorio “Documents”: En el se incluirá la documentación necesaria sobre el manejo y la instalación del sistema.

7


• Directorio “extras”: Contendrá los instaladores de las herramientas necesarias.

• Directorio “squish-4.1”: Paquete de la herramienta Squish, herramienta usada para la automatización.

• Directorio “SquishScripts”: Contendrá todo el código creado para ser ejecutado por Squish, tanto los test como las clases creadas. El interior de este directorio estará diseñado y organizado con la idea de añadir nuevos scripts para otras aplicaciones.

• Directorio “VIX”: Directorio necesario para el manejo automático de la herramienta de maquinas virtuales VMWare Workstation. Contendrá la librería capaz de hacer esto además de su ejecutable.

• Fichero “SourceCodeDownloader”: Script Python para bajar la versión de la aplicación bajo prueba desde el servidor del administrador de versiones GIT. Dispondrá de parámetros configurables en su ejecución.

• Fichero “SquishServerLauncher”: Script Python para iniciar el servidor de Squish y que permanezca a la escucha de petición de tests. Dispondrá de parámetros configurables en su ejecución.

• Fichero “SquishTestLauncher”: Script Python para enviar al servidor de Squish la orden de iniciar el test. Dispondrá de parámetros configurables en su ejecución.

• Fichero “xml2result2html”: Script Python con la finalidad de transformar los resúmenes de los test de formato xml a formato html.

Además, así como con el paquete anterior, el presente documento también formará parte de los entregables de este proyecto.

2.9: DESCOMPOSICIÓN DE TAREAS

El proyecto se ha dividido en una serie de tareas que nos ayudarán en la organización y en la estimación del tiempo del mismo.

A continuación se muestran las tareas con una breve descripción y sus subtareas.

TAREA 1: SEGUIMIENTO DEL PROYECTO

Esta tarea abarcará toda la duración total de la vida del proyecto, en la que se efectuarán controles en diversos momentos del ciclo de vida.

1.1. Reuniones: Contempla en tiempo consumido en las reuniones realizadas sobre el proyecto.

8


1.2. Revisiones: Son las comprobaciones periódicas para asegurar que el proyecto va por buen camino y cumple los objetivos de la planificación, y en caso de necesitarse hacer las rectificaciones adecuadas.

TAREA 2: GESTIÓN DEL PROYECTO

Esta tarea abarca las labores de documentación y las específicas que afectan al proyecto fin de carrera como asignatura y no como proyecto de sistema de información.

2.1. Generación del DOP: Creación del presente documento de los objetivos de proyecto.

2.1.1. Estudio previo: Obtener información sobre dirección de proyectos.

2.1.2. Descomposición de tareas: Descomponer el proyecto en tareas. Generar el diagrama de descomposición de tareas.

2.1.3. Asignar tiempo a tareas: Estimar el tiempo que se dedicará a cada duna de las tareas.

2.1.4. Diagrama Grantt: Crear el diagrama de Gantt.

2.1.5. Documentación: Documentar textualmente las tareas identificadas.

2.1.6. Revisión: Revisar la documentación generada en esta tarea.

2.2. Generación de la memoria.

2.2.1. Estudio previo: Estudiar documentación de proyectos de años anteriores y otra información proporcionada por el departamento sobre proyectos fin de carrera.

2.2.2. Creación de la memoria: Creación del documento de la memoria del proyecto. La duración de esta tarea se extiende durante toda la vida del proyecto, puesto que la memoria se irá actualizando tras la finalización de tareas.

2.2.3. Revisión del documento: Revisar la documentación generada en esta tarea

2.3. Defensa del Proyecto.

2.3.1. Preparación: Preparación de la presentación del proyecto ante el tribunal.

2.3.2. Defensa: Defensa del proyecto ante el tribunal.

9


TAREA 3: ESTUDIO PREVIO

Mediante esta tarea se conocerá el escenario en el que se desarrollara el proyecto y sus antecedentes, además se presentarán las aplicaciones y herramientas que serán utilizadas. En el caso de la herramienta para la automatización se realizara un estudio entre varias alternativas, en el que se realizara una comparativa y una posterior elección.

3.1. Estudio del escenario.

3.1.1. Estudio de la empresa: Se estudiará la empresa Digi International en la que se realizará el proyecto para conocer información sobre ella y sus antecedentes al proyecto.

3.1.2. Estudio de las herramientas: Se estudiarán las aplicaciones y herramientas implicadas en el proyecto creadas y utilizadas por las empresa.

3.1.3. Estudio de alternativas en automatización de pruebas: Se buscarán y compararán herramientas para la automatización de pruebas.

3.2. Establecer los límites del sistema a desarrollar junto con el personal de la empresa.

3.3. Estudiar la viabilidad del proyecto junto con el personal de la empresa.

TAREA 4: ESPECIFICACIÓN DE REQUISITOS

Consiste en el proceso en el cual tras el análisis previo se extraen los requisitos fundamentales que debe poseer el sistema.

4.1. Crear documento de especificación de requisitos: Antes de comenzar con las iteraciones definiremos los requisitos que debe cumplir la plataforma globalmente. Se numerarán y describirán adecuadamente para poder ir identificándolos a medida que se vayan satisfaciendo a lo largo de cada una de las iteraciones.

TAREA 5: FORMACIÓN Y APRENDIZAJE

En esta tarea se buscarán por parte del alumno los conocimientos necesarios para la elaboración del proyecto.

5.1. Aprendizaje en la aplicación bajo prueba: Conocer la aplicación Codewarrior + plugin XBee SDK, para posteriormente crear los test que correrán sobre ella.

5.2. Aprendizaje en la aplicación de automatización de pruebas: Conocer el funcionamiento del entorno de desarrollo para Squish.

10


5.2.1. Documentar funcionamiento y estructura de Squish.

5.3. Aprendizaje en lenguaje de programación Python: Aprender este lenguaje de programación será necesario para la codificación de los ejecutables y los test.

TAREA 6: CICLO 1 - BASE DEL SISTEMA Y TEST PARA XBEE PROJECT

Esta tarea corresponde con la primera iteración del proyecto. Una vez haya sido finalizada habrá sido creada toda la estructura básica del sistema y el test XBee proyect el cual podrá ser utilizado partir de este momento.

6.1. Análisis.






6.1.1.5. Revisión.




6.2. Diseño.

6.2.1. Diseño de la estructura del sistema.

6.2.2. Diseño de las clases.

6.2.3. Diseño de la representación web de los resultados.

6.3. Construcción.

6.3.1. Crear los scripts para usar Squish y Git.

6.3.2. Implementar el código para Squish.



11


6.3.2.3. Crear los ficheros de configuración.

6.3.2.4. Crear librería de funciones adicionales.

6.3.3. Crear el script para transformar a formato web los resultados.

6.3.4. Documentar código.

6.4. Pruebas.



TAREA 7: CICLO 2 - TEST PARA XBEE SAMPLE

En esta tarea se ampliará el sistema añadiéndole el test XBee sample. Esta tarea se apoyará en la estructura creada anteriormente.

7.1. Análisis.




7.1.1.3. Crear diagrama de actividad


7.1.1.5. Revisión.




7.2. Diseño.

7.2.1. Diseño de clases.

7.3. Construcción.

7.3.1. Implementar código para Squish.



12


7.4. Pruebas.



TAREA 8: CICLO 3 - VIRTUALIZACIÓN DEL SISTEMA

La finalidad de esta tarea será la de incluir todo el sistema dentro de una máquina virtual, de forma que pueda ser luego lanzado mediante algún comando y que realice los test que se le pida de forma automática. Para el caso de esta tarea los límites de sus fases son bastante difusos y es por eso que se seguirá una estructura diferente a las tareas anteriores, siendo la de este caso mucho mas simple.

8.1. Análisis.






8.1.1.5. Revisión.

8.2. Construcción.

8.2.1. Implementación del script lanzador de VMWare.

8.2.2. Implementación del binding de Python para la librería vix.dll.

8.3. Pruebas.

8.3.1. Pruebas unitarias del sistema.


TAREA 9: DOCUMENTACIÓN

Esta tarea se centrará en la elaboración de la documentación para el manejo del sistema, además de la pertinente documentación dentro del código generado.

9.1. Manual de instalación y uso del sistema.

13


14

Ilustración 1: Diagrama de descomposición de tareas general.


15



16




2.10: ESTIMACIÓN TEMPORAL

2.10.1: CALENDARIO DE TRABAJO

Ya que este proyecto se desarrolla durante el periodo de prácticas en la empresa Digi, se dispone de mucho tipo entre semana para el desarrollo del mismo. Por otro lado, al ser utilizadas herramientas y recursos que solo son accesibles desde la empresa, será imposible aprovechar los fines de semana.

2.10.2: ESTIMACIÓN DEL TIEMPO DE LAS TAREAS

En la siguiente tabla se muestra la estimación de horas para cada una de las tareas:

Nombre Duración en horas

Seguimiento del proyecto 14

Reuniones 6

Revisiones 8

Gestión del proyecto 66

Generación del DOP 25

Estudio previo 4

Descomposición de tareas 4

Asignar tiempo a tareas 4

Diagrama Grantt 2

Documentación 10

Revisión 1

Generación de la memoria 72

Estudio previo 8

Creación de la memoria 60

Revisión 4

Defensa del proyecto 13

Preparación 12

Defensa 1

Estudio previo 43

Estudio del escenario 37

Estudio de la empresa 8

17


Estudio de las herramientas 17

Estudio de las alternativas 12

Establecer los límites 3

Estudiar viabilidad 3

Especificación de requisitos 8

Creación del documento 8

Formación y aprendizaje 197

Aplicación bajo prueba 43

Aplicación de automatización 68

Documentación 4

Python 62

Ciclo 1 155

Análisis 7

Casos de uso 5





Revisión 1




Diseño 8


Clases 3

Interfaz de representación de resultados 1

Construcción 15

Crear script para Squish 27





Crear librería de funciones adicionales 5

18


Crear el script de los resultados web 2

Pruebas 26



Ciclo 2 100

Análisis 8

Casos de uso 6





Revisión 2




Diseño 4

Clases 4

Construcción 62





Pruebas 26



Ciclo 3 42

Análisis 5

Casos de uso 5





Revisión 1

19


Diseño 2


Construcción 9

Crear lanzador de VMWare 6

Modificar bindeo de vix.dll para Python 3

Pruebas 26



Documentación 5

Manual de instalación y uso 5

Total de hora del proyecto 626

20


2.10.3: DIAGRAMA DE GANTT

A continuación: se muestra las diferentes partes del diagrama de Gantt de las tareas del proyecto.

21

Ilustración 5: Diagrama de Gantt - Visión General.

Ilustración 6: Diagrama de Gantt - Tareas de gestión del proyecto.


22




23

Ilustración 9: Diagrama de Gantt - Ciclo 3 y documentación.


3: GESTIÓN DEL PROYECTO

3.1: REPLANIFICACIÓN


Durante el desarrollo del proyecto, han surgido una serie de imprevistos que han afectado a la planificación. Esto ha afectado para cumplir con los plazos que fueron asignados para algunas de las tareas.

A raíz de esto, se efectúa una replanificación de las tareas el día 15 de agosto.

3.1.2: FACTORES DE RETRASO

Los factores por los que se ve obligado el proyecto a una replanificación son los siguiente:

• Se libera una nueva versión del la aplicación bajo prueba. En esta versión cambia algunos aspectos de la interfaz gráfica son cambiados considerablemente. Esto ocasiona tener que actualizar el código de los test, además de aumentar la complejidad de los mismos.

• Se libera una nueva versión de Squish. Se decide utilizar esta nueva versión desde ese momento en adelante, pero posteriormente se descubre un error que no sucedía con la versión anterior. Tras esto, se le comunica a la atención al cliente de de Squish la existencia de este fallo. Después de algunos correos el error es localizado y posteriormente solucionado.

• Problemas en el desarrollo por la falta de experiencia en las herramientas.

También se puede considerar, no como factor de retraso, que la planificación de las tareas era bastante optimista. Ya que, a pesar de los problemas anteriores, se podía intuir a mitad del desarrollo que sería complicado cumplir con las fechas.

24