JMeter:

Cómo funciona una herramienta de

simulación de carga para pruebas de
performance?
Posted on July 19, 2018 by Federico
Para hacer pruebas de performance es fundamental entender cómo funciona una herramienta
de simulación de carga. Las pruebas de rendimiento consisten en simular carga en el sistema
bajo pruebas para analizar su desempeño durante la ejecución de la prueba, pudiendo
encontrar cuellos de botella y oportunidades de mejora.
Para la simulación se utilizan herramientas específicas, en las que se debe automatizar las
acciones que generarán esa carga, esto es: las interacciones entre el cliente y el servidor (digo
cliente para no restringir a un usuario, ya que puede ser el tráfico desde un navegador, una app
nativa, otra aplicación, etc.). Para poder simular muchos usuarios con poca infraestructura de
pruebas, se automatizan las interacciones a nivel de protocolo, lo cual hace que la
automatización sea más compleja (en cuanto al trabajo necesario para su preparación) que la
automatización de pruebas funcionales, que se realiza a nivel de interfaz gráfica.

En este post quiero darte un panorama general de cómo funcionan estas herramientas a nivel
conceptual, para que luego puedas concentrarte en estudiar cómo funciona alguna en particular.

¿Para qué hacer una prueba de performance?

Las pruebas de rendimiento son sumamente necesarias para reducir riesgos en la puesta en
producción, logrando así analizar y mejorar el rendimiento de la aplicación y los servidores, al
estar expuestos a usuarios concurrentes. Para ello se utilizan herramientas específicas (llamadas
generadoras de carga) para simular la acción de múltiples usuarios concurrentes.
Realizando simulaciones de usuarios accediendo simulatáneamente al sistema, podremos
responder a preguntas como:

o ¿La aplicación podrá responder adecuadamente a la carga esperada?

o ¿Cuántos usuarios podrá soportar el sistema antes de dejar de responder con tiempos de
respuesta aceptables?
o ¿Qué tan rápido se recupera la aplicación luego de un pico de carga?
o ¿Cómo afecta a los usuarios la ejecución de determinado proceso?
o ¿Cuáles son los cuellos de botella del sistema?
o ¿Cómo cambia la performance del sistema al tener un gran volumen de datos?
o ¿Qué configuración es óptima para la operativa diaria?
o ¿Será la aplicación capaz de responder adecuadamente ese día en que tendrá mucha mayor
carga que lo habitual?

¿Cómo se realiza una simulación de carga?

Las herramientas especializadas en realizar este tipo de simulaciones ejecutan cientos de
threads (hilos, que podríamos pensarlo como pequeñas partes de un programa que ejecutan de
manera concurrente). Estos hilos simulan las acciones que ejecutarían los usuarios reales, y por
eso se los llama “usuarios virtuales“, y lo podríamos pensar como un robot que ejecuta un
caso de prueba.

Estas herramientas que realizan la simulación se ejecutan desde máquinas dedicadas a la

prueba. Las herramientas permiten generalmente utilizar varias máquinas en un
esquema master-slave para distribuir la carga, ejecutando por ejemplo 500 usuarios desde cada
máquina. El principal objetivo de este sistema de distribución de carga es que no podemos dejar
que estas máquinas se sobrecarguen, porque de esa forma podrían invalidar la prueba, ya que se
generarían problemas para simular la carga o para recolectar los datos de tiempos de respuesta,
por ejemplo.

En la imagen queda representado cómo desde unas pocas máquinas se puede ejecutar gran
cantidad de carga (usuarios virtuales) sobre nuestro sistema. Para el análisis de performance se
necesitan expertos de distintas partes de la infraestructura (red, application servers, bases de
datos, etc.) utilizando distintas herramientas de monitorización.
¿Cómo preparar los scripts para la simulación?
A diferencia de los scripts de pruebas funcionales, en estos scripts si bien se utiliza el enfoque
de record and playback, no se graba a nivel de interfaz gráfica, sino que a nivel de protocolo
de comunicación. Esto es porque en una prueba funcional al reproducir se ejecuta el navegador
y se simulan las acciones del usuario sobre el mismo. En una prueba de rendimiento se van a
simular múltiples usuarios desde una misma máquina, por lo que no es factible abrir gran
cantidad de navegadores y simular las acciones sobre ellos, ya que la máquina utilizada para
generar la carga tendría problemas de rendimiento, obteniendo así una prueba inválida. Al
hacerlo a nivel de protocolo se puede decir que se “ahorran recursos”, ya que en el caso del
protocolo HTTP lo que tendremos serán múltiples hilos que enviarán y recibirán texto por una
conexión de red, y no tendrán que desplegar elementos gráficos ni ninguna otra cosa que exija
mayor procesamiento.
Para preparar un script se procede en forma similar que para los scripts de pruebas funcionales,
pero esta vez la herramienta en lugar de capturar las interacciones entre el usuario y el
navegador, se captura los flujos de tráfico HTTP entre el cliente y el servidor (HTTP o el
protocolo que se vaya a simular, y de nuevo, cliente puede ser el browser, una app nativa o lo
que se quiera simular). Entonces, para la automatización se necesitan conocimientos sobre
herramientas de automatización y protocolos de comunicación (HTTP, SIP, SOAP, ISO8583,
etc.).

