La Certificación ISTQB® Advanced Level Test Automation Engineer

Desde el año 2016, la ISTQB ha ampliado su oferta con la certificación de nivel avanzado Test Automation Engineer. 

En el contexto actual del testing, la automatización ha tomado un peso muy elevado en las actividades de testing y muchos profesionales intentan obtener conocimientos que les permita desempeñar esta actividad de manera profesional.

Esta certificación se vuelve muy interesante para todos aquellos que estamos involucrados en actividades de automatización y también en otros tipos de pruebas como son las de rendimiento. Por esta razón vamos a dedicar una entrada de QA Técnico a resolver las posibles dudas de los interesados.



¿A quién está dirigido? 
¿Necesito tener algún requisito previo?
¿Necesito algún conocimiento de automatización?
¿Qué vamos a aprender en el curso?
¿Qué NO debemos esperar del curso?
¿Cómo es el curso?
¿Cómo es el examen?
¿Como puedo obtener la certificación ISTQB ® Advanced Level Test Automation Engineer?

   

JMeter . Revista de Actualidad Febrero 2017

Bienvenidos lectores habituales de esta sección al mundo de JMeter en español. Hoy tras otro periodo de inactividad en las actualizaciones, abrimos un artículo para comentar algunas de las mejoras que hemos visto en la nueva versión con la que estamos trabajando JMeter v 3.0

¡Comenzamos!

Algunos de los plugins que vamos a tratar aquí, han sido desarrollados por la empresa especializada en Cloud, BlazeMeter. Estos añadidos han sido cedidos a la comunidad de usuarios por esta empresa, por lo que son accesibles y disponibles con las mismas características que otros plugins ya desarrollados.

Concurrency Thread Group

Este plugin permite realizar escalados de carga de una forma más flexible que otros ya existentes.

Concurrency Thread Group

Como podemos observar, permite definir de una manera bastante definida

• concurrencia de hilos de ejecución (Target Concurrency)
• tiempo en el que se desea alcanzar esa concurrencia (Ramp up time)
• número de hilos que se inyectarán en cada escalón de la rampa de entrada (Ramp-up step count)
• Tiempo de ejecución a plena carga de la prueba (Hold target Rate time)

  Aparte ,podemos especificar en qué medida de tiempo queremos planificar : minutos o segundos , así  como un número máximo de iteraciones por hilo de ejecución.

Esto evidentemente es muy útil cuando tenemos limitaciones asociadas a los datos: por ejemplo un juego de identificadores o cuentas que no se pueden reutilizar en distintas ejecuciones o iteraciones.

Pasando datos entre threads. Sincronización

Una de las funcionalidades que los usuarios de JMeter han estado pidiendo en “wish-lists” o en los TODO ha sido la posibilidad de pasar datos entre threads. Para ello se ha desarrollado el concepto de  comunicación entre hilos , usando un mecanismo de colas FIFO (First IN, First OUT).

El concepto es bien simple, un paso de ejecucion de un thread captura o genera un dato que se quiere pasar como entrada en la ejecución de otro hilo.

Un modo habitual para hacerlo hasta ahora sería una variable . Sin embargo, esto tiene el problema de que dicha variable se sobreescribiria en cada iteración (a menos que se dispusiera de una estructura de control compleja) o bien volcándola a un fichero para usarlo como entrada de variables.

Como cualquiera que haya usado esta herramienta u otras similares, sabrá que le generación de datos de manera dinámica es compleja y, para el caso de volcado a ficheros, no es muy recomendable realizarla en la misma ejecución en la que se están generando.

Desarrollo 

Se ha desarrollado una serie de funciones a llamar desde muestreadores asociados a un hilo que pueden volcar los datos obtenidos durante la ejecución y volcarlos a una cola desde la que pueden acceder  otros hilos.

Las funciones desarrolladas son las siguientes: fifoPut, fifoGet, fifoPop, fifoSize.

El uso de cada una se explicita en el siguiente cuadro

