Artículos etiquetados con:qa
Pruebas de rendimiento con JMeter. Ejemplos básicos

En todo proyecto de desarrollo software es muy importante la realización de planes de pruebas que garanticen que se cumplen los requisitos funcionales de la aplicación. Pero no todo el trabajo de un QA son las pruebas funcionales. Además de éstas, existen otras que pueden marcar la calidad de una aplicación: de seguridad, de usabilidad, de rendimiento.

Las pruebas de rendimiento son, desde la perspectiva más evidente, las que se realizan para determinar lo rápido que un sistema realiza una tarea en unas determinadas condiciones de trabajo. En este post hablaremos sobre su utilidad, los tipos que existen y cómo realizarlas con JMeter.

 

 

¿PARA QUÉ SIRVEN LAS PRUEBAS DE RENDIMIENTO?

Para alcanzar un buen nivel de rendimiento de un sistema es fundamental que las pruebas comiencen en el inicio del desarrollo del software. Al igual que en las pruebas funcionales, el coste de solucionar defectos se ve aumentado conforme más se tarde en detectarlos.

Además, si queremos que los resultados sean lo más fiables posible, nuestro entorno de pruebas debe ser lo más parecido posible al de producción, y no cruzarlo nunca con el de desarrollo ni el de otras pruebas.

La pruebas de rendimiento sirven, entre otras cosas, para:

  • Demostrar que el sistema cumple los criterios de rendimiento.
  • Validar y verificar atributos de la calidad del sistema: escalabilidad, fiabilidad, uso de los recursos.
  • Comparar dos sistemas para saber cuál de ellos funciona mejor.
  • Medir qué partes del sistema o de carga de trabajo provocan que el conjunto rinda mal.

 

 

TIPOS DE PRUEBAS DE RENDIMIENTOS

PRUEBA DE CARGA

Éste es el tipo más sencillo de pruebas de rendimiento. Una prueba de carga se realiza generalmente para observar el comportamiento de una aplicación bajo una cantidad esperada de peticiones. Esta carga puede ser el número esperado de usuarios concurrentes, utilizando la aplicación que realizan un número específico de transacciones, durante el tiempo que dura la carga. Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones importantes de la aplicación. Si también se monitorizan otros aspectos como la base de datos, el servidor de aplicaciones, etc., entonces esta prueba puede mostrar el cuello de botella en la aplicación.

 

PRUEBA DE ESTRÉS

Se utiliza normalmente para romper la aplicación. Se va doblando el número de usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba se realiza para determinar la solidez de la aplicación en los momentos de carga extrema. Esto ayuda a los administradores para determinar si la aplicación rendirá lo suficiente en caso de que la carga real supere a la carga esperada.

 

PRUEBA DE ESTABILIDAD (SOAK TESTING)

Normalmente se hace para determinar si la aplicación puede aguantar una carga esperada continuada. Generalmente esta prueba se realiza para determinar si hay alguna fuga de memoria en la aplicación.

 

PRUEBA DE PICO (SPIKE TESSTING)

La prueba de picos, como el nombre sugiere, trata de observar el comportamiento del sistema variando el número de usuarios, tanto cuando bajan como cuando tiene cambios drásticos en su carga. Esta prueba se recomienda que sea realizada con un software automatizado que permita realizar cambios en el número de usuarios mientras que los administradores llevan un registro de los valores a ser monitorizados.

 

 

METODOLOGÍA

Según Microsoft Developer Network, la metodología de las pruebas de rendimiento consiste en las siguientes actividades:

  1. Identificar el entorno de pruebas. Identificar el entorno físico de pruebas y el entorno de producción, así como las herramientas y recursos de que dispone el equipo de prueba. El entorno físico incluye hardware, software y configuraciones de red. Tener desde el principio un profundo conocimiento de todo el entorno de prueba permite diseños de pruebas más eficientes. Facilita también la planificación y ayuda a identificar problemas en las pruebas en fases tempranas del proyecto. En algunas situaciones, este proceso debe ser revisado periódicamente durante todo el ciclo de vida del proyecto.
  2. Identificar los criterios de aceptación de rendimiento. Determinar el tiempo de respuesta, el rendimiento, la utilización de los recursos y los objetivos y limitaciones. En general, el tiempo de respuesta concierne al usuario, el rendimiento al negocio, y la utilización de los recursos al sistema.  Identificar cuáles serían criterios de éxito de rendimiento del proyecto para evaluar qué combinación de la configuración da lugar a un funcionamiento óptimo.
  3. Planificar y diseñar las pruebas. Identificar los principales escenarios, determinar la variabilidad de los usuarios y la forma de simular esa variabilidad, definir los datos de las pruebas y establecer las métricas a recoger. Consolidar esta información en uno o más modelos de uso del sistema a implantar, ejecutarlo y analizarlo.
  4. Configurar el entorno de prueba. Preparar el entorno de prueba, las herramientas y recursos necesarios para ejecutar cada una de las estrategias, así como las características y componentes disponibles para la prueba. Asegurarse de que el entorno de prueba se ha preparado para la monitorización de los recursos según sea necesario.
  5. Aplicar el diseño de la prueba. Desarrollar las pruebas de rendimiento de acuerdo con el diseño del plan.
  6. Ejecutar la prueba. Ejecutar y monitorizar las pruebas. Validar las pruebas, los datos de las pruebas y recoger los resultados. Ejecutar pruebas válidas para analizar, mientras se monitoriza la prueba y su entorno.
  7. Analizar los resultados, realizar un informe y repetirlo. Consolidar y compartir los resultados de la prueba. Analizar los datos, tanto individualmente como con un equipo multidisciplinario. Volver a priorizar el resto de las pruebas y a ejecutarlas en caso de ser necesario. Cuando todas las métricas estén dentro de los límites aceptados, ninguno de los umbrales establecidos hayan sido rebasados y toda la información deseada se ha reunido, las pruebas han acabado para el escenario definido por la configuración.

 

 

