Hoy, cuando cada residente de una megalópolis tiene una computadora en su bolsillo que puede hacer mucho más que volar a la luna , usamos aplicaciones móviles todos los días. Noticias, clima, promociones, compras: todas estas funciones se implementan en cientos de miles de aplicaciones. Pero si su aplicación favorita se congela o se bloquea, rápidamente deja de ser su favorita.
Este artículo fue escrito por los chicos de
WaveAccess.Llevamos más de 10 años desarrollando aplicaciones móviles y no podemos darnos el lujo de lanzar un producto que esté en manos de los usuarios. Es por eso que "bombear" el equipo de pruebas y la infraestructura no es menos importante para nosotros que otras áreas.
Cientos de dispositivos Android, iPhones con diferentes versiones del sistema operativo y una diagonal diferente de dispositivos representan el desafío para los ingenieros de control de calidad de "detectar" defectos en dispositivos móviles reales y en diferentes versiones de sistemas operativos. Pero pocas personas pueden ejecutar el mismo script manual en 10, 20, 50 dispositivos. Gracias a tales tareas, aumentamos nuestra habilidad de pruebas automáticas, especialmente en dispositivos móviles. Pero seamos honestos: crear y mantener la infraestructura incluso con 20 dispositivos reales para ejecutar pruebas automáticas es un dolor de cabeza.
En este artículo queremos decir cómo probamos el nuevo servicio Microsoft App Center para nosotros mismos para verificar la calidad de la aplicación que estamos desarrollando en el zoológico de dispositivos reales.
¿Por qué surgió la pregunta de usar el servicio?
Ahora estamos desarrollando una aplicación para apoyar las compras. El proyecto ha estado en marcha durante mucho tiempo: el cliente ofrece constantemente algunas características nuevas, solo está desarrollando para el desarrollo. Ya hay docenas de pantallas en la aplicación, desde "comprar" hasta varias opciones de mensajes, empujar, "recoger su arco" funciones. Y todo este tiempo, se realizan presentaciones del proyecto a los inversores, lanzamientos en nuevos centros comerciales, por lo que cuanto mayor sea la velocidad de lanzamiento (sin una caída en la calidad del producto), mejor.
Hasta ahora, realizamos pruebas automáticas en un número limitado de dispositivos que estaban a nuestra disposición (para este proyecto, unos 30 dispositivos Android y "manzanas"). Ahora la aplicación está alcanzando un nuevo nivel, la audiencia ha crecido y la calidad se ha vuelto aún más crítica. La pregunta surgió sobre el uso de un servicio en la nube para ejecutar pruebas automáticas en más dispositivos diferentes.
En el proceso de lanzamientos, quería utilizar todas las prácticas modernas y probadas de desarrollo de software: revisión cruzada, integración continua, pruebas funcionales y unitarias automatizadas en una gran lista de dispositivos en iOS + Android, colección de análisis y crashlytics.
Hemos aplicado cada una de estas prácticas anteriormente, tanto individualmente como en combinación. Pero dada la escala del proyecto y el gran tamaño del equipo, quería obtener una solución universal. Permita que la herramienta pueda hacer todo lo anterior y, en un solo lugar, puede brindar la oportunidad de administrar el estado de desarrollo y entrega de aplicaciones móviles para diferentes plataformas y monitorearlo.
Cada uno de los roles en el equipo tenía sus propias condiciones: los desarrolladores no querían cambiar el proceso de desarrollo ya establecido (repositorio, herramienta de compilación, etc.), ni cambiar a herramientas demasiado nuevas y no verificadas en el producto. Los ingenieros de pruebas soñaron con reducir la carga en los dispositivos de verificación en el zoológico, los gerentes y el cliente querían una interfaz conveniente para monitorear todo el estado con flujo transparente.
El estudio de los análogos es una etapa bastante importante en la elección de una herramienta. Analizamos varios servicios que brindan tales capacidades (para pruebas de Appium, por ejemplo, BrowserStack). En el caso del Centro de aplicaciones de Microsoft, nos dieron un período de prueba, por lo que tuvimos la oportunidad de intentar comprender qué sucederá con el proyecto si dedicamos un poco más de recursos a la calidad y automatizamos todo el proceso de lanzamiento de la aplicación móvil para cualquier plataforma con un solo servicio. Te contamos cómo fue.
Cómo configurar la aplicación de iOS
Entonces, utilizando el período de prueba, que no impone restricciones en la funcionalidad, creamos nuestra aplicación iOS en el Centro de aplicaciones de Microsoft:
Elige una plataforma:
Agregue el SDK de App Center al proyecto:
pod 'AppCenter'
Después de instalar los hogares, abra el archivo AppDelegate.swift y agregue las siguientes líneas bajo su propio comando de importación:
import AppCenter import AppCenterAnalytics import AppCenterCrashes
En el mismo archivo, agregue las siguientes líneas al método didFinishLaunchingWithOptions:
MSAppCenter.start("{Your App Secret}", withServices:[ MSAnalytics.self, MSCrashes.self ])
Un proceso similar es para el objetivo C, la versión completa de la instrucción está aquí .
Buildim!
Vaya a la pestaña Construir, seleccione nuestro servicio svc.
Configurar la compilación. No olvide firmar, ya que esto nos genera un archivo de aplicación en formato de aplicación que se puede ejecutar en dispositivos reales:
Hecho Haga clic en el botón Construir ahora y espere la compilación.
Una historia similar para las aplicaciones de Android, la instrucción está aquí .
Lanzamos las primeras pruebas para iOS
Las pruebas unitarias y nativas para cada plataforma se pueden incluir en el ensamblaje (hay una marca de verificación). A continuación, le informamos sobre la funcionalidad de AT en diferentes dispositivos.
Configure un conjunto de dispositivos iOS, Android, enviando pruebas a un conjunto
Vaya a la pestaña Prueba, Conjuntos de dispositivos. Creamos un conjunto de dispositivos en los que manejaremos nuestras pruebas. Hay más de 250 dispositivos Android para elegir y más de 200 dispositivos iOS diferentes (versión de generación + versión de iOS). Una lista detallada de dispositivos está aquí .
Aquí fue un poco decepcionante que la respuesta oficial a la pregunta, qué tan pronto después del lanzamiento aparecerán los nuevos dispositivos Apple, suene como "1-2 meses después de la venta".
Preparamos las pruebas para su lanzamiento en App Center (un ejemplo para XCUITest) y las enviamos para su lanzamiento. App Center tiene la capacidad de crear solo aplicaciones, por lo que aún tiene que construir el proyecto de prueba localmente en su máquina o en su CI.
Shell: # Generate an XCUITest bundle and your iOS application as described above. $ rm -rf DerivedData $ xcrun xcodebuild build-for-testing -derivedDataPath DerivedData -scheme YOUR_APP_SCHEME # Upload your test to App Center $ appcenter test run xcuitest \ --app "<app center username/<app name>" \ --devices DEVICE_SET \ --test-series "master" \ --locale "en_US" \ --build-dir DerivedData/Build/Products/Debug-iphoneos
Pruebas de Appium
Vale la pena asegurarse de que los marcos de prueba utilizados sean consistentes con los compatibles. Además, debe usar el controlador proporcionado por App Center, y esto impone sus limitaciones en el uso de marcos (por ejemplo, Google Giuce no se puede usar).
Proyecto Build para usuarios de Maven
Paso 1. Agregar un repositorio y dependencias
Deberá agregar el repositorio de JCenter al archivo pom.xml.
XML <repositories> <repository> <id>jcenter</id> <url>https://jcenter.bintray.com/</url> </repository> </repositories>
Luego agregue una dependencia para extensiones de pruebas de Appium
XML <dependency> <groupId>com.microsoft.appcenter</groupId> <artifactId>appium-test-extension</artifactId> <version>1.3</version> </dependency>
Por lo tanto, durante la compilación, los controladores extendidos de Android e iOS estarán disponibles (que son necesarios, en primer lugar, para implementar la función de "etiqueta"; más sobre esto en el Paso 4).
Paso 2. Agregar un perfil de arranque
Copie el fragmento en su pom.xml en <profiles>. Si falta la sección <profiles> en el archivo pom, debe crearla. Después de la activación, el perfil empaqueta nuestras clases de prueba y todas las dependencias en la carpeta de destino / carga, listo para cargar en TestCloud.
Construido para usuarios de Gradle
Paso 1. Repositorio y dependencias
Nos aseguramos de que en el build.gradle en la carpeta raíz del proyecto se active el repositorio JCenter:
gradle allprojects { repositories { jcenter() } }
Agregue el siguiente fragmento a build.gradle en la carpeta de la aplicación:
gradle androidTestCompile('com.microsoft.appcenter:appium-test-extension:1.0')
A partir de Gradle 3.0, androidTestCompile está en desuso . En cambio, necesitas androidTestImplementation.
Paso 2. Automatiza la generación del archivo pom
Para que el cargador funcione, se requiere el archivo pom.xml. Agregue el siguiente fragmento en build.gradle en la carpeta de la aplicación para que el archivo pom se recopile automáticamente:
gradle apply plugin: 'maven' task createPom { pom { withXml { def dependenciesNode = asNode().appendNode('dependencies') //Iterate over the compile dependencies (we don't want the test ones), adding a <dependency> node for each configurations.testCompile.allDependencies.each { def dependencyNode = dependenciesNode.appendNode('dependency') dependencyNode.appendNode('groupId', it.group) dependencyNode.appendNode('artifactId', it.name) dependencyNode.appendNode('version', it.version) } def profilesNode = asNode().appendNode('profiles') profilesNode.append(new XmlParser().parse('https://raw.githubusercontent.com/Microsoft/AppCenter-Test-Appium-Java-Extensions/master/gradleuploadprofilesnippet.xml')) } }.writeTo("pom.xml")
Probar cambios
Paso 1. Agregar importaciones
Importe paquetes a sus clases de prueba:
Java import com.microsoft.appcenter.appium.Factory; import com.microsoft.appcenter.appium.EnhancedAndroidDriver; import org.junit.rules.TestWatcher; import org.junit.Rule;
Paso 2. Crear una instancia de TestWatcher
Agregue a cada clase de prueba de regla JUnit (o la clase de prueba base):
Java @Rule public TestWatcher watcher = Factory.createWatcher();
Paso 3. Cambiar el tipo de controlador
Cambie el tipo de controlador cuando se declara, ya sea desde AndroidDriver <MobileElement> a EnhancedAndroidDriver <MobileElement>, o desde IOSDriver <MobileElement> a EnhancedIOSDriver <MobileElement>
Java private static EnhancedAndroidDriver<MobileElement> driver;
Paso 4. Actualización de instancias de controladores
Cambiamos las instancias del controlador para que las líneas del formulario:
Java driver = new AndroidDriver<MobileElement>(url, capabilities);
... cambiado en apariencia:
Java driver = Factory.createAndroidDriver(url, capabilities);
El uso de estos controladores aún le permitirá ejecutar pruebas localmente sin modificaciones adicionales, pero además le permitirá agregar una "etiqueta" a los pasos en una prueba ejecutable usando driver.label ("su texto"). El texto y la captura de pantalla del dispositivo estarán disponibles en el informe de prueba en Test Cloud. Se recomienda encarecidamente que acceda a la etiqueta a través del método Después , ya que esto agregará una captura de pantalla del último estado de la aplicación al informe de prueba.
Se tomará una captura de pantalla incluso si la prueba falla. Como regla, hay suficiente información para comprender por qué sucedió esto. Un ejemplo de implementación en el método After :
Java: @After public void TearDown(){ driver.label("Stopping App"); driver.quit(); }
Descargar a prueba de App Center
El proceso de carga es el siguiente:
- Genere el comando de carga de prueba de App Center. Documentación (EN): inicio de una ejecución de prueba .
- Empaquetamos clases de prueba y todas las dependencias en la carpeta de destino / carga
cáscara:
- mvn -DskipTests -P paquete de preparación para la carga
- Descarga y ejecución de pruebas iniciadas
Al finalizar, podemos ver los resultados en cada dispositivo de la lista:
Pantallas con resultados, registros, informes
En cada uno de los dispositivos iOS o Android, puede ver un registro detallado y una captura de pantalla para diagnosticar un bloqueo de prueba:
Además de las estadísticas de todos los lanzamientos en un intervalo de tiempo:
Es cierto que no se proporciona acceso al "dispositivo" para depuración e inspección. Si algo sale mal con las pruebas y los registros no son suficientes, todo se decide solo a través del soporte. En uno de los servicios populares para lanzar AT en dispositivos, BrowserStack, existe esa oportunidad y está integrada en Appium. Se podría dar la URL y el puerto para crear una conexión con el servidor del dispositivo.
Conclusiones
Sorprendentemente, todo el proceso de lanzamiento, desde la integración continua hasta la entrega continua de la aplicación, se proporciona en un solo lugar: Microsoft App Center ofrece compilación, prueba, implementación de CI para almacenar, análisis, crashlytics.
Habiendo probado menos de la mitad de la funcionalidad propuesta, el equipo causó una buena impresión. De las ventajas obvias: no es necesario escribir soporte para cada dispositivo en forma de código. Bueno, otras golosinas por favor:
- No es necesario elevar el servidor para una multitud de dispositivos.
- No es necesario conectar dispositivos 100500 a este servidor.
- No es necesario vivir con problemas técnicos de Android cuando está activado 24 \ 7.
- No es necesario ensamblar un contenedor para el dispositivo, no es necesario administrar estos contenedores.
- No hay necesidad de soportar emuladores limitados.
Microsoft App Center nos organizó según los parámetros iniciales: no es muy exigente en términos de integración, pero proporciona todas las funciones solicitadas, eliminando el difícil soporte. Tenemos la intención de utilizar el servicio en el proyecto, ya que resuelve las tareas de las herramientas y garantiza la calidad.