Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Resumen de la Federación de Comercio

Trade Federation (Tradefed o TF para abreviar) es un marco de prueba continuo diseñado para ejecutar pruebas en dispositivos Android. Por ejemplo, Tradefed se utiliza para ejecutar el Paquete de pruebas de compatibilidad (CTS) y el Paquete de pruebas de proveedores (VTS) .

Trade Federation es una aplicación Java que se ejecuta en una computadora host y se comunica con uno o más dispositivos Android mediante ddmlib (la biblioteca detrás de DDMS) a través de adb.

Hemos enumerado algunas de las características principales de TF a continuación, junto con un par de casos de uso de muestra. Dicho esto, si desea saltar y comenzar, puede dirigirse directamente a la página Comenzar aquí .

Caracteristicas

  • diseño modular, flexible y escalable
  • ha incorporado soporte para ejecutar muchos tipos diferentes de pruebas de Android: instrumentación , uiautomator , native / gtest, JUnit basado en host, etc.
  • proporciona confiabilidad y mecanismos de recuperación además de adb
  • admite la programación y ejecución de pruebas en múltiples dispositivos en paralelo

Consulte Pruebas a través de TF para obtener la información más actualizada sobre cómo ejecutar sus pruebas existentes, como Instrumentación .

Casos de uso

La modularidad de la Federación de Comercio hace que sea sencillo ubicarse en entornos con infraestructuras existentes de construcción, prueba e informes. Enumeramos a continuación algunos casos de uso demostrativos donde tradefed podría permitir prácticas de prueba eficientes y escalables.

Primero, es útil considerar el panorama de posibles casos de uso en términos de la pregunta "¿qué partes son modificables y qué partes son estáticas?" Por ejemplo, un OEM de dispositivo puede modificar el marco, el sistema y el hardware, pero tiene poca o ninguna influencia sobre las aplicaciones existentes. Un desarrollador de aplicaciones, por otro lado, puede modificar la aplicación, pero tiene poco control sobre la mayoría de los aspectos del sistema o el marco.

Como resultado, una entidad en cada caso de uso tendrá diferentes objetivos de prueba y tendrá diferentes opciones en el caso de un conjunto de fallas de prueba. A pesar de estas diferencias, Trade Federation puede ayudar a que cada uno de sus procesos de prueba sea eficiente, flexible y escalable.

OEM del dispositivo

Un OEM de dispositivo crea hardware y, a menudo, modificará el sistema y los marcos de Android para que funcionen bien en ese hardware. El OEM podría esforzarse por lograr esos objetivos mientras conserva la estabilidad y el rendimiento a nivel de hardware y sistema, y ​​se asegura de que los cambios en el marco no rompan la compatibilidad con las aplicaciones existentes.

El OEM podría implementar un módulo de flasheo del dispositivo que se ejecutará durante la etapa de configuración de destino del ciclo de vida . Ese módulo tendría un control completo sobre el dispositivo durante su período de ejecución, lo que le permitiría forzar el dispositivo al gestor de arranque, flashear y luego forzar al dispositivo a reiniciarse en modo de espacio de usuario. Combinado con un módulo para conectarlo a un sistema de compilación continua, esto permitiría al OEM ejecutar pruebas en su dispositivo a medida que realizan cambios en el firmware a nivel del sistema y los marcos a nivel Java.

Una vez que el dispositivo se haya iniciado por completo, el OEM podría aprovechar las pruebas existentes basadas en JUnit, o escribir otras nuevas, para verificar la funcionalidad de interés. Finalmente, podrían escribir uno o más módulos de informes de resultados para vincularlos a los repositorios de resultados de pruebas existentes o para informar los resultados directamente (por ejemplo, por correo electrónico ).

Desarrollador de aplicaciones

Un desarrollador de aplicaciones crea una aplicación que debe ejecutarse bien en una variedad de versiones de plataforma y una variedad de dispositivos. Si surge un problema en una versión o dispositivo de plataforma en particular, el único remedio es agregar una solución alternativa y seguir adelante. Para desarrolladores más grandes, el proceso de prueba podría incorporarse en una secuencia de construcción continua. Para desarrolladores más pequeños, puede iniciarse periódicamente o manualmente.

La mayoría de los desarrolladores de aplicaciones usarían los módulos de instalación de prueba apk que ya existen en TF. Hay una versión que se instala desde el sistema de archivos local , así como una versión que puede instalar aplicaciones descargadas de un servicio de compilación . Es importante tener en cuenta que la última versión continuaría funcionando correctamente con arbitrariamente muchas instancias TF que se ejecutan en la misma máquina host.

Debido a la habilidad de TF para manejar múltiples dispositivos, sería sencillo clasificar cada resultado de la prueba por el tipo de dispositivo que se utilizó para esa prueba. Por lo tanto, TF podría generar una matriz de compatibilidad bidimensional (o multidimensional) para cada compilación de la aplicación.

Servicio de pruebas

Un servicio de prueba podría, por ejemplo, permitir a los desarrolladores de aplicaciones enviar aplicaciones y ejecutar pruebas en dispositivos equipados con herramientas de medición de energía para determinar el uso de energía de la aplicación. Esto difiere de los dos casos de uso anteriores en que el generador de servicios no controla los dispositivos o las aplicaciones que se ejecutan.

Debido a que Trade Federation puede ejecutar cualquier clase de Java que implemente la interfaz IRemoteTest simple, es trivial escribir controladores que puedan coordinar alguna pieza externa de hardware con el caso de prueba que se ejecuta en el dispositivo. El controlador en sí puede generar subprocesos, enviar solicitudes a otros servidores o hacer cualquier otra cosa que pueda necesitar. Además, la simplicidad y versatilidad de la interfaz de informes de resultados, ITestInvocationListener , significa que también es sencillo representar resultados de pruebas arbitrarias (incluidas, por ejemplo, métricas de potencia numérica) en la canalización de informes de resultados estándar.