Blog de Antonio Manuel Muñiz

Desarrollo, Ingeniería y Calidad del Software

Archivos mensuales: noviembre 2008

Segundo día en expo:QA

El segundo (y último) día de conferencias en expo:QA, al igual que el primero, no me ha defraudado. Me vuelvo a Sevilla muy satisfecho. De las conferencias de hoy destaco dos:

Integración Continua (Eric Pugh, Open Source Connections)

Eric Pugh nos ha contado cómo implantar un sistema de integración continua teniendo en cuenta los contratiempos que encontraremos (tanto técnicos como «sociales»), entendiendo como contratienpos sociales por ejemplo el hecho de que los programadores vean el sistema de IC como una herramienta que sólo resalta los errores que se cometen, cuando en realidad es todo lo contrario, les ayuda a realizar mejor su trabajo. Incluso les ahorra tiempo cuando hay que preparar una demo al cliente, todo se reduce a lanzar un build en IC.

Eric comentaba que la IC será un «radiador de información útil para todo el equipo del proyecto». Por último vimos una demostración con Hudson. Destacar el esfuerzo de Eric por hacer la exposición en español.

Methodology for performace testing (Edgardo Greising)

En esta charla Edgardo ha compartido la metodología usada en el laboratorio de Ensayos de Plataformas del CES. Esta metodología consiste en:

  • Definición de escenarios: infraestructura, datos de prueba, número de usuarios concurrentes, etc
  • Automatización: determinar el guión de ejecución
  • Reproducción del entorno de producción: hardware, software, red (en caso de que queramos medir tiempos)
  • Monitorización: a nivel software y a nivel humano (usuarios reales interactuando con la aplicación en paralelo con cientos de usuarios virtuales)
  • Reportes: recomendando el uso de gráficas para encontrar patrones de comportamiento

Primer día de conferencias en expo:QA

Una vez finalizado el primer día de conferencias en expo:QA me deja un buen sabor de boca, y ganas de escuchar lo que viene mañana. En general las conferencias están siendo bastante interesantes, y lo que más me gusta, lo que se cuenta aquí está en la línea que seguimos en la empresa en la que trabajo, con más o menos dificultades ;).

Algunas reseñas de las conferencias más destacables de hoy (en mi opinión, por suspuesto):

Cualificaciones del ingeniero de pruebas basadas en la competencia: ¿el siguiente paso para la profesión del ingeniero de pruebas?

En esta conferencia Susan Windsor hablaba de los pros y contras de las recientes certificaciones de Software Testing, destacando cómo alguien que no tiene ninguna experiencia técnica en testeo de software puede aprobar la certificación simplemente estudiando un determinado glosario y unas nociones básicas. Por contra, la obtención de la certificación hace que todos los profesionales certificados usen un lenguaje común al hablar de software testing y unas metodologías similares que aunan esfuerzos a la hora de definir las pruebas. Por otro lado pasaba a valorar las cualidades necesarias para ser un buen tester, tanto innatas, como adquiridas.

Evitar el síndrome de caja negra en proyectos de software externalizados

Luis Rodríguez Berzosa ha realizado una charla muy interesante, orientada al aseguramiento de la calidad en proyectos (o partes de proyectos) que se externalizan bajo el lema toma requisitos y dame software, valorando las implicaciones que tiene la no gestión de la calidad del software externalizado. Me gustó especialmente la frase «cuando mejor se reconoce la falta de calidad es cuando se sufre», y en este tipo de desarrollos la empresa receptora del software es la que lo sufre, es decir, la que lo mantiene, lo migra, lo modifica, etc. En este aspecto, comentaba Luis, es importante medir una serie de factores (métricas) como son: Fiabilidad, Usabilidad, Eficiencia, Comprensibilidad (legibilidad del código) y facilidad de migración (esto lo digo yo: estas métricas me suenan). Otra frase destacable, en cuanto al seguimiento de determinadas normas o metodologías (ISO, CMMI, etc): «El talento supuesto no es suficiente se necesita buen trabajo», en relación a la tendencia de las normas de decir qué, pero no cómo.

Gestión de la calidad en los diferentes roles

