Cómo probar la aplicación empresarial android en varios dispositivos

Estoy trabajando en una gran aplicación empresarial android y nos estamos preguntando cómo son las otras empresas de pruebas de sus aplicaciones. Tenemos alrededor de 10 tipos de dispositivos, que recomendamos a nuestros clientes, porque es imposible tener todo tipo de dispositivos y probar la aplicación en ellos.

He oído que Eset y Sygic también tienen algunos dispositivos principales soportados en la que es su aplicación probada y en caso de algún error específico del dispositivo, que acaba de obtener ese dispositivo.

Hice algunas investigaciones y encontré algunas herramientas de prueba automatizadas (como TestDroid). ¿Alguien tiene experiencia real con herramientas de prueba automatizadas como TestDroid?

Sería impresionante, si alguien que está trabajando para alguna gran empresa podría compartir los procedimientos de prueba, herramientas, consejos o recomendaciones de cómo probar las aplicaciones empresariales android cuando existen tantos dispositivos con varias versiones del sistema operativo, resoluciones y extensiones del sistema (como HTC Sense, Samsung TouchWiz).

Muchas gracias chicos.

Si forma parte del equipo de desarrollo, y QA más probable de algún otro equipo que podría terminar con dos conjuntos de casos de prueba. Usted tiene que demostrar a su gerente que ha hecho su trabajo y que pasa los casos de prueba y QA hará su parte de las pruebas para mostrar a su gerente de esta aplicación pasar todos los requisitos.

Creo que nuestro equipo de control de calidad está usando un par de estos servicios mencionar aquí de vez en cuando, pero no todas las veces. Cuando, le pregunté me han dicho que no es muy conveniente para ellos a utilizar estos servidores, ya que es muy lento, y sus casos son todos los que no se pudo probar cierta cosa.

Pero de nuestro lado (equipo de desarrollo) no tuvimos presupuesto adicional y no obtuvimos satisfactoria adelante de QA y también del desarrollador que estudió estos servicios al lado de nuestro requisito. Por lo tanto, terminamos haciendo nuestra propia automatización de prueba. Que tomó exactamente dos días.

  1. Usando GIT,
  2. Jenkins
  3. ADB
  4. Script de lote / shell.

Por lo tanto, cada vez que terminamos una característica y sus casos de prueba de unidad, marcamos esa característica como completa en el rastreador de problemas. El desarrollador empuja el código a un sistema de control de versiones.

A la mañana siguiente, cuando un desarrollador viene a trabajar, él o ella ir al panel de Jenkins y comenzar una construcción. Jenkins acaba de ejecutar un archivo por lotes que hace lo siguiente,

  1. Descargar el último código de GIT. Utiliza un comando git.
  2. Actualizar id de versión.
  3. Ejecute el proceso de compilación de la línea de comandos de Android para crear la aplicación.
  4. Siga los mismos pasos para la aplicación de prueba de unidad.
  5. Instale ambas aplicaciones en un dispositivo o dispositivos conectados a ese servidor.
  6. Ejecute la aplicación de prueba utilizando ADB en dichos dispositivos.
  7. Recoja el registro de prueba de la unidad (estilo Junit).
  8. Envíe el registro a todas las partes interesadas.

Esto también es lo mismo para las pruebas de estrés. Pero, si hace pruebas de estrés durante la noche puede recoger megabytes de registro, en ese caso la búsqueda de palabras clave base es definitivamente una buena idea para encontrar accidentes.

Para las pruebas de diseño / resolución, siempre puede tomar la captura de pantalla utilizando adb o de la aplicación de prueba de unidad y adjuntar esas imágenes como adjuntos de correo electrónico también.

Definitivamente, el uso de un servicio de terceros facilitará la tarea y siempre podemos subcontratar lo que necesitamos. Pero recuerde que son casos cuando las pruebas manuales son absolutamente necesarias. Al igual que si tu aplicación desea activar Wi-Fi o cualquier cosa desde la Settings Android que requiera la entrada explícita del usuario, o los casos en que estás usando otro recurso, como usar la cámara para tomar fotografías o probar la integración de redes sociales. Asegúrese de comparar sus necesidades con el servicio que ofrecen las entidades empresariales.

Debajo de la información es la conclusión de nuestras experiencias;

La mejor manera de soportar grandes cantidades de dispositivos es probar tu aplicación con tus propios dispositivos de prueba. Para el proyecto de la empresa grande usted debe pensar para cubrir la mayor parte del usuario actual si la compañía no tiene grupo específico del dispositivo.

Hay una manera de decidir dispositivos superiores por debajo del método;

Debe comprobar la página del panel de control de estadísticas de android para obtener información para comprender la mayoría de las especificaciones del dispositivo. La manera simple de hacer esto es tomando la combinación de estadísticas de investigación de las Versiones de la Plataforma (según las Distribuciones) && Tamaños y Densidades de la Pantalla.

Entonces usted tiene una lista aproximada de dispositivos populares y debe poseer tanto como de ellos.

Si su presupuesto no es suficiente para comprar un montón de dispositivo que puede optar por externalizar las pruebas de algunas empresas como testDroid, etc Pero no recomiendo que, debido a la prueba automatizada general lo que han hecho no es suficiente para su aplicación y cuando hay un Picazón bug aparece usted debe tener este dispositivo para asegurarse de que está arreglado.

Aunque decidimos utilizar nuestros dispositivos para la prueba, hemos intentado el outsourcing en pasado, y hay 3 superiores de nuestra opción;

En realidad, hay un montón de herramientas para las pruebas automatizadas de las aplicaciones de Android. Echa un vistazo a una pequeña visión general de las herramientas más populares que los probadores Android utilizan para las pruebas automatizadas: http://blog.bughuntress.com/automated-testing/useful-tools-for-android-apps-test-automation . Mirando a través de ellos, probablemente encontrará algo útil. Todos ellos son comúnmente utilizados para la automatización de pruebas en grandes empresas.

Github hook => Jenkins => TestFlight envía correos electrónicos a probadores manuales + comienza la prueba Robotium usando Spoon.

Después de algún tiempo todos los informes van a PM y equipo de desarrollo, en caso de éxito firmado apk va a publicar

  • ApplicationTestCase obsoleto en el nivel 24 de API
  • La forma más rápida de probar el código fuente de Android modificado?
  • ¿Cómo puedo comprobar en Robotium que la aplicación ha terminado?
  • Envío de mayúsculas a un TextEdit durante pruebas instrumentadas
  • ¿Cómo forzar un cambio de orientación en una prueba de instrumentación de Android?
  • Problema con Android IAP, sin OrderID en el objeto de compra
  • Mockito en el emulador de Android
  • Prueba de GPS en Android
  • ¿Cómo enviar eventos clave a un emulador sin cabeza en una prueba de instrumentación?
  • Saltar prueba para la variante de construcción específica en Android + Gradle?
  • Carpeta de activos en Android Studio Unit Test
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.