Pruebas como validación de la ingeniería del software

Excelente texto donde se pone de manifiesto la verdadera importancia y repercusión de las pruebas de software. Se puede debatir muy mucho sobre la similitud o no de la ingeniería del software contra otras ingenierías, pero lo que si debemos tener claro es que por su propia naturaleza, los métodos y procesos aplicados a un desarrollo software distan en gran medida de los empleados en una ingeniería clásica.

 Durante los últimos miles de años, los ingenieros han desarrollado las matemáticas y física que usan para una solución estructural sin tener que construirlo para ver lo que hace.

Graficas para JMeter – Loadsophia

En general, cualquier plan de pruebas contemplará al menos tres hitos o fases intermedias claramente diferenciadas. Una fase inicial de preparación del entorno necesario, programación de los scripts, configuración de las herramientas necesarias, etc. El siguiente punto será la propia ejecución de las pruebas siguiendo el plan diseñado y finalmente, habrá una fase de análisis y reporte de datos, en la cual se deberá analizar todos los datos obtenidos durante las ejecuciones anteriores y presentarlos de manera que aporten la mayor información posible.

Para esta fase final de análisis y reporte de resultados se pueden utilizar multitud de herramientas y formatos. Por la naturaleza de este tipo de pruebas, quizás la manera más intuitiva y fácil de analizar los resultados sea dibujando estos gráficamente. En pruebas de rendimiento muchas veces se obtiene más información analizando la tendencia y progresión del test que conociendo un valor concreto. Para ello, Loadsophia nos ofrece una manera fácil, gratuita y cómoda de obtener buenas gráficas.

 ¿Qué es loadosophia?

Básicamente un servicio de análisis de resultados de pruebas de rendimiento y generación de gráficas. A partir de los datos extraidos de herramientas como Apache JMeter o Apache Benchmark podremos obtener una serie de gráficas útiles para nuestro informe final.

 ¿Cómo funciona?

Modularizar con JMeter

En esto del desarrollo, es por todo conocidos que dividir, importar, reutilizar, … son acciones que nos reportarán un gran beneficio en el futuro, haciendo que nuestro código sea mucho más simple, se mantenga de una manera más sencilla, se eviten inter-dependencias, etc. Trabajando con JMeter en proyectos de cierto tamaño, es normal que el plan de pruebas de rendimiento empiece a crecer a poco que diseñes unos cuantos workflows o tengas numerosas peticiones a tu sistema.

En estos casos, es muy útil identificar aquellos escenarios genéricos que utilices en múltiples sitios, bien sea configuración para distintos escenarios, un conjunto de peticiones que siempre deben hacerse conjuntamente y en el mismo orden, o cualquier otro que consideres reutilizable.  Una vez identificados estos casos, podemos crear un pequeño repositorio de funciones que posteriormente podrás incluir en cualquier punto de tu plan de pruebas, así, si algo cambia, solo tendrás que tocar en un sitio, reduciendo el trabajo y sobre todo la posibilidad de cometer errores.

Cómo modularizar en JMeter

Haremos uso de un par de controladores. El primero de ellos, “Controlador simple”, nos servirá para agrupar todos aquellos recursos que queramos reutilizar, este será nuestro pequeño repositorio. Solo añade un controlador simple, desactiva su ejecución y bajo el, añade los módulos que quieras tener disponibles en el resto del plan de pruebas, utilizando también controladores simples

Una vez tengamos nuestro repositorio creado, cuando necesitemos incluir ese “trozo” de código en nuestro plan de pruebas, bastará con añadir un “Controlador de módulo” y seleccionar el módulo que queramos incluir en ese punto, quedando el plan de pruebas como sigue.

Además, tal y como se hace para el resto de controladores, si necesitas añadir alguna particularidad en un determidado punto, bastará con añadir como hijo del controlador aquel elemento que necesites, de modo que sus valores sobrescribirán a los definidos en el módulo importado. Por ejemplo, en la imagen anterior podemos ver como se ha añadido un elemento de configuración de cabecera HTTP, cuyos datos sobrescribirán a los definidos en el módulo inicial.

Con estos pequeños cambios, conseguiremos tener un plan de pruebas mucho más simple y facil de mantener.

Testing – Síndrome del queso suizo