En esta charla he visto cómo el concepto de Ecosistema Software también esta presente en Microsoft, por supuesto en un entorno .NET. Luis Fraile nos ha contado cómo modela microsoft las tareas de cada rol en un equipo de desarrollo, desde el jefe de proyecto (con el paquete office, integrado en el ecosistema) hasta el desarrollador y el QA (con Visual Studio), todo ello enmarcado en la plataforma de desarrollo Visual Studio Team System. En mi opinión tiene un pequeño hueco en el rol de analista funcional, ya que no hay ninguna herramienta en el «ecosistema» que modele las tareas del analista, y mucho menos que las trace hacia las tareas del resto del equipo.

Eso es todo por hoy, mañana más.

Load testing con Tsung

Tsung es una herramienta Open Source para realizar pruebas de carga de varios tipos: HTTP, WebDAV, XMPP (Jabber), PostgreSQL, MySQL y LDAP. Hasta ahora había usado JMeter para definir pruebas de carga sobre aplicaciones web, mediante la repetición controlada de peticiones HTTP más o menos complejas. Realmente lo que me ha sorprendido de Tsung es la variedad de tipos de tests posibles, especialmente las pruebas sobre bases de datos (MySQL y PostgreSQL) y sobre protocolo WebDAV.

Es cierto que la usabilidad de Tsung no está al nivel de JMeter, principalmente porque no tiene interfaz gráfica, pero el resultado en cuanto a interpretación de los reportes de la prueba, no tiene nada que envidiar, incluso diría que supera a JMeter en este aspecto.

Para realizar una prueba con Tsung el procedimiento es el siguiente (para una prueba a un servidor WebDAV, por ejemplo).

En primer lugar debemos instalar Tsung. Existen distrubuciones binarias para Debian, Ubuntu y RedHat, aunque para los amantes de la compilación existe una distribución de código fuente.

Para capturar las peticiones al servidor lanzamos el recorder:

~/Antonio$ tsung -p webdav recorder

Realizamos las peticiones configurando un proxy (localhost:8090, por defecto) en la herramienta que usemos para realizar las peticion (algún cliente WebDAV). Tsung generará un fichero XML que incrustaremos en el fichero de configuración ($HOME/.tsung/tsung.xml), en su sección sessions. En el fichero tsung.xml configuramos también los parámetros de la prueba: número de usuarios (simulados) concurrentes, intervalo entre peticiones, etc. Una caracteristica que llama la atención de Tsung es la posibilidad de configurar cierta incertidumbre en la prueba, por ejemplo, podemos indicar que simule peticiones desde un cliente X con una probabilidad del 80% y desde un cliente Y con un 20%. Incluso podemos definir incertidumbre en la propia petición (en tsung, sesiones).

Una vez configurada la prueba, lanzamos el test:

~/Antonio$ tsung -p webdav start

Al comienzo del test Tsung crea un directorio en $HOME/.tsung/log en el que escribe los ficheros de reporte. Estos ficheros serán tratados posteriormente para generar HTML con la información, esta tarea se lleva a cabo mediante el script tsung_stats.pl, incluido en la distribución de Tsung. Para poder visualizar el resultado de los tests en tiempo real podemos preparar un pequeño script que llame reiteradamente a tsung_stats.pl:

#!/bin/sh
alias tsung_stats='/usr/lib/tsung/bin/tsung_stats.pl'
tsung_stats
firefox ./graph.html
while [ "true" ]
do
  echo "Refreshing stats..."
  tsung_stats
  sleep 3
done

Este script se debe llamar desde el directorio en el que Tsung genera los reportes. Genera los HTML cada 3 segundos, lo único que debemos hacer es refrescar Firefox para ver la evolución.

tsung-graph-report

Transformaciones con Maven Assembly Plugin

Uno de los usos más típicos del plugin Assembly de Maven es la generación de un «distribuible» de nuestro proyecto. Mediante el uso de este plugin podemos seleccionar qué partes del proyecto se incluirán en el «distribuible».

También podemos, por ejemplo, generar una distribución de código fuente del proyecto que no contenga datos relativos a nuestro entorno y sea «compilable» fuera de él.

Pero en realidad lo que podemos conseguir con este plugin es ilimitado, pudiendo definir «transformaciones» de todo tipo:

assembly-graphic

Módulos OpenCMS y Maven

Objetivo: modelar el ciclo de vida de un módulo de OpenCMS con Maven2