Función	Parámetros	Descripción
fifoPut	COLA_ENTRADA, STRING_ENTRADA	Introduce el valor de la cadena pasada como parámetro en la cola de entrada definida
fifoPop	COLA_ENTRADA,STRING_SALIDA	Toma el primer valor de la cola (el más antiguo) y lo vuelca en el string de salida .Si la cola está vacía espera durante un tiempo especificado en un parámetro kg.apc.jmeter.functions.FifoTimeout  Hasta que haya un valor
fifoGet	COLA_ENTRADA,STRING_SALIDA	Toma el primer valor de la cola (el más antiguo) y lo vuelca en el string de salida sin eliminarlo de la cola. Si la cola no tiene elementos, devuelve una cadena vacía.
fifoSize	COLA_ENTRADA,STRING_SALIDA	Devuelve en la cadena STRING_SALIDA pasada como parámetro el número de elementos presentes en la cola

Ejemplos de uso:

${__fifoPut(COLA,${VALOR})}<-   Vuelca en la cola cookies el valor contenido en la variable                                                                      ${VALOR}

Una secuencia de trabajo sería

1. crear un extractor de expresiones regulares que capture el valor a pasar asíncronamente entre hilos en una variable ${VALOR} 
   
2. Introducir el valor en la cola FIFO mediante un fifoPut(COLA,${VALOR}))
   
3. Invocar mediante una secuencia de control a la cola FIFO asegurándonos que no se encuentra vacia
   
4. Retirar o leer el valor de la cola con un fifoPop(..) o fifoGet(..)

Notas acerca de la persistencia de los valores.

Los valores contenidos en las colas FIFO se guardan entre ejecuciones de un escenario dependiendo del modo de invocación de las funciones

• Si se han usado en Preprocesadores y PostProcesadores , se borran automáticamente en cada ejecución 

• Si se han usado en otros muestreadores, guardan los valores de las colas hasta que se vuelve a invocar una operación fifoPut sobre la cola ya existente. Si se quieren conservar valores, es mejor que los nombres de las colas varíen entre ejecuciones (por ejemplo, haciendo referencia a la fecha)

Debido a la extensión del artículo, publicaremos más análisis de los plugins y funciones relevantes en una continuación del mismo. ¡Esperamos que no haga falta que nos salgan canas a todos!

Como siempre, quedamos a la espera de vuestros comentarios y apreciaciones.

Usando JMeter y OWAS ZAP en integración contínua

Introducción

Seguramente alguien nos echaba de menos , así que hemos aprovechado uno de esos ratos libres que nos deja el trabajo y aprovechamos para dar unas pequeñas nociones acerca de la sinergia entre herramentas. En este caso en el mundo de la integración continúa y la seguridad ..usando un script de JMeter.

Objetivos.

La idea de este artículo es explicar uina manera de generar informes de seguridad con una herramienta integrable con un entorno de integración contínua como  Jenkins, realizando navegaciones que puedan ser analizadas por dicha herramienta y generando un informe que pueda ser evaluado cuando se haga una nueva versión o implementación de una aplicación

Para ello vamos a trabajar usando las siguiente utilidades

• Herramienta de seguridad OWASP Zap. Es una evolución de Paros Proxy que es reconocida en el entorno de integración contínua Jenkins, bien como plugin o como herramienta que genera acciones.
• HTML Report. Es un plugin de Jenkins que permite publicar documentos en foprmato HTML o XML  
• JMeter. La herramienta para pruebas de calidad, aunque centradas en el rendimiento, también usada para validaciones funcionales y demás

OWAS Zap habilita un puerto de escucha ,actuando como un proxy que permite analizar el tráfico que ciercula por él.

La herramienta realiza una serie de análisis de seguridad tanto pasivos como activos (modo spider, inyección SQL, cross-site scripting..etc) y permite generar un informe de seguridad con los principales fallos detectados.

Requerimientos

1º) Se ha instalado el plug-in de OWAS ZAP Zapproxy