Echando un vistazo a la programación del próximo Swiss Testing Day (http://www.swisstestingday.ch/) me he encontrado con una conferencia sobre un concepto y conocido, pero no por su nombre «oficial». Se trata del, Síndrome del queso suizo (The Swiss Cheese Syndrome)

En testing, es conocido que un sistema no puede ser probado al 100%. Es muy difícil, por no decir imposible conseguir reproducir todas las casuísticas de uso posibles, por ello, siempre hay huecos (agujeros) que nunca han sido testeados. Que no se vean a simple vista no quiere decir que no existan, o que no pueda darse un caso en el que te encuentres con uno de ellos, de ahí la similitud con un queso suizo.

Evidentemente, a más agujeros, menor calidad de sistema …

SoapUI – guardar respuesta en un fichero

Un pequeño script en Groovy para guardar las respuestas de una petición en un fichero.

def myOutFile = "DIRECTORY/FILE"
def response = context.expand( '${NAME_REQUEST#Response}' )
def f = new File(myOutFile)
f.write(response, "UTF-8")

 

Pruebas de rendimiento, workflows

Leia en Google Testing Blog “If you can’t build a web service that scales, testing is not your biggest problem!”  Pero, para definir la vía de escalada a seguir, debemos conocer cómo se comporta el sistema bajo una gran carga de trabajo.

La definición del plan de pruebas deberá hacerse con el objetivo de simular del modo más exacto posible el uso real del sistema bajo distintas situaciones. Para ello se definen workflows, basados en el comportamiento habitual de los usuarios frente a la aplicación. Los datos para su definición pueden ser obtenidos mediante sesiones de interacción, del análisis de log, gestión de auditoría, etc. Estos flujos serán las guías a seguir para el diseño de los scripts, planes de trabajo, etc, del plan de pruebas.

Para diseñar un detallado plan de pruebas de rendimiento, existen numerosos conceptos y variables con las que podemos jugar para conseguir el workflow requerido. Entre ellos, destacan los siguientes como los más importantes:

Actitudes de un QA

Como se suele decir, hay cosas que no se aprenden en la escuela, y en el mundo del testing, hay bastantes de esas. No son metodologías, no son conocimientos de software específicos, son actitud, compromiso, y buen hacer.

• Escribe, escribe, escribe: Da igual dónde lo hagas, con papel y lápiz, en un diario de trabajo, en un gestor de notas, pero mantén tus apuntes escritos. De este modo no dudarás en cualquier momento acerca de una decisión del pasado, también te servirá para afianzar la información en tu cabeza mientras lo pasas al papel.

• Automatiza aquello que hagas más de dos veces: instalaciones en el entorno de test, generación de informes de métricas, reglas en el cliente de correo, optimización de búsquedas, … Por pequeña que sea la ganancia en tiempo, multiplícala por cada vez que realizas dicha tarea y obtendrás un practico y útil tiempo al final del día. Haz que las máquinas trabajen por ti!

• 360º de conocimiento: debes conocer todos los aspectos del producto y tener una visión global del mismo, esto hará que tus pruebas estén enfocadas de mejor modo. Es una de las ventajas de la gente quality, no estás atado a un módulo específico, sino que conoces cual es la interacción con el resto del producto, cual es su objetivo, qué implicaciones puede tener un pequeño cambio en él, cuales son los posibles cuellos de botella, integración con terceros, etc, etc

Laboratorio de pruebas de Internet Explorer

Son muchos los blog que hablan del lanzamiento de Windows 8, de fechas, de nuevas funcionalidades, utilización de Metro, etc, etc, pero cual si no el propio blog de desarrollo de Windows 8 para conocer más sobre cómo trabajan los chicos de Redmon. Y es a través de este blog donde descubrimos el laboratorio de pruebas que han montado para testear la nueva versión de Internet Explorer.

Su objetivo es claro, “desarrollar el navegador más rápido del mundo” y para eso hay que trabajar duro, sobre todo conociendo la fuerte competencia que Chrome le está aplicando.

ContiPerf – test de rendimiento

ContiPerf es una librería para enfocada a pruebas de rendimiento utilizando test creados bajo JUnit4. Diseñada por Volker Bergmann, artífice también algunas otras herramientas: The Feed4 Tools ó Mad For DB. Se basa en la misma filosofía de anotaciones que se utiliza en JUnit4 para gestionar los distintos test. Algunas de las funciones que ofrece son:

• Repetición de test por tiempo o por número de ejecuciones
• Assert para tiempos de respuesta (máximo, media, percentil, …)
• Informes HTML y CSV de los resultados obtenidos
• Integración con Maven

Una vez creados los test unitarios con JUnit, podemos reutilizar estos para ampliar la calidad del testing añadiendo pruebas de rendimiento. No solo necesitamos que un test se ejecute correctamente, sino que este debería cumplir unos criterios de rendimiento (tiempo de respuesta, ejecuciones en paralelo sin bloqueos,…). Estos son divididos por ContiPerf según sean:

Excepciones – usuarios finales

En el desarrollo de software, es habitual enfocarse en la parte técnica del diseño, implementación, integración,… y perder el foco del objetivo final que debe cumplir el proyecto y a quién va dirigido el mismo. Esto hace que los desarrollos sean robustos internamente, que la comunicación entre distintos módulos sea eficiente y se controlen las posibles excepciones que puedan surgir, pero qué ocurre cuando se lanza una primera beta a usuarios reales?