Informe Practica Profesional

CC59A

Blue Company S.A.

Autor: Gaston Jorquera Ahumada

Carrera: Ingenierıa Civil en Computacion

Matrıcula: 24002302

E-Mail: gjorquer@dcc.uchile.cl

Fecha: 29 de Agosto de 2008

Evaluacion por Parte de la Empresa

Datos

Empresa Blue Company S.A.

Nombre del supervisor Emilio Davis Mendez

Telefono del supervisor 2448900

Firma del supervisor

Fecha de inicio 3 de Diciembre de 2007

Fecha de termino 2 de Enero de 2008

Evaluacion1

Satisfaccion con el trabajo realizado 7,0

Calidad tecnica 7,0

Iniciativa e interes 7,0

Responsabilidad 7,0

Trato personal y capacidad de adaptacion 7,0

1Nota de 1,0 a 7,0.

i

Observaciones

ii

Indice

1. Resumen 1

2. Introduccion 2

2.1. Lugar de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2. Grupo de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3. Equipo y Software Utilizado . . . . . . . . . . . . . . . . . . . 3

2.4. Situacion Previa . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.5. Descripcion General del Trabajo Realizado . . . . . . . . . . . 4

3. Trabajo Realizado 6

3.1. Bligoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1. Caracterısticas . . . . . . . . . . . . . . . . . . . . . . 6

3.1.2. Bugs y Errores de Traduccion . . . . . . . . . . . . . . 8

3.2. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.1. Tipos de Pruebas . . . . . . . . . . . . . . . . . . . . . 9

3.3. Integracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.1. Sistema Servidor Local . . . . . . . . . . . . . . . . . . 13

3.3.2. Sistema Browser . . . . . . . . . . . . . . . . . . . . . 17

4. Conclusion 18

iii

1. Resumen

El presente informe detalla el trabajo realizado en la Practica Profesional

II, llevada a cabo en Blue Company S.A. Se trabajo con Bligoo2, una red

social orientada a construir relaciones entre personas con los mismos intereses

o visiones.

En un principio el trabajo consistio principalmente en aprender a utilizar

la plataforma social junto con buscar bugs3 y revisar la traduccion al Ingles.

Luego, la tarea a realizar fue investigar y analizar distintas plataformas

de testeo de codigo abierto que podrıan ser utilizadas para revisar Bligoo.

Finalmente, se integraron las plataformas seleccionadas en un unico sis-

tema facil de utilizar.

Como conclusion se puede decir que el area de testeo esta bastante inma-

duro, en donde las herramientas no son las mejores, debido a que son bastante

especıficas, no existe mucha documentacion, y son difıciles de integrar y de

utilizar.

Junto con esto, tambien cabe destacar que los sistemas desarrollados no

son faciles de testear ya que, normalmente, no se programa orientado al testeo

y no se acostumbra a ir escribiendo pruebas de forma seguida, incremental

ni consistente.

2http://www.bligoo.com/3Defectos en la plataforma.

1

2. Introduccion

2.1. Lugar de Trabajo

Todo el transcurso de la practica profesional fue realizada en la oficina de

Blue Company S.A., ubicada en Encomenderos oficina 11, en la comuna de

Las Condes, ciudad de Santiago.

Blue Company S.A. es una empresa dedicada a la consultorıa y desarrollo

de aplicaciones Web 2.0. Se ha enfocado en el diseno y creacion de tecnologıas

que faciliten la comunicacion, coordinacion y colaboracion entre las personas.

Bligoo, el principal producto de Blue Company S.A., es un sistema social

de sitios que ayuda no solo a publicar o leer contenidos, sino que a construir

relaciones entre personas con los mismos intereses o las mismas visiones.

Blue Company S.A. ha crecido bastante a lo largo de sus anos de vida.

Actualmente, la red social Bligoo (con menos de 1 ano desde el lanzamiento

de la version Beta) fue nominada en el Top 250 de los negocios prometedo-

res, en la categorıa de Consumers and Entertainment, segun la publicacion

AlwaysOn4 de la Universidad de Stanford.

4http://alwayson.goingon.com/permalink/post/26452

2

2.2. Grupo de Trabajo

Blue Company S.A. no posee un area de Quality Assurance5 ni de Testing6