2º) Se prepara un script JMX de Jmeter en el que se define como proxy el definido por el OWAS ZAP Proxy (por defecto ,localhost puerto 9090)

3º) Se crea una secuencia de tareas de este modo

         i.            

             Tarea inicial de arranque del OWAS Zaproxy en la que quede en ejecución en estado de escucha en el puerto, almacenando los resultados de dicha escucha en una sesión (parámetro –session de la invocación por línea de comandos)

Incluir tarea de OWAS ZAP: Uso de línea de comandos shelll

       ii.            Se lanza una instancia de JMeter en la que haga una navegación (con un usuario y una sola iteración a priori bastaría, reutilizando alguno de los casos de las pruebas de rendimiento)

Incluir tarea de ejecución JMeter. Uso de línea de comandos windows

      iii.            Se lanza a continuación una parada controlada del OWAS Zapproxy para que consolide lo monitorizado en la sesión definida como repositorio

Tarea detención OWAS ZAPproxy: Ejecutando comandos shell

     iv.            Se lanza de nuevo el OWAS Zapproxy en modo “generación de informes” , indicando como salida (parámetro de invocación “-last_scan_report) un fichero .html que se genera automáticamente con los resultados del análisis efectuado por la herramienta de seguridad.

Tarea creación informe tras navegación. Ejecutar línea de comandos shell

       v.            Por último , en la siguiente sección “Acciones a ejecutar después” del menú de Jenkins correspondiente a la tarea de seguridad, se puede incluir el plug-in HTML Report, que permite mostrar un enlace directo desde la tarea al fichero generado

Acción post ejecución tarea seguridad: Plugin HTML Report

El informe queda accesible desde el menú del marco izquierdo

O bien desde el propio pantalla de “Estado del proyecto” ,accediendo por el enlace de HTML Report o navegando en el directorio del “Espacio de Trabajo” (WORKSPACE)

Esperamos que os sea útil esta información. Ya sabeis, comentarios, dudas y demás serán bien recibidos.

JMeter III..y pico.Depurando Scripts avanzado.

En este artículo vamos a completar algunas técnicas que se usan habitualmente en las pruebas con esta herramienta, porque tal y como dicen , “la creación de código es un proceso retroalimentado, dado que siempre se pueden encontrar errores”.

Depurando un script de JMeter. Debug Sampler.

Muchas veces nos encontramos con la necesidad de saber cómo varian los valores de las variables, ya sean parametrizadas o correlacionadas. Para conocer el valor de las mismas , se dispone de un elemento de postprocesado sumamente útil : El debug Post-processor.

Este elemento sigue las normas de ámbito del resto de elementos de un plan de trabajo o script de JMeter, es decir, recoge información acerca de las peticiones que se encuentren por encima del mismo en la estructura de árbol del script.

Debug PostProcessor. Habilitación de visualización de variables

Como se puede ver, el elemento post-procesador de Debug, permite seleccionar

• Valores del entorno

JMeter properties

Sampler properties

System properties

• Valores relacionados con la prueba (¡lo que nos interesa! )

                     JMeter Properties

   

Big Data II.Ecosistema de Hadoop.

Introducción.

Como ya dijimos en el anterior artículo, Hadoop actúa sobre los datos contenidos en su HDFS mediante las operaciones MapReduce. Ahora voy a contaros una cosa. Antes de empezar a tratar sobre dichos datos debe volcarlos a  ficheros y para ellos , requiere de herramientas externas para realizar lo que se llama E.T.L. (Extraction , Transformation ,Loading).

Extraction: Extrae datos de diferentes origenes. Si se dispone de conectores o drivers específicos sobre BBDD Hadoop y su ecosistema admite la conexión a fuentes de datos via ODBC o similares para el proceso.

Transformation: Valida, normaliza los datos para evitar errores

Loading: Vuelca los datos al HDFS (o a otros sistemas de BigData).

Para ello se introduce aquí el concepto de “ecosistema de hadoop”, es decir aquellas herramientas y utilidades que complementan a Hadoop para realizar las tareas de procesamiento masivo de datos.