En la imagen queda representado que con herramientas como JMeter lo que sucede es cómo se
“graba” la prueba, donde básicamente se abre un proxy que capturará el tráfico entre el cliente
y el servidor. El script resultante será una secuencia de comandos en un lenguaje proporcionado
por la herramienta utilizada, en el cual se manejen los requests y responses de acuerdo al
protocolo de comunicación.
Una vez que se graba el script, es necesario luego realizar una serie de ajustes sobre estos
elementos para que quede reproducible. Estos scripts serán ejecutados por usuarios
concurrentes, y, por ejemplo, no tiene sentido que todos los usuarios utilicen el mismo nombre
de usuario y clave para conectarse, o que todos los usuarios hagan la misma búsqueda (ya que
en ese caso la aplicación funcionaría mejor que de usar diferentes valores, dado que influirían
los cachés, tanto a nivel de base de datos como a nivel de servidor de aplicaciones Web).
El costo de este tipo de ajustes dependerá de la herramienta utilizada y de la aplicación bajo
pruebas. En ocasiones es necesario ajustar cookies o variables, pues las obtenidas al grabar
dejan de ser válidas, debiendo ser únicas por usuario. Se deberán ajustar parámetros, tanto del
encabezado como del cuerpo del mensaje, etc.

Como comentario final, me gustaría destacar que hay una diferencia muy grande de esfuerzo
entre preparar un script para un flujo de un usuario en un browser a que si quisiéramos preparar
una prueba puntual para un endpoint específico de una API Rest.

Cómo realizar pruebas de carga con

JMeter:
Instrucciones paso a paso para
principiantes
Una herramienta de pruebas de rendimiento de código abierto como JMeter
proporciona a las organizaciones la capacidad de ejecutar pruebas de rendimiento
para sus aplicaciones web, sitios web y API, pero no tiene que lidiar con ninguna
inversión inicial que venga con herramientas de pruebas de rendimiento basadas
en comerciales o de pago. Al elegir una solución de pruebas de carga basada en
escritorio de código abierto como JMeter frente a una solución basada en web de
pago, como LoadView, hay muchas consideraciones en las que pensar. Si usted
es sólo un principiante de JMeter, es posible que desee tomarse un tiempo para
entender cómo funciona todo y leer artículos apropiados o ver videos sobre cómo
empezar con JMeter. Echemos un vistazo a algunos de los pasos implicados para
instalar JMeter y cómo configurar una prueba de carga básica.
Paso 1: Verificar los requisitos del sistema
Al igual que cualquier otra aplicación de escritorio, debe asegurarse de que su
sistema cumple con los requisitos básicos necesarios para poder ejecutar JMeter.
Como mencionamos anteriormente en esta guía, JMeter es una aplicación basada
en Java, por lo que debe asegurarse de que tiene Java instalado, así como la
versión correcta. JMeter es compatible con versiones de Java 8 o superior.
Además, para el rendimiento y la seguridad, se recomienda instalar las últimas
versiones secundarias de JMeter. JMeter puede ejecutarse en diferentes sistemas
operativos Windows, Mac y Linux, así que asegúrese de comprobar que el sistema
operativo es compatible o que tiene una implementación java compatible.
Paso 2: Descargar binarios JMeter o código fuente
Una vez que haya comprobado que su sistema cumple con todos los requisitos
necesarios del sistema, puede descargar los últimos archivos binarios o archivos
de origen JMeter, en función de su entorno o requisitos específicos. Los archivos
binarios contienen las versiones compiladas del programa JMeter y puede
ejecutarlo inmediatamente. Por otro lado, los archivos de origen se pueden instalar
sin utilizar un administrador de paquetes, lo que permite a los desarrolladores o
equipos configurar y compilar el programa ellos mismos y tener más control sobre
los programas instalados. En la mayoría de los casos, se instalan las versiones
binarias del software. Y tenga en cuenta que hay diferentes tipos de descarga de
archivos, incluyendo .zip, y extensiones de archivo .tgz.
Paso 3: Proceso de instalación de JMeter
Una vez que haya seleccionado la versión binaria o de origen de JMeter, se
descargará en su sistema. Puede elegir abrir el archivo, moverlo a una nueva
ubicación o crear una nueva ubicación de carpeta dentro del sistema para un
acceso más rápido más adelante. Desde allí puede comenzar a extraer el archivo.
Esto puede tardar unos minutos en completar todo el proceso de instalación.
Dependiendo de su sistema operativo, puede encontrar diferentes pasos durante
el proceso de instalación, pero una vez instalado JMeter, la funcionalidad de
JMeter será la misma.
Paso 4: Interfaz de usuario JMeter
Al iniciar JMeter, se abrirá y se le llevará a la ventana Plan de prueba. A partir de
aquí, usted será capaz de construir su plan de prueba. Esta ventana incluye
acceso al menú y a la barra de herramientas principal situada cerca del lado
izquierdo superior de la ventana. Puede acceder a algunas de las mismas
características desde el menú y la barra de herramientas principal, pero la barra
de herramientas principal proporciona un acceso más rápido a algunas de las
herramientas y funcionalidades que utilizará durante el proceso de creación y
configuración de pruebas de carga. Cerca del lado superior derecho de la ventana,
verá opciones para el tiempo, registros (ver/ocultar) y usuarios durante la
ejecución de la prueba.
La sección principal, llamada sección Editor, es donde podrá ver y configurar los
distintos elementos y campos del Plan de prueba para la prueba de carga. A la
izquierda de la sección Editor, verá la vista de árbol del Plan de pruebas a medida
que avanza por el proceso de creación y configuración de pruebas y puede
expandir y cerrar elementos individuales para profundizar en ellos individualmente.