pero estan muy conscientes sobre la importancia de aplicar estas tecnicas

en el desarrollo de software. Es por esto que, en el perıodo en el que fue

realizada la practica profesional, Blue Company S.A. contaba con Nicolas

Fernandez, Memorista de la Universidad Tecnica Federico Santa Marıa, que

trabajaba bajo la tutela de Alejandro Vera, Arquitector Senior de Sistemas,

para investigar, analizar y desarrollar una plataforma de testing y disenar las

diferentes pruebas para someter a Bligoo.

Por lo tanto, la practica profesional fue realizada en conjunto con Nicolas

Fernandez y Alejandro Vera, y ademas fue supervisada por Emilio Davis,

Gerente de Tecnologıa, y Paolo Colonello, Director.

2.3. Equipo y Software Utilizado

Todo el desarrollo de la practica profesional se hizo con un desktops de

desarrollo, cuya arquitectura es x86, se utilizo el servidor en donde corre la

plataforma Bligoo7 y un servidor local8 que tiene una replica de la aplicacion.

Como ya fue mencionado anteriormente, el trabajo giro completamente

en torno a la plataforma Bligoo, siendo este el principal software utilizado.

5Procesos planeados y sistematicos para asegurar la efectividad de un producto o ser-vicio.

6Proceso de checkeo de un software, que verifica que este satisface los requerimientosy detecta errores.

7http://www.bligoo.com/8http://www.bligoo.net/, accesable solo desde la intranet.

3

Para las herramientas de testing, se escogio trabajar con plataformas que

corran sobre Java, ya que se deseaba que estas corrieran en el servidor local

que ya soporta Java, o con plataformas que funcionen en navegadores de

internet. De esta forma no era necesario tener que instalar, configurar ni

administrar otros ambientes de desarrollo.

2.4. Situacion Previa

La plataforma social Bligoo no contaba con un sistema de testeo esta-

blecido, esto es debido a dos razones; Blue Company S.A. no cuenta con un

area de QA ni de Testing, y Bligoo no fue desarrollado orientado al Testing,

entonces no existıa ningun tipo de prueba que revisara el funcionamiento de

este.

2.5. Descripcion General del Trabajo Realizado

Al comienzo de la practica, el trabajo consistio en aprender a utilizar la

plataforma Bligoo para ası saber y entender, a grandes rasgos, como funciona

y que tipo de cosas se pueden realizar. Basicamente, para poder tener una

“imagen” del sistema a gran escala. Junto con aprender a utilizar la red social

se buscaron bugs y errores de traduccion al Ingles, ya que la version Beta de

Bligoo habıa sido lanzada recientemente9.

A continuacion, se investigaron y analizaron distintas plataformas de tes-

teo de codigo abierto que podrıan ser utilizadas en la validacion de Bligoo.

9Jueves 22 de Noviembre de 2007

4

Se buscaron herramientas para realizar pruebas unitarias, de integracion, de

regresion, de interfaz grafica y de carga. Esta investigacion se realizo utilizan-

do, principalmente, el sitio web Open Source Software Testing Tools10 como

fuente de informacion.

Por ultimo, se integraron las diversas plataformas seleccionadas en un

unico sistema facil de utilizar. Este sistema esta basado en una Wiki, de tal

forma que las distintas pruebas pueden ser facilmente agregadas definiendolas

con comandos especiales al editar las distintas paginas. Ademas, el sistema es

suficientemente poderoso como para definir conjuntos de pruebas que pueden

ser ejecutadas a la vez o por separado. Dentro de la Wiki se implementaron

las pruebas unitarias, de integracion, de regresion y de carga, mientras que

las pruebas de interfaz grafica se realizan mediante extensiones instalables a

Mozilla Firefox.

10http://www.opensourcetesting.org/

5

3. Trabajo Realizado

Como ya fue mencionado anteriormente, todo el trabajo se realizo en

torno a Bligoo, por lo tanto, a continuacion se explicara con un mayor nivel

de detalle la plataforma.

3.1. Bligoo

Bligoo es un sistema social de blogs que ayuda no solo a publicar o leer

contenidos, sino que a construir relaciones entre personas que tengan los

mismos intereses o las mismas visiones.