JMETER

Existen numerosas herramientas, tanto open source como privativas, para realizar las pruebas de rendimiento: NeoLoad, LoadRunner, LoadUI, WebLOAD, etc. Una de las más populares es JMeter (open source), en la cual nos centraremos en este post.

Rendimiento JMeter - JMeter - SDOS

 

En JMeter, un plan de pruebas es una jerarquía de componentes en forma de árbol (panel de control de la izquierda). Cada nodo del árbol es un componente. A su vez, un componente es una instancia de un tipo de componente en la que quizás se han configurado algunas de sus propiedades (en el panel de control de la derecha).

Los diferentes componentes de los que puede constar un plan de pruebas son:

  • Test Plan. Es el tipo de componente que representa la raíz del árbol.
  • Thread Group. Representa un grupo de usuarios. En JMeter cada thread es un usuario virtual.
  • Controllers (Sampler, Logic Controler). Los samplers realizan peticiones contra la aplicación y los logic controlers establecen el orden en que se ejecutan éstos.
  • Config Element. Establecen propiedades de configuración que se aplican a los samplers a los que afectan.
  • Assertion. Comprueban condiciones que aplican a las peticiones que realizan contra la aplicación los samplers a los que afectan.
  • Listeners. Recopilan datos de las peticiones que realizan los samplers a los que afectan.
  • Timer. Añaden tiempo extra a la ejecución de las peticiones que realizan contra la aplicación los samplers a los que afectan
  • Pre-Processor element. Realizan acciones o establecen configuraciones previa a la ejecución de los samplers a los que afectan.
  • Post-Processor element. Realizan acciones o establecen configuraciones posteriormente a la ejecución de los samplers a los que afectan.

 

 

EJEMPLO BÁSICO CON JMETER

Para preparar el escenario de las pruebas en JMeter cargamos una plantilla. Vamos a File>Template. Se abre una pequeña ventana nueva para elegir qué plantilla deseamos cargar. Elegimos la primera (‘Recording‘). Ésta sirve para “grabar” la navegación de un sitio web.

Rendimiento JMeter - Defined variables - SDOS

 

Para nuestro ejemplo básico, podemos eliminar algunos componentes como ‘User Defined Variables‘, ‘HTTP Request Default‘ y ‘HTTP Cookie Manager‘. Para la recepción de los datos, botón derecho sobre ‘Thread Group‘ y Add>Listener>Graph Results. Podemos añadir algunos receptores de datos más. Nosotros, finalmente trabajamos con este esquema:

Rendimiento JMeter - Esquema - SDOS

 

Para la configuración, vamos a ‘HTTP(S) Test Script Recorder‘ y en el campo del puerto escribimos el que queramos usar. En nuestro caso, 8181.

Rendimiento JMeter - Settings Port - SDOS

 

Pulsamos, ahora, en ‘Thread Group‘ y en ‘Number of Threads‘ escribimos el número de usuarios concurrentes que queremos que hagan las peticiones. En nuestro caso, 10. En ‘Loop Count‘ (repeticiones) pondremos 100. Ya tendríamos configurado correctamente JMeter.

Rendimiento JMeter - Thread Group - SDOS

 

Antes de empezar a grabar, debemos configurar el proxy de nuestro navegador con el puerto que escribimos anteriormente y la dirección IP de nuestro equipo:

Rendimiento JMeter - Configuracion Proxy - SDOS

 

Ya tenemos todo listo para empezar a ‘grabar‘ las peticiones que hagamos desde nuestra aplicación. En JMeter, pulsamos sobre ‘HTTP(S) Test Script Recorder‘ y hacemos click en ‘Start‘. Ya estamos ‘escuchando’.

Rendimiento JMeter - Grabar peticiones - SDOS

 

Ya solo nos queda navegar a través de la web que queramos probar. Para nuestro ejemplo, hemos navegado en una página de prueba: Blazedemo.

Las peticiones se van guardando en nuestro Test Plan:

Rendimiento JMeter - Test plan - SDOS

 

Cuando tengamos las peticiones, paramos la grabación pulsando en ‘Stop‘. Finalmente, para ejecutar nuestro plan de pruebas simplemente hay que pulsar el botón de ‘Run‘.

Rendimiento JMeter - Ejecutar plan de pruebas - SDOS

 

Los resultados pueden observarse en los ‘Listeners‘ que añadimos anteriormente:

Rendimiento JMeter - Resultado listeners 1 - SDOS

 

Rendimiento JMeter - Resultado listeners 2 - SDOS

 

 

EJEMPLO BÁSICO CON JMETER + MAVEN

Para usar JMeter dentro de un proyecto Maven, vamos a utilizar el plugin jmeter-maven-plugin.

La configuración de éste en el archivo POM es la siguiente:

<plugins>
	<plugin>
		<groupId>com.lazerycode.jmeter</groupId>
		<artifactId>jmeter-maven-plugin</artifactId>
		<version>2.7.0</version>
		<executions>
			<execution>
				<id>jmeter-tests</id>
				<goals>
					<goal>jmeter</goal>
				</goals>
				<phase>verify</phase>
			</execution>
		</executions>
		<configuration>
				
			<generateReports>false</generateReports>
			<resultsFileFormat>xml</resultsFileFormat>
			<testResultsTimestamp>false</testResultsTimestamp>
					
		</configuration>
	</plugin>

 

Por defecto, JMeter crea un reporte a través de un archivo .csv. Para que esto no ocurra tenemos que poner a false el generateReports. El siguiente plugin que vamos a utilizar necesita leer los datos de un archivo .xml, de ahí la configuración de resultFileFormat.

El otro plugin que usamos es jmeter-graph-maven-plugin que nos mostrará los distintos resultados en forma de gráficas. En el archivo POM indicamos cuál será el archivo de entrada y los de salida que corresponderá a cada una de las gráficas que añadamos:

