Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
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 Compatibility Test Suite (CTS) y Vendor Test Suite (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 usando ddmlib (la biblioteca detrás de DDMS) sobre adb.

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

Caracteristicas

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

Consulte Prueba 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 Trade Federation hace que sea sencillo encajar en entornos con infraestructuras de creación, prueba e informes existentes. A continuación, enumeramos algunos casos de uso demostrativos en los que tradefed podría permitir prácticas de prueba eficientes y escalables.

En primer lugar, es útil considerar el panorama de casos de uso potenciales en términos de la pregunta "¿qué partes son modificables y qué partes son estáticas?" Por ejemplo, un OEM de dispositivos 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 dispositivos crea hardware y, a menudo, modifica el sistema y los marcos de Android para que funcionen bien en ese hardware. El OEM podría esforzarse por lograr esos objetivos al tiempo que conserva la estabilidad y el rendimiento en los niveles 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 actualización 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 potencialmente forzar el dispositivo en el cargador de arranque, flashear y luego forzar al dispositivo a reiniciarse nuevamente en el modo de espacio de usuario. Combinado con un módulo para vincularlo a un sistema de compilación continuo, 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 de 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 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 de plataforma y / o dispositivo 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 los 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 de 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 apks descargados 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 ejecutándose en la misma máquina host.

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

Servicio de prueba

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 constructor de servicios no controla los dispositivos o las aplicaciones que se están ejecutando.

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 está ejecutando en el dispositivo. El propio controlador 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 arbitrarios (incluidas, por ejemplo, métricas de potencia numéricas) en la canalización de informes de resultados estándar.