Paso 5: Crear un plan de prueba de carga

Los usuarios de JMeter pueden comenzar a crear su plan de prueba de carga
desde cero o también seleccionar entre varias plantillas de plan de prueba
ubicadas en el menú desplegable Archivo. Las plantillas incluyen soap
WebService Test Plan, plan de prueba web básico y avanzado, plan de prueba
FTP (Protocolo de transferencia de archivos), plan de pruebas funcionales y otros.
Estas plantillas de prueba incluirán todos los elementos, secciones y campos
específicos necesarios que usará para crear y compilar el plan de pruebas de
carga. Si es nuevo en las pruebas de rendimiento o en el propio JMeter, es posible
que inicialmente prefiera utilizar plantillas en lugar de crear el plan de prueba
desde cero, antes de pasar a planes de prueba más avanzados.
Para crear un plan de prueba, vaya a Archivo y seleccione Nuevo o seleccione el
botón Nuevo en la barra de herramientas. Es importante tener en cuenta que debe
ejecutar JMeter en modo GUI para crear el plan de prueba. El CLI, o interfaz de
línea de comandos, se utiliza para ejecutar la prueba de carga. A continuación,
hablaremos sobre cómo especificar el número de usuarios para la prueba de
carga, que también se conoce como el grupo de subprocesos.
Paso 6: Crear grupo de subprocesos
Dentro del cuadro de diálogo Grupo de subprocesos, puede establecer y ajustar
varias propiedades de subproceso, como Número de subprocesos (usuarios),
Período de rampa (en segundos) y Recuento de bucles (cuántas iteraciones de
prueba), así como acciones adicionales, como retrasos, tiempos de inicio y
detención de pruebas y acciones que se deben realizar después de un error del
muestreador.
Paso 7: Configurar sampler
En JMeter, los muestreadores son los que permiten a JMeter enviar los diferentes
tipos de solicitudes. Por ejemplo, puede ser una solicitud HTTP (para un sitio web,
aplicación o API), solicitud FTP, solicitud SMTP, solicitud TCP, así como muchos
otros. Por ejemplo, si desea ejecutar una prueba de carga en una página web o
sitio web, seleccionará solicitud HTTP. Desde aquí se le muestra introduciendo
detalles adicionales como el protocolo (HTTP/S), el nombre del servidor o la IP, la
ruta de acceso (para la página web específica) y qué tipo de solicitud, como GET,
POST, HEAD, PUT, etc., que se puede utilizar para las pruebas de carga de API.
Paso 8: Configurar agentes de escucha
Para poder revisar los resultados del sampler, a continuación debe configurar lo
que se conoce como agentes de escucha en JMeter. Dentro de la ventana Plan de
prueba de JMeter, puede seleccionar entre muchos agentes de escucha
diferentes, como Informe de resumen, Gráfico agregado, Ver árbol de resultados,
Ver resultados en tabla, además de muchas otras opciones, para ver y analizar los
resultados de las pruebas. Además, puede agregar varios agentes de escucha a
un plan de prueba JMeter. A partir de este momento, el plan de prueba está
completo y puede ejecutar la prueba.
Paso 9: Grabación de los scripts de prueba de carga
Si solo está buscando ejecutar una prueba de carga básica de nivel HTTP o
protocolo, en términos de configuración de prueba, entonces realmente no hay
nada más que necesite hacer. Sin embargo, si necesita configurar una prueba que
se parezca más a las acciones del usuario, deberá usar su grabador de script de
prueba HTTP(S). Por lo tanto, dentro de JMeter, esto agrega otro paso en el plan
de prueba. Dentro del grupo de subprocesos, deberá agregar el controlador de
grabación. El controlador de grabación le permite navegar a través de un sitio o
aplicación, y grabará sus acciones a través de solicitudes HTTP/S. También puede
agregar varios controladores de grabación por página. El controlador de grabación
ahorra tiempo, por lo que no es deba agregar manualmente cada solicitud.
Sin embargo, el inconveniente es que todavía está grabando las solicitudes
HTTP/S, en realidad no está grabando pasos dentro de un navegador real, desde
la perspectiva del usuario. Ahora, también puede utilizar el servidor proxy JMeter,
que le permite grabar scripts desde un explorador, pero configurar esto tarda un
tiempo en configurarse. Debe entrar en la configuración de proxy del sistema,
importar el certificado JMeter y, a continuación, configurar finalmente la
configuración de proxy.
Como alternativa, una solución como LoadView, que utiliza el Grabador Web
EveryStep, es un gran paso adelante de las opciones de grabación de JMeter,
como scripting de puntos y clics en exploradores reales sin ninguna de las
configuraciones complejas y que consumen mucho tiempo. Simplemente abra la
grabadora y comience a escribir scripts.

