Artículo
12/22/2016

Connect(); 2016

Volumen 31, número 12

Mobile Test de Connect();: Scale Your Automated Mobile App Testing with Xamarin Test Cloud (Escalar las pruebas automatizadas de la aplicación móvil con Xamarin Test Cloud)

Por Justin Raczak; 2016

En los últimos años, ha habido un cambio drástico en la forma de compilar y entregar software de los equipos. Antes se creía que los largos procesos de recopilación de requisitos garantizaban la entrega de un producto perfecto en su primera versión, pero ahora se sabe que un aprendizaje rápido, unido a una iteración ágil, es la clave del éxito. A media que el pensamiento evoluciona, también deben hacerlo los flujos de trabajo. Los ciclos de trabajo que duran meses o años y van seguidos de interminables fases de QA no facilitan un aprendizaje rápido. Los bucles de comentarios se deben reducir y los pequeños cambios se deben implementar rápidamente y ofrecerlos a los usuarios. Para realizar una implementación sin problemas, se debe saber que el software está en buen estado en todo momento. Esto se consigue con la automatización de las pruebas.

Las pruebas automatizadas le permiten probar sus aplicaciones de un modo que solía requerir días o semanas. En lugar de esperar hasta el final de un sprint compuesto por cientos de líneas de código nuevo, puede probar los pequeños cambios que se agregan con cada confirmación. Estas pruebas continuas detectan los defectos en cuanto se introducen y reducen el tiempo necesario para su depuración. Además, dado que el comportamiento de la aplicación se valida continuamente, tiene la seguridad de que realiza la implementación para los usuarios cuando está lista. Las pruebas automatizadas facilitan un mundo en el que descubre defectos y envía una corrección en el mismo día. Pero el ecosistema móvil presenta retos únicos con una amplia variedad de dispositivos móviles y fabricantes de SO.

Xamarin Test Cloud permite escalar las pruebas automatizadas de un modo rápido y sencillo con cambios mínimos en el flujo de trabajo existente. Con más de 400 configuraciones de dispositivo únicas, Test Cloud le permite validar el comportamiento de la aplicación en los modelos de dispositivo y versiones de SO más importantes para los usuarios sin los gastos ni los costos generales de administración asociados con la compilación y administración de un laboratorio de dispositivos propio. En la mayoría de casos, puede acceder a este gran valor con pocos o ningún cambio en su código.

Test Cloud admite pruebas de creación en C# (UITest), Ruby (Calabash) y Java (Appium y Espresso). En la parte de modificación de proyecto de este artículo, me centraré en nuestra adición de marco de prueba más solicitada, Appium con JUnit, y describiré los cambios que debe hacer en el proyecto para ejecutar las pruebas existentes en Test Cloud. También echaré un vistazo a la interfaz web desde la que revisará los resultados de pruebas y solucionará los problemas de las pruebas que generen errores. Las modificaciones específicas requeridas pueden cambiar con el tiempo. La versión más reciente de estas instrucciones está disponible aquí: bit.ly/2dhp2VQ.

En este ejemplo, se asumen las siguientes condiciones previas:

Una cuenta de Test Cloud activa (puede suscribirse en bit.ly/2e3YgTy)
Una herramienta de línea de comandos instalada (las instrucciones están disponibles en bit.ly/2dcrbXS)
Un proyecto de aplicación nativa de Android
Un conjunto existente de pruebas de Appium escritas en Java con JUnit (versión mínima: 4.9) conforme con Appium 1.5
Sistema de compilación de Maven (versión mínima: 3.3.9)

Cambios del sistema de compilación

Para poder empezar a usar Test Cloud, necesita agregar la dependencia para garantizar que las tareas para preparar los archivos de requisito estén disponibles para la compilación.

Agregar la dependencia de Test Cloud Para incluir Test Cloud en el proyecto y garantizar que sus controladores mejorados para Android e iOS estén disponibles en el momento de la compilación, agregue la dependencia siguiente al archivo pom.xml:

<dependency>
  <groupId>com.xamarin.testcloud</groupId>
  <artifactId>appium</artifactId>
  <version>1.0</version>
</dependency>

Agregar el perfil de carga Agregue el perfil de la Figura 1 a pom.xml dentro de la etiqueta <profiles>. Si aún no tiene ninguna sección <profiles>, cree una y agregue el perfil. Este perfil empaquetará las clases de prueba y todas las dependencias en la carpeta de destino o carga, desde donde se podrán cargar a Test Cloud.

Figura 1 Perfil de carga de Test Cloud