Hadoop es el “motor” del vehículo. Las herramientas de ecosistema se pueden ejemplarizar como los neumáticos, la suspensión,..etc

Para realizar dichas operaciones ETL tenemos herramientas como scoop (http://sqoop.apache.org/), que permite la transferencia de datos de E.T.L.  de manera eficiente e integrada con Hadoop. Está también desarrollada por la Apache Software Foundation. Aquí hago un paréntesis para indicar que Hadoop es capaz de tratar tanto con datos estructurados (las clásicas tablas de BBDD organizadas en columnas ) como con no estructurados (XML).

Flujo de Scoop y Hadoop.

Automatización de Pruebas: ROI Cualitativo.

ROI Cuantitativo vs ROI Cualitativo

En la anterior entrada, vimos como podíamos valorar y calcular el ROI en un proyecto de automatización de manera cuantitativa. El objetivo principal, era calcular a partir de qué momento la inversión realizada en la automatización comenzaba a ser rentable en términos económicos. Sin embargo, más allá de los fríos números, la automatización también presenta una beneficios cualitativos que aportan valores añadidos difíciles de cuantificar. 

ROI & PAYBACK de la Automatización de Pruebas

ROI vs. PAYBACK

Cuando se piensa en la automatización como posible solución en un proyecto de testing, se hace necesario un estudio de viabilidad que nos indique qué rentabilidad vamos a obtener, y cuándo podremos considerar que estamos amortizando la inversión realizada.

En general, este estudio de viabilidad o no se realiza, o se realiza de manera muy general, o incluso se hace partiendo de premisas incorrectas o falsos mitos sobre la automatización. Veamos en primer lugar dos conceptos a tener en cuenta:

• ROI (Retorno de la inversión): Es el beneficio que obtenemos de la automatización puede ser calculada de diferentes formas:
• % de beneficio obtenido: según la siguiente formula (Beneficio -Inversión)/Inversión. No obstante, también es posible encontrar el ROI de la automatización expresado directamente en horas de trabajo.
• Horas totales de ejecución manual ahorradas
• Costo total de ejecución manual ahorrado

• PAYBACK: Indica el tiempo que tardamos en obtener un beneficio de la inversión realizada. En el caso de la automatización, nos indicaría a partir de qué momento la inversión realizada en la automatización es amortizada.

Ambos conceptos, deben ser evaluados objetivamente y mediante parámetros adaptados a nuestro proyecto. Pasar por alto este estudio podría llevarnos a sorpresas no deseadas pero que son muy habituales. 

De manera general, la automatización supone una inversión que rentabilizaremos a medio plazo cuando el ahorro en horas de ejecución manual supere el tiempo invertido en la automatización. 


Es decir, la automatización supone unos costos (en licencias, infraestructura, scripting, etc...). Esta inversión será amortizada a lo largo del tiempo a costa de las horas de ejecución manual que ya no son necesarias. Es importante hacer constar que para el cálculo del ROI, es necesario conocer el costo del esfuerzo invertido en la ejecución manual de los casos de prueba. Sin ese dato, será muy difícil poder evaluar la viavilidad de un proyecto de automatización.

JMeter . Análisis plugin HTTP Simple Table Server

Hola de nuevo. Tras este periodo de tiempo sin publicar, se nos ha vuelto a iluminar la cabeza con una idea (de ahí ese molesto fogonazo que vemos de vez en cuando) , actualizando la entrada correspondiente al uso de máquinas remotas como inyectoras

Hasta ahora, como habíais visto en nuestro artículo referente a los equipos externos,  estos  se encontraban con una limitación muy importante comparados con otras herramientas  para pruebas .

Los ficheros de datos debían estar duplicados en la misma ruta  indicada  en el script en todas y cada una de las máquinas remotas.

Como uno se puede imaginar, esto obligaba a duplicar dichos ficheros y copiarlos. Sin embargo en la página de http://jmeter-plugins.org , hemos analizado el comportamiento de un plugin  categorizado como “Extra” que permite aplicar una alternativa para solventar esta limitación

Plugin HTTP Simple Table Server.

Este elemento,  tipificado dentro de la jerarquía del contenido del Extra Set como “Otros” , permite publicar  por el protocolo HTTP  un fichero , de manera que se puede acceder a los contenidos del mismo  en modo de base de datos

•       Lectura de un elemento
•       Escritura de un elemento
•       Estado actual del fichero
•      Tamaño del fichero

Es decir permite ciertas operaciones de consulta, inserción y estado, de modo que los registros o filas que contiene pueden ser usados en la operativa de un script  de JMeter.

El plugin se basa  en un pequeño servidor web que puede ser arrancado bien desde el modo de interfaz de usuario de JMeter, bien por línea de comandos o configurarlo en las propiedades de JMeter de manera que arranque de manera automática cada  vez que se inicie JMeter

Para hacer más ligero este documento, llamaremos al plugin como HTTP STS

Configuración

Independientemente del método de ejecución de este servidor, este necesita indicar varios parámetros para su uso

• Puerto TCP de operación
• Directorio de datos.

Arranque

Desde  la interfaz de  usuario, se puede incluir un HTTP STS como un elemento No de Prueba sobre el Workbench o “Banco de trabajo” de un script de JMeter

Incluir STS desde Banco de Trabajo

Esta manera  de incluirlo hará que sólo esté disponible mientras si se encuentre arrancado en modo gráfico, deteniéndose una vez que cerremos el script o detengamos el interfaz de JMeter

Arrancar STS desde JMeter GUI

Loadrunner 11.5. Virtual User Generator, entendiendo conceptos

Como diria Fray Luis de León y su "como deciamos ayer.." , seguimos con este análisis de la herramienta Loadrunner en su versión 11.5 . Ahora, con el análisis de los cambios que se incluyen en su generador de scripts Virtual user Generator

1. Script y Solution. 
2. Diferencias de la interfaz
3. Ejecutando

Script y Solution

Nada más arrancar el Virtual User Generator podemos ver  que se nos presenta una interfaz algo alejada de la distribución en marcos de uso que veniamos viendo hasta las versiones 9.X.  La razón fundamental es que ahora el entorno está basado en la interfaz de entorno de compilación y desarrollo Eclipse .

Nada más iniciar la creación de un nuevo script que refleje una navegación a probar , podemos ver que se invoca un nuevo concepto "Solution". Por lo que hemos podido ver hasta ahora, , su utilidad radica en poder combinar varias navegaciones más allá del uso de subtransacciones y nuevos Action para reflejar un flujo lógico de uso .

Solution con un sólo script protocolo Siebel Web

Podemos incluso incluir en una sola "solution" varios script de distintos protocolos que

El "Tester del Futuro"

Actualmente nos encontramos ante un desarrollo tecnológico que está dando lugar a nuevos entornos y necesidades. Algunos ejemplos son:

• La proliferación de dispositivos móviles hace que al día se realicen millones de descargas de apps. Las apps para dispositivos móviles integran distintas tecnologías y a su vez pueden hacer uso de aplicaciones de terceros
• El Cloud Computing está tomando una gran relevancia debido a las facilidades que ofrece para que cualquier empresa pueda utilizar aplicaciones en Cloud de manera barata y accesible.
• Las aplicaciones son cada vez más complejas e integran componentes de distintas tecnologías y proveedores.

El testing, como cualquier otra actividad del desarrollo e implantación de los S.I., se ha adaptado a este nuevo entorno: herramientas, metodología, tecnología, etc...

El ingeniero de pruebas se ha renovado y adaptado a los cambios. Pero, ¿cuáles son las características del tester del futuro?, ¿y qué conocimientos debe tener?

Intentaremos enumerar algunos de los desafíos a los que se enfrentan los ingenieros de pruebas en el actual contexto tecnológico, pero... el futuro ya está aquí!!