Actualmente, crear un blog es facil, pero que otros lo descubran y lo lean

no lo es tanto. En este sentido, Bligoo tiene como principal desafıo lograr que

otros lean lo que se escribe. Esto se logra recomendandole, a los usuarios,

artculos en base a las etiquetas usadas, por lo tanto, las distintas personas

podran saber que se escribio sobre algo que a ellos les interesa.

3.1.1. Caracterısticas

Facilidad de Uso Bligoo no es distinto a las otras plataformas para man-

tener blogs si se solo se visitan blogs de otras personas, se contestan

encuestas o se escriben comentarios, por lo tanto, no introduce una ba-

rrera en este aspecto. Pero, para la administracion de un blog propio,

Bligoo cuenta con poderosas funciones que son utilizadas de manera

intuitiva, en particular, el diseno visual se realiza mediante el mouse

6

arrastrando y soltando cajas de contenido en distintas partes posibles.

Navegacion Social Bligoo cuenta con un conjunto de funciones que per-

miten a las personas descubrir blogs a partir de otros, formando co-

munidades de blogs que se potencian entre sı. Ademas, Bligoo realiza

recomendaciones de artıculos interesantes en base a lo que la gente es-

cribe, lee y recomienda. Tambien, si es que uno no desea mantener su

propio blog, Bligoo permite encontrar blogs, artıculos y personas que

son de importancia para este usuario en particular.

Privacidad Bligoo permite definir grupos de contactos con distintos privile-

gios en un blog, por ejemplo, limitar la lectura o escritura de comenta-

rios a ciertos tipos de personas, manteniendo ası el nivel de privacidad

que el usuario desee. Ademas, Bligoo implementa un sistema de men-

sajerıa interno para poder tener conversaciones mas privadas.

Comunidades Bligoo permite definir comunidades dentro de la plataforma,

para que puedan realizar todo tipo de actividades y ası concentrar la

participacion. Ademas pueden habilitar el sistema de registro, para que

solo personas aceptadas puedan ingresar.

Estadısticas Bligoo permite ver una serie de indicadores de las visitas que

pasan por un blog creado por un usuario. No solo muestra la cantidad de

visitas sino que ademas muestra un resumen de los perfiles, por ejemplo,

muestra histogramas con las edades, sexo, etc., junto con mostrar que

artıculos son los mas leıdos, etc.

7

Blog Con respecto a los blogs, Bligoo permite publicar posts, agregar image-

nes, videos, comentarios y encuestas.

3.1.2. Bugs y Errores de Traduccion

Luego de la creacion de un blog, y de la investigacion sobre como fun-

ciona, se encontraron errores de traduccion en las siguientes secciones de la

plataforma:

En la pagina inicial (home).

En la pagina de registro.

En el mail de activacion.

En la pagina de administracion de un blog.

En la pagina de importacion de informacion desde WordPress.

En la pagina de servicio DNS para un blog.

En la pagina de servicios.

En la pagina de estadısticas.

En la pagina de grupos de usuarios.

En la pagina de administracion de comentarios.

En la pagina de invitacion a otras personas.

8

En la pagina del perfil de un usuario.

Tambien, varios tıtulos de las paginas estaban mal, o bien decıan “Bien-

venido a Bligoo” en alguna pagina distinta de la inicial, o contenıan tags

HTML11.

Ademas, se encontro solo un bug en la plataforma. Este era un proble-

ma cuando una persona tenıa solo un blog, en donde el sistema escribıa un

mensaje de informacion como si tuviera mas de uno.

3.2. Testing

La segunda parte del trabajo consistio en investigar diversas plataformas

de testing que existen para una cierta cantidad de tipos de pruebas.

A continuacion se detallan los tipos de prueba requeridos y las plataformas

investigadas.

3.2.1. Tipos de Pruebas

Existen muchos tipos de pruebas, aunque varios de ellos son iguales solo

que se aplican en situaciones distintas. Las pruebas solicitadas para testear

la plataforma son las siguientes:

Pruebas Unitarias Es una forma de probar el correcto funcionamiento de

un modulo de codigo del programa. Se utiliza para asegurarse de que el nivel

11En particular el tag span

9

