Herramientas de cloud testing: Sauce Labs

El enfoque cloud en el ámbito del testing está poco explotado a pesar de la diversidad de opciones. Actores como AWS Device Farm, Sauce Labs, VS app-center, Firebase TestLab, Bitbar o BrowserStack son un ejemplo de que el cloud-based testing es ya una realidad lo suficientemente madura como para que formen parte de nuestro ecosistema.

Aunque nuestra experiencia abarca la mayoría de plataformas, hoy os vamos a hablar de Sauce Labs. Explicaremos el funcionamiento básico de esta plataforma, escogida por su sencillez de implantación, además de por su capacidad para ejecutar nuestras pruebas manuales/automáticas con máquinas virtuales para web y emuladores/dispositivos reales para movilidad.

Todo ello sin la necesidad de tener una infraestructura física y, por lo tanto, con la posibilidad de externalizar y optimizar nuestra inversión en hardware para realizar pruebas.

 

¿Qué es Sauce Labs?

Sauce Labs es una empresa americana alojada en california que proporciona servicios en cloud o alojados en la nube. Estos servicios están orientados a realizar testing manual y automatizado sobre aplicaciones web en distintos navegadores y móviles android e iOS (emuladores, simuladores y granja de dispositivos reales) de manera remota.

 

¿Qué ventajas tiene el testing automatizado en la nube?

  • Se ahorra en infraestructura local o tradicional: podemos ejecutar nuestras pruebas automatizadas en cientos de dispositivos reales o simulados sin tener coste alguno, sin la necesidad de tener una extensa infraestructura con máquinas virtuales o ni tener que adquirir dispositivos. Sauce Labs tiene emuladores, navegadores y dispositivos reales de los últimos del mercado.
  • Es escalable y paralelizable: permite tener tantos nodos paralelos como tengamos contratados ejecutándose a la vez. Además, proporciona un sistema de túnel y VPN para conectar con sistemas de testing no productivos.
  • Administrado totalmente por web: se puede dividir por equipos de trabajo, hay vistas para clientes y todo se administra vía web.
  • Es integrable con sistemas de CI como jenkins, bamboo o team, y soporta la mayoría de frameworks de automatización: Espreso, XCUITest, Appium y Selenium WebDriver.

 

Ejemplo de una prueba automatizada en Sauce Labs usando Appium contra un emulador de Android

A continuación vamos a explicar, paso a paso, cómo lanzar una automatización con Sauce Labs sobre una aplicación Android usando el framework de automatización Appium y el lenguaje de programación Java.

Paso 0. Obtener una cuenta de Sauce Labs