GRABADORA WEB EVERYSTEP

Paso 10: Ejecute la prueba de carga

Después de configurar todos los detalles y la configuración de la prueba de carga,
simplemente puede seleccionar el botón Ejecutar en la barra de herramientas y
comenzará la prueba. Recuerde ejecutar la prueba en el modo CLI para obtener
mejores resultados.
Paso 11: Revise los resultados de la prueba de carga
Dependiendo del tipo de agente de escucha que haya elegido, puede ver los
resultados a medida que se ejecuta la prueba. Por ejemplo, si seleccionó Ver
resultados en tabla, verá que los resultados se muestran a medida que se ejecuta
cada ejecución o usuario. También se incluirán en los resultados métricas
adicionales, como Tiempo (en milisegundos), Estado (muestra respuestas y
errores válidos), Bytes y bytes enviados, Latenciay Tiempo de conexión. A partir
de estos resultados puede ver dónde se produjo cualquier error o dónde puede
haber tiempos de carga lentos.
 Selenium y la automatización de las pruebas
RECU-0381 (RECURSO HERRAMIENTA)

 Área: Verificación de Entrega Software

 Carácter del recurso: Recomendado

Descripción
Selenium es un conjunto de utilidades que facilita la labor de obtener juegos de pruebas para
aplicaciones web. Para ello nos permite grabar, editar y depurar casos de prueba, que podrán ser
ejecutados de forma automática e iterativa posteriormente.
Además de ser una herramienta para registrar acciones, permite editarlas manualmente o crearlas
desde cero. Las acciones se basan en el uso de diferentes API's en diferentes lenguajes (PHP, Ruby,
JAVA, Javascript, etc). Entre su principales características podemos nombrar:

 Facilidad de registro y ejecución de los test.

 Referencia a objetos DOM en base al ID, nombre o a través de XPath.
 Auto-completado para todos los comandos.
 Las acciones pueden ser ejecutadas paso a paso.
 Herramientas de depuración y puntos de ruptura (breakpoints).
 Los test pueden ser almacenados en diferentes formatos.
El potencial de esta herramienta puede ser utilizado para la grabación de las pruebas funcionales
durante la Generación de pruebas de regresión. Con este servicio se consigue obtener una batería de
pruebas automatizadas que podrán ser utilizadas cuando sea necesario repetir las pruebas.

Recursos necesarios
Los navegadores mas conocidos compatibles con la utilización de Selenium son:

 Explorer
 Mozilla Firefox
 Google Chrome
 Safari