mas bajo de la plataforma funciona de forma correcta, es decir, los compo-

nentes indivisibles del programa funcionan por separado como se espera.

La idea es escribir casos de prueba por cada funcion o metodo no trivial

de forma que cada caso sea independiente del resto.

Debido a que existen muchas plataformas para pruebas unitarias para

Java, se decidio analizar las dos mas importantes.

Cactus12 es un proyecto de Jakarta13 para realizar pruebas unitarias en

el lado del servidor (Servlets, EJBs, Tag Libs, Filters, etc). La idea es poder

crear nuevas pruebas de una forma simple y facil. Esta basado y extiende

JUnit.

JUnit14 es un framework, mantenido por Object Mentor, para escribir

y ejecutar pruebas automatizadas. Este framework es altamente utilizado

(posiblemente uno de los primeros frameworks de testing unitarios que se

escribio) y muchos otros proyectos han derivado de este.

Si bien estos frameworks son bastante buenos, exigen que las pruebas sean

programadas en clases para luego ser ejecutadas por lınea de comandos. Para

poder implementar el sistema solicitado se tendrıa que programar una interfaz

grafica para poder escribir y ejecutar las pruebas sin tener que programar ni

compilar codigo.

12http://jakarta.apache.org/cactus/index.html13Ofrecen diversas soluciones Java codigo libre14http://www.junit.org/

10

Pruebas de Integracion Se refieren a las pruebas de todos los elementos

unitarios que componen un proceso, realizadas de una sola vez. De esta forma

se revisa que el proceso funciona correctamente de forma integral.

FitNesse15 es un servidor web, una wiki y una herramienta de testing,

basado en FIT (Framework for Integrated Test). FitNesse, mas que una pla-

taforma para pruebas de integracion, es una herramienta muy completa pa-

ra realizar diversos tipos de pruebas, principalmente pruebas de aceptacion

(tambien llamadas pruebas funcionales o de caja negra), pero igual se pueden

crear pruebas unitarias y de integracion.

La principal caracterıstica de FitNesse es que no requiere que las pruebas

se programen, solo basta con que las paginas en la Wiki se escriban de una

forma muy en particular y las pruebas son ejecutadas con un link en la Wiki.

Fit (y por lo tanto FitNesse) tambien utiliza JUnit como base. La di-

ferencia es que tienen clases de pruebas genericas (llamadas Fixtures) que

funcionan en base a parametros.

Pruebas de Regresion Es cualquier tipo de prueba que intente descubrir

la aparicion de un nuevo bug introducido por cambios realizados reciente-

mente. Es decir, realizar pruebas unitarias y de integracion a codigo que ha

sido recientemente modificado16.

Debido a que este tipo de pruebas son, simplemente, las mismas anteriores

aplicadas en un contexto distinto, las plataformas de testing para este tipo

15http://fitnesse.org/16Cuando se realizan optimizaciones o refactoring es conveniente realizar estas pruebas.

11

de prueba son las mismas que para pruebas unitarias y de integracion.

Pruebas de Carga Son pruebas encargadas de sobrecargar una aplicacion

para asegurarse de que soporte una cantidad determinada de clientes y de

que el tiempo de respuesta a estos sea la deseada.

JMeter17 es otro proyecto de Jakarta encargado de medir el desempeno

de aplicaciones en servidores. Realiza esto emulando muchos usuarios que

realizan diversas consultas y analiza el tiempo de respuesta. Tiene una in-

terfaz grafica y se pueden definir archivos de pruebas para ser ejecutados.

Ademas, se pueden ejecutar estos archvios de prueba por lınea de comandos

guardando los resultados en imagenes o archivos.

Pruebas de Interfaz Graficas Son una de las pruebas mas complicadas.

Estas aseguran que la interfaz grafica funciona de la forma esperada. Como se

implementen estas pruebas depende mucho de la plataforma en donde corre

la aplicacion a probar.

Selenium18 es una suite de herramientas para automatizar las pruebas

de interfaz para aplicaciones web. Su principal caracterıstica es que corre en

varios navegadores web y que puede ser controlado por diversos lenguajes de

programacion.

Si bien la herramienta permite la ejecucion de pruebas en diversos nave-

gadores y mediante diversos lenguajes de programacion, esta funcionalidad