<plugin>
	<groupId>de.codecentric</groupId>
	<artifactId>jmeter-graph-maven-plugin</artifactId>
	<version>0.1.0</version>
	<executions>
		<execution>
			<id>create-graphs-collection</id>
			<goals>
				<goal>create-graph</goal>
			</goals>
			<phase>verify</phase>
			<configuration>
				<inputFile>${project.build.directory}/jmeter/results/EjemploBlaze.jtl</inputFile>
				<graphs>
					<graph>
						<pluginType>ThroughputVsThreads</pluginType>
						<width>1920</width>
						<height>1080</height>
						<outputFile>${project.build.directory}/jmeter/results/ThroughputVsThreads.png</outputFile>
					</graph>
					<graph>
						<pluginType>ResponseCodesPerSecond</pluginType>
						<width>1920</width>
						<height>1080</height>
						<outputFile>${project.build.directory}/jmeter/results/ResponseCodesPerSecond.png</outputFile>
					</graph>

 

Las distintas gráficas y su significado pueden verse en jmeter-plugins.org.

Para ejecutar nuestro plan de pruebas de JMeter, debemos guardarlo dentro de /src/test/jmeter del proyecto Maven. Desde la terminal, accedemos a la raíz del proyecto Maven y ejecutamos: $mvn verify.

Una vez ejecutado, aparecerá algo como:

Rendimiento JMeter - Maven - SDOS

 

Y las gráficas aparecerán donde indicamos en la configuración del plugin. Estos son algunos ejemplos:

  • Bytes throughput over time. Cantidad de bytes enviados y recibidos por JMeter durante la prueba de carga.
    Rendimiento JMeter - Bytes throughput over time - SDOS

 

  • Server hits per second. Hits enviados por el plan de prueba al servidor por segundo.
    Rendimiento JMeter - Server hits per second - SDOS

 

  • Response codes per second. Código de respuesta por segundo devuelto durante la prueba.
    Rendimiento JMeter - Response codes per second - SDOS

 

El código de este proyecto lo puedes encontrar en nuestro repositorio.

 

 

EN RESUMEN

Está claro que las pruebas funcionales son las más importantes, ya que son las que garantizan que la aplicación realizará las funciones marcadas por el cliente. Pero asegurar la calidad de una aplicación es mucho más que eso.

Por esto, QA y desarrolladores tienen que colaborar estrechamente no sólo para que la aplicación haga esta cosa o la otra, sino también para que lo haga en el mínimo de tiempo posible. Ahí puede estar la diferencia entre una buena aplicación y otra mejor, entre una buena y mejor satisfacción del cliente.

En definitiva, no sólo de pruebas funcionales vive el QA.

 

 


Cómo crear desplegar un artefacto con Maven

Uno de los propósitos de QA es generar modelos que aporten consistencia y organización a la hora de trabajar en proyectos de automatización.

Si además queremos que este modelo se sustente en la unificación de las bases de proyectos, la opción es Maven. Dicho esto, la primera pregunta que puede surgir es, ¿y por qué no con Gradle?

Lo cierto es que, a pesar de que su uso parece estar generalizándose, la gran mayoría de los proyectos basados en automatización siguen usando Maven. Además cuenta con una documentación mucho más extensa. Siendo sinceros, aunque empieces a utilizar Gradle para la automatización, finalmente acabarás recurriendo a Maven.

En este post veremos cómo crear, configurar y distribuir artefactos de nuestros proyectos para mejorar los procesos de desarrollos futuros.

 

QUÉ ES MAVEN

En primer lugar debemos entender qué es Maven y el beneficio que nos aporta. Nuestra idea es usarlo para desplegar un artefacto.

Maven es una herramienta que nos simplificará los procesos de desarrollo de un proyecto. Una de las principales ventajas es tenerlo todo centralizado en un fichero llamado POM (Project Object Model), el cual nos aportará toda la información y configuración del proyecto.

Este fichero está dividido en diversas secciones, pero para nuestro propósito nos centraremos principalmente en dos:

  • Configuración de la construcción
  • Configuración del entorno

 

CONFIGURACIÓN DE LA CONSTRUCCIÓN

Contiene la configuración de los plugins e informes que usaremos durante el ciclo de vida de la construcción. Éste se divide en varias etapas con las que podemos alterar el comportamiento del proyecto:

  • Validación
  • Compilación
  • Test
  • Empaquetado
  • Test de integración
  • Verificación
  • Instalación
  • Despliegue

Estas fases tienen una ejecución lineal. Esto quiere decir que, siguiendo la lista anterior, si quisiéramos usar la fase de verificación, previamente Maven pasaría por todas las fases anteriores.

 

CONFIGURACIÓN DEL ENTORNO

Será la encargada de definir los entornos externos a nuestro proyecto que necesitaremos, y los perfiles o requisitos para diferentes configuraciones dentro del mismo entorno. Algunas de las posibles configuraciones son las siguientes:

  • Distribuciones
  • Incidencias
  • Integración continua
  • Cadena de suministros
  • Prerrequisitos
  • Repositorios
  • Perfiles

 

 

QUÉ ES UN ARTEFACTO

A grandes rasgos, un artefacto es un conjunto de funciones, acciones y servicios que almacenamos conjuntamente en un único lugar para que cualquier persona pueda disponer de ellos y poder usarlos.

Así conseguimos tener un proyecto modularizado que nos permita beneficiarnos de todo lo creado. Además, si requerimos de una actualización o necesitamos añadir nuevos artefactos, el impacto de los cambios sobre nuestro proyecto será muy bajo.

 

 

CONFIGURAR UN ARTEFACTO

Para poder llevar a cabo el despliegue de un artefacto, debemos configurar nuestro POM del proyecto siguiendo el siguiente modelo.