<profile>
  <id>prepare-for-upload</id>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <version>2.10</version>
        <executions>
          <execution>
            <id>copy-dependencies</id>
            <phase>package</phase>
            <goals>
              <goal>copy-dependencies</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}
                /upload/dependency-jars/</outputDirectory>
              <useRepositoryLayout>true</useRepositoryLayout>
              <copyPom>true</copyPom>
            </configuration>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <executions>
          <execution>
            <id>copy-pom-file</id>
            <phase>package</phase>
            <goals>
              <goal>testResources</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}
                /upload/</outputDirectory>
              <resources>
                <resource>
                  <directory>
                    ${project.basedir}
                  </directory>
                  <includes>
                    <include>pom.xml</include>
                  </includes>
                </resource>
              </resources>
            </configuration>
          </execution>
          <execution>
            <id>copy-testclasses</id>
            <phase>package</phase>
            <goals>
              <goal>testResources</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}
                /upload/test-classes</outputDirectory>
              <resources>
                <resource>
                  <directory>
                    ${project.build.testOutputDirectory}
                  </directory>
                </resource>
              </resources>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

Cambios en las pruebas

Ahora que ya ha configurado la compilación, debe modificar las clases de prueba para aprovechar las extensiones de Java de Test Cloud.

Agregar las importaciones a las clases de prueba Importe los paquetes siguientes a las clases de prueba:

import com.xamarin.testcloud.appium.Factory;
import com.xamarin.testcloud.appium.EnhancedAndroidDriver;
import org.junit.rules.TestWatcher;
import org.junit.Rule;

Crear una instancia de TestWatcher Inserte la instancia en una de las clases de prueba:

@Rule
public TestWatcher watcher = Factory.createWatcher();

Actualizar las declaraciones de controlador Sustituya todas las declaraciones de AndroidDriver<MobileElement> por EnhancedAndroidDriver<MobileElement>, como se muestra a continuación:

private static EnhancedAndroidDriver<MobileElement> driver;

Actualizar las instancias de controlador Reemplace todas las instancias del controlador de modo que las líneas con este formato:

Driver = new AndroidDriver<MobileElement>(url, capabilities);

se transformen en:

Driver = new EnhancedAndroidDriver<MobileElement>(url, capabilities);

El controlador mejorado le permite "etiquetar" los pasos de la prueba con driver.label("myTestStepLabel"). Este método produce una etiqueta de paso de prueba y una captura de pantalla complementaria que se podrá ver en el informe de prueba de Test Cloud. Recomiendo llamar a la etiqueta del método @After, que hará una captura de pantalla de la aplicación en su estado final antes de finalizar la prueba. La captura de pantalla se hará incluso si se produce un error en la prueba, lo que podría proporcionar información importante sobre el motivo del error. En la práctica, podría tener un aspecto como este:

@After
  public void tearDown(){
    driver.label("Stopping app");
    driver.quit();
  }

Cargar a Test Cloud

Ahora que el proyecto ya está equipado con todos los requisitos previos, está listo para preparar los archivos y realizar una ejecución en Test Cloud. Antes de continuar con los pasos de carga, es una buena idea probar una ejecución local para asegurarse de que todo funciona como se espera. Si necesita solucionar los problemas de los cambios de configuración que acaba de hacer, es mucho más rápido hacerlo localmente.

Para empaquetar las clases de prueba y todas las dependencias en la carpeta de destino o carga, ejecute el comando siguiente:

mvn –DskipTests -P prepare-for-upload package

Es recomendable comprobar que el directorio de destino o carga existe en la carpeta raíz del proyecto para asegurarse de que está preparado para realizar la carga. Si se trata de una aplicación nueva en Test Cloud, tendrá que crearla como parte de la ejecución de prueba. Siga el flujo para crear una ejecución de prueba nueva para seleccionar los dispositivos, definir las preferencias y generar el comando que necesitará para realizar la ejecución. Para este ejercicio, recomiendo seleccionar una pequeña cantidad de dispositivos de la categoría de nivel 1 para que los resultados estén listos para revisarlos rápidamente. Copie el comando generado y ejecútelo en la línea de comandos.

Después de negociar y validar correctamente la carga de archivos, los dispositivos se aprovisionarán, la aplicación se instalará y las pruebas se ejecutarán. El modelo de funcionamiento de Test Cloud se basa en la simultaneidad de dispositivos o la cantidad de dispositivos físicos que se pueden usar en paralelo. Por ejemplo, un usuario con cinco dispositivos simultáneos puede probar una aplicación en los modelos Nexus 5X, Nexus 6P, Samsung Galaxy S5, Samsung Galaxy S6 y HTC M8 al mismo tiempo. Esta eficiencia es una de las ventajas más significativas de Test Cloud y facilita la ampliación de la cobertura para abarcar más dispositivos sin apenas aumentar el tiempo de espera adicional.