17http://jakarta.apache.org/jmeter/18http://selenium.openqa.org/

12

no pudo ser implementada en la practica. Esto debido a que se necesita que

el Selenium Core corra en un computador con el sistema operativo adecua-

do y que tenga interfaz grafica, por lo tanto, no podıa ser ejecutado en el

servidor local y los computadores no tienen Windows ni Mac OS instalado,

ası es que se redujo a Mozilla Firefox. Entonces se decidio no complicarse con

esta funcionalidad y utilizar el plugin para Mozilla Firefox para automatizar

instrucciones de usuario.

De esta forma, se separa la realizacion de pruebas de intefaz del resto de

las pruebas.

3.3. Integracion

Una vez investigadas las distintas herramientas para realizar las pruebas

requeridas, se decidio utilizar FitNesse, JMeter y Selenium.

El sistema integrado se compone de dos partes: una que corre en el servi-

dor local, compuesto por FitNesse y JMeter, que realizan las pruebas unita-

rias, de integracion y de regresion, y otra parte que corre en el navegador del

tester, compuesto por Selenium, que realiza las pruebas de interfaz grafica.

3.3.1. Sistema Servidor Local

Plataforma Base Para implementar el sistema en el servidor local se uti-

lizo como base la plataforma FitNesse. La instalacion era bastante directa,

solo basto con descomprimir el archivo descargado y modificar el script de

inicializacion para que no pida parametros. Es decir, la herramienta era un

13

servidor standalone en donde solo es necesario ejecutarlo y se pondra a recibir

solicitudes en un puerto en particular (en donde funcionara la Wiki).

Una vez la Wiki haya sido iniciada y se puedan editar paginas, uno puede

empezar a crear pruebas. La plataforma esta hecha de tal forma que las

pruebas quedan definidas en las paginas de la Wiki (todas las paginas tienen

un link para ejecutar las pruebas definidas dentro de esta).

Una caracterıstica de esta Wiki es que todo el texto dentro de la pagina

es ignorado al momento de ejecutar las pruebas, excepto por las tablas. La

informacion en las tablas debe estar cuidadosamente estructurado para poder

ejecutar las pruebas.

Para crear una nueva prueba se deben realizar los siguientes pasos:

1. Todas las clases que se desean testear deben estar en una carpeta en

particular. En la pagina de la Wiki se puede incluir esta direccion al

classpath escribiendo un comando especial.

2. Escribir una clase que extienda a algun Fixture (clases basicas de tes-

ting) y escribir los metodos parametrizados para validar la clase. Estos

metodos deben no deben ser absolutos, sino que deben recibir argu-

mentos para validar que el metodo que se desea chequear funciona

bien. Luego, en la Wiki, se establecen los valores de estos parametros.

De esta forma basta con disenar las pruebas para luego agregar nuevos

casos de prueba sin tener que editar ni recompilar el codigo.

Esta clase debe ser compilada y almacenada en una carpeta definida.

14

Un ejemplo de esta clase a continuacion:

1 import f i t . ColumnFixture ;

2

3 public class Bicyc l eTes t extends ColumnFixture {

4

5 protected Bicyc l e b ;

6 public int speed ;

7

8 public Bicyc l eTes t ( ) {

9 b = new Bicyc l e ( ) ;

10 }

11

12 public int speedUp ( ) {

13 b . speedUp ( speed ) ;

14 return b . speed ;

15 }

16

17 public int applyBrakes ( ) {

18 b . applyBrakes ( speed ) ;

19 return b . speed ;

20 }

21

22 }

3. Escribir una tabla, en la Wiki, siguiendo la estructura impuesta, es

decir, un codigo parecido al siguiente:

1 ! | Bicyc l eTes t |

2 | speed | speedUp ( ) | speed | applyBrakes ( ) |

3 | 1 0 | 1 0 | 0 | 1 0 |

4 | −20 |10 | −20 |10 |

5 | 4 0 | 5 0 | 2 0 | 3 0 |

6 | 8 0 | 1 1 0 | 1 5 0 | 0 |

15

Este codigo establece la variable de instancia speed como 10 y luego

ejecuta el metodo speedUp() y compara que el resultado retornado sea