A continuación, planteamos un ejemplo de los pasos a seguir para configurar un artefacto que posteriormente pueda ser usado.

 

CONFIGURACIÓN DE LA CONSTRUCCIÓN

Usaremos plugins que se centrarán en cuatro fases del ciclo de vida del proyecto: compilación, empaquetado, verificación y despliegue. Aunque pasaremos por todas, éstas son las fases que nos afectarán principalmente a la hora de generar el artefacto.

maven-compiler-plugins

El compilador será el primero. Simplemente estableceremos para qué versión de Java queremos compilar el código fuente del proyecto. Esto no un requisito necesario pero sí importante para poder evitar incompatibilidades dentro del proyecto.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-compiler-plugin</artifactId>
	<version>3.7.0</version>
	<configuration>
		<source>1.8</source>
		<target>1.8</target>
	</configuration>
</plugin>

 

maven-jar-plugin

El empaquetador tendrá el papel de establecer el formato del código compilado. En nuestro caso emplearemos el tipo JAR, pero estos pueden ser diversos según la necesidad.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-jar-plugin</artifactId>
	<version>3.0.2</version>
	<executions>
		<execution>
			<id>jar</id>
			<goals>
				<goal>test-jar</goal>
			</goals>
		</execution>
	</executions>
</plugin>

 

maven-source-plugin

Dentro del grupo de empaquetadores, tenemos algunos plugins adicionales que usaremos sobre todo para añadir más información al artefacto final. En nuestro ejemplo hemos introducido el máximo de información al artefacto. Por ello, añadimos el código sin compilar para que sea accesible bajo el proyecto que lo usara y el javadoc que serán todas las descripciones de los componentes del artefacto.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-source-plugin</artifactId>
	<version>2.0.4</version>
	<executions>
		<execution>
			<id>attach-sources</id>
			<goals>
				<goal>jar</goal>
			</goals>
		</execution>
	</executions>
</plugin>

 

maven-javadoc-plugin

Será el encargado de establecer la configuración de empaquetado de toda la documentación en una distribución de tipo JAR.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-javadoc-plugin</artifactId>
	<version>3.0.0</version>
	<executions>
		<execution>
			<id>attach-javadocs</id>
			<goals>
				<goal>jar</goal>
			</goals>
		</execution>
	</executions>
</plugin>

 

maven-jarsigner-plugin

Para la parte de seguridad añadimos, como buenas prácticas, un firmado. Así nos aseguramos de que no está modificado por un tercero.

Usando este plugin verificamos que el firmado sea correcto. Simplemente se necesita configurar un contenedor de firmas y la firma que deseemos usar sobre el artefacto.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-jarsigner-plugin</artifactId>
	<version>1.4</version>
	<executions>
		<execution>
			<id>sign</id>
			<goals>
				<goal>sign</goal>
			</goals>
		</execution>
		<execution>
			<id>verify</id>
			<goals>
				<goal>verify</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<keystore>src/main/resources/keystore.jks</keystore>
		<alias>myalias</alias>
		<storepass>password</storepass>
		<keypass>password</keypass>
	</configuration>
</plugin>

 

CONFIGURACIÓN DEL ENTORNO

Para finalizar sólo nos queda configurar el entorno. Para ello, emplearemos únicamente el gestor de distribuciones que será el que subirá a un repositorio privado nuestro artefacto.

Eso sí, debemos tener en cuenta que tendremos dos tipos de versiones de artefacto:

  • En desarrollo
  • De distribución

Como Maven autogestiona qué versión subir, la única forma de indicárselo es mediante el tag Version de nuestro proyecto mediante los siguientes formatos:

  • Versión en desarrollo: X.X.X-SNAPSHOT
  • Versión de distribución: X.X.X
<distributionManagement>
	<repository>
		<id>releases</id>
		<name>my-project-releases</name>
		<url>http://url_repo/artifactory/my-project-releases</url>
	</repository>
	<snapshotRepository>
		<id>snapshots</id>
		<name>my-project-snapshots</name>
		<url>http://url_repo/artifactory/my-project-snapshots</url>
	</snapshotRepository>
</distributionManagement>

 

 

CONFIGURAR LAS CREDENCIALES

Como sabemos, todo servicio suele estar vinculado a una cuenta. Por tanto, debemos establecer nuestro usuario y contraseña de acceso al repositorio para poder realizar el despliegue.

Siguiendo un modelo de buenas prácticas, Maven recomienda establecer estas credenciales en un fichero llamado settings.xml, Éste será el encargado de definir valores de configuración para ser usada en las ejecuciones (sin ser específicas) para un proyecto en concreto.

Los dos ámbitos que podemos encontrar son:

  • Maven. Será usado como configuración global su ubicación se encuentra en ${maven.home}/conf/settings.xml
  • Usuario. Será usado con la configuración establecida por el usuario su ubicación se encuentra en ${user.home}/.m2/settings.xml

Si es la primera vez que configuramos nuestro fichero como usuario, debemos crearlo e introducir las credenciales de la siguiente manera:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
	                    https://maven.apache.org/xsd/settings-1.0.0.xsd">
	<servers>
		<server>
			<id>releases</id>
			<username>admin</username>
			<password>password</password>
		</server>
		<server>
			<id>snapshots</id>
			<username>admin</username>
			<password>password</password>
		</server>
	</servers>
</settings>

Debemos tener muy en cuenta el ID que usemos ya que será el que asocie Maven automáticamente con los repositorios definidos anteriormente.

 

 

DESPLEGAR EL ARTEFACTO

Finalmente, teniendo todas las configuraciones establecidas, sólo nos resta desplegar el proyecto. Por tanto, procederemos a abrir un terminal y navegar hasta el directorio del proyecto de nuestro artefacto.

Una vez situados en él, simplemente convocamos el paso de despliegue de nuestro ciclo de vida para efectuar la construcción completa y finalmente la subida al repositorio de nuestro artefacto.

