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

jmeter_1

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.

jmeter_2

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.

Analizando el campo de batalla. Navegadores.

browser_fightDurante el desarrollo de una aplicación web, hay multitud de cuestiones que debemos tener presentes para que el resultado de la misma sea el mejor posible. Entre requisitos de cliente, de infraestructura, de usabilidad, etc, debe aparecer definido el target que va hacer uso de nuestra aplicación. Este target deberá ser usado para llevar a cabo un análisis acerca del uso y características de los navegadores y dispositivos a los que habrá que prestar mayor atención.

La primera idea que se nos viene a la mente es buscar estadísticas del uso de distintos navegadores para así priorizar nuestros esfuerzos, y dar la mejor respuesta a aquellos más utilizados. Como primera aproximación está bien, pero … hay cosas que puntalizar:

Sigue leyendo

¿Confías en tu equipo?

Quizás el nexo de unión entre personas más difícil de crear y más fácil de romper. Durante la evolución del ser humano, la confianza en los demás y en sí mismo ha sido un requisito imprescindible para su supervivencia. Sinceridad, credibilidad, honestidad son aspectos que promocionan esta relación de confianza.

Si nos centramos en cómo la confianza puede afectar a nuestro propio trabajo así como al funcionamiento de tu empresa podemos abordarla desde distintas perspectivas:

Confianza en uno mismo

Debemos ser honestos y conocer nuestras capacidades, nuestros límites. Nadie puede juzgar mejor que nosotros mismos si el trabajo que estamos desarrollando es el mejor que podemos hacer. Solo con nuestras acciones podremos obtener la confianza de los demás en nuestro trabajo. Ser persistente, disciplinar y conocer el objetivo a cumplir contribuye a aumentar la confianza en uno mismo.

Confianza en el equipo

Sigue leyendo

Optimizando JMeter

jmeter-logo-g2khostingEn el diseño de un plan de pruebas de rendimiento, uno de los puntos a los que hay que prestarle gran atención es al diseño del sistema encargado de la generación del volumen de carga necesario. Antes de llegar a acciones más costosas y elaboradas como puede ser utilizar servicios en la nube, distribuir un grid de nodos, … podemos optimizar los recursos disponibles para obtener el máximo partido de ellos.

Una de las herramientas más utilizadas cuando trabajamos con pruebas de rendimiento es Apache JMeter. Código abierto, muy extendido entre los equipos de testing y respaldado por una gran comunidad. Los problemas más habituales comentados en los foros sobre el uso de esta herramienta suelen estar relacionados con el uso de memoria y CPU, los cuales se pueden reducir en gran parte siguiendo una serie de recomendaciones.

Es fácil ver que todos los recursos utilizados en el pre y post-procesado de las peticiones, reduce los recursos disponibles para las necesidades reales, por lo tanto, todo lo que puedas hacer antes/después, hazlo. Es más eficiente cargar un fichero de datos que tener que calcular estos durante la ejecución del plan. Otro punto a tener en cuenta son los listeners. Deshabilitalos todos, no los necesitas durante las pruebas de carga. Ya nos encargaremos de formatear los resultados una vez finalizado el test.

¿Qué más podemos mejorar?

Sigue leyendo

Fechas en Oracle

Una tabla bastante útil cuando trabajas con fechas en Oracle.

Formato codigo descripción
YEAR Año
YYYY Año - 4 dígitos
MM Mes (01-12; JAN = 01).
MON Nombre del mes abreviado (JAN,FEB,MAY,...)
MONTH Nombre el mes, completado con espacios hasta 9 caracteres
D Día de la semana (1-7).
DAY Nombre del día
DD Día del mes  (1-31).
DDD Día del año (1-366).
DY Nombre del día abreviado
HH Hora del día (1-12).
HH12 Hora del día (1-12).
HH24 Hora del día (0-23).
MI Minuto (0-59).
SS Segundo (0-59).
SSSSS Segundos pasados media noche  (0-86399).

De este modo, haríamos consultas como:

SELECT * FROM mytable WHERE table_date >= 
TO_DATE('29-04-2013 19:00','DD-MM-YYYY HH24:MI');
SELECT to_date('2004/12/14 4:29 PM', 'YYYY/MM/DD HH:MI PM' )
FROM dual;

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 …

Sigue leyendo