Las componentes de Selenium que son necesarias para la grabación y ejecución de las pruebas
son:

 Selenium client v1.0.1: cliente de Selenium, necesario para crear pruebas Junit con Selenium.
 Selenium IDE v1.0.2: plugin de Firefox para la grabación de las pruebas, paso a paso.
 Selenium Server v1.0.1: servidor de Selenium, que es el que realiza las pruebas.
Para mas detalles sobre esto pincha aqui.
 Otras consideraciones
 La versión de Java necesaria es la JDK 1.6.0_16.
 Es recomendable tener instalado un entorno de desarrollo, por ejemplo Eclipse 3.4.2.
 Otra herramienta recomendable ya que nos va a ser muy útil para el reciclaje de las pruebas
es Firebug. Se trata de un plugin de Firefox que permite inspeccionar el código HTML de una página
y, entre otras opciones, obtener el Xpath de los diferentes elementos.
 Para que las pruebas puedan ser extendidas para y puedan ser ejecutadas en varios navegadores,
necesitaremos tener instalada la herramienta JUnit. Para mas detalles sobre esto pincha aquí.

Selenium IDE

Cómo instalarlo
La instalación de Selenium IDE al tratarse de un complemento de Firefox es muy sencilla. Podemos
descargar e instalar el complemento desde cualquiera de los siguientes enlaces:

 Página Oficial de Firefox

 Página Oficial de Selenium
Una vez instalado el complemento y tras reiniciar Firefox podremos tener acceso a Selenium IDE tanto
desde el menú de herramientas, el cual nos abrirá la aplicación en una nueva ventana, como desde
Ver -> Panel lateral -> Selenium IDE que nos lo mostrará como un Panel (ver la imagen) dentro de la
ventana principal de Firefox.
 Panel de Selenium IDE

Descripción del Panel

El Panel consta de los siguientes objetos:

 Un menú desplegable con las siguientes opciones:

o Menú 'Archivo': Permite crear un nuevo 'Test Case', abrir uno existente, guardarlo, exportarlo en
varios formatos y lo mismo con los 'Test Suite'
o Menú 'Editar': contiene las opciones de copiar, pegar, seleccionar, etc...
o Menú 'Options': en este menú se encuentran las opciones de configuración de Selenium y las
opciones de selección de formato del visor y del portapapeles. En las opciones de Selenium se puede
definir el encoding de los ficheros de test, el tiempo de timeout por defecto, etc...
 Debajo del menú existe un campo de texto que contiene la url base sobre la que se van a grabar las
pruebas.
 A continuación hay una lista de iconos con los que se puede ejecutar todo el test grabado, ejecutar
sólo la línea seleccionada, pausar la ejecución, iniciar la grabación,...
 También se dispone de un selector de velocidad para ajustar la velocidad a la que se ejecutan los test.

Pestaña Table
Contiene una lista con los comandos que se van grabando según se van realizando las acciones sobre
la pantalla.
 Pestaña Table en el Panel de
Selenium IDE
Esta pestaña sólo aparece habilitada cuando se selecciona en el menú “Options” el formato HTML.

Pestaña Source
Muestra el código fuente generado, en el formato que se haya seleccionado.
Pestaña Source en el Panel de Selenium IDE
Esta pestaña se encuentra siempre disponible.

Grabación de Pruebas

Tipos de grabación
La grabación de una prueba puede ser configurada para que se haga de forma automática o manual:

Grabación Automática
Para grabar una prueba simplemente habrá que habilitar el panel de Selenium IDE en el
navegador Mozilla Firefox, verificar que el botón grabar está activo (debe quedar de color rojo claro)
y empezar a realizar la navegación. Nuestra navegación quedará registrada, generándose los
comandos que correspondan en cada caso, que se podrán ver en el panel de Selenium IDE.
En el botón secundario del ratón hay una opción con la cual para cualquier elemento de la página en la
que se navega se muestran las funciones de Selenium disponibles. Esta opción es muy útil para
cuando se quiere verificar que existe un texto en la pantalla o si un elemento está presente.
 Menú secundario. Funciones de Selenium disponibles

Grabación Manual
Para programar las instrucciones que automatizan la prueba, se deshabilita el botón de grabar, en la
pestaña “Table” se selecciona una línea vacía y en los desplegables que aparecen en la parte inferior
se indica la instrucción.

Pestaña Table en el Panel de Selenium IDE

 El primer desplegable contiene la lista completa de funciones que ofrece Selenium IDE (no incluye el
detalle de cada una de ellas ya que, al seleccionarla, en la parte de información podemos ver la
operativa de la función seleccionada).
 El segundo combo muestra una lista con todos los indicadores posibles para el elemento sobre el que