Usaremos la siguiente línea de comando:

$ mvn deploy

 

 

USAR EL ARTEFACTO

Una vez hayamos configurado correctamente el artefacto, podemos usarlo en proyectos. Para ello, debemos configurar el POM de nuestro nuevo proyecto añadiendo la dependencia de nuestro artefacto de la siguiente forma:

<dependency>
	<groupId>testing</groupId>
	<artifactId>my-project-deploy</artifactId>
	<version>1.0.0</version>
</dependency>

 

Esto nos permitirá un uso total de nuestro artefacto siempre y cuando nuestro repositorio sea público. En el caso contrario, debemos definir la ubicación de nuestros repositorios en nuestro proyecto para que entienda de dónde procede.

<repositories>
      <repository>
            <url>http://url_repo/artifactory/my-project-releases<</url>
            <releases>
                  <enabled>true</enabled>
            </releases>
            <snapshots>
                  <enabled>false</enabled>
            </snapshots>
      </repository>
	<repository>
	      <url>http://url_repo/artifactory/my-project-snapshots</url>
            <releases>
                  <enabled>false</enabled>
            </releases>
            <snapshots>
                  <enabled>true</enabled>
            </snapshots>
      </repository>
</repositories>

 

Hemos realizado un proyecto Maven con todas estas configuraciones de despliegue, para que puedas verlo en acción y utilizarlo como dependencia con tu proyecto si quieres. Podrás encontrarlo en nuestro repositorio de Github.

 

 


¿Qué papel tiene QA en las metodologías ágiles?

Pese a que cada vez son más las empresas que apuestan por el uso de metodologías ágiles en sus equipos de desarrollo de soluciones software, aún son muchos los que desconocen la flexibilidad, la agilidad y el ahorro de tiempo que supone implementar estos procedimientos.

La llegada de metodologías ágiles, tales como Scrum, permite abordar de forma ágil y rápida cada uno de los procesos que conforman la vida de un proyecto:

  • llevando a cabo desarrollos por etapas o sprints
  • realizando subidas a producción más cortas
  • incorporando herramientas de integración continua
  • fomentando la comunicación directa con el cliente para contrastar los resultados periódicamente

El objetivo principal no es otro que detectar errores en fases tempranas para rectificar en cualquier etapa previa a la subida a producción.

Pero sin lugar a duda, una de las mayores ventajas aportadas por las metodologías ágiles es la creación de productos de calidad que logren la completa satisfacción del usuario final. Esto ha dado visibilidad a la importante labor que realizan los responsables de calidad de soluciones software.

 

ENTONCES, ¿QUIÉN NECESITA QA?

A pesar de la visibilización de la que hablábamos, hoy en día, las personas que trabajamos en equipos de QA seguimos percibiendo un gran desconocimiento de nuestras responsabilidades por parte del resto de participantes de un proyecto. Nos encontramos a menudo con preguntas del tipo: ¿Qué es QA? ¿A qué te dedicas exactamente? ¿En qué fase del proyecto entra tu labor?

Es preciso saber, que la labor del QA no sólo tiene lugar tras la fase de desarrollo, como ocurría con las metodologías tradicionales. La figura de los responsables de calidad está presente durante todo el proceso, validando la aptitud del producto en cada una de las etapas.

 

¿QUÉ LABOR DESEMPEÑA UN EQUIPO DE QA?

Como decíamos, al contrario de lo que se piensa de forma generalizada, el equipo de QA no solo se limita a detectar fallos en el sistema. Su labor va mucho más allá: se analizan comportamientos, se anticipan defectos y se verifica que el funcionamiento y la usabilidad de una solución sean correctos.

El equipo de QA se sitúa entre el cliente y el equipo de desarrollo. Ayuda al primero a traducir sus requisitos y objetivos en pruebas, y al segundo a verificar cada una de sus acciones antes de que el producto llegue al usuario. De este modo, el equipo de QA aportará al cliente una visión real del trabajo realizado por el equipo y el estado en que se encuentra el proyecto en cada etapa.

El hecho de estar presente en todo el proceso, permitirá al QA optimizar y mejorar procedimientos ya existentes dentro del equipo, aportando soluciones que tengan como fin último aumentar la calidad de la solución.

Todo esto se traduce en la disminución considerable del tiempo de desarrollo, pudiendo reducir el número de revisiones y permitiendo validar el funcionamiento de la solución en cada una de las etapas.

Pero, ¿cuáles son los puntos fuertes del equipo de QA?

  • Su figura intermedia permite gestionar directamente el feedback del cliente en cada sprint. Permite corregir posibles errores y encontrar soluciones de forma ágil e inmediata.
  • Realiza todo el proceso de pruebas desde la perspectiva del usuario final. Aporta soluciones ante defectos de usabilidad o experiencia de usuario en fases tempranas.
  • Cuenta con un gran conocimiento funcional de la aplicación. Reduce las dudas que los desarrolladores suelen encontrar en la fase de desarrollo.
  • Su labor fomenta el análisis, la documentación y la recopilación de información que será de vital importancia en la fase de desarrollo.
  • Gracias a su manejo de herramientas de integración continua, podrá realizar la automatización de pruebas. Este proceso le llevará, en cualquier caso, a agilizar las pruebas de calidad y rendimiento de la solución desarrollada.

 

EL PROCESO DE PRUEBAS

El proceso de pruebas llevado a cabo por el equipo de QA a lo largo de un proyecto no solo darán lugar a un producto fiable y de calidad, sino que también permitirá establecer un control permanente sobre todos los procesos, evitando los problemas que suponen la detección de errores en fases más avanzadas.

Pero si por por algo se caracteriza el trabajo del equipo de QA es por la completa planificación de sus labores en cada una de las fases de un proyecto:

  1. Análisis
  2. Diseño y desarrollo
  3. Validación y entrega

 