Sauce Labs no es gratuito. No obstante, se puede pedir un trial solamente rellenando un registro en o adquirir una licencia (se pueden ver los precios en https://saucelabs.com/pricing).

A continuación, en el ejemplo que vamos a ver, se está usando una cuenta trial.

Paso 1. Obtener el usuario y el APIKey de una cuenta de Sauce Labs

En este caso necesitamos una cuenta de Sauce Labs. Una vez la tengamos, nos autentificamos con nuestras credenciales y navegamos a 'User settings'. Allí obtendremos los siguientes datos desde settings:

  1. Usuario
  2. APIKEY

Navegar a settings:

"navegar a user settings"

 

Donde copiamos el usuario (Username) y el APIKey (Access key) de:

user settings

Paso 2. Subir la 'apk'

Sauce Labs nos proporciona un directorio temporal en la nube para nuestro usuario y una serie de servicios web con un API REST para automatizar ciertas tareas como, por ejemplo, subida de APK. Para consumir los servicios usaremos un terminal y el software cURL

Previamente es muy importante saber en qué Data Center estamos, ya que como podemos observar en la imagen anterior estamos en US-WEST. Esto es muy importante para los webservices que vamos a mostrar a continuación y la url del driver:

Por lo tanto, usaríamos https://saucelabs.com. Después subiremos nuestra apk usando el siguiente comando que invoca al webservice de Sauce Labs, donde posteriormente le haremos referencia cuando se lance el test automatizado:

curl -k -u  jaime.vivalabssauce:APIKEY -X POST -H 'Content-Type: application/octet-stream' https://saucelabs.com/rest/v1/storage/jaime.vivalabssauce/getConsumerDebug_v4.apk?overwrite=true  --data-binary /git/appium-getConsumer/src/test/resources/files/getConsumerDebug_v4.apk

 

La respuesta sería la siguiente:

{
   "username":"jaime.vivalabssauce",
   "filename":"getConsumerDebug_v4.apk",
   "size":1650198,
   "md5":"0c9bce7d61c88ab86a43f0739d170f56",
   "etag":"c16690da0e882cdbac22c573f8e6c8f7"
}

 

Para comprobar si está bien subido se puede ejecutar este comando, que nos lista los ficheros que tenemos subido a la carpeta personal:

curl -k -u jaime.vivalabssauce:APIKEY -X GET -H 'Content-Type: application/octet-stream' https://saucelabs.com/rest/v1/storage/jaime.vivalabssauce

 

Y obtendremos como respuesta el listado de ficheros que tenemos, comprobando que el que hemos subido existe:

{
  "files": [
    {
      "name": "getConsumerDebug_v4.apk",
      "size": 1650198,
      "mtime": 1574334802,
      "md5": "0c9bce7d61c88ab86a43f0739d170f56",
      "etag": "c16690da0e882cdbac22c573f8e6c8f7"
    }
  ]
}

 

Para más información sobre el API de Sauce Labs podéis consultar este link. ¡Y cuidado! Este directorio es temporal, es decir, que cada cierto tiempo se borra. Por lo que es recomendable subir nuestra apk antes de cada sesión de testing automatizado.

Paso 3. Configurar las capabilities para lanzar el test automatizado

Hay que destacar que lo más importante es que tu código de automatización no cambia, es decir, se lanzará igual que si lo tienes en local. Lo que cambia es el endpoint o dirección del Data Center al servidor de Appium.

En una visión tradicional tendríamos un servidor de Appium y nuestro emulador en una máquina local o remota.

"configuración del hub de webdriver"

Y donde tendríamos que realizar los siguientes pasos previos antes de empezar el testing:

  • Tener conectada la máquina de pruebas con un emulador de Android y administrarlo (crearlo, eliminarlo después de la automatización,…)
  • Tener levantado el servidor de Appium en un puerto y administrarlo (levantar antes de la suite de tests, hacerle un shutdown después, mantener toda la infraestructura de drivers como uiAutomator2 para Android, etc.).

Las capabilities quedarían de esta manera indicando la url local del servidor de appium "http://127.0.0.1:4723/wd/hub" y el nombre de emulador "Android Emulator"

DesiredCapabilities capabilities = new DesiredCapabilities();
   capabilities.setCapability("deviceName","Android Emulator");
   capabilities.setCapability("platformVersion", "8.1");
   capabilities.setCapability("platformName", "Android");
   capabilities.setCapability("app", "src/test/files/apks/getConsumerDebug_v4.apk");
   URL url = new URL("http://127.0.0.1:4723/wd/hub");
   AppiumDriver<MobileElement> appiumDriver = new AndroidDriver<MobileElement>(url, 

 

Y en una visión cloud como la que tiene Sauce Labs tenemos un EndPoint donde el servidor de Appium es una dirección remota, siendo totalmente transparente el hecho de lanzar en local o contra el cloud. Gracias a ello nos quitamoscla administración del emulador y del servidor Appium, tal y como podemos observar en esta imagen:

"platform configurator para configurar tu dispositivo"

Por tanto, donde no nos hace falta tener levantado nada ni tener ninguna dependencia de infraestructura, las capabilities quedan de esta manera:

DesiredCapabilities capabilities = new DesiredCapabilities();

   capabilities.setCapability("deviceName","Samsung Galaxy S7 Edge HD GoogleAPI Emulator");
   capabilities.setCapability("platformVersion", "8.1");
   capabilities.setCapability("platformName", "Android");
   capabilities.setCapability("name", "SauceLabsTest");
   capabilities.setCapability("browserName", "");
   capabilities.setCapability( AndroidMobileCapabilityType.APP_PACKAGE,"com.example.getconsumer");
   capabilities.setCapability("app", "sauce-storage:getConsumerDebug_v4.apk");

   URL url = new URL("https://USUARIO:APIKEY@saucelabs.com:443/wd/hub");
   AppiumDriver<MobileElement> appiumDriver = new AndroidDriver<MobileElement>(url, c

 

De todo ello, destacamos lo siguiente:

"configuración del hub de webdriver"

 

"platform configurator para configurar tu dispositivo"

 

Paso 4. Lanzamiento y comprobación de resultados

La ejecución del código de testing automatizado, como hemos comentado anteriormente, se ejecuta tal y como ejecutamos de manera local, invocando en nuestro caso a mvn clean test dado que nuestro proyecto está usando Maven, java y TestNG:

$> mvn clean test
INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running TestSuite
jul 16, 2020 9:10:39 AM io.appium.java_client.remote.AppiumCommandExecutor$1 lambda$0
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 45.078 s - in TestSuite
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 55.082s
[INFO] Finished at: Thu Jul 16 09:10:50 CEST 2020
[INFO] Final Memory: 20M/256M
[INFO] ------------------------------------------------------------------------

 

Se pueden consultar los resultados en la web directamente navegando a Automated → TestResults y buscando por nuestro TestName: SaucelabsTest

Sauce Labs nos proporciona:

  1. Video de la automatización.
  2. Los comandos de Appium lanzados desde el cliente y que se corresponden con el video (commands).
  3. Los logs de android (logcat), del cliente y del servidor de Appium (Logs).
  4. Los datos de la capabilities mandadas desde Sauce Labs y datos sobre la infraestructura cloud. (Metadata).

"Imagen de resultados de una prueba automatizada ejecutada"

 

Como podemos ver en la imagen anterior, solamente hemos hecho un ‘clic’ en el botón "GO TO POKEAPI", y dejando el código completo que se tendrá que añadir a una clase de prueba de TestNG:

public class AndroidAppiumTest{


  @Test
  public void clickButtonTest() throws MalformedURLException {

		//creacion del driver
		DesiredCapabilities capabilities = new DesiredCapabilities();
   		capabilities.setCapability("deviceName","Samsung Galaxy S7 Edge HD GoogleAPI Emulator");
   		capabilities.setCapability("platformVersion", "8.1");
   		capabilities.setCapability("platformName", "Android");
   		capabilities.setCapability("name", "SauceLabsTest");
   		capabilities.setCapability("browserName", "");
   		capabilities.setCapability( AndroidMobileCapabilityType.APP_PACKAGE,"com.example.getconsumer");
   		capabilities.setCapability("app", "sauce-storage:getConsumerDebug_v4.apk");

		URL url = new URL("https://USUARIO:APIKEY@saucelabs.com:443/wd/hub");
		AppiumDriver<MobileElement> appiumDriver = new AndroidDriver<MobileElement>(url, capabilities);
	   


		//se hace un click al boton de "GO TO POKEAPI"
		appiumDriver .findElement(MobileBy.xpath("//*[@text='GO TO POKEAPI']")).click(); 


		// eliminamos la app, liberamos el driver y la sesión de saucelabs terminará
		appiumDriver.removeApp("com.example.getconsumer");
		appiumDriver.quit();
	}


}

 

En este ejemplo se usa las dependencias maven: appium-java-cliente 6.1.0 y testing 6.14.3

<dependency>
    <groupId>io.appium</groupId>
    <artifactId>java-client</artifactId>
    <version>6.1.0</version>
</dependency>
  
<dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>6.14.3</version>
    <scope>test</scope>
</dependency>

 

Conclusiones

Sauce Labs es una herramienta para realizar sobre todo pruebas automatizadas (aunque soporta pruebas manuales o live testing sobre sus máquinas remotas) muy completa y recomendable para evolucionar la automatización de pruebas a un sistema cloud, obteniendo las siguientes ventajas:

  • Aunque podemos perder algo de control sobre la máquina donde desplegamos, ganamos en ahorro de costes en el mantenimiento de emuladores, en servidores de Appium, etc.
  • Podemos hacer pruebas sobre el mismo código en más de 500 emuladores y dispositivos reales en distintos sistemas operativos, emuladores/simuladores de iOS y Android, así como en dispositivos reales. En una infraestructura tradicional esto es muy difícil de mantener, sobre todo si son dispositivos reales.
  • Si tenemos que hacer pruebas Web podemos probar el código en distintos sistemas operativos/emuladores, incluido navegadores dentro de dispositivos móviles.
  • Soporta pruebas de rendimiento y pruebas headless.
  • Incluye un sistema de analíticas.
  • Es integrable con herramientas de Visual Testing, además de las ya comentadas anteriormente en las ventajas de Sauce Labs, como Jenkins, Bamboo o Katalon.

En el caso de que exista una versión iOS de nuestra aplicación con el mismo código Appium podemos lanzar la automatización contra estos sistemas solo cambiando las capabilities. Esto nos permite una gran portabilidad y escalabilidad del testing automatizado.

Posts relacionados

Descubre cómo automatizar Service Tests con Rest-assured

Descubre cómo automatizar Service Tests con Rest...

UIColletionViewLayout---SDOS

Pruebas de rendimiento con JMeter. Ejemplos...

Comentarios
¿Qué opinas? Escríbenos. Nos encantará leerte :)