se quiere realizar la acción (ver Localización de elementos), siempre que se hayan grabado
automáticamente, en caso de edición manual aparece vacío.
 En el último campo se introduce el valor que pueda necesitar la función de Selenium para su
ejecución, por ejemplo, el texto a introducir en un campo de texto.
En el apartado de referencias podemos encontrar un enlace a la página oficial de Selenium (Manual de
Referencia) donde se nos muestran todos los comandos posibles y su descripción.
De la misma forma también se pueden editar pruebas que ya hayan sido grabadas con anterioridad,
editando los campos que aparecen en la parte inferior de la pestaña “Table” o directamente en el
código generado en la pestaña “Source”.

Identificación de los elementos de la interfaz

Hay comandos de Selenium que necesitan como parámetro un localizador del elemento sobre el que
realizar la acción. Es muy importante que dicho localizador se resuelva de forma única, para que la
prueba sea correcta, y la acción no se realice sobre un elemento indeseado. Por otra parte, también
debe tenerse en cuenta que el identificador elegido sea reutilizable en el futuro: por ejemplo debe
evitarse la elección de un identificador que cambie con cada nueva versión de la aplicación.
Por ello, es muy importante elegir de manera adecuada los identificadores que vamos a usar en cada
caso:

 id: Es la mejor opción siempre y cuando la página HTML tenga definidos correctamente los
identificadores de sus elementos, es decir, que sean únicos e invariantes en el tiempo. En estos casos,
el mantenimiento de las pruebas generadas usando este método es prácticamente nulo, y el hecho de
añadir o quitar elementos a la página no afecta al 'id' del resto de elementos existentes.
 name: Por definición, el atributo 'name' de un elemento HTML no tiene que ser único, con lo que el
uso de este método de localización no garantiza que la prueba se ejecute de la manera deseada.
Además, en funciones que sólo referencian a un elemento (getText, click, type, etc...) la acción se
realizaría siempre sobre el primer elemento encontrado, por ejemplo, esta opción no sería válida para
hacer click sobre un conjunto de 'radiobuttons' con el mismo nombre.
 identificador: Ésta es la opción por defecto que Selenium-IDE al grabar las pruebas y consiste en
usar el 'id' si existe y si no usar el 'name'.
 dom: Esta opción utiliza el DOM de la página para hacer referencia a los elementos. El problema que
presenta es que cualquier introducción de un nuevo elemento, o reorganización de los existentes,
provoca que las referencias cambien, lo que puede invalidar las pruebas grabadas anteriormente.
 xpath: Este método de identificación es similar al anterior, pero en este caso hace uso de la
estructura XML que posee todo documento HTML, para así hacer referencia a los elementos mediante
una ruta, ya sea absoluta (partiendo desde el elemento /) o relativa (partiendo de un elemento
conocido). Posee el mismo problema que el localizador por 'dom' ya que tanto el DOM como el XPATH
dependen de la estructura del documento. Además Xpath devolverá un elemento único siempre que
sea una ruta absoluta, en el caso de rutas relativas no se cumple ya que una misma ruta puede ser
válida para varios elementos.
 link: Este método es el más utilizado al querer localizar un enlace. Su uso requiere conocer el texto
que va a mostrar dicho enlace en la página HTML, por lo tanto no es útil en caso de existir enlaces con
el mismo texto (devolvería el primero de ellos), enlaces sin texto, o enlaces con texto dinámico.
 css: Este localizador consiste en identificar los elementos por sus propiedades de CSS. Este método
tampoco garantiza la unicidad del elemento referenciado.

Cuadro resumen

Independencia de la Compatible Compatible

Localizador Único
estructura HTML JSF Ext JS

id Si Si Si(*) No

name No Si Si No
 Independencia de la Compatible Compatible
Localizador Único
estructura HTML JSF Ext JS

identificador No Si Si(*) No

dom No No Si Si

Xpath Si(**) No Si Si

link No Si Si Si

css No Si Si Si