FASE DE ANÁLISIS

En esta etapa verificaremos que tanto los objetivos como los requisitos planteados por el cliente sean correctos y precisos. Con ellos elaboramos un plan de pruebas.

Aquí nos serán de ayuda herramientas que nos permitan crear, ejecutar y dar reporte de los planes de prueba y su adecuación a los requisitos. Entre ellos destacan: TestRail, Zephyr para Jira, Teslink y Mantis.

Identificaremos también los casos de prueba que más tarde se convertirán en test automáticos. El objetivo es ejecutar pruebas de manera repetitiva y detectar posibles incidencias en etapas tempranas.

 

FASE DE DISEÑO Y DESARROLLO

En esta etapa el QA será el encargado de velar por el cumplimiento de cada uno de los requisitos, vigilando que la solución se adapta a la propuesta funcional y de diseño creada entre el equipo y el cliente.

Aquí entran en acción las herramientas de integración continua que permitirán a desarrolladores y QA trabajar en armonía:

  • Se automatizan de procesos de compilación
  • Se revisa del código generado
  • Y se realizan entregas continuas

Así se logra identificar fallos rápidamente. Una de las principales herramientas para hacerlo es Jenkins.

 

FASE DE VALIDACIÓN Y ENTREGA

En la fase final ejecutaremos el plan de pruebas, revisando que la solución ya desarrollada respeta los requisitos fijados y la entrega al cliente se hace en las condiciones adecuadas. Aquí podremos entregar al cliente reportes e informes de nuestro plan de pruebas.

Todos estos procedimientos se llevarán a cabo sprint tras sprint, formando parte importante del proceso iterativo que tanto defienden las metodologías ágiles.

 

 

EN RESUMEN

Decir que las metodologías ágiles han puesto en alza el valor de los equipos QA es innegable. No obstante, no hay que olvidar la responsabilidad que conlleva su participación en cada una de las fases de un proyecto.

Sus labores forman parte de un proceso continuo, que los convierte en los encargados finales de asegurar que el producto funcione correctamente y que logre superar las expectativas, de un cada vez más exigente, usuario final.

Después de todo esto, ya no hagas a un QA la pregunta de ¿a qué te dedicas? Sino ¿cuando empezamos a trabajar juntos?

 


La integración continua actual pasa por pipelines

En integración continua, como en la vida, hay que renovarse o morir y esto es lo que está pasando con los pipelines y herramientas como Jenkins.

Todos los que hemos utilizado Jenkins como herramienta de interacción continua, sabes lo difícil que resulta mantener los jobs si hay algún cambio a todos los que se tengan. Por ello, pedíamos a voces una herramienta que nos ayudase a gestionar estas actualizaciones de forma centralizada. De aquí es de donde surge la idea de pipelines.

Para empezar, tenemos que ponernos en contexto, ¿qué es eso de los pipelines?

 

PIPELINES: DEFINICIÓN

Un pipeline es una nueva forma de trabajar en el mundo devops en la integración continua. Utilizando pipeline y Jenkins, podemos definir el ciclo de vida completo de una aplicación (descargar código, compilar, test, desplegar, etc.) mediante código.

De esta forma, resulta mucho más sencillo replicar los diferentes pasos con distintas aplicaciones y gestionar mejor los cambios en cada paso.

Un ejemplo de pipeline integrado en herramientas como Jenkins podría ser:

Pipelines stageview - SDOS

 

 

 

¿POR QUÉ USAR PIPELINES?

Uno de los mayores beneficios de usar pipelines y Jenkins es poder hacer los jobs más configurables, fáciles de editar y más durables. También podemos utilizar entradas (input) humanos o esperar la aprobación de otro job para ejecutar el nuestro mediante pipelines.

Pero, además de estas ventajas, el principal valor diferencial de esta nueva estructura es que es versátil y extensible, y podemos crear pipelines para hacer un fork, un bucle, e incluso para ejecutar cosas en paralelo. Además podemos customizarlas todo lo que queramos mediante groovy.

 

MÁS VENTAJAS

Con pipeline podemos:

  • Definir de forma sencilla:
    • Parámetros de entrada
    • Variables de entorno y credenciales
    • Opciones como un timeout, retry o descartar builds
  • Enviar mensajes o hacer alguna acción post-build dependiendo del resultado de la ejecución del pipeline.
  • Saltar alguna fase dependiendo del entorno, la rama que ejecutemos, etc. mediante expresiones boleadas.

 

 

TIPOS DE PIPELINES

Hay dos tipos de pipeline: scripted y declarative.

Nosotros nos centraremos en el declarativo, por ser más novedoso y completo, pero te dejamos una tabla para que compares:

SCRIPTED PIPELINE DESCRIPTED PIPELINE
Modelo de programación imperativo Modelo de programación declarativo
Entorno de programación con todas las funciones Sintaxis más simple y pragmática para la creación de Jenkins pipeline
Gran flexibilidad y extensibilidad Limitado a lo que puede hacer un usuario
Se declara y ejecuta mediante nodos Se declara y ejecuta mediante el comando pipeline y los diferentes stages, stage, steps y step
No hay muchas limitaciones para usuarios expertos y requerimientos complejos La mejor opción para el desarrollo de estrategias de CI y CD con Pipelines
En común:
– Usan Groovy
– Pueden utilizar librerías compartidas
– Pueden utilizar script y shell
– Se guardan en un fichero .jenkinsfile

 

 

¿QUÉ ES UN PIPELINE DECLARATIVO?

Un pipeline declarativo es aquel que podemos crear, editar o configurar mediante una estructura definida que nos ayuda a entender y predecir los pasos del pipeline. Simplifica y da opciones a la sintaxis de los sub-sistemas de pipeline. Al igual que los descriptivos, los pipelines declarativos deben guardarse en un fichero Jenkinsfile para poder ser ejecutados luego por Jenkins.