La herramienta de línea de comandos transmitirá actualizaciones sobre el estado de la ejecución de prueba y le proporcionará un vínculo al informe de prueba al finalizar la ejecución. Siga el vínculo del informe de prueba proporcionado para examinar los resultados.

Hay tres niveles de granularidad posibles para ver los resultados:

Informe general.
Cuadrícula de dispositivos.
Informe detallado de dispositivos.

Los describiré de uno en uno.

Informe general El informe general proporciona información resumida sobre una ejecución de prueba, incluidos los detalles sobre si se ejecutó correctamente o con errores, las estadísticas de error por versión del SO, el fabricante y factor de forma, además de los detalles sobre la propia ejecución como las configuraciones de dispositivo de destino y el tiempo de ejecución total (consulte la Figura 2).

Figura 2 Informe general

Si se producen errores durante la ejecución de prueba, es probable que quiera profundizar para examinar las causas raíz y recopilar datos para la depuración. La cuadrícula de dispositivos es el siguiente nivel de detalle.

Cuadrícula de dispositivos La cuadrícula de dispositivos es un mecanismo muy eficiente para navegar por los resultados de pruebas paso a paso y consultar las capturas de pantalla realizadas a lo largo de todo el proceso. Dado que los errores se indican claramente en los pasos de la prueba, puede saltar rápidamente a un paso con error y examinar el estado visual de la aplicación en cada dispositivo. En el caso de grandes conjuntos de datos, puede filtrar los dispositivos que se muestran para que solo aparezcan los que sufrieron errores. De este modo, se crea un campo de inspección más limpio. Si la causa del error no se revela con este nivel de detalle, puede explorar en profundidad el siguiente nivel para consultar los detalles de los dispositivos (consulte la Figura 3).

Figura 3 Informe de cuadrícula de dispositivos

Informe detallado de dispositivos El informe detallado de dispositivos le proporciona el mismo acceso a la navegación por los pasos de prueba y las capturas de pantalla, pero proporciona detalles adicionales específicos sobre el dispositivo seleccionado, incluida la CPU y el uso de memoria. Desde esta vista, también puede acceder a los registros del dispositivo y el seguimiento de la pila, que resultarán muy útiles a la hora de investigar un error durante la prueba (consulte la Figura 4).

Figura 4 Informe detallado de dispositivos

En este punto, he seguido el flujo de trabajo más común en Test Cloud:

Ejecutar la prueba (manualmente o a través de la integración continua o CI).
Revisar los resultados.
Recuperar los recursos de depuración.
Corregir.

A continuación, describiré algunas formas sencillas de pensar en la estrategia orientada a dispositivos y de optimizar el rendimiento del flujo de trabajo de prueba para que la canalización fluya rápidamente.

Considerar la cobertura de dispositivos

Seleccionar los dispositivos que admitirá la organización y con los que realizará las pruebas es casi tan importante como realizar la propia prueba. Aunque hay muchos orígenes de datos de mercado agregados y generalizados que pueden ayudarle a orientar sus consideraciones en esta área, el origen de mayor impacto son los datos de uso de su propia base de usuarios. La excepción a esto es, por supuesto, una aplicación que solo se distribuye internamente a un conjunto de dispositivos conocidos y administrados. Para aplicaciones externas y de consumidor, así como para aplicaciones internas distribuidas según la directiva Bring Your Own Device (BYOD), los datos de uso son el mejor origen.

Muchas herramientas del mercado le pueden ayudar a obtener información sobre los dispositivos que usa su público. Este es el conjunto de datos desde el que puede extrapolar la lista de dispositivos compatibles. La metodología exacta que use para determinar los dispositivos que admitirá a partir de la lista agregada depende de usted y de su organización. En la mayoría de casos, no tendrá sentido admitir todos los dispositivos de los datos de uso, ya que resultaría difícil y caro. Puede decidir cubrir tantos dispositivos como sea necesario para abarcar cierto porcentaje de la base de usuarios. También puede decidir pensar en términos de cantidad de usuarios y admitir tantos dispositivos como sea necesario para dejar cubiertos menos de 500 dispositivos de usuario. Si tiene una aplicación de comercio electrónico, puede hacer referencias cruzadas de los datos de uso con los datos de transacciones para asegurarse de cubrir los dispositivos que representan el mayor gasto y las transacciones más frecuentes. De nuevo, el enfoque específico que siga para desarrollar la lista de dispositivos compatibles se debe basar en las necesidades y los objetivos de la empresa.