(/*) Siempre que el 'id se defina manualmente. (**) Xpath devolverá un elemento único siempre que
sea una ruta absoluta, en el caso de rutas relativas no se cumple ya que una misma ruta puede ser
válida para varios elementos.

Limitaciones
Algunas de las limitaciones encontradas para la grabación de las pruebas usando Selenium son las
siguientes:

Uso de tecnología AJAX

El uso de esta tecnología en los desarrollos permite modificar el HTML cargado de una página sin
realizar una recarga de la misma, por lo que las funciones de Selenuim que esperan a que la página
haya cargado para continuar con la ejecución de los tests, no sirven.
En estos casos la estrategia que se recomienda seguir es identificar un elemento que sea modificado
mediante la llamada AJAX y realizar una espera hasta que el elemento sea modificado. Lo más
habitual es esperar a que un elemento cambie de visibilidad (visible->oculto y viceversa), o que
aparezca un nuevo elemento HTML (un nuevo input, un nuevo texto, etc..). De esta manera se podrá
identificar cuándo una llamada AJAX ha terminado y es posible continuar con la ejecución de los tests.

Ventanas emergentes
Para la ejecución de las pruebas, Selenium 'inyecta' código javascript en la página HTML y así
consigue la ejecución automática del código grabado. Esto hace que no sea posible acceder a ningún
elemento que se quede fuera del ámbito del código HTML, como es el caso en el que se necesite
interactuar con ventanas emergentes. Existen varias situaciones, y en algunas de ellas el problema es
solventable:

 Ventanas emergentes de javascript (alert, confirm y promt): Selenium ofrece funciones para

interactuar con ellas. Es necesario conocer el nombre de la ventana emergente para poder hacer uso
de las funciones que Selenium dispone a tal efecto.
 Ventanas emergentes generadas por el sistema operativo (cargar / guardar un fichero /
selección de certificado digital): En este caso Selenium no es capaz de interactuar con ellas y es
necesario recurrir a herramientas externas.
 Ventanas emergentes del propio navegador (enlaces nuevas ventanas): Al igual que en el caso
de ventanas emergentes de javascript, Selenium ofrece funciones para interactuar con ellas. Es
necesario conocer el nombre de la ventana emergente para poder hacer uso de las funciones que
Selenium dispone a tal efecto.
En cualquier caso, las ventanas emergentes obligan a realizar una actuación manual.
 Diferencias entre navegadores
Existen diferencias en la interpretación javacript de cada navegador (incluso puede que entre
diferentes versiones del mismo navegador) o los permisos que se pueda tener para realizar diferentes
tareas, lo cual implica que las pruebas generadas deben seguir estrategias diferentes según el
navegador al que vaya dirigido, aumentando la complejidad del diseño.
Las diferencias entre navegadores (incluso entre diferentes versiones del mismo navegador) mas
comunes son:

 Acceso mediante HTTPS:Cuando se accede a una página mediante HTTPS, ésta proporciona un
certificado de seguridad que se debe aceptar para continuar la navegación.
o En Internet Explorer 7, esta ventana de información se puede grabar con Selenium, con lo que se
puede sortear fácilmente.
o En cambio en Firefox, la aceptación del certificado de seguridad pasa por una ventana emergente a la
que Selenium no tiene acceso, por lo que hay que recurrir al uso de perfiles en la definición del
navegador a usar en las pruebas:
 Arrancar el manager de perfiles de Firefox (firefox.exe -P )
 Crear un nuevo perfil y acceder a Firefox con dicho perfil
 Aceptar el certificado de seguridad permanentemente y configurar Selenium para que use el perfil
para Firefox (java -jar Selenium-server.jar -firefoxProfileTemplate [ruta al perfil]).
 La interpretación de funciones:Se da el caso de que una misma funcion de Selenium tiene
comportamientos diferentes dependiendo del navegador.
o verifyTrue (verifyFalse, verifyEquals, verifyNotEquals): estas funciones comprueban si una condición
dada es verdadera o falsa, lanzando al final de la ejecución de la prueba, una excepción en caso de
error. En Internet Explorer el funcionamiento de este tipo de funciones no es el adecuado,
devolviendo valores 'true' cuando no debería hacerlo.
o isElementPresent(isTextPresent): Esta función verifica si un elemento está presente en la página HTML
o no. En Firefox, si el elemento está oculto (visibilidad con valor 'hidden') devuelve 'false', mientras
que en Internet Explorer devuelve 'true'.

Reutilización de las pruebas grabadas con Selenium

Impacto de los cambios en la aplicación sobre las pruebas automatizadas

Dependiendo del cambio introducido en la aplicación, las pruebas funcionales automatizadas con
anterioridad podrán ser reutilizadas en mayor o en menor medida. Los cambios se pueden agrupar en:

 Nuevas interfaces: Es el caso en el que se presentan nuevas funcionalidades en la aplicación en

forma de nuevas ventanas, sin interferir en las ya existentes mas allá de agregar los accesos a las
nuevas pantallas. El impacto de estas nuevas funcionalidades sobre las pruebas ya grabadas es muy
bajo o incluso nulo, ya que el hecho de que hayan aparecido estas nuevas pantallas no afecta en nada
a las ya existentes.
 Modificaciones en funcionalidad de interfaces existentes: Es el caso en el que se modifica la
funcionalidad de pantallas ya existentes. El impacto de estos cambios va en función del nivel de
cambios introducido. Así cuanto más haya cambiado, mayores serán las modificaciones necesarias en
las pruebas automatizadas que incluso puede que requiera una grabación desde cero.
 Cambio en las interfaces existentes sin modificar la funcionalidad: Es el caso en el que se
modifica el aspecto y/o contenido de las pantallas pero sin afectar a la funcionalidad existente: puede
ir desde un simple cambio en las hojas de estilo (css) a una reorganización completa de los datos
mostrados (cambio en la estructura HTML). En este caso el impacto va a depender mucho del tipo de
localizador de elementos que se haya usado. Siempre que se usen localizadores independientes de la
estructura del HTML, los cambios no deben afectar. Sin embargo, para aquellos elementos para los
que se haya usado un localizador dependiente de la estructura del HTML, habría que revisar si los
cambios han afectado a los localizadores.

Evaluación de la automatización de las pruebas de una aplicación

Antes de decidir la automatización de las pruebas de una aplicación con Selenium es necesario
analizar el tiempo medio que se va a invertir en la grabaciones de las pruebas, ya que en ocasiones
puede resultar mucho mayor que el proceso de ejecutarlas manualmente. Para mas datos puede
consultarse la pauta sobre automatización de pruebas funcionales
Preguntas frecuentes
¿Dónde puedo encontrar el plugin de Selenium IDE?
En la página oficial de Selenium, en la sección de descargas hay enlace al plugin Selenium IDE para
Firefox.
En la grabación de una prueba, al realizar algunos pasos, no se actualiza la lista de
comandos grabados. ¿No se están grabando?
En ocasiones tarda en refrescarse la lista de comandos, así que se puede continuar la grabación y si a
las 5 o 6 ordenes no aparecen, comprobar si el botón de grabación está activo.
¿Cómo puedo saber la ruta XPath de un elemento?
Se puede mirar el código fuente de la página e ir construyendo la ruta XPath a mano. Pero para
ahorrar tiempo y evitar errores conviene instalar el plugin Firebug para Firefox. Una vez instalado
podremos activarlo con el botón que se ha añadido a la parte inferior del navegador. Una vez activo
veremos una ventana como ésta:

Firebug para Firefox

En la pestaña HTML podemos ver un árbol con la estructura de la página. En él se puede buscar el
elemento del cual queremos conocer el XPath, aunque es más fácil hacer uso del botón de selección
de elementosy hacer click sobre el elemento deseado, lo que hará que se abra el árbol HTML justo en
el objeto seleccionado:

Botón de selección de elementos

Una vez encontrado el objeto en el HTML, al hacer click con el botón secundario sobre él, aparece la
opción “Copiar XPath”, con lo que tendremos en el portapapeles la ruta XPath del elemento.
Ruta XPath del elemento
He grabado una prueba ¿cómo la ejecuto?
Para ejecutarla desde Selenium IDE, lo primero es parar la grabación, para ello se desactiva el botón

Botón parar
 A continuación, para ejecutar hay que pulsar el botón

Botón play
He grabado una prueba y aunque los localizadores de los elementos son correctos
(Selenium los encuentra), las funciones no se ejecutan sobre el elemento deseado.
Hay que comprobar que el localizador usado sea único, porque lo más probable en este caso sea que
no lo sea y la ejecución se esté realizando sobre otro elemento.
He grabado una prueba y al ejecutarla me dice que no encuentra un elemento que si está en
la página.
En este caso puede estar ocurriendo dos cosas:

 Que el elemento se haya creado con AJAX, por lo que hay que introducir el código necesario para que
la ejecución se espere hasta que el elemento se cargue con AJAX (por ejemplo esperando a que el
elemento exista y esté visible).
 Que el identificador sea dinámico y ya no sea válido, en cuyo caso hay que buscar otro tipo de
localizador que sea invariante en el tiempo.
Al ejecutar una prueba que tiene grabada la interacción con un popup javascript, no
aparecen dichos popups. ¿Está mal grabada la prueba?
No, la prueba esta correctamente grabada, Selenium a la hora de ejecutar una prueba no muestra los
popups de javascript, pero si que interactua con ellos a través de las funciones que dispone a tal
efecto.
¿Como sé si una prueba se ha ejecutado correctamente?
Al realizar una ejecución, en la lista de comandos podremos ver en color verde las instrucciones que
se lanzan correctamente y en rojo las que han fallado. Además en la ventana de información aparece
las razones por las que se ha producido el fallo.