Un ejemplo de un bloque con un pipeline declarativo podría ser:

pipeline {
    /* insert Declarative Pipeline here */
}

Las reglas básicas para construir un pipeline declarativo válido son las mismas que la sintaxis en groovy, con las siguientes excepciones a tener en cuenta:

  • El nivel más alto de un pipeline debe ser un bloque especificado como pipeline {}
  • No hay ; para separar bloques, cada bloque debe estar en su propia línea.
  • Los bloques sólo pueden contener secciones, directrices, pasos o asignación de bloques.

 

SINTAXIS BÁSICA DE UN PIPELINE DECLARATIVO

  • Pipeline {} Identificamos dónde empieza y termina el pipeline así como los pasos que tiene
  • Agent. Especificamos cuando se ejecuta el pipeline. Uno de los comandos más utilizados es any, para ejecutar el pipeline siempre y cuando haya un ejecutor libre en Jenkins.
  • Stages. Bloque donde se definen una serie de estados a realizar dentro del pipeline.
  • Stage. Bloque que define una serie de tareas realizadas dentro del pipeline, por ejemplo: Build. test, deploy, etc. Podemos utilizar varios plugins en Jenkins para visualizar el estado o el progreso de estos estados.
  • Steps. Son todos los pasos a realizar dentro de un stage. Podemos definir uno o varios pasos.
  • Step. Es una tarea simple dentro del pipeline. Fundamentalmente es un paso donde se le dice a Jenkins qué hacer en un momento específico o paso del proceso. Por ejemplo, para ejecutar un comando en shell podemos tener un paso en el que tengamos la línea sh “ls” para mostrar el listado de ficheros de una carpeta.

Un ejemplo de un pipeline declarativo podría ser:

pipeline {
	agent any
	stages {
    	stage('Build') {
        	steps {
            	sh 'make'
        	}
    	}
    	stage('Test'){
        	steps {
            	sh 'make check'
            	junit 'reports/**/*.xml'
        	}
    	}
    	stage('Deploy') {
        	steps {
            	sh 'make publish'
        	}
    	}
	}
}

 

 

¿QUÉ ACCIONES PODEMOS HACER EN UN PIPELINE?

Jenkins nos hace bastante fácil el desarrollo de pipelines. Si estamos acostumbrados a utilizar plugins para nuestra integración continua podremos ver en la mayoría de los changelogs de los plugins que utilizamos que ya soportan pipelines.

Si queremos asegurarnos, tenemos que tener un job con pipeline instalado y hacer clic en la sección de pipeline syntax. Ahí podremos ver todos los plugins que tenemos instalados y si tienen o no un script de pipeline asociado que podamos utilizar.

Pipelines syntax - SDOS

 

Pipelines syntax page - SDOS

 

 

CREACIÓN DE UN JOB CON PIPELINES

Para poder utilizar pipeline debemos instalar varios plugins en Jenkins:

Una vez que los tengamos instalados debemos crear un job tipo pipeline:

Pipelines creation - SDOS

 

A continuación tenemos que añadir la configuración siguiente:

  • Parámetros necesarios:
    • Url del repositorio de Git
    • Rama donde tengamos el código
  • En la sección de pipelines:
    • Url del repositorio de Git donde está el pipeline
    • Rama donde tengamos el pipeline
    • Nombre del fichero .jenkinsfile donde tenemos el pipeline definido

Pipelines configuration - SDOS

 

 

¿CÓMO UTILIZAMOS EL PIPELINE EN QA?

Actualmente en nuestro departamento de QA estamos utilizando los pipelines para realizar la integración continua de nuestros test automáticos con Appium.

Primero, y antes de empezar, necesitamos una serie de parámetros de entrada específicos para poder ejecutar los test, estos son:

Pipelines parameters - SDOS

 

Una vez que tenemos estos parámetros configurados por job, tenemos que ver los pasos que podemos hacer. Es decir, ¿qué pasos tenemos configurados en el pipeline con Appium para pruebas móviles en Android?

  • Configuración inicial. Definición y seteo de variables globales.
  • Descarga de código. Descargamos el código del repositorio mediante una URL y rama.
  • Ejecutar ADB Server. Ejecutaremos el ADB para lanzar el emulador.
  • Lanzar el emulador. Lanzaremos el emulador que hemos configurado desde los parámetros.
  • Appium Test. Ejecutaremos los test de appium.
  • Sonarqube. Realizamos el análisis de Sonarqube a nuestro código.
  • Post-build actions. Enviamos un e-mail con los datos de la ejecución así como una notificación al slack.

 

 

¿CÓMO EJECUTAR UN JOB EN JENKINS CON PIPELINES?

Una vez que tenemos nuestro job configurado con el pipeline, simplemente tenemos que ejecutarlo para ver el resultado de las diferentes fases:

Pipelines ejecution - SDOS

 

 

CONSULTA NUESTRO CÓDIGO DE PIPELINE

Te dejamos un enlace a nuestro repositorio de GitHub. Esperamos que te ayude agilizar los test de Appium y que el mantenimiento de tus scripts de automatización de pruebas sea coser y cantar.

 

 


Nuestro resumen del Sonarsource: Madrid City Tour 2017

El miércoles pasado cogimos un AVE bien temprano para llegar a Madrid, en mitad de la huelga de taxis, al evento de Sonarsource: Madrid City Tour 2017, Spain que se celebraba en el hotel NH Madrid Nacional.

Empezamos con el registro donde conseguimos nuestra acreditación y alguno de esos detallitos que tanto nos gustan…

Acreditación Sonarsource Madrid

 

Una vez que todos tomamos asiento, el CEO de Sonarsource, Olivier Gaudin (@gaudol) nos dio la bienvenida e hizo una pequeña introducción de lo que veríamos en el evento, además de señalar que una de las ambiciones más importantes de Sonarsource como compañía es construir una de las mejores soluciones para la revisión de código del mercado. Y eso nos entusiasma.