Tenga en cuenta que el mercado de dispositivos móviles avanza rápidamente. Esto significa que, para que la lista de dispositivos compatibles sea precisa y significativa, debe examinar sus datos de uso con regularidad. Busque señales en el mercado que puedan sugerir que es un buen momento para volver a revisar los datos, como el lanzamiento de un nuevo modelo de dispositivo o SO.

Optimizar la canalización de prueba

La mejor forma de extraer el máximo valor de la automatización de las pruebas es realizarlas pronto y con frecuencia. Esto reduce el tiempo y el costo asociado con la corrección de errores y garantiza que la canalización de implementación esté despejada. Sin embargo, a medida que los equipos y las operaciones se escalan, la latencia puede aumentar en la canalización y la productividad de desarrollo puede bajar. Veamos algunas formas de mantener la canalización despejada y una productividad elevada.

No todas las pruebas son iguales A medida que los proyectos crecen con el tiempo, sus conjuntos de pruebas tardan más en ejecutarse. Hay un punto de inflexión en el que ejecutar el conjunto de pruebas después de hacer un cambio sencillo resulta difícil e incómodo y, a menudo, da pie a malos hábitos, como omitir las pruebas por completo. Para prevenirlo, piense en la ruta crítica de la aplicación, es decir, ¿qué flujos o experiencias de la aplicación deben funcionar incuestionablemente? Si usamos el ejemplo anterior de aplicación de comercio electrónico, esto puede significar que los usuarios puedan examinar los productos, agregarlos al carro y finalizar la compra. Es menos importante que los usuarios puedan definir sus preferencias de notificación. Con esta estructura en mente, resulta más práctico ejecutar pruebas después de cada inserción o, incluso, después de cada confirmación. En lugar de ejecutar el conjunto de pruebas completo para cambios pequeños, puede ejecutar solo las que formen parte de la ruta crítica. Cómo consiga esta delineación, exactamente, dependerá del marco de prueba que use.

Los dispositivos adecuados en el momento adecuado Aunque ejecutar la prueba de todas las inserciones de una rama de característica puede ser idóneo desde la perspectiva de calidad, pronto resulta caro para los grandes equipos, especialmente para aquellos que admiten distintas configuraciones de dispositivos. Para reducir la sobrecarga, puede aplicar una estrategia progresiva a los dispositivos de destino en estas ejecuciones de prueba. ¿Es necesario probar una compilación de una rama que no es de producción en cada dispositivo que admita? Probablemente, la respuesta es no. En lugar de eso, puede seleccionar una cantidad razonable de dispositivos que equilibre unas pruebas eficaces con tiempos de espera inferiores. En el caso de una compilación de CI previa a la producción, un muestreo de los modelos de dispositivo y versiones de SO más populares de la lista de dispositivos compatibles proporcionará un nivel de cobertura valioso sin elevar el tiempo de compilación a más de una hora. En el caso de pruebas de un desarrollador individual desde una estación de trabajo local, puede que realizar las pruebas en uno o dos dispositivos sea suficiente.

Estos son algunos ejemplos de formas de pensar sobre la configuración del flujo de trabajo de prueba. Otra cuestión más general es la necesidad de invertir tiempo en cuestionar si el flujo de canalización actual es el óptimo. Incluso si ya ha respondido antes a esta pregunta, como en todo lo que haga, es buena idea realizar una inspección y adaptación rutinarias.

Resumen

En este artículo, ha visto lo fácil que es migrar de ejecutar las pruebas en un simulador o dispositivo local único a aprovechar la eficacia de cientos de configuraciones de dispositivos con Xamarin Test Cloud. También he descrito algunas estrategias para organizar el flujo de trabajo de prueba y extraer el máximo valor de los recursos de prueba. Si aún no usa Test Cloud, puede registrarse para una evaluación gratuita en bit.ly/2e3YgTy y empezar a usarlo con sus proyectos.

Justin Raczak es administrador de programas senior en Microsoft y dirige el servicio de automatización de pruebas móviles. Aunque se unió a Microsoft recientemente, se ha centrado en las pruebas automatizadas y su rol en el progreso de la entrega continua durante los últimos tres años. Puede ponerse en contacto con él en justin.raczak@microsoft.com.

Gracias al siguiente experto técnico de Microsoft por revisar este artículo: Simon Søndergaard
Simon Søndergaard es ingeniero de software en Microsoft.