igual a 10. Y ası sigue por cada columna en cada fila. Se puede notar

que se desea validar que aumentar la velocidad un numero negativo o

frenar un numero negativo haga nada.

Luego de realizar la prueba, la pagina pone las celdas cuyo resultado

esta bien en verde y en rojo en caso contrario.

Extension Para realizar las pruebas de carga fue necesario crear un nuevo

Fixture que puede ser llamado desde la Wiki. Este Fixture, llamado Jmeter-

Fixture, no necesita ser extendido por otra clase para funcionar.

Para crear una nueva prueba de carga solo se debe crear una tabla con la

siguiente forma:

1 ! | JmeterFixture |

2 | i n i t | f i l e s / s t r e s s /p |

3 | s t a r t | |

4 | output | |

5 | graph | |

En donde init es la ruta al archivo de configuracion que tiene la defi-

nicion de la prueba creada con JMeter. Luego, en la celda a la derecha de

start aparece informacion sobre el comando JMeter ejecutado y en output

aparecera la informacion de salida de la ejecucion del comando. Finalmente,

en graph aparecera el grafico de resultado de la prueba de carga.

Otra caracterıstica importante de FitNesse es que permite crear SubWi-

16

kis, es decir, paginas dentro de pagias. Cuando se realiza esto, la opcion

de ejecutar una Suite de Tests aparece. Cuando se selecciona la opcion, se

ejecutan todas las pruebas de la pagina y de las SubWikis dentro de esta,

resumiendo los resultados.

Tambien, captura las excepciones mostrandolas en la pagina.

3.3.2. Sistema Browser

El sistema que corre en el navegador es el Selenium IDE. Este plugin es

una plataforma de testing completa y muy facil de usar.

La creacion de pruebas puede ser escribiendo los distintos scripts o gra-

bando las acciones directamente desde el navegador web, es decir, uno empie-

za a grabar y luego hace click en las distintas partes, escribe en los campos

de texto, etc.

En cualquier parte de la creacion de las pruebas se pueden agregar as-

serts19 para ir comprobando que la salida del navegador es la esperada.

Ademas tiene otras caracterısticas, como establecer breakpoints en los

scripts de pruebas y guardar las pruebas en archivos HTML, scripts de Ruby,

y otros formatos.

En conclusion, el sistema por sı solo funciona suficientemente bien para

cumplir con los requisitos.

19Acciones que comprueban que el estado sea el requerido.

17

4. Conclusion

En el transcurso de la practica profesiona se pudo ver como funciona una

empresa dedicada al rubro de la Computacion, lo que fue una experiencia

muy valiosa. El ambiente laboral en Blue Company S.A. era muy agradable

y comodo20 con una excelente disposicion de todas las personas.

Se aprendio sobre los distintos tipos de pruebas y, mas importante, se

pudo ver la relevancia del testing en plataformas grandes.

Finalmente, se puede decir que el area de testeo esta bastante inmadu-

ro. No existe mucha informacion al respecto ni buenas practicas (aparte del

desarrollo orientado al testing), ademas, las plataformas de testeo no son las

mejores debido a que son bastante especıficas, tienen muy poca documenta-

cion, difıciles de integrar y de utilizar.

En particular, FitNesse, siendo una aplicacion de codigo lbire, no tenıa

documentacion sobre el codigo ni en el codigo ni como estaba implementado,

es decir, no explicaba la interrelacion entre los distintos metodos y clases,

los patrones de diseno utilizados, etc. Entonces se tuvo que leer y seguir

manualmente el orden de las instrucciones ejecutadas para poder entender

como funcionaba y como agregar nuevos componentes.

Junto con esto, tambien cabe destacar que los sistemas desarrollados no

son faciles de testear ya que, normalmente, no se programa orientado al testeo

y no se acostumbra a validar de forma seguida e incremental, haciendo que

20Asistı a la celebracion de Fin de Ano en la casa en Tunquen de Ingrid Antonijevic,Presidenta del Directorio.

18

el diseno de las pruebas sea muy complicado.

Por ultimo, se aprendio que uno debe desarrollar siempre teniendo en

cuenta que hay que testear el codigo y que alguien, en algun momento ya sea

tarde o temprano, volvera a leer el codigo.

19