También señaló la importancia de analizar el código periódicamente con Sonar para mejorar la seguridad (reducir vulnerabilidades de nuestro código), la fiabilidad (reducir bugs) y la mantenibilidad (reducir deuda técnica).

 

Nuevos productos en la Suite de Sonar

Fabrice Bellingard (@bellingard), Product Manager de SonarCloud, fue el encargado de mostrar todos los productos de la suite de Sonar (SonarLint, Sonarqube, SonarJava, SonarC#, SonarWeb, SonarPHP, SonarTS, etc.) y de anunciar uno de sus nuevos productos: SonarCloud.

Suite productos Sonar - Sonarsource Madrid - SDOS

 

SonarCloud es una plataforma de análisis de código continuo y online con la que puedes analizar tus proyectos y ver los resultados online en la nube.

Todas estas herramientas que nos ofrece Sonar nos ayudan a crear lo que llamaron “Continuous Code Quality” que incluye: Continuous Integration, Continuous Deployment, Operate, Continuous Delivery.

 

Demo de Git + Jenkins + SonarCloud

Llegó entonces la espectacular demo con SonarCloud, también de manos de Fabrice Bellingard.

¿En qué consistió esta demo? Partiendo de un repositorio de Git con un código sin fallos previamente analizado por Sonarqube, un Job de Jenkins (con Pipelines) se lanzaba mediante un webhook configurado en Git cuando encontraba un nuevo Pull Request en el repositorio. Este Job de Jenkins estaba asociado a un JenkinsFile que contenía un Step para analizar el código del PR con Sonarqube. Los resultados del análisis del nuevo código se mostraban en SonarCloud.

Demo - Sonarsource Madrid - SDOS

 

La demostración tuvo como finalidad mejorar la calidad de cada PR y comprobarla antes de mergear el código con la rama Máster.

 

Nueva métrica: complejidad cognitiva

Tibor Blenessy (@saberduck), uno de los desarrolladores de Sonarqube, nos presentó una nueva métrica en Sonar: la complejidad cognitiva.

La complejidad cognitiva es una nueva forma de medir la entendibilidad del código. Como apuntó Tibor citando a Martin Fowler: “Cualquier tonto puede código que un ordenador entienda. Los buenos programadores son aquellos que escriben código que los humanos puedan entender”.

Surgió entonces una pregunta: ¿en qué se diferencian entonces la complejidad ciclomática y la complejidad cognitiva para Sonar? La complejidad ciclomática mide la testeabilidad del código, mientras que la complejidad cognitiva mide el entendimiento del código, además de promover hacer un código mejor.

 

Cómo escribir código limpio

Otra de las partes destacadas del evento fue la intervención de la empresa Excentia, partner de Sonar, que nos habló sobre cómo escribir código limpio, dándonos una receta para ello:

  1. Cuando codifiques, arregla los errores antes de que existan con SonarLint
  2. Cuando hagas un push, analiza cada Pull Request con Sonarqube
  3. Cuando hagas una subida, comprueba el Quality Gate del nuevo código con Sonarqube y Jenkins
  4. Cuando gestiones, echa un vistazo al estado de todos tus proyecto con Sonarsource Enterprise Edition

Limpiar código - Sonarsource Madrid - SDOS

 

Recurrieron además a una gráfica para todos conocida, la del coste de arreglar un defecto en las diferentes etapas del ciclo de vida software.

Coste de errores - Sonarsource Madrid - SDOS

 

Nueva Versión de Sonar en noviembre

Para finalizar el evento, Olivier Gaudin anunció la que fue una de las noticias más importantes del evento: la presentación de una nueva versión estable (LTS: Long Time Support) de Sonar en el mes de noviembre. Esta nueva versión contará con muchísimas nuevas features, incluyendo funciones comerciales como gran disponibilidad, gestión de ramas y notificaciones de SonarLint.

También se habló de las diferentes soluciones que nos ofrece Sonar, así como de las ventajas y desventajas de cada una.

 

Nuestras reflexiones

Después de todas estas exposiciones tan interesantes, tuvimos una comida en la misma sala en la que pudimos, en un ambiente más relajado, preguntar todas las dudas y hablar con los ponentes.

Nos volvimos a Sevilla con muy buena sensación: lo que vimos allí está en muy en línea con el trabajo diario en nuestro departamento de QA. Nos ha servido también para conocer algunas herramientas que ya hoy, sólo unos días después del evento, hemos incorporado a nuestro trabajo.

En resumidas cuentas, Sonarsource Madrid City Tour nos ha servido para constatar que hay algo que estamos haciendo bien en QA. Estamos en el camino a seguir. Queremos y sabemos que vamos a llegar muy lejos.


Save the date! 26/09: meetup QA

El próximo martes 26 de septiembre, nuestra oficina de Sevilla alojará una Meetup sobre calidad en el desarrollo de software. Estefanía Fernández, responsable del área QA en SDOS, será la encargada de compartir sus conocimientos sobre SonarQube y Docker.

Siguiendo la dinámica habitual de este tipo de encuentros, el enfoque será participación abierta y práctico, con ejemplos reales del uso de estas herramientas que serán muy útiles a la hora de utilizarlas.

En SDOS estamos entusiasmados con acoger a la comunidad QA de Sevilla para este encuentro. Un comunidad que, aunque de creación relativamente reciente, cuenta ya con unos 150 miembros y está apostando muy fuerte por ser punta de lanza del sector.

Si te interesa, ¡ya sabes! Te esperamos en nuestra oficina, el martes 26 de septiembre a las 19:00 horas. La inscripción se llevará a cabo desde la plataforma Meetup. ¡Date prisa que el aforo es limitado!


Uso de cookies

Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continúas navegando estas dando tu consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pincha el enlace para obtener más información.

ACEPTAR
Aviso de cookies