Si realizamos una búsqueda rápida en google vemos que las palabras OpenCMS y Maven no aparecen juntas facilmente. La única referencia interesante es el plugin desarrollado por Comundus, pero está orientado a la gestión del proyecto OpenCMS completo, no al desarrollo de módulos de forma aislada. En este post veremos cómo gestionar dependencias, compilar y empaquetar un módulo de OpenCMS con Maven2.

En el proceso de modelado hay una restricción: el código fuente debe ser compatible con el uso del plugin opencmsmoddev para Eclipse. Esto nos obliga a no seguir la estructura típica de un proyecto Maven sino la que requiere dicho plugin. La estructura requerida es la siguiente:

--+ src
--+ system
  |--+ workplace
     |--+ resources
--+ lib
--+ schemas
--+ templates
--+ manifest.xml
--+ pom.xml

Dada esta premisa, necesitamos configurar el P.O.M de una forma un poco especial. En primer lugar debemos indicar donde estan nuestros fuentes y donde poner los compilados:

<sourceDirectory>src</sourceDirectory>
<outputDirectory>classes</outputDirectory>

Además el resultado de realizar un mvn package debe ser un zip desplegable en una instancia de OpenCMS. Para ello utilizaremos el plugin maven-antrun-plugin con la siguiente configuración:

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.1</version>
    <executions>
        <execution>
            <id>zip-module</id>
            <goals>
                <goal>run</goal>
            </goals>
            <phase>package</phase>
            <inherited>false</inherited>
            <configuration>
                <tasks>
                    <echo>Packaging OpenCMS Module...</echo>
                    <mkdir dir="target/dist/system/modules/${project.groupId}.${project.artifactId}" />
                    <copy todir="target/dist/system/modules/${project.groupId}.${project.artifactId}/src">
                        <fileset dir="src" />
                    </copy>
                    <copy todir="target/dist/system/modules/${project.groupId}.${project.artifactId}/classes">
                        <fileset dir="classes" />
                    </copy>
                    <copy todir="target/dist/system/modules/${project.groupId}.${project.artifactId}/schemas">
                        <fileset dir="schemas" />
                    </copy>
                    <copy todir="target/dist/system/modules/${project.groupId}.${project.artifactId}/templates">
                        <fileset dir="templates" />
                    </copy>
                    <copy todir="target/dist/system/workplace">
                        <fileset dir="system/workplace" />
                    </copy>
                    <copy file="manifest.xml" todir="target/dist" />
                    <zip destfile="target/${project.groupId}.${project.artifactId}.zip" basedir="target/dist" />
                </tasks>
            </configuration>
        </execution>
    </executions>
</plugin>

Esta tarea genera el zip requerido por OpenCMS a partir de lo que anteriormente hemos puesto en target/dist.

Aprovecharemos la gestión de dependencias que nos ofrece Maven, en principio la única dependencia que necesitamos es la del propio núcleo de OpenCMS. He usado como base OpenCMS 7.0.5, no he encontrado esta dependencia en ningún repositorio de Maven (conocido). Para solventar esto debemos instalarla en nuestro repositorio local e incluir la dependencia correspondiente en el P.O.M:

<dependency>
    <groupId>org.opencms</groupId>
    <artifactId>opencms</artifactId>
    <version>7.0.5</version>
    <scope>provided</scope>
</dependency>

La marcamos como provided ya que en tiempo de ejecución será OpenCMS el que la incluya en el classpath.

OpenCMS requiere que ciertos recursos se coloquen en el directorio src junto a los fuentes, para poder usar filtrado usaremos:

<resources>
    <resource>
        <directory>src</directory>
        <filtering>false</filtering>
        <excludes>
            <exclude>**/*.java</exclude>
        </excludes>
    </resource>
</resources>

Al empaquetar el módulo necesitamos incluir todas sus dependencias (excepto la marcadas con scope provided), para ello usaremos maven-dependency-plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
        <execution>
            <id>copy</id>
            <phase>process-resources</phase>
            <goals>
                <goal>copy-dependencies</goal>
            </goals>
            <configuration>
                <excludeScope>provided</excludeScope>
                <outputDirectory>target/dist/system/modules/${project.groupId}.${project.artifactId}/lib</outputDirectory>
                <overWriteReleases>true</overWriteReleases>
                <overWriteSnapshots>true</overWriteSnapshots>
            </configuration>
        </execution>
    </executions>
</plugin>

Este es el fichero pom.xml completo.